Will Intel Ship an x86-64bit Chip This Year?

Solid Paradox writes "According to The Register, American Technology Research predicts an x86-64-bit processor will 'soon' arrive from Intel and in another story, they also predict that Sun and IBM will be the major players in the future 64-bit boom. Meanwhile the Inquirer has a somewhat related article entitled Senior Intel PR man talks 64-bit extension talk, which follows their Pentium V will launch with 64-bit Windows Elements article that says that the chip is to be sampled internally this month."

Comments

Itanium

[Anonymous Coward]

Isnt Itanium a x86-64-bit processor?

Re:Itanium

[urmensch]

No, It is a new arch (Intel Architexture, IA64) - That's one of the big deals about the AMD 64 bit chip, it is x86 compatible.

Re:Itanium

[arvindn]

Elaborating slightly on this, the Itanium is a "VLIW" chip, which is a wholly different way of doing computation compared to the more usual "superscalar" paradigm. That's why it wasn't compatible with the x86, that's why they targeted it at servers doing heavy computation etc. The AMD chip, on the other hand, can support x86 relatively easily by including a "morphing layer" (I think that's the name) which maps x86 instructions to the native instructions of the chip. So they're able to target desktops.

Re:Itanium

[John Courtland]

They've been doing the microcode thing for a while, at least since the original Athlons. They made a RISC-chip, and decoded complex instructions on the fly into a RISC architecture.

Re:Itanium

[oldmanmtn]

The AMD chip, on the other hand, can support x86 relatively easily by including a "morphing layer" (I think that's the name) which maps x86 instructions to the native instructions of the chip

This is only correct if you consider microcode to be the "native instructions" on AMD. Itanic introduced a whole new ISA, which I guess requires some kind of 'morphing to support x86. Opteron uses the existing x86 ISA with a small number of 64-bit extensions. So, x86 is the "native instruction" set for the AMD CPUs, which allows for much better performance of current 32-bit applications.

Re:Itanium

[bhtooefr]

The RISC architechture dates back to the NexGen 5x86 (a fourth-generation (486) code, sixth-generation architecture CPU). AMD developed the K5, another RISC-based x86, that was 5th-gen code, 6th-gen arch, and then they bought out NexGen and used their in-development NexGen 6x86 (5.5code/6arch) to make the AMD K6 line. The Pentium Pro was the first fully sixth generation (6th code/6th arch) processor. All P6 (PPro, P2, P3, PM, some Celerons, some Xeons) or NetBurst (P4, some Celerons, some Xeons) cored Intel CPUs are RISC internally. All K series (K5, K6, Athlon/Duron, Opteron) AMDs are RISC cored.

Re:Itanium

[Your Anus]

So, will the Intel x86-64 use the same instructions as the AMD x86-64, or is this still the Yamhill thing?

Re:Itanium

[Bun]

Isn't Itanium a x86-64-bit processor?

"No, It is a new arch (Intel Architexture, IA64) - That's one of the big deals about the AMD 64 bit chip, it is x86 compatible."

Slight correction: Itanium's achictecture, IA64 is in fact a fully 64-bit architecture that is incompatible with IA32 (x86). Others have commented on the VLIW architecture, how this puts the onus on the compiler, etc., so I won't get into this.

Re:Itanium

[Truekaiser]

last time i checked it doesn't have hardware compatablitly for 32 bit.

Re:Itanium

[urmensch]

the AMD chip? I'm pretty sure it does.

Re:Itanium

[urmensch]

No, It is a new arch (Intel Architexture, IA64) - That's one of the big deals about the AMD 64 bit chip, it is x86 compatible.

Isn't that what I wrote?

Re:Itanium

[Truekaiser]

Itanium is intels chip. clawhammer/sledgehammer is amd's

Re:Itanium

[urmensch]

You are correct, however, let me clarify.

This is what the AC asked.
Isnt Itanium a x86-64-bit processor?

And this was my response.
No, It is a new arch (Intel Architexture, IA64) - That's one of the big deals about the AMD 64 bit chip, it is x86 compatible.

How is that any different then the following? or from what you wrote:
Itanium is intels chip. clawhammer/sledgehammer is amd's

Itanium is not a x86-64bit processor and it is not compatible with IA32/x86. This is what makes AMD's chip a potentially big deal in the desktop market.

God, I hope this makes sense, otherwise I must be b0rked.;)

Re:Itanium

[Bun]

Isn't Itanium a x86-64-bit processor?

"No, It is a new arch (Intel Architexture, IA64) - That's one of the big deals about the AMD 64 bit chip, it is x86 compatible."

[my note]

"Isn't that what I wrote?"

I guess. The first time I read it, though, the 'no' seemed to say that IA64 wasn't a 64-bit architecture. Clearly, I read it wrong. My bad.

Pentium V

[GameGod0]

Quoted from the article:
"The Pentium V is likely to fly along at between 5GHz to 7GHz, have 2MB plus of level two cache, be built on a 90 nanometer process, and have a stackable design." So, you'll have a 64-bit module sitting on top of your 32-bit CPU?
Sounds like Sega's 32X to me... except it'll play Doom 1 faster.

Re:Pentium V

[builderbob_nz]

64 bit on 32 bit, sounds similar to the old 32 bit API/overlay systems for running DOS games. Makes me wonder how much of a mess this will make of the instruction set.

Re:Pentium V

[Crypto Gnome]

And like most other good Vs (eg V8 and to some extent V6) it'll cost more than most people are prepared to pay.

Especially considering that to date the HUMONGOUS push by Intel to rev up dem CPUs hase done nothing more than prove beyond any shadow of unertainty that high-RPM engines do not necessarily give the best performance.

Anyone here old enough to remember the trend towards "turbo charged" engines not so long ago? How many of them are still around?

Re:Pentium V

[Anonymous Coward]

Turbo charged engines are very much alive. Almost every diesel engine has a turbo.

Re:Pentium V

[JanneM]

Turbos? Yes, they're around, and quite common too. Difference is, they're not pushed as some kind of macho add-on anymore; instead, the technology is mainly used to improve efficiency (by, among other things, improving accelleration so you can use a smaller, more efficient engine and retain the performance you want). And among small diesels (common in Europe), I'd say turbo diesels are a lot more common than the non-turbocharged variety.

Re:Pentium V

[vpscolo]

and the 32x only had about 6 decent games in its entire life Rus

Re:Pentium V

[swordboy]

So, you'll have a 64-bit module sitting on top of your 32-bit CPU?

I've been speculating (here and elsewhere) that this stackable thing is not going to be Intel's next big thing. I believe that the stacked module will simply contain NVRAM and not a 64-bit coprocessor. Why NVRAM? Well, it opens up some interesting possibilities. For example, if you had enough NVRAM on-chip (or reasonably close in terms of latentcy and bandwidth), you could simply shut down portions of the processor on-the-fly to save power. You could also stick the entire operating system on the stuff. The possibilities are amazing. If you haven't looked already, see my journal for much information on the subject as it relates to Intel.

Of recent interest are some presentations by Intel on NVRAM. Of interest is that they've announced that they've found that OUM will take them beyond transistors in one presentation while another presentation actually shows a transistorless cell that is quite simple (two electrodes and a programming material sandwiched in between).

A transistorless storage device could be the piece that stacks onto the P5.

Re:Pentium V

[ThogScully]

Saabs are all turbocharged. Subaru's got a few (WRX, STi) and Mitsubishi's got the Evolution. Mazdaspeed's Protege is turbocharged. And nearly every deisel on the road is turbocharged.

Considering that the Evo and STi are two of the best performing cars available in the US right now, it may be time for you to consider changing your attitude and paying attention to what's under the hood.
-N

Re:Pentium V

[Anonymous Coward]

Except the 32bit api/overlay system you speak of was actually a loader which put the processor into 32 bit protected mode and setup a nice playing environment for applications instead of having to roll your own implementation each time. If 64bit mode on the new x86 chips is enabled similiar to how 32bit mode is enabled currently then there is no need to care. Remember when NT4/Win95 came out dos4gw became a thing of the past...

Re:Pentium V

[doubleyewdee]

And like the 32X nobody is going to be interested. Either people will buy the 32-bit unstacked version and never change it (but if Windows 64 shows up in 2004, why bother with 32 bits?) or you'll have to buy the pre-stacked system, which will almost certainly cost significantly more than a single-chip AMD x86-64 solution.

I remember in the early 90s the crud you could buy to turn your 486/33 into a 486/66 DX2 processor. Even then these products were not wildly popular, and at that time it was significantly more expensive to do anything else (and there was no real x86 competition). These days, such a product would doubtlessly be unpopular. Hobbyists will know better, and general consumers are sometimes afraid to even look at the back of their computer, let alone open it up and pop something onto their CPUs.

If Intel is really doing this 'add-on' stuff, I think they're going to end up getting hurt in a pretty significant way unless they can keep cost down on the add-on components. Even then it seems like useless complexity, a hesitation to commit to a standard that may well cost them big.

Re:Pentium V

[digitalunity]

Yes, but out of the two options, turbocharging is always preferable. High cylinder pressures from turbos are more tolerable with current manufacturing methods than are high rpms. They are an excellent compromise between fuel efficiency and maximum output.

Re:Pentium V

[bmajik]

uh.. you might want to stick to talking about computers. because im not sure you know wtf you're talking about when it comes to cars.

let me give you some basics:

an engine is an air pump. the more air you send through it in unit time, the more power it makes.

a great way to get more air into an engine is with forced induction. turbocharging is one route to acheive forced induction.

where are the turbo cars indeed ?
- subaru WRX
- lancer evo 8
- Audi RS6
- Dodge SRT-4
- Porsche 996TT

these are some of the fastest cars you can buy, each in their own respective price bracket.

there were some early reliability concerns with turbocharging because people forgot that americans are stupid and do things like not change their oil or keep running the car even though its obviously over heating. this would often lead to oil coking in the turbine and eventual bearing failure, causing turbos to wear out.

incidentally, replacing a turbine is a pretty common modification, and an easy way to extract more power from an engine (when part of a well thought out systems engineering approach that has the appropriate modifiactinos in inductino and exhaust to support the new turbine and keep it in its ideal efficiency range for the cfm/boost desired)

so, turbo charging is alive and well, some of the worlds most exciting cars are benefitting from it.

but some of the worlds most mundane, reliable cars are as well. turbo deisel engines are incredibly common and reliable in the fleet industry. ford has some 7+ liters turbo deisel truck motors that go hundreds of thousands of miles with only regular maintenance. and turbo diesel cars are huge in europe where diesel is cheaper and more energy efficient (and cleaner) then it is here... VW is introducing more TDI engined models this year infact. many of them make twice as much peak torque as naturally aspirated motors with similar displacement.

high RPM engines are also wildly successful in racing. They DO give the best performance. It's easy to see why:

SAE horsepower = (Torque (ft/lbs) * RPM) / 5252

in other words, the more revs you make, the more horsepower you'll produce. As long as your rpms are climbing faster than the non-constant torque curve is decreasing, you want to continue to rev higher.

This is why the BMW-Williams P82 Formula 1 motor redlines at slightly north if 19,000 RPM. It's a 3 liter V10 naturally aspirated motor making in excess of 900 horsepower. It isn't making as much torque but doesn't need to - only about 280ft/lbs or so.. because the car its installed in weighs bout 1000lbs. High-RPM high horsepower cars are the most performant in typical tarmac racing because you can take advantage of aggressive, torque multiplying gear ratios.

Incidentally, thats still more torque than most of the motors driving 3000+ lb street cars are producing.

Re:Pentium V

[John Courtland]

Horsepower really doesn't matter, because at 7000 RPM's, your torque band is probably on a sharp decline, yet your horsepower numbers are higher because you are at a high RPM (HP = (tq * RPM)/5252). If you look at the very powerful, twin-turboed Toyota Supra, you'll see gobs of peak horsepower, but the torque band looks like a mountain. Despite having in the realm of 600-800 HP, the car runs 12's, because it makes really good power at only one point in its RPM range, and doesn't have a lot of torque. A 600-HP Mustang or Camaro will run 11's, because its torque is available throughout the RPM range.

Re:Pentium V

[Anonymous Coward]

yet your horsepower numbers are higher because you are at a high RPM (HP = (tq * RPM)/5252).

I think I remember horsepower/torque charts showing horsepower drop at high rpm.

here is a quick example. I know it is a different kind of engine than referred to. But Even horsepower drops eventually.

Re:Pentium V

[Anonymous Coward]

The size of the engine and the revolutions of the engine are two completely different criteria in determining an engine's power, but both are critical. A V8 can have a higher power output because a V8 can more efficiently have larger cylinders and thus have more gas and air mixing and producing power. A smaller inline 4, with a smaller cylinder size, can produce the same power as a larger V8, by having higher revolutions (RPM). Remember, power output is simply Engine Torque * RPM * (conversion factors). The larger the engine, the more torque the engine has, all other things equal.

The real trick with engines is how long you want it to last. A big V8 may produce as much or less power as a high revving 4, but could last dramatically longer, because it is working at a steady 1500 rpm, instead of a screaming 6000 rpm inline 4.

You could also have both worlds, having a high revving, incredibly powerful and large V8. But your engine may not last as long.

And turbocharging is another topic! I find your comment about the trend of turbocharging uninformed. Turbocharging has been around as long as engines have been around and will always be around. And not just in cars. Airplanes, trains, ship, and long haul big rig trucks all use turbocharged engines. Why? Because it's efficent. It's an efficient way of adding more power to your engine without adding excessive weight. And those engines are designed to last for years and years; most big rig truck engines are used for 2,000,000 miles OR MORE! Same goes for train engines. How long does your car last?

Re:Pentium V

[jallen02]

Hmmn?

Most 500rwhp - 500ft/lb tq cars I know of are quite capable of running on the lower side of 10s. I have seen several TT V8 stangs on a stock bottom end with auto trannies pushing low tens on street tires. (of course I am thinking rwhp as that is all I really like to use. I think flywheel HP is a gimmick).

(Not to mention TT V8 stangs can get ~24mpg@500rwhp)

Jeremy

Re:Pentium V

[Anonymous Coward]

Please. You are giving those of us who like V8s a bad name. Do some research before you post.

Turbos work good on all kinds of engines. Turbo-Diesels don't even rev high.

Both High-rev engines and low-rev engines have advantages and disadvantages.

High-rev is fuel efficient and works well in areas where the vehicle has to travel fast.

low-rev lasts longer and works well when towing or off-roading.

Re:Pentium V

[c.emmertfoster]

Stop attempting to argue or crack jokes, dude. The moderators are being unfair to you tonight.

Re:Pentium V

[c.emmertfoster]

Don't forget the 386 to "486" upgrade that was offered by Cyrix. I've got a computer somewhere with one of those, although I never noticed much of an improvement from it.

Re:Pentium V

[Anonymous Coward]

My car (MCC smart cabrio aka smart cabrio aka smart fortwo cabrio) has a 699 cm turbo charged engine. Not everywhere fuel is as inexpensive as where you live.

Re:Pentium V

[nelsonal]

The only thing that killed the turbos was the Yen dollar exchange rate in the mid 90s. Let's say that a Supra or 300GT would have cost about 5,000,000 Yen through the entire decade of the 90s. In 1990, the car would be priced at a relativly low $32,000. However by 1995, you needed almost $59,000 to get the same 5 million yen. Too many american consumers would rather have a Corvette, and they begin to approach the price of something really nice from Europe at this point. This is obviously simplistic, as the car's yen price likely rose through the decade. However it does get the point across, now that the yen is weaker, and the cars are smaller (mostly turbo 4s rather than twin turbo V6s). They have returned at a price point more palatable to the average American car buyer. If the dollar keeps falling they are likely to go away, how many people will pay $35,000 to $40,000 for an STi or Evo? I don't think either is make over here yet. That's mostly what killed any possiblity of a vibrant Japanese supercar market in the US. Honda keeps making the NSX mostly to refine and improve their alumninum technonlogies, the additional attention drawn doesn't hurt either.

Re:Pentium V

[bhtooefr]

Basically, wasn't the 486SX a version of the 386DX with on-chip cache, and better layout internally? BTW, IBM made a 486 that worked on a 386 SX bus, and it went almost as fast as a 486 running on it's native bus.

Re:Pentium V

[Anonymous Coward]

Those cars rule. I was the Smart Roadster (or the Brabus modded one). BTW, I live in the US.

Re:Pentium V

[Craig Davison]

No. A 486SX was a 486DX without the math coprocessor. The 487SX add-on was actually a full 486DX. If you added a 487SX, your 486SX would be disabled.
Basically, you could have known this for sure after 5 minutes of web surfing.

Re:Pentium V

[jallen02]

Most of the 10s street cars all have major traction problems. I have seen guys go from low tens to mid 9s w/Slicks and no other significant changes. It actually is kind of scary to drive a car with that much available torque on the road on street tires.. but ah.. who am I kidding.. it beats walking ;)

Jeremy

Re:Pentium V

[phxhawke]

On the x86-64 chips, entering 64-bit mode is a 2 step process. With the first step being enabling 32-bit protected mode first before enabling 64-bit mode.

Re:Pentium V

[bhtooefr]

I knew THAT. Let me rephrase it: The 486SX is a version of the 486DX without a math coprocessor. The 486DX was an enhanced version of the 386DX with a better design, on-chip cache, and higher MHz.

Re:Pentium V

[Loki_1929]

"you could simply shut down portions of the processor on-the-fly to save power. "

They might need it if there is any truth to this. From the article:

"Our motherboard contacts in Taiwan tell us... [that] motherboards they're designing for the middle of the year will support a not-so-cool 150 watts, just in case Intel gets a 3.8GHz Prescott out of the door."

150 watts? This NVRAM would have to shut down about half the CPU (not including L2) to keep the thing from burning a hole in the space-time continuum. If it's of any interest, roadmaps seem to indicate huge jumps in pin counts and die sizes for the P5s. What some have alluded to is an integrated memory controller, similar to AMD's, being integrated into the P5 chips, along with dual core support (just like AMD). The problem with sticking the NVRAM on top of the chip is price. Integrating a memory controller is a far cry in terms of production costs than sticking extras in later. Aside from that, if you're talking about an add-on, you run the risk of seeing huge latency numbers.

I think Intel needs to finally start focusing on CPU efficiency and instruction design. The MHz battle is long since over, and Intel is going to start slamming into some barriers that competitors won't see for quite a long time due to more efficient designs. What good is running a chip at 50GHz if 80% of those cycles are spent waiting for data to arrive due to relativity constraints? Unless Intel is prepared to integrate technology that takes advantage of quantum entanglement, they're not going to have a whole lot of success with their continuation of ramping up clock frequency.

Re:Pentium V

[RelliK]

No, they will call it Pentium Pentium... :-)

Re:Pentium V

[Craig Davison]

And more instructions, and a different pinout. Some instructions also took less clock cycles.

There was a version of the 486DX pin-compatible with the 386DX called the RapidCAD.

Re:Pentium V

