Slashdot Mirror
Explaining Disappointing XScale Performance In Pocket PCs
JYD writes: "I found this new article on a Pocket PC web site where Microsoft talks about why XScale Pocket PCs aren't as fast as people thought they would be. Is it the OS? The CPU not supporting ARM4 properly? I wonder if the Linux port would run faster on 400 Mhz ... or did Intel screw up the CPU?"
My group has been working on a syhthesizable secure G3 card CPU and it will probably be the slowest ARM ever made.
The CPU will be fully delay insensitive and asynchronous to stop power and clock glitch attacks.
We are currently looking at 4 Mhz on 0.18 process.
Mouse powered Chips, Open source Processors and Lego
a review I read showed a 400Mhz XScale performing at 50%-75% the speed of a 206MHz Strongarm chip. I would be really interested in some none OS specific tests that showed whether or not the XScale offers any performance benifit whatsoever - I know that it is supposed to scale to 1Ghz and has better battery life than the 206Mhz Arms but if it NEEDS to run at 800MHz just to perform at the same level as its older sibling then it is a waste of space.
The Amulet group has been working for year to make a low power yet high speed asynchronous ARM processors.
The Amulet 3 runs at 120 MHz and consumes very little power. Most of all its asynchronous so when you dont have mych processing to do it just sits there consuming "no" power.
They take a hell of a beating and still run. I connected one to a hamster wheel and you can see it here running despite the power fluctuating madly.
The only reason it only goes at 120MHz is because the memory isnt fast enough.
Its a little strange that only three ARM production lisences were given out. One to intel one to motorola and one to Amulet group.
Mouse powered Chips, Open source Processors and Lego
Umm... right, that's why my PocketPC 2000 Cassiopiea E115 is now as useful as a doorstop as it has a MIPS chip in it.
When I got my PocketPC, MS touted that 'software matters' - even in their publicity. Suddenly, they ditch all the SH3 and MIPS users and just support ARM in PocketPC 2002. Not only that, but applications like Terminal Services and Messenger they won't release for the older machines. I see a lot of people saying that this is becasue PocketPC 2002 is based on CE.NET - that's not correct. PocketPC 2002 is just another revamp of PocketPC 2000, which are both based on CE 3.0. So when it all boils down, it's just Microsoft playing marketing tricks. Net result of their decision - my £450 PDA became obsolete in 18 months.
I now own a Palm.
This complaint was also based on the FIRST Xscale pda to EVER be released. Sure there's GOING to be problems. The iPaq started off with similar issues, but you don't hear anyone talking about it now do ya? There's alot of reasons that add up to create the total performance picture. Maybe Toshiba used cheaper internal ram? Maybe they need more memory for video (I think it has like 256 K maybe?? I don't know but I know it has dedicated video ram). The point is the performance on ONE Xscale based PocketPC does not make a prediction on how the others will perform. Also as these are flashable, we can expect even the Toshiba to get better performance as flash updates are made available.
Gorkman
OK, so I whould have read the story before posting...
It's simply Intel moving to a new instruction set (ARM V5) and building a (slow) emulation of the old one (ARM V4), and Microsoft says it would be horribly difficult to support two different instruction sets, so the choice was to either live with the new CPU performing slower than the old one or cut off support for the old hardware.
Hmmmmm, yet another thing (like the OS modularity) that MS seems to be unable to do, while my Gentoo Linux is doing it by default. The sourcecode to their products has to be a complete and utter mess if they can't even get it to take advantage of new instruction sets without dropping compatibility.
"We won't use guns, we won't use bombs, we'll use the one thing we've got more of and that's our minds" - Pulp
No onslaught here.
:(
The Newton 2100 kicks ass. I used Palm and Windows CE before finally trying out a Newton 2x00 series. The Newton made me swoon.
It's the best damn computing device out there, PC, PDA, or otherwise. I used to do my e-mail, my diary-keeping, my word processing, etc. on my PC in Linux, but now I even write my books and do 90% of my e-mailing on my Newton 2100 directly over ethernet. I read news on it, make travel plans on it, I have my household inventory on it (in Notion)... and I read BBC World News and Slashdot on it in Newt's Cape.
The PC only gets touched every few days. The Palm and CE devices are long gone. I only regret that Apple killed the Newton, so there won't be a color version.
STOP . AMERICA . NOW
I believe the point is that the benchmarks were not *terrible*. Terrible implies that the new processor is = the old 206 Mhz one, which certainly isn't the case. The problem is that people expect a 400Mhz processor to give about a 2x performance increase over the old 206Mhz one, but for a bunch of geeks, it's amazing how easily you people forget that 1Mhz != 1Mhz when you're comparing different processors (even if they both use the same instruction set), such as AMD vs. Intel. Speaking of Intel, remember that Intel realized that common folk are easily sold on a high Mhz number rather than instructions processed per clock cycle, so Intel obviously designed their processors (Pentium family and StrongArm family) to scale up to high Mhz.
There are no new ARMv5 instructions that affect performance in any noticable way for general purpose computing (i.e using an optimized C-Compiler with your old code).
.clompletely filled before execution, etc)
The main new instructions are:
- a "find first one bit in word" instruction, which helps software division and huffman encoding
- some DSP-instructions like 16x16 bit multiplication/40Bit add for filters (audio-encoding, etc)
Both these enhancencents more or less require assembly coding
The other major architectural enhancements are branch-prediction (offset by higher penalties on branch misses) and larger caches (32K dcache versus 8K and 32K icache vs 16K, if i remember correctly)
However, the cache latency has increased from 1 to 3 cycles.
It means that when you load a value from memory and hit the cache, the compiler needs to find 3 unrelated instructions you can execute before you can use the result in the fourth instruction after the load.
This is a severe blow if your compiler does not figure it in, and even if it tries, or if you use assembly, you often cannot find three such instructions (table walks, or under register pressure)
In the worst case (table-walk, LUT's), this effectively halves your processor speed.
As far as i know, the bus interface has not improved from the SA1110, and this was not too efficient to start with (does not exploit accessing preloaded bank, cache-line has to be
Apart from that, there are some issues in the PXA silicon, which I think force some timeconsuming workarounds (extra cache flushes, Writeback-cache does not work, slow bus cycles). I would guess that these affect performance even more than the 100MHz SDRAM clock - after all that's about what you find in your 1GHz+ P-III-design.
However, this is only what i gathered from the datasheets, I have not yet used a PXA system as it does not yet seem to be an improvement over the SA1110 that justifies a new design.
Before blaming Intel for going with an Arm 5 core with "slow" (slow being relative, as the benchmarks vary) Arm 4 emulation, remember that all they did was produce a CPU for the embedded market that can run on batteries. The MS Pocket PC market is just one market for these processors. They want them used in cell phones and powering all kinds of devices, just like the StrongArm did.
Obviously, they felt that the majority of their customers would want an Arm5 based device. Wait a few months, and you might see some pretty impressive cell phones or linux based devices that use Arm5.
The complaint against Intel is only legitimate if their Arm5 scores are terrible. Otherwise it is the fault of the device maker for using a chip that doesn't perform well for the task at hand, or MS for not optimising.
He said, "You'll be able to tell your grandchildren that you helped assemble the first NT supercomputer," and I cringed.