f



When a 32-bit OS is 37% faster than a 64-bit OS

http://biz.yahoo.com/bw/061003/20061003005999.html?.v=1

CHICAGO--(BUSINESS WIRE)--Neal Nelson & Associates, a Chicago area
computer performance consulting firm, has announced test results that
show a possible 37 percent throughput advantage when a Web-based
application is run under the 32-bit version of SUSE Linux Enterprise
Server 10 from Novell, in comparison to the same machine running a
64-bit version of SUSE Linux Enterprise Server 10. The tests were run
on a computer configured with two AMD Opteron 64-bit processors.

0
lqualig (4343)
10/6/2006 3:26:10 PM
comp.os.linux.advocacy 124139 articles. 3 followers. Post Follow

14 Replies
798 Views

Similar Articles

[PageSpeed] 16

In comp.os.linux.advocacy, Larry Qualig
<lqualig@uku.co.uk>
 wrote
on 6 Oct 2006 08:26:10 -0700
<1160148367.587970.241260@i3g2000cwc.googlegroups.com>:
>
> http://biz.yahoo.com/bw/061003/20061003005999.html?.v=1
>
> CHICAGO--(BUSINESS WIRE)--Neal Nelson & Associates, a Chicago area
> computer performance consulting firm, has announced test results that
> show a possible 37 percent throughput advantage when a Web-based
> application is run under the 32-bit version of SUSE Linux Enterprise
> Server 10 from Novell, in comparison to the same machine running a
> 64-bit version of SUSE Linux Enterprise Server 10. The tests were run
> on a computer configured with two AMD Opteron 64-bit processors.
>

This bears some analysis.  Could be a compiler optimization issue,
or perhaps there's something slightly off with the hardware.

Either way, a little weird.

-- 
#191, ewill3@earthlink.net
/dev/signature: Resource temporarily unavailable
0
ewill5 (11075)
10/6/2006 5:00:05 PM
The Ghost In The Machine wrote:

> This bears some analysis.  Could be a compiler optimization issue,
> or perhaps there's something slightly off with the hardware.

We'd have to start with what "web based application" they are talking about.

And like you say, is this an app compiled for a 32-bit OS?   If so it 
might run faster because the OS would be reinterpreting its 32-bit words 
and passing data in and out at 64 bit that had to be reformated for 
32-bit -- obviously making it slower.

However, through put overall in and out the socket to the web, I think, 
would be faster.


-- 
Texeme Construct
0
jabailo (8241)
10/6/2006 5:24:22 PM
On 2006-10-06, The Ghost In The Machine <ewill@sirius.tg00suus7038.net> wrote:
> This bears some analysis.  Could be a compiler optimization issue,
> or perhaps there's something slightly off with the hardware.
>
> Either way, a little weird.

Memory use is one thing that comes to mind.  I have some report generation
code in Perl that sent my 1 gig RAM AMD64 SuSE box into swapping hell, but ran
fine on my 1 gig RAM P4 SuSE box.  On the 64 bit box, it used around 3 times
as much RAM (which I don't understand...I'd expect approximately twice the
memory usage).
0
reply_in_group (13194)
10/6/2006 6:59:22 PM
In comp.os.linux.advocacy, John Bailo
<jabailo@texeme.com>
 wrote
on Fri, 06 Oct 2006 10:24:22 -0700
<1YmdnU6JRMjeDLvYnZ2dnUVZ_qKdnZ2d@speakeasy.net>:
> The Ghost In The Machine wrote:
>
>> This bears some analysis.  Could be a compiler optimization issue,
>> or perhaps there's something slightly off with the hardware.
>
> We'd have to start with what "web based application" they are talking about.

Aye.

>
> And like you say, is this an app compiled for a 32-bit OS?   If so it 
> might run faster because the OS would be reinterpreting its 32-bit words 
> and passing data in and out at 64 bit that had to be reformated for 
> 32-bit -- obviously making it slower.
>
> However, through put overall in and out the socket to the web, I think, 
> would be faster.
>

I suspect it depends on the limiting factor.  If it's the bandwidth of
the NIC 32- or 64-bit should make very little difference.

Benchmarks are tricky, though. :-)

-- 
#191, ewill3@earthlink.net
/dev/signature: Resource temporarily unavailable
0
ewill5 (11075)
10/6/2006 7:00:02 PM
The Ghost In The Machine wrote:

> I suspect it depends on the limiting factor.  If it's the bandwidth of
> the NIC 32- or 64-bit should make very little difference.
> 
> Benchmarks are tricky, though. :-)
> 

