On 10/16/07, <b class="gmail_sendername">Bert Freudenberg</b> <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>On Oct 16, 2007, at 10:36 , Andrew Gaylard wrote:<br><br>> 5. What are the advantages/disadvantages to using 64-bits?<br>> - The first advantage is that your image size can be enormous.<br>> If you need the size of your VM code + in-memory image to exceed
<br>> 4 GB, then 64-bits is for you. Note that it will take ages to<br>> write out<br>> an image that's this big to disk. The sort of applications that need<br>> this are those which load a small(ish) image, and run code that
<br>> creates millions of objects, but don't save them back to disk in the<br>> image.<br><br>However, the garbage collector really is not up to the task of<br>collecting multiple gigabytes of garbage.</blockquote>
<div><br>OK <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> - Another advantage is that when the 64-bit-VM is built, the C
<br>> compiler<br>> knows the ABI is different from the 32-bit ABI. The x86-64 case is<br>> an important example: the old i386 ABI offered few registers, used<br>> i387 floating-point, and passed parameters on the stack. The x86-64
<br>> ABI has may more registers, has SSE, SSE2, etc for FP, and<br>> passes parameters in registers where possible. It also has additional<br>> instructions (MMX et al). All of this makes for a VM that runs faster
<br>> if the compiler is able to make use of it (and is told to at<br>> compile-time).<br><br>I doubt that, you need to profile. I have not heard anyone reporting<br>the 64 bit VM to be faster than the 32 bit version, on any machine.
</blockquote><div><br>I've found that the new registers and instructions can make a difference<br>when building apps 32-bit. (No, I don't have numbers.) However,<br>the loss of backward-compatibility across the x86 range normally
<br>precludes this for normal usage. When moving to 64-bits, I suspect<br>that this gain in performance is outweighed by the cost of larger pointers.<br>So, yes, we shouldn't make this point unless we have made some<br>
measurements and have some hard data.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 6. Why isn't there an officially-released 64-bit image?
<br>> Watch this space!<br><br>Because nobody needs it (yet), and therefore nobody feels an urge to<br>provide and maintain one.</blockquote><div><br>Actually, two years ago I was involved in a project that needed an<br>
estimated 6GB of object-space in RAM. (The project got cancelled<br>due to a fear of languages that don't have curly braces. But that's<br>another story.) There really are some people -- though not many --<br>who do have real-world problems which require 64-bit addressing.
<br>So it's not true to say that "nobody" needs it. But it's not a common<br>need, I do agree.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Anyway, writing this up for future reference is needed, thanks for<br>doing this. One thing you should watch out for though is to<br>distinguish between a 64 bit VM and a 64 bit image, which are<br>independent.</blockquote>
<div><br>Ah. Yes. Good that you pointed this out. So would it be correct to<br>say "a 64-bit VM is needed only if you have an architecture which<br>can't run 32-bit apps, or if you have a need for an enormous number
<br>of objects, in which case you'll also need a 64-bit image"?<br><br>Thanks for the input.<br><br>Andrew<br></div><br></div>