[drsmithy]

I remember in the early 90s the crud you could buy to turn your 486/33 into a 486/66 DX2 processor.

Crud ? All they were was a regular old 486DX2/66 CPU with an on-board voltage regulator. They worked very well and we a quick and easy way to basically double CPU performance.

Even then these products were not wildly popular, and at that time it was significantly more expensive to do anything else (and there was no real x86 competition).

Certainly where I was at the time they were quite a popular upgrade item. There was at least as much competition as there is today - more, really - from pin-compatible AMD and Cyrix chips that could replace your intel one - no need to even buy a new motherboard.

These days, such a product would doubtlessly be unpopular.

These days, "such a product" is really just a faster, socket/slot compatible CPU, and they are about as popular upgrades now as they were then.

Re:Pentium V

[Anonymous Coward]

and the 32x only had about 6 decent games in its entire life

...which is about 5 more decent games than the XBox has! Boo-ya!

ducks and hides from flames...

Re:Pentium V

[Anonymous Coward]

where are the turbo cars indeed ?
- subaru WRX
- lancer evo 8
- Audi RS6
- Dodge SRT-4
- Porsche 996TT

All decent cars, but I'm not convinced that it makes your point. As a counterpoint, I offer up the Z06 Corvette, which is normally aspirated. It destroys all except the Porsche in every performance category (and the Vette & Porsche are evenly matched in most). However, the Vette gets far better mileage than its only performance competitor in your list, while beating the mileage of most of the less powerful ones:

Vette Z06: 18/28 - 405 HP
Porsche 966: 15/22 - 420 HP
Lancer: 18/26 - 270 HP
WRX STI: 18/24 - 300 HP
Dodge SRT4: 22/30 - 230 HP

So it's not clear to me that turbos are a net win - the vette is getting far better mileage than the cars in its power class, and beating or at least coming close to the mileage of the less powerful cars. Seems to me the NA engine is doing quite a bit better than the turbos!

(Not to mention that the Vette will destroy them on a real racetrack - the 2004 Z06 is one of only a few stock production cars to break 8 minutes on Nurburgring, which dominates everything but one or two of Porches very costly exotics)

Re:Pentium V

[jandrese]

There were some early reliability concerns with turbocharging because people forgot that americans are stupid and do things like not change their oil or keep running the car even though its obviously over heating. this would often lead to oil coking in the turbine and eventual bearing failure, causing turbos to wear out.

I think the real killer was the need to let the car sit idle for a minute or two every time you wanted to turn the thing off to let the oil drain out of the turbo. Nobody wants to shave a minute off of their trip to the store only to have to waste it waiting for their car. The additional wear and tear on the engine sealed the deal. Deisals are a different story, and people have been more willing to use turbos on deisels in general because the performance boost is more noticable (and necessary as car sized deisals tend to accelerate like a dog without a turbo). It's a good technology with a few drawbacks that prevent it from being really practical.

Re:Pentium V

[obeythefist]

5-7GHz, eh? What about IPC? .002 of an instruction each clock cycle? That seems to be intels method. Make the CPU faster at any cost, including actual performance.

Re:Pentium V

[Anonymous Coward]

I wish I could mod you up, whoever you are, because your post has so much truth in such compact sentences! More detail would help, but what you said is correct.

I'm gushing, I know. I'll stop now.

BTW, it's great that in spite of being offtopic, so many still post about turbos. Lots of car geeks here!

Re:Pentium V

[bhtooefr]

I said better design on the 486. I hadn't thought that it had more instructions, however. Also, Cyrix had shipped 486 CPUs that were pin-compatible with the 386DX, and TI and IBM shipped CPUs that were pin-compatible with the 386SX (that performed almost as well as their 32-bit bussed Intel counterparts in the case of the IBM - just think of an IBM designed full 32-bit 486!).

YES!

[Alan Partridge]

Not that I'd know one way or the other...

Stack size

[Anonymous Coward]

Darn, my stack size is about to double...

I guess recursive algorithms are about the become a memory hog.

Re:Stack size

[hey]

The return address will grow to 64-bit but the parameters to your recursive routines need not be that big.

Re:Stack size

[Anonymous Coward]

But the entries will be 64 bit aligned, no matter what, just as stack entries on a pentium is 32-bit aligned.

What'a'waste

Re:Stack size

[Anonymous Coward]

...and if you are using SSE2 on the Pentium 4 (or Opteron) the data are 128-bit aligned (if you're coding for speed).

Re:AMD

[francium de neobie]

> AMD dominates Intel so much now eh... It is year 2004, right?

Just in time for...

[inode_buddha]

LongHorn. Or is that "lower horn"? If the XP hardware jump was any indicator, they're gonna need it.

But...

[NeoThermic]

Can it do hardware 32bit as well? Currently the Intel Itanium 64 bit chip has to emulate 32bit for applications that are not 64bit compliant, and therefore the AMD64 which can do hardware 64 and 32 bit sweeps the floor.

Plus, who is ready to receive 64 bit chips? Windows isn't quite yet there with their 64 bit OS, and many linux distros only have beta quality 64 bit OS'es.

NeoThermic

Re:But...

[Dave2 Wickham]

I thin the "x86-64" in the title is supposed to imply that it can cope with all x86 apps

(Typing on a dodgy eyboard with no woring "cay" or "dot")

Re:But...

[TeknoHog]

many linux distros only have beta quality 64 bit OS'es.

Just to nitpick, Linux has supported other 64-bit architectures (at least Alpha) from its early years, so it definitely has the 64-bitness sorted out already. X86-64 is a relatively new thing, but not quite the first one with 64 bits.

Re:But...

[hackstraw]

Can it do hardware 32bit as well?

Who cares? You will be able to buy a 32bit machine for quite some time for your "legacy" apps.

Plus, who is ready to receive 64 bit chips?

Hmm, 64bit chips have been around for 10 years or so. Ask someone who works with real hardware this question.

Windows isn't quite yet there with their 64 bit OS, and many linux distros only have beta quality 64 bit OS'es.

a) this is slashdot, windows doesn't matter b) although my experience with 64bit linux distros is limited, Debian was stable on an Alpha 5 years ago, and RedHat Advanced Workstation 2.1 is rock solid on our 33 Itaniums, and RH 7.1 is rock solid on our 60 Alpha's.

FWIW, I believe that Intel's 32-64bit x86 hybrid would be kinda stupid. Intel already has a fine (although still expensive) 64bit processor. Like I already said, 32bit machines will be available for quite some time for legacy apps, and for any app that is currently maintained, it fairly trivial to recompile it so that the app is 64bit clean.

Lastly, I do not understand people's obsession with x86. Disco died in the early 80's, but we still want to use a computer archetecture from the 70's?

Re:But...

[alexq]

According to theregister's article (go read it! :) as well as what I've heard about this and the AMD chip, the 64-bit extensions will be just like the 32-bit extensions were for the original pentium. In other words - it will be backwards compatible without the crummy emulation. :)

Re:But...

[October_30th]

Lastly, I do not understand people's obsession with x86. Disco died in the early 80's, but we still want to use a computer archetecture from the 70's?

a) With the exception of the black magicians of the embedded systems, people people do not, in general, have to write bit-banging assembler code. Who cares if x86 is shite - and no-one's disputing that here - if the compiler/interpreter hides them nassty, nassty bitses.

b) It is imperative that the legacy code runs fast or that it can be easily recompiled. You mentioned that you've run Alphas. I too had an Alpha 164LX in 1990s and ran Linux on it. It was fine and dandy, but after a while I got tired fixing those stupid-programmer-cast-a-pointer-to-int bugs in order to compile free software. I expect tons and tons of similar problems on Opteron platforms, but on IA64 the problems would probably become ever worse.

Re:But...

[Anonymous Coward]

If you're really stressed for a K or . you can cut and paste them from elsewhere in the page. Your name provides the K and .s are everywhere.

Re:But...

[bersl2]

and many linux distros only have beta quality 64 bit OS'es.

LFS + CFLAGS="-O2 -m64" + Building a x86-64 toolchain

Haven't tried it myself, having no Opteron and motherboard. :(
I can dream, can't I?

Windows XP 64-bit

[Zog The Undeniable]

But will MS write their 64-bit XP to work on Athlon 64 and the new Intel chip, or will we have three different versions (Itanium, Athlon 64 and Intel x86-64)? At this rate Windows will become as fragmented as Linux ;-)

Re:Windows XP 64-bit

[Anonymous Coward]

The rumour is that Microsoft said a firm no to Intel requesting support for an entirely new 64-bit variation, but they worked out a deal where Microsoft would delay their x86-64 version of Windows until Intel was able to develop a compatible processor. The Intel x86-64 processor might even contain a few extra instructions that AMD doesn't have, just to ensure incompatibility.

These kinds of rumours may not not have anything to do with reality, but at least they can explain why Microsoft has not released the x86-64 Windows for sale even though there have been fully functional betas available for almost a year now.

Re:Windows XP 64-bit

[AKnightCowboy]

These kinds of rumours may not not have anything to do with reality, but at least they can explain why Microsoft has not released the x86-64 Windows for sale even though there have been fully functional betas available for almost a year now.

It's official then. AMD is dying.

Just kidding. Personally I'll buy an AMD64 processor any day over the Intel processor unless they completely change their business practices and price it either comparable or less than the AMD 64-bit CPU. Somehow I doubt Intel will do that since they still think they are the 2000lb behemoth of the CPU business and don't see that they have some very good competition from AMD among hardware enthusiasts. If I had the $750 I would get the Athlon FX-51 chip in a heartbeat.

Re:Windows XP 64-bit

[Anonymous Coward]

To me "x86-64" would seem to refer to the AMD instruction set.

Re:Windows XP 64-bit

[Basje]

Doing that would effectively lock microsoft out of a portion of the market, a portion that linux could fill well. Considering the pressure linux is beginning to put on MS, that seems unlikely.

Re:Windows XP 64-bit

[johneee]

Well, in theory, because of Windows' Hardware Abstraction Layer and the way it's architected, they should be able to put all three on a single disc and install the one you need. All the chips are based on X86, so the differences wouldn't be quite as huge as to make that impossible.

Now that I think of it, if I were Microsoft, I'd make the Professional version of the desktop OS the only one that supports 64 bit CPUs. That would fit in with the current strategy (home=1 cpu, pro=2cpu).

Re:Windows XP 64-bit

[ceeam]

Well - that might be a strong reason why they want to have everything .NET way. (What a stupid name, again...)

Re:Windows XP 64-bit

[Zog The Undeniable]

Jerry Sanders must be well pissed off then. It's not going to help Athlon 64 sales at the expense of P4, if users still have to run 32-bit XP for the foreseeable future. I smell an Intel dirty trick.

Re:Windows XP 64-bit

[Jeff DeMaagd]

I thought the first _public_ beta of W64 for AMD was released just a few months ago, and that people said it still needs a lot of work.

Even if it were out, I think the problem is getting people to invest into the platform, be it large and small time developers. In short, the platform needs a "killer app" to make it a worthwhile transition for most people.

Re:Windows XP 64-bit

[Anonymous Coward]

I heard the same thing, only with purple monkey dishwasher.

Re:Windows XP 64-bit

[222]

Microsoft strongarmed Intel into adopting AMDs x86-64 instruction set, basically saying that there was no way in hell MS would maintain 3 different 64 bit trees for windows.
Cant really blame MS on that one though, cant bend over backwards for everyone, especially considering product testing gets exponentially more difficult for each codebase.

Re:Windows XP 64-bit

[WNight]

Why does it need a killer app? It's an incremental upgrade that's no more expensive than the last incremental upgrade? It's pretty much a no-brainer for anyone who buys AMD, it's just as fast in 32bit code and 64bit code can be much faster on the right stuff (audio/video encoding, etc).

It's great that MS is delaying though. All the companies that make 3d modelling and rendering software and haven't already switched to Linux are doing so now. Ditto companies making scientific analysis software and other computationally intensive programs.

In letting Intel talk them into hindering AMD (or just being pathetic at bringing out a new OS version) Microsoft has just shot themselves in the foot.

Re:Windows XP 64-bit

[HiThere]

But if they made the deal a year or so ago... they might have gone for it. Linux has increased it's penetration a great deal in the last two years.

And if the deal was a contract, it might be too expensive to get out of.

Re:Windows XP 64-bit

[PatJensen]

FreeBSD 5.2-rc1 AMD64 is awesome and has great 64-bit driver support. Out of the box, everything installed and worked on my new Athlon64 with the MSI board with a GENERIC kernel! Gigabit ethernet, audio, Nvidia video, ATA-133, you name it. The only thing I couldn't make work was cvsup, and I used CTM instead to build FreeBSD-current.

I've dabbled in Windows XP 64 a bit. It looks, tastes and feels like Windows but is missing a crapload of drivers (both Microsoft internal and vendor). Nvidia makes 64-bit drivers but ATI doesn't.

Pat

Re:Windows XP 64-bit

[Anonymous Coward]

This is where .Net comes in. Large portions of LongHorn are written as .Net managed code, which is processor independent.

Re:AMD

[Alan Partridge]

What? We've just moved most of our workstattions from Athlon XP to Pentium 4 because of poor application support for AMD.

AMD are making excellent products, but fear, laziness and general inertia are keeping Intel in front just like they're keeping Microsoft in front. I wish it would change but my experience suggests otherwise.

Dumb question

[pubjames]

Ok, flame me if you wish, here's my dumb question:

If I got a computer with a 64 bit processor, what difference would I notice compared to a non-64 bit resaonbly high-end PC? I mean, would it just be a bit faster? Or a hell of a lot faster? Or just faster at certain things? Or would it not make much difference at all for normal everyday office tasks and playing games etc.?

Re:Dumb question

[Anonymous Coward]

Just faster at certain things.

It's been 14 seconds since you hit 'reply'!

Re:Dumb question

[Bishop, Martin]

Absolutly nothing until programs start to utilize all 64 bits...and who knows when that will be

Re:Dumb question

[TwistedSquare]

Depends... ;) If you ran 32-bit windows on a 64-bit machine you would notice little difference. If you run it on (presumably Linux) apps compiled for 64 bit then you would notice a big difference.

Re:Dumb question

[Anonymous Coward]

you would not notice any difference today.

it's an evolutionary step.

5 years from now, when you are completely used to 64bit, taking you back to 32bit will definitely be noticeable.

just like if we forced you to use a 16bit processor and operating system today, you'd notice, wouldn't you?

Re:Dumb question

[Sivaram_Velauthapill]

The 64bit CPUs will have higher clock speeds than the 32bit. So automatically they will be faster if EVERYTHING ELSE WAS THE SAME (which isn't). In theory, 64bit should be better than 32bit (that goes without saying). The real answer will depend on the applications. It will take some time for developers to write applications that use 64bit. Since nearly all applications are 32bit right now, developers won't change overnight and you probably wouldn't notice a difference for a while. So 32bit is probably good enough for 3 years I would say.

BTW, general office tasks may not seem much improvement but games definitely will. Games are one of the most tasking activities for a computer. Games can easily use up all your CPU power (although often, you are video-card-limited rather than CPU-limited--depends on game though).

Sivaram Velauthapillai

Re:Dumb question

[argent]

Going to 64-bit isn't likely to make a difference to most programs. It will make a difference if you run software that needs a lot of address space, either because it wants to load or directly map more than 2-4GB of data, or because it's using sparse addressing for some reason (there are a number of algorithms where having a small amount of data scattered over a large address space is the most efficient way to operate). What's more likely to make a difference is using the change in address space to get people to recompile their code to a new instruction set that's better designed than the one you already have.

Given Intel's track record on instruction set design, I'm not encouraged. Consider their history: 8080 and register starvation, 8086 and register starvation, iApx432 - the second most bloated CISC design ever, 80286 and the age of segmentation, 80386 and more register starvation, i860 - the most complex RISC ever, IA64 - how many years late and now apparently being left to rot? The best design they ever did was the i960, and it got effectively killed by internal politics and delegated to embedded controller work.

If they were smart, they'd have kept the next generation Alpha team intact and released EV8 as the Intel iAXP processor... in a few years nobody would remember that they'd started with someone else's design (look how well they've marketed the XScale).

Re:Dumb question

[Crypto Gnome]

Actually, you're almost completely wrong. All things being the same (clock speed, on chip cache, etc) 64-bit computing should be measurably slower than 32bits.

WTF???

Yes, you heard right... slower.

More bits per instruction means

• more thrash-in-your-cache
• more RAM bandwidth used just sucking down instructions

And that's without even beginning to go into mega details of advanced CPU design.

Repeat after me 64-bits does not magically change anything.

The reasons these chips will most likely run apps faster is due to

• faster clock speed
• more cache ram
• wider system bus
• generally better CPU design

This is basic real world physics and engineering here, not Wizards of Might and Magic.

Re:Dumb question

[mahart]

Using 32bit OS's and 32bit programs there would be no difference.

Here are some benchmarks that show the difference once programs start to get rewritten/recompiled for 64bit (for the Athlon64)

Re:Dumb question

[argent]

In theory, 64bit should be better than 32bit (that goes without saying).

Not actually true. The larger the word size, the more bits you have to move on every operation. Going to a larger word size is normally driven by application requirements: if an application doesn't need a larger address space or a wider ALU a larger word can actualy make it slower.

What can you do with a 64-bit processor?

Well, one thing you can do is directly address every byte on the largest disk drives we can get today. With an operating system that was designed for direct access, like Multics, you would never have to "read" any files: when you opened one, it would look just as if it had already been read in... all your physical memory would effectively be a big disk cache.

For another, you can give each computer on the network part of the address space, so the same thing would be true for any file on your local LAN. Or any program on your LAN... no more messing around with protocols and remote file servers and databases... if you had the access rights, it would be as if they were local files.

You could do the same thing for each instance of a program, so you wouldn't need complex mapping code when passing messages from one program to another... in fact you could just pass the address of a message and let the memory management system move it over when you actually need it. That would get rid of a LOT of redundant copying, since you probably don't need all parts of every message.

The problem is, you'd need a whole new OS (or a whole old one... Multics is older than UNIX) to really take advantage of this kind of thing.

Re:Dumb question

[simcop2387]

actually for a 32-bit app since its the processor is litterally backwards compatable (thats the beauty of x86-64) it may not slow it down all that much, if not at all noticably to a person, now if you are using 64-bit code at the exact same rates as 32-bit code, it could most easily be slower.

Re:Dumb question

[Alan Partridge]

The perceived length of your penis would increase in direct proportion with the word length of your main CPUs instructions.

It's a scientific FACT.

Re:Dumb question

[Anonymous Coward]

Did I get it right that you claim that 64 bit instructions are twice as long as 32-bit ones? What are you on?

Now, the reality in x86-world is that the chips have already been largely 64 bit (think of mmx and fpu). Making the rest of the instructions so as well might provide in fact a simpler design.

