Slashdot Mirror
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."
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.
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.
Life is the leading cause of death in America.
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?
Visit CryptoGnome in his home.
Absolutly nothing until programs start to utilize all 64 bits...and who knows when that will be
Setec Astronomy
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.
Trust the Computer. The Computer is your friend.
For you and I, JimBob and JoeBlow, a good fast 32-bit system will kick much 64-bit arse. At least until
Visit CryptoGnome in his home.
Linus Torvalds on 64bit desktops
Linus Torvalds on 64bit desktops
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
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).
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
This is basic real world physics and engineering here, not Wizards of Might and Magic.
Visit CryptoGnome in his home.
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.
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.
Stick Men
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.
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.
Sig, you mean I'm supposed to have a Sig????
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.
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).
Stick Men
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.
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.
My opinions are my own, and do not necessarily represent those of my employer.
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.
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.
...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.
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.
Degaussing scares the bad magnetism out of the monitor and fills it with good karma.
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).
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
Ita erat quando hic adveni.
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.
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.
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.