[GRLUG] Random questions.

[Bob Kline]

On Fri, Jul 27, 2012 at 12:14 AM, Michael Mol <mikemol at gmail.com> wrote:

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

I think the last point is key for me right
now, and I'll be switching over.  I am
amused that some others see 32-bit
and 64-bit a wash, but of course it
always depends on what you're doing.
I spend much to most of my time in
in a browser, so any performance
improvements there - and that usually
means speed - are a big plus.

Interesting discussion.  Maybe it's
time for LJ,  Tom's Hardware, or some
other outfit to do an A/B on the two
situations now, and highlight some of
the bigger differences.  Perhaps some
are actually dramatic now.

An aside, way back when, Motorola
made some custom versions of the
68000 family of CPUs that had
extended addressing sizes. I think one
was the 68012.  CPUs were small
enough back then that one would do
that..

   -- Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20120727/ffeed46f/attachment-0001.html>