Well there you go...I hadn't thought about the NIC card.  That would 
obviously slow down a 64-bit system's throughput for any networked 
application.

-- 
Texeme Construct
0
jabailo (8241)
10/6/2006 7:06:58 PM
In comp.os.linux.advocacy, Tim Smith
<reply_in_group@mouse-potato.com>
 wrote
on Fri, 06 Oct 2006 18:59:22 -0000
<12id9sa3l0s8677@news.supernews.com>:
> On 2006-10-06, The Ghost In The Machine <ewill@sirius.tg00suus7038.net> wrote:
>> This bears some analysis.  Could be a compiler optimization issue,
>> or perhaps there's something slightly off with the hardware.
>>
>> Either way, a little weird.
>
> Memory use is one thing that comes to mind.  I have some report generation
> code in Perl that sent my 1 gig RAM AMD64 SuSE box into swapping hell, but ran
> fine on my 1 gig RAM P4 SuSE box.  On the 64 bit box, it used around 3 times
> as much RAM (which I don't understand...I'd expect approximately twice the
> memory usage).

I'd expect about the same memory usage; the only thing 64
bit should affect is padding around the edges of (and in
the middle of, if development gets a little sloppy) memory
blocks.  However, it is possible something is allocating
a lot of little blocks and the alignment is different.

Swapping won't help, certainly; a 4k page on an 833 MHz
32-bit FSB, if I'm not mistaken, should take 1.23 - 4.92
microseconds to walk through (depending on whether one uses
32-bit integers or bytes).  The same page on disk will have
an average rotational latency of 5.5 milliseconds on a 5400
RPM hard drive, and 3 milliseconds on a 10000 RPM unit.
If one needs a head seek add a few more milliseconds to
that total.  The actual read might take 25.6 microseconds,
if the drive has 160 MB/s transfer capability.

Expensive, especially if all one needed that page for was a
single byte, word, or longword.

-- 
#191, ewill3@earthlink.net
Linux.  Because it's not the desktop that's
important, it's the ability to DO something
with it.
0
ewill5 (11075)
10/6/2006 8:00:06 PM
Larry Qualig wrote:

> 
> http://biz.yahoo.com/bw/061003/20061003005999.html?.v=1
> 
> CHICAGO--(BUSINESS WIRE)--Neal Nelson & Associates, a Chicago area
> computer performance consulting firm, has announced test results that
> show a possible 37 percent throughput advantage when a Web-based
> application is run under the 32-bit version of SUSE Linux Enterprise
> Server 10 from Novell, in comparison to the same machine running a
> 64-bit version of SUSE Linux Enterprise Server 10. The tests were run
> on a computer configured with two AMD Opteron 64-bit processors.


You can run 8 bit applications faster in a PIC than in a 32 bit CPU.
It does depend on how you qualify the application.

I mean, are you talking bollocks because of that or because
you genuinely misunderstood?

0
10/6/2006 8:53:33 PM
In article <s1niv3-vq2.ln1@sirius.tg00suus7038.net>,
 The Ghost In The Machine <ewill@sirius.tg00suus7038.net> wrote:
> I'd expect about the same memory usage; the only thing 64
> bit should affect is padding around the edges of (and in
> the middle of, if development gets a little sloppy) memory
> blocks.  However, it is possible something is allocating
> a lot of little blocks and the alignment is different.

If a language uses the natural integer size of the machine, integers 
will take up twice as much space on a 64-bit machine.  Pointers will 
take up twice as much space.

Consider the following Perl code:

   my @a;
   for (my $i = 0; $i < $count; ++$i)
   {
      push @a, $i;
   }
   print "done\n";
   <STDIN>;

I ran this for various values of $count.  Here is the amount of memory 
it used:

      64-bit   32-bit
1     11m      4m             # not a typo: $count was 1 to get a base
2m    63m      44m
4m    135m     83m
8m    259m     158m
16m   507m     313m
32m   1003m    622m

I also tried a similar test, but instead of an array, it was a hash of 
$count items.  The keys and items were strings of 10 characters.  Here 
was the memory usage:

      64-bit   32-bit
200k  50m      27m
400k  89m      53m
800k  163m     98m
1600k 315m     184m
3200k 620m     381m

If I were building a machine for log analysis, report generation, etc., 
I think I'd go for a 32-bit machine (or at least install the 32-bit 
version of Perl).

