2CPU.com » News » March 2005 » 64-bit Computing @ Tech-Report

Scott over at Tech-Report has put together an article discussing 64-bit computing. Is it mostly hype or is it for real?

64-bit computing won't bring us two times the performance in an amazing overnight transformation of the PC, as the move from 8 bits to 16 seemed to do back in the day. But it's not a pointless exercise in shuffling bits, either. The 64-bit extensions to the venerable x86 instruction set architecture (ISA), including AMD64 and Intel's code-compatible EM64T, actually offer some tangible benefits with few drawbacks. These extensions to the x86 ISA offer a much larger memory address space, bring a cleaner programming model with performance benefits, and retain backward compatibility with existing 32-bit applications.

You can read the entire article over here.

03/04/2004 03:04 PM: Intel will outsell AMD 64-bit chips by year end by Jim
The Inquirer has posted about some comments made by Peter Glaskowski, the chief editor of the Microprocessor report. He seems to think that while Intel is definitely playing catch-up with its 64-bit X...

07/07/2002 12:56 AM: Opteron and Itanium: Two Roads to 64-bit Computing by Jim
Ace's Hardware has another interesting article up, this time dealing with AMD's Opteron and Intel's Itanium. Two companies with a different philosophy with respect to 64-bit computing. However, in the...

duraid SMP Qualified Posts: 387 Joined: 2002-03-31

#35372 Posted on: 03/23/2005 10:27 PM cleaner programming model my ass. that's like going to a waste recylcing plant with a feather duster, brushing up a couple of machines and going "there, i made it cleaner!!" **** that for a joke. x86 is messy, and x86-64 is SLIGHTLY better.

rmn oh my, it's huge! Posts: 6013 Joined: 2002-01-26

#35373 Posted on: 03/23/2005 11:24 PM The human brain is terribly messy, but it can do some pretty amazing things (some are more amazing than others). Genetic algorithms are terribly messy, but they have solved some very complex problems in far more efficient ways than "elegant" code ever could. Elegance isn't everything, and the fact that several people who are not "locked" into x86 due to software support (and who will, in fact, be developing the software themselves) still choose x86 shows that a) developing for x86 isn't that unpleasant and b) the performance / cost / whatever gains more than make up for the architecture's lack of elegance. I've programmed in x86 assembly myself, for several years, and I survived more or less unharmed. As Linus Torvalds wrote, if you take a very neat, very elegant architecture, and start optimising it for the real world, you might end up with something very similar to x86: http://www.ussg.iu.edu/hypermail/linux/kernel/0302.2/1909.html RMN ~~~

Mr Bill two by two, hands of blue Posts: 2946 Joined: 2002-02-16

#35374 Posted on: 03/24/2005 12:00 AM Agree with RMN. Maybe a purist would want to get the algorithmically simplest (most orthogonal) instruction set but having some specialized functions done in hardware can be an advantage. Soul of a New Machine by Tracy Kidder is a great read. P.S. Tech Report is my favorite review site. Edit: spelling;) My SMP rig [URL="http://personal.palouse.net/billshan/ghost.htm#A_Merlin"]Merlin[/URL]

Glock Glock Operator Posts: 205 Joined: 2001-06-13

#35375 Posted on: 03/24/2005 12:07 AM 64 bit computing is already there where it's actually needed (datacenter/data-mining/viz). But sooner of later some power app or candy OS will require something over 4GB RAM to function at optimum efficiency, and thanks to AMD's Opteron/AthlonFX, most of (if not all) the neccessary groundwork will have already been done (by this I mean affordable boxes, not uber-expensive Sun boxes). For the office or home user, however, I think that what's needed more is (now we're talking about optimizing) a new pre-boot architecture, aka BIOS. These dinosaurs need to undergo a major ELE (Extinction Level Event) and be replaced by a more sleek and sexy system. Even if you don't mind the DOS-look (come on), it still smells legacy all over the place. I'm sure start-up times could be improved upon, amongst many things (better pre-os support for modern day pheripherals, RAID,...). Maybe I'm rambling, but somehow it isn't very sexy when you turn on (no pun intended) your new dual Opteron or multi-core Intel EM64T system and see a screen similar to a Radio Shack TRS-80 system and see every card take minutes to complete a pre-flight check. Question: couldn't the initialisation-sequences of the gfx, scsi, raid and maybe other components be made to run in separate threads, so they happen simultaneously? Just an idea... "What is understood, need not to be discussed..." Loren Adams

