64-bit performance

Posted Apr 14, 2008 21:57 UTC (Mon) by epa (subscriber, #39769)
In reply to: My kid hates Linux (ZDNet) by JoeBuck
Parent article: My kid hates Linux (ZDNet)

Do you have any documented cases of x86_64 code running slower than i386 or needing more
memory?  After all 32-bit ints are still available on x86_64.  Some code might use twice the
memory when pointers are twice as big, but you only really care about memory usage for
memory-heavy apps, and those are the exact ones where you really want a 64-bit system to allow
more than 4Gibyte addressable memory for each app.

64-bit performance

Posted Apr 15, 2008 4:39 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] (2 responses)

Take a box with 2 Gb of memory. Run a program that requires a 1.5 Gb working set to avoid paging with 32 bit code, where the in-memory structure is heavy with pointers. Now recompile with -m64. Voila, it now needs maybe 2.5 Gb to avoid paging. You might well see the 64 bit code run 100 times slower.

We run workloads like that all the time.

64-bit performance

Posted Apr 15, 2008 6:08 UTC (Tue) by bronson (subscriber, #4806) [Link] (1 responses)

I suppose it's true that if you use an artificial 2.5 GB dataset and impose a 2 GB memory
limit, 32 bit would be faster.

In the real world, why wouldn't you just spend $50 for a 2GB memory upgrade?  Then the 64 bit
box would fly.  If you're not convinced, let's try this exercise again with a hypothetical 3.2
GB data set.  :)

In my experience, modern 64 bit boxes with stuffed with lots of ram are really cheap and
really damn fast.  I can't think of any reason to deploy 32 bit for servers/HPC these days.

64-bit performance

Posted Apr 15, 2008 18:38 UTC (Tue) by JoeBuck (subscriber, #2330) [Link]

"If you're not convinced, let's try this exercise again with a hypothetical 3.2 GB data set."

You've just answered your own question. Now you can run a problem that requires a 3.2GB working set with your 32 bit executable quickly (if you can squeeze it into the 4GB address space, and you'll need what Red Hat used to call the hugemem patch to make it work), but it takes maybe 5GB with the 64 bit executable, and the 32 bit version runs quicker.

Of course, you need the 64 bit executable when the problem size exceeds 4GB. The point is, it is useful for the developer to provide the user with both executables, to run on an operating system that can run both.

64-bit performance

Posted Apr 15, 2008 7:32 UTC (Tue) by laf0rge (subscriber, #6469) [Link] (2 responses)

The entire linux networking stack, and especially netfilter/iptables with connection tracking
is running 10-15% slower on x86_64 than on i386 kernels.

The main reason being that all pointers are suddenly twice as large, and thus most data
structures need at least one more cache line, resulting in significantly less of the working
set being present in cache, increasing cache misses, etc.

I think any code that has a lot of pointers in data structures should see the same effect.

64-bit performance

Posted Apr 15, 2008 19:39 UTC (Tue) by bronson (subscriber, #4806) [Link] (1 responses)

That's very interesting.  Has anybody tried working around this?

One solution would be convert hot 64-bit ptr fields to 32-bit offsets pointing into a single
memory pool.  I'm not familiar enough with the networking code to know how traumatic this
would be.  (I'm definitely not saying do this everywhere; just where it really matters).

This topic might make a fairly fascinating paper.  :)

64-bit performance

Posted Apr 18, 2008 6:07 UTC (Fri) by alankila (guest, #47141) [Link]

We should have pointers of a size intermediate between 32 and 64 bits, let's say 40-bit
pointers. The point being that the it'd be large enough to address the RAM necessary but
doesn't waste so much space.

I really don't think we'll ever grow to the point where we'll use all of the 64-bit pointer
address space, and pointers with top 20-30 bits unused are just wasted space.

Too bad that the whole world thinks in 2^n.