<br><br><div class="gmail_quote">On Fri, Jul 27, 2012 at 12:14 AM, Michael Mol <span dir="ltr"><<a href="mailto:mikemol@gmail.com" target="_blank">mikemol@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, Jul 26, 2012 at 10:31 PM, Bob Kline <<a href="mailto:bob.kline@gmail.com">bob.kline@gmail.com</a>> wrote:<br>
> On Thu, Jul 26, 2012 at 10:15 PM, Michael Mol <<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Jul 26, 2012 at 9:26 PM, Bob Kline <<a href="mailto:bob.kline@gmail.com">bob.kline@gmail.com</a>> wrote:<br>
>> > I still use a 32-bit version of Linux.<br>
>> > What's to be gained or lost by going<br>
>> > to a 64-bit version?<br>
>><br>
>> Larger address space.<br>
>><br>
>> Reduced memory fragmentation (so, less process memory bloat)<br>
>><br>
>> Improved performance, owing to utilization of more general-purpose<br>
>> registers.<br>
>><br>
>> What's to lose? At worst, some small amount of memory due to increased<br>
>> pointer size, but this shouldn't be a problem unless you're running in<br>
>> embedded-type environments. Practically speaking, it's a nonissue for<br>
>> most users.<br>
>><br>
><br>
> <a href="http://en.wikipedia.org/wiki/Physical_Address_Extension" target="_blank">http://en.wikipedia.org/wiki/Physical_Address_Extension</a><br>
><br>
> Apparently more than 4GB of RAM<br>
> is not necessarily an issue yet with<br>
> 32-bit CPUs, thanks to PAE.<br>
<br>
</div>PAE is a joke, if you have real larger address space capability.<br>
<br>
PAE works very much like the old XMS memory manager of DOS days. You<br>
have a block of your address space which you can swap out for some<br>
page sitting in unaddressable memory. In XMS, this block of memory was<br>
64KB. It's a bit larger these days, of course.<br>
<div class="im"><br>
><br>
> Anyway, I thought the 32-bit  versus<br>
> 64-bit differences might be more<br>
> consequential, but just as it's taken<br>
> ages to fully exploit 32-bit processors,<br>
> that seems to also apply to 64-bit now.<br>
> But apparently one is still typically an<br>
> order of magnitude away in terms of<br>
> memory sizes, and maybe other hardware,<br>
> before native 64 bit makes any difference<br>
> for the home user.<br>
<br>
</div>There's a huge difference between virtual addresses and physical<br>
addresses. You don't need more than 3GB of RAM in order to see benefit<br>
from a 64-bit address space. Understanding why means understanding how<br>
memory allocations work...<br>
<br>
When a program allocates memory, it tells the kernel, 'hey, I need a<br>
contiguous block of memory at least this many bits long.' When it's<br>
done, it may tell the kernel that it no longer needs that memory.<br>
<br>
This works great in theory, but you run into a few problems. First is<br>
that there's a minimum allocation size; the kernel isn't going to<br>
grant a program memory in chunks any smaller than the size of a single<br>
page. (By default, that's 4KB). So if you need 256 bytes of memory,<br>
the kernel will hand you 4KB. This minimum granularity can be buffered<br>
somewhat by your C library managing memory carefully, of course.<br>
<br>
The second problem you face is when your program lives a long time and<br>
makes a mixture of large and small requests (or even many small<br>
requests, followed by a large request.). If your address space is<br>
speckled with hundreds of tiny spots of allocated memory, you won't be<br>
able to get a new chunk of RAM any larger than the largest contiguous<br>
bit of free space. Think of it like files getting fragmented on your<br>
disk, with the additional restriction that while your free space is<br>
allowed to be fragmented, files *themselves* must not be. So, while<br>
your filesystem starts off fine with no fragmentation, the creation<br>
and removal of files of various sizes eventually causes your free<br>
space to be fragmented.<br>
<br>
The third problem relates to the first and second. Remember that while<br>
your kernel will only hand out chunks of memory in multiples of 4KB,<br>
your C library kindly breaks that into smaller pieces, and will<br>
service further requests from what remains of those 4KB blocks without<br>
bothering the kernel, if it can. Now, let's say you're done with some<br>
of those pieces. You tell your C library you're done with that<br>
memory...but there's still one 16 byte chunk of memory somewhere in<br>
that 4KB block that you haven't decided you're done with, yet. The C<br>
library can't give that 4KB back to the kernel until you've told it<br>
you're done with that 16 byte chunk.<br>
<br>
Firefox is widely known for 'leaking' memory. With the exception of<br>
some poorly written extensions holding references on objects, the<br>
cause of this wasn't true memory leaks, the cause was the<br>
fragmentation of the process's memory, as described above.<br>
<br>
While a 64-bit address space doesn't help with the first or third<br>
problems, it almost completely alleviates the second problem.<br>
<br>
Further, while everybody touts the RAM limit as being the biggest<br>
benefit of the AMD64 architecture, it's _not_. The biggest benefit<br>
come from other architectural improvements. Some of it comes from a<br>
massive increase in the number of general-purpose registers (remember<br>
back when PowerPC was kicking x86's butt for performance? This was a<br>
big part of the reason. The other half has been covered as of the<br>
introduction of Advanced Vectoring Extensions.), and some of it comes<br>
from a new calling convention that makes PIC not so much a pain in the<br>
butt.<br>
<br>
<br>
And regarding your earlier comment about 64-bit being sufficiently<br>
tested...we hit that point at least four years ago. I've been running<br>
64-bit Linux (well, multilib) almost exclusively since 2008, and the<br>
only thing that gave me any trouble was Skype...and that cleared up a<br>
few years ago.<br>
<div class="HOEnZb"><div class="h5"> </div></div></blockquote><div>Everything I know says these points </div><div>are all very much on the mark, and </div><div>given the last point, your comment </div><div>about "what do you have to lose" is</div>
<div>probably the key one.  It should only</div><div>get better as time goes on - that's</div><div>always been the case for the bigger</div><div>word and address sizes, which have</div><div>always had teething problems.  </div>
<div><br></div><div>I think the last point is key for me right</div><div>now, and I'll be switching over.  I am </div><div>amused that some others see 32-bit</div><div>and 64-bit a wash, but of course it </div><div>always depends on what you're doing.</div>
<div>I spend much to most of my time in</div><div>in a browser, so any performance </div><div>improvements there - and that usually</div><div>means speed - are a big plus.</div><div><br></div><div>Interesting discussion.  Maybe it's </div>
<div>time for LJ,  Tom's Hardware, or some</div><div>other outfit to do an A/B on the two</div><div>situations now, and highlight some of</div><div>the bigger differences.  Perhaps some</div><div>are actually dramatic now.</div>
<div><br></div><div>An aside, way back when, Motorola</div><div>made some custom versions of the</div><div>68000 family of CPUs that had </div><div>extended addressing sizes. I think one</div><div>was the 68012.  CPUs were small </div>
<div>enough back then that one would do</div><div>that..</div><div><br></div><div>   -- Bob</div><div><br></div><div> </div></div>