duraid SMP Qualified Posts: 387 Joined: 2002-03-31

#35376 Posted on: 03/24/2005 01:41 AM Originally posted by Glock For the office or home user, however, I think that what's needed more is (now we're talking about optimizing) a new pre-boot architecture, aka BIOS. These dinosaurs need to undergo a major ELE (Extinction Level Event) and be replaced by a more sleek and sexy system. But why?? Elegance isn't everything, and the fact that several companies who are not "locked" into using normal PC BIOSes due to software support (and who won't, in fact, be developing the software themselves) still choose normal PC BIOSes shows that a) the PC BIOS isn't that unpleasant and b) the performance / cost / whatever gains more than make up for its lack of elegance. *rolls eyes*

duraid SMP Qualified Posts: 387 Joined: 2002-03-31

#35377 Posted on: 03/24/2005 01:43 AM Originally posted by Glock Question: couldn't the initialisation-sequences of the gfx, scsi, raid and maybe other components be made to run in separate threads, so they happen simultaneously? Just an idea... Go buy yourself an Itanium box, because I guarantee you this won't be coming to an x86 system any time soon. Remember, legacy support comes first!!!

duraid SMP Qualified Posts: 387 Joined: 2002-03-31

#35378 Posted on: 03/24/2005 02:19 AM Originally posted by rmn The human brain is terribly messy, but it can do some pretty amazing things (some are more amazing than others). I don't see your point. Do you even have one? Surely you're not trying to compare the product of millions of years of evolution on something the size of the planet with the PC BIOS, which is the product of some dumbass 20 years ago bending over and enjoying some deep anal lovin' from bill gates because poor bill was having a hard time making his amazing CP/M ripoff boot properly. Genetic algorithms are terribly messy, but they have solved some very complex problems in far more efficient ways than "elegant" code ever could. Again, I don't see your point. Genetic algorithms aren't messy, they're actually the one of the _simplest_ optimization methods around. The _solutions_ they produce might be messy, but that's ******* exactly what we have here. Or are you suggesting that more-or-less random searching is the right way to design computer bootstrap systems? Elegance isn't everything, and the fact that several people who are not "locked" into x86 due to software support (and who will, in fact, be developing the software themselves) still choose x86 shows that a) developing for x86 isn't that unpleasant and b) the performance / cost / whatever gains more than make up for the architecture's lack of elegance. What a pile of crap. People choose x86 for two reasons: 1) they're not trying to do anything ambitious with their computer 2) it's dirt cheap ...and these two often go together. If you don't need an amazing computer, why not get the cheapest one that does the job? Surely this is how 90% of personal computer purchases are made today. Why do you think Intel more or less owns the CPU market? Because their x86 CPUs are amazingly good, or because they're good enough, and damn cheap? Can you say "Dell"? I've programmed in x86 assembly myself, for several years, and I survived more or less unharmed. This is a real shame actually. If writing x86 assembly started killing people, the world would probably end up a cleaner place in the long run. As Linus Torvalds wrote, if you take a very neat, very elegant architecture, and start optimising it for the real world, you might end up with something very similar to x86: OK, Linus is not a CPU architect, and it shows in that post you linked to. I think he's starting to learn that IA64 is worthy of respect, now that IA64 hackers totally dominate Linux scalability development. But forgetting that, he makes only a few concrete points. For example: 1) He thinks that x86 instruction encoding helps you "win on icache". This is true, but totally misguided. icache is the simplest part of a CPU to design, and the gaps in speed, density and power consumption between icache instruction decode stages will only widen with time, as wire delay becomes a bigger and bigger problem. 2) He thinks that having a tiny number of registers "isn't an issue", and that x86 compiler developers have been able to work around it. Well this is ******** nice and simple, all you have to do is use GCC or the Intel C/C++ compiler on an x86-64 system to see that simply doubling the tiny number of registers instantly buys you an extra 5-15% performance boost on almost everything, for a tiny increase in transistor count. Look, Linus is a programmer, and a decent one. It ends there. He doesn't even have a PhD, let alone a CPU design under his belt. If you hate Intel/IA64/whatever with such a passion, why don't you listen to what AMD engineers have to say about IA64. I think you'll find some of that online if you dig deep enough, and they are far more qualified to comment on various processor architectures than people like Linus.

