AMD is celebrating the one-year anniversary of its 64-bit Opteron processor this week, but executives are looking forward to what may be a more crucial time for the upstart processor.In its first year, Opteron has established itself as a platform for high-performance computing, but it has yet to develop a serious foothold running the type of packaged applications associated with enterprise computing. Part of the reason is that only a limited number of enterprise applications have been written to take advantage of AMD’s (and Intel’s) 64-bit extensions to IA-32. And the most notable hole in 64-bit x86 support is Windows, which is scheduled to support both Opteron and Intel’s EM64T in the second half of this year. Read more at PCWorld.
AMD Waits for 64-Bit Apps
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The first anniversary of a very nice processor.
BTW, I wonder how 64-bit Windows is going to deal with drivers (I mean those who are no longer supported).
Oh, apropos amd64: I hope libpwcx.a (sadly proprietary) will soon get compiled for amd64 so that I get more fps through the webcam lying around here currently.
I see people going out at getting the 64 bit chips already, but why unless someone is a developer? What apps are there that fully take advantage of it?
You know, there’s this small, unimportant OS called Linux… 😉
But it’s true, even on Linux it took quite a while ’till AMD64-optimized apps surfaced.
Well the only apps I’ve heard that take advantage of 64-bit procs are a few film apps such as Shake and Smoke but apps such as XSI, Maya, Houdini, etc are still 32-bit. So it’s understandable why AMD is holding off on releasing any more 64-bit procs till the software developers catch up. I was suprised companies such as Softimage and Alias are soon releasing major updates for their software but still will only offer 32-bit apps. Either there is not enough interest for 64-bit or software developers are unwilling to make the leap at this time. Sort of silly that there are 64-bit procs and 64-bit OS’s but hardly any 64-bit software. Makes one question why purchase a 64-bit system at current prices when there isn’t much software support for the technology?
Once Intel actually releases their processes AMD will probably loose some ground. This is due to the fact that people oddly enough trust the Intel brand more than AMD even though AMDs Opeterons could be better. Of course AMD has the advtage probably in MP servers where there are more than 2 processors but just as the guy at the end of the article said it himself people just trust Intel more than AMD.
I have no doubt that Microsoft is helping Intel by delaying 64-bit Windows and MS apps, giving time to Intel make a 64-bit Pentium.
have no doubt that Microsoft is helping Intel by delaying 64-bit Windows and MS apps, giving time to Intel make a 64-bit Pentium.
Microsoft is not helping anyone but themselves here. By delaying the release of a 64 bit version of Windows XP for these chips until both AMD and Intel have them, Microsoft is ensuring that niether chipmaker can get too powerful.
Also, by delaying the release until after they’ve got XP SP2 integrated into their shiny new OS, they can push it as the next great thing for a few years until Longhorn is no longer a development branch.
> at current prices
What are you talking about? I had a hard time finding a cheaper 32-bit laptop than a 64-bit Acer Aspire 1500 with the features I wanted. Well, I failed and got me the latter.
Funny how Intel is now catching up…
Has anyone ever got any 64-bit linux distro stable with their Opteron?
I have tried Mandrake’s 9.2 and 10.0 RC1 for AMD64 and could not even get an install with 9.2, 10.0 RC1 installed okay, but still a little shakey.
Wondering about the SuSE 9.1 offering.
What? First understand software developers that port to Windows are not directly influenced by Microsoft as they are seperate companies. Secondly, Intel has already released it’s Itanium2 which is 64-bit and backwards compatible with 32-bit apps.
The only slow down has been with Microsoft and their delay for AMD support with their 64-bit WinXP. It’s as far as I know still in beta. Microsoft’s tactics are similar to RedHat by seperating support for procs on differant OS releases and then marking up the prices. This is unlike SuSE Linux 9.1 that offers support for both single and dual Intel/AMD procs in one OS. SuSE even offers the Professional version with a 32-bit OS and 64-bit OS to satisfy everyone with out any added cost. It’s true that in the past SuSE worked closely with AMD but are now trying to offer a product that meets the demands of all consumers. Whether they are a home user or company.
As for a 64-bit Pentium it will most likely be a 64-bit Itanium2 but with Hyperthreading, similar to Intel’s XEON that has Hyperthread support. At least for now AMD is ahead of the game and really there is no need to produce more chips till software developers can catch up with current technology.
As for a 64-bit Pentium it will most likely be a 64-bit Itanium2 but with Hyperthreading, similar to Intel’s XEON that has Hyperthread support.
Uh, no. Intel has already announced that it’s going to use the AMD x86-64 ISA (with possible small modifications) branded as IA32-e with its new Xeons and Pentium 4s.
Itanium is dead in the water, and Intel knows it.
>> Judson: I see people going out at getting the 64 bit chips already, but why unless someone is a developer? What apps are there that fully take advantage of it?
The chips include significant performance improvements for 32-bit software (e.g. an on-die memory controller). That’s why they are beating P4’s in benchmarks *now* whilst being very competitive in pricing.* They also happen to be rather “future proof” in the sense that they support AMD64. Moreover, when the 64-bit software is released, there will be additional speed because of the increased number of general purpose registers, and software that actually needs to be 64-bit should gain some boost with the better memory addressing and/or faster 64-bit integer operations.
* Admittedly, you do have to know what chips to look for and where to get them although this affects enthusiasts moreso than companies (which normally buy in bulk).
> Marcelo: I have no doubt that Microsoft is helping Intel by delaying 64-bit Windows and MS apps, giving time to Intel make a 64-bit Pentium.
The 64-bit beta of Windows XP does not even come with sound support, and Creative has just recently released beta audio drivers for AMD64. Porting the operating system is a heck of a lot easier than making sure all your third party software (apps and drivers) will work correctly and not create support nightmares for you and your third parties. One of the things that has always plagued Windows has been the crashing of this third party software; having tons of problems at product release would be disastrous for PR.
>> emagius: Itanium is dead in the water, and Intel knows it.
I agree with the rest of your comment but not this. Intel will be releasing new Itanium chips with a significantly better price/performance ratio. Not for the desktop, though, and yes you would have to be a tad ignorant to believe that Itanium will be working on the desktop any time soon. I think that Itanium is exploring new concepts and that it will take many years of R&D for it to become very successful.
Let HP know also when they get made. They have a few Alpha 64’s that are still waiting.
“Itanium is dead in the water, and Intel knows it.”
Only in the sense that POWER is dead in the water, and IBM knows it….
i’ve heard that there are vector FPU chips that plug in via PCI that deliver something like 40GFLOP.
why not partner that with the opteron over hyper transport rather than over PCI, and have this pair go against even the fastest Itanium or Power
x86 has 8GP and 8SSE; x86-64 has 16GP and 16SSE
why only a small increase in GP?
i’m surprised that since amd had a chance to create a clean new 64-bit processor, one that is more risc like,
why didn’t they extend the 8GPU to 32 or 48 or even 64 registers, rather than to 16GP registers.
and the same with the SSE registers.
most RISC cores like POWERPC use 32GP registers, whereas opteron only has 16GP.
There are a few apps around for suse’s 64bit amd linux version, thinking outside film for a moment, and into mathematics: there’s Mathematica; with matlab to support in the upcoming version 7.
Gentoo/amd64 works fine here. I don’t know what’s up with Mandrake, but gentoo flies on my laptop.
16 GPRs is a quite low figure comparing to RISC CPUs, maybe the architecture of x86 allows efficient handling of stack stored temporary variables and functions parameters. On RISC CPUs, usually, at least half the GP registers are used for “C stack” datas. Maybe AMD wanted to keep the traditional x86 programming model.
Believe it, Itanic is now under the flotation line. It was a superior design based on new ideas but now the performance edge over x86-64 is desappearing and the price difference related to the production levels and AMD concurrence will kill it.
For many years, DEC Alphas were the most powerfuls CPUs. They didn’t desappeared because they became obsolete or a better technology was invented. The x86 massive production weapon destroyed it.
( Anyone have heard of the legendary Intel 432 with advanced concepts as tagged data types registers and hardware garbabge collection features… An huge expense for Intel evaporated also by the x86 line, 80286 at that time )
BTW, PowerPCs are by no way dead, even without Apple computers or IBM servers, PowerPCs can live on the embedded market, just like the ARM which was first used in a computer ( Archimedes … ) and now in portables phones.
( But I think that PowerPC computers will also exist for some time also … )
SuSE 9.0 is stable on the Athlon64 F48.
I often hear people argumenting “they have to optimize app XYZ for 64Bit”.
Why do I have to port/optimize for 64Bit?
Isn’t that just a recompile on a AMD64 PC?
Most programs made for non-windows platforms will require little or no changes.
Frameworks like wxWidget or the OpenOffice.Org framework is 32-bit and will need to be ported in order for the applications to be recompiled for AMD64.
The vast majority buy them because they’re just faster in 32bit than the Athlon XP. If you want a fast 32bit processor that won’t break the bank at the moment, the Athlon64 is it. You just happen to get the AMD64 extensions extra.
Well the very low numbers of added GPR’s in the AMD64 (8GPRs and 8 regular) did stun me too …. 32 GPRs would make the AMD64 very interesting – even in 10 years time…
Regarding Linux on the AMD64, well SUSE took part in the porting process – I would go with the SUSE Linux at the moment (The SUSE Linux 9.1 Pro will include both an IA32 DVD and CD’s and an AMD64 DVD)
Regarding the dead in the water …. HP knows Itanic is dead in the water – I’m not sure that Intel even kbows what they’re doing at the moment – and IBM sells everything to everybody (Including Itanic, Power, PowerPC and AMD64)…
Software support. You’d need to write specifically for that setup, and not a lot of applications could really use that power efficiently.
>> —.rasserver.net: x86 has 8GP and 8SSE; x86-64 has 16GP and 16SSE why only a small increase in GP?
Features which may be good and even necessary for one architecture may not even be useful on another architecture. I have heard that GPRs over 16 simply did not significantly impact performance. Keep in mind there are processors that work at optimal efficiency without cache memory, albeit not on the desktop. 😉
>> Jan M: I often hear people argumenting “they have to optimize app XYZ for 64Bit”. Why do I have to port/optimize for 64Bit? Isn’t that just a recompile on a AMD64 PC?
Being able to compile and run in 64-bit mode is not the same thing as being able to run efficiently in 64-bit mode. Some applications have been using tricks to do 64-bit math efficiently on 32-bit processors; the compiler cannot just automatically find all tricks and replace them with clean, optimal 64-bit code. Generally, programs which have been written well (i.e. ones that have been encapsulating low level code into inline functions or macros) will be easier to optimize for AMD64. Developers that handled 64-bit integer math by spreading inline assembly code all over their programs or that handled it by using the equivalent C bit operations all over the program would have a big job ahead of them if they decided to optimize for AMD64.
>> flywheel: Regarding the dead in the water …. HP knows Itanic is dead in the water – I’m not sure that Intel even kbows what they’re doing at the moment – and IBM sells everything to everybody (Including Itanic, Power, PowerPC and AMD64)…
Well, as I said, Intel is redesigning the Itanium processors to make them significantly more efficient and less expensive. I should also add that Intel is designing future chipsets to be compatible with both Itanium and Pentium. It is not infeasible that you would be able to buy motherboards to work with either chip in, say, two or three years time. After that the buying decision would rest more on the merits of the chips.
If Intel really wants to churm out Itaniums, the x86-64 line of products is clearly an obstacle.
By supporting AMD’s architecture, they abandoned the idea of making Intaniums mainstream ( Intel never believed that 64 bits were of any use on personal computers, which is not that much stupid actually )
Well, the x86 architecture is like the Babel Tower with many levels of additions to the programming model : FPU, 386 registers, MMX, 3DNow , SSE, 64bits, … Maybe the next Itanium will support both x86-64 and genuine 64 bits programming model : Intel and AMD have already gone beyond the reasonable level of patches and fixtures to that architecture 15 years ago, there is no limit to x86 weirdness.
On why people trust Intel more than AMD – it’s simple. Intel have done much more to create a brand-identity (“Intel Inside”, and now, “Yes. Intel.”). Only recently have AMD gone to do a brand-creating campaign (“AMD Me”), but not as much effort was placed into it as Intel placed into their brand identity.
Branding goes a long way.
Plus, there wasn’t, until recently, any Tier-1 OEM making AMD-based servers; nobody want to be the first. Sun, the most high-profile backer of Opteron isn’t exactly renowned for its x86 lower-end servers.
If Intel really wants to churm out Itaniums, the x86-64 line of products is clearly an obstacle.
If IBM really wants to churm out POWERs, the x86-64 line of products is clearly an obstacle.
or..
If Sun really wants to churm out SPARCs, the x86-64 line of products is clearly an obstacle.
They aren’t in the same market. Itanium was made for the mid- and higher-end server market, Opteron, as reflected in its pricing (competitively priced against Xeons as opposed to Itaniums, or POWERs, or UltraSPARC, etc.) is made for the lower-end server and workstation market; a market that still uses x86 as their platform of choice.
Intel made Itanium largely to compete against higher-end processors and to replace Alpha. If there is anything threatening Itanium’s positions, it is POWER or UltraSPARC. Not x86-64. I don’t see how people using SGI’s MIPS workstations or Sun’s UltraSPARC workstations and servers would end up using Opteron – it is like desktop using StrongARM as their processors.
Besides, Itanium is based VLIW; x86 is based on CISC. The only way where Itanium can provide x86 instructions is via an emulating layer ala Transmeta’s Code Morphing – which isn’t hardware, rather software, emulation.
With on-board memory controllers, hypertransport links, high IPC, great FP performance, and if ServerWorks is creating chipsets that would support 16 and 32 way Opterons – you may be wrong.
(If unreliable, unsubstantiated, rumors are to be believed
http://www.amdzone.com/index.php?name=PNphpBB2&file=viewtopic&t=705…
I have an AMD64 machine running Windows XP on one partition for gaming and Mandrake 10 on another partiton. XP runs exceptionally fast and I have had no more crashes than I normally have had with Windows XP. Mandrake screams. I am really impressed with it, not to mention how easy it was to do a standard install.
Over all, I am very impressed with AMD and would go with them over Intel every time. Price/performance, they are much better.
Because AMD was trying to keep the opcode extension reasonable. x86 instructions already give 3 bits to specify which of the 8 registers to use for source, destination, base, and/or index. To go to 32 register would mean you would need 2 more bits, or a total of 6 more bits to specify all the above. This would mean you would need two bytes to use as an extension to the normal x86 opcode – one byte to indicate the next byte contains the extension bits. You could do it, but it makes the code much larger.
What AMD did was to redefine 16 opcodes (the one byte INC reg/DEC reg opcodes) to give themselves four bits: 1 for the operation size override, and three to give 1 extra bit for each of the register specification fields for a total of 4 bits – 16 registers.
thanks. is it a good strategy?
I think so. I used to program on the 68K chips, and they had only 16 registers (8 data, 8 address). It’s what I would call a minimum configuration. 8 registers is just too few, 16 is the lower end, and I really wouldn’t go past 64 on the upper end. It’s possible a future upgrade will add the two byte extension for 32 registers… you never know. In the meantime, 16 will do just peachy for those of us who feel cramped by 8.
thanks “JF” for explaining that point. i did not know 68k had only 16 registers. if you wouldn’t go past 64, what then is your opinion for the Itanium, which has over a hundred?
but such a possible future update, wouldn’t that break compatibility?
i’m curious as to whether there are opportunities for improvements in opteron that amd missed, for example, hyperthreading ala P4. it’s my understanding they extended the GP and SSE registers but not the FP registers.
do only compilers benefit from those extra registers?
Itanium is typical Intel over-engineering. You saw the same thing when Intel added protected mode to the x86 line. I don’t know of any OS that makes use of more than a fraction of the features Intel made part of protected mode. Same thing for their version of “RISC”. WAY over-engineered. Making VLIW part of it guaranteed that very few people would ever do assembly language programming on it. Therefore, most other features don’t even come into play. Only compiler writers wind up making any use of the features in the IA64. Hence, all that extra effort wound up being a complete waste, even before AMD64 killed it.
Adding a two byte extension for more than 16 registers would keep backwards compatibility for current AMD64 instructions. On older systems, such an extention would cause an unimplemented instruction fault, much like trying to execute SSE2 on a Pentium 2 CPU.
HyperThreading is based on the general idea that it is hard to schedule code that is completely free of dependencies. When a dependent instruction enters the instruction execution unit, it stalls the unit until the resource it depends on is free. During the time that unit is stalled, the other units COULD be running code for something else. The odds that code from one process would be dependent on the code from another process are small, so stalls are independent of the process. Ideally, running multiple threads on the same CPU keeps the execution units running all the time, giving you almost 100% resource utilization. In theory. In reality, it’s very bandwidth intensive to keep two seperate threads fed with data. It’s one reason why Intel’s L2 caches are so friggin’ huge… they need to be to make HyperThreading work. AMD would rather put more into dual core than HyperThreading. Another AMD64 core uses fewer transistors than the L2 cache needed to make HyperThreading work.
The FP and MMX are being phased out as obsolete (and 3DMax on AMD). They ARE obsolete – SSE2 gives ALL the same instructions as MMX on a larger data register, and then some, so MMX is no longer needed. The architecture of the FP is VERY archaic and wasteful of hardware. Scalar SSE does a better job and is easier to program, so FP is no longer needed.
More registers help compilers in that they can leave things in registers more often, but that also helps assembly language programmers in the same manner. Rather than making a local stack frame and constantly using [EBX+offset], you can just use all the registers. It makes a BIG difference in speed. I wrote a project where everything was accessed off a local or global stack frame, then went back after it was working and re-wrote it to keep things in registers whenever humanly possible. The version using heavy register use was more than twice as fast. It was a pain to debug because there were very few registers available… tracking the register usage was a huge pain. Having more registers makes the register tracking much more simple, leading to easier debugging.