«

Since the size of integer is fixed (32 bits) on any platform, does java
program run on 64-bit platform as fast as on 32-bit platform?

On 10 May 2006 03:44:55 -0700, "jcc" <> wrote, quoted
or indirectly quoted someone who said :

>Since the size of integer is fixed (32 bits) on any platform, does java
>program run on 64-bit platform as fast as on 32-bit platform?

Java runs on a wide range of 32 and 64 bit platforms. If you have
enough money you can get yourself a mainframe or a CPU with 256
processors.

But I think what you are getting at is the observation that given the
same amount of silicon, a 64 bit CPU will typically be slower since
more RAM and bandwidth are used to get the same job done. The reason
for 64 bits is to address huge virtual memories. You can plausibly do
all your IO with memory mapping or virtual RAM allowing you to boost
performance simply by buying more real RAM without redesigning your
software.





--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

jcc wrote:

> Since the size of integer is fixed (32 bits) on any platform, does java
> program run on 64-bit platform as fast as on 32-bit platform?
>

The java program is the same, so the question really addresses the
implementation of the JVM that runs it. And the question of which is
'faster' depends on a great many things.

Between a given 64-bit datapath and a given 32-bit datapath, each may
have pros and cons versus the other.

A 64-bit control might be able provide some very efficient instructions,
and a program (a JVM in this case) might be coded to take advantage of
that. Or, a 64-bit control might be implementing the same instructions
as the 32-bit processor.

A 64-bit processor should have an order of magnitude more registers
compared to a 32-bit processor. If the program can exploit this, then
some operations that would require loading from memory (typically the
slowest instruction) can work in register space instead.

A 64-bit processor is likely to have been designed from scratch
relatively recently, and thus, may have a very sophisticated
forwarding/pipelining architecture which could make it more efficient
than another chip executing the same series of instructions.

A 64-bit processor has a much larger addressing space, and much wider
buses. This means that things like sequential reads from memory can be
optimized by grabbing big chunks of RAM per load instruction, in
anticipation of spatial locality. It also means that cache associations
can be made much wider, and caches can be much taller than the
equivalent 32-bit variety, and this should also result in a more
efficient datapath.

There are some diminishing returns, even some liabilities, when so many
transistors are put on a chip, as is implied by the requirement of a
64-bit datapath. So we are likely looking at a multicore processor
instead of a one giant single path. Then it's a significant factor
whether the program (the JVM and the OS) can exploit the performance
benefits implied by the processor architecture.

Now your question was only about integers. That's a tough one. Many of
the considerations around the datapath also apply in various ways to the
ALU (arithmetic logic unit(s)). On the other hand, a 64-bit ALU might
not necessarily outperform a 32-bit one with the same operations on
32-bit register data.

Overall, I would certainly expect a 64-bit processor to do no worse than
a 32-bit processor running the same program, but I would also expect
certain benefits of the 64-bit datapath to give increased performance as
a side effect of the wider paths, more registers, cache design, etc.
Further, if the program was designed for the 64-bit architecture, then
it should be expected to take advantage of any performance benefits that
are offered by that architecture.

Regardless, the *program* isn't the java program, it's the JVM.

jmcgill wrote:
> jcc wrote:
>
> > Since the size of integer is fixed (32 bits) on any platform, does java
> > program run on 64-bit platform as fast as on 32-bit platform?
....
> A 64-bit processor should have an order of magnitude more registers
> compared to a 32-bit processor.

"an order of magnitude"
^^^^^^^^^^^^^^^^^^^^^^

I guess you're counting, like the processors, in base 2