Murdock Captain Posts: 1398 Joined: 2001-07-02

#35379 Posted on: 03/24/2005 03:39 AM Originally posted by duraid I don't see your point. Do you even have one? Pot??? Kettle??? Black??? Remind me again, what was your point? Tell me again, why I should value your opinion over Linus Torvalds on this matter? Torvalds: Started a CPU company. duraid: Had a really really really really really really really really really really really really really really really really really really really really really really really really really really good experiance with his Itanium box. Well, judging by the number of "reallys" it's clear who is more qualified. :rolleyes: :rolleyes: :rolleyes: The pathetic state of our government will never change unless we stop electing politicians and start electing public servants. Remember: There was once a time when the term "politician" had a very negative connotation.

sjerra Registered User Posts: 171 Joined: 2003-12-13

#35380 Posted on: 03/24/2005 04:35 AM Well, I do follow duraid on the register count. I read the Linus post (interesting read rmn) and he minimalised the lack of registers by praising the better job of the developers. That by itself does not justify nor reduces the importance of the low number. Other then that, Duraid, be carefull when you throw in PhD's as a measure of someones competence. While obtaining a PhD might indicate a certain level of competence. The other way around doesn't indicate jack shit. It is as if x86 is finally maturing. We can only praise that. It's about time! sjerra

rmn oh my, it's huge! Posts: 6013 Joined: 2002-01-26

#35381 Posted on: 03/24/2005 05:22 AM I would just like to take this opportunity to point out that the Amiga will rule the world. RMN ~~~

i_wolf labhair dom as gaelige Posts: 2097 Joined: 2002-11-19

#35382 Posted on: 03/24/2005 06:37 AM Personally I am no big fan of either the x86 or x86-64 ISA. Again as sjerra and duraid alluded to, I don't like the limited number of visible general purpose registers. Furthermore, I like the idea of a fixed instruction size with ISA's like Power and PowerPC as opposed to variable length x86 instructions.... However while architectures like Power (and PowerPC), PA-RISC , IA64 etc... have reduced the complexity of their silicon and done some ingeniously clever things with their respective silicon it would be wrong to assume that they are less messy than x86... Personally I believe the 'messiness' has just moved some place else. In the case of most of the architectures I have mentioned, while architecturally advanced and providing many more registers to the developer than x86, they place a far greater onus on the compiler and software developer than say the x86 ISA would. For example the Power ISA allows for great flexability in the implementation of that ISA. Recent implementations however have deviated massively from prior implementations (e.g. instruction grouping/packaging in Power 4 and up) meaning that older 'optimized' compilers are in no way optimized for recent implementations. These same newer elaborate designs have meant that the compiler writer needs not just improve the backend for a new Power implementation but also must improve the front end as well. This places huge burden on the compiler developer. The IA64 is also heavily dependent on the compiler developer. @RMN: The Atari ST will rule the world. Hung like a donkey. Go like a horse!

satori I love bears, in leather. Posts: 468 Joined: 2003-11-30

