Date:	Tue, 9 Mar 1999 09:34:58 -0800 (PST)
From:	Linus Torvalds <torvalds@transmeta.com>
To:	Florian Lohoff <flo@rfc822.org>
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/