Red Hat Releases x86_64 Technology Preview, GinGin

HTMLSpinnr writes "Red Hat announced today it's release of GinGin64, a "Technology Preview" (read: not beta) of Red Hat's AMD64 technology. You can grab a copy here or at one of Red Hat's various mirrors. Though the version number listed in the release notes is 8.0.95, inside sources say it's based on Red Hat 9 plus some updates."

Comments

Great

[CausticWindow]

Anybody know about any (realatively new) versions of Linux for Itanium that one could benchmark this against? Preferably free of charge?

Re:Great

[Anonymous Coward]

Just get gentoo and install it on both pc's, benchmark, done. These are really nothing but recompiles.

Re:Great

[CausticWindow]

Ok, so the standard version of gcc can compile for both Itanium and x86-64? I'll try that then (when I can borrow some x86-64 hw too).

Re:Great

[vadim_t]

How are you going to benchmark it?

The only meaningful benchmark IMO is processing_power/cost. A comparison based on clock speed would be pretty useless since architectures are different, and Itanium is so incredibly expensive. I'm pretty sure that even if x86_64 is slower it's much cheaper to get enough CPUs for your needs than to buy an Itanium.

Re:Great

[pmz]

The only meaningful benchmark IMO is processing_power/cost.

So, you would be happy buying only eMachines to put in your server room ? :)

Re:Great

[pmz]

...Itanium is so incredibly expensive.

It is, because it was originally designed to compete with old "big iron" RISC servers. Itanium is big, it is hot, it is low-volume, and it is expensive.

I would bet that Opteron actually has Intel shitting itself right now. The more I see about Opteron, the better it looks for 1 to 4 CPU servers, which are generally powerful enough for most tasks, now-a-days. Opteron is sitting squarely in competition with Xeon, Itanium, PowerPC, UltraSPARC, MIPS, etc. for a huge segment of the server market. Opteron is going to make this next year very interesting, because 64-bit rack-mount servers with good processing power are now easily under $5,000. I am expecting a shake down in 64-bit pricing across the industry as everyone tries to compete.

Re:Great

[vadim_t]

No, I meant that the only meaningful way of comparing processors is provided power for the same amount of money. If I need a server can can handle X load, and I can either get a dual AMD machine for $3000, or a single CPU Itanium for $6800, then the AMD one clearly wins, even if the CPU can do less work per second than the Itanium.

Now, I didn't research this much, but my point is that all that matters is the cost of doing X task with AMD processors vs Intel ones. Clock speed is irrelevant when comparing completely different architectures. And the comparison of the fastest AMD CPU with the fastest Intel one is also mostly useless.

Re:Great

[Glock27]

The only meaningful benchmark IMO is processing_power/cost. A comparison based on clock speed would be pretty useless since architectures are different, and Itanium is so incredibly expensive.

There are two meaningful quantities. Performance, and price/performance. A performance metric, like SPEC, measures (primarily) the absolute performance of the CPU, by measuring the time taken to complete a given computational task. This might be computing a quantum dynamics problem, or calculating a satellite trajectory, or any other arbitrary computing task. Clock speed isn't relevant, only the total work done per unit time. SPEC uses a statistical measure of several integer-only tasks for the integer part of its test, and a similar scheme for the fp part. It has single-CPU tests and tests for multiprocessor systems. Opteron is a tad slower in FP (no big deal) but about 50% faster in integer performance.

Price/performance weights the performance numbers by the cost of the respective systems, and is a more important metric for many businesses. ;-)

Re:Great

[vadim_t]

Well, unless your budget is unlimited, or whatever you're working on is not paralellizable, price/performance is still more important than the performance of an individual CPU. I'm pretty sure that eventually we'll have to switch to using multiple CPUs anyway.

Re:Great

[gunix]

As I said before, prices are changing fast, so it is a little tricky to find the price.
But you certinly have a point here.
I'd say: find the time to complete your task for a number of computer modells FIRST.
Then it would be quite easy to find prices when you are about to place an order for 200 machines.

Gaming benchmarks is a totaly different thing. What difference does 145 fps do compared to 144 fps when your screen only updates 90 times per second?

Re:Great

[Glock27]

Well, unless your budget is unlimited, or whatever you're working on is not paralellizable, price/performance is still more important than the performance of an individual CPU. I'm pretty sure that eventually we'll have to switch to using multiple CPUs anyway.

Massively parallel supercomputers are being built using both Itanic, er, Itanium and Opteron processors. Compute performance and memory addressing capability per node are still important. Probably more important in those applications than absolute performance is performance per watt dissipated.

Re:Great

[vadim_t]

Ah, but if you've got to do something that requires a supercomputer then you have to look at the whole instead of just the CPU. For a consumer it makes sense to replace a 1Ghz CPU with a 2 Ghz one and see games work two times faster. But if you are processing GBs of data and accessing memory very randomly then it might not help much if your CPU spends most of the time waiting for the RAM.

In these cases you'd have to consider everything, for example, which CPU is better suited to the task, up to how many CPUs can your architecture scale, what's the memory bandwidth, what's the latency, etc. Perhaps the task can be done cheaply with a cluster, or you need Rambus memory.

Then, after thinking about all that you might decide that it's a good idea to pay IBM to provide a supercomputer to do your stuff on.

Re:Great

[Glock27]

Then, after thinking about all that you might decide that it's a good idea to pay IBM to provide a supercomputer to do your stuff on.