#35383 Posted on: 03/24/2005 07:16 AM Originally posted by i_wolf @RMN: The Atari ST will rule the world. Never! My Intellivision is ruling the world as we speak. How do I know? Last time I was at the parents, it told me so (I have B-17 Bomber, not Bomb Squad) Being happy is not a part time job.

Glock Glock Operator Posts: 205 Joined: 2001-06-13

#35384 Posted on: 03/24/2005 07:21 AM Originally posted by rmn I would just like to take this opportunity to point out that the Amiga will rule the world. RMN ~~~ ROTFLMAO... Excellent comeback rmn... Priceless... You got them all with a single sentence! Now that is a true sign of class! "What is understood, need not to be discussed..." Loren Adams

XWRed1 Registered User Posts: 185 Joined: 2001-08-27

#35385 Posted on: 03/24/2005 03:42 PM Torvalds: Started a CPU company. What company would that be? He only worked there as an employee, and he worked on software stuff.

Krogoth255 Registered User Posts: 30 Joined: 2004-02-09

#35386 Posted on: 03/24/2005 10:50 PM The real reasons why x86 is still even around despite, the availability of techincally superior architechs. x86 still has the largest software library of all the CPU architechs out there. It's all because 90% of all mainstream systems are based on x86 architech on some shape or form. The cost of switching the entire x86 intrastructure (programmers, new systems, recompling older apps) for the sake of utillizing a superior architech still outweights any of its potental benefits. Barton 2800@2083 Mhz, ASUS A7N8X 1.4, RADEON 9700 PRO, 3x256MB Corsair PC3200, 5 ATA HDDs=540GBs, LTR-107T LTR-52327S, PX-708A ,TBSC, Logitech Z5500 and Fortron 530W

rmn oh my, it's huge! Posts: 6013 Joined: 2002-01-26

#35387 Posted on: 03/24/2005 11:40 PM From the point of view of someone that wants to get some actual work done (as opposed to masturbate looking at the specifications), a "superior architecture" is one that does the job faster, or cheaper, or both. There are lots of render farms, clusters, etc., where the software was multi-platform (or even developed from the ground up for that cluster), that are still based on x86 or AMD64. It doesn't really matter if CPU X is 50% faster "per cycle" than CPU Y when CPU Y runs at a clock speed 3 times higher. And it matters even less that CPU Z "could be 100% faster if the compilers were better". It doesn't matter if the Amiga "should" have ruled the world. It didn't. People who said it would were wrong. And maybe (just maybe) it wasn't everyone else that was stupid, maybe it was the Amiga zealots that were so busy spreading the gospel that they didn't see the train coming (and running over them, and speeding away). This doesn't mean x86 is the best architecture for every situation, but to dismiss it as being around only due to legacy software support is silly. And it's even siller to dismiss it for pseudo-aesthetic reasons ("well, it is 40% faster, but those variable-length instructions clash with my curtains"). I find that most people who complain about how "ugly" the x86 architecture is have never programmed in assembly, in any architecture. RMN ~~~

AssKoala Anti-Zealot @ GATech Posts: 3309 Joined: 2002-01-02

#35388 Posted on: 03/25/2005 01:48 AM Originally posted by rmn From the point of view of someone that wants to get some actual work done (as opposed to masturbate looking at the specifications), a "superior architecture" is one that does the job faster, or cheaper, or both. RMN ~~~ Amen to all that. Me Webpage | If you always think like an expert, you'll always be a beginner. | "A handful of knowledgeable people is more effective than an army of fools" -Writing Secure Code, 2nd Ed.

jrv-austin Registered User Posts: 257 Joined: 2004-01-19

