64 bit linux on VM to run Java app

On Mon, 23 Jun 2008 20:19:12 -0400, Lew <lew@lewscanon.com> wrote,
quoted or indirectly quoted someone who said :

>>
>> The Atari Jaguar. 64-bit registers, 24-bit addresses and 32-bit operands!
>
>I think Roedy was asking for extant, relevant examples.

That's fair. We were discussing the definition of "64-bit". You need
the exceptions to hammer out an air-tight definition.

One that might boggle the mind is my old LGP-30 computer that had 0
RAM, but a rotating magnetic drum.

It had one 32-bit register. The store was 32 bits, but the low order
bit had to be 0, and in practice the low order 2 bits were not used.
Addresses were 16 bits wide, with word addressibility. I have
referred to it as a 31.5 bit computer.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Mon, 23 Jun 2008 21:25:32 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>18,446,744,073,709,551,616 / 10^9 is *not* 18,446,744 !
>
>It *is* billion not million !!

I chopped off 9 digits on two different occasions and rechecked. Oh
dear. Wetware is failing badly.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Mon, 23 Jun 2008 20:01:57 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>#[I am ignoring the 1024 versus 1000 issue]
>
>Is that statement unclear ????

I felt the discrepancy needed clarification.

I run into this all the time. Whenever A says something that agrees
with what B says, restates what B says, or elaborates what B says, or
asks for confirmation of an interpretation of what B said, then B
complains, as if the general assumption is that every statement in a
newsgroup must necessarily be a refutation of some previous poster.

I find this amusing given the ostensible purpose of debate is to
persuade others to agree with you.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :



>> see http://mindprod.com/bgloss/sixtyfourbit.html

Please have a second look at the entry. I have updated it based on
your feedback.

>
>#Thus they can handle numbers up to 9,223,372,036,854,775,807 as a
>#single chunk.
>
>64 bit means 64 bit virtual addresses not 64 bit integers.
>
>#Computer programs can be up to 9 million gigabytes long
>
>I assume you are trying to tell that the virtual address space
>is 9 million GB. Which is wrong. The potential max of virtual
>address space is 16 EB (16 billion GB). Current implementations
>are limited to 256 TB (256000 GB).
>
>[I assume x86-64]
>
>[I am ignoring the 1024 versus 1000 issue]
>
>#Low-end CPUs may not be particularly fast in 64-bit mode.
>
>Unless slowed down by lack of memory because 64 bit requires more
>memory, then 64 bit apps will always be faster due to more registers
>and new FP instructions. Low end or not low end.
>
>#Many dual Xeon boards are limited to 8 gigabytes total
>
>I doubt that is still the case today.
>
>#The architecture features 64 general purpose registers (vs only 8 in 32
>#bit mode)
>
>No - only 16 GP registers in x86-64.
>
>#Because of AMD’s success with this instruction set, and the slow
>#Itanium sales, Intel implemented AMD64 too, renaming it Intel-64
>
>Intel has used multiple names for its 64 bit: IA-32e, EMT64T and
>Intel64. I think the last one is confusing because Itanium is
>called IA-64.
>
>Arne
>
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On 06/23/2008 03:41 PM, Roedy Green wrote:
> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> 64 bit means 64 bit virtual addresses not 64 bit integers.
>
> 64-bit registers, 64-bit addresses and 64-bit operands usually all go
> together. Can you think of any exceptions?

Intel i860? 32-bit ALU, 64-bit FPU

PS2 Emotion engine is another possibility. It has mixed 64-bit and
32-bit engines, 128-bit registers, and operates on 32-bit values.

Roedy Green <see_website@mindprod.com.invalid> wrote:

>One that might boggle the mind is my old LGP-30 computer that had 0
>RAM, but a rotating magnetic drum.
>
>It had one 32-bit register.
Please, let's not do the computer equivalent of "The Four Yorkshire
Men" <http://www.youtube.com/watch?v=GqNGhcdtMbc> again.

Since I have recently complained about irrelevant YouTube links I
should add that the link is to a Monty Python skit about how happy but
poor the men were in the good old days.

On Tue, 24 Jun 2008, Roedy Green wrote:

> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>>> see http://mindprod.com/bgloss/sixtyfourbit.html
>
> Please have a second look at the entry. I have updated it based on
> your feedback.
>
>> #Low-end CPUs may not be particularly fast in 64-bit mode.
>>
>> Unless slowed down by lack of memory because 64 bit requires more
>> memory, then 64 bit apps will always be faster due to more registers
>> and new FP instructions. Low end or not low end.

"If you added sufficient RAM to your 64-bit system to compensate, it would
run faster mainly because the newer 64-bit architectures have 8 times as
many high speed registers."

Whoaaa nelly. No.

Firstly, about the number of registers. The x86-64 architecture has more
registers than the x86. But architectures don't execute code - processors
do. And for a long time now, we've had a thing called register renaming,
which goes along with out-of-order and superscalar execution, which means
that the number of registers on the processor, physical registers, can
exceed the number of architectural registers. The x86-32 architecture may
only have 8 registers, but, for instance, the Pentium 4 Netburst design
has 128 physical registers.

