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.
On the other hand, Intel often gives little thought to enhancing performance of old code on new processors. If memory serves me right, Intel's Pentium Pro ran 16-bit code embarrassingly slowly.
-jhp
/. -- the Free Republic of technology.
Actually, you're right. Sorta.
If you take Linux (source based, optimized for cpu) and a modern window manager like enlightenment (if you think its not modern, prove it in a reply) with a preemptive kernel and put it on a Celeron ~500mhz with 128mb of PC100 SDRAM it WILL BEAT the Windows 98 in speed, although it is different.
I just don't see how people assume KDE and Gnome are "modern" because they resemble Windows. Is that the trend?
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
Intel's Xscale architecture -should- have impressive performance. However, it seems that circumstances have conspired to keep it from showing its potential. In order to retain binary backwards compatibility, Microsoft has kept their software compiler rather basic, ensuring that it will work for multiple architectures. This lack of optimization also means that any architectural improvements Xscale has over Arm V4 or whatever it's called will not mean anything. Hopefully the history of Xscale will work like netburst architecture's history, where about 1 year after inception, software that makes use of its architecture efficiently (like SSE2 with the P4) will start to appear.
------- "From bored to fanboy in 3.8 asian girls" ----------
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.
Pocket PCs aren't as fast as people thought they would be. Is it the OS?
It could be the OS, which is the obvious answer since it's a Microsoft OS, and this is Slashdot. But I don't know. I've never tried running anything other than PocketPC OS on the iPaq, and probably never will. (It's a work thing.)
How did Microsoft become so popular? It was DOS, wasn't it? The program that ran on any x86 computer. Well, Microsoft should take a page from their previous success and allow a little more flexibility in PocketPC design. The main gripe that I and everyone else has about these gizmos is that they're locked into a 240 by 320 by 16-bit color display. That's lame, especially if one of the highlights of PocketPC is how easy it is to port your Win32 app. If you have to redesign all the screens to fit in a tiny-ass space, it's easy on the coders but hell on the systems analysts.
It looks to me like Palm have a much more open approach, they are using the same tactic that established Microsoft's dominance with DOS back in the 80s. You can get that new Sony Clie' with TWICE the screen real estate (as in pixels) of ANY PocketPC available. Kind of a no-brainer if you ask me.
Off to the solstice parade!
Q: What could possibly have gone wrong?
A: While we acknowledge that some peoples' perception is of something having gone wrong, we believe that any wrongness is unavoidable.
Q: Well, some analysts say it's intel's fault
A: We have implemented what we could implement, and don't believe there is any implementable implementation that would implement significant gains.
Q: Analysts also say it will be 2004 before the issue is fixed
A: It is too early to talk about 2004. That said, we are committed to delivering a good product.
Q: This is really bad news for the Pocket PC platform
A: Yes, it is. However, fortunately the issue is so small that this really isn't bad news for the Pocket PC platform.
Cheers
-b
They've probably used aggressive power saving on the chip to save every electron but at the expense of performance.
Thats not such a bad thing, most of these things run address books and sync to email. The battery is the real problem with them, not the fact it can't encode video streams!
Sure they'll get a few complaints, but nothing like the slating they've been getting for the battery life problem.
I can fully attest to that. I happen to have a 128 MB Celeron 500Mhz box sitting right next to me (no lie). I had Windows 98SE on it for a few days, and It was dog slow, unusably so. I put Mandrake on there (with KDE 2.something) and it flew. I was very surprised how fast it was. It's even faster now that I moved to WindowMaker.
Well, that statement clearly deserves a +5 Funny.
That may be true, but I'm just telling it like it is. KDE on BSD and Linux was sooo much slower than either Windows 98 or 2000. Trying to run Konqeror was like pulling teeth. I actually got better performance running XDM and a virtual console through Exceed than if I sat there at the actual X console and tried to startup KDE
Aw, fuck it. Let's go bowling. - The Big Lebowski
MS admits in the linked article that the OS is not "optimized". It fails to use the new ARM instruction set, and worse, does not seem to use the power-management capabilities of the XScale. Supposedly the Xscale uses half the power of the StrongARM, but battery tests on the new PPCs do not show this savings. This fix will be a while coming, as the next version of the OS does not appear to be optimized either.
Interestingly, Asus in their upcoming Xscale PPC is coming up with workarounds, such as on the fly automatic clock and voltage throttling. So while the Xscale supports capabilites that MS is not using, the vendors are not waiting for next year for MS to get their act together.
Hopefully the vendors will also figure out a way to speed up the terrible benchmarks of the Xscale PPCs.
*Actual clock speed 400 mhz
I did n't mean the 3MHz drop hurts you alot, I meant that if you compare the clock to bus speed ratio you're looking at a 50% reduction in bus speed compared to cpu clock rate.
If there is not enough cache memory increasing processor clock speed will not have a positive affect on performance because the real effective clock rate will be bound by how fast the processor can fetch data from main memory.
MS : "Moving to ARM V5 would break upgrade compatibility."
Translation : "We can't or won't write portable code."
There's absolutely no technical reason they can't take advantage of the V5 enhancements while still retaining support for ARM V4 and a common code base. This must have been a business decision, but I can't fathom the thought processes which led to it.
You've not noticed that yet? GNOME and KDE are not supposed to be "modern," they're supposed to be like Windows, so people used to Windows can switch. They're being largely designed and coded by ex-Windows users. And that's fine, if you like the Windows works, but want a free version of it, more power to you.
:)
It's hard to build a modern computing environment on top of a non-modern operating system (Unix, Linux). Again, GNU/Linux *not* being modern isn't a dis, it's just the way things are. It works. I use it on my machine, largely as a host for a more modern OS (but far more spartan at this point). And no, I'm not talking about Mac OS X being some epitome of "modern," it's based on all the same things. Unix is so.... 50s in it's ideology.
And before a bunch of escaped slashtards flame me, i repeat, THIS IS NOT A BAD THING. If you like Linux, GNOME or KDE, use it. Some of us, however, are not satisfied with the limits they impose on the way we work and are trying to forge something new.
Enlightenment isn't any more modern than GNOME or KDE. But it may be a little more fun.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
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
This fits perfectly in Intel's "Megahertz sells" paradigm.
Just push clockspeed up at any cost - who cares about performance? It's already running windows - so what can you expect?!
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
next
Comment removed based on user account deletion
Comment removed based on user account deletion
*sigh* No, pocketpc 2002 is NOT the new name for WinCE, pocketpc 2002 and 2000 are an implementation of windowsCE 3.0. Windows CE is an embedded realtime OS that can be used for all sorts of things, PDAs being one of them. Think of pocketpc 2002 as a "distro" of CE3.0 with a special pocketpc gui installed.
Jeremy
Comment removed based on user account deletion
Without a compiler that has optimizations for the XScale, you will still get poor performance. So all the tweaks in the world to your existing code base will be for nought without a corresponding change in the compiler which is targeted for ARM7/9 cores and has only basic support for XScale.
When shopping for a PDA I don't remember speed meaning anything but "cost to much"
People buy PDAs for cheap lap tops or simple organisers. Nither needs speed.
Pocket PCs can get faster and faster while Palm Os PDAs outsell them.
The Palm Os devices are cheaper and use less power.
This is becouse they are slower.
It's not speed... it's memory....
Handspring Visors have memory cartrages and the Palm m500 use media cards so while Power PC devices play with added speed and don't get it Palm os devices get added memory.
Thies things are just portable databanks they aren't for processing information just storing it.
Want to play MP3s? Slap on an MP3 player... a sound chip that has an mp3 incoder built in and some added ram.
Want to do presentations? Slap on a presentaion device.
Go on the Internet? Snap on a wireless... (Unless it's built in)
Play Quake? compile data?
Hotsync with desktop...
I'm looking for a keyboard and a wireless for my Visor (the i705 can't handle telnet) so I can use a shell account from my PDA...
I'm not going to have any real computting power on a PDA. Thats not what a PDA is for.
I don't actually exist.
Linux with KDE is slower than Windows 98 basically for two reasons. The first is that Linux does more stuff. For instance, it runs various daemons in the background to allow for remote access, it journals filesystem logs, it implements proper crash protection, it has a usable command line with virtual terminals etc. Windows 98 doesn't have these things, so it can be faster.
The second reason is that KDE is written largely in C++, and the Linux C++ linker is inefficient (it is much faster at C). The programs run fine, but they take longer to start up, which is what makes it "feel" slow. Gnome should in theory be faster, but they kill any speed increase they'd otherwise get by having a slower (well, in v1.4) graphics library and by using incredibly heavy things such as CORBA for ipc, and a daemon for configuration etc.
The reason other window managers (not just ancient ones, others such as WindowMaker or E) are faster is because a) they are simpler and b) tend to be written in C
The speed of GTK is improving, though CORBA/ORBit will always be slow on the gnome side imho. The Linux Linker issues with C++ are known about and are being resolved, which will lead to much better performance.
Another problem is that some modern distros are quite bloated. My SuSE 7.3 box loads all sorts of stuff at startup that I don't actually need, but I never got around to switching it off. Combined with the slow start of KDE and the fact it loads after login (which windows does before login), and it begins to feel slow.
Performance is improving, however it's still largely in the hands of the GNU folks and the distro companies.
thanks -mike
The Intel PXA250 has only 32K/32K of cache, which means that any real application will experience an extremely high cache miss rate. The memory bus is 16 or 32 bits, and has a maximum clock rate of 100 MHz. So, if you're running the maximum width bus at its maximum speed, you're likely to see an instruction dispatch rate of about 50~100 million ops/second. That's slow, and there's really nothing to be done short of adding much more cache.
If you are doing anything that requires performance, you shouldn't rely on the compiler. Intel has their "Integrated Performance Primitives" which give you a nice abstraction layer so you can wring the most power out of each processor without having to hand code asm for each one.
Uhm, it was first invented in 69 and improved to what we would recognize as Unix in the early 70's.
*sigh*
But most of the core ideas were developed in the 50s. Just because Win98 came out in 1998 (or was it 99?) it doesn't mean that it's technology is of the 90s. That's pretty much from the 50s too.
I should've known that comment would confuse many.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
the next version of Pocket PC - that will surely have a .NET runtime in it. That will make all the problems go away, won't it? Just compile the apps to IL, target, and distribute.
Let's hope your skepticism is justified. Because if it isn't, Linux as a platform will be in very serious trouble.
Linux has no answer to cross-platform code, the one exception being Gnome with Mono. If that remains the only effort, and continues to attract hype and developer support, one day soon we'll wake up and find that the single viable open source platform to write to is under the technical direction of Microsoft.
However did this happen?
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.
Marvin wrote:
> 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.
This is not correct.
All ARMV4 instructions are implemented natively in the XSCALE core.
The XSCALE core, just as the SA1110, executes almost all ARMV4 instructions in one clock, and, as far as I remember, uses more clocks only for very few instructions:
- shift register by register (2 instead of 1)
- mul / mul-acc (extra latency cycle in some cases)
- branch miss in the added BPU
- maybe some coprocessor accesses
Except for an assembly rewrite of some inner loops in the kernel, there is not much MS can do about the Memory interface that hasn't scaled with the CPU clock.
I do not think that compiler tweaking will gain much more than 10% in performance.
but I haven't any points. I'll just throw out the Compaq Aero series as another MIPS arch that was very quickly made useless. Not to say it was ever very useful. We bought five but the sync process was so shitty that we never used them.
"I assumed blithely that there were no elves out there in the darkness"
It's important to differentiate between architecture optimizations
and CPU specific optimizations. The ARMv5 instruction set is a
relatively minor architectural tweak to the ARMv4 instruction set.
The names give you the impression that it's some grand change between
v4 and v5, if a technical guy did the naming it would be ARMv4 and
ARMv4.01. ARM is playing some games with architecture naming
to protect their business position with patents in a silly way.
ARMv5 adds a couple of new instructions over v4, an instruction to count
leading zeros in a register (which a compiler would likely never
use), and a better method of switching between the ARM instruction
set and the 16-bit Thumb instruction set. The later isn't
relevant for PocketPC since Thumb mode isn't supported. I think
v5 might having a new debugging hook as well.
The new XScale parts are ARMv5te, the T is for the 16-bit Thumb
instruction set, which no one seems to care about. The "E" adds
some DSP oriented instructions that are pretty interesting for
media codecs and such. They are the MMX equivalent for the ARM
world. They likely won't improve performance of the general
purpose aspects of the platform.
I think it's a red herring to chase Microsoft for not optimizing for
the ARMv5, the changes are really small and I don't see any
performance impact, certainly not if you have to maintain another
version for all of the strongARM based products.
Now, as far as CPU specific optimizations for the PXA250 (XScale)
implementation of the ARM architecture. IMHO Intel chased
MHz and left behind a lot of good sense about system performance.
The high order bit is bus performance as others have already
pointed out.
In addition to the bus performance, Intel made many tradeoffs
to optimize for clock speed: The 7-stage pipe has a 4-clock penalty
for a mis-predicted branch. This is compared to the circuit
design heroics in the strongARM that implements "all branches
are 2-cycles". The Xscale approach is much more complicated, it
probably doesn't perform any better, but you get a high clock speed.
Intel adds clock cycles to all load/store-multiple instructions
in Xscale. This is a pretty big deal in ARM since they are
used in the entry and exit of most C functions, in memcpy(),
and any time you are moving chunks bigger than a register.
The load-use penalty is bigger in Xscale. This is a pretty big
deal in ARM. The ARM instruction set is pretty compact. It is a
RISC processor, but the combination of shifting operations
combined with ALU operations makes it possible for a good compiler
to generate reasonably compact code. As a result, it's harder
for a compiler to put instructions between a load and instructions
that use the destination of the load. This is another trade-off
in Xscale that allows a higher clock speed but hurts performance
otherwise.
I go on too long, but the DEC designed strongARM used in the SA1100
is a tour-de-force of clean implementation and balanced system
performance. It's amazing that core was designed in 1993 (I think,
someone please correct me) and is still the leader for handheld
apps. The Intel guys went after clock speed at the expense of
everything else in Xscale and it will probably never optimize well
for a platform like PocketPC.
jeff
Simple arithmetic: if it was CPU-bound, halving the clockspeed should roughly halve the FPS. Suspect the graphics chip. BTW, having it beaten by an iPaq in a graphics benchmark sucks rocks. A friend of mine got a 50-fold speed improvement in iPaq graphics by rewriting the GDI driver. Either the gfx driver is broken or there's something badly wrong with the gfx hardware.
Got time? Spend some of it coding or testing
We can use MIPS portables here.
Got time? Spend some of it coding or testing
Most of the core ideas in Unix were developed in the 60's, actually.
Computing in the 50's was a very different thing, so limited that the idea of wasting cycles on things like memory management or protected memory would have been considered insane. It wasn't until hardware developed to the point where there were cycles and memory to spare that anything like Unix (or MULTICS, which is where most of Unix's ideas were developed) became possible.
himi
My very own DeCSS mirror.
Gnome should in theory be faster, but they kill any speed increase they'd otherwise get by having a slower (well, in v1.4) graphics library and by using incredibly heavy things such as CORBA for ipc, and a daemon for configuration etc.
I don't know about the graphics library thing, but the GNOME ORB is somewhat stripped down to make it faster. Unless you actually serve objects remotely over the net, the GNOME CORBA ORB basically just adds a little bit of function call overhead. I'm willing to accept that tiny bit of overhead for a tested, industrial-strength object model like CORBA. KDE, as I understand it, is inventing their own somewhat lightweight object model, and I'm worried they will later find some situation where they wish they had left in a feature they stripped out to make it lightweight.
As for Win98, don't forget that it is a candy coating around Win95, and Win95 was aggressively optimized for size and speed. The target machine for Win95 was a 486 with 4MB of RAM. There is a bunch of assembly language in there, in critical places; and some of it is even 16-bit code. (16-bit code is much harder to write, since you have to cram things into smaller spaces and you have to explicitly handle near/far pointers, but it's tiny! Even with the thunking overhead, it won't slow you down too much if you just use it rarely.) Also don't forget that the MS C compiler actually does produce very good code, better than GCC is able to now. (Although I hear good things about the latest version of GCC, I don't think they have caught up with MS C yet.)
The tiny size of the Win95 core means that it caches well, too, and a high cache hit rate makes for speedy performance.
I'd be interested to see benchmarks of Win98 vs. a really stripped-down Linux system (no daemons running, etc.) that was compiled with aggressive optimizations and is running a really lightweight window manager (IceWM or ROX or something). And defintely no Nautilus; try your system with ROX Filer instead. I saw a huge speed jump when I did that. (Debian makes it so easy to try such experiments!)
There is still room left in Linux-based systems for size and speed improvements. Every time GCC gets better, every part of the system gets a little better. And I don't believe that much work has been done on either GNOME or KDE to make it stripped-down lean-and-mean... the first law is "make it work before you make it faster", and folks are still busy making it work right. (But Nautilus has had a lot of speed work done on it lately, and I've heard it is much improved compared to its 1.0 release.)
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
We are aware that PXA250 (XScale)-based devices are not demonstrating the huge performance gains that were anticipated. That said, Pocket PCs continue to offer the best performance and the richest functionality vs. other handhelds on the market today.
Translation: We know your new car only goes 40mph instead of the 65mph you old car did, but it beats a bicycle, doesn't it? (credits to Jim S for that one).
Even better:
I think the market expectation of what performance on a 400 MHz processor vs. 206 MHz processor has been unreasonable.
Not at all. The process is almost twice as fast, I don't think it is utterly unreasonable to expect the product to be at least one and a half times faster.
But my question is, how is the battery life on one of these things? If it really is the 12-16 hours instead of the 8 currently then the XScale is still a worthwhile bet.
Avantslash - View Slashdot cleanly on your mobile phone.
It's usually pretty hard to thrash a code cache to the point of it being the bottleneck. You pretty much have to deliberately write code to do that. For reference, an Athlon has a 64KB code cache, and that's running at a far higher speed than both of these ARM processors. Your figure of 50-100 million ops/second assumes an unreasonable 100% instruction cache miss rate. You'd have to have a program totally devoid of loops to achieve that. At a still unreasonable hit rate of 95% you'd still get 96% ((95*400+5*100)/40000) of full performance.
My guess why the real world performance is so bad is probably Microsoft's lack of optimization specific to the processor. There's a few trade-offs Intel have made to get the clock higher, including:
I certainly wouldn't expect to be able to take code targetted for StrongARM and see all of the performance increase that 200->400 would indicate. I can imagine hand coding assembler to work around the latencies and getting near to 100% performance. It's not that hard for a modern compiler to work this out either - a current day x86 is far more difficult to target than an X-Scale.