Slashdot Mirror
Are 64-bit Binaries Slower than 32-bit Binaries?
JigSaw writes "The modern dogma is that 32-bit applications are faster, and that 64-bit imposes a performance penalty. Tony Bourke decided to run a few of tests on his SPARC to see if indeed 64-bit binaries ran slower than 32-bit binaries, and what the actual performance disparity would ultimately be."
In case anyone hasn't realized it yet, this article proves that OSNews is the most retarded website on the planet.
The typical story is titled like "A comprehensive review of the Atari ST". The contents are typically something like... "I found an old Atari ST, but my cdrom wouldn't fit in the 5.25" disk drive and mozilla wouldn't compile. So the Atari sucks"
I benchmarked a skilled Chinese abacus user against a C-programmer implementing an accounting system. The chinese dude figured out that 1+1=2 before the C-programmer loaded his editor, so the abacus is faster.
Conformity is the jailer of freedom and enemy of growth. -JFK
It all depends on how many of those 64 bits are 1's. 1's are a lot heavier than 0's, so too many of them will slow your program down a lot. If you compare a 32-bit program with all 1's, it will run significantly slower than a 64-bit program with only a few 1's. It's simple, really.
From the article:
I create a very simple C file, which I call hello.c:
main()
{
printf("Hello!\n");
}
Watch out... SCO owns this bit of code too...
--ken
Bitcoin pyramid: Join here: http://www.bitcoinpyramid.com/r/1427 it's FREE!
I can only assume that this is only going to be limited to SPARC...I mean, we've already seen the major differences between Itanium and Opteron dealing with 32 bit apps, right? Or is this a different question, since Opteron gets to run 32bit effectively "native"? And, at this point, when running 32 bit apps on a 64 bit chip, just what can "native" mean anyway?
Given a choice between free speech and free beer, most people will take the beer.
In his explanation, he said something of the order of "if you want speed, use the 32-bit version of the binaries, because otherwise the computer physically has to move twice as much data around for each operation it does." Only if you want the extra memory mapping capability of a 64-bit binary, he said, would you need to use the 64-bit version.
I suppose in summary, though, it depends on exactly what your binary does.
Aren't there certian optimizations and, in general, better coding for most 32 bit applications (on the lowest level of the code) because people have used it for so long? Couldn't it just be that we need to refine coding for 64 bit processors?
Most "tech gurus" I've talked to at my university about the benefites of 64bit processing say that it is in part due to the increase of the number of registers (allowing you to use more at the same time, shortening the number of cycles needed). Could time allow us to write more efficient kernels, etc for 64 bit processors?
So either the code isn't good enough, or perhaps there's another physical limitation (longer pipelines, etc) on the chip itself? Correct me if I'm wrong.
Now, gcc is known to produce shit code on sparcs. I am not saying 64 is always better, but to be hones, the stuff should at least have been compiled with Sun CC, possibly with -fast and -fast64 flags...
Well neither of you have provided any actual evidence proving they rock.. or sock... o.O -tromps off to OSNews to check out their benchmarks- I shall be back ^_^
The surmise that ALL 64 bit binaries are slower than 32 is incorrect...
At this stage of development for the various 64-bit architectures, there is very likely a LOT of room for improvement in the compilers and other related development tools and giblets. Sorry, but I don't consider gcc to be necessarily the bleeding edge in terms of performance on anything. It makes for an interesting benchmarking tool because it's usable on many, many architectures, but in terms of its (current) ability to create binaries that run at optimum performance, no.
I worked on DEC Alphas for many years, and there was continuing progress in their compiler performance during that time. And, frankly, it took a long time, and it probably will for IA64 and others. I'm sure some Sun SPARC-64 users or developers can provide some insight on that architecture as well. It's just the nature of the beast.
But that's only because it has two extra execution units for 64 bit code. 64 bit software is not inherently faster. Most people here would know this, but I just thought I might preemptively clear up any confusion.
I recall being very disappointed when my new VAX 11/750 running BSD 4.1 was much slower than my PDP 11/45 running BSD 2.8. All the applications I tested: cc, yacc, etc. were faster on the 16-bit PDP than the 32-bit VAX.
I kept the VAX anyway.
The same tricks that boost the performance of their CPU model numbers 20-30% over their clockspeed? =P
My understanding is that when you switch an Athlon64 or Opteron into 64bit mode, that you suddenly get access to more general purpose registers than the x86 normally has. So the compiler can generate more efficient code in 64bit mode, making use of the extra registers and so forth. I don't know if this makes a difference in real world apps or not though.
The guy seemed to have his conclusion written before he started... Or at least that's how it seemed to me. When he was doing the SSL test, he said that the results were ONLY about 10% slower on the 64 bit version. Now I might be far too much of a graphics programmer.... but I would consider 10% to be a rather significant slowdown.
The other thing that bothered me of course was when he said that the file sizes were only 50% bigger in some cases... sure, code is never all that big, but... still...
They didn't use an obsolete UltraSparc chip?
They added more registers to an architecture that had very few of them. This is likely where most of the performance increase comes from in 64bit mode on the Opteron, not from the fact that it is 64bit.
Your "analysis" may be valid, but it's really not applicable. The title of the story is, "Are 64-bit Binaries Really Slower than 32-bit Binaries?" The author takes a 64-bit machine, compiles a few programs, and tests the resulting binaries to see which is faster. I'd say that the review is aptly titled and an interesting point to think on. Certainly he didn't compile every open source program known to mankind, as it sounds like he missed some pet app of yours. OpenSSL might be kind of arbitrary, but gzip and MySQL seem like reasonable apps to test. Like the last page says (you *did* RTFA, right?), if you don't like his review, go write your own and get it published.
Then 16bit binaries should be even faster then 32.
And why stop there?
8bits should really scream.
I can see it now: 2GHz 6502 processors, retro computing. The 70's are back.
This article sounds completely stupid. Someone didn't know that pulling 64-bits across the bus( reading/writing can take longer than 32-bits? Never thought of the caches?
Just read the GCC Proceedings, there's explanations and benchmarks of the why/how/when of x86-64 in 32 vs 64-bit mode, both speed of execution and image size.
Belief is the currency of delusion.
The main product I work on, which was designed in a freaking vacuum, is so tightly tied to wintel that I've had to spend the greater part of a year gutting int and making it portable. Kind of. We currently use 1.5 gig of for the database cache. If we go any higher, we run out of memory. /3gb switch, but we kept having very odd things happen.
We tried win2k3 and the
This database could very easily reach 500 gig, but anything above 150 gig and performance goes in the toilet.
My solution...
Get a low-to-midrange Sun box that can handle 16+g and has a good disk subsystem. But that's not a current option. Like I said, this thing was designed in a vacuum. The in-memory data-structures are the network data structures. That are all packed on 1-byte boundaries. Can you say SIGBUS? A Conversion layer probably wouldn't be that hard, if it weren't build as ONE FREAKING LAYER!
Sorry, I had to rant. Anyway, a single 64 bit box would enable us to replace several IA32 servers. For large databases, 64bits is a blessing.
Matt
The point of a 64-bit architecture boils down to two things really, memory and data size/precision.
An architecture with 32-bits of address space can directly address 2^32 or approximately 4 billion bytes of memory. There are many applications where that just isn't enough. More importantly, an architecture whose registers are 32-bits wide is far less efficient when it comes to dealing with values that require more than 32 bits to express. Many floating point values use 64 bits and being able to directly manipulate these in a single register is a lot more efficient than doing voodoo to combine two 32-bit registers.
So, if you have an problem where you're dealing with astronomical quantities of very large (or precise) values, then a 64-bit implementation is going to make a very big difference. If you're running a text editor and surfing the web then having a wider address bus and wider registers isn't going to do squat for you. Now that doesn't mean that there may not be other, somewhat unrelated, architectural improvements found in a 64-bit architecture that a 32-bit system is lacking. Those can make a big difference as well, but then you're talking about the overall efficiency of the design, which is a far less specific issue than whether 64-bits is better/worse than 32.
Lee
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
As it needs to be said for any benchmarking story:
...and benchmarks.
There are 3 types lies. Lies. Damned Lies.
First, anyone with half a brain already knows what his "scientific" results prove. Second, anyone with two thirds of a brain has already performed similar (but probably better) tests and come to the same conclusion.
And third, OpenSSL uses assembly code hand-crafted for the CPU when built for the 32-bit environment (solaris-sparcv9-gcc) and compiles C when built for the 64-bit environment (solaris64-sparcv9-gcc). Great comparison, guy.
Apples, meet Oranges (or Wintels).
Mark
It makes absolutely no sense. Operations concerning large integers were MADE for 64 bit.
Hell, if they made a 1024 bit processor, it'd be something like OpenSSL that would actually see the benefit of having datatypes that bit.
Something is wrong, horribly wrong with these benchmarks. Either OpenSSL doesn't have proper support for 64 bit data types, this fellow compiled something wrong, or some massive retard published benchmarks for the wrong platform in the wrong place.
Or maybe I'm just on crack.
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
We've got an Itanic box at work that has WinXP 64bit edition on it so we can build & test some 64bit Windows binaries.
It's the slowest box in the place! Open a terminal (oops, command shell, or whatever they call it on Windoze) and do a 'dir' - it scrolls so slowly that it feels like I'm way back in the old days when I was running a DOS emulator on my Atari ST box.
Pretty much everything is _much_ slower on that box. It's amazingly bad and I've tried to think of reasons for this: Was XP 64bit built with debugging options turned on when they compiled it? But even if that were the case it wouldn't account for all of it - I'd only expect that to slow things down maybe up to 20%, not by almost an order of magnitude.
please, read the rest of the article, he just uses that as an example to show that the arguements he was passing to the compiler really were having an effect on the output, although I don't see why he ahd to do that considering what he does afterwards, that part was not the benchmark...
Actio personalis moritur cum persona. (Dead men don't sue)
Well considering that manufacturers have been working like crazy to produce both 64 bit hardware and software applications, one could see that there is still some stuff to be done in the field.
What most of the posts are considering and the test itself are "concluding" is that it has to be slower over all and even in the end when 64 bit computing finally reaches it's true breadth. However when the bottlenecks of the pipeline (in this case the cache) and the remaining problems are removed you can actually move that 64 bit block in the same time it takes to move a 32 bit block.
Producing to 32bit pipes takes up more space then creating a 64bit pipe in the end, no matter which way you look at it and no matter what kind of applications or processes its used for.
However the big thing that could change this theory is Hyper Compressed Carbon chips, that should replace silicon chips within a decade. (that's fairly conservative estimate.
From the article:
[...] you'll likely end up in a position where you need to know your way around a Makefile.
Well duh. What a surprise: compiling for a different platform might requires Makefile tweaking.
Am I the only one to think that was a dummy article wasting a spot for much more interesting articles about 64 bit computing?
A message from the system administrator: 'I've upped my priority. Now up yours.'
Why are we comparing mature 32-bit software with 64-bit software in its infancy?
Your "analysis" may be valid, but it's really not applicable. The title of the story is, "Are 64-bit Binaries Really Slower than 32-bit Binaries?" The author takes a 64-bit machine, compiles a few programs, and tests the resulting binaries to see which is faster.
How can you be certain that this isn't simply comparing the efficiency of the compilers - and not the resulting binaries???
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
But what's the fsking point?
News flash: 64-bit apps are, usually, slightly slower than 32-bit ones. Duh. Any developer who's been around 64-bit environments for more than a few weeks knows this. It's not like there's some subtle magic going on here; bigger pointers means more data to schlep around.
I think your parent's complaint is that is sort of like a cursory analysis indicating that triangular wheels aren't quite so good as round ones. If you really needed to be told this, you aren't in the audience that the article sounds like it's trying to address.
Certainly, many applications need 64 bits to operate. That doesn't mean it's the best tool for all jobs. The tone of the article sounds like it's exploring some big question that nobody's thought about before, and that's just silly.
If it makes you feel better, programs from 1995 tend to run a lot faster on modern hardware. Gzip a kernel on a 66MHz Pentium and then on 2GHz Opteron and you'll see what I mean.
Are you kidding? This guy is a genius. Not only did he actually figure out that the UltraSPARC-II processor is 64-bit, but he can actually use the file and time utilities! Most of the "linux admin" types I know who buy old Sparcs for the novelty factor end up putting linux on them anyway..."This Solaris stuff is too hard".
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
64-bit binaries run slower than 32? That's certainly the dogma in the x86 world, where 64-bit is in its infancy. That was the belief about Solaris/Sparc and the HP/AIX equivalents FIVE YEARS AGO maybe.
Running benchmarks of 32 vs. 64 bit binaries in a 64 bit Sparc/Solaris environment has shown little or no difference for us, on many occasions. If the author had used Sun's compiler instead of the substantially less-than-optimal gcc, I expect that his 20% average difference would have disappeared.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Because he used the same compiler, in 32-bit and 64-bit mode???
A deep unwavering belief is a sure sign you're missing something...
Both 32bit and 64bit binaries running on the same processor get the same data paths and the same amount of cache on many processors. But, for one thing, 64bit binaries use up more cache memory for both code and data. So, yes, if you run 32bit binaries on a 64bit processor with a 32bit mode, then the 32bit binaries will generally run faster. But the reason why they run well and all the data paths are wide is because the thing is a 64bit processor in the first place--that's really what "64bit" means.
64bit may help with speed only if software is written to take advantage of 64bit processing. But the main reason to use 64bit processing is for the larger address space and larger amount of memory you can address, not for speed. 4Gbytes of address space is simply too tight for many applications and software design started to suffer many years ago from those limitations. Among other things, on 32bit processors, memory mapped files have become almost useless for just the applications where they should be most useful: applications involving very large files.
between precision and speed.
It's not surprising that 64-bit processors are rated much slower than 32-bit ones. The fastest 64-bit AMD is rated 2.0ghz while the fastest AMD 32-bit is 2.2ghz.
If you use a shovel you can move it very fast to dig a hole. If you use a backhoe you're going to move much slower but remove more dirt at a time.
Using modern technology to build a 386 chip would result in one of the highest clock speeds ever but it would be practically useless. Using 386 era technology to build a 64 bit chip would be possible but it'd be massive and horribly slow.
I'm still debating whether or not to go with 64-bit for my next system. I'd rather not spend $700 on a new system so I can have a better graphics card and then have to spend several hundred more shortly after to replace the CPU and MB again. But then again, 64-bit prices are still quite high and I'd probably be able to be productive on 32-bit for several more years before 32-bit goes away.
Ben
Work Safe Porn
GCC uses the same code generator for both Sparc32 and Sparc64.
A deep unwavering belief is a sure sign you're missing something...
The article mentions tweaking the LD_LIBRARY_PATH...
I was told a long time ago by a number of people I considered to be Solaris gurus -- not to mention in a number of books, Sun docs, etc. -- that the LD_LIBRARY_PATH variable was not only heading towards total deprecation, but introduced a system-wide security issue.
In its stead, we were supposed to use the "crle" command to set our library paths.
On all of my boxes I use crle and not LD_LIBRARY_PATH and everything works as expected.
Any pro developers or Solaris technical folks that can comment on this?
I put NetBSD on most of my Sparc hardware. Because then I can run and build from the same exact source tree of packages as I use on my Intel boxes. And run a kernel built from exactly the same source.
Which brings up a point: both NetBSD/Sparc and NetBSD/Sparc64 will run on an Ultra 1, which is a 64 bit machine. Why doesn't somebody install each NetBSD port on two seperate Ultra 1 machines. Then the benchmark comparision can be between the normal apps that build on both systems, running in parallel on two identical systems. Its exactly the same codebase except for the 32 or 64 bittedness.
---
News flash: 64-bit apps are, usually, slightly slower than 32-bit ones. Duh. Any developer who's been around 64-bit environments for more than a few weeks knows this. It's not like there's some subtle magic going on here; bigger pointers means more data to schlep around.
That is the sort of "obvious" conventional wisdom that the article is questioning. In fact, 64-bit architecture means a lot more than pointer size, and merely counting bits is no way to estimate performance.
When we get solid state hard drives and if they're reliable and fast as regular ram then ram will be gone and the SSD will take over. So in essence your machine may just allocate itself a huge chunk of the drive as it's own memory space..
Imagine a machine that can grab 16g for it's memory usage and your video card having a huge chunk for itself also. Along with your terrabits of information space if things pan out well enough.
Adding more/more complex features to a cpu rarely speed it up by itself, however, it might allow the next generation of CPU to scale beyond the current generation.
Both in terms of direct CPU performance and for the software that runs on it.
This has happened a bunch of times during history. Remember the introduction of MMUs for instance? Definately slows down the software running on the machine, but without an MMU we all know that it was virtually impossible to do stable multitasking.
1/2 GB of memory basically the standard these days with XP.
A lot of people are buying home computers with 1 GB or more.
Dell in Japan (where I live) has a special offer these days on a lattitude D600 with 1GB of ram. That is, they expect to sell this thing in quantities.
I think a fair amount of PC users will hit the 4GB limit within a few years. Personally, I already swear about having just 1GB in my desktop at times when I have a handful of images from my slide scanner open in photoshop + the obvious browsers/mail programs and maybe an office program or 2 open.
Introducing 64bit does not make todays HW any faster than their counterparts, but it will make it possible to continue making machines better, faster and capable of handling increasingly more complex tasks.
Depends mainly on what data the test is using. If it's floating-point heavy, and uses double, then it always was 64-bit. On 64-bit hardware it'll gain the full-width data path and will be able to load/store 64-bit floating-point numbers faster, all things being equal. If it uses ints (not longs), it is and will stay 32-bit, there will be no difference unless the hardware is capable of loading two 32-bit numbers at once, effectively splitting the memory bus in two (HP-PA RISC can do it, his old Sun cannot, newest Suns can, I don't know if Opterons can). Finally, if the test uses data types which convert from 32 to 64 bits it will become slower, but only if it does enough math on these types. The later is important, since every half-complicated program uses pointers, explicitly or implicitly, but not every program does enough pointer arithmetics compared to other operations to make a difference. However, if it does, then it'll copy pointers in and out of main memory all the time, and you can fit half as many 64-bit pointers into the cache.
That's where the slowdown comes (plus some possible library issues, early 64-bit HP and Sun system libraries were very slow for some operations).
If your process resident memory size is the same in 64 and 32-bit mode, you should not see any slowdown. If you do, it's an issue with the library of the compiler (even though the compiler in this case is the same, the code generator is not, and there may be some low-level optimizations it does differently). If resident size of 64-bit application is larger, you are likely to see slowdown, and the more memory-bound the program is the larger it'll be.
Ha! Shows what you know! Atari-STs came with a built-in 3.5" drive - not a 5.25" so I say nya! to your feeble attempt at computer critic criticism.
I figured I would post a comment about AMD and their 64 bit chip benchmarks. Then I realised I was already beaten to it by about eleventy billion other people. Guess I should at least do a FIND through the comments before posting in future!
On SPARC, there are no 64-bit-only optimizations. The only reason to use 64-bit math is either if you need 64-bit integers, or use 64-bit pointers. Since none of the benchmarks can use either (the MySQL benchmark could, but the machine only had 256MB of RAM).
A deep unwavering belief is a sure sign you're missing something...
the tests were all run on a 64-bit machine. The argument is not so much about whether 32-bit or 64-bit binaries run faster, but which is the faster architecture. I'm pretty sure we don't have any apples-to-apples test platforms for that one, though
How exactly did you get 2 x 32bit processors running 64bit code?
Normal people worry me!
They've at best proved a supposition about a single architecture/process/compiler family. They have not proved a general case. Did they test on amd64? Alpha? Mips? No? Then why are they making unwarranted generalizations? Ah, they're retarded.
Actually, they didn't make generalizations. He very specifically stated that he only tested on a 64-bit Sparc, and an older one at that. He pointed out that while you can make some general conclusions, you can and should run tests on other architectures.
He also pointed out that he only tested a few applications, not a whole bunch of them. He was questioning conventional wisdom and wanted to know if there was any fact behind it, and he determined that there was. He did not determine the entire scope of the facts, and he did not claim to do so.
Sorry, I found it to be an interesting read, but you really have to take the first page seriously when he says "I only tested these things, so I can only conclude based on these tests, and it doesn't prove the general case." If you ignore that, then yes, you'll wind up with what you took away from the article.
Like what I said? You might like my music
By what method is a processor judged to be 16,32 or 64 bits?...
The 6502 had 8bit data, but 16 bit address bus, and was considered an '8 bit'
68000 had 16 bits data, 32 bits address - this was a 16 bit
So, why can't we just increase the address bus size of processors, to 64,while keeping the databus size at 32bits. have some new 64 bit addressing modes. The processor can still be 32 bit data, so the size of programs can stay the same....Store program code in the first 4Gigs of memory, (zero page!) , and the pointers within that code can remain 32bits, but have the option of using bigger 64bit pointers to point at data in the remaining 2^63 bytes. This should give best of both worlds of 32vs64 bit.
Address Windowing Extensions (AWE) really are a good solution for your problem.
If you're doing Win32, but really want 64-bit, then consider Win64. There are several OEMs providing it.
If your response is "can't afford it", then your .5 Terabyte database project is probably underfunded and likely to fail.
Solaris isn't any harder. It's just closed source and there isn't anywhere near as much free software avaiable for it. There certainly aren't as many 'guide for the clueless' websites as there are for Linux, needless to say. That can sometimes be a positive thing. To run free software packages, you can try to coerce the Zoularis thing and build software from the NetBSD pkgsrc tree on it, I guess. The interface between 'free software' and Solaris just has a lot more rough edges, in my experience, than running a Free OS on it from the start. I run Solaris on my SS10sx, because there's no free-software X Server for it that supports 24 bit color on it's dual cgfourteen framebuffer, but other than the ability to 'boast' about running Solaris at home, there's not much other reason to run it. I guess that's a status thing, or something.
---
OK, I'll do that. The compiler does make a difference. I'm just thinking that we don't take the whole picture into account enough here on slashdot.
You're right about everything, except trying to imply, if that's what you were doing, that he used the 'wrong' compiler. In order to test execution speed of 32-bit vs 64-bit binaries, you need to use the same compiler to build the binaries.
See, it gets complicated when you use different compilers. Yes, GCC is likely to build better-optimized binaries for 32-bit. Yes, GCC has a reputation for not optimizing binaries very well in the first place. But if he didn't use the same compiler for both binaries, the results would have been seriously skewed in answering the question. The results would have called into question why he used different compilers, whether or not the different compilers were equal, and so forth.
To answer the question, he needed a compiler that could build both types of binaries to the same level of optimization, no matter how shitty. He wasn't trying to build the fastest binaries on earth, he was trying to build binaries that could be compared to one another in execution speed, using the same source code, and a compiler that would produce the same shitty executable.
That's all. :)
Like what I said? You might like my music
We were finding the damn things in the ventilators for weeks afterward.
And the brethren went away edified.
Still, the word size of the processor is not a major factor in now fast a CPU is. Finding fater ways to process instructions, caches, and how fast you run the CPUs at make more of a difference. I am probably leaving out a lot of other major factors. Oh well.
The article is a bit interesting although it seems very amateurish. Just my personal opinion.
In fact the same logic means that with all else being equal an 8 bit processor is slightly faster than a 16 bit processor and a 16 bit processor is slightly faster than a 32 bit processor. But of course all else is never equal so things are usually the other way around.
Has anyone heard of a set (family?) of processors that were exactly the same EXCEPT for the processor's word size?
Losing faith in humanity one person at a time.
I guess you didn't have the "pleasure" of using near, far and huge pointers in DOS compilers. In your model, every library function would have to have two versions - one that takes 32 bit pointers and one that takes 64 bit.
Uniform and simple is good...
At a TV station I used to work at, we used to send people on searches for "Liquid Video". Pretty much the same results! It's amazing the people that get hired at TV stations. Mr. Blinker-Fluid would be a genius compared to some in my industry of choice.
:)
At the station I'm at now, they send PA's to ask the engineers for the "ChromaKey for the Genlock".
It's mandatory to wash your hands before returning to the land of Dairy Queen.
The performance increase comes from a combination of lower memory latency (built-in memory controller) and an increased number of registers. The small number of registers on x86 chips has always been one of the main gripes people have had about the architecture.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
You are correct, although the issues are more subtle than your examples (not hard).
A benchmark is useless without interpretation. The people at OSNews have failed to give us any technical background information on the SparcV chip (penalties running in 64-bit as well as benefits), a proper breakdown of the type of math done by the example programs, as well as analyses of bottlenecks in the benchmarks (MySQL, for instance, is possibly I/O limited).
They've given us raw numbers, with no thought behind them. This is what makes a bad article.
It's all in benchmark. It doesn't matter what you benchmark, only what you benchmark with ;)
;)
But there are several points
1. The results for openssl are no good because openssl for sparc32 has critical parts written in asm, while for sparc64 it is generic C.
2. The results would be much better if you did it with Sun's cc, which is much better optimised for both sparc32 and sparc64.
3. The results, even if they were accurate, are good only for sparc32 vs sparc64. Basically, sparc64 is the same processor as sparc32, only wider
I don't know what's the case for ppc32 vs ppc64, but when you look at x86 vs x86-64 (or amd64 as some prefer to call it) you have to take into account much larger number of registers, both GP and SIMD.
As a matter of fact, x86 is such a lousy architecture that it really doesn't have GP registers -- every register in x86 processor has its purpose, other than the rest. It looks better in case of FP and SIMD operations, but it's ints that most of the programs deal with. Just compile your average C code to asm and look how much of it deals with swapping data between registers.
(well, full symmetry of registers for pure FP, non-SIMD operations was true until P4, when Intel decided to penalize the use of FP register stack and started to ``charge'' you for ``FP stack swap'' commands, which were ``free'' before, and are still free on amd processors)
x86-64 on the other hand in 64bit mode has twice more registers with full symmetry between them, as well as even more SIMD registers. And more execution units accessible only in 64bit mode.
But, from this chaotic notes you can already see, that writing good comparission of different processors is a little bit more than ``hey, I've some thoughts that I think are important and want to share''. And the hard work starts with proper title for the story -- in this case it should be ``Are sparc64 binaries slower than sparc32 binaries?''.
Robert
Bastard Operator From 193.219.28.162
The biggest fault I can see with this test depends upon sizeof(int) -
I don't know about Sun, but in some other environments in which a 32 bit and a 64 bit model exist, the compiler will always treat an int as 32 bits, so as not to cause structures to change size. Hell, even on the Alpha, which was NEVER a 32 bit platform, gcc would normally have:
sizeof(short) = 2
sizeof(int) = 4
sizeof(long) = 8
Now, consider the following code:
for (int i = 0; i 100; ++i)
{
frobnicate(i);
}
IF the compiler treats an int as 4 bytes, and IF the compiler has also been informed that the CPU is a 64 bit CPU, then the compiler may be doing dumb stuff like trying to force the size of "i" to be 4 bytes, by masking it or other foolish things.
So, the question I would have is, did the author run a test to insure that the compiler was really making int's and unsigned's be 64 bits or not?
www.eFax.com are spammers
And what if the compiler sucks/has no optimizations for 64-bit binaries?
I just wonder why some are so offended by the article. I have to believe that some people feel that he has "disagreed" with them or something to have such violent reactions. It's just some benchmarks, as he infers, it's better than some people just supposing the answer to a things they are wondering about.
and merely counting bits is no way to estimate performance.
If you only have room for 16k of data in your L1 cache and all your size_t, pointers, and in most cases longs too take twice as much memory at worst it is like you have only 8k of cache now compared to the 32bit version!At best it is going to make no difference, but at worst it is like your system now has only half the cache and half the memory bandwidth. Seems to me that by counting bits you can estimate your performance will be between 100% and 50% of the 32bit version, all other things equal.
A noteable exception would be when you need a 64bit value and are forced to emulate that.
If the compiler sucks, then it would suck equally for 32-bit and 64-bit binaries! They use the same code generator!
A deep unwavering belief is a sure sign you're missing something...
This is modded Insightful?
You've completely missed the entire point of the test. This has nothing to do with your next purchase decision -- it's purely designed to test whether or not the common claim that using 64-bit values decreases performance due to memory latency is true. This test makes no claims whatsoever that it has anything to do with whether or not you should be using a 64-bit setup. RTFA.
The "obsolete architecture" is one of the few where 64-bit and 32-bit operations have no inherent performance advantage on the processor, unlike the Opteron and Itanium processors where 64-bit mode has several advantages over 32-bit mode (extra registers or not being emulated). This makes it a perfect testbed for evaluating this claim. The speed of the processor has absolutely no relevance to the question at hand (with the exception of testing memory access starvation on system with a greater CPU to bus clock difference).
It's a shame you're too wrapped up in a "buy, buy, buy" mindset to consider the value of curiosity and of testing commonly held beliefs.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").