Another note is that processor bitness and size of the data you operate on memory aren't necessarily related so all the data you access isn't suddenly going bloat itself to twice the size. (unless it's full of pointers)

Re:Dumb question

[LnxAddct]

This may be a dumb question but...if you recompile code on a 64 bit platform, does that code then use any benefits of being 64-bit or will it still run just the same as 32 bits. I'm just curious because I may be getting an AMD 64-bit (or possibly holding out now and see how Intel prices their processor) and want to know if compiling Gentoo or anything else on it will make any major improvements.

Regards,

Steve

Re:Dumb question

[Vlad_the_Inhaler]

That rings a bell.

There was some show-stopping problem with the way HURD addressed discs which meant they could only support pathetically small discs. This was going to force a major rewrite and I have never heard anything of the project since.

Would this new architecture fix that problem? (possibly not, it may have been something along the lines of large discs needing a large memory footprint - something x86-64 would help with but would be too wasteful to be used)

Re:Dumb question

[Anonymous Coward]

and who knows when that will be

Right now.

The dual Opteron 240 I got today is right now working hard compiling a fully 64-bit Gentoo...

Furthermore, SuSE already has a 64-bit distro out.

Re:Dumb question

[Terje Mathisen]

You're right: 64 bits doesn't make it faster, but otoh it doesn't really make it significantly slower or bigger either.

According to the latest discussions on news:comp.arch, the 64-bit size overhead on current cpus is around 3%, the internal bus size increase doesn't matter, and code size can be more or less the same.

It is only when you automatically extend all default-sized data items from 32 to 64 bits that you get a noticable slowdown.

It is only when you really do need more than about 2 GB of RAM that a 64-bit cpu is really useful.

Terje

Re:Dumb question

[pantherace]

How about now?

Running most anything but windows (everyone can probably remember "32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor written by a 2 bit company that can't stand 1 bit of competition.")

The real question is what the 64 bit $BLANK tacked on to the front would be.

Linux: it just works on 64-bit.
Windows: please emulate a 32-bit (or lower) processor*
*I have used NT 4 on alpha (pretty much just acted like it was 32-bit), and know that there is a "64-bit Windows" on Itanium, but if you look at the list of services, a whole lot of windows componets (some of the database stuff even) is emulated x86 code.

Re:Dumb question

[Anonymous Coward]

In addition to the other replies above:

Even 64-bit apps won't be faster unless they handle 64-bit data items. If they just handle 32-bit items, the 64-bitness of the system just wastes bandwidth (kinda using 64-bit slots and bus widths for ultimately 32-bit items).

But Opteron has a benefit that's not actually tied to the 32 or 64 bitness as such.Namely, AMD added new registers that are available in the x86-64 mode (even with 32-bit data) -- precisely this is behind the speed-up in Counter-Strike and other 32-bit games and apps. X86 is an extremely register-starved architecture.

Re:Dumb question

[Anonymous Coward]

and want to know if compiling Gentoo or anything else on it will make any major improvements.

Well, if it is any indication, my dual Opteron 240 (1.4 GHz) running Gentoo is compiling stuff faster than anything I've ever seen before and I've worked on dual Xeons and Athlon MPs.

My guess it is primarily the 1 GB cache.

Re:Dumb question

[Darren Winsper]

It will indeed fix it. HURD handles storage devices (Hard disks, CDs, etc) by memory mapping them into the address space. In a 32-bit system, you can only address 4GB (Forgetting such systems as PAE), thus HURD can't handle very big partitions on 32-bit systems. However, if you move to 64-bit, it become feasible with todays storage systems, along with tomorrow's for some time to come.

Re:Dumb question

[Vlad_the_Inhaler]

Something has to be wrong with that.
A 32-bit system can access 4GB of memory without kludges. Are you implying that every byte on a disc partition has to map to a byte im memory? I can't believe that is what you are saying and it would mean that you will always need more memory than disc-capacity.

That would be the mother of all design-errors.

Re:Dumb question

[dimonic]

Sorry, but I am not actually answering your question directly, but it is perhaps appropriate because your question begs a bigger question.

I don't think anyone needs more speed than the best 32 bit CPUs provide today. The bigger problem today is bugs. Memory leaks, security flaws, memory protection errors, you name them. If I understand him correctly, Linus Torvals has weighed in to say that 64 bit architecture will allow a new way of addressing devices: 1:1 mapping. This will eliminate a huge amount of paging and cacheing code in OSs. If I read Linus correctly, he is saying that 64 bits is enough to map any entire hard drive space directly into memory. This brings me to the comments of another luminary: Donald Knuth. Knuth has written and demonstrated ways of writing very low bug count software, and created a seminal work, the practical, non-trivial application LaTeX, which I use daily. Knuth has proved that a large complex application with strong change management can achieve a very low bug count and still have enough features to have no real competition in its field.

So what I am getting to is another question: is 64 bits enough, now and forever? I mean will we ever need more address space for anything? So can we write or change our OS so direct mapping of everything is the norm, and thus eliminate half the cleverness and most of the bugs in the OS? And expect that this will be "the last re-write". That all that will be needed in the future is new device drivers and re-compiles for new CPUs?

Re:Dumb question

[beeblebrox87]

Every byte on a disc partition has to map to a location in memory. Basically it's like treating your hard drive as a really slow RAM module.

Re:Dumb question

[Darren Winsper]

You don't, because of the way virtual memory works. Let's assume you have a 16-bit address space, &0000-&FFFF. Now, each and every application gets 64MB of VM to play with. Now, if you memory-map a file to &F000-&FFFF, it doesn't actually take up RAM. When you attempt to write to those locations, data will be written to the file instead of to RAM.

Virtual memory addresses don't necessarily correspond to phyisical memory addresses.

Re:Dumb question

[Anonymous Coward]

With that kind of cache what's use is the ram for anyway?-)

Re:Dumb question

[Anonymous Coward]

Every Intel processor since the Pentium has had 64-bit memory access and datatypes. Any SSE chip can also support 128-bit datatypes for certain operations. Making the Pentium '64-bits' only requires 64-bit memory addressing(which entails a 64-bit program counter and stack pointers). x86 instructions already range from 1 to 10 bytes in width(14 bytes including the immediate field) so memory bandwidth will not change as a result of the new instructions existing.

Re:Dumb question

[alexq]

This is almost entirely wrong.

When they talk about 64-bit processors, they are talking about the data stream, not the instruction stream. In the articles linked, they only discuss 64-bit extensions to the x86 architecture - which has mostly 32 bit instructions (and of course legacy support), which means that there is no additional bandwidth for instructions. Also, it stands to reason that all the old instructions will still use the 32-bit data they were using before (so no extra data bandwidth either).

One benefit to having a 64-bit data stream is that you (should) have increased bandwidth - a data-fetch instruction can now fetch 64 bits at a time instead of the old 32 bits at a time (yes, you need more pins for this).

You also have greater accuracy for floating-point operations, and a higher maximum value for integers. This can speed up things considerably if, under a 32-bit architecture, you need to implement workarounds for this extended accuracy.

There are a lot of applications where you can take advantage of the extra bits (the more the merrier). Bitmasks for one thing, and lots of graphcis and vector operations can be modified to be twice as fast when you have twice the data stream. I don't remember the specifics of how these are implemented, maybe someone else can elaborate on these.

Re:Dumb question

[ceeam]

Well - don't worry. Software authors will care about that. 64-bit booleans! Woo-hah!
(For something completely different: Try installing Win 3.11 onto Athlon or PIV system some time just for kicks... ;)

Re:Dumb question

[slyfox]

More bits per instruction means... more thrash-in-your-cache... more RAM bandwidth used just sucking down instructions

Wrong! When someone says "a 64-bit chip" they mean the number of bits used to specify a memory location (ie., the size of a pointer). They are not talking about the size of the instructions!

The main benefit is not wider arithmetic operations or higher performance. The main benefit is more addressable memory. Since the amount of memory in a machine has been doubling every year or two, we need an extra "bit" of addressability every couple of years. We already need 64-bit chips for servers, and it is only a matter of time until we need 64-bits on the desktop.

Re:Dumb question

[Sloppy]

If I got a computer with a 64 bit processor..

A better question would be to ask specifically about x86-64 vs i386, instead of 64-bit vs 32-bit.

In general, comparing 64-bit processors to 32-bit processors is like comparing apples to oranges. Each side is going to be able to find situations where it is faster.

But if you ask about x86-64 compared to i386, then it gets a bit easier. x86-64 is better and faster, at nearly everything. The 386 is finally dead (or at least seriously threatened), thanks to AMD. It's not just about the number of bits, but also features (e.g. writable xor executable pages), number of registers (which can have a huge effect on performance in some situations), etc. Of course, the number of bits will matter some some things, too (e.g. some kinds of cryptographic operations).

Or would it not make much difference at all for normal everyday office tasks and playing games etc.?

Well, it shouldn't make a difference for everyday office tasks, because those things aren't normally CPU-bound. "Everyday office tasks" are situations where the processor is 99% idle waiting for the monkey to press a button. Those people should be using ten-year-old computers, or at least should only be replacing them as they break, rather than upgrading for speed.

Games... I believe most gamers run closed-source code, so be careful. x86-64 will run faster, but you might have a hard time getting the software.

Re:Dumb question

[anthonyrcalgary]

Well, one thing you can do is directly address every byte on the largest disk drives we can get today. With an operating system that was designed for direct access, like Multics, you would never have to "read" any files: when you opened one, it would look just as if it had already been read in... all your physical memory would effectively be a big disk cache.

I dunno how Windows or Multics handle it, but on the UNIX side you can use mmap for that. It's slightly less elegant than an all-memory way of doing things, but it's really not that bad. One line for the mmap call, a few lines of tests to make sure it worked, and you're good to go.

Re:Dumb question

[Detritus]

I don't think anyone needs more speed than the best 32 bit CPUs provide today.

You are very wrong. I'd like to do RF digital signal processing on my PC. Current CPUs are hopelessly underpowered for many of the DSP applications that would be useful to me.

Re:Dumb question

[Sloppy]

until programs start to utilize all 64 bits...and who knows when that will be

The mid 1990s.

Re:Dumb question

[Anonymous Coward]

32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor written by a 2 bit company that can't stand 1 bit of competition.

That has to be the nerdiest thing I have seen all week. Thanks a lot for ruining my day, butt monkey.

Re:Dumb question

[fitten]

On Windows, search for MemoryMappedFile. The equivalent to mmap.

Re:Dumb question

[dimonic]

I don't think "very wrong" is on the mark. I was perhaps over generalizing, as are you if you think that most people need the raw horsepower you need. I was thinking about folks that use word processors, browse the web, send e-mail, play games: you know, about 99% of CPU users. So for 1% of users, I am "very wrong" in my intentionally controversial opening statement.

My main point (which you appear to have overlooked in your zeal to shoot me down) is that the 64 bit architecture offers something else other than (or instead of) raw performance. If you consider that also "very wrong", would you post your argument concerning that point also?

Also, for your application are there not some useful DSP add-in boards that can supply an order of magnitude increase in performance for DSP? At the price of the high end GPUs one could surely buy a DSP or two and have change left over.

Re:Dumb question

[AndrewHowe]

But (at least on the AMD implementation)
* 64 bit GPRs are available
* Most stuff defaults to 32 bit, auto extended to 64 bit
* You can do 64 bit stuff but you need a prefix byte on the instruction. This is also needed for fancy addressing modes and extra regs (8..15)
* MOV and PUSH support 64 bit immediate values which will obviously cause bloat.

So, "Wrong!", back to you with knobs on ;-)
Agreed, though, that the most pressing need is for more address bits; however, the new addressing modes and registers are nice.

Re:Dumb question

[slyfox]

You can do 64 bit stuff but you need a prefix byte on the instruction. This is also needed for fancy addressing modes and extra regs (8..15).

Yes, that is true. In my original comment, I forgot that AMD's extension of x86 to 64-bit addressing does increase code size for some instructions. In contrast, PowerPC, SPARC, and MIPS instructions did not increase in size when moving to 64-bit.

Fortunatly, AMD took the opportunity to make some other enhancements (such as the larger number of registers which you mentioned), the code increase should be offset by the other enhancements for most programs.

Re:Dumb question

[shotfeel]

I don't think anyone needs more speed than the best 32 bit CPUs provide today.

I'd disagree with that. One example that is becoming more common because CPUs are getting faster is editing video on a home computer. I do it, and I know more and more people who are doing it. The home movie of today is being shot with a digital camera, edited on a computer, and burned to a DVD. The video encoding process still takes a long time (relatively speaking) and being able to preview and apply various effects can take even more time.

Re:Dumb question

[Anonymous Coward]

Why do you fucking moron go on pretending you understand something of this, when in reality you are talking completely out of your ass? This isn't the first time, mind you!

It's perfectly okay to be clueless, but it's not okay to try to impersonate an expert when you just aren't one.

Your comment was just gibberish. Been reading Anand lately? ;-)

Anyway, stop posting when you have nothing useful to add. Enugh noise in the signal already.

Re:Dumb question

[Anonymous Coward]

Oh shit, PDFs.

Re:Dumb question

[Grishnakh]

Don't be ridiculous. The main advantages of 64-bit architecture is memory addressability and large-number computation. There are many applications for this; just because Granny doesn't want to do anything besides send email is irrelevant to the rest of us that do have uses for this power.

Some examples, some of which have already been pointed out:

1) video editing. Digital video takes up tons of space, and 2GB of memory addressability just doesn't cut it when you're trying to edit something that takes tens of gigs or more.

2) large-number computation. Scientific simulations, video rendering, etc. do tons of computation, and doing it 64 bits at a time will improve performance greatly.

3) games. The way games operate isn't too different than the rendering that Hollywood studios do in massive quantities, and games need to do it in real-time.

4) computation using large data sets. Simulators of all kinds (used for designing semiconductors, aircraft, automobiles, etc.) work with massive amounts of data. 2GB of memory addressability isn't enough.

Whether you think "most people" need 64 bits or not is irrelevant. I really don't care about the masses of AOL users who just read their email; in my line of work, 64 bit systems will soon probide a very noticable benefit as the simulators we're currently using are pushing the limits of 32-bit memory addressability and will soon need more. Given that there's thousands of engineers here in my company alone, and untold hundreds of thousands more involved in other types of simulation, is alone enough of a market opportunity for these CPU manufacturers to be pushing this technology. As for the home users, I'm sure the game writers will come up with ways to use that power too.

Re:Dumb question

[b-baggins]

Simply not true on the consumer end. Digital video is just beginning to come into its own, and modern PCs are still painfully slow in this regard. Do a high-quality mpeg-2 encoding job some time on your 3.8 GHz Dell and see how long it takes.

Re:Dumb question

[akuma(x86)]

It would be slower for most things and faster for some things.

With 64 bits you need to make the critical path of the processor wider (the ALUs, the register file etc...). The makes your circuits slower. You have the lost opportunity cost of frequency -- You could have made the processor run at a higher frequency with a 32 datapath - For those of you with a background in computer arithmetics, think about the carry-chain in an adder.

64 bit addressing means that your pointers now take up twice as much space as your old 32 bit pointers. This exerts more pressure on your memory system and makes your L1 and L2 caches appear smaller. It also makes your memory bandwidth appear narrower since you need to ship more data across the bus between the processor and DRAM.

The benefit of x86-64 is that it provides more registers. This means that there are fewer loads and stores which are used to spill and fill stack variables. This reduces the number of instructions required. It doesn't necessarily speed up the processor because stack variables would live in the store-forwarding buffer and would bypass the cache lookup, but you do have fewer instructions which means less pressure on your instruction cache and lower instruction-fetch bandwidth requirements.

There is a benefit for applications that naturally use 64-bit data types. This is a minor effect because many apps do not need the full 64 bit arithmetic.

The other big benefit is that you can now address a 64-bit virtual address space which is convenient for accessing large data structures.

Re:Dumb question

[the_greywolf]

More bits per instruction means

while i agree with you in principle, this isn't entirely true on a CISC-type architecture. x86 instructions can be anywhere from 1 to 8 bytes (and in some cases more), but in general, anything more than 4 bytes is uncommon. even in 64-bit long mode, AMD's architecture doesn't really increase the memory requirements for code. 64-bit instructions are, for the most part, the same size as the 32-bit instructions. if anything, 32-bit instructions should slow things down in long mode - because each instruction is preceded by a 0x66 byte.

Repeat after me 64-bits does not magically change anything.

no, it doesn't. i agree with you on that. but a 64-bit data bus sure as hell makes a lot of breathing room. and with code recompiled to take advantage of the additional registers (not to mention the fact that they're wider), code can run faster, more efficiently, and process more complex data.

The reasons these chips will most likely run apps faster is due to

don't forget the short(er) pipelines, additional execution units, additional registers, etc. AMD has done a damn fine job in making a good CPU. and they've done a damn fine job in making legacy stuff run fast.

yes, you're right - 32-bit should be faster than 64-bit. but it isn't. at least, not when it comes to the Opteron.

Re:Dumb question

[MarcQuadra]

Ahh, the difference is between 'Usable Space' and 'Address Space'.

I might only have 52MB RAM in my system, but I can 'Address' 4GB. So can you!

The 'big idea' behind the 64-bit address space is that it's huge enough to map everything (RAM, Disk, some LAN-storage, Video RAM, etc.) 'the same' so you won't need to treat disk space different than RAM. This has far-reaching consequences. Think of the PalmPilot (older ones), it had anywhere between 512K and 16MB RAM, and NO hard disk, it just treated running apps like stored files, not running them through the CPU when they weren't needed. It's a great idea, but it's very far away from what I can tell; the people aren't ready for it, developers, schools, nobody's learning this new paradigm yet.

You won't NEED as much RAM as disk space, you'll HAVE the ability to map the entire disk as a piece of 'memory' and get to it the same way you would get to an address in RAM, just slower. Overall it seems much more sensible, to have all the 'storage' on the same playing field.

In the meantime, we'll finally be able to slap over 4GB into our machines, and certain things will be faster. And we'll have to deal with motherboard changes a few times before the field 'settles down' on reasonable designs.

Re:Dumb question

[dimonic]

It seems everyone has read only one line of my question. For those of you who know who you are, Once Again: I suspect a 5 GHz CPU in a current system will not be twice as fast as a 2.5 GHz system. In fact, my own experience is that even in CPU intensive stuff, one will be lucky to get a 15% increase in performance. And for most jobs, this will not be noticeable. For some jobs, for sure, a fster CPU will always help. But better software would help all jobs.

WHAT I AM SAYING IS THAT THE BIGGER BENEFIT WILL COME FROM THE ADDRESS SPACE of 64 bits. In fact, 32 bit CPUs will probably be faster than 64 bit CPUs for many tasks, but 64 bit CPUs will lead to more reliable software.

Re:Dumb question

[Anonymous Coward]

Little niggle: 16-bit address spaces can only address 64 KB of memory, not 64 MB. That's part of the reason why 16-bit computing sucked, and yet 32-bit computing held us over for two decades. Until we get programs that really need 4 GB of stuff in (virtual) memory. The main advantage, though, is to simplify things and increase performance; just like with 16-bit, you can do anything with a 32-bit computer that you can do with a 64-bit computer (but it might requires a bunch of fancy hacks that nobody in their right mind would want to use these days).