I don't know if there's a correlation between the number of architectural
registers, and the number of physical registers you can use effectively.
If there is, then a register-rich 64-bit architecture could have even more
physical registers, and your point might still be valid.

However, there's another point. You're bang on about 64-bit machines
having bigger pointers (and possibly integers), and so data structures
using more memory. But this doesn't just affect the amount of memory a
structure uses, it affects the bandwidth it takes to move it in from
memory, and the amount of space it takes up in the cache. If you're
walking a linked list, for instance, then you need to load one pointer per
link; with an 8 GB/s memory interface, that's 2 billion links per second
on a 32-bit machine, but only 1 billion on a 64-bit. Similarly, if a link
object comprises a two-word object header and two one-word pointer fields,
then 4 MB of cache will hold a quarter of a million links on a 32-bit
machine, but only 128 thousand on a 64-bit.

So, if you're adding things to your machine to compensate for the
64-bitness, it needs to be not just RAM, but cache and bus bandwidth. I
don't believe that either of those things are limited by the width of a
register - 32-bit machines routinely have >32-bit buses already, and cache
size is limited by the size of the processor die and the process
technology - so i don't think 64-bit machines have any intrinsic advantage
here.

tom

--
Curse me, God, for making you this way!

Tom Anderson wrote:
> However, there's another point. You're bang on about 64-bit machines
> having bigger pointers (and possibly integers), and so data structures
> using more memory. But this doesn't just affect the amount of memory a
> structure uses, it affects the bandwidth it takes to move it in from
> memory, and the amount of space it takes up in the cache. If you're
> walking a linked list, for instance, then you need to load one pointer per
> link; with an 8 GB/s memory interface, that's 2 billion links per second
> on a 32-bit machine, but only 1 billion on a 64-bit. Similarly, if a link
> object comprises a two-word object header and two one-word pointer fields,
> then 4 MB of cache will hold a quarter of a million links on a 32-bit
> machine, but only 128 thousand on a 64-bit.

Mitigating that factor, one 64-bit quantity might hold that two-word
object header, and thus not inflate the memory requirement for that
piece.

It's all accordin'.

--
Lew

Roedy Green wrote:
> On Mon, 23 Jun 2008 20:01:57 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> #[I am ignoring the 1024 versus 1000 issue]
>>
>> Is that statement unclear ????
>
> I felt the discrepancy needed clarification.
>
> I run into this all the time. Whenever A says something that agrees
> with what B says, restates what B says, or elaborates what B says, or
> asks for confirmation of an interpretation of what B said, then B
> complains, as if the general assumption is that every statement in a
> newsgroup must necessarily be a refutation of some previous poster.
>
> I find this amusing given the ostensible purpose of debate is to
> persuade others to agree with you.

I do not have a problem with clarifications.

But I find it rather confusing when you use "I presume ..."
and then you list something that is explicit in the text
you are replying to.

If you use "To clarify ..." then people will be less confused.

Arne

Tom Anderson wrote:
> "If you added sufficient RAM to your 64-bit system to compensate, it
> would run faster mainly because the newer 64-bit architectures have 8
> times as many high speed registers."
>
> Whoaaa nelly. No.
>
> Firstly, about the number of registers. The x86-64 architecture has more
> registers than the x86. But architectures don't execute code -
> processors do. And for a long time now, we've had a thing called
> register renaming, which goes along with out-of-order and superscalar
> execution, which means that the number of registers on the processor,
> physical registers, can exceed the number of architectural registers.
> The x86-32 architecture may only have 8 registers, but, for instance,
> the Pentium 4 Netburst design has 128 physical registers.

It does not matter (for the point under discussion).

The compiler (JIT if Java) can only use the architectural registers. And
the CPU can only map architectural registers to physical registers - it
can not memory addresses to physical registers.

> However, there's another point. You're bang on about 64-bit machines
> having bigger pointers (and possibly integers), and so data structures
> using more memory. But this doesn't just affect the amount of memory a
> structure uses, it affects the bandwidth it takes to move it in from
> memory, and the amount of space it takes up in the cache. If you're
> walking a linked list, for instance, then you need to load one pointer
> per link; with an 8 GB/s memory interface, that's 2 billion links per
> second on a 32-bit machine, but only 1 billion on a 64-bit. Similarly,
> if a link object comprises a two-word object header and two one-word
> pointer fields, then 4 MB of cache will hold a quarter of a million
> links on a 32-bit machine, but only 128 thousand on a 64-bit.
>
> So, if you're adding things to your machine to compensate for the
> 64-bitness, it needs to be not just RAM, but cache and bus bandwidth. I
> don't believe that either of those things are limited by the width of a
> register - 32-bit machines routinely have >32-bit buses already, and
> cache size is limited by the size of the processor die and the process
> technology - so i don't think 64-bit machines have any intrinsic
> advantage here.

They do have a small one.

http://www.digit-life.com/articles2/...00-part-m.html

measured it to 1.6% to 3.8% for SPECint2000 benchmark.

Arne