-- 
--Tim Smith
0
reply_in_group (13194)
10/6/2006 11:38:10 PM
In comp.os.linux.advocacy, Tim Smith
<reply_in_group@mouse-potato.com>
 wrote
on Fri, 06 Oct 2006 16:38:10 -0700
<reply_in_group-DDE06B.16381006102006@news.supernews.com>:
> In article <s1niv3-vq2.ln1@sirius.tg00suus7038.net>,
>  The Ghost In The Machine <ewill@sirius.tg00suus7038.net> wrote:
>> I'd expect about the same memory usage; the only thing 64
>> bit should affect is padding around the edges of (and in
>> the middle of, if development gets a little sloppy) memory
>> blocks.  However, it is possible something is allocating
>> a lot of little blocks and the alignment is different.
>
> If a language uses the natural integer size of the machine, integers 
> will take up twice as much space on a 64-bit machine.  Pointers will 
> take up twice as much space.

Duh.  My brain must be half asleep today. :-)  Very good point.

>
> Consider the following Perl code:
>
>    my @a;
>    for (my $i = 0; $i < $count; ++$i)
>    {
>       push @a, $i;
>    }
>    print "done\n";
>    <STDIN>;
>
> I ran this for various values of $count.  Here is the amount of memory 
> it used:
>
>       64-bit   32-bit
> 1     11m      4m             # not a typo: $count was 1 to get a base
> 2m    63m      44m
> 4m    135m     83m
> 8m    259m     158m
> 16m   507m     313m
> 32m   1003m    622m
>
> I also tried a similar test, but instead of an array, it was a hash of 
> $count items.  The keys and items were strings of 10 characters.  Here 
> was the memory usage:
>
>       64-bit   32-bit
> 200k  50m      27m
> 400k  89m      53m
> 800k  163m     98m
> 1600k 315m     184m
> 3200k 620m     381m
>
> If I were building a machine for log analysis, report generation, etc., 
> I think I'd go for a 32-bit machine (or at least install the 32-bit 
> version of Perl).
>

Assuming Perl can compile itself in such a fashion.
I'll admit I have no experience on 64-bit machines beyond
maybe a brief stint with OSF/1 on an Alpha.  And even then,
we punted and used -taso on /bin/ld, basically restricting
all pointer usage to 32 bits.

-- 
#191, ewill3@earthlink.net
Does anyone else remember the 1802?
0
ewill5 (11075)
10/7/2006 2:00:03 AM
On Fri, 06 Oct 2006 17:00:05 GMT, The Ghost In The Machine
<ewill@sirius.tg00suus7038.net> wrote:

>In comp.os.linux.advocacy, Larry Qualig
><lqualig@uku.co.uk>
> wrote
>on 6 Oct 2006 08:26:10 -0700
><1160148367.587970.241260@i3g2000cwc.googlegroups.com>:
>>
>> http://biz.yahoo.com/bw/061003/20061003005999.html?.v=1
>>
>> CHICAGO--(BUSINESS WIRE)--Neal Nelson & Associates, a Chicago area
>> computer performance consulting firm, has announced test results that
>> show a possible 37 percent throughput advantage when a Web-based
>> application is run under the 32-bit version of SUSE Linux Enterprise
>> Server 10 from Novell, in comparison to the same machine running a
>> 64-bit version of SUSE Linux Enterprise Server 10. The tests were run
>> on a computer configured with two AMD Opteron 64-bit processors.
>>
>
>This bears some analysis.  Could be a compiler optimization issue,
>or perhaps there's something slightly off with the hardware.
>
>Either way, a little weird.

Yes, a compiler issue (GNU C/C++ is known to be really weak at
optimizing for anything), of maybe 64-bit Linux is just a fiction,
another of the "mee-too" handwaving of the OSS community.

Sure, Linux is 64-bit, all the way and since 10 years at least, only
problem: it's 37% slower than plain old crappy BKL'ed 32-bit! :-)))

About the benchmark "we have successfully isolated the performance
impact on this application of the 32-bit version versus the 64-bit
version of SUSE Linux Enterprise Server".

You don't like the outcome so, of course, the benchmark was flawed.

The funniest thing is to read the hilarious replies about NICs and
stuff. Linvocates at their best: failing to grasp the big picture...

0
otto2436 (617)
10/7/2006 10:14:10 AM
In comp.os.linux.advocacy, OK
<otto@keiser.de>
 wrote