Re:Dumb question

[Anonymous Coward]

Well, a little problem with that paradigm is that you don't want programs to be able to muck with another program's memory (memory protection), so you need to have duplicated memory ranges anyway. This is still only really useful if you need to map that much memory into one program's address space (I suppose it might cut down slightly on the context switch time, though).

Re:Dumb question

[Darren Winsper]

Yep, my bad, I just had MB stuck in my head.

Re:Dumb question

[dave1g]

"Games... I believe most gamers run closed-source code, so be careful. x86-64 will run faster, but you might have a hard time getting the software"

Actually game developers have been some of the biggest proponents of the 64 bit DESKTOP(more specifically the one designed by AMD).

I dont remember the quote anyore or who said it, so I dont expect you to entirely believe me. LOL I have good Karma so maybe that makes me more reliable? LOL But it went something like this, "We run into this certain 32 bit limitation everyday in our game developement process, and so we have to do some crazy work arounds. If we could write our code the way we need to the games would be MUCH faster"

So yeah thats like heresay...after amnesia but you will have to take my word for it, the games companies loves x86-64. But like others have said it probably has more to do with the increase in registers and not the 64 bit address space. But if you are going to make a jump, might ass well be a big one, right?

Re:Dumb question

[argent]

Unless your disk or at least your largest file is less than 2G (4G if you really stretch things), no, you can't use mmap the same way without a 64-bit OS design.

Plus, the 64-bit model would give you a persistent pointer to that file that could be passed to other programs or other computers and still uniquely address a byte-aligned object in *that* file, so long as they're in the same addressing domain.

Re:Dumb question

[argent]

Actually, it's treating the entire hysical memory as a realy fast disk cache. :)

Other things up their sleeve

[swordboy]

I think that Intel have some other tricks up their sleeve. See my journal for some screwy wishful thinking. What is cool about loads of on-chip NVRAM is that it opens up the possibility for Intel to ship an embedded operating system. The Wintel duopoly will reach new heights with DRM and Trusted Computing.

Re:Other things up their sleeve

[cynicalmoose]

Sun and IBM will be the major players in the future 64-bit boom

That would suggest that Linux would also be a major player. First mover advantage isn't dead yet.

Re:Other things up their sleeve

[Cyno]

The Wintel duopoly will reach new heights with DRM and Trusted Computing.

I don't see how.

I won't pay for any of it and I won't support anyone who does. Without people like me encouraging my friends/family to use their technology I don't see how it will be very profitable for them. They still have to make back their costs developing all this junk.

Re:Other things up their sleeve

[Anonymous Coward]

Furthermore, if consumers have any choice at all, it's well known that they won't go for a technology that limits their flexibility. Note the failure of the DivX player, the Intel CPU ID, and the rampant overriding of region codes on RPC-2 drives.

Latest and Greatest

[PRES_00]

All the latest and greatest processors are already invented. It is only a question of the companies to wait for the right time to let it out onto the market as to maximize profit.

This is why I don't let the hype get to me. I rather praise the companies that give me the greatest price/performance ratio for a given time. If you can buy it, then it's not cutting edge.

Dumb Answer

[!the!bad!fish!]

You would notice that 64 bits costs a lot more.

Sample Results..

[MosesJones]

After Sampling the new Chip Internally the general view was :

"Tastes like Chicken"

Further Internal Samplings are being conducted using Tabasco and BBQ sauces.

Re:Sample Results..

[Anonymous Coward]

Personally, I prefer the Salt and Vinegar chips.

Battle?

[Anonymous Coward]

Is this the beginning of a Linux+AMD vs. Windows+Intel battle?

Re:Battle?

[Anonymous Coward]

Uhh, AMD isn't on the side of Linux, any more than Intel is on the side of Windows. You should try not to confuse the big battle in operating systems with the big battles in CPUs. If forced to choose, both Intel and AMD would go for Windows before Linux; AMD even more than Intel, as they have more to lose and less clout. Note how AMD rushed to support Palladium.

Add-in module is for an *ITANIUM* coprocessor ...

[Anonymous Coward]

I don't believe Intel could bring themselves to adopt an AMD design. It is known that Intel was working on an Itanium-Pentium hybrid that failed due to development complexities. By going with the "add-in module" (like the "Numeric coprocessor" before it) they can still push forward with their original plan in a slightly different way.

For the moment, there are more tools and a slightly more mature development environment for IA-64 versus x86-64. But x86-64 adoption will come for free, whereas its going to be like pulling teeth even with this "module add-in" solution. On the technical side, things look grim for Intel, however, Intel is too resourceful a company to bet against.

The picture will be clearer 12 months from now -- it will be a Pentium V + an Itanium add on versus Opteron or Athlon FX. Intel's got to try to bank on outperforming AMD (no easy feet as the benchmarks on Opteron and Athlon FX demonstrate), otherwise their more expensive solution with be DOA.

Re:Dumb question - deserves a straight answer

[Crypto Gnome]

The best answer to your question is : not necessarily faster. Variables in this equation include but are not limited to:

• good motherboard support
• good OS support
• advanced multi-bit path to ALL hardware interfaces (eg them newsystem buses which are mostly not yet vailable)
• good fast RAM
• software recompiled to the 64-bit CPU
• actual use of 'benefits' of 64-bit computing (eg consumes unearthly amounts of RAM)

For you and I, JimBob and JoeBlow, a good fast 32-bit system will kick much 64-bit arse. At least until

• full OS (and driver) support for 64-bit mode
• apps recompiled for 64-bit
• fast mother with fancy-schmancy ultra-wide ultra-fast system bus
• new cards (*especially* video) on said new bus

x86-64???

[Glock27]

x86-64-bit processor will 'soon' arrive from Intel

Do you mean AMD64? Will the Intel chips really be fully compatible with an AMD-designed instruction set?

If this happens, it will only reinforce the fact that Intel has lost it's leadership position in the x86 compatible market. It will also severely impact any eventual large scale adoption of Itanium.

AMD just needs to bite the bullet and actually do some marketing. It has clearly superior products at this point. The Athlon 64 3000+ looks like a great buy, and a nice way to check out 64 bit computing at a low price point. If you have the money laying around, though, you really can't beat the PowerMac G5s. :-)

BTW, it's also too bad that Microsoft has delayed 64-bit Windows. It shows all too clearly that the "Wintel" partnership is alive, well, and smelly. On the other hand, it does provide a nice platform for Linux to tout it's superiority - "What's taking so long Microsoft, we've had an AMD64 version of Linux for months already!". So much for the "advantages" of Microsoft's software development practices... :-P

Re:x86-64???

[scharkalvin]

YES. M$ has put Intel on notice it will NOT support a third 64 bit processor under windows. If they want their x86-64 to run windows it WILL use the AMD64 instruction set, or it will NOT be supported.

Re:x86-64???

[NanoGator]

"If this happens, it will only reinforce the fact that Intel has lost it's leadership position in the x86 compatible market."

What?

Leadership is determined by who's got more out there, not by who's following whose standard. By your definition, AMD could never ever achieve leadership position because it's usinng Intel's instructions.

AMD may be a threat, but it has not ousted Intel, not by a long shot.

Re:x86-64???

[Glock27]

Leadership is determined by who's got more out there, not by who's following whose standard. By your definition, AMD could never ever achieve leadership position because it's usinng Intel's instructions.

No, leadership is determined by who introduces the technology that everyone will be using in the future.

You're talking about "marketshare" which is a different concept. ;-)

The fact that Intel has such a commanding lead in marketshare at the moment is mainly a glowing endorsement of effective marketing practices. The P4 has been a stunning failure as a technology - all it has really achieved is lower performance at 1/3 higher clockspeed (P4 3.2 GHz. vs. Athlon FX 2.2 GHz.). The only place that P4 excels is the SIMD instruction set, where latency doesn't matter - and those instructions don't help much at all with general purpose computing.

Intel Inside - Just Say No. :-)

Re:x86-64???

[sjwt]

heheh
a totaly mad idea..

rember the bundled graphics card and game idea
ATI had??

How about a doom3 + AMD64 chip :)
after all i rember reading (on /. so it must be true) that they will realise Doom3 with a 64bit version at launch..

Re:x86-64???

[Vlad_the_Inhaler]

My impression was that AMD are shipping all they can produce for a pretty high price.

A marketing offensive under these circumstances would be counterproductive - they would be spending money creating a need for product they could not shift in those quantities. AMD have been there before and it hurt them.

As for Linux and x86-64 support, the German C't magazine tested this recently and had some pretty major problems with some MotherBoards.
One of the changes between the last 2.6.0-test and official 2.6.0 kernels was a 'show stopper' with the x86-64.
This is all bleeding-edge stuff, I'll probably wait until Q2 before making the plunge.

Re:x86-64???

[Anonymous Coward]

One of the changes between the last 2.6.0-test and official 2.6.0 kernels was a 'show stopper' with the x86-64.

I'd go for Tyan when it comes to mobos. A bit expensive, but excellent quality.

Does anyone know if dual channel Adaptec AIC7902W will be supported any time soon on Linux? Mine crashers and burns horribly with 2.6.x.

Re:x86-64???

[ajagci]

Leadership is determined by who's got more out there, not by who's following whose standard.

No, the term "leadership" by itself is commonly understood to refer to "technical leadership", i.e., who sets the standard, not who moves more product. If there is any ambiguity, just be clear about it. In this case, from context, it should be clear that the term was used to talk about technical leadership.

By your definition, AMD could never ever achieve leadership position because it's usinng Intel's instructions.

The instructions Intel defined ten years ago don't help us determine who leads the industry now technically. What matters is recent changes, who made them, and who copied them.

AMD may be a threat, but it has not ousted Intel, not by a long shot.

And AMD may never "oust" Intel. But they can still be in a technical leadership position.

Re:x86-64???

[Anonymous Coward]

By your definition, AMD could never ever achieve leadership position because it's usinng Intel's instructions.

Seems to me that because of AMD leadership, Intel can't even decide to stop using it's own instructions.

Re:x86-64???

[mduell]

If you have the money laying around, though, you really can't beat the PowerMac G5s. :-)

Sure you can. It's called Dual Opteron :-) (or 4-way... or 8-way...)

Re:x86-64???

[Anonymous Coward]

Seems to me that because of AMD leadership, Intel can't even decide to stop using it's own instructions.

...using its own instructions.

Learn how to use a goddamn apostrophe, people!

Re:x86-64???

[Glock27]

Sure you can. It's called Dual Opteron :-) (or 4-way... or 8-way...)

I'd like to do a dual-Opteron machine myself, running Linux. However, if you want a nice, commercially supported OS, MacOS X seems the way to go. Even when Win64 actually ships for AMD64, it'll be distinctly second-rate compared with MacOS.

Performance wise, the G5s at least hold their own with Opteron, and they are able to handle twice as many double-precision FP ops per cycle. Altivec is also strong compared with SSE2.

Re:AMD

[Alan Partridge]

Specifically - our DPS Reality DDRs are NOT SUPPORTED running on AMD systems. We use Pentium 4 or we get not support.

I know that these issues have little bearing in your mom's basement, but in the real world shit like this MATTERS.

I don't doubt it at all...

[shfted!]

Guess the Rumours are True.

Re:I don't doubt it at all...

[mabinogi]

Wow, a Register article and an Inquirer article confirm another Inquirer article.

I'm shocked.

I start believing any of this when I see press releases. Or at least when slighlt more reputable news sources start reporting it.

Itanic == Titantic

[vpscolo]

You can help but think they might of chosen another name to start with can you? Of course they might of been hoping for the success of the film rather than the story of the boat sinking Rus

Re:Itanic == Titantic

[Anonymous Coward]

Intel called it the Itanium. The nickname "Itanic" was coined by people who expect it to be like the Titanic...

Re:What's next for Apple?

[Alan Partridge]

"I wonder what apple will do to counter Intel when they put their 64bit chip on the market?"

The same thing they always do with Intel - ignore them and hope that they go away.

How fast are things really getting?

[gotpaint32]

How fast are these processors getting lately! It just seems odd that a few years ago a jump in processor speed or architecture actually meant something significant. But lately I haven't been noticing this phenomenon as much. Clock speeds are skyrocketing at the same if not greater rate than in previous years but applications seem to demand proportionatly less cycles as time goes on. In 95 a computer could barely keep up with the demands for more memory, cpu speed and whatnot by programs making many computers unusable after about a year. Now we see in a years time improvements in opening photoshop a few seconds quicker than before. Please dont flame this post saying that IA64 is meant for high end servers and workstations, I realize this, but is advancement in clock speed and architecture really as important a step as it used to be.

Re:How fast are things really getting?

[argent]

That's because a lot of these clock speed improvements are "marketing MIPS".

To speed a computer up, the best way is to look for what's slowing it down the most, and speed that up.

To sell more computers, the best way is to look for what's easiest to speed up, and advertise that as the big advantage.

It's actually possible for a clock speed improvement to be accompanied by other changes that slow down some programs. Intel hit that when the first generation XScale was used in the Pocket PC... the big bottleneck for video on the ARM chips used in the Pocket PC was memory bandwidth... they had 206 MHz processors and 100 MHz memory and people were trying to play videos from memory cards that were far slower than that. They sped up the ARM instruction set on the XScale by breaking the instructions up with a longer pipeline. What happened? Well, that longer pipeline actually increased the impact of the slower memory by increasing the impact of a "bubble in the pipeline" when it had to go to main memory instead of cache to load instructions or when a mispredicted branch forced it to discard partially completed instructions, and on some benchmarks the 400 MHz XScale was actually slower than the 206 MHz StrongARM... and some vendors actually ran the XScale at 200 or 300 MHz!

The second generation XScale's 200 MHz bus largely solved that... at the cost of having to use faster and more power-hungry RAM. Everything's a tradeoff.

So, if you have a computer with a 266 MHz memory bus... how much difference do you think you'll see going from a 700 MHz processor to a 1.4 GHz processor or even a 2.1 GHz one? Well, that depends on what you're processing! If your program and its data is small enough to mostly fit in the cache, you'll get a big boost. If you're playing a videogame with megabytes of graphics being shoved down the AGP port to the video card, probably not a whole lot... save your money and upgrade the graphics card instead.

And that's why memory chips keep changing, they keep coming up with faster and faster memory... but that's falling further and further behind the marketing MIPS because there's a lot fewer tricks left to pull to market those numbers up.

Re:How fast are things really getting?

[curious.corn]

Well, I suspect there's not much technical advancement or breakthrough as far as chip technology is concerned. All I see is heaps of on-chip memory and ever so complicated preemptive code execution logic. The CPU translates the dog old IA2^n instructions (still there for compat/market stranglehold) into it's own language to run like a JVM or Tranmeta. I think all this sums up to having a compiler hardwired in silicon; which also explains the amount of pipelining and frequency scaling: these operations are quite cumbersome and require loads of gates to perform. So, it's quite obvious that slicing the combinational stuff, throwing luts in the mix and just tweaking the "compiler" makes some difference. It's quite boring as far as I can tell and somehow feels like running on the least commom factor. I'd be interested in reconfigurable logic, compilers that recognize algorithmic patterns in code and instruct the Processing Unit to morph into a hardware representation of it. Away from the single stack, program counter model! multiple thread cores (32?) arbitrating the flow from one hw-alg to the other... oh well Microsoft will never recompile it's sw to anthing that isn't intel so it's just a daydream...

Re:How fast are things really getting?

[inode_buddha]

"...but is advancement in clock speed and architecture really as important a step as it used to be.

Weird; I thought *I* was the only one who noticed this (using linux here). Up to now, my usual response was to get more RAM, but even that has a diminishing return. Then I started getting CPU's with large cache (>1MB) and praying for good branch prediction. I'm convinced that I've got all the hardware I'll need for a few years, and probably won't upgrade until I can get Xeons on E-Bay like you do with 486's now. This tells me that the bottleneck lies elsewhere, probably getting the system bus up to speed with the CPU clock for both disk and memory I/O. This is regardless of being 32 or 64 bit. IOW, PC-133 memory or 66 mHz utlra-ATA makes little sense at gHz processor speeds.

What good is a huge engine if you can't feed it fuel fast enough?

Re:How fast are things really getting?

[MarcQuadra]

I'll take that another step. For those of us with 1+GHz machines, what do you actually have to WAIT for? Very few people I know have to WAIT for their computers at all except for opening apps and browsing the web, which isn't even contingent on bus speed, it's I/O-bound. The BEST way to improve 'speed' on the desktop is to move to a lower-latency disk subsystem, one that can handle multiple concurrent I/O requests. If you've never tried slapping a nice SCSI drive into an older desktop you don't know what I mean, it's a WORLD of difference.

As for some of us, we really do notice bus speed/clock speed/cache size improvements, I do a lot of compiling on my Athlon-XP '2500+' and that's an all-around performance hog.

Re:How fast are things really getting?

[Anonymous Coward]

Actually, the whole program doesn't have to fit into the cache, just the current working set. This is true of most programs, even multigigabyte games.

Memory bandwidth doesn't have as much real world impact on desktop CPUs as it might in the case of the XScale (which probably doesn't have as much room for caches); we can't boost memory bandwidth very far anyway (compared to the ramp in processor speeds), and the performance boost is significant but small. Reducing memory latency is a big win compared to memory bandwidth improvements (hence the integrated memory controller on the Athlon), but again, in the big scheme of things, it's not such a big deal.

This is one reason why increasing the size of the CPU caches is one of the primary ways CPU manufacturers increase CPU performance between major architecture generations: as programs use larger and larger working sets, CPU caches need to increase to keep up (but in general, most programs can fit fairly well). In the ideal world, you'd have a 4 GB CPU cache.

On the other hand, real world results often submerge memory issues. For example, increasing the size of the L3 cache on the Xeon does almost nothing for performance, even in high end applications. The L3 cache just isn't that big a part of the memory infrastructure, compared to what you already get with the L1 and L2.

The number of gigabytes you have to push to your graphics card doesn't go through the processor at all, for precisely the reasons mentioned (it'd overload the CPU bus). Instead, it's transferred via DMA directly between main memory and the video card, without contending with the CPU bus. Stuff like geometry can be generated at the CPU, although modern engines are pushing more and more stuff to the GPU.

