> From: Tobias_Ernst@bland.fido.de (Tobias Ernst)
>
> Hallo!
>
>  l> OK, so what OS should I run on this thing and where can I 
>  l> get it so that I can get some more performance out of this box?
>
> To get good performance you'd best use the Compaq/DEC cc/cxx compiler
> suite. This one is available for Tru64 Unix and Linux, both of which
> should run on your machine. An interesting question would be if running
> Tru64 or Linux binaries compiled with cxx under NetBSD in the emulation
> would still be faster than running them natively with gcc as compiler.

The "emulation" just means that system calls go through kernel modules
that understand the linux or osf1 syscalls and do file opens twice .. once
in the emulation tree and once in the real tree. We run the foreign loader
and the foreign libraries, so everything else is the same speed.

Anything compute-bound or even read/write- or mmap- i/o bound should go
exactly the same speed.

The only places you could notice a difference are the rare program that
open(2)'s or stat(2)'s lots of files and then doesn't do anything with
them. Mainly, that would be ls(1) and du(1); other than those, you should
get exactly the same speed on NetBSD as you do running the "emulated" binary
natively on the same hardware with the foreign OS, and even ls(1) and du(1)
should be close. If the other file system was faster, you might notice that
too. (But the faster ones are often less reliable, and you always notice
that. :-)

Actually, in -current, we have page coloring now, so depending on how well
(if at all) the other kernel did that, and on a random factor depending on
the program's access pattern, NetBSD could conceivably run it _faster_.

> The difference gets especially obviously when you have floating point
> code and the code is arranged in a way so that the compiler can make
> use of the Alpha's vectorizing floating point unit. In this scenario
> using Compaq C can give up to a factor of 5 if not 10 as compared to
> gcc. For average floating point code the factor is about 2, whereas for
> integer arithmetic (the kind of work most users do most of the time) it
> is less obvious.

We are working on getting that compiler to run. More volunteers are always
(well, almost always :-) appreciated...send me email...

//