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

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

[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

[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

[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

[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

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

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

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

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

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

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

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

[Bishop, Martin]

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

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

[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

[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

[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

[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

[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

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

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.

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.

Battle?

[Anonymous Coward]

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

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

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

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

I don't doubt it at all...

[shfted!]

Guess the Rumours are True.

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.

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

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

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?

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.

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.

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

[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

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

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

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.

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

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.

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

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

[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

[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

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

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

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