Another interesting sidenote: this year and next year, NVIDIA and ATI are moving their high-end cards exclusively to the next PCI standard, PCI Express (in the X16 form factor). That should mean lots and lots more bandwidth, and system designers will be able to easily boost the PCI performance by dumping more and more PCI Express channels on to their motherboards (as it's a serial bus like HyperTransport... and I suppose I should mention Rambus...).

Re:How fast are things really getting?

[argent]

Until recently I'd never been in a situation where I had to run multiple IDE drives in master-slave mode, and had been thinking that IDE had been getting pretty nice. MAN did disk I/O performance take a hit... and arranging things so I could avoid concurrent access to those two drives was a BIG help.

Even going to a not-so-nice SCSI drive (Quantum Fireball) to avoid that IDE bus locking made things nicer.

Re:How fast are things really getting?

[MarcQuadra]

I've said this before, I 'upgraded' from a 60GB ATA/100 drive to a 9GB Ultra2Wide (80MB/sec) SCSI drive. My applicatiopn launch times are ONE THIRD what they were when using the ATA drive. Both were 7200 RPM.

I also get better performance on my NFS-mounted SCSI drive than I do on most locally-mounted ATA drives.

The sequential throughput of a drive is a function of RPM and density, but the 'real-world' performance is helped primarily by TCQ and superior buffering.

Internal use only

[ChaosMt]

"...article that says that the chip is to be sampled internally this month."

Perhaps I'm up too late, but when I read the above, this image of a windows developer flashed in my mind. He's frustrated with a child-proof cap and resorts to reading the side of this bottle from Intel: "For marketing use only. Do note mix with alcohol or windows. New buffer exploits are inevitable. May cause loss of market share if ingested."

Re:AMD

[jarryd]

I find they only really "dominate" in with 64 bit architexture with their Opteron, but again, Intel hasn't yet released their own "desktop" 64bit cpu.

Intel (as far as I know) are trying to increase cpu speed and reduce the die (or the cpu) size.

Linus' opinion on 64 bit desktops

[anti-NAT]

Linus Torvalds on 64bit desktops

Linus Torvalds on 64bit desktops

just what we need

[Anonymous Coward]

Great just what we need. another patch on a 20+ year old design. its not Apple who needs to switch platform's its us the whole x86 platform should be dropped. Apple has been able to pull off a proccessor change from the m68k to the PPC and they were able to mantain compatibly with legacy apps in emulation.

Re:just what we need

[the_arrow]

Apple has been able to pull off a proccessor change from the m68k to the PPC and they were able to mantain compatibly with legacy apps in emulation.

And this month we will (finally) see how well AmigaOS has been able to do the same thing.

Re:just what we need

[fitten]

It's much easier to do (not that it isn't as hard as hell - just a lot easier) when you control your hardware. Apple maintains control over its hardware which makes the OS easier to build and maintain as well. If Apple had 100s (if not 1000s) of companies that built hardware for the machine that were required to update all their drivers and such, they'd have had a much more difficult time at it.

back in the day...

[lithiumfox]

Remember when everything was simple, no color monitor, simple keyboard layout etc. Back then, my Tandy3000 and I could take on the world.

Did I Miss Something?

[los furtive]

...they also predict that Sun and IBM will be the major players in the future 64-bit boom

Isn't IBM already a major player?

Re:Dumb question::Even Dumber Question

[Cragen]

What for? Ok, I realize the Universe does not end at my network connection. I really have little need for more speed, but, obviously, someone does. Who, please? Doing what? With what goal in mind? Seriously. (It would be interesting to know what the big dogs do or want to be able to do.) Thanks,

*cragen.

twas a noble idea by intel

[kraksmoka]

for a change, to break backwards compatibility, but we have to ask them. WHAT THE HELL WERE THEY THINKING THIS TIME???? finally, x86 becomes THE commodity platform and they try to kill it ?? ? ? makes no sense. AMD knew what was up all along. IBM did the same with its 64 bit offering, and Sun still makes slow processors (fun to complain about hardware too).

anyway, they screwed the pooch, but will never correct the mistake. when you've got a few billion dollars, you can wait just long enough to lose most any amount of money on a new product.

Re:twas a noble idea by intel

[Vlad_the_Inhaler]

I was at a Linuxworld talk around 14 months ago and someone from AMD (a VP?) held a keynote speech on this processor, one that was sufficiently convincing for me to go out and buy some shares in the company :-)

He could not understand what Intel were up to either.
Linus made a similar point later around the time he left Transmeta and added the rider that the Itanium was based on bad design decisions, irrespective of compatability.

Re:twas a noble idea by intel

[alexq]

I see things differently.

Intel was the market leader, but they weren't completely stupid. The x86 architecture is one of the worst imaginable - the pentium pro's design involves a pipeline that was some obscene number of stages deep (i forget, but it was in the double digits). If someone would like an explanation of what this means, please reply and I'll post it, but I'll keep things simple for now.

Essentially Intel saw that there was only so far they could take the x86 architecure, and realized that to stay successful, someone would have to eventually replace it with something. They decided it should be them (while in the meantime presumably working on this backup plan). The problem is that IA64 (itanium) is kind of crappy - it's a very academic design which lacked a lot of forethought (if anyone wants me to soapbox on this reply as well please)...

