Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Are 64-bit Binaries Slower than 32-bit Binaries?

michael posted more than 10 years ago | from the glass-half-empty dept.

Software 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."

Sorry! There are no comments related to the filter you selected.

Re: OSNews (5, Funny)

duffbeer703 (177751) | more than 10 years ago | (#8072821)

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.

Re: OSNews (0)

Anonymous Coward | more than 10 years ago | (#8072841)

I beg to differ. OSNews rocks.

The Jeffrey -- since 1979

Re: OSNews (2, Informative)

Ninwa (583633) | more than 10 years ago | (#8072857)

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 ^_^

Re: OSNews (1)

juuri (7678) | more than 10 years ago | (#8072930)

Good luck, you'll need it.

Re: OSNews (-1, Redundant)

kayen_telva (676872) | more than 10 years ago | (#8072915)

i guess i havent realized it yet. it wasnt super deep, but decent. whats the problem again ?

Re: OSNews (4, Insightful)

rainwalker (174354) | more than 10 years ago | (#8072929)

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.

Re: OSNews (3, Insightful)

chunkwhite86 (593696) | more than 10 years ago | (#8073070)

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???

Re: OSNews (2, Informative)

be-fan (61476) | more than 10 years ago | (#8073087)

Because he used the same compiler, in 32-bit and 64-bit mode???

Re: OSNews (2, Interesting)

dant (25668) | more than 10 years ago | (#8073072)

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.

Benchmarks (3, Funny)

Anonymous Coward | more than 10 years ago | (#8072964)

As it needs to be said for any benchmarking story:

There are 3 types lies. Lies. Damned Lies. ...and benchmarks.

Re:Benchmarks (5, Funny)

Frymaster (171343) | more than 10 years ago | (#8073068)

There are 3 types lies. Lies. Damned Lies. ...and benchmarks.

i've got some specint stats that show that damned lies are up to 30% faster.

Re: OSNews (4, Funny)

DNS-and-BIND (461968) | more than 10 years ago | (#8073080)

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".

I read this yesterday. Here's a tip... (0, Interesting)

(1337) God (653941) | more than 10 years ago | (#8072822)

I read this piece yesterday. Here's a tip for those of you who may currently or need to work on building an x86 to x86_64bit cross-compiler under the Linux operating system.

One of my tight friends, Dan Kegel (cute pic of him here [kegel.com] , oh and he works for Google, so he's super-smart and rich! :-*), has something called the CrossTool at http://kegel.com/crosstool [kegel.com] that should be of major help to anyone working with 64-bit Linux systems.

You may even be able to list it as COTS on your project even though it's free as in beer. In any case, I've tried it, it's sweet, you should try it, it works great for what it does, just like most *nix apps. I prefer having one small tool do something really well than one large software package do a bunch of things really crappily.

Anyway, stop by Dan's page and say hi. Tell him I sent ya ;-)

You forgot (-1, Troll)

Bame Flait (672982) | more than 10 years ago | (#8072836)

That we don't care, and that your flagrant homosexuality renders irrelevant anything you could possibly have to say.

Just go bite a pillow and burgle a turd.

Re:You forgot (0, Troll)

larry bagina (561269) | more than 10 years ago | (#8073004)

score 0 insightful? this deserves a +5 at least!

Well, he's not cute.... (1, Interesting)

Anonymous Coward | more than 10 years ago | (#8073048)

but more to the point, why would you advertise your sexuality in a technical post? I mean, if a straight person (and believe me, there is no such thing as "bi", you're either straight, queer, or in denial about being queer) were to post "I love vagina" in every post, you'd rightfully make fun of him.

But we're supposed to care that you consider a man's ass a sexual input? Stop looking for so much attention and lets talk computers.

this is it... (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8072823)

a first post for me...

Re:this is it... (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8073015)

Howard? Howard Dean? Is that you? Yeaaaaahg!!!

I for one... (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#8072824)

welcome our new 64bit overloards

Re:I for one... (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8072839)

Ye gads! If they can't spell, I'm starting a revolution!

First Post for Negroes (-1)

Bame Flait (672982) | more than 10 years ago | (#8072825)

This is a shout-out.

For all the negroes like me who see this, and recognize its first postitude.

RECOGNIZE!

Hey forum-bitch. Your nick is retarded. (-1, Flamebait)

Ayanami Rei (621112) | more than 10 years ago | (#8073003)

::no text, but I'm giving you the finger, how's that for a shout-out?::

It all depends... (5, Funny)

paul248 (536459) | more than 10 years ago | (#8072830)

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.

Re:It all depends... (2, Funny)

Anonymous Coward | more than 10 years ago | (#8072843)

How do you figure? CMOS only uses energy when transitioning between one and zero, when both transistors are in the ohmic region (drawing current). I don't see how 1 is any more heavy than 0.

Re:It all depends... (4, Funny)

Anonymous Coward | more than 10 years ago | (#8072848)

Here on planet Jokeania, we laugh at his statement.

Re:It all depends... (0, Redundant)

jusdisgi (617863) | more than 10 years ago | (#8072860)

OMG

That was funnier than shit. Too bad I ain't got the mod.

It's not Ohmic! (0)

Anonymous Coward | more than 10 years ago | (#8073023)

When you're referring to Metal Oxide Semiconductor Field Effect Transistors, most CMOS circuits use the Ohmic region when at steady state. The saturation region is when it draws current, doh!

Re:It all depends... (2, Funny)

Anonymous Coward | more than 10 years ago | (#8072871)

Pointy haired boss: Dilbert! My laptop is awfully heavy. Is there anything I can do?

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... (1, Funny)

Anonymous Coward | more than 10 years ago | (#8072887)

does that mean you can optimize your code by constantly xoring variables with themselves?

Re:It all depends... (5, Funny)

Uncle Gropey (542219) | more than 10 years ago | (#8073035)

It's not that the 1's are heavier, it's that they tend to snag in the system bus and take longer to travel than the smoother 0's.

Re:It all depends... (2, Funny)

paul248 (536459) | more than 10 years ago | (#8073052)

That's why I modded my CPU to handle 0's and 8's instead. I call it the 8thlon XP.

Re:It all depends... (4, Funny)

Frymaster (171343) | more than 10 years ago | (#8073085)

it's that they tend to snag in the system bus and take longer to travel than the smoother 0's.

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.

Short answer (0, Interesting)

Anonymous Coward | more than 10 years ago | (#8072831)

From reading the article, the answer is: Sometimes, depending.

More SCO code. (2, Funny)

Ken Broadfoot (3675) | more than 10 years ago | (#8072832)

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

Re:More SCO code. (1)

jusdisgi (617863) | more than 10 years ago | (#8072845)

Too bad that's so off-topic; it's funny.

Why don't you pull it out again on a SCO story?

Re:More SCO code. (4, Funny)

jusdisgi (617863) | more than 10 years ago | (#8072888)

Hey...that's funny...I just called a post off-topic that was a direct quote from the artical.

Cool.

Of course, the funny thing is that I'm right (in a way).

Re:More SCO code. (0)

Anonymous Coward | more than 10 years ago | (#8073088)

It seems from the wording of your second post that you modded the parent before you RTFA. Thats classic.

architectural differences... (4, Informative)

jusdisgi (617863) | more than 10 years ago | (#8072833)

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?

Re:architectural differences... (1)

ebbomega (410207) | more than 10 years ago | (#8072967)

Native is a very specific concept actually. If you can take a piece of code in its very base-bones assembler 1s and 0s and put it through a processor and obtain the expected result, it processes that code natively. If not, then it can't. Itanium cannot process 32-bit code natively. It needs an emulator which trades those 1s and 0s to a different format that the itanium can read (thus changing the input to the processor) and then the processor can read it. Obviously emulation would take a lot more clock cycles than native performance, and thus speed is greatly improved when using native processing as opposed to emulated.

Moving more data (4, Interesting)

Sean80 (567340) | more than 10 years ago | (#8072844)

I'm no expert in this specific area, but I remember a conversation from a few years back abour the 32-bit versus the 64-bit version of the Oracle database. The guy I was speaking with was pretty knowledgeable, so I'll take his word as truth for the sake of this post.

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 (3, Insightful)

renehollan (138013) | more than 10 years ago | (#8072883)

*cough* wider data busses *cough*. 'course this does mean that 64 bit code on systems with 32 bit wide data paths will be slower, but, like, migration always involves speed bumps. I remember the a.out to elf transition pain days of Linux.

Re:Moving more data (0)

Anonymous Coward | more than 10 years ago | (#8072944)

when did *coughs* become voluntary?

Re:Moving more data (4, Informative)

Waffle Iron (339739) | more than 10 years ago | (#8072959)

*cough* wider data busses *cough*. 'course this does mean that 64 bit code on systems with 32 bit wide data paths will be slower

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 (1)

starm_ (573321) | more than 10 years ago | (#8073034)

The you should just have 128 bit buses for 64 bit code. and you would get the same performance

Re:Moving more data (2, Funny)

momerath2003 (606823) | more than 10 years ago | (#8072894)

...because otherwise the computer physically has to move twice as much data around for each operation it does.

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. :(

Re:Moving more data (0)

Anonymous Coward | more than 10 years ago | (#8072943)

hehe. pure genius.

Couldn't time fix this? (3, Insightful)

Transcendent (204992) | more than 10 years ago | (#8072846)

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.

Re:Couldn't time fix this? (3, Informative)

Ken Broadfoot (3675) | more than 10 years ago | (#8072889)

"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)."

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? (0)

Anonymous Coward | more than 10 years ago | (#8072897)

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?


Defanitely. real world tests show that hand optimised direct to interger assembly language 64 bit code blowz 32 bit out of the water. Compilers have had now 16 years????? to become optimized for 32 bit access with all kinds of tips and tricks but there is none for 64bit, in fact much 64bit code is still being slowed down by assumptions made by compilers!!!!!!. useing anything but gcc like maybe iBM or iNtels own in house compilers and u will see the diff.

Re:Couldn't time fix this? (0)

Anonymous Coward | more than 10 years ago | (#8073038)

"Increased number of registers" has nothing to do with whether or not a CPU is 32 bit or 64 bit. Register count is a migration issue when you're moving from a crappy register-starved ISA to a less crappy ISA that supports more registers. 32 bit PPC, for example, is not register-starved in the same way as IA32 so register count is irrelevant in moving from 32 bit to 64 bit PPC. Both 32 bit and 64 bit PPC have 32 GPRs.

gcc? (5, Interesting)

PineGreen (446635) | more than 10 years ago | (#8072847)

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...

Re:gcc? (4, Informative)

PatMouser (1692) | more than 10 years ago | (#8073066)

Yup! It turns out poorly optimized code in 32 bit mode and I shudder to think what the 64 bit code would look like.

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?

I'll save you guys the read. (1)

Sj0 (472011) | more than 10 years ago | (#8072861)

Yes they are, but only by about 10-20%.

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. (2, Funny)

archen (447353) | more than 10 years ago | (#8072899)

The same tricks that boost the performance of their CPU model numbers 20-30% over their clockspeed? =P

Re:I'll save you guys the read. (3, Funny)

HardCase (14757) | more than 10 years ago | (#8072908)

Makes me wonder what tricks AMD has managed to pull out of their hat to increase 64 bit performance by 20-30%...


They didn't use an obsolete UltraSparc chip? ;-)

Re:I'll save you guys the read. (4, Informative)

ParisTG (106686) | more than 10 years ago | (#8072912)

Makes me wonder what tricks AMD has managed to pull out of their hat to increase 64 bit performance by 20-30%...

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.

Re:I'll save you guys the read. (1, Informative)

Anonymous Coward | more than 10 years ago | (#8072919)

Makes me wonder what tricks AMD has managed to pull out of their hat to increase 64 bit performance by 20-30%...

No tricks. The benefit doesn't come from 64 bit-ness, it comes from other changes in the ISA when something is compiled in 64-bit mode. There are 8 more GPRs on AMD64 than on IA-32. More registers = less movs to/from cache = faster. Also the integrated memory controller can't hurt. Also it has 8 more SSE2 registers IIRC.

Note that none of these things is tied to AMD64 having 64 bit regs. Course there are plenty of 64-bit benefits too (PK ops like RSA are basically instantly 4 times as fast on 64-bit machines as compared to a 32-bit machine).

How mature are the compilers? (5, Interesting)

Anonymous Coward | more than 10 years ago | (#8072867)

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.

Re:How mature are the compilers? (4, Insightful)

T-Ranger (10520) | more than 10 years ago | (#8073043)

GCC's primary feature is, has always been, and likey will be for a long time: portability. GCC runs on everything.

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...

*Why* do I have that feeling... (-1, Insightful)

inode_buddha (576844) | more than 10 years ago | (#8072869)

that this whole discussion will compare apples and oranges to death? I could make a fruit salad out of these.
Seriously though, there's *so* many other factors involved:

How much cache is ideal for hello.c?
How many branches does it need? Is the prediction worth a shit?
Does hello.c run faster at 2 GHz?

THINK before you post please so my hair doesn't hurt so much... thx.

Re:*Why* do I have that feeling... (0)

Anonymous Coward | more than 10 years ago | (#8072911)

Read the fucking article. He didn't use hello.c for the benchmarking.

Fuck I hate slashdot idiots who complain about people who don't THINK before they post.

Practice what you preach, asshole.

Re:*Why* do I have that feeling... (2)

Drantin (569921) | more than 10 years ago | (#8072984)

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...

Opteron is faster in 64 bit (5, Informative)

citanon (579906) | more than 10 years ago | (#8072874)

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.

Re:Opteron is faster in 64 bit (5, Informative)

fifirebel (137361) | more than 10 years ago | (#8072924)

Also because in 64-bit mode, the Opteron has access to more registers. The IA-32 architecture is so register-limited that throwing more registers at any task makes a huge difference.

And 32 bit is slower than 16 bit (5, Interesting)

gvc (167165) | more than 10 years ago | (#8072877)

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.

Re:And 32 bit is slower than 16 bit (1)

operagost (62405) | more than 10 years ago | (#8072971)

Should have run VMS.

:-P

Re:And 32 bit is slower than 16 bit (1)

BeeazleBub (535448) | more than 10 years ago | (#8072979)

That was also found out for x86 when OS/2 and Win95 (to a lesser extent because of its heavy reliance on 16 bit code in certain places) back in '92/93.

I can still feel the pain from the flame wars. If memory serves it all came down to an issue of compliler and library optimization. Most of the 32 bit code was unoptimized for various reasons which caused wide variances in performance.

Re:And 32 bit is slower than 16 bit (1, Informative)

Anonymous Coward | more than 10 years ago | (#8073030)

Don't forget (ugh) all the additional clock cycles needed for 16:16 and 16:32 bit addressing modes- (which we still have, unless you run an older Novell server which uses flat 32 memory mode.) Also, all the additional clock cycles needed to go from real to protected mode (stupid PC hardware stuff- but only on Windoze platforms) and "thunking"- also only on Windoze.

Yes, I remember the days of the first 386es and how much slower they were! I still have a 286-25 (I think...somewhere...) that kicked 386-33 butts.

Not so simple for AMD64 (3, Interesting)

martinde (137088) | more than 10 years ago | (#8072904)

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.

What I found most remarkable... (3, Interesting)

Grey Ninja (739021) | more than 10 years ago | (#8072906)

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...

If 32bit is faster than 64... (5, Funny)

CatGrep (707480) | more than 10 years ago | (#8072931)

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.

Re:If 32bit is faster than 64... (1)

vrmlknight (309019) | more than 10 years ago | (#8073001)

Actually you are correct a 2GHz 8-Bit processor would scream (for simple math and basic operations) but your limited to 8 bits which makes it tough to do some complex things that and it would be a real pain to write a program that used large/long numbers a lot would need to be swapped around :)

Re:If 32bit is faster than 64... (0)

Anonymous Coward | more than 10 years ago | (#8073045)

Who cares? That's for the compiler to worry about.

Jebus christ. (2, Informative)

eddy (18759) | more than 10 years ago | (#8072934)

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... (3, Interesting)

yecrom2 (461240) | more than 10 years ago | (#8072951)

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.
We tried win2k3 and the /3gb switch, but we kept having very odd things happen.
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 (4, Insightful)

leereyno (32197) | more than 10 years ago | (#8072958)

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

This guy is a tool (4, Interesting)

FunkyMarcus (182120) | more than 10 years ago | (#8072970)

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

Re:This guy is a tool (1)

FunkyMarcus (182120) | more than 10 years ago | (#8072985)

Assembly code vs. C code refers to the big-number library. No substitutions, exchanges, or refunds.

Something is wrong. (5, Interesting)

DarkHelmet (120004) | more than 10 years ago | (#8072972)

Maybe it's me, but how the hell is OpenSSL slower in 64 bit?

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. (4, Insightful)

FunkyMarcus (182120) | more than 10 years ago | (#8073019)

Maybe it's me

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. (0)

Anonymous Coward | more than 10 years ago | (#8073020)

It's probably based on some large integer package that isn't taking advantage of the 64 bits that are available to it... shrug.

Re:Something is wrong. (0)

Anonymous Coward | more than 10 years ago | (#8073040)

ssl also does a lot of character-by-character processing.

Re:Something is wrong. (1, Informative)

Anonymous Coward | more than 10 years ago | (#8073053)

Operations concerning large integers were MADE for 64 bit

How? Explain please. Crytographic algorithms perform logical operations on each individual bit. To set a single bit in a register, you have to do something like:

mov rbx, value // value is 0 or 1
shr rbx, 8 // shift right into bit 8
and rax, ~8 // mask off the target bit 8
or rax, rbx // or value into the register
[perform operation on rax, etc]
Since you're operating on a bitstream - at the bit level - and each bit operation depends on others - my question is: how - in any way, does it matter that rax is 64-bit rather than a 32-bit eax? For simple math, yes, 64-bit will help. For bitwise logic and crypto - no. If anything - besides overflow - a large register size is a hinderance for operations like this.

Re:Something is wrong. (0)

Anonymous Coward | more than 10 years ago | (#8073065)

Or maybe I'm just on crack.

And just how long have you been working for SCO, exactly?

I might test this... (1)

after (669640) | more than 10 years ago | (#8072973)

... one me and a friend get a Sun Ultra (dunno what one yet) in a few days. Hoperfully, we can set up somthing that requires a lot of number cruntching. Perhaps a 64-bit SETI@home, I dunno.

The cool thing is for programmers, is that with the right macros and functions, one can use a single 64-bit integer as (get this!) 2 32-bit integers. This will come in handy for games and sutch where two sets of common numbers are accesed frequently.

Anyone ever used WinXP-64bit edition? (4, Interesting)

CatGrep (707480) | more than 10 years ago | (#8072983)

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.

Re:Anyone ever used WinXP-64bit edition? (0, Flamebait)

Anonymous Coward | more than 10 years ago | (#8073037)

in my opinion, that describes windows XP.

i have never seen a machine running XP with decent performance.

Re:Anyone ever used WinXP-64bit edition? (1)

KewlPC (245768) | more than 10 years ago | (#8073069)

Was WinXP64 specifically optimized for the Itanium? Probably not. The Itanium places a lot of burden on compilers, and Microsoft's compilers probably aren't generating optimal Itanium code yet.

And, of course, if Win64 is running in the Itanium's x86 compatibility mode, then of course it's going to be slower. Intel has advertised from the very beginning that the Itanium's x86 compatibility mode was just to help ease the transition to the Itanium, and has always said that it would run slower than the Itanium's native 64-bit mode.

I'm not a huge fan of the Itanium myself, but please try to get things straight.

Need to host child porn? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8072987)

Need to host child porn?

Retarded article. (1, Insightful)

Anonymous Coward | more than 10 years ago | (#8072994)

Short answer: No.

Medium answer: If you're not a programmer, yes. Expect about the same speed, but maybe slightly less.

Long answer: Direct comparisons like this are in no way valid because the code is identical. It's the same algorithm running at the same clockspeed. Your compiler can't program. Think about this: There's only so much space taken up by a logical operation. The question:

"is this bit set to one? if yes, do this.. if no, do that"

..does not get any faster just because of the size of the register the single bit is contained in. It's still bound by the clockspeed. Programmers can rewrite algorithms to do certain things in parallel, but it's probably not unless it's a big memory operation, multimedia app, game or graphics package. For those it will be much better.

Which is why Intel is more concerned with clockspeed than number of bits.

what a bunch of bullcrap (1, Funny)

Anonymous Coward | more than 10 years ago | (#8073009)

No one had tested it before to my knowledge, so predicting the outcome was impossible.

yes, right. we predict only on things we've seen someone else do in the past.

you've got the right idea, mate...

Hello World As A Benchmark! (0, Offtopic)

PissingInTheWind (573929) | more than 10 years ago | (#8073016)

That has to be the most stupidest compiler test I've ever read.

And it's not the number of bits that is important: it's the size of them.

More info in scoop, please (1)

RyatNrrd (662756) | more than 10 years ago | (#8073017)

The info on the Slashdot page should read more like an abstract or executive summary of the article. What we have here reads much more like an advertisement for an article.

Yeah, I could and should RTFA, but I object to posts on the front page of Slashdot being "teasers" for other people's news sites. The info, please.

Forward thinking (5, Interesting)

Wellmont (737226) | more than 10 years ago | (#8073025)

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.

Of Course They're Going to Be Slower (0, Troll)

GoldMace (315606) | more than 10 years ago | (#8073026)

For the most part, there's little need for the extra bits, so you are just wasting computer time processing unnecessary bits.

Maybe you should all concentrate on making things more efficient, rather than relying on faster processors to make your crappy bloatware look fast.

I don't care if you are from the GPL camp or even Microsoft, everything out there from both camps is bloatware!

Computers in 2004 should actually be faster than computers from 1995. From all I've seen, because of the constant bloatware, this is not even the case, and may actually be the opposite.

Re:Of Course They're Going to Be Slower (2, Interesting)

DeathPenguin (449875) | more than 10 years ago | (#8073074)

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.

A Makefile? (2, Interesting)

PissingInTheWind (573929) | more than 10 years ago | (#8073036)

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?

This is unfair comparison (3, Insightful)

superpulpsicle (533373) | more than 10 years ago | (#8073047)

Why are we comparing mature 32-bit software with 64-bit software in its infancy?

64bit vs 32bit and what that actually means (1, Interesting)

Anonymous Coward | more than 10 years ago | (#8073063)

My understanding of low level languages may not be comprehensive, however I am aware that for (lets use the simplest example I am familiar with) MIPS there are a number of registers for the storing of data that will be 'saved' and returned to the caller function, these registers are commonly known as $S0 - $S7, these registers have to be saved in the subroutine in order not to loose the volatile information stored therein.

for example: ...
sw $T0, 0($S0) ..

having more registers would allow you to bypass this step of writing the data to the mem address of $T0, you could use one of the new registers that are not volatile and store it there, thus removing the need for perhaps 5 instructions at a time on each return from a subroutine alone.

rather than the Store Word instruction (SW) you could just: ..
addi $T1, $ZERO, $S0 ..

which would not be lost in the return to the calling function.

further to this, and i'm not sure that the intel x86 performs the same way, when you wish to load a
large number, i think in MIPS its >8bit into a register (16 bit register size) you have to infact perform TWO operations to load ONE number.

basically you load the first (largest significant bits) first

number = xFFFF FFF0 ..
LUI $T0, xFFFF #load to the upper half of the
# register, because the address
# space only allows for 8 bit size
ADDI $T0, cFFF0 # add the second portion of the
# number. ...

on the basis that x86 shares some of these things, then 64 bit must be faster GIVEN even ground with compilers and so forth, these are assumed (EVEN THO THAT IS NOT THE CASE) because otherwise its all pissing in the wind.

if this has errors, forgive me, this is not my area of specialty by a long stretch.

-Archfile

What 'system of belief' is he following? (4, Insightful)

swordgeek (112599) | more than 10 years ago | (#8073083)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?