on Sat, 07 Oct 2006 12:14:10 +0200
<cuuei212emvhuoudo5v5urit04mbpod99j@4ax.com>:
> On Fri, 06 Oct 2006 17:00:05 GMT, The Ghost In The Machine
> <ewill@sirius.tg00suus7038.net> wrote:
>
>>In comp.os.linux.advocacy, Larry Qualig
>><lqualig@uku.co.uk>
>> wrote
>>on 6 Oct 2006 08:26:10 -0700
>><1160148367.587970.241260@i3g2000cwc.googlegroups.com>:
>>>
>>> http://biz.yahoo.com/bw/061003/20061003005999.html?.v=1
>>>
>>> CHICAGO--(BUSINESS WIRE)--Neal Nelson & Associates, a Chicago area
>>> computer performance consulting firm, has announced test results that
>>> show a possible 37 percent throughput advantage when a Web-based
>>> application is run under the 32-bit version of SUSE Linux Enterprise
>>> Server 10 from Novell, in comparison to the same machine running a
>>> 64-bit version of SUSE Linux Enterprise Server 10. The tests were run
>>> on a computer configured with two AMD Opteron 64-bit processors.
>>>
>>
>>This bears some analysis.  Could be a compiler optimization issue,
>>or perhaps there's something slightly off with the hardware.
>>
>>Either way, a little weird.
>
> Yes, a compiler issue (GNU C/C++ is known to be really weak at
> optimizing for anything), of maybe 64-bit Linux is just a fiction,
> another of the "mee-too" handwaving of the OSS community.
>
> Sure, Linux is 64-bit, all the way and since 10 years at least, only
> problem: it's 37% slower than plain old crappy BKL'ed 32-bit! :-)))
>
> About the benchmark "we have successfully isolated the performance
> impact on this application of the 32-bit version versus the 64-bit
> version of SUSE Linux Enterprise Server".
>
> You don't like the outcome so, of course, the benchmark was flawed.
>
> The funniest thing is to read the hilarious replies about NICs and
> stuff. Linvocates at their best: failing to grasp the big picture...
>

It doesn't matter.  You need to upgrade your hardware anyway, to take
advantage of Vista's Aero. ;-)

Microsoft.  When it absolutely, positively has to be good for the
economy.

-- 
#191, ewill3@earthlink.net
"640K ought to be enough for anybody."
  - allegedly said by Bill Gates, 1981
0
ewill5 (11075)
10/9/2006 3:00:02 PM
After takin' a swig o' grog, The Ghost In The Machine belched out this bit o' wisdom:

> In comp.os.linux.advocacy, OK
>
>>>> http://biz.yahoo.com/bw/061003/20061003005999.html?.v=1
>>
>> Yes, a compiler issue (GNU C/C++ is known to be really weak at
>> optimizing for anything), of maybe 64-bit Linux is just a fiction,
>> another of the "mee-too" handwaving of the OSS community.
>>
>> Sure, Linux is 64-bit, all the way and since 10 years at least, only
>> problem: it's 37% slower than plain old crappy BKL'ed 32-bit! :-)))
>>
>> About the benchmark "we have successfully isolated the performance
>> impact on this application of the 32-bit version versus the 64-bit
>> version of SUSE Linux Enterprise Server".
>>
>> You don't like the outcome so, of course, the benchmark was flawed.
>>
>> The funniest thing is to read the hilarious replies about NICs and
>> stuff. Linvocates at their best: failing to grasp the big picture...
>>
>
> It doesn't matter.  You need to upgrade your hardware anyway, to take
> advantage of Vista's Aero. ;-)
>
> Microsoft.  When it absolutely, positively has to be good for the
> economy.

Unfortunately for OK's inane chortling over the results, the white paper
(only 5 pages) doesn't see fit to state which compiler was used.  Nor
does it state how much RAM was on the machine.  It doesn't try to
analyze the effect of their own software on the comparison.

It does mention the cache, and the explanation of the graph they show
may well lie in a cache issue, and yet they miss the opportunity to
clarify this issue (e.g. are their data structures twice as large on the
64-bit system).

All in all, a fairly amateurish effort, I think.

Just like OK's continued troll-efforts.

-- 
   If Bill Gates had a dime for every time a Windows box crashed...
      ...Oh, wait a minute, he already does.