One Opteron based supercomputer is being built by Cray. It will use up to 10,000 Opterons.

SGI is building Itanium supercomputers.

Both companies know a bit about such boxes. ;-)

Re:Great

[captaineo]

Absolute performance might be important if you use software that charges exorbitant per-CPU licensing fees. I know several packages that cost $5k-$15k per CPU - in that case, the cost of the CPU itself is negligible, so you might as well go for the highest absolute performance.

Large datacenters also probably need to worry about performance/power consumed, and performance/heat output.

MMmm....

[grub]

GinGin and TonicTonic with a good squeeze of LimeLime.

Re:MMmm....

[Anonymous Coward]

Is that what they call a (double) Gin && Tonic ?

-smurk

Re:MMmm....

[Anonymous Coward]

Weird... I think I'll have to stop taking GinGin -- I'm seeing double.

Re:MMmm....

[Anonymous Coward]

GinGin and TonicTonic with a good squeeze of LimeLime
You surely mean GNU/Gin, Gnu/Tonic and GNU/Lime.

Regards,

RMS

Technology Preview???

[anandcp]

Alas, the world has learnt a lot from Micro$oft.
Technology Previews instead of plain old Beta??
What next, Mass User Testing instead of Release?
I expected it from MSFT, not from RedHat

Re:Technology Preview???

[black mariah]

My guess is that 'technology preview' is the equivalent of alpha, not beta. Meaning they'll give you all the code for you to see how it works, but don't expect anything to be useful.

Re:Technology Preview???

[Max Romantschuk]

Technology Previews instead of plain old Beta??
What next, Mass User Testing instead of Release?

Actually, a Technology Preview usually signifies an Alpha. It's more like "We have something working" than "Please test this nearly-finished-product for us".

Not that I'm saying there's no hidden agenda, who knows? ;)

Re:Technology Preview???

[Timesprout]

I think previews are a good idea as a measn of guaging customer response before commiting to a full release schedule of functionality and dates. Let potential customers play with it for a while and get their feedback without everyone wondering when it will be released, are dates slipping, will features be dropped rtc ad nauseum. It gives people a chance to properly evaluate and provide meaningful feedback

Re:Technology Preview???

[Anonymous Coward]

It's Linux innovation.

Re:Technology Preview???

[_|()|\|]

Technology Previews instead of plain old Beta??

Matt Wilson explained this in the linked thread:

This isn't a beta for a product - it's a Technology Preview. Unlike a beta, it doesn't reflect what will be included in any planned future product. The next release of Red Hat Enterprise Linux ... will support the AMD64 platform in both 32 and 64 modes.

They're doing this to gain experience with the platform. This preview is based on RHL 9, whereas their first actual x86-64 product will probably be part of the next version of RHEL.

Is it worth it?

[AlistairGroves]

So how big are the performance gains? And does this make it worth holding out for the Athlon 64 proccessors?

Re:Is it worth it?

[g4dget]

64bit is not primarily about raw processor speed, it's about being able to address more than 4G of memory. But, FWIW, the AMD chips seem to be a bit faster than the current crop of 32bit chips as well.

Re:Is it worth it?

[Anonymous Coward]

...plus the marketing value. A pointy haired boss drool for buzzwords, if it ain't "64-bit" it's not interesting. Trust me, it's like this IRL. Running a 32-bit OS on a 64-bit arch sounds "half efficient" for the PHB.

-smurk

Re:Is it worth it?

[Anonymous Coward]

Why the hell would you "hold out" for an Athlon 64 processor? If you're going to get a server processor, get an Opteron. If you're not, get an Athlon 64. There's no holding out to it.

They're the same processor optimized for different things. So shut up and get whatever one is optimized for your use. If it's the Athlon 64, it's not called holding out, it's called WAITING.

Re:Is it worth it?

[ShonFerg]

Actually, the biggest speed boost from operating in 64-bit mode comes from the fact that Opteron/Athlon 64 has twice the general purpose and SSE registers, and also is the first AMD processor to support SSE2. The low register count has always been a stumbling point for x86 processors compared to other technologies like the PowerPC, which have many, many more. This is the fastest and most vital memory to any processor so adding more was an awesome decision, but of course they only work in 64-bit mode.

The fact that it's 64-bit will only help you (double the speed, actually) if you're operating on 64-bit variables, which don't come up in general software very much, but are very good for scientific research, simulations, etc.

And yes, you can directly address more than 4GB of memory... in fact each processor has it's own memory controller built in which also adds to the speed a bit and means that in multi-processor systems each processor gets its own bank of DIMMs.

There's a wonderful article over at ArsTechnica which does a great job of explaining all the benefits of the x86-64 technology here.

--Shon

Re:Is it worth it?

[p3d0]

64-bit ops can be more than twice as fast as 32-bit ops on 64-bit data. Consider multiplication, where you need to do four pairwise multiplies plus some adds. Or "neg", which is one instruction for 32-bit data, but three instructions for 64-bit data on a 32-bit machine. (neg low, adc high, neg high)

Re:Is it worth it?

[Vasilis Vasaitis]

The fact that it's 64-bit will only help you (double the speed, actually) if you're operating on 64-bit variables, which don't come up in general software very much, but are very good for scientific research, simulations, etc.

This is a common argument, and I get to see it all the time. I.e., that 64-bit calculations are not going to benefit a lot of people, because not many people are using them right now. On the other hand, people aren't using them now because they can be painfully slow on their 32-bit computers, so what's the conclusion?