#35389 Posted on: 03/25/2005 09:33 AM Originally posted by Glock I think that what's needed more is (now we're talking about optimizing) a new pre-boot architecture, aka BIOS. These dinosaurs need to undergo a major ELE (Extinction Level Event) and be replaced by a more sleek and sexy system. You need to keep in mind what the point of a BIOS is: to boot the OS. A BIOS has not been used by any OS run-time for many years, not since the Win9x family. If you want more BIOS you need merely look no further than the EFI proposal, which essentially puts DOS in ROM. It's been universally panned by everyone in the industry I'm aware of, except the independent BIOS vendors who see it as a new source of revenue. In recent years BIOS vendors have in fact added support for booting devices without option ROMs such as USB. Question: couldn't the initialisation-sequences of the gfx, scsi, raid and maybe other components be made to run in separate threads, so they happen simultaneously? Just an idea... To some extent that already happens: parts of Dell's BIOS POST (some keyboard, floppy, IDE hard disk) are initialized by threads that run in parallel with bulk memory initialization. This has been true for a dozen years or so. For the most part POST itself is fairly quick and limited by how fast the other hardware comes up. Hard disks, for example, often cannot be configured until after they've spun up since the drive's run-time firmware may be on the disk, and POST has little choice but to wait. Other hardware fequently has POR restrictions that must be obeyed (PCI cards may not respond right away, DRAM may not exit test mode for a few milliseconds, etc). Tyan K8W S2885, 2x Opteron 248, 8GB ECC DDR400, 3ware 8506-8 mirrored 2x Raptor 74, 2x 7k250 HP zx6000 1x 1.5 GHz 6MB Itanic2

scheme SMP user Posts: 259 Joined: 2002-01-18

#35390 Posted on: 03/25/2005 10:22 AM Originally posted by jrv-austin For the most part POST itself is fairly quick and limited by how fast the other hardware comes up. Hard disks, for example, often cannot be configured until after they've spun up since the drive's run-time firmware may be on the disk, and POST has little choice but to wait. Other hardware fequently has POR restrictions that must be obeyed (PCI cards may not respond right away, DRAM may not exit test mode for a few milliseconds, etc). Even more than that, a multi-threaded POST initialization adds a bunch of complexity to initialization and error handling and recovery. It's simply easier to deal with unexpected conditions and errors when you're only dealing with one thing at a time. I don't think that bios manufacturers are going to put much effort into something like a multi-threaded initialization if it's only going to shave a second off the initlization time. I would prefer that bios manufacturers added something like the open firmware bios over a multi-threading the initialization. The open firmware stuff would be very useful in recovering, troubleshooting, or configuring the system.

duraid SMP Qualified Posts: 387 Joined: 2002-03-31

#35391 Posted on: 03/25/2005 07:33 PM Originally posted by AssKoala Amen to all that. I'm telling you guys, Taiwan is where it's at. The food's great too!

duraid SMP Qualified Posts: 387 Joined: 2002-03-31

#35392 Posted on: 03/25/2005 08:14 PM Originally posted by rmn This doesn't mean x86 is the best architecture for every situation, but to dismiss it as being around only due to legacy software support is silly. And it's even siller to dismiss it for pseudo-aesthetic reasons ("well, it is 40% faster, but those variable-length instructions clash with my curtains"). RMN, can you put the pills down and come back to reality for a minute? You seem to think that x86 is the epitome of pragmatism: it might not be the best, but it's very well refined and it works very well, and it's cheap! Did you fail to notice that AMD released the K8 core at 1.8GHz, and two years later the maximum clock speed has grown only 44%, to 2.6GHz? Two years? 44%? That's not like the good old days, is it. OK, don't get me wrong, I'm not saying that the Pentium 4 or Pentium M have done any better, but Itanium (and even POWER) certainly has. In the same two years ia64 has gone from 1.0 to 1.7GHz. Shifting things ahead one year you'd see a boost from 1.5 to 2.5GHz. Itanium is simply outpacing K8 in terms of clockrate growth, but that's not surprising - the architecture is simpler, so the core ends up simpler too. I don't know what your little rant about clockrate/IPC is about. Obviously performance is the product of these, and IA64 parts are fast enough to beat everything else on FP, end of story. On integer, they're competitive with the very fastest that Intel and AMD have to offer, sometimes beating them by huge margins (tried AES encrypting data on Itanium 2? It's four times faster clock per clock than K8. You heard right, four times.) Even using boring old compilers that have been around for five years now (e.g. HP C), Itanium "Montecito" will match or beat the fastest K8 available at the time on integer, and I'm happy to put a friendly $20 bet on that if you'd like. I find that most people who complain about how "ugly" the x86 architecture is have never programmed in assembly, in any architecture. If you don't have a problem with x86 assembly then that's good for you, but if you have the time to spare, get into IA64 assembly - it's so simple, you'll like it! Getting performance is challenging but you can do it (it's like finishing 10 rounds of tetris basically), and when you do it's often a BIG reward. None of this "i rewrote the whole routine in assembly just to get an extra 8%" like you have with x86.

duraid SMP Qualified Posts: 387 Joined: 2002-03-31

#35393 Posted on: 03/25/2005 08:18 PM Originally posted by Murdock Torvalds: Started a CPU company. When Linus Torvalds was in the alps, fighting grizzly bears, he used his magical fire breath and saved the maidens fair!!! When Linus Torvalds travelled in time to the year 3010, he fought the evil robot king and saved us all again. And when Linus Torvalds built the pyramids, he beat up Kubla Khan, because Linus Torvalds doesn't take shit from a-n-y-b-o-d-y---!!!

i_wolf labhair dom as gaelige Posts: 2097 Joined: 2002-11-19

#35394 Posted on: 03/26/2005 02:22 AM Just a point of note. Writing in assembly for any architecture is somewhat a pain in the arse.... assembly is often used as a last resort by software houses for parts of code that are extremely performance critical and for which there is no other viable option to eek out that extra performance. The reason for this is maintainability.... assembly is far more difficult to maintain than a HLL. Furthermore portability is hampered when you introduce assembly. This is not to knock your point duraid that x86 assembly is far more difficult to write than ia64 or power assembly (it is more messy/difficult); but with such advanced and modern compilers for the x86 platform, it doesn't really matter too much to the x86 platform if its assembly is more messy to write than IA64 or Power. In a lot of cases there really isn't any need to delve into assembly on the x86 platform, compiler support is very good on that platform in the first place. Did you fail to notice that AMD released the K8 core at 1.8GHz, and two years later the maximum clock speed has grown only 44%, to 2.6GHz? To be honest x86 architectures have not been alone hitting invisible ceilings in the past two years with regard to scaling. IBM ran into problems with its Power 4 and PPC970 derived parts. The PPC970 was introduced at 1.6GHz -> 2GHz almost two years ago and today is still sitting at 2.5GHz (with no visible improvement in clock speed for almost a year). That was merely a 25% increase in clock speed for a year (2Ghz -> 2.5Ghz). The Power 4 didn't do much better. The Power 5 clocks between 1.6GHz and 1.9Ghz. I think most processor manufacturers (including Intel with their Itanium) have decided that performance does not merely need to be measured vertically (with frequency scalling) but by improving IPC and techniques such as multiple cores etc... So it would look like frequency scaling is not a problem solely limited to x86 architectures. Hung like a donkey. Go like a horse!

AssKoala Anti-Zealot @ GATech Posts: 3309 Joined: 2002-01-02

#35395 Posted on: 03/26/2005 02:42 AM Originally posted by duraid It's four times faster clock per clock than K8. You heard right, four times. I realize the futility of discussing anything with you, but you do realize that you increase the validity of rmn's post with the italicized area I quoted from you? Who gives a damn what clock-to-clock gives you if the "lesser" worker per clock is running more clocks per second. Me Webpage | If you always think like an expert, you'll always be a beginner. | "A handful of knowledgeable people is more effective than an army of fools" -Writing Secure Code, 2nd Ed.

tfp Embedded C Lackey Posts: 340 Joined: 2002-09-22

#35396 Posted on: 03/26/2005 04:08 AM Well that is only a valid argument if the other chip is running 4 times faster then his Itanium Writing the code that breaks your hardware...

2CPU.com » News » March 2005 » 64-bit Computing @ Tech-Report