ARM has ARM mode, Thumb Mode, Jazelle Mode, and ThumbEE mode.
FOUR instruction sets. Multiple different floating point unit specs that are incompatible with each other. Crazy page table formats. The architecture spec is over 2000 pages long, for pete's sake!
ARM has a more uniform encoding, but actually has a large number of instructions, and does crazy things like put a rotating shifter in the load address path. Not good from a modern pipeline perspective. You can get around it by breaking up the operation, but then you're getting into complex instruction decode like x86.
I'm not saying ARM is bad. I'm just saying they have no magic. You're right, Intel doesn't either (though they do have manufacturing and an army of engineers to do hand-layout). Nor does MIPS or PPC. But MIPS does make energy efficient cores, roughly as good as ARM. They haven't been as popular as ARM, but they're around.
And I'm certainly not saying x86 is great -- it's certainly not. I don't think it's quite as bad as people make it out to be...
Look, I wish the architecture made a difference. For one, we'd all probably be using Alpha. That was a great, elegant, beautiful processor architecture. For another, I'd have much better job prospects. But it doesn't matter that much. Scalar architectures are scalar architectures. Instruction set makes some difference, but not very much.
Yes, ARM marketing (notoriously overoptimistic) says they will have a 2GHz A9 in 28nm, relatively high performance process.
But A9, in terms of efficiency, is not substantially better than where Atom will be. That shouldn't be surprising. They're both scalar architectures. They both have a little less than 15 useful registers. They both have similarly deep pipelines. They both rely on branch prediction for performance. Neither company has magic, it's not surprising that they're similar on the curve of performance / efficiency.
Put another way, your instruction encoding doesn't really buy you all that much.
Now ARM has some lower-end cores (ARM9, ARM11, Sparrow/CoretexA5) that are much more energy efficient than Atom. But they're also much lower performance.
But this is how ARM's marketing plays it out: we have super-efficient cores (ARM9)! We have higher-performance cores (Theoretically, A9)! You think that ARM cores are somehow both high performance and much more efficient than Atom will be in the same technology... but this will probably turn out to be false.
Put another way... are MIPS or PowerPC cores dramatically more efficient than x86 at similar performance levels? No. They have most of the same architecture benefits that ARM does... more, in many ways, because they have about double the number of useful registers. But they're on basically the same efficiency/performance curve as everyone else.
You could probably do an x86 implementation that was similar to ARM11/A5... no floating point, no SSE, just the basic 386 instruction set. Give it a short pipeline and turn down the frequency, and it will probably compete relatively well on energy efficiency with those low-end ARMs.
The thing I DON'T understand... why does ARM marketing get an article on slashdot every week or so?
I'm continually unimpressed with ARM implementations.
They claim that they are low power and high performance, but at the end of the day, on real benchmarks, they always disappoint.
And it's not surprising. It's a serial architecture with only 15 registers. That's the same as x86-64. x86 decode isn't trivial, but Intel has gotten good at it. And ARM isn't without its instruction set issues; the encoding isn't incredibly straightforward as they've gone back and crammed things in like Thumb2.
So the architectures are roughly a draw. Maybe ARM has a slight advantage theoretically in slightly smaller code size, and Intel likely has an advantage in practice that there is a bigger ecosystem.
So then it all comes down to implementation and process. Both of which Intel does very well. Atom is a full-custom, well floorplanned, very nice chip. It was their first try as a "low power" chip, and it performs quite well for the energy on real-world things you need to do. ARM, which traditionally has sold soft macros, hopes to compete? For those of you software folks, "full custom" == hand-optimized, "soft macro" == source code. Sometimes the compiler can do a decent job, but Intel does fully custom designs for a reason.
I think the main thing ARM has going for it is hype. TrustZone(TM) is the most highly-marketed physical address bit I've ever seen. They lucked into being the default control processor at the low end, and have made a decent business out of selling soft cores to folks needing small amounts of processing power.
But they have no special magic. They have a ho-hum architecture, certainly inferior to something like Alpha. They have a set of simple, low-performance designs that get decent energy efficiency. And they have a great marketing engine and speak loudly.
The real reason you might see netbooks with ARM cores is that the manufacturers are just reusing smartphone chips, or have some other special SOC they want to reuse. You can license an ARM and put around it all kinds of interfaces and accelerators. But now you can get an Atom core from TSMC, too, so maybe the advantage is waning....
Why don't you see phones that only support the 3G protocols?
Because they're not ubiquitous. You will end up somewhere where coverage isn't so great for your new protocol. If you can handoff to an older protocol, you will keep your connection. So this is why even a few years ago you could get Verizon phones that still supported AMPS, why every phone that supports EV-DO also supports 1X (and older standards), and why every phone with WCDMA/HSDPA/HSUPA/etc still supports plain old GSM/GPRS/EDGE.
It's also why it doesn't make a lot of sense to have a WiMAX only phone. You need at least WiMAX+GSM, or WiMAX+CDMA1X. You need to be able to hand off to the older interfaces. And probably you want to support everything... WiMAX when it's available, HSDPA or WCDMA when that's available but WiMAX isn't, or GSM/GPRS/EDGE when that's all that's available.
Or maybe you never leave downtown Atlanta. Then maybe WiMAX-only would be fine, assuming you trust the reliability of the relatively new network.
Linux has plenty of critics. Developers are critical of their own code. Just look through the lkml or read the code, there are plenty of places where there is constructive criticism about how something is done.
Like I said, we were only interested in one application: our simulator. It was developed for gcc and suncc for sparc. icc produced a slower binary. ICC may be faster over a wide variety of benchmarks, and probably especially ones where vectorization, etc can be used. However, for our simulator, gcc produced better results.
Look, I would love nothing more than ARM to win. Because if ARM wins, it opens up the door for innovation in architecture. And that's good for everyone.
But they won't. Intel can make x86 chips that are low cost and low power consumption. And ARM is rapidly approaching implementation requirements that mean it's not as simple as you think it is. They overcrowded the opcode space, making decode hard. Thumb2 means serial decode problems, just like x86. And the whole anything-shifted-by-anything field on every instruction isn't so great for decent OoO pipelines. You end up having what amount to microcoded instructions with the move-multiples. So you end up doing basically the same things Intel would do -- breaking up instructions, speculative decode blocks, microcoded instructions, etc -- and Intel has been doing it longer and better.
Two operating modes, seven supervisor modes, various page table formats, thousands of instructions (when you consider addressing modes and condexec and ARM/THUMB and Neon and VFP and...)... do you really think that ARM is *really* all that much more simple than x86?
ARM ain't no Alpha. ARM ain't no MIPS.
So maybe ARM has a niche in ARM7 and ARM9 class tiny, licensable, synthesizeable 32-bit microcontrollers that run at speeds of up to 200Mhz, but I'm afraid ARM won't be able to compete with Intel when it comes to gigahertz-level processors.
Oh, and as for thinking like a "techy", in the end the only thing that matters is "Does it run my office suite" and "does it run my games". And the answer is likely "no" if you have an ARM. Because at the end of the day, nearly everyone runs Microsoft Office and nearly everyone ends up with some games compiled for x86.
Like I said, I hope I'm wrong. It's much, much, much better for my career and the future of computing if ARM starts doing great. But I don't think I'm wrong. Too bad, too.
The reason to go with x86 is because ARM is just as shitty of an architecture.
Seven supervisor modes now? Horrible page table format? Have you seen what they are planning for 64-bit addressing?
Even more importantly than the CPU architecture, the ARM busses are typically very low performance. And if most of the time is dealt with memory movement, having a better bus dwarfs what's going on with the CPU.
So, in the end, you have slow cores. Intel knows how to make x86 fast. And, as they are starting to show, they can make it low power also.
ARM has yet to show a fast core. They don't use that much power, but if "netbooks" are low end laptops instead of high end cell phones, a few watts is fine.
Oh, and did I mention that x86 cores are x86 compatible? That makes the software barrier to entry a lot lower.
To compete with Intel, you have to be better. A lot better. For very low end, ARM is better, because all that matters is leakage power, and after that all that matters is power for very small processing. At a higher level of performance, ARM is different, but perhaps not better. Maybe the ARM architecture has some features which make it less complex to implement than x86. But at the end of the day if nobody is making ARM cores that spank x86 cores, x86 will win. Didn't you learn this from PowerPC? Don't you realize the same thing will probably happen to ARM except at the extremely low end? And even there, if Intel decides to start licensing 386 synthesizeable cores, how long do you think ARM7 and ARM9 will last?
I'll second Innumeracy, and also add _A Mathematician's Apology_, by Hardy, which can be red in full (Evidentially) here. A quote from it:
The mathematician's patterns, like the painter's or the poet's
must be beautiful; the ideas like the colours or the words, must fit
together in a harmonious way. Beauty is the first test: there is no
permanent place in the world for ugly mathematics.
Make sure you do your own regular backups, clearcase will eat your repository in a disastrous way, and you'll wait for IT to fix it for 2 weeks. At least, that was my experience with clearcase.
Incorrect. 21mbps for a user in a 5MHz band of spectrum. Multiple spectrum bands per cell, multiple reuse of the frequency bands per cell using directional antennas (eg, 120 degree partitioning). And reuse of the spectrum band for multiple users using code division.
You're sharing the backhaul from the tower to whatever it talks to, though.
Telstra is rolling out HSPA+ Jan 2009 @ 21Mbps. That's 21Mbps in a single 5Mhz band of spectrum, without MIMO.
If you use two bands (10Mhz) you get Multicarrier HSPA+, which peaks at 42Mbps. I'm sure you could stick more bands together and get even higher rates.
With HSPA+ getting 21+ Mbps in a single 5Mhz carrier, are folks really going to get that much improvement in areas with lots of users with WiMAX at 100Mbps in a 20Mhz carrier? There's only so much spectrum...
It's a huge kludge for idiotic processors (like arm9) that don't have physically-tagged caches. On all non-incredibly-sucky processors, we have physically tagged caches, and so having every app have its own address space, or having multiple apps share physical pages at different virtual addresses, all of these are fine.
Problems with SAS:
Everything has to be compiled Position-independent, or pre-linked for a specific location
Virtual memory fragmentation as applications are loaded and unloaded
Where is the heap? Is there one? Or one per process?
COW and paging get harder
People start using it and think it's a good idea.
Most people... even people using ARM... are using processors with physically-tagged caches. Please, Please, Please, don't further the madness of single-address-space environments. There are still people encouraging this crime against humanity.
Maybe I'm a bit bitter, because some folks in my company have drunk the SAS kool-aid. But believe me, unless you have ARM9, it's not worth it!
Maximum information rate is bandwidth times the log2 of (1+signal/noise).
Signal/noise ratio is mainly determined by things like the type and number of antennas and how you use them (to do beamforming, etc).
Bandwidth is a fixed quantity, you can only get so much from the government.
So given that with modern 3G protocols, we get pretty close to the Shannon limit for a given antenna technology, how are huge gains available by switching to WiMAX? They can get big bandwidths for a single user by eating up lots of spectrum (and they do, like 20Mhz at a time), but overall throughput for all users... is it really better than provisioning that 20Mhz into several HSUPA+ channels?
I'm talking about H.264. That's about as good as it gets right now, but it's pretty darn good. Turn on all the bells and whistles -- a large ME window, B-frames, CABAC -- and you get really really good compression, beautiful video at 25-30% of the bit rate of MPEG2. At least from my experience. Maybe I'm not a Motion Picture Expert.
A single sided DVD can hold roughly 8G of data.
That's roughly 10 megabits average for a 120 minute movie
10 megabits Average Bit Rate looks quite good for 24-30 fps @720p. I haven't tried the same clip at 24-30fps @1080p, which is somewhere north of 2x the number of pixels. Maybe it's not so great... but given the quality at 5Mbps @720p, I would imagine I would enjoy the movie.
Heck, OTA uses not too much more bit rate, and it's MPEG2.
You can easily fit HD video on DVD media using H.264 compression. The only reason you need the storage of HD-DVD or Blu-Ray is if you:
Want to force customers to buy new, expensive players instead of minor DSP/Firmware upgrades to existing player designs
Want to force customers to have a difficult time making their own HD media because Blu-Ray writable media and burners are too expensive.
Believe that by making the size larger that pirates can't figure out how to transcode to a smaller formant before posting on the internet (and that 30G images are too big to download)
Want to be able to ship many movies on a single disc... but that doesn't seem to be happening
The companies could have come up with a new format using better compression. Players would be marginally more expensive because of increased decode processing, but in general I think you'd see $30 DVD players become $35 DVD/HD players very fast because of the very marginal increase in capabilities needed.
Who cares about saving money in the government any more? You can just get some more bonds issued... more free money! It's even better if you're the Federal Government, the Federal Reserve will loan you all the money you want. You can loose (literally) tons of hundred dollar bills and not care! A few computers a couple of years old is chump change.
Maybe you didn't get the memo.
Slashdot Mirror
ARM has ARM mode, Thumb Mode, Jazelle Mode, and ThumbEE mode. FOUR instruction sets. Multiple different floating point unit specs that are incompatible with each other. Crazy page table formats. The architecture spec is over 2000 pages long, for pete's sake!
ARM has a more uniform encoding, but actually has a large number of instructions, and does crazy things like put a rotating shifter in the load address path. Not good from a modern pipeline perspective. You can get around it by breaking up the operation, but then you're getting into complex instruction decode like x86.
I'm not saying ARM is bad. I'm just saying they have no magic. You're right, Intel doesn't either (though they do have manufacturing and an army of engineers to do hand-layout). Nor does MIPS or PPC. But MIPS does make energy efficient cores, roughly as good as ARM. They haven't been as popular as ARM, but they're around.
And I'm certainly not saying x86 is great -- it's certainly not. I don't think it's quite as bad as people make it out to be...
Look, I wish the architecture made a difference. For one, we'd all probably be using Alpha. That was a great, elegant, beautiful processor architecture. For another, I'd have much better job prospects. But it doesn't matter that much. Scalar architectures are scalar architectures. Instruction set makes some difference, but not very much.
Yes, ARM marketing (notoriously overoptimistic) says they will have a 2GHz A9 in 28nm, relatively high performance process.
But A9, in terms of efficiency, is not substantially better than where Atom will be. That shouldn't be surprising. They're both scalar architectures. They both have a little less than 15 useful registers. They both have similarly deep pipelines. They both rely on branch prediction for performance. Neither company has magic, it's not surprising that they're similar on the curve of performance / efficiency.
Put another way, your instruction encoding doesn't really buy you all that much.
Now ARM has some lower-end cores (ARM9, ARM11, Sparrow/CoretexA5) that are much more energy efficient than Atom. But they're also much lower performance.
But this is how ARM's marketing plays it out: we have super-efficient cores (ARM9)! We have higher-performance cores (Theoretically, A9)! You think that ARM cores are somehow both high performance and much more efficient than Atom will be in the same technology... but this will probably turn out to be false.
Put another way... are MIPS or PowerPC cores dramatically more efficient than x86 at similar performance levels? No. They have most of the same architecture benefits that ARM does... more, in many ways, because they have about double the number of useful registers. But they're on basically the same efficiency/performance curve as everyone else.
You could probably do an x86 implementation that was similar to ARM11/A5... no floating point, no SSE, just the basic 386 instruction set. Give it a short pipeline and turn down the frequency, and it will probably compete relatively well on energy efficiency with those low-end ARMs.
The thing I DON'T understand... why does ARM marketing get an article on slashdot every week or so?
Sooner than you know.
They claim that they are low power and high performance, but at the end of the day, on real benchmarks, they always disappoint.
And it's not surprising. It's a serial architecture with only 15 registers. That's the same as x86-64. x86 decode isn't trivial, but Intel has gotten good at it. And ARM isn't without its instruction set issues; the encoding isn't incredibly straightforward as they've gone back and crammed things in like Thumb2.
So the architectures are roughly a draw. Maybe ARM has a slight advantage theoretically in slightly smaller code size, and Intel likely has an advantage in practice that there is a bigger ecosystem.
So then it all comes down to implementation and process. Both of which Intel does very well. Atom is a full-custom, well floorplanned, very nice chip. It was their first try as a "low power" chip, and it performs quite well for the energy on real-world things you need to do. ARM, which traditionally has sold soft macros, hopes to compete? For those of you software folks, "full custom" == hand-optimized, "soft macro" == source code. Sometimes the compiler can do a decent job, but Intel does fully custom designs for a reason.
I think the main thing ARM has going for it is hype. TrustZone(TM) is the most highly-marketed physical address bit I've ever seen. They lucked into being the default control processor at the low end, and have made a decent business out of selling soft cores to folks needing small amounts of processing power.
But they have no special magic. They have a ho-hum architecture, certainly inferior to something like Alpha. They have a set of simple, low-performance designs that get decent energy efficiency. And they have a great marketing engine and speak loudly.
The real reason you might see netbooks with ARM cores is that the manufacturers are just reusing smartphone chips, or have some other special SOC they want to reuse. You can license an ARM and put around it all kinds of interfaces and accelerators. But now you can get an Atom core from TSMC, too, so maybe the advantage is waning....
Because they're not ubiquitous. You will end up somewhere where coverage isn't so great for your new protocol. If you can handoff to an older protocol, you will keep your connection. So this is why even a few years ago you could get Verizon phones that still supported AMPS, why every phone that supports EV-DO also supports 1X (and older standards), and why every phone with WCDMA/HSDPA/HSUPA/etc still supports plain old GSM/GPRS/EDGE.
It's also why it doesn't make a lot of sense to have a WiMAX only phone. You need at least WiMAX+GSM, or WiMAX+CDMA1X. You need to be able to hand off to the older interfaces. And probably you want to support everything... WiMAX when it's available, HSDPA or WCDMA when that's available but WiMAX isn't, or GSM/GPRS/EDGE when that's all that's available.
Or maybe you never leave downtown Atlanta. Then maybe WiMAX-only would be fine, assuming you trust the reliability of the relatively new network.
And they claim they'll double it by the end of the year (with multicarrier HSPA+?)
Can't even convert 0b1010 to the correct hex digit (A).
Linux has plenty of critics. Developers are critical of their own code. Just look through the lkml or read the code, there are plenty of places where there is constructive criticism about how something is done.
Yes, you should get more bandwidth. Yes, you should shape traffic to favor real-time traffic over bulk traffic. You should be doing both.
Like I said, we were only interested in one application: our simulator. It was developed for gcc and suncc for sparc. icc produced a slower binary. ICC may be faster over a wide variety of benchmarks, and probably especially ones where vectorization, etc can be used. However, for our simulator, gcc produced better results.
But they won't. Intel can make x86 chips that are low cost and low power consumption. And ARM is rapidly approaching implementation requirements that mean it's not as simple as you think it is. They overcrowded the opcode space, making decode hard. Thumb2 means serial decode problems, just like x86. And the whole anything-shifted-by-anything field on every instruction isn't so great for decent OoO pipelines. You end up having what amount to microcoded instructions with the move-multiples. So you end up doing basically the same things Intel would do -- breaking up instructions, speculative decode blocks, microcoded instructions, etc -- and Intel has been doing it longer and better.
Two operating modes, seven supervisor modes, various page table formats, thousands of instructions (when you consider addressing modes and condexec and ARM/THUMB and Neon and VFP and...)... do you really think that ARM is *really* all that much more simple than x86?
ARM ain't no Alpha. ARM ain't no MIPS.
So maybe ARM has a niche in ARM7 and ARM9 class tiny, licensable, synthesizeable 32-bit microcontrollers that run at speeds of up to 200Mhz, but I'm afraid ARM won't be able to compete with Intel when it comes to gigahertz-level processors.
Oh, and as for thinking like a "techy", in the end the only thing that matters is "Does it run my office suite" and "does it run my games". And the answer is likely "no" if you have an ARM. Because at the end of the day, nearly everyone runs Microsoft Office and nearly everyone ends up with some games compiled for x86.
Like I said, I hope I'm wrong. It's much, much, much better for my career and the future of computing if ARM starts doing great. But I don't think I'm wrong. Too bad, too.
The reason to go with x86 is because ARM is just as shitty of an architecture.
Seven supervisor modes now? Horrible page table format? Have you seen what they are planning for 64-bit addressing?
Even more importantly than the CPU architecture, the ARM busses are typically very low performance. And if most of the time is dealt with memory movement, having a better bus dwarfs what's going on with the CPU.
So, in the end, you have slow cores. Intel knows how to make x86 fast. And, as they are starting to show, they can make it low power also. ARM has yet to show a fast core. They don't use that much power, but if "netbooks" are low end laptops instead of high end cell phones, a few watts is fine.
Oh, and did I mention that x86 cores are x86 compatible? That makes the software barrier to entry a lot lower.
To compete with Intel, you have to be better. A lot better. For very low end, ARM is better, because all that matters is leakage power, and after that all that matters is power for very small processing. At a higher level of performance, ARM is different, but perhaps not better. Maybe the ARM architecture has some features which make it less complex to implement than x86. But at the end of the day if nobody is making ARM cores that spank x86 cores, x86 will win. Didn't you learn this from PowerPC? Don't you realize the same thing will probably happen to ARM except at the extremely low end? And even there, if Intel decides to start licensing 386 synthesizeable cores, how long do you think ARM7 and ARM9 will last?
We were not impressed.
Nobody is noticing that Google is shipping an easy-to-use, free, fast, pretty operating system?
Make sure you do your own regular backups, clearcase will eat your repository in a disastrous way, and you'll wait for IT to fix it for 2 weeks. At least, that was my experience with clearcase.
You're sharing the backhaul from the tower to whatever it talks to, though.
Put a backslash at the proper indent level and then you can put the next line at whatever indent level you wish.
If you use two bands (10Mhz) you get Multicarrier HSPA+, which peaks at 42Mbps. I'm sure you could stick more bands together and get even higher rates.
With HSPA+ getting 21+ Mbps in a single 5Mhz carrier, are folks really going to get that much improvement in areas with lots of users with WiMAX at 100Mbps in a 20Mhz carrier? There's only so much spectrum...
Well, you got me beat.
It's a huge kludge for idiotic processors (like arm9) that don't have physically-tagged caches. On all non-incredibly-sucky processors, we have physically tagged caches, and so having every app have its own address space, or having multiple apps share physical pages at different virtual addresses, all of these are fine.
Problems with SAS:
Most people... even people using ARM... are using processors with physically-tagged caches. Please, Please, Please, don't further the madness of single-address-space environments. There are still people encouraging this crime against humanity.
Maybe I'm a bit bitter, because some folks in my company have drunk the SAS kool-aid. But believe me, unless you have ARM9, it's not worth it!
Signal/noise ratio is mainly determined by things like the type and number of antennas and how you use them (to do beamforming, etc).
Bandwidth is a fixed quantity, you can only get so much from the government.
So given that with modern 3G protocols, we get pretty close to the Shannon limit for a given antenna technology, how are huge gains available by switching to WiMAX? They can get big bandwidths for a single user by eating up lots of spectrum (and they do, like 20Mhz at a time), but overall throughput for all users... is it really better than provisioning that 20Mhz into several HSUPA+ channels?
A single sided DVD can hold roughly 8G of data.
That's roughly 10 megabits average for a 120 minute movie
10 megabits Average Bit Rate looks quite good for 24-30 fps @720p. I haven't tried the same clip at 24-30fps @1080p, which is somewhere north of 2x the number of pixels. Maybe it's not so great... but given the quality at 5Mbps @720p, I would imagine I would enjoy the movie.
Heck, OTA uses not too much more bit rate, and it's MPEG2.
- Want to force customers to buy new, expensive players instead of minor DSP/Firmware upgrades to existing player designs
- Want to force customers to have a difficult time making their own HD media because Blu-Ray writable media and burners are too expensive.
- Believe that by making the size larger that pirates can't figure out how to transcode to a smaller formant before posting on the internet (and that 30G images are too big to download)
- Want to be able to ship many movies on a single disc... but that doesn't seem to be happening
The companies could have come up with a new format using better compression. Players would be marginally more expensive because of increased decode processing, but in general I think you'd see $30 DVD players become $35 DVD/HD players very fast because of the very marginal increase in capabilities needed.Oh well.
Who cares about saving money in the government any more? You can just get some more bonds issued... more free money! It's even better if you're the Federal Government, the Federal Reserve will loan you all the money you want. You can loose (literally) tons of hundred dollar bills and not care! A few computers a couple of years old is chump change. Maybe you didn't get the memo.