Messages in this thread | | | Date | Tue, 9 Mar 1999 09:34:58 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: Linux/IA-64 byte order |
| |
On Tue, 9 Mar 1999, Florian Lohoff wrote: > > Also with the Emulation issue - CPU get better performance and > a little x86 performance penalty causes the application to run > at same speed as long as they are not native code.
Note that one Merced, I bet that most people will find that x86 binaries are noticeably _faster_ than native merced binaries. Just a prediction, but one that has some reasons for being true:
- icache footprint. I don't have a Merced NDA, but from all early rumors it's fairly obvious that Merced binaries will be huge. The x86 is one of the densest architectures right now in terms of I$ (yes, I know about ThumbARM etc, the point being that if you compare major architectures the x86 actually does really well), and not only are Merced instructions large, speculation tends to cause more expansion.
- binary loading time. Same issue as above.
Sure, you'll probably have tons of cache (both CPU cache and disk cache) on any reasonable Merced system, but basically having resources still doesn't mean that it's a good idea to waste them. Waste not, want not. For stuff that doesn't absolutely _need_ to be native IA-64, you probably want to use the older IA-32 binaries.
The kernel needs to be native IA-64 mainly because of 64-bit issues, and because there are probably many things that can be done only in native code. For similar reasons you'll probably want to have some important applications (databases etc) be IA-64, and probably all timing-critical FP code. But there isn't all that much of an argument for making most normal applications be native IA-64.
(For example, have people realized just how large something like KDE+StarOffice is? Imagine blowing that up by a factor of three or so..)
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |