Opteron launches
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.
Posted Apr 24, 2003 1:27 UTC (Thu)
by coriordan (guest, #7544)
[Link] (8 responses)
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
Posted Apr 24, 2003 2:32 UTC (Thu)
by proski (subscriber, #104)
[Link]
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:
Posted Apr 24, 2003 2:33 UTC (Thu)
by dlang (guest, #313)
[Link] (2 responses)
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
Posted Apr 24, 2003 20:27 UTC (Thu)
by josh_stern (guest, #4868)
[Link] (1 responses)
Posted Apr 30, 2003 4:17 UTC (Wed)
by emkey (guest, #144)
[Link]
Posted Apr 24, 2003 8:02 UTC (Thu)
by decaffeinated (subscriber, #4787)
[Link] (1 responses)
Eight Megs And Continuously Swapping
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.
Posted Apr 24, 2003 9:18 UTC (Thu)
by james (subscriber, #1325)
[Link] (1 responses)
From the article:
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.
Posted Apr 24, 2003 22:09 UTC (Thu)
by jzbiciak (guest, #5246)
[Link]
Posted Apr 24, 2003 11:20 UTC (Thu)
by ibukanov (subscriber, #3942)
[Link]
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.
Posted Apr 24, 2003 14:01 UTC (Thu)
by leandro (guest, #1460)
[Link] (4 responses)
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...
Posted Apr 24, 2003 17:18 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (3 responses)
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.
Posted Apr 30, 2003 5:32 UTC (Wed)
by emkey (guest, #144)
[Link] (1 responses)
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...
Posted Aug 7, 2003 21:38 UTC (Thu)
by leandro (guest, #1460)
[Link]
Good for them. But a RISC system in the same process would be even faster with less heat, and be smaller too. 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.
Posted Aug 7, 2003 21:42 UTC (Thu)
by leandro (guest, #1460)
[Link]
It still matters enough that the ARM and the POWER are more efficient designs. Ever saw an x86 high-performance embedded system?
Posted Apr 24, 2003 21:04 UTC (Thu)
by del (guest, #380)
[Link]
> Building "cat" as a 64-bit application can only serve to make it bigger andNice jab at Emacs ;)
> slower. So a processor with native 32-bit support is a good thing.
'cat' only requires 16 bit ints. How come no-one ever compiles apps as 16-bit? How come GCC doesn't have a "compile as lower bit-width" optimisation? (or was someone just taking a wild guess? ;)
> scientific crankers, large databases, emacs) will benefit
Hardly a useful optimization
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.
My guess is that that the transition is going to be more painful than going from 16-bit to 32-bit, and that there will be a lot of "partially 64-bit" software, including operating systems.
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)Nice jab at Emacs ;)
When I looked at the specification of Opteron (some time ago), it Opteron in 32 vs. 64 bit
seemed 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?
Its my understanding that you can only use the extra registers in 64 bit mode on the released opteron.
Opteron in 32 vs. 64 bit
As I recall, that'sNice jab at Emacs ;)
Nice jab at Emacs ;)
Nice jab at Emacs ;)
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.
James.
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.
Nice jab at Emacs ;)
> 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.Opteron launches
x86 is inefficient, because the ISA must be translated into an internal RISC or VLIW.Opteron launches
Opteron launches
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.Opteron launches
Opteron launches
> the Opteron system generated FAR less heat then the dual itanium2. Plus the Opteron system was roughly the same size.
> I believe VLIW CPU's such as the itanium have an analog to the decoding that goes on in the X86 based CPU's.
Opteron launches
> The inefficiency caused by the need to translate to internal RISC operations matters less and less as time goes on.
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.e(ventually) m(unches) a(ll) c(omputer) s(torage)
Thank you, John Corbet, for the laugh.
I find people who run Star Office yet eschew emacs as bloated to be puzzling indeed.
del