Anyway, I've been thinking about this lately, and I've come up with a case that you might be able to get a lot of speed improvement from the 64-bit processor: fixed point calculations. I mean, floating point has always been slow compared to integer math, but if you need it, what's the alternative? Fixed point math with 32-bit integers is very inaccurate for most tasks, so you're stuck with the slow FP ops. Or are you?

The 64-bit integers that AMD64 provides give the programmer a lot of room for fixed point math. With a 32-32 split, for example, you get the all-so-familiar 2 billion range for the integral part, plus a reasonable amount of accuracy for the fractional part. And you can always work with uneven splits, so the possibilities are endless.

So, how is this going to benefit programmers and users? Take video processing as an example. You often see in DVD backup programs, choices for a given task like "integer - fast" vs. "floating point - accurate". Well, with the AMD64 processors, you'll probably have a third option as well: "fixed point - fast *and* accurate". Or it might not even be an option, but the only default. So the user gets all the eggs in one basket, and the programmer gets to write less code. w00t!

Re:Is it worth it?

[ShonFerg]

Fixed point 64-bit math is something I hadn't considered, but you're right, that might be an alternative to using floating point.

Still, using SSE2 would probably be a better alternative for applications like DVD burning which require repetative instructions since you can process packages of 128-bit data all at once. That way you could instruct the processor to take in 4 32-bit floating point numbers (or 2 64-bit ones) at one time and do operations on them them in parallel rather than process one 64-bit fixed-point integer at a time.

x86-64 also has double the SSE 2 registers that the Pentium does (in 64-bit mode) as well, though they're the same size. I think it's fairly exciting that developers will be able to begin to assume SSE 2 support on all new systems once the Athlon 64 replaces the current Athlon.

Personally, the only thing I've used 64-bit integers on the current 32-bit platform for was high-resolution timing.

--Shon

Re:Is it worth it?

[g4dget]

The fact that it's 64-bit will only help you (double the speed, actually) if you're operating on 64-bit variables, which don't come up in general software very much, but are very good for scientific research, simulations, etc.

No, that's just not true. "64 bit" these days only tells you something about the size of a pointer but not much more. Beyond that, 16 bit, 32 bit, and 64 bit processors have a wide variety of operations, ALUs, and bus widths. There are "32 bit processors" with 16 bit data buses, "32 bit processors" with 128 bit data buses, etc.

It is very unlikely that on a well-defined 64 bit processors, half the processor remains idle when you use 32 bit operations.

In any case, my point was that the main reason for going to 64 bit is not speed. It just happens to be the case that the AMD Opteron is probably also the fastest 32 bit x86 chip around right now.

Re:Is it worth it?

[ShonFerg]

No, that's just not true. "64 bit" these days only tells you something about the size of a pointer but not much more.

We're talking about x86-64 right? It has the capability to operate on 64-bit integer data, and use 64-bit pointers, and retains x87's existing ability to operate on 64-bit floating point numbers with 80-bit internal accuracy, while gaining SSE2's ability to operate on 128-bit vectors.

It is very unlikely that on a well-defined 64 bit processors, half the processor remains idle when you use 32 bit operations.

From my understanding, that's exactly what happens. x86-64 simply extends the existing x86 standard of allowing each register to hold smaller values, but only a certain number of them by giving each portion of the register its own name. You don't gain access to 4 times the registers in 32-bit mode, unfortunately. In fact, you only have access to the standard 8 registers because 32-bit x86 only knows about 8 registers. But not even by running 32-bit data in 64-bit mode do you gain the ability to store two 32-bit values in each GPR.

Check out this chart from the article I linked in my earlier post.

Also, if you go over and check out this article on Ace's Hardware where they benchmark various applications on an Opteron, you'll find this excellent explanation for why I said it would double the speed when operating on 64-bit data. Again, specifically talking about x86-64 here:

The Opteron has 64-bit general purpose registers, so any code that uses 64-bit integer operations should benefit a lot - using 2 32-bit registers, to do a 64-bit integer multiply takes 4 32-bit multiplies, and a 64-bit add requires 2 32-bit adds. To show this we have a custom micro-benchmark just on the Opteron which performs a "dot product" operation on two arrays of integers, which requires a lot of multiplies, with 32-bit and 64-bit integer versions and x86-32 and x86-64 code, using GCC.

[chart omitted]

The x86-64 version is 33% faster for 32-bit integers, probably due to greater loop-unrolling. With 64-bit operations, the x86-64 version is a massive 354% (4.54x) faster, with a combination benefit of more registers and 64-bit processing. Notice also that the 64-bit x86-64 result is the same as the 32-bit x86-32 result - with double the complexity of the data, performance is the same.

So that's what I was talking about, it simply takes more time, more iterations, for a 32-bit processor (one that operates on 32-bit data) to virtually process a 64-bit variable.

--Shon

Re:Redhat is dying.

[black mariah]

You might want to roger Redhat, but the rest of us prefer not to be so promiscuous.

Debian?

[g4dget]

How is the Debian support for the 64bit AMD chips coming along?

Re:Debian?

[Anonymous Coward]

Hold on there buddy you're talking new technology + debian better wait about a decade.

Re:Debian?

[m1chael]

it supports its 32bit i386 compatiblity mode.

Re:Debian?

[drinkypoo]

It's going great! Their plan for x86-64 support is coming along nicely:

1. Wait for RedHat to implement x86-64 support.
2. ?
3. Profit!

Of course, this is how it's done, this is what's so nice about FAOS programs, code reuse between projects. It is in particular what has made Linux the OS with the fastest-growing installed base, though I can't see how that could be true unless you lump all Windows together. Even lumping all NT together shouldn't work what with the 9x -> XP upgraders.

Re:Debian?

[Anonymous Coward]

they'll have to sign a NDA to get hold of Opterons. Once they're commonplace there will be a port. How sharing of 32 and 64 bit libs should be done in the FHS isn't decided yet. (also applies for SPARC)
There's people planning for an Opteron port, so don't worry, there will be a Debian port once they're common enough.

Yes but...

[Dot.Com.CEO]

Is there any online shop where I can buy an Opteron 2x motherboard as well as assorted processors? I would love to have one of those beasts on my desk right now but I have not been able to track anything down, at least in Europe.

Until I am able to buy Opteron motherboards and processors and build my own system, AMD64 is not here for me, unfortunately...

Re:Yes but...

[d^2b]

I saw opteron 242 processors on www.ncix.com
(a canadian company) for about euro 290 for
the retail box.

(For you norteamericanos, that is CAD 468)

Re:Yes but...

[Perdo]

You can always try pricewatch and look for a vendor that will ship to Europe.

http://castle.pricewatch.com/search/search.idq?q c= %22OPTERON%22*%20AND%20%40totalcost%3E0%20AND%20%4 0minorder=1&cr=opteron&ne=11693&l=1164 7

Re:Yes but...

[Anonymous Coward]

(For you norteamericanos, that is CAD 468)

Since there is $1000 CAD to the US dollar, I guess it's about 47 cents.

Re:Yes but...

[ergo98]

47 cents...$700...what's the diff, eh?

Oh, I get it: Funny! Ha ha ha ha.

Re:Yes but...

[Dot.Com.CEO]

Two problems:

. Shipping to Europe will cost a fortune and will be here after at least one month. . Customs will add at least 20-30% to the price.

So, basically, in order to order anything from the States, us Europeans have to pay much more to import it. Better wait a bit until the online shops catch up...

Re:Yes but...

[Sj0]

It's always great to mock the northern peso^H^H^H^H^H^H^H^H^H^H^H^H^HCanadian dollar.

Re:On what will it function?

[TheRealRamone]

Wasn't there an x86-64 emulator?

(checks search engine...)

Why hmm yes indeed there is.

Ouilah!

--TRR

Re:On what will it function?

[vesamies]

I don't think it will. You know, AMD64 technology is only 64 bits, whereas Commondore 64 is 64K bytes, which according to my calculations is 524288 bits. Keep your C64 in a closet for a while longer...

Is she re-badged though?

[matqua]

Will this "Technology Preview" feature modified components such (glibc, gcc, etc) or just redhat 9 with a patched kernel?

Re:Is she re-badged though?

[Fefe]

Why in heaven's name would you COME HERE and ASK US instead of go the Red Hat and ask them?!

My God, is there no limit to stupidity? Sheesh.

Re:Is she re-badged though?

[matqua]

they mentioned something in the brief so i thought id ask while i was here, geeze take it easy.

More Details

[Laven]

The RELEASE-NOTES of this technology preview appears to be almost exactly that of Red Hat Linux 9. Check out the discussion on AMD64-list for more details of what this Linux is capable of. Or rather, read the List Archives.

I personally ordered two Opteron servers this week. I plan on building an e-mail server and K12LTSP server using modified Red Hat Linux. My findings of success/failure when I figure out AMD64 Linux quirks will be posted to AMDMB.com in the coming weeks. (Also check out our Athlon Linux forum.)

From the AMD64-list discussion so far, there are only a few details:

* Kernel and all applications 64-bit compiled. This includes support for the larger memory address space and 16 registers. (SPEED!)
* AMD64 Linux *can* run 32-bit applications, unfortunately you would need 32-bit shared libraries that were not included in this technology preview. They said that they will be included in a possible future shipping distribution. I personally will try to research how to find/build these 32-bit shared libraries for myself, although I suspect it will show up on amd64-list soon enough.
* Existing 32-bit closed source programs like Macromedia Flash plugin 6.0 for Linux may work with 32-bit shared libraries, but not while running within 64-bit compiled Mozilla. You would need 32-bit compiled Mozilla. Bummer.

Re:More Details

[matqua]

sweet, now i want an opteron, but i don't want the bill

recompile

[dpilot]

But how good would a recompile for Itanium with gcc really be? I've been under the impression that the only really decent compiler for IA64 came from Intel/HP. It's a tough target to compile for.

Re:recompile

[Anonymous Coward]

Even then, most packages do not compile using, say, icc, but require gmake and gcc. Also it is realistically the only compiler to be used in a GNU/Linux system.

Re:recompile

[dpilot]

I don't dispute that. Even though it may not generate x86 code quite as good as icc, gcc isn't bad and is acceptable as the standard compiler for Linux. It's just that for IA64 the gulf in generated code quality between gcc and the Intel/HP compiler is much larger because it's a tougher target. There simply hasn't been much time for gcc on IA64 to mature, and Intel/HP have put a ton of resource into theirs.

As to the practical effect of this, I don't know. Since IA64 is currently targeted toward higher-end servers, it may not matter that things have to be a little different.

Re:recompile

[Monkelectric]

