Very Computer

(This case assumes a 64-bit Ultra-Sparc running on a 64-bit kernel)

It seems obvious to me that 32-bits applications in general gets very
noticable decrease in performance compared to if they were 64-bits
applications.

Anyone who knows where to find any document that supports me on this?

Or am I wrong? (Any documents that can prove me wrong?)

Regards,

// WoC

Why would they?  32 bit apps use a different set of system call traps,
so there's no performance degradation.

Why do you think 32 bit apps running on a 64 bit kernel are at a big
disadvantage compared to 64 bit apps?

--
Rich Teer

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

If the 32-bit system calls are wrappers around the 64-bit calls,
it's reasonable to think the 32-bit calls could be slightly slower
than the 64-bit ones.

That's just a theory.  I don't know how the 32-bit calls are handled
in a 64-bit kernel.

  -Greg
--

I have a map of the United States that's actual size
                 -- Steven Wright

Quote:> If the 32-bit system calls are wrappers around the 64-bit calls,
> it's reasonable to think the 32-bit calls could be slightly slower
> than the 64-bit ones.

They're not.  The 64 bit syscalls use a different trap to the 32 bit
ones.

Quote:> That's just a theory.  I don't know how the 32-bit calls are handled
> in a 64-bit kernel.

It's all revealed in "Solaris Internals" by Jim Mauro & Richard McDougall.

--
Rich Teer

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

That was what I had in mind... plus the (max) number of files open per
process (default value)
// WoC

How would the maximum number of open files adversely affect performance?

--
Rich Teer

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

If it's reached, there wouldn't be much performance to measure, would it? ,)

// WoC

When you say "it seems obvious to me" do you mean you're assuming this
or do you mean you have a benchmark case of an application running
noticably slower as a 32 bit app on a 64 bit OS?

There should be no noticable performance decrease - if there is your app
may be a pathological case or there's a problem that needs to be
investigated.

--
Tony

It's not obvious to me at all. Where did you get this idea from? Intel by
any chance?

Quote:>  Anyone who knows where to find any document that supports me on this?

No.

Quote:>  Or am I wrong? (Any documents that can prove me wrong?)

You are and yes, there are documents. A long time ago, while Digital was a
Unix company and they had a usable web site, it was rather easy to find
whitepapers and other technical documentation about Alpha. I don't know
how to find them now and I only have printouts somewhere.

Anyway, some of them were describing performance measurements on Alphas
with 32-bit and 64-bit code (these two numbers applie to the pointer
size). And, predictably, the code with 64-bit pointers was slower. Why?
Because you still have the same size of CPU cache, but you can put less
data in there. Your memory usage increases as well, so there is a
potential case when your machine would start swapping with 64-bit app, but
wouldn't with 32-bit app.

Measurements done by Digital's engineers showed that performance decrease
was up to 15%. This is the number for Alpha CPU version which they had at
the time. It does not mean that it's the same for modern Alphas and it
does not mean that it has any connection with SPARCs in general and Sun's
implementation in particular. However, the reason for performance loss is
still the same: pointers take more space, so 64-bit apps on SPARCs will
usually be slower than the equivalent 32-bit apps.

The obvious exception is an application which does a lot of 64-bit integer
arithmetic (excluding pointer arithmetic). I don't know many in this camp.
Coming to think about it, I don't know any. The other reason for using a
64-bit application is the address space. If it doesn't fit in 32 bits, then
you need 64-bit pointers.

To continue on Alpha: Digital didn't have installed 32-bit base to
support, so they could choose if they'd ship only 64-bit OS or a dual
32/64-bit one. Since performance decrease wasn't large, they decided to
ship a pure 64-bit OS, in order to avoid maintenance hassle with dual
libraries and binaries. I think it was a good decision. However, if you
really want to, you can use 32-bit pointers on Alphas under Digital
Unix/Tru64 with the native compiler. You'd have to process the system
include files first and then invoke the compiler with -taso option.
There's a man page describing the process, but I forgot it's name.

--
 .-.   .-.    I will always cherish the initial misconceptions I had
(_  \ /  _)   about you.
     |

In a NDA'ed meeting with Sun a while ago an engineer explained that Sun were
perfectly aware of how to test systems and perform benchmarks as they were a
bunch of professionals with a clue.

As near as damn it, existing 32bit binaries will run as well under a 64bit
kernel as a 32bit kernel. If you want you can do your own benchmarks as the
32bit kernel is installed as well as the 64bit and you can run comparisons
by booting the one you want.

There may be some slight differences in performance in each direction but
these would be difficult to seperate out from other changes to the kernel
(for example, memory management in Sol8 is significantly improved. On our
E6500 with the same workload, going to Sol8 has released about 2G of memory
on a 9G machine.)

There is a widespread belief that bigger word lengths result in faster
programs.  This is not necessarily true, it depends on the program and the
programmer.  Program binaries and runtime sizes will be larger.

It should be noted that the size of int in a C program _remains_ 32 bits
even when compiled with Sun's compiler and 64bit options.  This will
surprise many 2nd rate programmers and break a lot of C code that
(incorrectly) assumes that a pointer will always fit into an int :-)

--
/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\

To hell with the prime directive, let's kill something.