So what? A person who earns 1k/mon and a person who earns 10k/mon both are able to buy MS windows when they need to. The income makes no difference for a product of which volume is the most important. We are not talking about Bentley or Royce Rolls.
Because the Chinese market is not big enough to justify the cost? 80+% of the population are tied up in agriculture, which makes the none-agriculture population comparable to the US... but given the significantly lower living standards, its not very fesible to "develop something that works for China", at least in the near future, and in the profit driven environment, it's not an attractive investment.
Having a new market as large as the US is not attractive??!!
First, when you double execution units and instruction fetch/decode units and reorder buffers, you are creating two cores! Logical processors share all the execution components but each with a copy of general registers etc.
Second, SMT and CMP (chip multiprocessor) aim to solve different problems. SMT is to overcome the memory access latency. When one logical processor is idling, the other can jump in and make use of the executino unit. CMP is to bringing extra computing power onto the chip without exponentially increasing power comsuption and die size and transistor numbers and design/debug complexity.
Third, clock is really a big problem. At GHz, clock signal cannot travel across a 20mm die. As a result, we either add several low clockrate cores onto the die or choose asynchronous chips which are a hell difficult to design and verify!!
Actually this is not just a wild guess. I have inside information that Intel is going to release 64-core CPUs in 5 years. Those multi-core CPUs target three latest emerging workloads: (1) pattern recognition; (2) data mining; (3) data synthesizing. And it's more a software problem than a hardware challenge. Better figure out how to use all those cores in the most efficient way.
The cause for cache conflict is not a hardware but a software one. Suppose there is one process/thread running on each core. When the two processes have incompatible instruction/data streams that evict each other out of the cache, performance is seriously reduced. This requires an intelligent enough OS scheduler.
The details of experiment done on Viking are available in the chapter five "Blues for a Red Planet" in the book "Cosmos" by Carl Sagan. It also explains why the results of experiemnt are controversial.
Garbage collection problems are far easier than caching problems in networks. There are many reasons. The most important one is that in garbage collection, 'references' are basically 'pointers'. An object that's not pointed to by any other objects is considered garbage. And don't forget, in garbage collection, you can even 'stop the world'!
By contrast, in caching, 'references' are 'client requests', which are unpredictable and highly variable. Furthermore, on busy networks, there is seldom a moment for you to 'stop the world' and 'evolve' for a while!
In the story, people use network simulators and randomly generated requests. Since network simulators are notoriously simplistic and inaccurate, and caching is heavily influenced by real-life workloads, I'm interested to know whether their algorithm is applicable in reality.
In research, it's vital to differentiate between correlation and mechanism. Stating that Linux and Mac OS/X are less secure than Windows based on kindergarten-level integer comparison is correlation: i.e. following/duplicating superficial attributes of known objects in hope of getting the same results in other objects. This is almost always baseless and useless. It's more important to undertand the underlying hidden reasons, or mechanisms: Windows security problems stem from awful designs in OS, such as integration of all sorts of applications into kernel space for speed acceleration. Whilst Linux and Mac OS/X security problems are mostly from mis-configurations.
Slashdot Mirror
They are not idiots. They are sueing Google to get publicized. How many visits can Slashdot generate alone?!
Google for "Intel Vanderpool".
So what? A person who earns 1k/mon and a person who earns 10k/mon both are able to buy MS windows when they need to. The income makes no difference for a product of which volume is the most important. We are not talking about Bentley or Royce Rolls.
First, when you double execution units and instruction fetch/decode units and reorder buffers, you are creating two cores! Logical processors share all the execution components but each with a copy of general registers etc. Second, SMT and CMP (chip multiprocessor) aim to solve different problems. SMT is to overcome the memory access latency. When one logical processor is idling, the other can jump in and make use of the executino unit. CMP is to bringing extra computing power onto the chip without exponentially increasing power comsuption and die size and transistor numbers and design/debug complexity. Third, clock is really a big problem. At GHz, clock signal cannot travel across a 20mm die. As a result, we either add several low clockrate cores onto the die or choose asynchronous chips which are a hell difficult to design and verify!!
Actually this is not just a wild guess. I have inside information that Intel is going to release 64-core CPUs in 5 years. Those multi-core CPUs target three latest emerging workloads: (1) pattern recognition; (2) data mining; (3) data synthesizing. And it's more a software problem than a hardware challenge. Better figure out how to use all those cores in the most efficient way.
The cause for cache conflict is not a hardware but a software one. Suppose there is one process/thread running on each core. When the two processes have incompatible instruction/data streams that evict each other out of the cache, performance is seriously reduced. This requires an intelligent enough OS scheduler.
The details of experiment done on Viking are available in the chapter five "Blues for a Red Planet" in the book "Cosmos" by Carl Sagan. It also explains why the results of experiemnt are controversial.
Garbage collection problems are far easier than caching problems in networks. There are many reasons. The most important one is that in garbage collection, 'references' are basically 'pointers'. An object that's not pointed to by any other objects is considered garbage. And don't forget, in garbage collection, you can even 'stop the world'!
By contrast, in caching, 'references' are 'client requests', which are unpredictable and highly variable. Furthermore, on busy networks, there is seldom a moment for you to 'stop the world' and 'evolve' for a while!
In the story, people use network simulators and randomly generated requests. Since network simulators are notoriously simplistic and inaccurate, and caching is heavily influenced by real-life workloads, I'm interested to know whether their algorithm is applicable in reality.
In research, it's vital to differentiate between correlation and mechanism. Stating that Linux and Mac OS/X are less secure than Windows based on kindergarten-level integer comparison is correlation: i.e. following/duplicating superficial attributes of known objects in hope of getting the same results in other objects. This is almost always baseless and useless. It's more important to undertand the underlying hidden reasons, or mechanisms: Windows security problems stem from awful designs in OS, such as integration of all sorts of applications into kernel space for speed acceleration. Whilst Linux and Mac OS/X security problems are mostly from mis-configurations.