Actually I think if GCC is a bad compiler for Itanium, then that *SHOULD* be a factor in itanium performance. GCC is *the* standard compiler for *everything*. Claiming poor performance with GCC is absurd. This situation would be similiar to car manufacturers claiming poor performance with "gas". You need our *special* gas that we have a monopoly on. Intel *SHOULD* be contributing to GCC to make it a good compiler but they'd *rather* sell an expensive compiler.

Re:recompile

[dpilot]

Please don't get me started on IA64. I tend to go on minor tirades, though I guess I didn't on this particular thread. Let's just say that in no way do I disagree with you.

To bend over backwards in an attempt at fairness toward IA64, let's just say that the IA64 code generation of gcc is very immature, and perhaps time and a code fork will fix that. After all, that's what it took for X86.

Then for a mild bit the other direction, Intel's secrecy on portions of their documentation, Appendix H being the most notorious, probably didn't help gcc advance. Then remember that IA64 is simply *the most proprietary* architecture on the face of the Earth. NONE of the IP is cross-licensed, ONLY Intel and HP have rights. (IANAL, but this is from what I've read.) These remarks are aside from any performance, cost, heat, or particularly, compilability remarks that might be made.

Re:recompile

[Monkelectric]

No disagreement with you at all. Im just saying they should suffer the consequences of that secrecy in their benchmarks.

More seriouslier

[Anonymous Coward]

I think the appellation "GinGin" may be an homage/reference to the dog on "I Dream of Jeannie" that hated uniforms and could become invisible. Picture Dr. Bellows in a shredded uniform and you'll know what I mean.

Is everything ready or will it take some while?

[LocalHero]

I remember when the mmx processor came. It hade this all new instructions that would increase the preformance with over 400% or something :).. But there where no applications so all the mmx instructions did was increasing the cpu core -> making the cpu extra hot. Today we atleast have some programs that utilize the mmx instructions. But how long did it take? Now to the point. When they make a opteron dist "Windows 64 and Redhat for example" do they only make sure that all applications can run, like only patching the necesary or do they redisign the whole os optimizing it for speed?

Re:Is everything ready or will it take some while?

[jjp5421]

You forget that the Pentium (1) MMX processors doubled the L1 cache in the chip (16K to 32K I think), so even without MMX instructions in the software there was a good performance gain. As for the heat, they were still cooler than the Cyrix and AMD chips (only PowerPC's were running "cool" that year).

Re:Is everything ready or will it take some while?

[TeknoHog]

Porting to MMX/SSE/3DNow is not that simple, because they require parallelity in the code. Depending on the language and compiler, it can be automated to some extent, but usually the coder must explicitly state when it's OK to calculate some things in parallel.

On the other hand, if your code is 64-bit clean (as Linux should be, as it runs on many platforms including SPARC and Alpha), it's mainly a matter of recompilation to take advantage of 64-bit processors. AFAIK, there are no new instructions introduced with AMD's 64-bit procs, although I'm not sure if 64-bitness will affect the vector extensions in any way.

Re:Is everything ready or will it take some while?

[JCholewa]

> I remember when the mmx processor came. It hade this all new instructions
> that would increase the preformance with over 400% or something :)..
> But there where no applications so all the mmx instructions did was
> increasing the cpu core -> making the cpu extra hot. Today we atleast
> have some programs that utilize the mmx instructions. But
> how long did it take? Now to the point. When they make a opteron
> dist "Windows 64 and Redhat for example" do they only make sure that
> all applications can run, like only patching the necesary or do they
> redisign the whole os optimizing it for speed?

For the new instructions, you had to hard-code for the explicit parallelism. The additions in x86-64 include added registers, which would reduce the need for doing cache lookups. You don't have to specially code for this. So you can just recompile your app straight (this is reasonably trivial with the most important OSS).

I personally don't care all too much about the 64-bit registers (except that there are twice as many of them... that's kinda nice). There are other advantages under the hood that have nothing to do with needing recompilation. The integration of the memory controller and its subsequent reduction in memory latency has given a better performance boost than what I'd expected, given the benchmarks that have popped up. There are a few little microarchitectural things added on elsewhere. I haven't looked lately, but there are probably slightly larger buffers, capacity for more in-flight instructions, and I do recall that the instruction pipe was smoothed out somewhere around the decode area.

-JC

ROTFL

[Fefe]

Yeah, right, like you log in to a public free Itanic server to run some benchmark and expect to be a) the only user of that machine and b) that nobody logs in and skews your numbers while the benchmark runs.

Besides, Itanic is a horrible performer in day to day tasks. I compiled my libc project on a 900 MHz Itanic II and it was outperformed by a factor of four by my 900 MHz Pentium 2 notebook.

I'm talking about the compilation speed here. Transcoding MPEG-2 to MPEG-4 is also a lot slower, a German university group did some Itanic assembly optimizations to learn about the architecture, and their code was still much slower than an Athlon XP+ 2000.

In short: forget about Itanic. The architecture is doomed.

Re:ROTFL

[CausticWindow]

Who said anything about logging into a public Itanium server? I've got one in the office next to mine.

Re:ROTFL

[Fefe]

Man, it doesn't matter whether it's the Itanic or Hammer that is public. If it's public, you won't be alone on it, which will make proper benchmarking impossible.

Re:ROTFL

[CausticWindow]

And again.. I'm all alone on it if I so wish. :)

Also, how did you compile libc?

Re:ROTFL

[Fefe]

I typed "make" ;-)

Impossible!

[gillbates]

So you mean to tell me that Linux is available on a 64 bit architecture before Windows?! Does Steve "Mr. Innovation" Balmer know about this?