Seriously though, a 32 bit x86 can be considered to have
8 GPR (general purpose register) and 8 FPR (floating-point
register)... You won't find many 64 bit CPUs having
80 GPR and 80 FPR these days (though there have been
some having as much as 64 GPR IIRC, but this isn't very
common on the most successfull 64 bit platforms Java
runs on today if I'm not mistaken).

Just nitpicking that said, I agree with everything you said!

wrote:
> jmcgill wrote:
>> jcc wrote:
>>
>>> Since the size of integer is fixed (32 bits) on any platform, does java
>>> program run on 64-bit platform as fast as on 32-bit platform?
> ...
>> A 64-bit processor should have an order of magnitude more registers
>> compared to a 32-bit processor.
>
> "an order of magnitude"
> ^^^^^^^^^^^^^^^^^^^^^^
>
> I guess you're counting, like the processors, in base 2


I should have said "it *could* have"


I'm thinking a 64-bit MIPS instruction could simply double the register
index from 5 bits to 10. Instead of 32 registers you could have 1024
without really changing the basic architecture. Obviously with the wide
instruction we could be a lot smarter than that.

I admit I'm only guessing, and my only experience with any real 64-bit
processors has been running in 32-bit mode on 64-bit sun hardware.

I would actually like to see benchmarks based on whatever the currently
popular 64-bit machines happen to be, and I would be very interested in
reading opinions from people who have implemented JRE (and OS) for 64 bit.

<> wrote in message
news: oups.com...
> jmcgill wrote:
>> jcc wrote:
>>
>> > Since the size of integer is fixed (32 bits) on any platform, does java
>> > program run on 64-bit platform as fast as on 32-bit platform?
> ...
>> A 64-bit processor should have an order of magnitude more registers
>> compared to a 32-bit processor.
>
> "an order of magnitude"
> ^^^^^^^^^^^^^^^^^^^^^^
>
> I guess you're counting, like the processors, in base 2
>
> Seriously though, a 32 bit x86 can be considered to have
> 8 GPR (general purpose register) and 8 FPR (floating-point
> register)... You won't find many 64 bit CPUs having
> 80 GPR and 80 FPR these days (though there have been
> some having as much as 64 GPR IIRC, but this isn't very
> common on the most successfull 64 bit platforms Java
> runs on today if I'm not mistaken).
>
> Just nitpicking that said, I agree with everything you said!

It's been a long time since I've done development in assembly, but I
thought it was only Intel's x86 design which was register-starved, and most
other architectures had a lot more. I vaguely remember one processor I
worked with (Motorola PowerPC?) which had something like 120 physical
registers and a rotating window circular-buffer thing to emulate an infinite
number of registers, given sufficient amount of RAM.

- Oliver

Oliver Wong wrote:

> It's been a long time since I've done development in assembly,

It's been less than a week for me

> rotating window circular-buffer thing to
> emulate an infinite number of registers, given sufficient amount of RAM.

If you have to load a value from RAM, you not only are defeating the
purpose of a register access, but you are also replacing register
access, the fastest operation in the datapath, with memory access, the
slowest.

"jmcgill" <> wrote in message
news:7ws8g.4754$_c1.224@fed1read05...
> Oliver Wong wrote:
>
> > It's been a long time since I've done development in assembly,
>
> It's been less than a week for me
>
> > rotating window circular-buffer thing to
>> emulate an infinite number of registers, given sufficient amount of RAM.
>
> If you have to load a value from RAM, you not only are defeating the
> purpose of a register access, but you are also replacing register access,
> the fastest operation in the datapath, with memory access, the slowest.

Let's say the registers are numbered 0 to 119. You start up with the
window pointing at registers 0 to 19. You do some fiddling there, and decide
you want more a new set of registers (e.g. because you're about to jump to a
sub procedure), so the window rolls over to point to 20 to 39. When you
start getting dangerously near to 119, a background process kicks in and
saves the values from 0 to 19 to RAM, so by the time you tell the CPU you
want the window to roll over and give you the logical registers 120 to 139,
you'll actually be using the physical registers 0 to 19, and no data lost
will occur. Also, since the background process intelligently waits until the
memory channels are idle before doing its background save, no delay is
noticed.

Something like that, anyway. It's been a couple of years since I've
worked on this architecture.

- Oliver

Oliver Wong wrote:

> Something like that, anyway. It's been a couple of years since I've
> worked on this architecture.

I try to avoid any routine that needs more than 2 or 4 concurrent
registers anyway. My sanity depends on that

Oliver Wong wrote:
> <> wrote in message
> news: oups.com...
> > jmcgill wrote:
> >> jcc wrote:
> >>
> >> > Since the size of integer is fixed (32 bits) on any platform, does java
> >> > program run on 64-bit platform as fast as on 32-bit platform?
> > ...
> >> A 64-bit processor should have an order of magnitude more registers
> >> compared to a 32-bit processor.
> >
> > "an order of magnitude"
> > ^^^^^^^^^^^^^^^^^^^^^^
> >
> > I guess you're counting, like the processors, in base 2
> >
> > Seriously though, a 32 bit x86 can be considered to have
> > 8 GPR (general purpose register) and 8 FPR (floating-point
> > register)... You won't find many 64 bit CPUs having
> > 80 GPR and 80 FPR these days (though there have been
> > some having as much as 64 GPR IIRC, but this isn't very
> > common on the most successfull 64 bit platforms Java
> > runs on today if I'm not mistaken).
> >
> > Just nitpicking that said, I agree with everything you said!
>
> It's been a long time since I've done development in assembly, but I
> thought it was only Intel's x86 design which was register-starved, and most
> other architectures had a lot more.

Hi Oliver,

yup, which was exactly my (funny) point: even going from x86
32-bit to today's 64 bit CPU that run 64 bit JVM (ie not all 64 bit
CPU), the topic of the thread), you'd be unlikely to find 10x as
more "real" GPR (general purpose register).

Which is why I specified "on x86 32 bit" btw


> I vaguely remember one processor I worked with (Motorola
> PowerPC?) which had something like 120 physical registers

I'd have said 32 real registers on some PPC at least for sure and
it could indeed have been much much more.