I once met Bob Colwell (one of the head architects an Intel - I think he's an Intel fellow) and asked him what he thought about the Intel architecure.. he responded "oh, it's crap".. but he defends supporting it by saying that it's the only way to continually support the code base, and they've done a good job of extending it - I bet most people back then would have never guessed it would come as far as it has.

An old joke:

q: What're the two worst microarchitecures out there?
a: Sun and X86, obviously.
q: What're the two most successful microarchitectures out there?
a: Sun and X86.
I guess DEC should have stuck with VAX

really, the lesson there is that code/install base _is_ very important - and Intel was trying, in the best way they saw how to bridge the gap to a new architecture which they had control of(which might have worked if IA64 didn't, well, IMHO suck).

NO

[1ini]

No they will not.
Intel likes to keep its architectures separated. They have Pentiums/Xeons for 32bit and Itaniums for 6bit processing. Releasing a x86-64 CPU will kill the Itanium plain and simple.

Re:NO

[Crypto Gnome]

Itaniums for 6bit processing

I always thought Intel was a few slices short of a loaf, but that's just ridiculous.

Re:NO

[spektr]

Yes, Intel's new 6bit processor (aka Hexium XR) will be ridiculous, but very successful. The 512k stage pipeline and the 6 bit architecture lets it run at frequencies above 35,000 THz. Faster than light speed - ridiculous speed! This high rpm wonder wins the race in the first gear - who needs a second one! Please pay attention to the specified safety margins and stay out of the way of the leaking X-rays.

Re:NO

[Anonymous Coward]

This is why we should all move to bit serial architectures: we'll never need to worry about the ideal number of bits.

Will They?

[Anonymous Coward]

Don't be ridiculous. They have a virtual monopoly of the chip industry, I'm sure they can milk some more from their current offerings.

Too Much Work

[InvaderXimian]

I don't think MS could port Windows to all those different architectures (they can't get one right) so perhaps they'll either need more people, make it open source within a select few MS Devs or something or just make it really crappy.

Think about it, optimizing an operating system for 4+ archs is no easy task and I doubt MS could do it in a reasonable amount of time.

Maybe they'll hire the Duke Nukem: Forever developers on that one.

Re:Too Much Work

[cchd]

But Microsoft already did this. NT4 was originally developed on MIPS and then "ported" to IA32 and Alpha. Most of the original work on the 64bit Windows for Itanium was done on Alpha (as no Itanium chips were available). Assumint that no new 32 bit dependancies have been built into 2000 and XP (big assumption here) then a simple recompile should get things moving on other architectures again.

Re:Too Much Work

[hackstraw]

I don't think MS could port Windows to all those different architectures

Thats why linux, solaris, the BSDs suck. For example:

mlap:~/src/linux-2.6.0-test9/arch% ls -1
alpha/
arm/
arm26/
cris/
h8300/
i386/
ia 64/
m68k/
m68knommu/
mips/
parisc/
ppc/
ppc6 4/
s390/
sh/
sparc/
sparc64/
um/
v850/
x86_ 64/

Re:Too Much Work

[fitten]

...and why there is .NET

The perform the same, really...

[Anonymous Coward]

Both high-revving and high-torque, low-rpm engines pretty much perform exactly the same. The great equalizer being the gearbox (transmission). You don't have to believe me though, it's common racing knowledge. Instead of doing all the research work for you (cuz /. geeks are just soooo lazy to do any of it themselves) I'll give you this here link to a book that explains all. If you actually give a damn about facts and truth, you should read it

Will AMD's x86-64 and Intel's x86-64

[Sarojin]

architectures be compatible? If they aren't, that could be quite a hassle

Re:Will AMD's x86-64 and Intel's x86-64

[InvaderXimian]

The Itanium2 architecture isn't compatible with anything of AMD's. I believe x86-64 is also refered to AMD64, which is the Operton. Just remember x86-64 as a 64-bit processor with regular 32-bit app support. If you don't remember the release of the Itanium processor, help you refresh your memory: It sucked. Well, it wasn't compatible with any other current OS and it could run some 32-bit applications but it was horribly slow. As you can tell, it didn't do very well even though companies like HP hoped it would.

Re:Will AMD's x86-64 and Intel's x86-64

[tuffy]

Intel is free to implement AMD's x86-64 architecture in their own chips. And they most certainly will, since creating an entirely new, incompatible architecture is a lose for both AMD and Intel. Whereas making it a standard is a win for both companies and the sort of thing that can push new chips to consumers.

Re:Will AMD's x86-64 and Intel's x86-64

[OS24Ever]

they will most certainly not support AMD's instructions. Their instructions set will have to be different otherwise they will license something from AMD which they will never do with their current market position.

Re:Will AMD's x86-64 and Intel's x86-64

[tuffy]

they will most certainly not support AMD's instructions. Their instructions set will have to be different otherwise they will license something from AMD which they will never do with their current market position.

Intel doesn't have to license anything from AMD to implement x86-64; Intel already has permission to use it without per-chip royalties because of previous cross-licensing agreements. The only thing preventing Intel from going that route now is because of pride and keeping the Itanic on life support. But I expect that'll change sooner or later.

Re:Will AMD's x86-64 and Intel's x86-64

[ceswiedler]

I believe that Intel already has an agreement to use AMD's x86-64 instruction set, if they choose to. I don't know what the licensing terms were, and of course, Intel is free to develop their own extensions. But as another poster said, Microsoft would be very unhappy with that.

Re:Will AMD's x86-64 and Intel's x86-64

[Wiz]

Intel does have a license for x86-64, there is nothing from stopping them from making one!

Other than shafting the Itanium of course!!

Re:Will AMD's x86-64 and Intel's x86-64

[Anonymous Coward]

Except that Microsoft have said they won't support yet another incompatible architecture. They support IA64 and AMD64, but if Intel release something else that's not compatible with either, Microsoft won't support it.

Very Likely

[turgid]

Intel will very likely release a 64-bit x86 processor, or kludge unit for Pentium V, this year (just like the math coprocessor was prior to the 486).

However consider this:

AMD has been shipping Opteron for nearly a year already, and ports of the main OSs (including Windows and Linux) have been done, with others already working in the lab. It also runs old 32-bit OSs with no change. It will run legacy x86 code at full speed along side new 64-bit code. It is more efficient in terms of useful work done per clock cycle compared to Pentium 4 and Xeon. It scales better in multi-way systems (very important in workstations and serves) : the logic is built in. Xeon does not have this (and plain P4 is limited to single-way). It has a built in memory controller. It has twice as many registers. It's very inexpensive. Go and look up your favourite component retailer right now and compare an Opteron to a Xeon (and even the "high-end" Pentium 4).

The only place AMD may have trouble selling is to the ignorant masses who buy on MHz (or GHz) from highstreet stores, and pay too much.

The corporate world is more clued-up, and so are the enthusiasts and power-users.

Even if AMD does not knock intel off of it's perch, there is a huge potential market for Opteron. Several major corporations are behind Opteron. They've committed to it. It's going to be big business. 2004 will see a radical change in the hardware business. I predict that in the second half of this year, people will laugh a 32-bit PeeCees. They will be obsolete and bargain-basement by then.

Re:Very Likely

[The One KEA]

It took 11 years for 32bit operating systems to finally displace 16bit operating systems. Your prediction of 32bit PCs being laughed at by December 2004 is probably a little too radical.

However, your other comments about AMD and the Opteron are spot on, IMO - the enterprise world is NOT going to buy a competing, slightly incompatible 64bit platform when it has already invested in another 64bit platform that is ALREADY AVAILABLE and is KNOWN to be just as fast/faster than a 32bit commodity platform or an older 64bit platform like a PPC box from IBM. It's hard enough these days for IT departments to support the current heterogenous mix of 32bit commodity desktops and servers and the old/new 64bit platforms from AMD and IBM. Throwing in a third which could cost even more and add more headaches would be pretty hard to sell, IMHO.

You were also right about marketing; AMD abolsutely MUST find a way to conclusively show that GHz != Speed. They need a new aggressive marketing campaign ASAP - unless the rumours about Prescott being a bit of a dud are true.....

Either way, AMD knows that they're sitting on a goldmine; they just need to exploit it as much as they can.

Re:Very Likely

[turgid]

It took 11 years for 32bit operating systems to finally displace 16bit operating systems. Your prediction of 32bit PCs being laughed at by December 2004 is probably a little too radical.

Sun and DEC brought out 64-bit hardware and Operating Systems around 1994-1995. This is now 2004. I don't think my prediction is radical at all.

Re:Very Likely

[The One KEA]

That was for corporations, where naturally OS turnover and hardware upgrades are far more likely to take advantage of the latest and greatest, once they've been sold to management. I was referring to the consumer and small business market; IIRC they were the last bastion of 16bit OSes simply because they couldn't be as easily convinced to upgrade. What they had worked for them and they felt that they didn't need anything better.

IMO, that's part of the problem with 64bit computing: the only people who are adopting it are corporations, enthusiasts and scientists - all three of these groups require or desire the abilities that a commodity 64bit platform, compatible with the vast installed base of 32bit software, is able to provide. Once the n00b masses of grandmas, Joe Sixpacks and organized-sports parents can be convinced to buy 64bit platforms, then I believe 32bit will be booted for good.

Re:Very Likely

[Anonymous Coward]

Your predictions are radical if you consider that people have used these AMD domination arguments for years. And yet, AMD still has a rather tiny market share. Don't dismiss the power of marketing and momentum. Just because a technology is better does not mean it will dominate, even if a lot of people know it is better. Look at Beta vs VHS.

Re:Very Likely

[Anonymous Coward]

Prediction: In the second half of this year, you will be laughing at 32-bit PeeCees. They will not be obsolete, and they will not be bargain basement.

You're forgetting that 95% or more people don't even need 64 bits! Do you? When was the last time you needed a flat address space > 4GB? In the real world, where people have mortgage payments and kids and can't afford to buy the bleeding-edge every three months, 32-bit PC's will still dominate in the home market. With 64-bit Windows just released and unproven, the corporate market will be leery of upgrading their new hardware to 64-bit. And again, most corporations don't even need 64 bits. And don't kid yourself for a second that they're "clued in". If they were, they'd have bought AMD Athlons in droves. But Intel still dominates, largely due to marketing and to large manufacturers like Dell who have sold their souls to Intel.

Re:Very Likely

[Mojo Trolljo]

Your prediction is wrong. It will take much longer than next year (if ever) when Opteron starts to become "mainstream". The biggest reason is application availablility along with essentially non-existant tier-1 vendor support.

I can list about 4 software products that I know of that currently take advantage of the AMD64 instruction set (two of them are OS's, the main one not even released yet!). Currently, there is no AMD64 java, no *good* AMD64 compilers -- MS or Sun will likely have these by end of next year, but may take even longer to mature AND the Sun compiler will be Solaris only.

No corporation is going to spend their budget on new AMDs under these circumstances. The development environment well.. sucks and what's the point of upgrading your hardware if you only want to run 32bit x86 binaries?

As for scaling to multi-way servers, etc. Show me an example? If a corporation is going to spend on large SMP boxes, I doubt x86 compatability is at the top of their list of priorities. They will already have Power, Sparc, or IA64 big iron.. Yes, Itanium. Which is already in 64-way boxes and soon to be in 128-way boxes. Show me such scalability with an opteron!

Re:Very Likely

[turgid]

t will take much longer than next year (if ever) when Opteron starts to become "mainstream".
Opteron is already mainstream.

application availablility along with essentially non-existant tier-1 vendor support.

Let me put it this way: you are living under a rock.

what's the point of upgrading your hardware if you only want to run 32bit x86 binaries?
The performance on legacy code alone is enough to warrant the upgrade.

Show me such scalability with an opteron!
Cray will be doing so soon, I believe with 10,000+ Opterons in one machine, and I'm sure you'll be pleasantly surprised.

no *good* AMD64 compilers
Ah, so you haven't heard of Pathscale then?

This year promises to be very interesting indeed.

Re:Very Likely

[Mojo Trolljo]

Oh, I am living under a rock... I will bite troll.

Opteron is already mainstream.

Of course it is because Overclockers UK says so. Nevermind that Windows isn't even released for it! Oh yes, Linux x86-64 is mainstream, I forgot.

10000 Opterons in an SMP?? You have any clue what you are talking about??? Show me a link for this (I'm not talking clusters either because they can be made with anything) instead of spewing AMD fanboy crap.

I remember the same thing happened when Athlon was first released and was first to 1GHz and would beat pentium in all the benchmarks for a cheaper price. I also remember Intel coming back strong and eventually winning the x86 performance race.

Re:Very Likely

[Anonymous Coward]

I did AMD a couple years ago with a Via chipset. It was riddled with annoying problems. It's going to take a lot of coaxing to get me to put another AMD box on my desk.

--

Re:Very Likely

[turgid]

Nevermind that Windows isn't even released for it
Real computers don't run Windows.

10000 Opterons in an SMP?? OK, Red Storm isn't SMP, but Opteron has hardware to make it natively scale to 8 way. You can engineer your own glue logic (like intel does with the Xeon which only natively goes to 2 way) to make it scale beyond this. Once you get beyond a few thousand processors, you need a different kind of parallel architecture (regardless of CPU) like NUMA, cc:NUMA, COMA, some kind of low-latency clustering etc.

As for fanboy crap, we'll see.

Intel may come back strongly indeed, but at the cost of billions of dolars, the resigning of itanic to a very small niche (a few thousands of CPUs sold a year) and being forced to adopt their main competitor's (and hitherto underdog) architecture.

Re:Very Likely

[Anonymous Coward]

And where is that 64-bit hardware brought out in 1995 right now? Alpha is dead. Sun is alive, but not at their healthiest by any means - fat lot good did that 64 bit hardware do to them both.

Opteron is a damn good piece of work, but it's evolutionary, not revolutionary - nobody is going to toss their brand new P4/Athlon XP 3200 to trash can because it's somehow made "laughable" by a design that's not really even that much faster.

People who've sticked to their 500MHz systems that are good enough for the little they do aren't going to flood into stores and get replacements because they're buzzword-64bit.

32 bit systems are not going to disappear overnight, or even overyear, it'll fade away gradually as old things will get replaced slowly.

Rumor?

[Mys*lf]

I heard that the Prescott includes a set of deactivated 64bits instructions, can someone confirm?

Re:x86-64??? que?

[Crypto Gnome]

You forgot to add "bork bork bork" to the end of your post (ie Swedish Chef Mode).

Re:AMD

[Caeda]

And it's amd's problem how? Seems you should get on the ass of the company that makes the fucked up card that they decide doesnt work with amd, not amd for having their own proccessor. In the real world morons like you figure that out without making retarted posts like that.

Re:Pentium V , modems

[tomatobasil]

7 Ghz - Cool beans - so how fast will it *feel if I ram it thru the same old 56k modem with the usual awesome 4k sustained thruput rate ?

Re:AMD

[Alan Partridge]

That's EXACTLY AMD's problem. People like me can't buy their gear even though we'd like to because third party developers don't bother to support AMD CPUs.

Funnily enough, it's not my business to crusade on AMD's behalf, I have actual work to do. I'd far rather use a Mac anyway.

Re:Dumb question - deserves a straight answer

[Webmonger]

For you and I, JimBob and JoeBlow, a good fast 32-bit system will kick much 64-bit arse.

This isn't valid. x86-64 systems can run 32-bit apps at full speed, so they'd be kicking their own arse.

Also note that x86-64 corrects some of the weaknesses of the x86 architecture, so x86-64 apps are automatically faster. Counter-strike was 30% faster, clock-for-clock.

Re:Dumb question - deserves a straight answer

[Anonymous Coward]

Exacly. But there is an additional aspect that isn't mentioned here: all new hardware has a breaking in period where the drivers and support isn't mature.

The end-user difference between 32 and 64-bit is the potential. 64-bit will, after getting some time for the hardware and drivers to mature, smoke even the fastest 32-bit chips.

Re:Dumb question - deserves a straight answer

[inode_buddha]

True, all your points. I just couldn't help but think that this is the kind of thing that Alpha CPU's have been doing for years. Kinda expensive, though. Cray supercomputers come to mind.

Re:AMD

[sjwt]

And this is differnt from the rest of there ground brakeing efforts how exactly =>

It's not the bits, it's the instruction set.

[argent]

The big problem with the Pentium isn't that it's only 32 bits wide, it's that the instruction set is so poorly designed. It's complex and hard to execute quickly, doesn't have enough registers, REALLY doesn't have enough floating point registers, has too high a cost to transferring data between the CPU and FPU, and huge chunks of silicon have to be used to cover for these faults.

Intel has tried to patch this with extended instruction sets before, like MMX, but they haven't been able to discard the legacy design. The last big improvement in their architecture was when they went from the 286 to the 386, and were able (eventually) to shed the overhead of 16-bit segments. Mostly... and they did that by making it a completely different mode instread of a patch on the existing instruction set the way the 8086-80286 transition was.

If their new "extensions" have a better instruction set, they will be able to perform the same kind of break without losing their existing user base. They tried to do this with IA64, but the processor was too slow and the IA32 "mode" was WAY too slow. It remains to be seen whether the new chip does a better job.

If they had been smart, they'd have kept the Alpha EV8 team intact after they bought them from the Compaq fire sale, renamed it the "IAXP", and shipped it with a hardware IA32-Alpha recompiler for legacy support.

Re:It's not the bits, it's the instruction set.

[The One KEA]

So what's your opinion on the AMD64 core and instruction set? Does it inherit the same problems in the core's 64bit modes, or do those 64bit modes actually remove some of the limitations of the original x86 instruction set? For example, you cited the lack of registers onn the x86 platform. The AMD64 platform has twice as many registers in the 64bit modes, both standard and SIMD registers; is this an improvement? Or does it come down to good compiler support?

Re:It's not the bits, it's the instruction set.

[turgid]

The big problem with the Pentium isn't that it's only 32 bits wide, it's that the instruction set is so poorly designed. It's complex and hard to execute quickly, doesn't have enough registers, REALLY doesn't have enough floating point registers, has too high a cost to transferring data between the CPU and FPU, and huge chunks of silicon have to be used to cover for these faults.

AMD has solved these problems in the Opteron (and Athlon 64) by doubling the number of integer registers (to 16) and making them all general-purpose, and by implementing SSE2 (again, with 16 registers compared to the Pentium 4's 8) for fast floating point. SSE2 allows you to explicitly code two double-precision floating point adds or multiplies to execute in a single clock cycle (or 4 single precision ones). It also does scalar FP, and does it much faster than the legacy x87 floating point hardware (which is still there for backwards compatability).

Re:It's not the bits, it's the instruction set.

[argent]

Sixteen registers is still pretty slim (about the same as the original 68000 or the creaky old 1802, and definitely on the low side compared to the Alpha or IA64), but sixteen general purpose integer registers and sixteen floating point registers is certainly a big step up.

I would have preferred them to make a cleaner break with the legacy instruction set, but I suppose they figured their just-in-time recompiler makes the instruction set details less critical, and since x86 compatibility isn't going away they can't save any silicon by exposing RISC ops to the compiler.

Re:It's not the bits, it's the instruction set.

[alexq]

I agree with you on just about everything (unique for slashdot? ;)... especially about the EV8 team and processor - unfortunately instead (as you probably know) they've simply reassigned the entire ev8 team to "fix" itanium. We'll see how that goes :\

Licensing?

[B5_geek]

Does anybody know if the extensive cross-licensing agreements that exist between AMD & Intel cover the x86-64 additions?

Would that not be the cats meow if Intel had to pay AMD royalties for each chip they sold?

AMD fan or Intel fan; we are damn lucky that there is competition.

Re:Licensing?

[tuffy]

AFAIK, Intel is already licensed to implement their own x86-64 chips without the need for per-chip royalties.

Old News

[explorer]

Most of the articles linked to are pretty old. Only two are even from this month, and they're from Friday/Saturday. Yawn.

Let's keep it current.

Re:Better Question

[zontroll]

I used to work for them a few years ago and I agree with the fact that marketing tries to push stuff that the public doesn't necessarily want. They're definitely not as egregious as micro$oft in this regard, but they do try.

fragmented Linux???

[ajagci]

At this rate Windows will become as fragmented as Linux ;-)

What do you think is "fragmented" about Linux? The Linux kernel is the same on every distribution. All major distributions have the same file system layout. The main thing distributions differ in is package management and pre-installed software, but Windows doesn't even really have package management, and the pre-installed software that ships with Windows differs from one PC model to the next.

And Windows manages to be this fragmented just in the consumer space. In addition to Windows XP/Home, we also have Windows XP/Professional, Windows XP/Embedded, the still-supported older versions (2000, NT, ME, 98), and Windows CE and its varieties (PPC, etc.).

Seems to me Windows is already far more "fragmented" than Linux.

Re:fragmented Linux???

[Anonymous Coward]

What do you think is "fragmented" about Linux?

The fact that there are 200 different versions that take forever to learn because they are deliberately-microsoft-style-different

The Linux kernel is the same on every distribution.

true

All major distributions have the same file system layout.

Yeah, right! Different versions of the SAME distribution don't even have the same filesystem layout, much less different distributions. This is the one thing almost guaranteed to be different.

The main thing distributions differ in is package management and pre-installed software,

Which has become such a differentiating factor, religeous wars all but consume some boards and lists.

but Windows doesn't even really have package management, and the pre-installed software that ships with Windows differs from one PC model to the next.

Hardly. IE is there, outlook express is there, and the MS Office install works without crashing on every version, and installs its crap in the same place on every system, unlike linux-compile-dumped-the-files-where? fun you can have with open sw.

Don't get me wrong, I'm playing devils advocate here (many more Linux boxes around me than Windows), but lets be honest, if the current path leads to 'world domination' then the enemy wasn't nearly as formidable as everyone thought.....

you are so wrong

[ajagci]

Repeat after me 64-bits does not magically change anything.

Even if you run just 32bit applications under 64bit Linux kernels on the Opteron, your 32bit applications magically get almost the full 4G address space to themselves, because the 64bit kernel can relocate itself out of the user's address space. That alone is enough justification for a 64bit x86 for many server applications.

The reasons these chips will most likely run apps faster is due to

Yes, and you know what those changes are there for? They are there because the chip supports 64bit instructions. Theoretically, you could put them into a 32bit-only chip, but that would make little sense. x86 chips can, after all, already address more than 4G of memory, so even the address lines are there. So, if you go through all the trouble of turning your chip into a full 64bit architecture, you might as well add the instructions to take advantage of it.

Think of it this way: the "64bit" moniker for the Opterons really tells you that they have been built as the next generation, fast 32bit architecture that uses wider data paths, and the 64bit instructions are just icing on the cake.

Yes, you heard right... slower. [...] More bits per instruction means

But you don't move more bits per instruction if you don't have to. The Opteron chips run 32bit code faster than previous Athlons. 64bit processors, even those without a legacy 32bit architecture attached, have instructions for manipulating 32bit data just fine. It is just that when your program needs to work with 64 bits at a time, it can do so more efficiently.

In fact, in well-written 64 bit code, the amount of additional memory used and data moved by the application should be small. Of course, in some C/C++ programming styles, pointers are everywhere, and those kinds of applications will almost double their memory usage and bandwidth--but that is fixable.

Re:you are so wrong

[p3d0]

But you don't move more bits per instruction if you don't have to. The Opteron chips run 32bit code faster than previous Athlons. 64bit processors, even those without a legacy 32bit architecture attached, have instructions for manipulating 32bit data just fine. It is just that when your program needs to work with 64 bits at a time, it can do so more efficiently.

No, you're hosed when you use pointers, as you mention. Which is a LOT, no matter what language or programming style you use. (Not sure how it could be "fixable"...) For instance, your stack now must be twice as large because each stack slot is 8 bytes instead of 4. Your page tables only hold half as many entries. And so on. Basically everything takes up more space.

In the Java world, typically half the heap is pointers and the other half is ints. (The other types are negligible.) So you should expect your heap to grow by 25% and put that much more pressure on your memory system.

However, in practice, apps recompiled for AMD64 extensions tend to run a bit faster than IA32 apps on the same hardware, because the benefit of the extra registers outweighs the costs of bloated pointers.

Re:you are so wrong

[ajagci]

No, you're hosed when you use pointers, as you mention. Which is a LOT, no matter what language or programming style you use.

Quite wrong. Many languages have neither pointers nor object references (Fortran, Prolog, Haskell, etc.).

For instance, your stack now must be twice as large because each stack slot is 8 bytes instead of 4.

The stack is dominated by data, not by those two pointers, so that is insignificant (if it were signficant, it woul be easy to avoid, too).

Your page tables only hold half as many entries.

That depends on how they are represented. But it also really just doesn't matter because 4 bytes is a tiny fraction of the size of each allocated page, so even with a naive representation, the amortized cost is negligible.

In the Java world, typically half the heap is pointers and the other half is ints. (The other types are negligible.) So you should expect your heap to grow by 25% and put that much more pressure on your memory system.

In languages like C, C#, or Fortran, in high-performance, memory-critical code, the heap will be dominated by large chunks of non-pointer data (usually, multidimensional arrays or arrays of value classes).

Java doesn't let you define those, so people don't use them. That's why you see such lousy memory statistics. It's just one of the many ways in which Java sucks badly at high performance computing. No amount of tweaking the JITs (and Java JITs have become quite good) will fix such fundamental language problems.

However, in practice, apps recompiled for AMD64 extensions tend to run a bit faster than IA32 apps on the same hardware, because the benefit of the extra registers outweighs the costs of bloated pointers.

For high-performance native 64bit applications, people who know how to write for 64bit machines know what to do to avoid the hit.

For the rest of the applications, it just doesn't matter. It's just one thing among many about performance that mainstream programmers don't understand. So, most programmers will go on blithely programming an Athlon64 as if it were a PDP-11--so what. The kind of dregs we get for application software is already usually an order of magnitude less efficient than it should be, but as long as it runs on cheap hardware, it just isn't worth worrying about.

Re:you are so wrong

[p3d0]

Quite wrong. Many languages have neither pointers nor object references (Fortran, Prolog, Haskell, etc.).

Uh, I'll give you Fortran, but I'd be surprised to see a Prolog or Haskell implementation that isn't rife with pointers. Haskell, in particular, has a call-by-need semantics that means every piece of data could potentially be a pointer to a closure.

For instance, your stack now must be twice as large because each stack slot is 8 bytes instead of 4.

The stack is dominated by data, not by those two pointers, so that is insignificant (if it were signficant, it woul be easy to avoid, too).

What in the world are you talking about? I'm talking about the stack on an AMD64, where push and pop instructions always deal with 8-byte quantities.

Anyway, what "two pointers" are you referring to? The return address and frame pointer?

Your page tables only hold half as many entries.

That depends on how they are represented.

Sorry, I thought we were talking about AMD64.

In languages like C, C#, or Fortran, in high-performance, memory-critical code, the heap will be dominated by large chunks of non-pointer data (usually, multidimensional arrays or arrays of value classes).

To paraphrase: in some code, memory will not be dominated by pointers. I'll grant you that.

I think you're talking about scientific (loops-and-arrays) code that has been carefully optimized. I'll grant you that a 64-bit processor shouldn't be detrimental to that code. But there's a whack of OO-style code out there that is not dominated by arrays, and that code pays for 64 bits even if it doesn't need them.

Re:you are so wrong

[ajagci]

Uh, I'll give you Fortran, but I'd be surprised to see a Prolog or Haskell implementation that isn't rife with pointers. Haskell, in particular, has a call-by-need semantics that means every piece of data could potentially be a pointer to a closure.

Well, and once you move from 32bit to 64bit machines, those kinds of implementations may have to change if they want to avoid blowing up their heap by a factor of two. Or maybe they don't if their authors decide it doesn't matter. The point is that Prolog and Haskell don't expose pointer semantics and can be implemented efficiently without it. For Prolog, for example, the situation is similar to some of the tricks people developed for implementing it on a PDP-10 (big words, little memory).

The stack is dominated by data, not by those two pointers, so that is insignificant (if it were signficant, it woul be easy to avoid, too).

What in the world are you talking about? I'm talking about the stack on an AMD64, where push and pop instructions always deal with 8-byte quantities.What do "push" and "pop" have to do with "the stack"?

"The stack" refers to the UNIX stack, the stack on which registers and local variables are saved. It is accessed using a wide variety of instructions, including stack-relative addressing, not just push/pop, and it isn't limited to 64bit quantities.

That depends on how [page tables] are represented.

Sorry, I thought we were talking about AMD64.

You made a general statement about 64bit computing and I made a general response. As I was saying, more importantly, the amortized cost of the larger page table entries is tiny.

I think you're talking about scientific (loops-and-arrays) code that has been carefully optimized.

That's not just scientific code, it's database code, graphics code, data mining code, data structure libraries, kernel data structures, and any other place where performance matters.

(Incidentally, why do you think UNIX uses so many integer IDs, historically with fewer than 32 bits? File descriptors, signals, exit codes, process ids, and all that. They could all be pointers, like they are on Windows, but they aren't.)

I'll grant you that a 64-bit processor shouldn't be detrimental to that code. But there's a whack of OO-style code out there that is not dominated by arrays, and that code pays for 64 bits even if it doesn't need them.

Sure, there is a lot of badly written C code (pointer style code), ill-conceived programming paradigms (what passes for OOP), and a lot of incompetently designed programming languages (e.g., Java). But any overhead from 64bit computing is the least of your worries with that kind of software.

Overall, my points are simple:

• Yes, things do change "magically" on the Opteron even for 32bit applications running in 32bit mode under a 64bit kernel: the applications get significantly more memory, and the kernel itself can manage much larger amounts of resources.
  
• No, you don't always take a hit from compiling stuff in 64bit mode--carefully written 32bit applications will not significantly increase their memory usage when recompiled for 64bit machines.
  

Re:Dumb question - deserves a straight answer

[chiph]

Anandtech recently had an article where they compared two-way systems running as web servers -- AMD Opteron 248 against Intel Xeon 2.8ghz. The AMD system was a stunning 40% faster running the same applications.

Chip H.

Turbo's

[Anonymous Coward]

Hmmm let me think about this for a second . . .

All SAABs you jacka$#. Most VWs sold in the U.S. have the 1.8T engine. Several Volvo models have turbos. Probably the majority of all Subarus. Mitsubishis. Several of the high-end Toyota sports cars.

Basically any mfg who actually engineers their vehicles as opposed to simply dropping a big gas-guzzling V6 & V8 engines. I drive a Saab 9-5 Aero with a turbo-charged engine: 2.3L 4-cylinder engine producing 250HP. During highway driving it gets 30mpg, but I average 26mpg mixed. It's called 'good engineering' - look it up.

Re:Dumb question - deserves a straight answer

[Waffle Iron]

Also note that x86-64 corrects some of the weaknesses of the x86 architecture, so x86-64 apps are automatically faster. Counter-strike was 30% faster, clock-for-clock.

That's an important point that people need to keep in mind. The 64-bitness in itself provides just about zero benefit to 99.9% of users.

Many people fail to realize that 64-bit in this context only means 64-bit pointers. Apps have been using 64-bit data for years: 80-bit floating point has been implemented in the X86 since the 1980s, and apps have been able to process 128 bits of fixed-point data at a time since the MMX was introduced in the late 1990s.

Even in a 64-bit CPU, most ints will probably be compiled at 32 bits to save memory space. There are very few situations where you need a 64-bit integer value in real world programs. You will not see any speedup due to suddenly being able to do arithmetic on bigger numbers.

The only "big deal" about 64-bit processors is the 64-bit addressing logic. This eliminates the 4GB limit on a contiguous virtual memory space. While this may be valuable for people running huge databases and scientific simulations, the individual user today has no need for this. The only big piles of data the average user may have today are videos, and algorithms to process video are highly streamable. There's no need to map an entire video into memory at one time.

64-bit pointers bring the disadvantage of consuming more valuable cache real-estate and bus bandwidth for every operation. These resources aren't free, and the extra cache and bandwidth added to support 64-bit pointers in a 64-bit CPU could have been utilized in a 32-bit processor to improve its performance as well.

AMD has indeed apparently produced a CPU that's faster on the average users' tasks, but as was pointed out, that's largely due to adding more register space to reduce the x86's notorious register pressure problem. AMD could have acheived the same effect by adding more registers and keeping the CPU 32 bits. I'm not saying that such a move would make any sense; it wouldn't (in particular, it would be a marketing disaster). I'm just pointing out that that's the only feature the vast majority of users will actually benefit from in the next 5 years with this CPU.

Furthermore...

[emil]

...the only two major computer system manufacturers who have elected to rely upon the Itanium are HP and SGI.

HP is manufacturing a number of different Itanium systems and winning performance awards with them. The largest is the "Superdome" which I believe will hold 64 CPUs. The Superdome is interesting in that it can accept either the old (soon to be discontinued) PA-RISC processors or the newer Itanium chips (hopefully Sun will do something similar with Sparc and Opteron in a revision of the e10k line).

SGI also makes a Linux Itanium NUMA supercomputer called "Altix" that is far more scalable than Superdome.

Both of these companies are going to be royally shafted if Intel produces a chip using the Opteron/Athlon64 instruction set. Intel has been incredibly unwise in not dropping the cost of the Itanium below the Opteron. Itanium has flaws, but it does have some incredible floating point performance.

HP is probably of the greatest concern. They ported their enterprise UNIX (HP-UX) to Itanium some time ago, and they are nearing a stable port of the OpenVMS operating system to Itanium. These operating systems have large, dedicated followings and they are technically quite advanced (far more so than Linux in many respects).

If the Itanium fails, it will be a bloodbath for HP enterprise systems.

Why would you buy an AMD64?

[emil]

Let's just review a few facts:

• Many dual-cpu boards tie all the memory to one cpu, slowing down the other one.
• Various versions of the AMD64 architecture are unreasonably expensive.
• I've heard rumors of Linux incompatibility with various boards and bioses.
• AMD is also in the act of outsourcing it's IT staff to India. While Intel undoubtedly does the same, AMD's action is more recent and this sort of thing shouldn't be rewarded.
• AMD's planning with Microsoft Win64 release was also obviously lackluster if Intel was able to delay it.

For all of the hype, there are plenty of reasons to sit tight on your wallet for a (rather long) while.

Re:Why would you buy an AMD64?

[Brian Stretch]

Many dual-cpu boards tie all the memory to one cpu, slowing down the other one.

Many don't, and in either case you have lower latency than Intel's solution.

Various versions of the AMD64 architecture are unreasonably expensive.

<cough>Itanium</cough>.

I've heard rumors of Linux incompatibility with various boards and bioses.

Ooooh, rumors!

AMD is also in the act of outsourcing it's IT staff to India. While Intel undoubtedly does the same...

AMD, Intel, world + dog. I don't like it either but they'll figure out it's a bad idea soon enough.

AMD's planning with Microsoft Win64 release was also obviously lackluster if Intel was able to delay it.

Assuming that rumor is true. The excuse that Microsoft is waiting on WinXP SP2 with its security fixes, including support for security features in the AMD64 series (buffer overrun protection), is a good one. Securing WinXP has got to be a bitch.

Meanwhile, you can buy an Athlon 64 3000+ CPU for barely over $200, and an ASUS K8V Deluxe board for a bit over $130. And you'll drop power consumption by enabling AMD's Cool & Quiet. Why bother with Intel's power-wasting, inefficient P4?

Re:Why would you buy an AMD64?

[Anonymous Coward]

Many dual-cpu boards tie all the memory to one cpu, slowing down the other one.

True enough. That's why AMD64 CPUs have the memory controller on-chip. Get it? The 2xx and 8xx Opterons have a dual-channel DDR memory bus per each CPU -- in other words, memory bandwidth scales linearly with the CPU count. (The single-CPU variants have the controller on-chip too: but in Opteron 1xx and Athlon FX-5x it's dual channel, whereas in Athlon 64 it's just single channel.)

What you're talking about just doesn't relate to AMD's x86-64 processors. Thanks for playing anyway.

Re:Why would you buy an AMD64?

[bucky0]

Let's just review a few facts:

Lets.

Many dual-cpu boards tie all the memory to one cpu, slowing down the other one.

There are a few boards like that, but certainly not a majority. The difference is very small however, considering that there is just one extra hop across a HT link to the processor with memory. (The memory controllers are directly connected to HT links which minimises latency)

Various versions of the AMD64 architecture are unreasonably expensive.

True, some versions are expensive, but your talking about a technology that's been released for approximately 3 months now. Give it time and prices on the high end stuff will go down. That said, you can get a single proc A64 system for fairly cheap.

I've heard rumors of Linux incompatibility with various boards and bioses.

Rumors...you're giving people advice on whether or not people should purchase a particular architechture on rumors? What's the severity of the problems?

AMD is also in the act of outsourcing it's IT staff to India. While Intel undoubtedly does the same, AMD's action is more recent and this sort of thing shouldn't be rewarded.

I agree

AMD's planning with Microsoft Win64 release was also obviously lackluster if Intel was able to delay it.

That's a whole ton of speculation. There's any number of reasons that release was delayed. MS could be having trouble porting the legacy code over, Intel could have negociated(sp?) hard(keep in mind who has the much larger market share), MS could have wanted to wait for marketing reasons...who knows? It's silly to blame AMD for it though.

My 2 cents.

Re:Why would you buy an AMD64?

[be-fan]

AMD is also in the act of outsourcing it's IT staff to India. While Intel undoubtedly does the same, AMD's action is more recent and this sort of thing shouldn't be rewarded.
-----------
So? Unless you have some evidence that the cost of outsourcing the IT staff (in terms of service) is greater than the benefit (money saved for AMD), then I should reward AMD for this. That means that they can deliver better processors for less money.

The CPU market is fairly competitive these days. Under those circumstances, outsourcing is just another business decision, and if it results in a net monetary benefit for the company, than it should be rewarded as a good business decision.

Re:Why would you buy an AMD64?

[Anonymous Coward]

Meanwhile, you can buy an Athlon 64 3000+ CPU for barely over $200, and an ASUS K8V Deluxe board for a bit over $130. And you'll drop power consumption by enabling AMD's Cool & Quiet. Why bother with Intel's power-wasting, inefficient P4?

I made the mistake of doing this recently, I sold it, bought an SHG2 with 2 2.0 Xeons and regardless which OS you choose on the boot menu (Linux or W2K) the Intel's kick ass. Plus if the fans ever fail, the xeons turn themselves off, and AMD burns holes in boards.

Re:Why would you buy an AMD64?

[Anonymous Coward]

Oh no some one can do my job for less. FUCK!!!!. Lets bitch about how unfair that is. Your a twat.

Only when Mac OS X goes 64-bit.

[emil]

Apple is pretty much dipping their toe in the pond at this point. Sun has been immersed for some time.

Gentoo stage1+2 compile time on dual Opteron: 6h

[Anonymous Coward]

Gentoo AMD64: "Emerge system" took less than six hours with the default settings.

I can't fucking believe it.

Setup: dual 2 x Opteron 240, Tyan K8S Pro with SCSI, 36 GB Hitachi 10krpm harddisk and 512 MB memory.

Cost of x86-64 compilers?

[tepples]

Ah, so you haven't heard of Pathscale then?

Will developers of free software be able to afford a Pathscale license? Or has GCC x86-64 code generation progressed to where that's not strictly necessary?

Re:Cost of x86-64 compilers?

[turgid]

Will developers of free software be able to afford a Pathscale license? Or has GCC x86-64 code generation progressed to where that's not strictly necessary?
gcc on x86-64 is "good enough" for most people, and can produce significant performance gains on Opteron over 32-bit compiled code.

In comparison, the last I heard about gcc on itanium was that it could only get about 20% of the performance of intel's proprietary compiler, and gcc still can't vectorise. Things may have changed, and the gcc-compiled itanic object code may be better now, but who knows.

The thing is, there is a highly-optimising compiler for Opteron (from Pathscale) if you want to pay for it and a "good enough" one (gcc) if you don't. If you're doing serious numbercrunching on any architecture, you must consider the best compilers, otherwise all that (expensive) hardware is wasted. Most times, that means paying for a specialist compiler.

I recommend you look at the gcc website for more information about platform-specifics.

Re:Dumb question - deserves a straight answer

[nelsonal]

I think AMD is trying to make a chip that will sell well to consumers, look it's faster, while simultainously providing a cheap method for businesses to get 64 bit memory addressing. That's the golden market their really after, the consumer market just provides a sales channel to keep everything running at full speed. Honestly, I'd guess that AMD is much more excited about SUN and IBM currently tepid interest than all the reviews showing 15% more speed than a P4.

Yeah but how much did that cost when it was new?

[MrDolby]

Yeah but how much did that cost when it was new?

Intel, AMD, etc

[sjd]

All of the posts I've read only talk CPUs. Hasn't anyone noticed that MS now (quietly) has a multi-platform software virtual machine? .NET strives from cross-platform compatibility, just as Java did years, and years ago. MS realised this IA-32/IA-64 was going to happen, and .NET quietly solves the problem. MS is pushing people to migrate their IA-32/Win32 apps to it. As a current .NET software engineer, the specific Windows platform becomes irrelevant. You could easily argue that MS is delaying the 64-bit world to give developers more time to migrate to .NET. Sean

Re:Intel, AMD, etc

[Anonymous Coward]

not to be a troll but,

fuck .net

sorry, just had to get that off my chest; i work at a microsoft shop and im an oss geek

Re:Dumb question - deserves a straight answer

[fitten]

And how much of this is because of 64-bit? The memory architecture of a dual Opteron is much better for high memory loads than a dual Xeon (independent memory bus for each processor, for starters), which Anand even attributes the performance increase (speaks of the on-cpu-die memory controller) in his Final Words

The IA may be shitty...

[moogla]

but even when programming in assembler, it isn't so bad. In fact using the x86_64 IA assembler is pretty nice in long mode (AMD is happy to send you the manuals gratis, to help out). Not as symmetric as say MIPS, but it's getting better.

The IA is the IA. It has little to do with how anything else works (which is all modern at this point). The only pain is having non-fixed length opcodes, but we've solved that problem (TLBs) so we get to use instruction cache better. I don't really see the problem!

Small point!

[moogla]

You can't do MMX and floating point in parallel. But you CAN do 64-bit arithmetic (which used to require MMX) and floating point in parallel, or 64-bit integer arithmetic and MMX/SSE/3dnow in parallel. This opens up the door for lots of additional speed optimizations by internal instruction level parallelism. Also it lets you do things with less instructions (and hence clocks) which used to be cumbersome before (faster fixed point/arbitrary precision math, large multiply/acc. operations, saturation math with 32-bit quantities)

Also another great one ... 64-bit bitfields!

Correction 32 vs. 64-bit fetch..

[moogla]

You have always been able to fetch 64-bits from RAM into a register as quickly as you could load a 32-bit register. You would use an MMX/FP instruction. The path from the cache to the P6 cpu is at least 64-bits wide, and cache lines (and memory bus) are as wide or wider.

Now they've extended that all the way to pointers and integers (and thus more ADDR lines for 64 (well 48-bit addressing), but that's a different story)

Re:Correction 32 vs. 64-bit fetch..

[alexq]

really? i'm unfamiliar with MMX so i'm sure you're right about that. are they doing full 64-bit addresses? the alpha didn't even do that, i was never sure why.

Re:AMD

[benzapp]

Provide a link to the company that makes that shit. I am curious what they produce.

slightly less elegant?

[moogla]

solaris uses mmap exclusively (internally) to emulate ALL file system access (swap, local, nfs, you name it). This allows it to intelligent manage the page cache and disk cache with the ultimate flexibility.

Linux has a similar behavior for certain filesystems (it's fs dependant)

Re:slightly less elegant?

[anthonyrcalgary]

It's still a system call, that's not as fast as accessing a file you've mmaped yourself.

Re:slightly less elegant?

[Anonymous Coward]

Not really. It's handled in the system library (libc), which manages the system calls (mmap's, and so on). The standard I/O layer doesn't necessarily need to use any system calls (basically, anything under man 3 rather than man 2 is a library call, not a system call). So it's just as fast maybe even faster, depending on how well the library is optimized over code you could write yourself.

Re:slightly less elegant?

[anthonyrcalgary]

The standard I/O layer doesn't necessarily need to use any system calls (basically, anything under man 3 rather than man 2 is a library call, not a system call).

Well, I/O has to use system calls at some point because of the privileged instructions, but one call to mmap is better. I take your point.

It's handled in the system library (libc), which manages the system calls (mmap's, and so on).

I've done a little assembly on SPARC/Solaris... It was a while ago, and they were old machines even then, but at the time, for (say) read, you'd do something like:

mov FD, %o0
add %fp, BUFF, %o1
mov MAX, %o2
mov 3, %g1
ta 0

Libraries can't intercept a trap... That goes straight to kerel space pretty much no matter what. I can imagine the compiler using a library instead of a trap for stuff, but that won't affect the old binaries, or old assembly programs.

Forgive me if I'm out of date. :) It's entirely possible that the compiler was putting reads through a library even then, and I was just doing it the dumb way.

Also the opteron is plain faster

[moogla]

than a Barton clock for clock. Just as the Barton was more efficient per Hz than the Throughbred. :-)

More important reason:

[moogla]

They chose to decouple addressing logic and instruction logic. You need to use prefix bytes to use 64-bit/extended register ops. Thus you are free to mix 32-bit and 64-bit instructions as needed in a single program to save instruction cache. As a result, 64-bit instructions follow the same "formula" as 32-bit instructions. In a way this must have helped immensely in design and Q/A because all the prefix byte really does is turn off features that remap 16->8 and mask the upper 32-bits of GP regs. Mostly it's unchanged. The big thing was the integrated MMU (with 64-bit addressing support), and all the extra instructions to manage it.

You can load a 64-bit value

[moogla]

from a 32-bit address aligned on a 8-byte boundary without penalty if it's in the cache already (to an FP/MMX reg, of course).
Access to two sequential 32-bit, 4 byte aligned values into GP registers can NOT be serialized, IIRC.

This is one of the reasons why you WANT to use MMX instructions to do simple processing of matricies or arrays or whatever... more efficient memory access.

DSP Performance

[Detritus]

TI C6000-series DSPs - state of the art

Integer - 2400M MACs/sec
FP - 550M MACs/sec
Cost - $300-600+ for 1k Unit quantity

Intel 2GHz P4

Integer - 4000M+ MACs/sec
FP - 2000M MACs/sec
Cost - $158 for 2 GHz, $550 for 2.8 GHz (today)

(Source: DCC Sunday Seminar 2002 Software Defined Radio )

Re:DSP Performance

[dimonic]

Hhmmm, I had no idea GPU power has so eclipsed DSPs. However, this is still beside the point, since it is not established that 64 bit inherantly provides much more raw performance in a direct way, and even more speculative is whether current architecture and OS can deliver significantly more real performance with a 64 bit system. I am simply stating that 64 bit may be providing a much more general improvement than simply a performance one. For the performance boosts for your application, multiple servers such as in a Beowulf cluster seem like a logical choice, once one runs into the ceiling of what any single CPU system can handle.

I can build 4 1.6 GHz systems for the price of one 64 bit system today. They can have gigabit networking, a good cluster OS, and probably beat the pants off the 64 bit system in crunching those RF DSP algorithms.

I am arguing that the bigger gain from 64 bit computing may lie in the vast simplification of device handling now that the theoretical address space can dwarf the achievable addressable size of devices.

Re:DSP Performance

[matfud]

This is very true. I noticed it a few years back
when Matrox changed from using TI DSPs on its
genesis DSP boards to using powerPC's. However the
genesis gets a lot of its grunt from the xilinx
FPGA that it also has. a few tens of millisecs to
set up the FPGA and it storms though many common
DSP tasks. Also the fact that you can put about 15
processors (8 boards) intogether.

I do think you are being a optimistic about the
performance of the P4 though.

matfud

Pentium V

[stud9920]

If the Pentium V suceeds, will intel market its successors as Pentium V pro, Pentium V MMX, Pentium V II, Pentium V !!!, and Pentium V 4 ?

Re:Dumb question - deserves a straight answer

[willtsmith]

If I write double in a program. I assume it's going to be compiled into a double.

A true 64-bit CPU would have a natural advantage in handling double length int's and floating point numbers.

Having said that I don't think 64-bit is necessary in anything but professional workstations. I also don't think that 3 Ghz CPUs are very necessary either. Especially since 1/3 of the hertz in a P4 is the equivalent of revving your engine.

From this perspective, a 64-bit CPU is a windfall not for engineers, but for marketers. So the 64-bit CPU can easily be made to look "superior" because well, it's twice as much. It's like Spinal Tap's Amps that go up to 11 instead of just 10.

We'll see how it plays out. But if the marketers have their way, we'll all be sporting 64-bit CPUs within tree years.

Re:Dumb question - deserves a straight answer

[willtsmith]

Large scale file servers are one example of machines that can directly benefit from 64-bit addressing. Forget the 4-Gig memory limit.

The other excellent example is anything to do with video. A single DV tape takes 16 GIG of space. As CPU speeds ramp up, the need for more memory to feed CPUs and eliminate disk latencies will increase.

Re:AMD

[Loki_1929]

"Intel (as far as I know) are trying to increase cpu speed and reduce the die (or the cpu) size."

Intel is having enough problems getting their P4 'Prescott' chips out the door. These were supposed to be available to consumer in December, but they haven't even been launched yet due to a number of problems. There are now rumours of redesigns going into effect with the Prescott chips to add even more stages to the already staggeringly long pipeline. Intel has moved to the .90 process, with AMD trailing not far behind in that regard. Intel's main problems seem to be leakage and heat. Northwood has hit an architectural limit, and Gallatin (P4 EE) isn't going to ramp up in clock speed very quickly either. Anything AMD releases at this point will be all but unanswered by Intel until some time around late Jan to early Feb at the earliest.

Until Intel gets the Prescott P4s rolling off the line and into PCs, it really shouldn't be concerned with trying to add even more crap into their chips. The real kicker with AMD's 64-bit chips is that they'll upgrade themselves over time. What I mean by that is that when the 64-bit desktop version of Windows (the enterprise version is already available) is released, and applications begin to get recompiled to take advantage of AMD64, the 64-bit AMD chips will look faster and faster without any changes at all. Intel is facing a real challenge in that the AMD64 architecture is built to ramp up in clock speed just as quickly as the P4 did. Intel needs to fix the Prescott problems immediately to keep the P4 line moving, then go on to the next thing as quickly as possible. The more time they spend trying to make Prescott look like less of a dismal failure, the less time they have to strike at AMD. Once AMD makes the changeover to .90 and 939pin, they're going to start tearing through the desktop market like a bat out of hell. If Intel offers nothing for a response, we'll see more than just tier 2s jumping on board. The only ones I don't see getting into the AMD64 game at that point are HP, due to their links to (money dropped on) Itanium.

Intel faces a multitude of problems. The Prescott issues make them unable to respond to faster AMD chips. On a more fundamental level, there's no one who really stands out at this point over at Intel - no one providing direction to the company. In-fighting appears to be holding up a number of things and sending mixed messages to the market and the channel. If Intel doesn't release a 64-bit desktop chip, it risks losing massive market share to AMD. If they do release a 64-bit desktop chip, they reduce Itanium (along with its 10+ years and Billions of dollars of R&D) to a niche product. Investors tend to lose confidence when 10 years of research are brought down by a company that spent most of its years riding your coat tails.

Intel faces some tough choices in the short term, and may end up being forced to choose between the desktop market and the server market. If it goes for both at once, it's going to need to pull some major weapons out within the next year to stay competitive. Multiple cores are not to be considered major weapons, as AMD's AMD64 architecture is already designed with dual-cores in mind. If Intel decides to choose the server market (the more likely choice between desktop and server), and all but abandon the desktop market, it could probably keep AMD from making a whole lot of headway into the low-midrange server market. This would prevent AMD from undercutting Intel's bread'n'butter. The problem with this strategy is that Intel's "glow", if you will, is lost forever.

On AMD's end, they need to pick up the pace with the .90 changeover. They should also consider dumping the 32-bit line as soon as possible, as that will lower the costs of producing the Athlon64 chips, thus lowering the price for consumers. The Athlon64 3000+ was an absolutely brilliant move, and may spell out the entire value market for AMD in the mid term. If they can mo

Re:Dumb question - deserves a straight answer

[Bombcar]

Yes, but if you measure it in dollars per butt-whipping, the 32 bit comes out ahead. But if you have an infinite amount of money to spend, then get the 64 bit stuff. Right now, 32 bits is where the most bang for your buck is.

Sure.. but not just markting.

[mindstrm]

I mean, of course it's a marketing ploy. It's also a direction to go for the future. At some point we want 64 bit chips, right? and some day, we will want 128 bit chips, right? and so on.. gotta change some time.

Second.. if you look at the benchmarks on amd-64 chips, you'll find that 1.8Ghz amd64 chips are equalling 3Ghz P4 chips, and that's on standard 32 bit code. Of course, that has nothing to do with being 64 bit, but with being re-architected.

The focus on 64 bit is markting one, for sure... but if you simply look at it as a more capable, better architected chip.... it makes sense.

Re:Sure.. but not just markting.

[HiThere]

I doubt that we'll ever go to 128 bit chips. IBM tried it on the 360 line, and it didn't go anywhere, ever. They later dropped it, and stayed at 64 bits.

What will happen after the 64 bit chips is parallel processing. SMP writ large. We're already dipping our toes into that one, but there's still a few problems that need solving. Still, one could do quite a lot with a cluster of 64 bit chips that each had separate large L1 & L2 chaches, and a shared ram, even now. And this is still early days. Expect either grid computing at the micro level, or computational surfaces (or they may both develop into the same thing [I'm not clear on the differences even now]).

Re:Sure.. but not just markting.

[mindstrm]

Sure.. and 640K will be enough for everyone... right?

Just becuase it was tried before it had a useful value doesn't mean it won't be useful in the future.. I'd think that is obvious.

Parallel computing is advancing, sure.. but what's that got to do with bit widths? Nothing, at all. They are totally separate things.

Re:Sure.. but not just markting.

[HiThere]

When they tried it, they found that the problem set that was addressed by larger word sizes wasn't significant. This isn't something that's really that likely to change.

OTOH, there have been alternative designs, like the chip out of Britain a few years ago that packed a bunch of instructions into a long word (possibly 128 bits) with the meaning that these instructions could all be executed simultaneously. Some variant architecture like that could provide a value to a long word. But with the currently standard architectures...no. It slows you down and doesn't buy you anything significant. If you need a larger address space than 2^64 bits can address, then you have a considerably larger budget than anyone I know. Even if you are using memory-mapped files (as was suggested earlier) I'm not convinced. I suspect the frequency of the need to address beyond the 2^64 bits away would be infrequent enough that it would be better design to have a few instructions that could take double-word pointers (which gives you most of the advantages of your 128 bit design with many fewer costs).

Note that even the case for 64 bit chips is weak. You can do nearly everything except memory mapped files with 32 bits. I suspect that clever instruction designed with the *idea* of occasional multi-word pointers would be a better solution almost all the time. Still, given the instruction sets that we have there is a case for 64 bit chips, if only for counting microseconds. (Figure out what the date range of a 64 bit integer is when counting microseconds...I was surprised at how large a period was covered.)

Also note that a 64 bit system requires 64 bit wide data paths, and a 128 bit system requires 128 bit wide data paths. That means a whole bunch of wires in the cables. And they'll be 4 times closer together than the current ones, so capacitance coupling problems will be 16? 64? times worse. So the cables will need to be braids of twisted pairs rather than flat (or some other scheme...but ribbon cables are just OUT). And finer wires mean higher voltages mean it runs hotter.

There's little that 128 bits can do that 32 bits can't. I can't think of anything that one could practically do with a 128 bit chip that couldn't be done as well with a 64 bit chip. The 64 bit chip might need to run 4 times as fast, but it would be easier to make the 64 bit chip run 4 times as fast than it would be to make the 128 bit chip. And I suspect that the switch to 64 bit chips is largely a marketing decision. Probably a slightly different instruction set on a 32 bit chip would have been better technically. You would need instructions to allow multi-word pointer manipulation...but done right that would allow you to get the advantages of even a 256 bit chip while using a 32 bit chip (that ran a bunch faster than the 256 bit chip would need to run...and was still easier to build).

Still, there may be a reasonable range of problems that benefit from a 64 bit chip. (But note that most of the speedup attributed to the 64 bit AMD chips are reported to be due to bug fixes.)

"Good enough"

[tepples]

The thing is, there is a highly-optimising compiler for Opteron (from Pathscale) if you want to pay for it and a "good enough" one (gcc) if you don't.

By "good enough," do you mean "no better than an interpreter, destroying the only reason to write an app in C or in C++ rather than in Python"?

If you're doing serious numbercrunching on any architecture, you must consider the best compilers

The problem is that my users might be doing serious number crunching with the executable versions of the Free apps that I develop, and as a free software developer, I can't afford even "good enough" if GCC isn't "good enough" on, for example, Itanium. Distributing source code and having each owner of a machine license his own compiler would increase the cost of owning a computer several-fold. If GCC isn't "good enough" on a given platform, there's no reason for poor free software developers to buy specimens of that platform.

I recommend you look at the gcc website

I tried. What page gives the status for each platform's code generator? The target-specific notes do not list any performance issues. Do you think I could find it in messages posted to mailing lists? If so, could you please give me a few tips on how to perform such a search?

Re:"Good enough"

[turgid]

By "good enough" I mean that you probably get to within 10-20% of the best compilers available. Today, if you want to exploit the extra FP performance available through vectorisation (using SSE/SSE2/3DNow!) you must hand code that yourself in assembly language. Don't take my word for it. Do some tests yourself. Optimisation is something of a black art.

As for the gcc target specifics, I think you might have to google for some performance tests, look through the mailing lists and ask the developers directly.

gcc is not "good enough" on itanium as I said previously. Instead of being within 10-20% of the intel compiler, it is about 80-90% behind IIRC (it's been a while and intel likes to keep this quiet). Maybe there has been some serious work on gcc for itanium since then? I don't know. you'll have to ask the gcc people.

A lot has changed in gcc in the last few years and the code generator has been much improved on "traditional" architectures, so they say, but this does not apply to itanium because it is so different.

If you want to get an idea of what itanium assembly language looks like, look in the Linux kernel source (2.4.23) at arch/ia64/kernel/gate.S. This is the (platform-specific) code for going from user-land into kernel land. Notice the bundles of instructions followed by ";;". These are the instructions being scheduled to execute (explicityl of course) in parallel. The ";;" tells the assembler "I've no more useful work do to in this instruction bundle, please pad it out with No-Operations." This is itanic's Achille's Heel: The poor compiler (or coder) must schedule the instructions explicitly in these bundles to make full use of the execution units. If the vectoriser isn't good enough, or there insn't enough inherent parallelism in the instruction stream, execution units stay idle and the CPU operates at a fraction of its theoretical peak performance. If you had such a machine, you could disassemble the object code and look to see how well parallelised the code was. You could compare the output from gcc with icc (intel's compiler.)

I could go on, but you've probably fallen asleep by now... :-)

One more reason for 64 bit address space

[Anonymous Coward]

Is that it can make profiling/diagnostic tools more powerful (Rational Purify, Microsoft AppVerifier, and custom tools like we developed). These tools are heavily limited today by total number of pages that application can allocate (~1.5GB/4KB/2-history). The /2 is because typically you need to put up a guard page before or after the allocation. The 64 bit addressing space should allow use of dedicated page for each allocation when running in profiling mode, and have a precise control and view of memory access patterns, buffer overruns, free memory writes, etc. If you try to do this today, memory demanding applications quickly run out of pages. It's possible to run them in simulation mode (trace step-by-step and analyze every instruction), but this makes profiling extremely slow and changes the timings to the point where a lot of race condition and timing related bugs are never exposed. The 64 bit address space should allow profiling those big applications at close to non-profiling speed.

It's more registers! (Was Re:Dumb question)

[adisakp]

If you look at the AMD 64-bit extensions, one of the simplest things you will see is a lot more registers for floating point and for integer operations. This makes it much easier for compilers to optimize code (reduce load and stores, perform parallel operations, interleaved loop unrolling) as well as decreases delays waiting on register resources in the CPU during dynamic excution where register renaming occurs. Believe it or not, even code that does all it's work requiring only 32-bit precision but uses the extra registers available should see speedups.

Yes, this is correct normally - BUT.......

[Wiz]

I've benchmarked SPARC Solaris system running the exact same programs in 32-bit and 64-bit mode. The 32-bit code is always 10-15% faster!

Why? The increase of memory usage and cache usage as stated above. If you don't need 64-bit, stick to 32-bits.

However, this is only the case if the 32-bit and 64-bit modes are the same. BUT....

On x86-64, this is not the case. In 64-bit mode you get double the number of registers

This is very important. x86 by default only has 8 register, and AMD kept it that way in 32-bit mode for compatability reasons. In x86-64 mode, you get 16 registers instead. So despite the extra memory & cache pressure, it is faster.

If you look around, you'll find benchmarks where LAME is 30% in 64-bit mode because of this!

Intel 64 bit? Who cares?

[thirty2bit]

Intel 64 bit? Who cares? We still don't use current processors efficiently today! Linux being the exception, boxes are saddled down with bloated, resource-hungry Windows running highly inefficient code based on VB or Mighty Fat Classlib (MFC).

Yesterday there was a /. article on Windows 98's death knell. People are pondering this with incredulity as W98 systems are still perfectly suitable for the needs of a great number of people.

It's sad that the hardware and software companies engage in unchecked one-upmanship while marketing departments FUD users into upgrading.

Re:Dumb question - deserves a straight answer

[Serveert]

Opteron is also NUMA so applications compiled on a NUMA-aware OS like Linux will be faster. 64 bits provides faster searches so databases will be faster.

....and....

[turgid]

I nearly forgot: HP is so desperate to ship itanic systems, that they have a 90-day free trial programme where you can have one on evaluation for free. I think intel's C compiler may be "free as in beer" under some circumstances. You could do your own tests of gcc vs. icc on itanic Linux. I hope you have good air conditioning and 3-phase electricity. :-)

Re:Dumb question - deserves a straight answer

[be-fan]

Actually, 64-bit CPUs have no advantage in handling floating-point numbers. All current CPUs handle use long-double floating point units internally, which are 80-bits. The '64' refers to the width of the integer unit and the size of the memory bus.

Re:Dumb question - deserves a straight answer

[Bun]

According to the article, none of it was due to the 64-bitness. It was run on a 32 bit os:

The Opteron test bed was configured as follows:

2 x Opteron 244 or 248 processors (1.8GHz/2.2GHz respectively)
8 x 512MB DDR333 DDR SDRAM modules
AMD reference 4-way Opteron motherboard
Microsoft Windows 2003 Enterprise Server with IIS6
Macromedia ColdFusion 6.1

Re:Dumb question - deserves a straight answer

[Webmonger]

In C and C++, "double" is implementation-defined. So a double will always be compiled into a double, but that's a tautology.

Typical Intel marketing FUD, more or less

[waferhead]

More or less.

AMD handed Intel their head for the first time here, and Intel "suddenly" has a comparable chip in the works, that will run at 10 Ghz, use very low power, be recyclable, do dishes, SOMEDAY.

"No, Wait, Don't buy that Opteron!!! Well have something better Real Soon Now"

I would bet a paycheck that heads rolled at Intel when the Opteron shipped and they didn't have anything close to production...

Re:Dumb question - deserves a straight answer

[drinkypoo]

Many people fail to realize that 64-bit in this context only means 64-bit pointers. Apps have been using 64-bit data for years

Yes, and on 32 bit machines they've been taking more than one operation for years. Any time you're working with data types which are a multiple of 64 bits, being 64 bit will mean you will only need to use half as many instructions to process the same amount of data. This is a "big deal".

Also, while register starvation is a real issue on x86, there are two things you're overlooking here. First, modern x86 CPUs use register renaming of temp registers - they have more than 4 GPRs, and probably temporary index registers as well - to alleviate the problem of register starvation. Second, some compilers are able to make optimizations for some chips by tweaking those registers. Hence register starvation is not a serious problem. (It certainly IS a problem, but the CPUs make up for it in most circumstances.) 16 GPRs is actually kind of anemic for a modern processor, but obviously a huge leap in the right direction. AMD actually claims that with this architecture, more than 16 GPRs would not provide gains worth the additional complexity.

The fact is that AMD has a chip which is simply more efficient for a variety of reasons. It operates faster than an Athlon XP in 32 bit mode, clock for clock, but legacy 32 bit code still only has access to the E[a-d]X and ESI, EDI, etc registers. The existence of additional visible GPRs is not a reason for 32 bit code that doesn't know they exist to run any faster.

Re:AMD

[Alan Partridge]

google it you lazy cunt

Re:Dumb question - deserves a straight answer

[Waffle Iron]

Any time you're working with data types which are a multiple of 64 bits, being 64 bit will mean you will only need to use half as many instructions to process the same amount of data. This is a "big deal".

X86 floating point has been using 1 clock and 1 instruction to operate on 80-bit chunks since the Pentium I. My argument was that outside the context of pointer arithmetic, 64-bit integers are almost useless. (Maybe after 2038 you'll need them for holding 'time_t' values.) Once numbers get that big, you are usually going to be using floating-point anyway, which works just fine today.

In 20 years of programming, I don't recall that I've ever had a need for numbers above 4 billion, but less than 2e19, but which don't support fractions (again, this is excluding pointer arithmetic). Sometimes I would have liked to do boolean operations on as many bits as possible, but IIRC, the MMX already lets you do that on 128 bits. As far as other operations on data types bigger than 64 bits, the other main one is bulk moves. However, that tends to be more determined by cache architecture than anything else. I seem to recall that the x86 already has tricks efficiently move entire cache blocks of data around.

I tend to agree with you on the registers. I have argued in the past that the X86 register scarcity wasn't a big deal because of register renaming and reordering. However, I've seen so many assertions that the new compiler-visible X86-64 registers were helping performance that I ended up accepting that maybe it was helping. Perhaps this new chip is just faster due to a bunch of unexciting little enhancements.

However, I still maintain that the 64-bit integer math doesn't help the average user in and of itself.

theregister.co.uk ---:Itanic == Titantic

[waferhead]

"The Reg" was the first place I heard that name---
Don't know if they came up with it, but they popularized it well.

64 bit data, 32 bit instructions? BULL

[Crypto Gnome]

The letters VLIW mean "Very Large Instruction Word". Processors that use this technique access the memory by transferring long program words, and in each word many instructions are packed. In the case of the IA-64, three instructions are used for each pack of 128 bits. As each instruction has 41 bits, there are 5 bits left that will be used to indicate the kinds of instruction that were packed.

So There

People PLEASE turn your brains on before trying to spout crap you know less than zero about.

This whole stream of commentary by people claiming "more data but not bigger instructions" is less accurate than RIAA statistics.

Re:64 bit data, 32 bit instructions? BULL

[Anonymous Coward]

At least they understand enough to talk about CPU architecture in question.

If you don't even understand the difference between x86-64 and IA64, why would ANYONE at all bother listening to all the other garbege you spout?

Re:64 bit data, 32 bit instructions? BULL

[Crypto Gnome]

Or understand what's common (ie VLIW) which was the point of my post. (dumbass)

Re:64 bit data, 32 bit instructions? BULL

[Anonymous Coward]

Except that it's not common - x86-64 is not VLIW/EPIC. Dumbass.

There have been and still are plenty of 64 bit RISC architectures (POWER, G5, Alpha...) for godssake, nothing in that number magically forces all the 64 bit CPU's to become VLIW.

Re:64 bit data, 32 bit instructions? BULL

[alexq]

Hm... Well, what I was saying was that instruction stream and data stream are (in theory) completely unrelated. IA64 does indeed have a larger instruction size that IA32.. but what I was talking about in the post (I guess it wasn't obvious?) was that a 64 bit IA32 architecture would mean that the instructions are still 32 bits, but the data stream is 64 bits. For IA64 this is obviously not the case.

Honestly from the tone of your post it's hard to believe you'll listen, but I want it to be clear that data stream and instruction stream size are unrelated - and you've proved it yourself by showing the 41 bit instruction size but 64 bit data size of IA64.

This is all tangential anyway since this thread wasn't about IA64. :)

IBM a majoe contender?

[MXi]

I thought IBM was supposed to be working with AMD on the new chips...

No it's Yamhill

[DABANSHEE]

The Itanium is some sort of 64bit VLIW processor with it's own instruction set that can also emulate X86-32 & PA-RISC or something.

X86-64 is what AMD's Hammer series processors (claw, sledge, etc) use.

Intel's rumoured 'Yamhill' is s'pose to be their X86-64 Hammer clone, that's what this thread's about.

Re:Add-in module is for an *ITANIUM* coprocessor .

[hayds]

What would be the point of an Itanium coprocessor? Its not the same as having a math coprocessor in a 486 system which took floating point instructions and executed them more efficiently than the main processor. Its a whole different architecture! You cant run an X86-64 OS with X86-64 apps, on an X86-64 and use an "Itanium coprocessor" to get extra speed.

I think there were some Apple and Sun machines at one stage with a Pentium PC on a PCI board that could run MS Windows in a window on the main OS. I guess you could do a similar thing here, but it would probalby be a pain in the ass, expensive buying 2 processors, and wouldnt really achieve much for you.

Re:AMD

[benzapp]

fuck you. Just go see a doctor for some cream to put on that swollen penis of yours. The redness will go away, and you won't be such a bitchy prick anymore. You should stop masturbating 10 times a day to avoid that kind of rash in the future however.

The old alpha maybe couldn't do it...

[Ayanami Rei]

because the bus itself wasn't 64-bits wide.

All modern chipsets, intel/via/amd, ppc, sparc (and probably the EV7-and-up alphas... just speculation) have 64-bit buses to RAM/northbridge, and at least as wide to L1/L2 cache.

16-bit?

[jaf1230]

I was actually talking to someone (a Mac person) today, and he was talking about a CAD prog and how it was 16-bit and wouldn't run on the g5... Any idea as to the 16-bit compatibility of the Athlon 64 (FX) and the Opteron/Itanium?

I do want to be able to run Win3.11wfw on my Athlon 64 3400+ of course ;-)

Biggest use

[RevMike]

You forgot the biggest need for 64bit - Database hosting.

Video editing and large data set computing are both somewhat niche uses.

Virtually every moderate and large size business is running a whole lot of databases, be they Oracle, Sybase, DB2, or even (egads) SQLServer. Nothing helps a database scale like more memory. Memory allows more buffering of data as well as the ability to do sorting and join operations without resorting to temp space on disk.

Hang on to your Hat....

[turgid]

Dell is coming.