We all know this is a hoax. It's not possible for open source software to "innovate"...

Re:Impossible!

[Dot.Com.CEO]

Windows has been available on Itanium for a couple of years now. Also, Windows 2k3 server for the AMD64 is in the same phase (alpha) as the Redhat offering.

Also, read the release notes for the Redhat thingie and see if it is possible to have a proper workstation on that thing. To be fair, though, Mandrake appear to have a more complete offer for AMD64 than Redhat.

Re:Impossible!

[TheRealRamone]

gillbates: "Linux is available on a 64 bit architecture before Windows?!"

Mr. Innovation: "Uhh... They must have stolen the code from SCO..." {talking to wristphone:} "Call Utah!"

Re:Argh

[Fefe]

It actually has less instructions than, say, PowerPC with Altivec.

(Hint: first think, then research, then optionally post)

Re:Argh

[Anonymous Coward]

How the hell did this idiot get modded to 2? AMD64 is probably the tightest 64 bit proc EVER, sans Alpha!

THINK before crying "bloat", you fuckers! Or stay in your rooms and keep making love to you A1000s!

I will wait for official SCO x86-64 support

[Anonymous Coward]

Why does GCC support SCO UNIX, anyway?

Re:On what will it function?

[Anonymous Coward]

And what the fuck is Ouilah, pray tell? Some Australian euphemism I've never heard of?

I hope you didn't mean -voila-.

Hardly news.....

[jocks]

I am surprised that this actually counts as news when SuSE repleased their 64bit version a couple of weeks ago.

Re:Hardly news.....

[Rob Riggs]

Red Hat is the #1 Linux distro in North America. Slashdot is an admittedly US-centric site. So it an appropriate news story. Many of us Red Hat users are anxiously awaiting their X86_64 release.

Re:Hardly news.....

[jocks]

Aye fair comment. I would have pointed out the North American bias but I did not want to become a flame grilled wopper! It will be interesting to see how Linux develops on 64bit architecture...lets face it, the application porting will be far, far more rapid than the rate of it's closed source cousin's.

Re:Hardly news.....

[dughutch]

Mostly so... I believe Oracle and IBM have already completed their port to AMD64... and Oracle is recommending using Linux for it's platform.... Check out http://www.oracle.com/ip/deploy/database/theme_pag es/index.html?linux_02032003.html It's great to see such big $$ support already.

can you purchase an opteron (yet)?

[e40]

If so, are there mobos available, too? Links would be appreciated.

Overheard at Intel...

[Glock27]

"This thing is a steaming pile of crap, and we've spent almost ten years and billions of dollars!"

OK, it wasn't overheard at Intel. But it should have been.

SPEC2000 scores:

Itanic2/1 GHz.: 810/1174 int/fp
Opteron: 1202/1170 int/fp

The integer score is important for many general-purpose computing tasks, like web serving and database.

Gee, Opteron is MUCH less expensive, performs better, runs up to 8-way with off the shelf components and runs your 32-bit x86 code twice as fast and absolutely compatibly. Let me think about this... ;-)

Re:Overheard at Intel...

[pmz]

Gee, Opteron is MUCH less expensive, performs better, runs up to 8-way with off the shelf components and runs your 32-bit x86 code twice as fast and absolutely compatibly. Let me think about this... ;-)

I think all the current 64-bit CPU producers are thinking about this, too, and saying "oh" and "um" quite a bit trying to figure out there marketing plans.

Re:Overheard at Intel...

[pmz]

echo "I think all the current 64-bit CPU producers are thinking about this, too, and saying \"oh\" and \"um\" quite a bit trying to figure out there marketing plans." | sed -e "s/there/their/g"

Re:Overheard at Intel...

[Glock27]

I think all the current 64-bit CPU producers are thinking about this, too, and saying "oh" and "um" quite a bit trying to figure out there marketing plans.

Yah. Another important feature of Opteron is that memory bandwidth scales with additional CPUs in an SMP setup. That is sweet.

Re:Overheard at Intel...

[Glock27]

To those who chimed in with "Overrated" mods...don't shoot the messenger. As someone said "To moderate is human, to reply divine". Let's see your rebuttal.

BTW, I'm sorry about your Intel stock, especially regarding what's about to happen to it. ;-)

Re:Overheard at Intel...

[Anonymous Coward]

Geeks'r'us...

Re:Overheard at Intel...

[pmz]

Another important feature of Opteron is that memory bandwidth scales with additional CPUs in an SMP setup.

However, I think the bandwidth aggregates among the local memories attached to each CPU. To get maximum benefit, the OS kernel would need to know how to best schedule and allocate processes to prevent CPUs from accessing other CPUs' memories often.

Re:Overheard at Intel...

[pmz]

(drops head in shame and sighs)

Re:Overheard at Intel...

[Rob Riggs]

the OS kernel would need to know how to best schedule and allocate processes to [limit] CPUs from accessing other CPUs' memories

And this technology must be Unix proprietary technology owned by SCO, because, god knows, no one else could come up with ccNUMA...

Re:Overheard at Intel...

[Penguin's Advocate]

Dude, Hypertransport + X-bar, processors accessing each other's memory isn't a problem at all (hence the reason bandwidth effectively doubles with doubling of processors)

Re:Overheard at Intel...

[Some Dumbass...]

Gee, Opteron is MUCH less expensive, performs better, runs up to 8-way with off the shelf components and runs your 32-bit x86 code twice as fast and absolutely compatibly. Let me think about this... ;-)

