[dundee] Linux on the desktop

[Andrew Clayton]

On Tue, 2004-01-13 at 18:31, Jonathan Barber wrote:
> On Tue, Jan 13, 2004 at 04:09:18PM +0000, Andrew Clayton wrote:
> > On Tue, 2004-01-13 at 15:09, Jonathan Barber wrote:
> > [snip]
> > 
> > > > Bigger binaries and can have slower performance.
> > > 
> > > WRT performance, are you refering to running binaries compiled for 32bit
> > > x86 platforms on 64bit platforms, or is this something else.
> > > 
> > 
> > No. You can't easily take a 32bit ELF Linux/x86 binary and run it on a 
> > Linux/Sparc64 for example...
> 
> I thought you might be talking about running 32 bit x86 apps under
> emulation on Opteron/Itanium.
> 

heh...

Actually one of the things that Opteron has over Itanium is you don't
get a performance hit from running your current 32bit binaries on it
along side your 64bit stuff.


> > What I'm meaning is, using, Linux/Sparc64 for example. The kernel is
> > 64bit, userland is 32bit. If you compile stuff as 64bit then the
> > binaries will be bigger and will likely run slower than their 32bit
> > brothers. 
> > 
> > Basically, IMHO, if you (anyone in general) think going to 64bits is
> > suddenly going to make everything faster, then you are going to be
> > dissapointed. Generally the main reason for using 64bit's is for
> > accessing large amounts of memory (where large may be >4GB). Or when
> > doing BIG science and using 64bit values is a help.
> 
> I do big science, and the 4Gb limit is a PITA. As I understood it, the

Yeah.. On 32bit the kernel has to jump through all kinds of loops to
access lots of RAM. In fact anything above ~896MB is treated
differently. All kernel data structures must reside within the first
~896MB of RAM. 64bit Linux effectively removes this limitation.

Linux on Alpha was the first 64bit port of Linux and had good success
with the scientific community until Compaq's buyout of DEC sealed its
fate :(

Compaq selling the Alpha stuff to Intel was the final nail in the
coffin, the only thing that would have saved it, would have been if
Itanium had sunk...


> unique selling point that AMD and Intel are putting forward for home
> users is that you can have much more realistic graphics in games...
> 

Not sure that Itanium is aiming for home users? Certainly AMD X86-64
seems to be the preferred of the two by a lot of the kernel hackers.
Seeing as it is basically just the current x86 instruction set with
64bit extensions...

Although Itanium2 seems to be performing quite a bit better that the
first Itanium's (to be expected I guess)


Of course you can count on SGI to bring out some nice Linux/IA-64 based
machines!


> > For the average home user, they aren't going to see much benefit.
> >  
> > Hmm. A quick check on a Solaris 7/SPARC64 system shows that the general
> > userland is only 32bit.
> 
> I googled on this, Solaris 8 does, but the userland programs are by
> default 32bit. To get 64 bit use the -m64 flag with gcc.
> 
> jon at hornet:~$ cat test.c
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main (int argc, char **argv) {
>     printf("hello world\n");
>     return EXIT_SUCCESS;
> }
> jon at hornet:~$ gcc -m64 test.c
> jon at hornet:~$ file ~/a.out
> /homes/jon/a.out:       ELF 64-bit MSB executable SPARCV9 Version 1,
> dynamically linked, not stripped 
> 

Yeah... same with Linux on SPARC64


> > (pts/1) [andrew at rts:~]$ file /bin/ls
> > /bin/ls:        ELF 32-bit MSB executable SPARC Version 1, dynamically
> > linked, stripped
> > (pts/1) [andrew at rts:~]$
> > 
> > 
> > If you have a 64bit system and can run 32bit binaries, then your
> > probably better off doing so. If not I wouldn't loose any sleep over
> > it.. ;)
> > 
> > > Do you have any links handy?
> > > 
> > 
> > Sorry no handy links... just what I've read and learnt in posts from the
> > likes of Ben Collins (Debian SPARC maintainer) and Dave Miller (SPARC
> > and Networking maintainer, Linux Kernel).


Andrew