You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Walter Vaughan <wv...@steelerubber.com> on 2007/03/29 18:00:48 UTC
64 bit ofBiz
Is anyone working with ofBiz in 64 bit mode? I'm looking at configuring/leasing
a server (dual quad core box), and to get the javaVM to use more than 2Gig of
memory from what I've read, I need to run a 64 bit JavaVM.
I know this probably is way overkill, but the cost is reasonable right now for
these servers, and we've got time to 'speriment, and if we have to,we can still
run this stuff in 32bit mode.
--
Walter
Re: 64 bit ofBiz
Posted by BJ Freeman <bj...@free-man.net>.
I may have stated it in a way that gave a misconception.
this is more of sales against technical.
it would be assumed that when a computer says it has 2 gigs of memory
for a 64 bit process that would be for the 64 bit addressing space.
however marketing wants to make it look bigger so there reference to 2
gigs is 32 bit wide memory modules.
so 2 gigs of 32 bit wide memory modules, equals 1 gigbyte of 64 bit
addressing.
Porter Woodward sent the following on 3/29/2007 12:00 PM:
> My understanding as far as 64 bit Java is concerned is that the JVM is
> available in 64 bit versions for Solaris, Linux, and Windows - typically
> for x64 (64 bit x86 processor) architecture. My home PC runs Windows XP
> 64 bit edition, and the 64 bit JVM with no problems. OFBiz even fires
> up and runs fine on it. I would believe that the 64 bit JVM would have
> a few advantages over the 64 bit version - not in terms of memory
> consumption (and the assertion that a 64 bit system will use double the
> memory is incorrect*) - but in terms of actual instructions needed to
> accomplish work.
>
> Internally Java has used pretty wide (bitwise) representations of
> primitive data types. For example a Java "int" is 32 bits on all JVMs.
> At the time of it's introduction that was pretty radical as typically a
> 'C' style "int" was typically 16 bits wide (depending on the vendor of
> your compiler). So you can imagine the "book-keeping" the JVM might
> have had to do on earlier operating systems and architectures - needing
> to use two 16 bit memory locations to store the value of a 32 bit
> integer, and also needing to keep track of which two 16 bit values went
> together, etc. The Java "long" type is 64 bits wide. Up until recently
> this has meant that the JVM has had to provide "emulation" in a manner
> similar to that described for 32 bit values on older systems for 64 bit
> values. No longer. A 64 bit JVM should be using native operations
> capable of 64 bit wide operands to handle 64 bit values.
>
> * as to why 64 bit processors don't suddenly see 1/2 the memory... (a) a
> byte is defined as 8 bits.
> (b) a kilobyte is 1000 bytes. (actually 1024)
> (b) a megabyte is 1000 KB. (actually 1024)
>
> So the sizing of memory values is external to the bit-width of
> operations and operands on a CPU.
>
> Additionally because x86 processors - even the x64 variants are still
> "CISC" style chips, they have variable bit length instructions. An ADD
> instruction might be 4 bits wide (and still work on 64 bit operands),
> whereas an SSE instruction might be 24 or 32 bits wide. Hence x86 CISC
> chips have to do more work to "decode" instructions as they come to the
> CPU... RISC was viewed as an improvement as all operations, and
> operands were fixed width. So a 32 bit RISC chip all instructions were
> 32 bits wide, and worked on 32 bit wide operands. Hence binary sizes
> for RISC chips were typically larger than the equivalent CISC binary -
> which might be the source of misapprehension concerning memory usage
> when increasing bit width of a CPU.
>
>
> BJ Freeman wrote:
>> the is slightly off topic:
>> when you increase the bits of a processor, the available ram is
>> decreased.
>> so 2 gig on a 32 bit is only usable 1 gig on 64 bit.
>> so unless the code in javaVM at the machine level is taking advantage of
>> the 64 bit instruction set, you are not gaining anything.
>> What usually happens it the complied runtime is still using the 32 bit
>> instruction set, on a 64 bit cpu. until they go in and optimize the
>> machine code generated.
>>
>>
>> Walter Vaughan sent the following on 3/29/2007 8:00 AM:
>>
>>> Is anyone working with ofBiz in 64 bit mode? I'm looking at
>>> configuring/leasing a server (dual quad core box), and to get the javaVM
>>> to use more than 2Gig of memory from what I've read, I need to run a 64
>>> bit JavaVM.
>>>
>>> I know this probably is way overkill, but the cost is reasonable right
>>> now for these servers, and we've got time to 'speriment, and if we have
>>> to,we can still run this stuff in 32bit mode.
>>>
>>> --
>>> Walter
>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: 64 bit ofBiz
Posted by Porter Woodward <pw...@practicable.net>.
My understanding as far as 64 bit Java is concerned is that the JVM is
available in 64 bit versions for Solaris, Linux, and Windows - typically
for x64 (64 bit x86 processor) architecture. My home PC runs Windows XP
64 bit edition, and the 64 bit JVM with no problems. OFBiz even fires
up and runs fine on it. I would believe that the 64 bit JVM would have
a few advantages over the 64 bit version - not in terms of memory
consumption (and the assertion that a 64 bit system will use double the
memory is incorrect*) - but in terms of actual instructions needed to
accomplish work.
Internally Java has used pretty wide (bitwise) representations of
primitive data types. For example a Java "int" is 32 bits on all JVMs.
At the time of it's introduction that was pretty radical as typically a
'C' style "int" was typically 16 bits wide (depending on the vendor of
your compiler). So you can imagine the "book-keeping" the JVM might
have had to do on earlier operating systems and architectures - needing
to use two 16 bit memory locations to store the value of a 32 bit
integer, and also needing to keep track of which two 16 bit values went
together, etc. The Java "long" type is 64 bits wide. Up until recently
this has meant that the JVM has had to provide "emulation" in a manner
similar to that described for 32 bit values on older systems for 64 bit
values. No longer. A 64 bit JVM should be using native operations
capable of 64 bit wide operands to handle 64 bit values.
* as to why 64 bit processors don't suddenly see 1/2 the memory...
(a) a byte is defined as 8 bits.
(b) a kilobyte is 1000 bytes. (actually 1024)
(b) a megabyte is 1000 KB. (actually 1024)
So the sizing of memory values is external to the bit-width of
operations and operands on a CPU.
Additionally because x86 processors - even the x64 variants are still
"CISC" style chips, they have variable bit length instructions. An ADD
instruction might be 4 bits wide (and still work on 64 bit operands),
whereas an SSE instruction might be 24 or 32 bits wide. Hence x86 CISC
chips have to do more work to "decode" instructions as they come to the
CPU... RISC was viewed as an improvement as all operations, and
operands were fixed width. So a 32 bit RISC chip all instructions were
32 bits wide, and worked on 32 bit wide operands. Hence binary sizes
for RISC chips were typically larger than the equivalent CISC binary -
which might be the source of misapprehension concerning memory usage
when increasing bit width of a CPU.
BJ Freeman wrote:
> the is slightly off topic:
> when you increase the bits of a processor, the available ram is decreased.
> so 2 gig on a 32 bit is only usable 1 gig on 64 bit.
> so unless the code in javaVM at the machine level is taking advantage of
> the 64 bit instruction set, you are not gaining anything.
> What usually happens it the complied runtime is still using the 32 bit
> instruction set, on a 64 bit cpu. until they go in and optimize the
> machine code generated.
>
>
> Walter Vaughan sent the following on 3/29/2007 8:00 AM:
>
>> Is anyone working with ofBiz in 64 bit mode? I'm looking at
>> configuring/leasing a server (dual quad core box), and to get the javaVM
>> to use more than 2Gig of memory from what I've read, I need to run a 64
>> bit JavaVM.
>>
>> I know this probably is way overkill, but the cost is reasonable right
>> now for these servers, and we've got time to 'speriment, and if we have
>> to,we can still run this stuff in 32bit mode.
>>
>> --
>> Walter
>>
>>
>>
>>
>
>
Re: 64 bit ofBiz
Posted by BJ Freeman <bj...@free-man.net>.
the is slightly off topic:
when you increase the bits of a processor, the available ram is decreased.
so 2 gig on a 32 bit is only usable 1 gig on 64 bit.
so unless the code in javaVM at the machine level is taking advantage of
the 64 bit instruction set, you are not gaining anything.
What usually happens it the complied runtime is still using the 32 bit
instruction set, on a 64 bit cpu. until they go in and optimize the
machine code generated.
Walter Vaughan sent the following on 3/29/2007 8:00 AM:
> Is anyone working with ofBiz in 64 bit mode? I'm looking at
> configuring/leasing a server (dual quad core box), and to get the javaVM
> to use more than 2Gig of memory from what I've read, I need to run a 64
> bit JavaVM.
>
> I know this probably is way overkill, but the cost is reasonable right
> now for these servers, and we've got time to 'speriment, and if we have
> to,we can still run this stuff in 32bit mode.
>
> --
> Walter
>
>
>
Re: 64 bit ofBiz
Posted by Walter Vaughan <wv...@steelerubber.com>.
Chris Howe wrote:
> There was a note on Sun's website that Java 5 does not support Itanium
> 2 processor, so I guess keep that in mind.
Nah, I'm looking at the Quad core Intel Xeons, Dual Core Opertons, or a used Niagra.
Re: 64 bit ofBiz
Posted by Chris Howe <cj...@yahoo.com>.
There was a note on Sun's website that Java 5 does not support Itanium
2 processor, so I guess keep that in mind.
--- Manuel Desdin <md...@iguanait.com> wrote:
> walter:
> our experience is using linux (x86_64), opteron amd processors dual
> and quad cores with 4 to 8GB of memory. beginning with java 1.5 there
>
> is a 64bits version from sun. our best results are with this version.
>
> and yes everything runs as good as with 32bits with 32bits
> processors. no experience here with new intel 64bits processors, but
>
> my expirience, at least under linux tells me that they will work
> equally good if not better.
> regards, manuel.
>
> On Mar 29, 2007, at 6:00 PM, Walter Vaughan wrote:
>
> > Is anyone working with ofBiz in 64 bit mode? I'm looking at
> > configuring/leasing a server (dual quad core box), and to get the
> > javaVM to use more than 2Gig of memory from what I've read, I need
>
> > to run a 64 bit JavaVM.
> >
> > I know this probably is way overkill, but the cost is reasonable
> > right now for these servers, and we've got time to 'speriment, and
>
> > if we have to,we can still run this stuff in 32bit mode.
> >
> > --
> > Walter
>
>
Re: 64 bit ofBiz
Posted by Manuel Desdin <md...@iguanait.com>.
walter:
our experience is using linux (x86_64), opteron amd processors dual
and quad cores with 4 to 8GB of memory. beginning with java 1.5 there
is a 64bits version from sun. our best results are with this version.
and yes everything runs as good as with 32bits with 32bits
processors. no experience here with new intel 64bits processors, but
my expirience, at least under linux tells me that they will work
equally good if not better.
regards, manuel.
On Mar 29, 2007, at 6:00 PM, Walter Vaughan wrote:
> Is anyone working with ofBiz in 64 bit mode? I'm looking at
> configuring/leasing a server (dual quad core box), and to get the
> javaVM to use more than 2Gig of memory from what I've read, I need
> to run a 64 bit JavaVM.
>
> I know this probably is way overkill, but the cost is reasonable
> right now for these servers, and we've got time to 'speriment, and
> if we have to,we can still run this stuff in 32bit mode.
>
> --
> Walter