Clearly, with its low cost, comparable performance, and ease of porting 32-bit programs, AMD's Opteron is going to cut into Intel's Itanium sales.

The real question is: what Itanium sales?

I assume that AMD isn't just positioning the Opteron as an alternative to the Itanium, but also as a "power user" chip, aimed at a slightly more general audience (e.g. video editing, CAD, scientific applications).

Re:Overheard at Intel...

[Glock27]

Clearly, with its low cost, comparable performance, and ease of porting 32-bit programs, AMD's Opteron is going to cut into Intel's Itanium sales.

The real question is: what Itanium sales?

Sure, Itanium sales are quite low right now. However, the whole idea of Itanium was to make a cheaper, faster, enterprise class server CPU that would kill SPARC, Alpha, PA-RISC and Power. It killed both HP architectures with marketing muscle alone. ;-) However, Itanic has decidely not lived up to the hype and the future isn't much brighter, IMO. Power is looking pretty good by comparison lately.

I assume that AMD isn't just positioning the Opteron as an alternative to the Itanium, but also as a "power user" chip, aimed at a slightly more general audience (e.g. video editing, CAD, scientific applications).

AMD has positioned Opteron as a general purpose workstation and server CPU.

Opteron looks like it has best of breed performance, at a much lower system cost. I think there'll be quite a shift in the marketplace. AMD's recent alliance with IBM looks particularly promising. It looks like the main threats from Intel are monopolistic behavior and marketing. Intel technology isn't looking so hot...

We'll see how it goes... I can't wait to get my hands on a dual Opteron workstation. :-)

Re:Overheard at Intel...

[cgori]

except that opteron specint is an estimated 1202 for a 2.0ghz chip (which isn't shipping yet). it goes like this:

• opteron 2.0ghz specint 1202 aka opteron 244
  
• opteron 1.8ghz specint ~1100 aka opteron 243
  
• opteron 1.6ghz specint ~950 aka opteron 242
  
• opteron 1.4ghz specint ~820 aka opteron 241
  
• itanium 1.0ghz specint 807
  
• itanium 1.5ghz specint ??? (~1200 likely)
  

you can't buy a 244 (or even a 243) yet, so comparing it to a shipping 1.0ghz itanium is not terribly valid. comparisons to the 1.5 are probably more accurate.

please don't get me wrong, the opteron is incredible bang for the buck, we're probably going to get some dual 244s when they become available. but please get your specints right when you quote numbers.

and i bet the "8-way with off the shelf" machines using 84x chips are gonna be much, much, much more expensive than the 24x-based machines. probably getting closer to itanium prices.

Re:Overheard at Intel...

[dracocat]

Gee, Opteron is MUCH less expensive, performs better, runs up to 8-way with off the shelf components and runs your 32-bit x86 code twice as fast and absolutely compatibly. Let me think about this... ;-)

You also forgot: Runs twice as hot

Re:Overheard at Intel...

[damiam]

As long as it's stable, why would anyone but a control freak/perfectionist care?

Re:Overheard at Intel...

[dracocat]

Less heat means a smaller heatsink. And less space required to dissipate the heat. When you pay for the rack space that your servers take it is very important. Putting a dual proc. AMD with 4 hard drives in a 1u is just asking for problems.

redhat is mining the community

[Anonymous Coward]

You just have to love RedHat's willingness to release a "free" technology preview; mine the early acceptors for feedback; after 6 months of refinement they'll then take it private and slap a $2500 RHEL pricetag on it.. is it worth the "preview"?

Re:redhat is mining the community

[Anonymous Coward]

Redhat is a FREE SOFTWARE COMPANY. Their OS is free software. The source to their Advanced Server kenel can be downlaoded freely by all.

And yes, you're an idiot.

Re:redhat is mining the community

[Anonymous Coward]

3 questions:

- If you rebuild the free SRPMS and package it yourself; can it be used without concern for violating some obscure RHAS license?

- does RH make RHAS updates available on their site in addition to the original sources? It doesn't appear as though they do; but maybe rsync'ing over time would prove they do?

- If you buy just 1 valid license for RHAS and use it to create light-weight images for hundreds of machines; does this vioalte the RHAS license? For instance on linux clusters that is 1 massive system that contains 100 or more nodes all running a barebones RHAS based image.

Re:redhat is mining the community

[Anonymous Coward]

There's this thing called the GPL. You may have heard of it. Please, feel free to read it, then die of haemmaroids.

Re:Argh

[TheRaven64]

It actually has less instructions than, say, PowerPC with Altivec.

(Hint: first think, then research, then optionally post)

Could you post a link to these statistics? What are you counting as an instruction? CISC instructions or micro-ops?

Oh, and I assume that you mean it has fewer instructions, not less...

You can have a nice dual-lie opteron workstation

[pr0ntab]

For about 3 and a half grand (which isn't too steep, bout the same for a nice Xeon system). The chips are the most expensive part (about $750 each). Motherboard, $300. RAM, case, monitor, HDs, the rest are whatever you get them for.

Personally, we spent $10,000 on one of these, put it had dual 20" LCDs on a Quadra4 GLX, and 3 each of WD 10k RPM and Seagate Barracuda V SATA HDs. And a Midiman 1010LT for sound, because we're snobs. w000000t. Can't wait to try this tech preview on it.

hmm

[Anonymous Coward]

Technology Preview
Sounds ever more like microsoft ..
cudos ;)

Both Platforms on One Media Set?

[Rob Riggs]

What I would like to see Red Hat release is both the 32-bit and 64-bit X86 versions on one media set (DVD-ROM, CD-ROM) and automatically choose the correct platform to install. I don't want to have to manually choose which disk sets to bring along to install/upgrade a system.

There is a non-monetary cost of 64-bit, too.

[morcheeba]

Breaking the 4G of memory does come at a cost, though. If your code uses a whole lot of pointers (many CAD & EDA packages do), then because the pointers take up twice the space they used to, you'll need up to 8G of physical memory to do the same task you could do with 4G on a 32-bit system. And twice the cache, and twice the memory bandwidth, too. It's a pretty steep cost!

Re:There is a non-monetary cost of 64-bit, too.

[g4dget]

Breaking the 4G of memory does come at a cost, though. If your code uses a whole lot of pointers (many CAD & EDA packages do), then because the pointers take up twice the space they used to, you'll need up to 8G of physical memory to do the same task you could do with 4G on a 32-bit system. And twice the cache, and twice the memory bandwidth, too. It's a pretty steep cost!

That may be true for your average, poorly written desktop software, but it is false for well-written scientific or engineering software.

Such software usually uses arrays and indexes that are determined by problem size, as opposed to making everything a pointer. Many such programs may use 8 bit or 16 bit indexes for most of their data. Going to a 64 bit processor often will not affect the memory footprint of such programs significantly.

Re:There is a non-monetary cost of 64-bit, too.

[morcheeba]

Bingo ;) Sorry; I should have pointed out this flip side. I kept quiet becuase it's something our small company can use to competitive advantage. We have a neat code generator and a good code methodogy that lets us support many different memory models with literally a click of a button. Other companies without this might get trapped behind a lot of legacy code.

Hardware reviewers used SuSE

[r6144]

I remember that both Tom's and Ace's reviews of the Opteron used SuSE's distribution, which seems to be released earlier and (if I remember correctly) more near-production-ready.

Binary compatibility?

[r6144]

It just seems that the 64-bit ABI and the 32-bit one are incompatible (really not surprising... even pointer sizes are different).

Anyway, we already have C++ ABI problem, so this one isn't much worse. What's more, hopefully every 64-bit compiled C++ application will have the gcc-3.2 ABI (old gccs don't even support x86-64), so no more C++ problems in the 64-bit world, and as a bonus, companies have finally found some incentive to make the not-very-standards-compliant code compile with newer gcc, so 32-bit versions compiled with gcc-3.2 will hopefully be available sooner.

Re:Binary compatibility?

[captaineo]

Theoretically you could have 32-bit code calling 64-bit libraries, as long as the libraries never return pointers to allocated memory above the 4GB line. But I doubt that's provided for in the ABI. My guess is that app/library combinations must be 64-bit-only or 32-bit-only in order to work.

And yes, amen to the whole C++ ABI thing. My only complaints are that the final solution involves yet another required library, libgcc_s.so, and AFAIK the libstdc++ API is never going to stabilize :(

Basic statement true, but unfair benchmark

[TheOrquithVagrant]

Although I'm definitely not going to question your basic statement of the Itanium being a terrible performer in "day-to-day tasks", compilation is probably a VERY unfair thing to use for benchmarking. Remember that one of the big problems with the EPIC architecture is that the compiler has all responsibility for optimizing the binary code in such a way that the maximum number of instructions can be exectuted in parallel. The process of compilation and optimization is hence probably massively more difficult and CPU-intensive than compilation for most other architectures. A fairer benchmark for compilation efficiency might be to do a cross-compile that produces x86 binaries.

Porting != Innovating

[Anonymous Coward]

It's a port to an architecture that's extremely similar except for the (admittedly significant) change in word size. Porting is not innovating.

Re:Porting != Innovating

[p3d0]

No, there are more differences than that at the kernel level.

Re:Porting != Innovating

[Anonymous Coward]

Porting is not innovating.

Right, it's more like "engineering", something at which Microsoft seems remarkably inept.

The fundamentally better (yes you heard that right) Linux software architecture made the port much easier, I'm sure.

Re:Redhat is dying.

[black mariah]

OH COME ON! It's a joke! Roger is slang for sex, you dolts! Holy hell...

Look what I found in the sources!

[jeeryg_flashaccess]

"..inside sources say it's based on Red Hat 9 plus some updates."

...inside sources also say:

forward 50
right 90
forward 50
right 90
forward 50
right 90
forward 50
right 90

Mmmm Hmmmm.

Re:Look what I found in the sources!

[Mr Thinly Sliced]

My god!

Its built on logo!

(* dramatic music, and scene passing through stars and hyper-universe bridge *)

m/s?

[conway]

299,792,458 m/s...not just a good idea, its the law!

Which universe are you from?
I hope you mean km/s

Re:m/s?

[Anonymous Coward]

3x10^8 m/s

why https? why no certificate

[louzerr]

Maybe I'm the only one with a problem with this, but this is a https site with a bad certificate. Does anyone have this on a http site?

Oui, monsieur

[TheRealRamone]

Je from little vrock!--TRR

Re:Karma can be yours!

[TheRealRamone]

Double sigs are cool --

just don't touch '007007', pronounced "double double oh seven", because i'm patenting and trademarking it ;?} --TRR

Re:On what will it function?

[Netsnipe]

No wonder Junis managed to get DivX working on his C64 in Afghanistan.