0
linonut2 (5242)
10/9/2006 4:47:16 PM
Linonut wrote:
> After takin' a swig o' grog, The Ghost In The Machine belched out this bit o' wisdom:
>
> > In comp.os.linux.advocacy, OK
> >
> >>>> http://biz.yahoo.com/bw/061003/20061003005999.html?.v=1
> >>
> >> Yes, a compiler issue (GNU C/C++ is known to be really weak at
> >> optimizing for anything), of maybe 64-bit Linux is just a fiction,
> >> another of the "mee-too" handwaving of the OSS community.
> >>
> >> Sure, Linux is 64-bit, all the way and since 10 years at least, only
> >> problem: it's 37% slower than plain old crappy BKL'ed 32-bit! :-)))
> >>
> >> About the benchmark "we have successfully isolated the performance
> >> impact on this application of the 32-bit version versus the 64-bit
> >> version of SUSE Linux Enterprise Server".
> >>
> >> You don't like the outcome so, of course, the benchmark was flawed.
> >>
> >> The funniest thing is to read the hilarious replies about NICs and
> >> stuff. Linvocates at their best: failing to grasp the big picture...
> >>
> >
> > It doesn't matter.  You need to upgrade your hardware anyway, to take
> > advantage of Vista's Aero. ;-)
> >
> > Microsoft.  When it absolutely, positively has to be good for the
> > economy.
>
> Unfortunately for OK's inane chortling over the results, the white paper
> (only 5 pages) doesn't see fit to state which compiler was used.  Nor
> does it state how much RAM was on the machine.  It doesn't try to
> analyze the effect of their own software on the comparison.
>
> It does mention the cache, and the explanation of the graph they show
> may well lie in a cache issue, and yet they miss the opportunity to
> clarify this issue (e.g. are their data structures twice as large on the
> 64-bit system).
>
> All in all, a fairly amateurish effort, I think.


It's probably more accurate than you think. From all of the published
application benchmarks I've seen, typically it's only crypto code and a
few RDBMS that benefit from 64-bit code. Most other benchmarks such as
this one and Tim's informal Perl script run slower with 64-bit code.

The company I work for sells tools for the largest databases in the
world. We work with Oracle, DB2, Informix, Teradata, you-name-it and we
run on everything from NT boxes to mainframes to every *nix inbetween
the two. Our customers regularly process hundreds of terabytes, even
petabytes of data with our product. We have 64-bit versions available
for HP's Tru64 and various 64-bit versions of Linux. The fact is that
the 32-bit version is notably faster than the 64-bit. And when you have
a several petabytes of data to scrub and process, this difference adds
up to something very significant.

Mind you that work like this is done on some very high end hardware.
Often these machines have 16-32 processors, huge amounts of NAS storage
and several dozen Gigs of memory. Certainly not starving for hardware
resources but large 64-bit code simply doesn't run as fast as 32-bit
code.

I suspect that small "tight" routines (crypto for example) would run
faster but when you're talking about large/broad apps the opposite is
true.

0
lqualig (4343)
10/10/2006 5:25:51 PM
In article <1160501151.335205.25990@e3g2000cwe.googlegroups.com>,
 "Larry Qualig" <lqualig@uku.co.uk> wrote:
> I suspect that small "tight" routines (crypto for example) would run
> faster but when you're talking about large/broad apps the opposite is
> true.

One factor for crypto is that public key systems tend to make use of 
large integer arithmetic.  Suppose you are working with 1024-bit 
numbers.  On a 32-bit machine, you might view such a number as a 32 
digit number, with each digit being 32 bits.  On a 64-bit machine, you'd 
view that same number as a 16 digit number, with each digit being 
64-bits.

The time it takes to do large integer operations is a function of the 
number of digits.  Addition and subtraction is O(n), where n is the 
number of digits.  So, with a given algorithm, 32 digits numbers take 
about twice as long as 16 digits numbers.

Multiplication using the classical algorithm is O(n^2), so a 64-bit 
machine will be about 4 times as fast as a 32-bit machine on a given 
number.

Of course, there are better algorithms than the classical algorithm, 
such as Karatsuba's algorithm.  That one is O(n^1.585), so a 64-bit 
machine is about 3 times as fast.

The fastest algorithms are O(n ln(n) ln(ln(n))).  A 64-bit machine will 
be a little faster than twice as fast as a 32-bit machine.

Which algorithm is actually used by a given large integer library can 
depend on the size of the numbers.  The faster algorithms have more 
overhead, so for each there is some threshold below which it is better 
to go with an algorithm that is asymptotically slower.  So, you might 
actually see speedups anywhere from 2 to 4, depending on the size of the 
numbers (but those will be lowered a bit because there is other overhead 
involved in the large integer library).

-- 
--Tim Smith
0
reply_in_group (13194)
10/11/2006 12:09:13 AM
Reply: