Weekly Edition
Return to the Front page
| |||||||||||||
Opteron launches
AMD has, at last, released
its long-awaited "Opteron" (or "Hammer") processor. LWN does not normally
devote much space to following developments in the microprocessor field,
but Opteron is worth a mention. There is a good chance that this is the
architecture many of us will be running in the future.
Opteron has the potential to deliver the best from both the 32-bit and 64-bit computing worlds. It will run 32-bit x86 code natively, and with good performance. That is a nice feature for people with binary applications, of course, though it is less useful in the free software world. If you have source (and an operating system which has been 64-bit capable for years), support for a new processor is often just a matter of running "make." There is another important aspect to 32-bit support, however: for most applications, 32-bits is the optimal size. Moving to a 64-bit mode involves a sizeable expansion of a program's code and data, with bad effects on cache utilization, virtual memory use, and memory bus bandwidth. Building "cat" as a 64-bit application can only serve to make it bigger and slower. So a processor with native 32-bit support is a good thing. There are situations, however, where only 64 bits will do. In particular, applications which need to address vast amounts of memory (e.g., big scientific crankers, large databases, emacs) will benefit from 64-bit pointers. So good 64-bit support matters too. Of course, the thing that really matters for Linux users is Linux support. AMD has worked with the free software community for years to ensure that its processor would be supported. The end result is that you can buy an Opteron server running a stable Linux port (choosing from multiple distributors) today. Windows support, instead, will show up in beta form only later this year, and Apple's support remains a rumor. In some areas, hardware support in Linux still lags behind other systems; with the Opteron, however, Linux got there first. If Opteron lives up to its PR, it could be a platform which brings Linux into many more machine rooms in the next few years. (Log in to post comments)
Nice jab at Emacs ;) Posted Apr 24, 2003 1:27 UTC (Thu) by coriordan (guest, #7544) [Link] > Building "cat" as a 64-bit application can only serve to make it bigger and> slower. So a processor with native 32-bit support is a good thing. Really? is someone sure about this? > ...applications which need to address vast amounts of memory (e.g., big Emacs ;) ...there was a time when this was true though. People mocking said it's name stood for "Eight Megabytes And Cycle Sucking". Eight Megabytes? cute, nowadays. Ciaran O'Riordan
Hardly a useful optimization Posted Apr 24, 2003 2:32 UTC (Thu) by proski (subscriber, #104) [Link] How come GCC doesn't have a "compile as lower bit-width" optimisation?This would have to be done across the board. Not just cat, but also libc would have to be recompiled. It int is 16-bit for an application and 32-bit for libc, such application would be unable to call libc functions without some kind of conversion of all data passed to and from those functions. Another problem is that such optimization would be quite inefective on some architectures, including i386. You can have either 32-bit code that uses 32-bit and 8-bit registers, or 16-bit code that uses 16-bit and 8-bit registers. Using a 16-bit register in 32-bit code or vice versa requires a special instruction prefix. Finally, there are very few applications that would benefit from such optimization. cat spends most time in libc and kernel. Any large program needs to address more than 64k. Programs doing heavy calculations with little code would still benefit from 32-bit bus width, given that the modern processors have on-die cache sufficient to keep the whole program and make memory access speed a non-issue. Now, going from 32-bit to 64-bit is different because:
Nice jab at Emacs ;) Posted Apr 24, 2003 2:33 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] yes there are people who have looked at things like 'cat' in 32 bit and 64 bit mode. there have been discussions on this topic on the kernel mailing list a few times, this is in part why you can run the PPC with a 64 bit kernel and 32 bit userspace (and why people want to)it turns out that if you have 64 bit kernel support simple tasks like cat really don't get any faster if you make cat 64 bit as well, and in some conditions actually make it slower due to the cache effects of the larger code the Opteron is even better in that it appears to allow you to run a mixed 32/64 bit userspace so programs that don't benifit from the 64 bit mode can remain small while those that do can be compiled in 64 bit mode to gain the advantages
Opteron in 32 vs. 64 bit Posted Apr 24, 2003 20:27 UTC (Thu) by josh_stern (guest, #4868) [Link] When I looked at the specification of Opteron (some time ago), itseemed that one had to use 64 bit code in order to get the advantage of extra working registers (a significant shortage on 32 bit X86). Is this still true, or has it been revised?
Opteron in 32 vs. 64 bit Posted Apr 30, 2003 4:17 UTC (Wed) by emkey (guest, #144) [Link] Its my understanding that you can only use the extra registers in 64 bit mode on the released opteron.
Nice jab at Emacs ;) Posted Apr 24, 2003 8:02 UTC (Thu) by decaffeinated (guest, #4787) [Link] As I recall, that'sEight Megs And Continuously Swapping
Nice jab at Emacs ;) Posted Apr 24, 2003 17:14 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] Right, the comment comes from the days when an 8Mb program was big and would continuously swap. But nowadays, Emacs is only a medium-sized program; Mozilla and many Gnome and KDE programs are a good deal bigger. It's time to retire the slams against Emacs. They are out of date.
Nice jab at Emacs ;) Posted Apr 24, 2003 9:18 UTC (Thu) by james (subscriber, #1325) [Link] From the article: Building "cat" as a 64-bit application can only serve to make it bigger and slower. So a processor with native 32-bit support is a good thing. Actually, on the x86-64 architecture, the "slower" bit is dubious. In 32 bit mode (which is designed to run existing binaries without modification), programs only have access to the x86's eight general purpose registers, and not all of these are really general purpose. In 64 bit mode, AMD have added an extra eight. This means that x86-64 binaries have to load and store data to (usually cache) memory less often. This means that there are usually less instructions for the processor to decode. It also means that compilers have more registers to play with when optimising. On the x86, there is often a limit to the amount of instruction-level parallelism that compliers can get out of source, simply because there aren't enough registers to spell out that several operations can happen at the same time. The extra eight registers are supposed to make this sort of optimisation a lot easier. James.
Nice jab at Emacs ;) Posted Apr 24, 2003 22:09 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] You will trade instruction footprint for data footprint. Primarily, pointers will increase in size, but little else. In the end, it'll be close to a wash performance wise for most applications that aren't register starved (eg. cat), and a boost for anything with code that could use more registers.
Opteron launches Posted Apr 24, 2003 11:20 UTC (Thu) by ibukanov (subscriber, #3942) [Link] > There are situations, however, where only 64 bits will do. In particular, applications which need to address vast amounts of memory (e.g., big scientific crankers, large databases, emacs) will benefit from 64-bit pointers. So good 64-bit support matters too.You also forgot about applications that needs to use memory mapping for files with total size exceeding 2-4 GB which one can do with 64 bits even if total amount of RAM is, say, 256MB. So working with video and other multimedia would benefit from it as well if applications would not need to resort to read/write when they are close to 2GB limit and when squeezing max performance is especially important.
Opteron launches Posted Apr 24, 2003 14:01 UTC (Thu) by leandro (guest, #1460) [Link] x86 is inefficient, because the ISA must be translated into an internal RISC or VLIW.x86 can be emulated for old binary-only apps. GNU/Linux users shouldn't even need to care, since most, ideally all, we use is free software, thus easily ported to 64 bits RISC. Even Intel and MS are moving out of x86. I do see the value of attacking the other leg of the Wintel duopoly. But I think we should do it with something more efficient, such as POWER and PowerPC or UltraSPARC. In the end, people talk so much about ecology and don't care that almost all computers waste so much energy on an inefficient CPU, fans and air conditioning...
Opteron launches Posted Apr 24, 2003 17:18 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] The inefficiency caused by the need to translate to internal RISC operations matters less and less as time goes on. Most of the area of modern processors is on-chip cache, and with a denser instruction decoding you need less cache.
Opteron launches Posted Apr 30, 2003 5:32 UTC (Wed) by emkey (guest, #144) [Link] Besides, I've played around a little bit with a dual Itanium2 and a quad Opteron and the Opteron system generated FAR less heat then the dual itanium2. Plus the Opteron system was roughly the same size.I'm not a CPU expert by any stretch of the imagination but I believe VLIW CPU's such as the itanium have an analog to the decoding that goes on in the X86 based CPU's. The Opteron has the potential to do some serious damage to Intel and to be a huge boost for Linux. I have my fingers crossed that AMD doesn't screw this whole deal up...
Opteron launches Posted Aug 7, 2003 21:38 UTC (Thu) by leandro (guest, #1460) [Link] > the Opteron system generated FAR less heat then the dual itanium2. Plus the Opteron system was roughly the same size. Good for them. But a RISC system in the same process would be even faster with less heat, and be smaller too. > I believe VLIW CPU's such as the itanium have an analog to the decoding that goes on in the X86 based CPU's. Actually IPF is not VLIW, but a strange contraption called EPIC. VLIW would be a RISC carried to the extreme, which isn't quite viable for binary, general-purpose computing.
Opteron launches Posted Aug 7, 2003 21:42 UTC (Thu) by leandro (guest, #1460) [Link] > The inefficiency caused by the need to translate to internal RISC operations matters less and less as time goes on. It still matters enough that the ARM and the POWER are more efficient designs. Ever saw an x86 high-performance embedded system?
e(ventually) m(unches) a(ll) c(omputer) s(torage) Posted Apr 24, 2003 21:04 UTC (Thu) by del (guest, #380) [Link] I believe that our fearless editor is an emacs user. Like him, I look forward to editor nirvana when emacs finally has the 64-bit platform to enable zippy performance.Thank you, John Corbet, for the laugh. I find people who run Star Office yet eschew emacs as bloated to be puzzling indeed. del
|
|||||||||||||