There's really nothing to see here. Just people who read "copy into RAM violates copyright" and either a) misunderstood, or b) have an agenda against copyright law in general, and are being sensational and more than a bit dishonest.
It's worse than that. Many of the posters here are bot authors, bot users, gold sellers or even gold buyers. They astroturf Slashdot whenever the subject turns up.
Some of the posters on this thread are very blatantly from the above list.
I really wish this attitude would filter into the Slashdot groupthink. At the moment, Google is Microsoft's enemy. Slashdot is falling for the "enemy of my enemy is my friend" idea. To put it very geekily, it's applying boolean logic to a tri-state system.
I really wish "X is good" or "X is evil" would filter OUT of the Slashdot groupthink. It's boolean logic to an analog system. Or put in slightly more complex terms - it's a false dichotomy. There are more options than the two extremes people sadly bucket everything into. Stupid people.
It's still 10-100 times more power hungry than the average ARM you find in an MP3 player or mobile phone. Both chips are totally unsuitable for usage in low power small mobile devices. Intel is quite deluded if they think they have a competitor.
So in fact x86 vs ARM is a competition between Intel fab and TSMC fab (and the other) and usually Intel has better process, enough to beat ARM? I don't know..
Absolutely not. No amount of process refinement is going to push x86 to the same power consumption as ARM. Atom is about 10-100 times the power consumption per MHz of current mobile ARMs. It's orders of magnitude short.
The mobile and low power embedded industries have long ago found that they don't need to stick to one architecture. In fact, the desktop industries are starting to realise this too (e.g Apple). You can compile any standards-compliant C/C++ code to another architecture without a problem these days. When you can do that, why would you pick x86? The answer: you don't. You pick ARM as there's a huge number low power, highly integrated SoCs available. Or you pick MIPS for set-top boxes because there's lots of choice of video processing cores for it. Nobody in their right mind picks x86.
Intel needs to make Atom about 100 times better, and until then they'll be laughed out of every mobile phone business visit within minutes.
Remember that MMIX is not designed to be a practical hardware computer architecture. It's designed to illustrate algorithms written in assembly language. It's optimized for humans to read and write, not for computers to execute quickly. I'm glad that he's keeping assembly as part of his books, and that's he's updated them to a 64-bit RISC architecture. Reading MMIX assembly programs is the closest to hardware that some readers will ever get, so he has one chance to show those readers how computers actually work. It had better be as simple as possible for people to understand.
But that's the problem - it's illustrating an architecture that's impractical. It gives the false impression that you don't have to worry about register spillage, a slightly non-orthogonal instruction set or most of the other issues that real world CPUs have to deal with. That's exactly the point of teaching people about a CPU in the first place, and unfortunately MMIX hides you from it.
And worse still - he DOES keep referring to MMIX whenever he talks about how multi-core or multi-threading is bunk.
I expected much, much more from Knuth than what I've just seen in that interview and after reading the design of MMIX.
Knuth dismisses multi-core and multi-threading as a fad and an excuse by manufacturers to stop innovating. I'm amazed someone of his intelligence has managed not to read up on exactly WHY this is happening:
Faster single-thread processing means faster clocking.
Faster clocking means smaller feature size.
Eventually you run into the limit of your process, shrink further and continue.
Finally, you run into the thermal limit of your process, and you cannot go faster in the same area.
To go faster you have to go sideways - more parallelism.
So he dismisses the technical problems that manufacturers have been falling over for the last few years as merely a lack of imagination. No - parallelism is here to stay, and people need to realise it rather than just wishing up some magical world where physics aren't a problem.
He dismisses multi-threading as too hard. It isn't, if you're not unfair to the concept. Nobody is getting 100% out of their single-threaded algorithms. You always have stalls due to cache misses, branching, the CPU not having exactly the right instructions you need, linkage, whatever. Nobody EXPECTS you to get 100% of 1 CPU's theoretical speed. So why do people piss all over multi-core/multi-threading when it doesn't achieve perfect speed-ups?
If you achieve only a 50% speed-up using 2 cores compared to 1, you're done a good job, in my opinion. That means you could have dual-core 3GHz CPU or a single core 4.5GHz CPU. Spot which of those actually exists. Getting a 25-50% speed-up from multi-core is easy. The 100% speed-up is HARD. If you stop concentrating on perfection, you'll notice that multi-threading is a) actually not hard to implement, and b) worthwhile.
Then there's MMIX. Knuth thinks that simplicity has to work all the way down to the CPU design. Yes, but not simplicity by way of having instructions made up of 8 bit opcode and 3x8 bit register indexes. A CPU doesn't give a crap how elegant that looks. It's also BAD design - 256 registers makes for a SLOW register file. It'll either end up being the slow critical path in the CPU (limiting top clock speed) or taking multiple cycles to access. There's also no reason to have 256 opcodes. He should have a look at ARM - it manages roughly the same functionality with much less opcodes.
It almost pains me to see the MMIX design and how it's a) not original, b) done better in existing systems already on the market, e.g ARM, and c) doesn't solve any of the performance limit problems he complains about. What's going on with Knuth?
Not at all. Are you aware of how many embedded Intel chips there are? I am counting the older generation parts, of course. Aren't you also doing so with ARM?
Are you aware of how many embedded ARM chips there are?
Do you know how many mobile phones are sold every year? DSL modems? Cable modems? WiFi routers? MP3 players?
Are you aware that every PC with an Intel chip in it has 1 or more ARM chips in it? Every recent hard disk I've seen has at least 1 (or more) ARM cores driving it. Monitors have them. The interface controller on flash cards sometimes have ARM cores.
That's right - for every Intel CPU sold, they enabled the sale of 1 or more ARM cores because Intel doesn't make a part suitable for some peripheral device. Intel's a minnow and they just don't make the right sort of cores - even with Atom - to beat the existing players.
Hmm, if you're saying they would like to be running at such low power, or are trying to get their chips running at lower power, which is what you seem to be implying, I don't think you're right. As the articles says Intel is making 100k 45nm processors per day, how many micro-watt ultra-mobile processords are made per day?
These apparently mythical chips I'm talking about: a) exist today and b) are in every mobile phone in the world. They make Intel's 100k per day figure look small.
Intel can really be in any processing market they want, and if they're not it's probably because they don't think it's profitable enough.
No, they have repeatedly failed to be in the ultra-portable market. Their latest failure was StrongARM/XScale. They bought it from DEC thinking they could muscle into the market, but due to stupid internal politics (it competed with i960 and even their low end x86) their team could never execute that potential. They sold it to Marvell last year.
Intel just doesn't have what it takes to be in the ultra-portable market, and doesn't look like they ever will. XScale was their best shot at it (it was genuinely really good) and they blew it.
I was under the impression that most of these had extremely lousy performance, and relied on dedicated decoding chips specificly designed for the task they do.
It's a common impression but it's wrong. For example, most of the CPUs you find powering MP3 players do decoding entirely in software. Even many CPUs powering hand-held video players do decoding entirely in software, but to be honest you'll find most of the high-end video players use hardware decode because a) it's faster and b) it's more power efficient.
The performance of the CPUs you find in a most high-end hand-held devices these days is surprisingly good. Well, it's surprising to people who haven't worked in the field, at least. We're constantly somewhat annoyed that the rest of the world hasn't worked it out yet. A high end ARM11 (common in high-end mobile phones) is actually quite competitive to the performance of a Via C3, for example.
These chips aren't designed to go into cellphones, and Intel frankly says they are not going into cellphones. They are instead designed for MIDs that will predominantly run Linux.
That's funny, because according to the link, MIDs are a class of hand-held device invented by Intel. So I'm right - they have a different definition of hand-held to everyone else.
The next generation of Atom at 32nm will have the proper power envelope to run your cellphone BTW.
They will be 10 times more power efficient than their 45nm version? Extremely unlikely. Also consider that the real lower power processor market isn't standing still either - they're managing about a 25%-50% power efficiency improvement per year. Also consider that the current high-end low-power CPUs you find in mobiles are comparable in performance to the first-Gen Centrino chips.
The kind of "hand-held" devices Intel are talking about have big batteries and are held with two hands. 1 Watt is not a lower power device in this market. The real hand-held device chip market measures their power in milliwatts not watts. They idle at a single milliwatt and average a 20-50mW in use. Intel is still running orders of magnitude higher than that.
The Atom architecture is intended to give Intel a foothold in handheld devices that have traditionally been the sole domain of very low-power RISC processors. The chip itself is tiny at less than 25mm square, and, according to Santa Clara, has a TDP of 0.6W - 2.5W, as compared to a 35W TDP for a "typical" Core 2 Duo.
Sigh. They do this every year or two - Intel announces a new core that will get them into more handhelds. They're still an order of magnitude short. Typical "very low-power RISC processors" you see in a device such as a mobile phone or MP3/video player are more like 0.01W - 0.25W, or even less. They're way more efficient clock-for-clock (and MIP-for-MIP) than any x86 core Intel has ever churned out.
Unless they have a funny definition of hand-held device we don't normally use, of course.
For those that don't get it yet: this breaks every other protocol that isn't HTTP.
Sigh, and for those who still don't get it: HTTP is what your web browser uses to get web pages.
All those who are spouting "it's useful" or "I don't understand what the fuss is" or "why can't they do it?"... you simply don't understand the issues and shouldn't be commenting.
The PortalPlayer CPUs don't have WMA decode in hardware. Or any codec for that matter. They just have 2 ARM7 CPUs in them and they decode everything in software.
In order to support WMA they would have to:
Get a WMA license from Microsoft.
Pay Microsoft a license fee.
License the WMA (software) codec from Microsoft.
Adjust their player design to suit Microsoft extremely odious licensing requirements (e.g DRM).
With any luck this will get thrown out of court within nanoseconds along with all fees paid by these idiots. Bet it won't.
Actually, you have it backwards. The x86 can do a handful of RISC instructions with a single instruction. That instruction might take longer to execute, but since you get more done for that one instruction, you get better instruction cache locality.
On all the x86 architectures I know, if you use any instruction which gets microcoded, you end up with a huge performance hit. You basically run single pipelined until the microcode ends. These days, both Intel and AMD datasheets highly recommend you use simple form instructions as much as possible.
Yes, there comes a point where instruction cache locality matters more than instructions per clock. Your average bloated GUI app would benefit more from optimise-for-size than optimise-for-speed, for example (and I wish people would realise that). Anything which pumps large amounts of data would be screwed if you did that, though.
In any case, the point is that other architectures CAN perform far better than x86 without the variable opcode length, prefixing and other nonsense. They don't produce large amounts of executable either.
In non-benchmarks, it's a win because it's a compression for executable code.
It's only a win if your execution is bottlenecked by instruction bus bandwidth. That only happens if you're thrashing your L1 instruction cache, and THAT only happens with horribly bloated software and/or horribly small L1 caches.
While it's a good compression of executable code, it's good compression of x86 code. Other ISAs manage to pack way more into their instructions in the first place. Plus, the random alignment of x86 instructions means that the pipeline is elongated by a couple of stages just to find the start of them!
Sorry, but x86 being a nice compression is a half-truth. Other ISAs manage just fine being, for example, fixed 32 bits per instruction and massively benefit from the simpler design. They also tend to be roughly as compact as x86. If you really want to see a properly compressed ISA take a look at Thumb-2.
You sir - thank you for proving my point completely unintentionally! You have no real grasp of why these units are either base-2 or base-10. You very obviously have no idea about the order of magnitude of these things or what they mean. Yet you have an opinion about which they should be - even though you have no idea what either means. Typical slashdot poster.
You only have an opinion on the matter because the storage manufacturers MADE it matter. If all storage was base-2 and comms/rates was base-10, you would never have thought of posting your wall of poorly capitalised text. It would never have occurred to you, because you never knew there was a subtle difference and nobody ever used one or the other deceptively.
Trouble is, they ARE used deceptively. But only in marketing.
Engineers, on the other hand, have ABSOLUTELY NO CONFUSION when they use the word "megabyte". It's 99% of the time very obvious which they mean. Again, if it's a storage size, it's base-2, and if it's a comms rate, it's base-10. No problems. The only problem comes when marketing and accounting realise they can overstate a product by 5-10% by confusing things.
Don't spout stuff you don't understand and heard elsewhere. THAT is what I mean by a history re-writing meme.
The standards are: storage is in base-2, external communication rates are in base-10. There is no confusion. If you ever work with storage and comms, it's really fucking obvious which is which. There is rarely confusion unless you are reading a datasheet which has been infected by marketing.
Storage is very naturally base-2 due to reasons that are obvious to anyone who programs.
Comms is very naturally base-10 due to reasons that are obvious to anyone who uses DSP or ever put a scope probe on a circuit.
Anyone who says there is confusion has never done the above.
The average customer has absolutely no idea what 1MB is whether it's in base 10 or base 2.
Customers would have had absolutely no reason to ask whether it's one or the other if manufacturers hadn't started being deceptive about which they used.
Thank you for also successfully managing to muddle the number of bits in a byte. You should work for Seagate.
Hard to find non-revised history these days, unfortunately. Even the wikipedia entry on the matter says that the silly SI "MeB" and "MiB" units are authoritative ways to say things. Sigh.
Check out 9 of the other 12 replies for more revisionism.
This is all very well but you are totally wrong. Go download a datasheet of a popular FLASH part. Guess what? The capacity is an exact power of 2.
I'm not just making this up. NAND is naturally base-2 capacity sized. Yes, there is sparing, but pages are normally 2048 byte (or larger these days) with a few extra bytes per 512 for ECC. The non-ECC areas are still power-of-2 based, and the chip area itself is square and ends up being another power-of-2 pages. End result, a power-of-2. I've been working on this stuff for about 6 years now - I'm not just coming up with it randomly.
Slightly optimistic numbers, there. The USB connectors, packaging and controllers are nowhere near $15 (more like $1-$2). Even so, the $8:GB ratio only holds for small numbers. The biggest problem with flash at the moment is scaling.
Each flash chip needs board space, soldering, and bus routing. So, each chip has 20 or so (depending on bus width) bus lines connecting it. That's just for 8GB. Now for a big drive, we'll need 16 of those. That's 16 chips stuck down on the board, making it a fair large board with a monster amount of bus routing. This is also where electrical engineers stick their hands up and say words like "bus capacitance, surely?" - in other words, it's not going to work for crap without buffers and other stuff stuck in there too.
So no - it simply does not scale well. Flash is very cheap at small sizes simply because it's so easy to interface it and wire it up. Wiring up 16 of them to one controller is not. This is why big SSDs are so damn expensive.
I predict that small form factor PCs (e.g laptops, media centers) may all end up using flash fairly soon, but desktops and servers aren't going that way any time soon. The technology isn't quite there, yet.
On that subject, whenever the 2^n or 10^n units thing gets brought up, some smart arse always says "it's so illogical to have binary based sizes like that, it's so confusing and the media doesn't work in binary anyway."
This is just history re-writing bullshit that someone spouts to get mod points and continue another meme.
There was a time when hard disks were all based on megabytes, and megabytes were always 2^20 = 1048576 bytes. NOBODY EVER GOT CONFUSED. History re-writers say otherwise, obviously. Where did it all change? Well, for hard disk manufacturers, it was a blatantly cheap trick to save 5-10% costs, and whenever anyone complained they could just to that viral history re-write meme about how binary based units were always confusing. Hell, they even convinced SI. SI have absolutely no authority or experience with determining computer units, and the "solution" they came up with is even more confusing and ugly. How do you tell if MeB or MiB is 2^20 or 10^6? Muppets.
Then came flash cards. Here's a thing a lot of people don't know: flash actually DOES come in binary sizes. That's how it's manufactured. Another thing a lot of people don't know: flash actually gets WORSE for write endurance as its density goes up. It's actually got much worse over time. To begin with, low density flash cards did not suffer much from write endurance problems - to the extent that when you got an 8MB flash card it was basically just writing straight through.
Densities went up, and you started to need a lot of spares, more error correction, and wear leveling. The result was that after formatting, you ended up with about 5-10% of your flash used up. Quite handily close to the decimal-based size. So manufacturers (and I believe SanDisk were the first to do this) silently started selling 64MB cards as 64,000,000 bytes of data instead of 67,108,864. No asterisks, no notes on the bottom of the packaging - nothing. It's fair enough, but done in a fucking deceptive manner.
I remember getting bug reports about our MP3 players (years back now) misreporting SanDisk flash cards as 61MB instead of 64MB. In the end (sigh) we put in a hack to spot deceptive cards and switch units to powers of 10.
So before anyone else spouts how the units are confusing - they weren't until manufacturers tried their damned hardest to make sure they were.
Next, people will complain about how SDRAM, caches and even registers are in silly powers of 2...
Does anybody know how well flash SSDs perform in RAID arrays? 15kRPM SAS drives are horrendously expensive so if I could plug a couple small flash drives into my RAID card (RAID 0) I'd be a happy camper. Can't find benchmarks anywhere and flash drives have horrible write speeds which means they have terrible OLTP performance.
Individual flash chips have terrible write performance, mostly due to the slow block erase time. However, you always use multiple chips in high capacity storage devices (anything larger than an MP3 player), and you can start doing fancy tricks with interleaving, or just plain have way more buffer memory to hide the erase time. If you really want to crank out even higher performance, then you stick multiple NAND interfaces of the controller chip and drive it all in parallel.
If you stack about 4-8 chips in a device, you start getting stream throughput comparable to a 15k drive. Also bear in mind that the chips we're talking about here are already stacked 4-8 internally anyway! The limiting factor will probably end up being the NAND flash bus (or number of busses) connecting the controller to the flash chips.
Slashdot Mirror
There's really nothing to see here. Just people who read "copy into RAM violates copyright" and either a) misunderstood, or b) have an agenda against copyright law in general, and are being sensational and more than a bit dishonest.
It's worse than that. Many of the posters here are bot authors, bot users, gold sellers or even gold buyers. They astroturf Slashdot whenever the subject turns up.
Some of the posters on this thread are very blatantly from the above list.
I really wish this attitude would filter into the Slashdot groupthink. At the moment, Google is Microsoft's enemy. Slashdot is falling for the "enemy of my enemy is my friend" idea. To put it very geekily, it's applying boolean logic to a tri-state system.
I really wish "X is good" or "X is evil" would filter OUT of the Slashdot groupthink. It's boolean logic to an analog system. Or put in slightly more complex terms - it's a false dichotomy. There are more options than the two extremes people sadly bucket everything into. Stupid people.
It's still 10-100 times more power hungry than the average ARM you find in an MP3 player or mobile phone. Both chips are totally unsuitable for usage in low power small mobile devices. Intel is quite deluded if they think they have a competitor.
So in fact x86 vs ARM is a competition between Intel fab and TSMC fab (and the other) and usually Intel has better process, enough to beat ARM? I don't know..
Absolutely not. No amount of process refinement is going to push x86 to the same power consumption as ARM. Atom is about 10-100 times the power consumption per MHz of current mobile ARMs. It's orders of magnitude short.
The mobile and low power embedded industries have long ago found that they don't need to stick to one architecture. In fact, the desktop industries are starting to realise this too (e.g Apple). You can compile any standards-compliant C/C++ code to another architecture without a problem these days. When you can do that, why would you pick x86? The answer: you don't. You pick ARM as there's a huge number low power, highly integrated SoCs available. Or you pick MIPS for set-top boxes because there's lots of choice of video processing cores for it. Nobody in their right mind picks x86.
Intel needs to make Atom about 100 times better, and until then they'll be laughed out of every mobile phone business visit within minutes.
Remember that MMIX is not designed to be a practical hardware computer architecture. It's designed to illustrate algorithms written in assembly language. It's optimized for humans to read and write, not for computers to execute quickly. I'm glad that he's keeping assembly as part of his books, and that's he's updated them to a 64-bit RISC architecture. Reading MMIX assembly programs is the closest to hardware that some readers will ever get, so he has one chance to show those readers how computers actually work. It had better be as simple as possible for people to understand.
But that's the problem - it's illustrating an architecture that's impractical. It gives the false impression that you don't have to worry about register spillage, a slightly non-orthogonal instruction set or most of the other issues that real world CPUs have to deal with. That's exactly the point of teaching people about a CPU in the first place, and unfortunately MMIX hides you from it.
And worse still - he DOES keep referring to MMIX whenever he talks about how multi-core or multi-threading is bunk.
I expected much, much more from Knuth than what I've just seen in that interview and after reading the design of MMIX.
Knuth dismisses multi-core and multi-threading as a fad and an excuse by manufacturers to stop innovating. I'm amazed someone of his intelligence has managed not to read up on exactly WHY this is happening:
So he dismisses the technical problems that manufacturers have been falling over for the last few years as merely a lack of imagination. No - parallelism is here to stay, and people need to realise it rather than just wishing up some magical world where physics aren't a problem.
He dismisses multi-threading as too hard. It isn't, if you're not unfair to the concept. Nobody is getting 100% out of their single-threaded algorithms. You always have stalls due to cache misses, branching, the CPU not having exactly the right instructions you need, linkage, whatever. Nobody EXPECTS you to get 100% of 1 CPU's theoretical speed. So why do people piss all over multi-core/multi-threading when it doesn't achieve perfect speed-ups?
If you achieve only a 50% speed-up using 2 cores compared to 1, you're done a good job, in my opinion. That means you could have dual-core 3GHz CPU or a single core 4.5GHz CPU. Spot which of those actually exists. Getting a 25-50% speed-up from multi-core is easy. The 100% speed-up is HARD. If you stop concentrating on perfection, you'll notice that multi-threading is a) actually not hard to implement, and b) worthwhile.
Then there's MMIX. Knuth thinks that simplicity has to work all the way down to the CPU design. Yes, but not simplicity by way of having instructions made up of 8 bit opcode and 3x8 bit register indexes. A CPU doesn't give a crap how elegant that looks. It's also BAD design - 256 registers makes for a SLOW register file. It'll either end up being the slow critical path in the CPU (limiting top clock speed) or taking multiple cycles to access. There's also no reason to have 256 opcodes. He should have a look at ARM - it manages roughly the same functionality with much less opcodes.
It almost pains me to see the MMIX design and how it's a) not original, b) done better in existing systems already on the market, e.g ARM, and c) doesn't solve any of the performance limit problems he complains about. What's going on with Knuth?
Not at all. Are you aware of how many embedded Intel chips there are? I am counting the older generation parts, of course. Aren't you also doing so with ARM?
Are you aware of how many embedded ARM chips there are?
Do you know how many mobile phones are sold every year? DSL modems? Cable modems? WiFi routers? MP3 players?
Are you aware that every PC with an Intel chip in it has 1 or more ARM chips in it? Every recent hard disk I've seen has at least 1 (or more) ARM cores driving it. Monitors have them. The interface controller on flash cards sometimes have ARM cores.
That's right - for every Intel CPU sold, they enabled the sale of 1 or more ARM cores because Intel doesn't make a part suitable for some peripheral device. Intel's a minnow and they just don't make the right sort of cores - even with Atom - to beat the existing players.
Hmm, if you're saying they would like to be running at such low power, or are trying to get their chips running at lower power, which is what you seem to be implying, I don't think you're right. As the articles says Intel is making 100k 45nm processors per day, how many micro-watt ultra-mobile processords are made per day?
These apparently mythical chips I'm talking about: a) exist today and b) are in every mobile phone in the world. They make Intel's 100k per day figure look small.
Intel can really be in any processing market they want, and if they're not it's probably because they don't think it's profitable enough.
No, they have repeatedly failed to be in the ultra-portable market. Their latest failure was StrongARM/XScale. They bought it from DEC thinking they could muscle into the market, but due to stupid internal politics (it competed with i960 and even their low end x86) their team could never execute that potential. They sold it to Marvell last year.
Intel just doesn't have what it takes to be in the ultra-portable market, and doesn't look like they ever will. XScale was their best shot at it (it was genuinely really good) and they blew it.
I was under the impression that most of these had extremely lousy performance, and relied on dedicated decoding chips specificly designed for the task they do.
It's a common impression but it's wrong. For example, most of the CPUs you find powering MP3 players do decoding entirely in software. Even many CPUs powering hand-held video players do decoding entirely in software, but to be honest you'll find most of the high-end video players use hardware decode because a) it's faster and b) it's more power efficient.
The performance of the CPUs you find in a most high-end hand-held devices these days is surprisingly good. Well, it's surprising to people who haven't worked in the field, at least. We're constantly somewhat annoyed that the rest of the world hasn't worked it out yet. A high end ARM11 (common in high-end mobile phones) is actually quite competitive to the performance of a Via C3, for example.
These chips aren't designed to go into cellphones, and Intel frankly says they are not going into cellphones. They are instead designed for MIDs that will predominantly run Linux.
That's funny, because according to the link, MIDs are a class of hand-held device invented by Intel. So I'm right - they have a different definition of hand-held to everyone else.
The next generation of Atom at 32nm will have the proper power envelope to run your cellphone BTW.
They will be 10 times more power efficient than their 45nm version? Extremely unlikely. Also consider that the real lower power processor market isn't standing still either - they're managing about a 25%-50% power efficiency improvement per year. Also consider that the current high-end low-power CPUs you find in mobiles are comparable in performance to the first-Gen Centrino chips.
The kind of "hand-held" devices Intel are talking about have big batteries and are held with two hands. 1 Watt is not a lower power device in this market. The real hand-held device chip market measures their power in milliwatts not watts. They idle at a single milliwatt and average a 20-50mW in use. Intel is still running orders of magnitude higher than that.
The Atom architecture is intended to give Intel a foothold in handheld devices that have traditionally been the sole domain of very low-power RISC processors. The chip itself is tiny at less than 25mm square, and, according to Santa Clara, has a TDP of 0.6W - 2.5W, as compared to a 35W TDP for a "typical" Core 2 Duo.
Sigh. They do this every year or two - Intel announces a new core that will get them into more handhelds. They're still an order of magnitude short. Typical "very low-power RISC processors" you see in a device such as a mobile phone or MP3/video player are more like 0.01W - 0.25W, or even less. They're way more efficient clock-for-clock (and MIP-for-MIP) than any x86 core Intel has ever churned out.
Unless they have a funny definition of hand-held device we don't normally use, of course.
Sigh, and for those who still don't get it: HTTP is what your web browser uses to get web pages.
All those who are spouting "it's useful" or "I don't understand what the fuss is" or "why can't they do it?"... you simply don't understand the issues and shouldn't be commenting.
Do you have any idea about the rarity and expense of small VGA resolution LCDs? There's a reason most mobile phones don't have a lot of pixels.
The PortalPlayer CPUs don't have WMA decode in hardware. Or any codec for that matter. They just have 2 ARM7 CPUs in them and they decode everything in software.
In order to support WMA they would have to:
With any luck this will get thrown out of court within nanoseconds along with all fees paid by these idiots. Bet it won't.
On all the x86 architectures I know, if you use any instruction which gets microcoded, you end up with a huge performance hit. You basically run single pipelined until the microcode ends. These days, both Intel and AMD datasheets highly recommend you use simple form instructions as much as possible.
Yes, there comes a point where instruction cache locality matters more than instructions per clock. Your average bloated GUI app would benefit more from optimise-for-size than optimise-for-speed, for example (and I wish people would realise that). Anything which pumps large amounts of data would be screwed if you did that, though.
In any case, the point is that other architectures CAN perform far better than x86 without the variable opcode length, prefixing and other nonsense. They don't produce large amounts of executable either.
It's only a win if your execution is bottlenecked by instruction bus bandwidth. That only happens if you're thrashing your L1 instruction cache, and THAT only happens with horribly bloated software and/or horribly small L1 caches.
While it's a good compression of executable code, it's good compression of x86 code. Other ISAs manage to pack way more into their instructions in the first place. Plus, the random alignment of x86 instructions means that the pipeline is elongated by a couple of stages just to find the start of them!
Sorry, but x86 being a nice compression is a half-truth. Other ISAs manage just fine being, for example, fixed 32 bits per instruction and massively benefit from the simpler design. They also tend to be roughly as compact as x86. If you really want to see a properly compressed ISA take a look at Thumb-2.
You sir - thank you for proving my point completely unintentionally! You have no real grasp of why these units are either base-2 or base-10. You very obviously have no idea about the order of magnitude of these things or what they mean. Yet you have an opinion about which they should be - even though you have no idea what either means. Typical slashdot poster.
You only have an opinion on the matter because the storage manufacturers MADE it matter. If all storage was base-2 and comms/rates was base-10, you would never have thought of posting your wall of poorly capitalised text. It would never have occurred to you, because you never knew there was a subtle difference and nobody ever used one or the other deceptively.
Trouble is, they ARE used deceptively. But only in marketing.
Engineers, on the other hand, have ABSOLUTELY NO CONFUSION when they use the word "megabyte". It's 99% of the time very obvious which they mean. Again, if it's a storage size, it's base-2, and if it's a comms rate, it's base-10. No problems. The only problem comes when marketing and accounting realise they can overstate a product by 5-10% by confusing things.
Don't spout stuff you don't understand and heard elsewhere. THAT is what I mean by a history re-writing meme.
The standards are: storage is in base-2, external communication rates are in base-10. There is no confusion. If you ever work with storage and comms, it's really fucking obvious which is which. There is rarely confusion unless you are reading a datasheet which has been infected by marketing.
Storage is very naturally base-2 due to reasons that are obvious to anyone who programs.
Comms is very naturally base-10 due to reasons that are obvious to anyone who uses DSP or ever put a scope probe on a circuit.
Anyone who says there is confusion has never done the above.
The average customer has absolutely no idea what 1MB is whether it's in base 10 or base 2.
Customers would have had absolutely no reason to ask whether it's one or the other if manufacturers hadn't started being deceptive about which they used.
Thank you for also successfully managing to muddle the number of bits in a byte. You should work for Seagate.
Hard to find non-revised history these days, unfortunately. Even the wikipedia entry on the matter says that the silly SI "MeB" and "MiB" units are authoritative ways to say things. Sigh.
Check out 9 of the other 12 replies for more revisionism.
This is all very well but you are totally wrong. Go download a datasheet of a popular FLASH part. Guess what? The capacity is an exact power of 2.
I'm not just making this up. NAND is naturally base-2 capacity sized. Yes, there is sparing, but pages are normally 2048 byte (or larger these days) with a few extra bytes per 512 for ECC. The non-ECC areas are still power-of-2 based, and the chip area itself is square and ends up being another power-of-2 pages. End result, a power-of-2. I've been working on this stuff for about 6 years now - I'm not just coming up with it randomly.
That and, as another reply points out, your numbers are in fact off by an order of magnitude anyway :)
Slightly optimistic numbers, there. The USB connectors, packaging and controllers are nowhere near $15 (more like $1-$2). Even so, the $8:GB ratio only holds for small numbers. The biggest problem with flash at the moment is scaling.
Each flash chip needs board space, soldering, and bus routing. So, each chip has 20 or so (depending on bus width) bus lines connecting it. That's just for 8GB. Now for a big drive, we'll need 16 of those. That's 16 chips stuck down on the board, making it a fair large board with a monster amount of bus routing. This is also where electrical engineers stick their hands up and say words like "bus capacitance, surely?" - in other words, it's not going to work for crap without buffers and other stuff stuck in there too.
So no - it simply does not scale well. Flash is very cheap at small sizes simply because it's so easy to interface it and wire it up. Wiring up 16 of them to one controller is not. This is why big SSDs are so damn expensive.
I predict that small form factor PCs (e.g laptops, media centers) may all end up using flash fairly soon, but desktops and servers aren't going that way any time soon. The technology isn't quite there, yet.
On that subject, whenever the 2^n or 10^n units thing gets brought up, some smart arse always says "it's so illogical to have binary based sizes like that, it's so confusing and the media doesn't work in binary anyway."
This is just history re-writing bullshit that someone spouts to get mod points and continue another meme.
There was a time when hard disks were all based on megabytes, and megabytes were always 2^20 = 1048576 bytes. NOBODY EVER GOT CONFUSED. History re-writers say otherwise, obviously. Where did it all change? Well, for hard disk manufacturers, it was a blatantly cheap trick to save 5-10% costs, and whenever anyone complained they could just to that viral history re-write meme about how binary based units were always confusing. Hell, they even convinced SI. SI have absolutely no authority or experience with determining computer units, and the "solution" they came up with is even more confusing and ugly. How do you tell if MeB or MiB is 2^20 or 10^6? Muppets.
Then came flash cards. Here's a thing a lot of people don't know: flash actually DOES come in binary sizes. That's how it's manufactured. Another thing a lot of people don't know: flash actually gets WORSE for write endurance as its density goes up. It's actually got much worse over time. To begin with, low density flash cards did not suffer much from write endurance problems - to the extent that when you got an 8MB flash card it was basically just writing straight through.
Densities went up, and you started to need a lot of spares, more error correction, and wear leveling. The result was that after formatting, you ended up with about 5-10% of your flash used up. Quite handily close to the decimal-based size. So manufacturers (and I believe SanDisk were the first to do this) silently started selling 64MB cards as 64,000,000 bytes of data instead of 67,108,864. No asterisks, no notes on the bottom of the packaging - nothing. It's fair enough, but done in a fucking deceptive manner.
I remember getting bug reports about our MP3 players (years back now) misreporting SanDisk flash cards as 61MB instead of 64MB. In the end (sigh) we put in a hack to spot deceptive cards and switch units to powers of 10.
So before anyone else spouts how the units are confusing - they weren't until manufacturers tried their damned hardest to make sure they were.
Next, people will complain about how SDRAM, caches and even registers are in silly powers of 2...
Individual flash chips have terrible write performance, mostly due to the slow block erase time. However, you always use multiple chips in high capacity storage devices (anything larger than an MP3 player), and you can start doing fancy tricks with interleaving, or just plain have way more buffer memory to hide the erase time. If you really want to crank out even higher performance, then you stick multiple NAND interfaces of the controller chip and drive it all in parallel.
If you stack about 4-8 chips in a device, you start getting stream throughput comparable to a 15k drive. Also bear in mind that the chips we're talking about here are already stacked 4-8 internally anyway! The limiting factor will probably end up being the NAND flash bus (or number of busses) connecting the controller to the flash chips.