Are 64-bit Binaries Slower than 32-bit Binaries? 444
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."
Re: OSNews (Score:5, Funny)
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.
Re: OSNews (Score:5, Insightful)
Re: OSNews (Score:4, Insightful)
How can you be certain that this isn't simply comparing the efficiency of the compilers - and not the resulting binaries???
Re: OSNews (Score:3, Informative)
Re: OSNews (Score:3, Insightful)
Re: OSNews (Score:3, Interesting)
Re: OSNews (Score:5, Informative)
Re: OSNews (Score:5, Informative)
Re: OSNews (Score:5, Insightful)
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.
OSNews = UnNews? (Score:3, Flamebait)
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
Re:OSNews = UnNews? (Score:5, Informative)
One of the issues that people forget is that a 64-bit processor may be able to retire a set number of 64-bit, say, integer additions per clock cycle (NOTE: retiring an operation per clock cycle does NOT mean that the operation takes one clock cycle to perform). Well, the odds are that it will also retire the same number of 32-bit integer additions per clock cycle. It may take 5 clock cycles to do either sized addition even. So, what do you have that is different? Well, on the SPARC, most simple operations are going to be similar in execution time. Regarless of the number of register windows that the particular architecture supports (which may come into play in some codes), you still basically have 32 registers for use in your computational kernel. The only real difference between many 32-bit and 64-bit versions of the code will be the amount of data that has to be moved around.
Where the 64-bit will help is when the 32-bit code has to synthesize 64-bit operations or has to do things like work on bit streams (not word/byte streams exactly) and can work on 64-bits at a time rather than doing really the same thing on 32-bits two times as much (128 bytes can be traversed in 32 32-bit operations or 16 64-bit operations - half the number of reads/operations).
All of this is pretty well understood by those who have dealt with these type systems before. However, the relative newcomer Opteron has an additional twist. In 64-bit mode, there are twice as many registers that can be used compared to 32-bit mode. This may (read: will) cause some codes to be done faster simply because more data can be stored in registers rather than memory, even L1 cache is a bit slower than a register.
Re:retarded. (Score:5, Informative)
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.
Re:retarded. (Score:5, Insightful)
What purchase decision? (Score:4, Interesting)
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.
Benchmarks (Score:3, Funny)
There are 3 types lies. Lies. Damned Lies.
Re:Benchmarks (Score:5, Funny)
i've got some specint stats that show that damned lies are up to 30% faster.
Re:Benchmarks (Score:5, Insightful)
And they often show disparity in their results due to being interupted. This would be a baddly carried out benchmark under less than ideal conditions. This is human error. Of course there are slight variations in subsequent runs, but these should be able to be explained and compensated for. It is most certainly not a benchmark lie though. If it took that long, then it took that long, now find out why!
But in benchmarking scientific rigor is always lost
Failing to retain a scientific approach is a human failing. It does not always happen and is not the benchmark telling lies, but due to poor procedure.
But the benchmark choice is frequently meaningless or misleading.
[poor] "Choice", "Meaningless" and "misleading" [results] each require an incompetent person. Don't blame the benchmark. Even if they wrote the benchmark, they might not understand the results.
Benchmarks do not elucidate any fact.
Yes they do. Very very specific facts which can later be used to make considerations for future decisions. It could be a specific application, algorithm, overall CPU ALU, FPU or single CPU instruction, it could be bus type, etc. Specific facts leading to educated decisions.
You will always see in CPU tests LAME encoding. The p4 will always win against an Athlon.
If this is the case, then LAME as it stands is specifically faster on a P4 than an Athlon. That would be a coarse benchmark though. Some would call it "real world". And it is. It is specific to LAME, but not specific at a lower level where it could be found why this might be the case and how to improve LAME on both P4's and Athlons seperately (with an end result that might have the Athlon out-perform the P4, due to new insight gained from benchmarking specific areas).
The reviewer will not explain why this is the case and that LAME encoding is simply clock cycle dependent.
So the reviewers fault becomes the benchmarks fault?
Benchmarkers need to be able to explain all the dependent variables, to tell why the results happen.
Thus my original statements?
In graphics cards Q3 benchmarks above a certain magnitude are meaningless.
Bad choice of benchmark is the fault of the benchmark?
Benchmarks need to be interpetted by someone competent enough to do so. Just because someone carried out a poor benchmark procedure or could not understand the results, does not mean the benchmark lied.
The reviewer with meaningless variables creates an inauthentic conditioned desire in the consumer that leads to bad and lax software and hardware engineering.
Incompetent reviewer, ignorant consumer, deceitful engineering.
Morrowind and other games have horrible problems with their graphics engine that can not be saved by faster GPUs and dx9.
So they are CPU bound? Memory? Sounds like maybe they don't know how to profile their code too well. When profiling, it helps to know how to benchmark and make meaning out of the results.
You cannot improve that which you do not understand, through anything other than luck. Benchmarks provide specific facts which, when correctly interpreted, can bring about improvements. People who can't interpret them, say they are meaningless.
Re: OSNews (Score:5, Funny)
Re: OSNews (Score:4, Interesting)
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.
Re: OSNews (Score:3, Insightful)
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. T
Re: OSNews (Score:2, Informative)
Re: OSNews (Score:2)
It all depends... (Score:5, Funny)
Re:It all depends... (Score:2, Funny)
Re:It all depends... (Score:4, Funny)
Re:It all depends... (Score:2, Funny)
Dilbert: Sure! Just start randomly deleting things. All that data can be pretty heavy!!!!
(later)
Pointy haired boss: Hmmm...Windows? My house already has all I need! *click* Yes! That's gotta be like 5 pounds!
Re:It all depends... (Score:5, Funny)
Re:It all depends... (Score:5, Funny)
this reminds of "back in the day" when we ran a token ring network. when end users would complain about net outage we'd simply tell them that the token got stuck or, worse yet lost. fortunately, we have a backup token on floppy back in the systems room. it's an fddi token, mind you, so it's a bit bigger but if you don't kink the cabling it should work fine for now.
Re:It all depends... (Score:4, Funny)
Re:It all depends... (Score:5, Funny)
Man, I'm going offtopic, but back in my oil-changing days...
Some new guy had started working, and his neck was redder than desert sand. He told me that his girlfriend's car had a blinker out on the left and he replaced the bulb and the light didn't come back on. I asked him if he checked his blinker fluid. He said he didn't know what blinker fluid was. I told him that blinker fluid sits in a reservoir in the middle of the car, and when you make a turn the fluid flows in the opposite direction of the turn, into the blinkers, to make sure that the electrical connection is good.
He spent 3 hours the next morning, on his day off, calling up parts stores and asking them if they had any blinker fluid. Poor guy. I had to break it to him slowly...
Re:It all depends... (Score:5, Funny)
That's the difference between a natural blonde and a dyed blonde.
Cleanup on aisle 3! (Score:4, Funny)
We were finding the damn things in the ventilators for weeks afterward.
Re:It all depends... (Score:5, Funny)
On early systems, particularly before the 286, the mass differential between 0 and 1 was a serious issue. However, the 286's innovative pipeline system introduced a shift in focus from mass to width. As pipelines became increasingly narrow, words composed primarily of "1"s began to execute at a more rapid pace than those with a heavy weighting of "0"s.
More SCO code. (Score:2, Funny)
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
Re:More SCO code. (Score:5, Funny)
Cool.
Of course, the funny thing is that I'm right (in a way).
architectural differences... (Score:4, Informative)
Re:architectural differences... (Score:2)
Re:architectural differences... (Score:5, Informative)
Probably applicable to the G5 as well (and Alpha, PA-RISC, MIPS), which like the SPARC has pretty much the same architecture for 32 bits and 64 bits.
The Itanic has an IA-32 subsystem hanging on it - performance is really poor compared to the main 64 bit core. The Opteron has more registers available in 64 bit mode than 32 bit mode and should show some performance improvements just for that reason.
As has been said mucho times - 64 bit processors really shine when you have lots of memory to work with. Having said that, one advantage of 64 bits is being able to memory map a large file and can result in better performance even with much less than 4 GB of memory - witness the MySQL tests.
Moving more data (Score:5, Interesting)
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.
Re:Moving more data (Score:4, Insightful)
Re:Moving more data (Score:5, Informative)
By the same token, 32-bit code on systems with 64-bit wide data paths will move twice as many pointers in one bus cycle.
Today's CPUs almost completely decouple buses from ALU-level operations. Buses usually spend most of their time transfering entire cache lines to service cache misses, so if your pointers take up a bigger portion of a cache line, 64-bit code is still consuming more bus clock cycles per instruction on average no matter how wide your buses are.
BTW, 32-bit processors have been using 64-bit external data buses since the days of the Pentium-I.
Re:Moving more data (Score:3, Insightful)
So, memory bandwidth remains an issue, and I concede the point.
Still,
Re:Moving more data (Score:5, Informative)
Modern processors (which actually stretches back at least 10 years) really want to run out of cache as much as possible, both for instruction and data access. And they've never wanted to do it more than now when in the x86 world, the processor core and L1 cache are operating at 3200MHz vs. 400MHz for the RAM.
One thing that has to happen is that you make a bet on locality of execution (again both for instructions and data) and burst load a section of memory into the caches (L2 and L1, and sometimes even L3). In implementation terms, it takes some time to charge up the address bus, so you increase bandwidth and execution speed by charging up address n, but doing a quick read of n+1, n+2, n+3, and more on the latest CPUs. You only have to wiggle the two low-order address lines for the extra reads, so you don't pay the pre-charge penalty that you would for access randomly in memory.
That's good if you're right about locality and bad if you're wrong. That's what predictive branching in the processor and compiler optimizations are all about - tailoring execution to stay in cache as much as possible.
On a 64-bit processor, those burst moves really are twice as big and they really do take longer (the memory technology isn't radically different between 32- and 64-bit architectures, although right now it would be odd to see a cost-cutting memory system on a 64-bit machine). If all the accesses of the burst are actually used in execution, then both systems will show similar performance (the 64-bit will have better performance on things like vector opcodes, but for regular stuff, 1 cycle is 1 cycle). If only half of the bursted data is used, then the higher overhead of the burst will penalize the 64-bit processor.
If you're running a character based benchmark (I've never looked at gzip, but it seems like it must be char based), then it's going to be hard for the 64-bit app and environment to be a win until you figure out some optimization that utilizes the technology. If your benchmark was doing matrix ops on 64-bit ints, then you'll probably find that that Opteron, Itanium, or UltraSparc will be pretty hard to touch.
A hammer isn't the right tool for every job as much as you'd like it to be. I actually think that the cited article was a reasonable practical test of performance, but extrapolating from that would be like commenting on pounding nails with a saw - it's just a somewhat irrelevant measure.
I guess I'm violently agreeing with renehollan's comment about speed bumps - apps that can benefit from an architectural change are as important as more concrete details such as compiler optimizations.
Re:Moving more data (Score:4, Interesting)
In implementation terms, it takes some time to charge up the address bus, so you increase bandwidth and execution speed by charging up address n, but doing a quick read of n+1, n+2, n+3, and more on the latest CPUs. You only have to wiggle the two low-order address lines for the extra reads, so you don't pay the pre-charge penalty that you would for access randomly in memory.
This is incorrect. It has nothing to do with charging the address lines. Loading multiple sequential locations is slow on the first access and fast on the subsequent bytes because a whole memory row (made of multiple words) is read at once. This full memory row (typically around 1kbit) is transferred from the slower capacitive DRAM storage to faster transistor-based flip-flops. The subsequent sequential words are already available in the flip-flops so it's faster to route them off-chip since the slow DRAM access is avoided.
Re:Moving more data (Score:2, Funny)
64-bit computers have to physically move data around? I suppose I'll have to buy a grappling arm attachment for my G5 to get it to work.
Couldn't time fix this? (Score:4, Insightful)
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.
Re:Couldn't time fix this? (Score:4, Informative)
Not just kernels. All programs.. however this happens in the compiler. Or assembly code. Not in "kernels" unless they are assembly code kernels..
Basically this test is moot without using compilers optimized for the 64 bit chips..
--ken
Re:Couldn't time fix this? (Score:3, Informative)
The benefit of a 64 bit processor is a larger address space and the ability to work on 64 bit data types much much faster than on a 32 bit system. More GPRs is an additional, separate benefit.
gcc? (Score:5, Interesting)
Re:gcc? (Score:4, Informative)
And before you start complaining, that comes from 3 years coding for a graphics company where every clock tick counts. We saw a MAJOR (like more than 20%) difference in execution speed of our binaries depending upon which compiler was used.
Hell, gcc didn't even get decent x86 (where x>4) support in a timely manner. Remember pgcc vs. gcc?
Re:gcc? (Score:3, Interesting)
Re:gcc? (Score:3, Insightful)
Actually I wouldn't say that gcc produces particularly bad code on all computers, it's sorta average, but not bad. Certainly the 3.3.x series are alot better than 2. Pretty good at number crunching [randombit.net] and it is more standards compliant than most.
I'll save you guys the read. (Score:2)
Makes me wonder what tricks AMD has managed to pull out of their hat to increase 64 bit performance by 20-30%...
Re:I'll save you guys the read. (Score:2, Funny)
Re:I'll save you guys the read. (Score:4, Funny)
They didn't use an obsolete UltraSparc chip?
Re:I'll save you guys the read. (Score:5, Informative)
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.
How mature are the compilers? (Score:5, Interesting)
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.
Re:How mature are the compilers? (Score:5, Insightful)
If you want FAST code you should use the compiler from your hardware vendor. The downside is that they might cost money, and almost definitly implement things in a slightly weird way. Weird when compared to the official standard, weird when compared to the defacto standard that is GCC.
I though this was common knowladge, at least amongst people who would be trying to benchmark compilers...
Opteron is faster in 64 bit (Score:5, Informative)
Re:Opteron is faster in 64 bit (Score:5, Informative)
And 32 bit is slower than 16 bit (Score:5, Interesting)
I kept the VAX anyway.
Re:And 32 bit is slower than 16 bit (Score:3, Interesting)
Not so simple for AMD64 (Score:4, Interesting)
Re:Not so simple for AMD64 (Score:3, Interesting)
*Stupid freaking AMD engineer made the PDF world accessible but then went and encrypted it so that I can't cut and paste, print it, or do anything with it*
Well basically INT's and LONG's remain 32 bit while Pointers, LONG LONG's and Floats are 64 bit by default.
The paper can be found at AMD's [amd.com]
What I found most remarkable... (Score:3, Interesting)
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...
If 32bit is faster than 64... (Score:5, Funny)
And why stop there?
8bits should really scream.
I can see it now: 2GHz 6502 processors, retro computing. The 70's are back.
Re:If 32bit is faster than 64... (Score:5, Insightful)
Of course, my conceptions back then might be getting a bit dated now. But not too terribly much. 32 bits will probably be the optimum for general use for quite some time. There's not too many applications that need a 64 bit address space. Not too many applications need 64 bit integers. We'll need 64 bit sometime, but I don't see the need for it in *general* purpose computing for the remainder of the decade. (Longhorn might actually need to a 64 bit address space, but that's another story...).
Remembering back to the 80286 days, people were always running up against the 16 bit barrier. It was a pain in the butt. But unless you're running an enterprise database, or performing complex cryptoanalysis, you're probably not running up against the 32 bit barrier.
But of course, given that you're viewed as a dusty relic if you're not using a box with 512Mb video memory and 5.1 audio to calculate your spreadsheets, the market might push us into 64 bit whether we need it or not.
Jebus christ. (Score:2, Informative)
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 [linux.org.uk], 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.
I'd kill for a 64 bit platform... (Score:3, Interesting)
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
More bits doesn't automatically mean more speed (Score:5, Insightful)
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
6502? (Score:4, Interesting)
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.
Let's not do anything like that! (Score:3, Insightful)
Uniform and simple is good...
This guy is a tool (Score:5, Interesting)
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
Re:This guy is a tool (Score:2)
Something is wrong. (Score:5, Interesting)
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.
Re:Something is wrong. (Score:5, Insightful)
It's you.
OpenSSL in the 32-bit environment as the guy configured it was doing 64-bit arithmetic. Just because the guy had 32-bit pointers doesn't mean that his computer wasn't pushing around 64-bit quantities at once. It's called a "long long".
In fact, as he had OpenSSL configured, he was using some crafty assembly code for his 32-bit OpenSSL builds that even used 64-bit registers. His 64-bit builds were using plain old compiled C.
But he didn't even know that.
Big whoop.
Mark
Re:Something is wrong. (Score:3, Informative)
All public key systems currently in use depend on doing arithmetic on large integers. Let's start with the classical algorithms for addition/subtraction/multiplication/division.
The addition and subtraction algorithms are O(N) and multiplication/division is O(N^2), where N is the number of digits.
What is a digit? On a 32-bit process, it will probably be 32 bits. On a 64-bit processor, it will probably be 64-bits.
What this means is that operating on large integers, say, 1024 bits
Anyone ever used WinXP-64bit edition? (Score:4, Interesting)
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.
Re:Anyone ever used WinXP-64bit edition? (Score:5, Insightful)
Forward thinking (Score:5, Interesting)
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.
A Makefile? (Score:3, Interesting)
[...] 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?
Re:A Makefile? (Score:3, Informative)
How many times have we slapped a
This is unfair comparison (Score:3, Insightful)
What 'system of belief' is he following? (Score:5, Insightful)
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.
of course, they are (Score:5, Informative)
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.
Re:of course, they are (Score:4, Interesting)
Most 64/32bit hybrid machines probably just split the arithmatic/logic units in half (just takes a single wire to connect them anyhow). Having an extra ALU around will surely push more 32bit numbers through the pipe. It's not going be as fast as a 64bit optimized application would gain from having the combined operations should it need them though.
I'm beginning to wonder these days how much CPU speed even matters though. We have larger applications that can't fit in cache, page switching from RAM that isn't anywhere near the speeds of the CPU, and hard drives that are only 40MB/s on a good day/sector, with latency averaging around 5-6ms. CPU is the least of my worries. As long as the hard disk is being utilized properly, you'll probably not see significant differences between processor speeds. I'm a firm believer that people think that 500MHz is slow because the hard drive in the machine was too slow. Unless you are running photoshop, SETI, Raytracing, etc., you probably wouldn't notice if I replaced your 3GHz processor with a 1GHz.
Re:of course, they are (Score:4, Informative)
That's an additional reason. There are probably many other places that neither of us has thought of that have been scaled up to make a true 64bit processor and that benefit 32bit applications running on the same hardware in 32 bit mode.
I'm beginning to wonder these days how much CPU speed even matters though.
It matters a great deal for digital photos, graphics, speech, handwriting recognition, imaging, and a lot of other things. And, yes, regular people are using those more and more.
Unless you are running photoshop, SETI, Raytracing, etc., you probably wouldn't notice if I replaced your 3GHz processor with a 1GHz.
You probably would. Try resizing a browser window with "images to fit" selected (default in IE, I believe). Notice how that one megapixel image resizes in real time? CPU-bound functionality has snuck in in lots of places.
There's always a trade-off (Score:5, Insightful)
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
Nit-picking: LD_LIBRARY_PATH vs crle? (Score:4, Interesting)
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?
64Bit will be needed when Solid State memory comes (Score:5, Interesting)
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.
What else is new. This is about scaling (Score:3, Insightful)
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.
Slower? It depends. (Score:5, Informative)
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.
Re:Slower? It depends. (Score:3, Informative)
I think the 20% increased size is the reason for the 20% worse performance, because memory access is often the bottleneck for real-life programs.
This would appear to miss the point... (Score:3, Insightful)
Summary of discussion (Score:3, Informative)
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
sizeof(int) (Score:3, Insightful)
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?
Re:*Why* do I have that feeling... (Score:2)
Re:*Why* do I have that feeling... (Score:4)
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. :)
Re:Of Course They're Going to Be Slower (Score:3, Interesting)
Re:Now I'm confused... (Score:4, Informative)
steve