Linus Has Harsh Words For Itanium

Anonymous Coward writes "As a follow up to the earlier story "Intel: No Rush to 64-bit Desktop"... In words that Intel are likely to be far from happy with, the Finnish luminary has stuck the boot into Itanium. His responses to some questions on processor architecture are sure to be music to AMD's ears. Linus, in an Inquirer interview concludes: "Code size matters. Price matters. Real world matters. And ia-64... falls flat on its face on ALL of these."" Of course, Linus works for a chip maker ;)

Comments

Itanium 2 is great

[Anonymous Coward]

Itanium 2 is a great architecture. I don't care what Linus says about it. Sure, it is not cheap to buy or to deploy, but speaking strictly from the technological point of view, Itanium2 kicks a$$ in its range.

Re:Itanium 2 is great

[Goalie_Ca]

"but speaking strictly from the technological point of view"
I think that was his point. It's great technically but it sucks in the real world. If its not practical its a shitty architecture IMHO.
I also think the x86-64 is a more viable solution as well.

Re:Itanium 2 is great

[Billly Gates]

"Itanium 2 is a great architecture/....

What the hell are you smoking? I want some.

Every risc archeticture with the exception of the sparc3 performs better. Especially IBM's power4 and the upcomming power5.

Also there is more then speed when comparing architectures. Itanium is a terrible platform to write compilers for. Alot of optimizations which are tradionally done in the chip at runtime itself must be set by compiler options. Not all of it can be done efficiently like this.

Speedwise Alpha is getting old now but still is the fastest chip around untill the power5 comes out this fall. For coding and optimization, Mips is the best cpu around.

Re:Itanium 2 is great

[Anonvmous Coward]

"I don't care what Linus says about it."

Makes ya curious why anyone should care about what he says, duddn't it?

I'd rather hear about what people can do than hear people complain about what they can't do. Why? Because you buy hardware to suit your needs, not suit your needs to your hardware.

Re:Itanium 2 is great

[Anonymous Coward]

What are YOU smoking?

Optimizations done at compile time are far better than optimizations done at runtime. At compile time, more is known about the structure of the program, where the flow of the program will be going, and more time intensive optimizations can be done than ones done in realtime in the cpu.

Itanium is slower right now, but as compilers with optimizations tailored to it come out, it has the potential to kick every RISC processor's ass. The reason for this is that RISC processors are bogged down by doing the optimizations at runtime that Itanium doesn't have to care about. This means the Itanium will have the same or less stalls and more efficient use of the processor.

Go read up on compiler optimizations to see why cutting out the middleman of instruction sets is a good thing.

Re:Itanium 2 is great

[lingqi]

wow, but you know why they call it "power4" and "power5" though.

the damn things have THOUSANDS of pins (like 8000+ on some iterations, iirc?), and drains MASSIVE current - as in, the kind that makes your dual O/C'd athlon look like an LCD clock.

I think IBM's power4/5 chips are as well "unsuitable for real world" as well, but for some different reasons. That's not to say they won't be put into some niice servers though - and that's the point, itanium2 wasn't meant for desktop (for at least a while) anyway, and I think in their world they play some different rules.

Re:Itanium 2 is great

[Waffle Iron]

Optimizations done at compile time are far better than optimizations done at runtime. At compile time, more is known about the structure of the program, where the flow of the program will be going, and more time intensive optimizations can be done than ones done in realtime in the cpu.

As time goes by, computer languages are trending towards more dynamic behavior. This tends to favor things like JIT compiling and linking into already running programs. Fewer people are going to be able to afford the luxury of spending hours to preprocess their code to fit into an extremely static ("explicitly parallel") hardware model. This will be especially true when chip makers treat their rocket science static compilers as a separate profit center.

Not to mention, the CPU is the one that is actually in the position to know what optimization is needed right now based on the currently running data set. Given that there is usually a several year lag between the latest CPU developments and widespread compiler support, I'd go for a CPU that knows how to do its own tricks. (Hasn't the Itanium architecture been nailed down for almost a decade now? And we're still waiting on better compilers for it?)

Re:Itanium 2 is great

[redgren]

They have so many pins because it is not a single cpu. It is an MCM (multi-chip-module). Each Processor "Brick" contains up to 8 CPU cores.

Current draw is around 250-300A for an MCM. Alot? Hell yeah, but your average athlon XP pulls about 35A. 8 x 35 = 280.

So, not so big a difference.

Re:Itanium 2 is great

[Tailhook]

(Hasn't the Itanium architecture been nailed down for almost a decade now? And we're still waiting on better compilers for it?)

That's the key isn't it? Itanium demands breakthroughs in compiler technology. Will this happen?

I dunno.

Re:Itanium 2 is great

[byron150]

Did I read that right???? 35A for Athlon? As in Amps? As in consistent draw? If this was correct then please if you could post a source for your information, otherwise I'll assume you meant milli-amps..... 35A.....wow....just.....wow!!!! I've been living under a rock apparently.

Re:Itanium 2 is great

[cygnusx]

I think IBM's power4/5 chips are as well "unsuitable for real world"

Is it true that Apple plans to use the Power5 of these for their future line of Macs? I asked because quite a few Mac sites have been talking about Power for some time as the messiah that'll finally ensure that they have not just the best, but also the fastest platform on Earth.

But if the chips are as humongous, hot (and undoubtedly expensive) as they seem to be, then how will Apple get them into their machines? Is there a low-power version of Power5 in the works?

Re:Itanium 2 is great

[afidel]

People care what Linus says about CPU architecture for the same reason people care what Carmack says about GPU architecture. In their field there are few people with a better broad knowledge across many platforms. Sure some people working for Intel, IBM, etc will know more about their aproach but Linus knows quite a bit about the realities of implementing real software on multiple real world platforms.

Re:Itanium 2 is great

[scd]

Sure, simple EE knowledge. Power = Voltage * Current. 50-some watts, 1.25V (ok, so they're approximate number, give them +/- 25%). Current follows.

Yes, that's the truth.

Re:Itanium 2 is great

[trezor]

So you believe that a current in the scales of milli-amperes would need massive cooling in order not to catch fire when run on a few volts?

Processors need alot of cooling because they consume alot of power. That should be dead simple. Alot of power != mA

Re:Itanium 2 is great

[hatchet]

Well Itanium2 is far from great. But it's architecture IA-64 has a bright future. It's much better than AMD's x86-64 and in long-run it is also cheaper.
x86-64 has 100% compatibility with IA32 with all extensions.. and even 16bit 286. Yes, you will be able to run shitty 16bit tetris natively on x86-64. But, do we really need this?
Why don't we just use 'software emulation' for older applications? Those applications are designed to run on slower processors. I really don't see a point why would it need to run natively.

Re:Itanium 2 is great

[Anonymous Coward]

That's a very theoretical argument. And in practice, current CPUs like x86 already require that code follow a strict set of rules for maximum performance (think of e.g. cacheline alignment and branch likelihood). So the difference between Itanium and, say, the P4 is not as big as a strictly theoretical argument would have you believe. The _big_ difference of course is that in almost a decade, nobody has managed to build that "ass-kicking" Itanium compiler.

Re:Itanium 2 is great

[riscycdj]

I'm not sure sure that every RISC architecture performs better. I think the 6502 was a RISC processor and I even have an old Acorn computer that uses an ARM processor. It was good for some things but I wouldn't say it was greased lightning. Point being, every is a very strong word. Use with caution.

Re:Itanium 2 is great

[darien]

Just to be trollish for a moment... maybe Linus doesn't like it because MS will have those breakthroughs first?

(Trollish because anyone familiar with Linus' work and character will know that this is extremely unlikely to be a secret factor in Linus' appraisal - plus, of course, there's no particular reason OSS volunteers can't come up with an Itanium-optimised compiler before MS. After all, it doesn't need billions of dollars, just time and commitment.)

Re:Itanium 2 is great

[phel666]

that plus the team that worked on the EV8 will be working to bring out the later Itaniums. 8)

Re:Itanium 2 is great

[Anonymous Coward]

If it's "traditional" to do runtime optimization in the CPU core, how come MIPS CPUs manage to do none at all? What the hell are you smoking? :-) MIPS is a horrible chip to write code on; gcc backends suck ass so you need to write assembler for tight loops, and there you're faced with the blatant terrors of naked pipelines.

This has got to be a troll.

Re:Itanium 2 is great

[johnnyb]

"The reason for this is that RISC processors are bogged down by doing the optimizations at runtime that Itanium doesn't have to care about."

Like what?

An HP research group actually showed that runtime optimizations can be dramatically more efficient than compile-time ones, since they have the data of how the application is actually being used. HP actually found that they got a performance boost by INTERPRETTING MACHINE CODE than just running it on the same hardware raw. Why? It could be altered to match the runtime characteristics, code that was often called together could be moved onto the same page of memory, thus increasing cache hits, etc. Note that all of the machine code was JITed back into machine code, but it was faster because it was based on real-world usage patterns.

Yes, compile-time optimizations are great, but that only encodes the static behavior. The dynamic behavior of an application can only be assessed at runtime. Some compilers can take dynamic performance data and recompile the original code to take advantage of it, but they are rare and don't have all of the features the HP research group showed.

Of course, I believe a lot of this is still in the research stage, but they have actually shown this to be the case.

Re:Itanium 2 is great

[roca]

I'll elaborate. Itanium is statically scheduled, so a "good" compiler has to know in advance the order in which instructions will complete. This is impossible when you're doing random memory accesses some of which will hit in cache but you don't know which ones.

Every other modern CPU can do out-of-order execution so a "good" compiler doesn't have to know exactly the order in which instructions will complete.

That is why there are "good" compilers for most architectures, but not for Itanium.

Re:Itanium 2 is great

[roca]

We've been working on compilers for 40 years. Intel and HP and others have been working on Itanium-ish compilers for 10 years. The "compilers with optimizations tailored to it" are already out, and they're just not good enough.

Re:Itanium 2 is great

[Anonymous Coward]

I'm not the original poster, but..

The itanium compliers need to find parallelism that doesn't manifest itself in regular C/C++ code. Sure the compiler can optimize things, but it does understand your algorithm, nor can it observed how it might execute all its codepaths, the hardware will see real behaviour. As Linus suggests, the architecture is just too clever to be truely practical. Further each Itanium rev is likely to need to change the rules on how instructions can be grouped and how long it takes for a load to complete for the results to be useable OR inforce some rules in HW to stall the execution with NOPs until it is. And again Linus hints, that if you need to apply rules in HW then do them completely and not in some half assed way.

That said, I think Transmeta also has some problems, because they too rely on deriving parallelism from an x86 code stream which might very difficult to acheive and have the code retire things in the correct sequence. In this respect Hyper Threading could be very effective because it allows the processor to obtain a level of parallelism from distinctly different code streams.Transmeta could of coarse implement pseudo HT but how knows. Perhaps Linus?

Re:Itanium 2 is great

[ncc74656]

I think the 6502 was a RISC processor

Nope...it has more or less the same type of instruction set as any other 8-bit processor. If I'm not mistaken, all of the different addressing modes it supports (immediate, absolute, zero-page, indexed, indexed indirect, indirect indexed) aren't something you'd see on a RISC processor. The single 8-bit accumulator and two 8-bit index registers are also too few for RISC...even x86 gives you more registers with which to play. (The ALU also lacks multiplication and division support, but that's not a RISC-vs-CISC determining factor. It's mainly an annoyance if you need to multiply/divide by numbers other than powers of 2.)

(To see what I've done with 6502 assembly language lately, you might want to have a look at this page.)

Re:Itanium 2 is great

[sketerpot]

I've been wondering for a while now, would it be possible for a program to do this interpreting machine code and optimizing at runtime, then spit out the new binary? This would be good for, say, major releases of software like Mozilla (perhaps a bad example since it is mostly written in XUL and JavaScript) or glibc.

Do you know if it's possible/practical, and if there is any software for this sort of thing?

Re:Itanium 2 is great

[dr2chase]

Itanium's problems were visible from the moment the architecture appeared. It is, and was, an architecture that should excel at running Fortran programs, which are much more easily optimized than code written in C, C++, or Java. Compilers written ten years ago should be able to do a decent job compiling Fortran to Itanium with only a modest amount of porting work. Problem is, people aren't just running Fortran on Itanium.

The apparently-dynamic nature of current programs (that is, the intractability of statically analyzing them) has been coming for years. Ten years ago I spent my time studying the inner loops of SPEC benchmarks, and even then the typical inner loop of a C program was the instructions:

compare X with a value
branch out if equal
load indirect through Y to get Y'
load indirect through Y' to get X
branch to top of loop.

If Y (and Y', and Y'', etc) don't address memory in cache, you're hosed. Static prediction algorithms used in some of the first RISC chips (HP-PA, e.g.) work as well as any other on this loop, but you don't know that you're done until you load all the data and compare it. The loop cannot run any faster per iteration than the latency of the memory that happens to hold the data (Cache is King).

Object oriented programming, whether accomplished with an OO-TM programming language, or just a structure full of function pointers, is about the same can of worms (internally, the processor is caching the last location of the indirect branch, so it is not substantially different from prediction of conditional branches).

Re:Itanium 2 is great

[Grishnakh]

plus, of course, there's no particular reason OSS volunteers can't come up with an Itanium-optimised compiler before MS. After all, it doesn't need billions of dollars, just time and commitment.

It also needs people who give a rat's ass about doing it. Compiler work is something that not many people do, especially not OSS volunteers. How many people are working on GCC? And how many of those aren't being paid for it by some company that has an interest in it?

If you have this expertise, why would you bother working on an Itanium compiler when you could be working on something you prefer, like Sparc, AMD Hammer, more optimizations for P4/Athlon, etc.?

I think the only way a decent compiler will be made for Itanium is for Intel to pay a group of engineers to make it, which is what they're doing with their proprietary icc compiler. Of course, this doesn't help gcc any, but Intel doesn't seem to care about that since they still think in the old model of users buying all their software pre-compiled from proprietary vendors, rather than being able to compile their own.

Re:Itanium 2 is great

[Grishnakh]

Hasn't the Itanium architecture been nailed down for almost a decade now? And we're still waiting on better compilers for it?

Yep, the pro-Itanium people are always crying, "you'll see how great Itanium is when good compilers for it come out!". Well, we've been waiting for these mythical super-compilers for years now, and there's no sign of them.

A 6502 processor could easily outperform a P4, if only you could enclose it in a subspace field and run it at faster-than-light speeds, but I'm not holding my breath for this invention to come out any time soon either.

Re:Itanium 2 is great

[jaoswald]

It's not as one-sided as you think. Optimizations at run-time have better access to actual branching frequencies and memory access patterns.

Most often, these "optimizations" take the form of hardware features like caches, pipelining, and speculative and out-of-order execution.

VLIW architectures, in principle, move some of this load to compile-time, which is I guess what you call progress. However, the efficiency of these optimizations depends on architectural details; inevitably, the compiler becomes much more tied to the specific hardware details of the processor. Effectively, some of the execution unit which was previously in hardware is now implemented in the compiler.

How well will Itanium 2-optimized code perform on a future Itanium 3? Or will you have to recompile using yet another new Intel compiler to get the software portion of the execution unit to match your hardware?

Re:Itanium 2 is great

[Agent_Basilisk]

Itanium 2 in benchmarks are faster than any other processor used for the same thing, it even kicks the Power 4's ass! Itanium given time will have software support and better compilers that are more optimized for the Itanium architecture. Intel had many problems getting a working processor and even more trouble trying to get support. Intel backs the Linux community and then we see now that support being thrown out the windows BY the Linux community. does this make sense? Itanium yes, on paper has been around for years, yes there were lots of problems, yes it doesn't run 32-bit code well (remember Intel's first shot at RISC with the P6 processor known as the Pentium Pro? It didn't work with 16-bit code well as there wasn't a consumer OS at the time (Windows 95) that could use only 32-bit code. This chip worked well on 98/NT/2000/XP/ME and Linux/BSD). so the moral of the story is, give it a little time, support it, and it will shine :D . sig, Twat's that all about?

Re:Itanium 2 is great

[dbrutus]

I always wonder why university professors don't take working OSS projects and contribute code to them as class projects. It would be a tremendous improvement in the number of people looking at the code, classes that actually created useful work would have their members able to put something interesting in their resume, and the amount of useful software would increase.

Re:Itanium 2 is great

[Grishnakh]

I wonder the same thing a lot. But the whole open-source thing seems to be lost on professors, even though it's ideally suited for the academic world where peer review is all-important.

I think the things that used to make academia great are now gone from colleges in the US; now they're just places for students to learn some useless facts and buy a degree (instead of learning how to think), and for professors to make money writing proposals and bringing in research dollars from big corporations.

Re:Itanium 2 is great

[John Bayko]

Optimizations done at compile time are far better than optimizations done at runtime.

Er, you're aware that one does not exclude the other?

Compile time optimizations can take more of the program structure into account, so can be really big wins when they're done well. But they can't take into account program behaviour. For example, the compiler can only tell that there's an if statement in the middle of a loop. The CPU can tell that 99% of the time it is false, so it can skip it and only go back if needed (profiling optimizers can do something similar, as can recompilers and translators - like Java HotSpot JVM and the Transmeta CodeMorpher (Linus works on that), which will both stop and optimize if a block of code is executed a lot).

The compiler is also nearly clueless about the structure of the CPU. Although the compiler can assume a CPU has a floating point unit, it has no idea if it has two that can execute in parallel, or how long the pipelines are. Modern CPUs can re-order instructions to match the actual hardware. The hardware can even add registers by "renaming" them - the x86 instruction set has eight general purpose registers, but the CPUs usually have dozens, so if a group of instructions share a register but don't share data, the CPU can give two independent registers the same "name" as far as the instructions are concerned, and execute both groups at the same time.

Yes, a compiler might assign registers more effectively, but only if you knew before hand what CPU was going to be used.

Compilers can group instructions together in such a way that the CPU is more likely to detect the right patterns. In this case, the optimizations are "implied", and a smart CPU will pick up on them and run faster, a dumb CPU won't, but it normally won't hurt performance. This means that you can have both high level, compiler optimizations as well as low level, CPU optimizations that the compiler could not perform.

Re:Itanium 2 is great

[Mikeytsi]

Because then the University can't take the code and sell it at a profit. It's pretty standard practice that all work you do, including new, patentable ideas, are considered "work for hire" and are owned by the school. "Existing project" and "OSS" tends to mean, "we can't exploit this to get money".

Re:Itanium 2 is great

[Cato the Elder]

Hence the best assembly mnemonic ever: eieio
(Enforce In-Order Execution of IO, for PowerPC chips)

But it's still a year away, isn't it?

[More Karma Than God]

Not to mention the fact that most home users won't see a 2X performance boost from 64 bits.

Re:But it's still a year away, isn't it?

[Waffle Iron]

Not to mention the fact that most home users won't see a 2X performance boost from 64 bits.

Most home users are going to see a performance drop from 64 bits. 64-bit code needs 8 bytes to hold every pointer. This will serve to eat up more cache and memory bandwidth, which are already major bottlenecks for any CPU.

Unless you have a program that actually needs to work on more than 2G of data at one time, 64 bits buys you nothing but extra time waiting to move around millions extra of zeroed out upper bytes.

Some people need that much data in memory at once, but the average home user today doesn't. People typically mention video, but if there's one thing that's easy to stream in and out of a smaller memory space, it's multimedia data.

Re:But it's still a year away, isn't it?

[KewlPC]

64-bit code needs 8 bytes to hold every pointer. This will serve to eat up more cache and memory bandwidth, which are already major bottlenecks for any CPU.

The only thing this eats up is cache; because the system has a correspondingly wider data bus, there isn't a hit in memory bandwidth (unless the designers are trying to be cheap bastards and give a 64-bit CPU the same data bus width you'd use for a 32-bit CPU). And most 64-bit CPUs have a lot of cache.

And as for what kind of applications you potentially need several gigabytes worth of memory for, there's scientific processing and the like.

Re:But it's still a year away, isn't it?

[Waffle Iron]

The only thing this eats up is cache; because the system has a correspondingly wider data bus, there isn't a hit in memory bandwidth (unless the designers are trying to be cheap bastards and give a 64-bit CPU the same data bus width you'd use for a 32-bit CPU)

Ever since the 8086/8088 duo, the bus width of a CPU has been decoupled from its word size. For a long time, the external bus width of (non Rambus) 32-bit CPUs has been wider than 32 bits. This works because the memory unit fetches entire cache lines. The CPU designers could be less cheap bastards today and bring out 32-bit CPUs with 256-bit wide busses if they wanted to.

And most 64-bit CPUs have a lot of cache.

You could put a lot of cache in a 32-bit CPU. You could put a small cache in a 64-bit CPU. In fact, the biggest difference between high-end and low-end CPUs is just the size of their caches.

To be fair, the current Itanium has an enormous cache that uses the vast majority of the die size and dicates its price and power consumption. It's logic core really isn't that big. If you embedded an X86 core in all of that cache, you'd get a very fast chip. If you teamed up an Itanium core in a Celeron cache, you'd get Celeron-level performance. 64 bits has little to do with it; you're mostly paying for cache and bandwidth when you buy high end CPUs.

Re:But it's still a year away, isn't it?

[EvilTwinSkippy]

News flash...

The pentium architecture has been loading 64 bits of memory at a time since the PII. They have to because that is the only way the RAM has a chance in hell of keeping up with the processor. Basically they load 2 instructions at once, and have them execute at double the speed of the RAM. (That's also part of why you get such a kick in the pants when you optimize with the -mcpu=i686 flag in gcc.)

Re:But it's still a year away, isn't it?

[KewlPC]

Ever since the 8086/8088 duo, the bus width of a CPU has been decoupled from its word size. For a long time, the external bus width of (non Rambus) 32-bit CPUs has been wider than 32 bits.

I realize this, and at no point did I say that 32-bit CPUs used data buses that were only 32 bits wide. But it only makes sense that the width of the data bus for a 64-bit CPU would be twice that of a 32-bit CPU, whatever that might be (128 bits, 256 bits, you get the point).

You could put a small cache in a 64-bit CPU.
I don't really see the point of that statement. While a huge amount of cache isn't a requirement for 64-bit CPUs per se, I've yet to see a 64-bit CPU that didn't have easily twice as much cache as a 32-bit x86 CPU.

Hell, the 32-bit MIPS R4400PC that powers the SGI Indy sitting next to me has 1 megabyte of L2 cache, and it was made back in something like 1995.

64 bits has little to do with it; you're mostly paying for cache and bandwidth when you buy high end CPUs.

When did I say otherwise? While that's certainly how the majority of the price breaks down, the large cache size isn't why you buy them.

Re:But it's still a year away, isn't it?

[KewlPC]

Hell, the 32-bit MIPS R4400PC

Whoops! That should read: 32-bit MIPS R4400SC. MIPS processors with PC in the name don't even have secondary (L2) cache. I mean, the SC in R4400SC stands for secondary cache; you'd think that I would pay more attention. And seeing how hinv on that machine reports 1 megabyte of secondary cache, I don't see how I could have anything other than a SC processor.

Preview, preview, preview!

Re:But it's still a year away, isn't it?

[psavo]

ever heard of cache lines? if you load a dword from memory, then all it's surrounding gets loaded too.. usually 32-128bytes per line..

Re:But it's still a year away, isn't it?

[hayriye]

No, 32 bits was twice faster than 16 bits, and 64 bits is twice faster than 32 bits. (Quotation from "Practical Handbook of IT Managers")

Re:But it's still a year away, isn't it?

[olethrosdc]

Erm, why would that be? If you are reading 8-bit numbers those would be stored 'packed' into memory, i.e. 8 bytes for each 64-bit word. This is certainly how it is done now that we have 32-bit architectures. Guess what? Each 32-bit word can store 4 bytes.

The pointers, yes, they might be 64-bit each. So what? The machine has a lot of registers, the locally used pointers kept there, not even in the cache. The only case where this might be imoprtant would be when using stuff with a lot of pointers, like linked lists for example. But you also forget one thing:

Unless the system uses up more cycles to read a 64-bit value than to read a 32-bit value there is no point. And do not forget that using absolute addressing (or full range relative adressing) is the *only* case in which you'd need 32 bits for your pointers. I would expect that in most cases you have instructions that are encoded so the entire instruction and relative pointer fit in 64 bits. If not less. (I guess it depends on how pure RISC the design is).

Re:But it's still a year away, isn't it?

[Junks Jerzey]

The only thing this eats up is cache; because the system has a correspondingly wider data bus, there isn't a hit in memory bandwidth (unless the designers are trying to be cheap bastards and give a 64-bit CPU the same data bus width you'd use for a 32-bit CPU).

As stated elsewhere, the Pentium has had a 64-bit bus from the get-go. Jumping to a 128-bit bus is a very expensive decision, especially as you're adding 64 additional pins to the package. Is that worth it across the board for the handful of applications that really need 64-bit pointers? No. Diminishing returns have seriously kicked in.

Re:But it's still a year away, isn't it?

[ncc74656]

The only thing this eats up is cache; because the system has a correspondingly wider data bus, there isn't a hit in memory bandwidth (unless the designers are trying to be cheap bastards and give a 64-bit CPU the same data bus width you'd use for a 32-bit CPU).

ItanicSX, anyone?

Re:But it's still a year away, isn't it?

[Anonymous Coward]

L. O. L.

The "Pentium architecture" is 3 completely separate implementations of the IA32 (32-bit x86) architecture:

- P5 (Pentium, Pentium MMX)
- P6 (PentiumPro, Pentium II, Pentium III)
- P7 (Pentium IV)

Each generation is as different from the others as 386 was from 486. One thing all the "Pentium" implementations share in common (aside from the catchy trademarkable name) is a 64 bit data bus. "i686" = P6, and optimizing for it only gives you a "kick in the pants" on P6 CPUs. It has little or nothing to do with the bus width of the Pentium chips; it's all about instruction selection and scheduling optimized for the particular (P6) implementation. That crap about loading "2 instructions at once" and "double the speed of RAM" is nonsense. You have to remember that all data come into the CPU through the caches, which are loaded 32 or more BYTES at a time from memory -- the wider bus just makes cache fills take fewer bus cycles. Alphas (64-bit) similarly had wide busses (128 or even 256 bit) for faster cache fills.

Obsessive

[snack-a-lot]

Not only does he work for a chip maker, he's like totally obsessed with the i386 architecture. I guess it's what he cut his teeth and and he's going to stick with it. But to think that no-one else has a use for it is very short-sighted.

It'll probably still make it into the kernel, though. I mean, alpha and sun architectures are in there, so ...

Re:Obsessive

[leviramsey]

Seeing as Intel was (still is?) a major backer of Red Hat, I'd imagine that Red Hat's kernel hackers have already ported it and will see to it that support for Itanium makes it into the release kernel.

Re:Obsessive

[petong]

Red Hat already has an ia-64 release that costs like $700.

But you can always download Debian for the ia-64 architecture for free...

--
Libation.com - Fine wine and beer

Re:Obsessive

[dildatron]

Mandrake also has an ia64 port of their distrobution. I just installed it a few weeks ago (version 8.1 I believe).

RedHat does as well, but their installer would lock up at the end of the install every time, with no errors in the install log. I installed Mandrake after I could not get RedHat to install.

This was on a first generation (lion) itanium.

Re:Obsessive

[Pharmboy]

Not only does he work for a chip maker, he's like totally obsessed with the i386 architecture. I guess it's what he cut his teeth and and he's going to stick with it. But to think that no-one else has a use for it is very short-sighted.

He works for a company that doesn't build chips with the i386 architecture. Its emulated in firmwear, "code morphing" is what they call it. Its slightly slower than hardware but its worth the trade for power consumption.

I am betting he has worked with plenty of morph code, creating virtual cpus, subsets of the i386 chip, or different completely. This is akin to designing hardware, in software.

I can't see how him working for Transmeta hurt his understanding of processors. Seems like it would actually enhance his understanding.

Re:Obsessive

[Anonymous Coward]

Don't be so quick to sell him short. Linus is a genius, particularly when it comes to understanding the strengths and weaknesses of microprocessor architecture. When other young men his age were playing "Pac Man", "Asteroids", and "D & D", Linus was finding his dungeons and dragons in the registers and machine code of microprocessors. Linus has worked on them all -- 8 bit, 16 bits, 32, bits, 64 bits, and beyond.

One reason Linux achieved stability years in advance over other "free" operating systems was because Linus took a bottom-up approach to system design. He started with the capabilities of the processor and then worked his way up from there.

The results were magnificent. The June 1992 issue of the German computer journal C't rated Linux as the most stable and crash-proof of all Unix operating systems. This is no shabby feat, considering the Linux's tender age, and formidable competition over which Linux triumphed, such as Irix and Sun OS.

Re:Obsessive

[Alien Being]

"emulated in firmwear"

Too much starch, or a kinky habit?

Re:Obsessive

[Bender_]

I think his reference to code size is quite interesting, considering he works for transmeta. The Crusoe translates the x86 code to its own VLIW code during program execution. Since VLIW architectures use usually very redundant instruction encoding, the code density/size of native crusoe code is most likely abysmal. (Who knows.. its not public) Therefore the Crusoe needs more bandwidth for code fetch than other cpus.

The question is, exactly where does big code size hurt? Disk space ? Certainly not, you can still decompress it during load time. Main Memory? Unlikely, the bigger part of the memory is still data. Instruction fetch Bandwidth and L1 cache clogging ? I guess so.. but thats exactly where the crusoe fails, too. So what about his obsession with code size ?

Re:Obsessive

[EvilTwinSkippy]

And of course, don't forget Gentoo.

The tricky part is building a custom stage-1 bootloader. Gotta love cross-compiling.

Re:Obsessive

[JWSmythe]

It looks like all the big Linux distributions have gotten together to support the IA-64 Linux development.. This was the first hit on search "Linux IA-64" on google.


http://www.linuxia64.org/

Working distributions date back from 03/2000

Straight from their page:

IA-64 Linux Distributions
# Caldera Systems (initial release 8/4/00) Download at ftp.caldera.com/pub/OpenLinux64
# Debian (initial release 8/10/01) Download at www.debian.org/ports/ia64
# Red Hat (initial release 5/17/00) Download at ftp.redhat.com/pub/redhat/ia64
# SuSE (initial release 6/13/00) Download at ftp.suse.com/pub/suse/ia64
# TurboLinux (initial release 3/13/00) Download at www.turbolinux.com/ia64.html

Their short list of representative companies include: Caldera Systems, CERN, Debian, Hewlett Packard, IBM, Intel, Linuxcare, NEC, Red Hat, SGI, SuSE, TurboLinux, and VA Linux Systems.

If you search their site, you'll see a few emails from Linus in their mailing list archives, so he's obviously involved at least to a degree (I couldn't imagine him not being involved). I dare say he's educated in the matter, and would know all the in's and out's of say putting together an OS. :)

I'm sure support will be included eventually.. Well, maybe not.. I know Linux will run on SGI, DEC Alpha, ARM (I'm running Linux on a Compaq iPaq with an ARM CPU), so maybe they'll leave it as a patch and let folks do seperate distributions.

I guess it's all in how widely used a processor is.. Not the average Joe has an SGI, Alpha, or Itanium at their house. (I'll keep quiet about the 150Mhz SGI Indy that we use as a doorstop).

Re:Obsessive

[Weirsbaski]

He works for a company that doesn't build chips with the i386 architecture. Its emulated in firmwear, "code morphing" is what they call it. Its slightly slower than hardware but its worth the trade for power consumption.

I'd put it the other way- Intel and AMD build chips that only know about x86 in one logic block. The x86 instructions are emulated in hardware, a "decoder" is what they call it. It draws more power, but it quite a bit faster than firmware, and it's worth the trade for performance.

Re:Obsessive

[darien]

When other young men his age were playing "Pac Man", "Asteroids", and "D & D", Linus was finding his dungeons and dragons in the registers and machine code of microprocessors.

Jon? Is that you?

AMD

[crumbz]

Was recently considering leaving the CPU business altogether. I wonder if the groundswell of support that is slowly building around their 64-bit CPU has changed their minds? Of course, it appears that they have "bet the house" on the Hammer and barring any disasterous product launch or systemic defects they are positioned well. Damn, if only I had a couple of grand to gamble in the stock market.....

Re:AMD

[Xerithane]

[AMD] Was recently considering leaving the CPU business altogether

Uh.. what? AMD can't leave the CPU business. That would leave them with.. Flash memory. We all know how much revenue that brings in for them.

You have any links to support this claim?

Re:AMD

[Anonvmous Coward]

AMD Was recently considering leaving the CPU business altogether."

Um when was that? The only thing I recall was a Slashdot article with a misleading headline...

Re:AMD

[ryanvm]

Perhaps the reason you don't have any money to gamble on stocks is because you have shitty business sense. ; )

64-bit processors are absolutely unnecessary on the desktop at this time, and Intel knows it. Why the supposedly tech-savvy geek culture of Slashdot can't grapple this is beyond me.

Re:AMD

[Dun Malg]

AMD...Was recently considering leaving the CPU business altogether.

No, that was an false rumor caused by people misunderstanding a quote from AMD's CEO (that Sanders guy? I can never remember his name. I keep thinking "Larry Sanders", but that's not right...). What he said was something like "AMD isn't going to play this silly desktop CPU game anymore". He only meant that AMD wasn't going to play mindless megahertz games with Intel anymore; you know, the constant push to get out a "faster" chip. They weren't quitting the CPU business, they were redefining their goals. I think hew was actually alluding to the x86-64. Not a bad idea, if you ask me-- put your resources into making a better chip rather than trying to squeeze a few more mHz out of their existing CPU designs.

Re:AMD

[exhilaration]

that Sanders guy? I can never remember his name. I keep thinking "Larry Sanders", but that's not right...

Perhaps you're thinking of Colonel Sanders?

Re:AMD

[JebusIsLord]

No they weren't.

AMD recently stated that they were no longer going to try to compete with Intel on even ground. This means they will be moving to high and low end chips AFAICT, as well as embedded memory and such. Lots of people misread that though so don't feel bad.

Re:AMD

[Rui del-Negro]

Less revenue but also a lot less expenses. In fact, I think their flash memory department turned in a profit, but as a whole they lost money - because of the CPU business.

Of course, the CPU business has the potential to generate pretty big profits, so I don't think they'll drop it, even if they have a bad year or two.

RMN
~~~

Re:AMD

[Seeker5528]

"64-bit processors are absolutely unnecessary on the desktop at this time, and Intel knows it. Why the supposedly tech-savvy geek culture of Slashdot can't grapple this is beyond me."

When it is absolutely unnecessary is the perfect time to pit an architecture that gives your existing software a significant performance boost and lets you transition to 64 bit software gradually against an architecture where you have to upgrade all of your software now or face a significant performance penalty.

Later, Seeker

... AND FOR THE RECORD

[YOU ARE SO FIRED!]

This is from the Linux-Kernel mailing list, not an Inquirer interview. Here is the post.

All in one

[Thalias]

Wow, just about everything under one topic. Linux, AMD, and Intel. So by this we are going to have 64-bit processors soon, is that what I'm hearing? Or will this turn out to be like most computer issues and come out a few years from now?

Re:All in one

[gearheadsmp]

Well, you kind of forgot how MS server 2003 doesn't have support for x86-64, but has support for Itanium II. Can't leave MS out of the fray ;)

Re:All in one

[EvilTwinSkippy]

Well, both AMD and Intel had working boxes at the LinuxWorld Expo in New York. That puts the 64 bit revolution, in my guestimation, a year away.

Once it hits the freak show, suits want it like a bad toy.

Linus too Harsh

[enigma32]

Now, we all know that the Itanium isn't everything it's cracked up to be, and I think none of us at are wrong in blaming intel for coming out with a lousy product....

But, isn't one of those situations he mentions in the interview (namely, running a large database server) what this chip is designed to be doing?

As I recall, the IA64 isn't designed for the desktop user... In fact, desktop users probably don't even need 64 processing for a number of years still....

Yet we're attacking Intel for making the chip to fit it's niche?

Perhaps we need to be more fair in the context of the usefulness of the chip, instead of considering it in all contexts and criticizing it based on that?

Re:Linus too Harsh

[TerryMathews]

In fact, desktop users probably don't even need 64 processing for a number of years still....

Desktop users need at least 64 bit memory registers real soon now. DDR memory is fairly cheap ($100/GB in 512MB increments). 32 bit processors top out at 2GB of RAM without resorting to trickery.

Plus, when it comes to processors, technology develops features and then software develops around said features, not vice versa. Once there is a 64 bit desktop processor, software companies will develop 64 bit software.

Heck, using VS .net2 or whatever it will be called, all you might have to do is add an option to your build configuration.

Re:Linus too Harsh

[Dynedain]

As I recall, the IA64 isn't designed for the desktop user... In fact, desktop users probably don't even need 64 processing for a number of years still....

I need more than 4GB RAM (3.5 if I want it stable) for video editing and 3D rendering.

AMD is developing their 64bit chipsets with the desktop market in mind, as well as the server market. Intel has forgone the desktop, which will turn out to be a huge blunder. Especially when its already a determined fact that the 32bit emulation mode on AMDs line slaughters the 32bit mode on the Itanium.

Re:Linus too Harsh

[Amiga Trombone]

But, isn't one of those situations he mentions in the interview (namely, running a large database server) what this chip is designed to be doing?

Sure, but it doesn't really do it significantly better than some of the more common RISC architectures (Sparc, Power, Alpha), and it's a lot more expensive.

As I recall, the IA64 isn't designed for the desktop user... In fact, desktop users probably don't even need 64 processing for a number of years still....

Probably not, but a lot more desktops get sold than high-end servers. If AMD manages to get a toe-hold on the desktop with their 64-bit solution, the chances are a lot better x86-64 will migrate up the food chain than ia64 will migrate down.

Perhaps we need to be more fair in the context of the usefulness of the chip, instead of considering it in all contexts and criticizing it based on that?

Well, that's the point. How useful is it really? What compelling reasons are there for using it in place of a x86-64 on the low end, or something like Power or Sparc on the high-end? All things considered, it really isn't a bad chip. But it is a solution in search of a problem.

Re:Linus too Harsh

[damiam]

32 bit processors top out at 2GB of RAM without resorting to trickery.

Nope - they max out at 4GB. I'm not gonna say no one will ever need more than that, but it's not gonna happen in the near future, at least on the desktop.

Re:Linus too Harsh

[angst_ridden_hipster]

Good God, man, haven't you ever heard of polygon reduction? Bump mapping? Image mapping?

It's hard to believe you *really* need all of that RAM. Then again, I haven't done 3D in years.

When I was a CG guy, we dreamt of bus speeds above 66MHz. We couldn't even imagine having more than 32M RAM. And we thought it was reasonable to wait two days for a 2k image to render...

Re:Linus too Harsh

[be-fan]

Actually, no. All of Intel's non-server chipsets top out at 2GB. The reason is that 4GB isn't possible without PAE thanks to stuff (BIOS, APIC, AGP memory, etc) that have to be mapped at the top end of the 4GB. Since 3GB is a rather weird size for main memory (hard to fill on dual-channel chipsets) 2GB is pretty much the reasonable max. PC2100 DDR (optimal for dual channel P4's) run about $50 for 512MB, or $200 for a GB. That's about what I paid for 64MB for my PII-300, and is quite a reasonable amount to budget for memory in a high end or even mid-range machine.

Re:Linus too Harsh

[angst_ridden_hipster]

Ohboy, that's going to look really harsh when you read it after Slashdot removed my fake HTML tags reading "RANT" and "OLD MAN VOICE" around some of the content.

preview, preview, preview...

Re:Linus too Harsh

[Billly Gates]

You may want to look at sgi. Sun also has 64 bit cad workstations but they have slower sparc processors but it may also fill your needs and they have a bigger marketshare.

SGI has been getting a bad rep recently during suns onslaught but these babies have already been 64 bit for years and have the necessary software. I do not know why slashdotters hate irix. It rocks.

I do not know how mature gcc is for the hammer so Linux and commercial graphics products may be a problem with it at first. Forget about WIndows. How long did it take them to write a 32-bit os after the 386 was released?

I recommend a risc unix box for these 2 reasons not to mention that this is sgi's core market. While AMD and Intel plan to go 64bit both sun and sgi have already been 64bit for a decade and support the large ram you need.

I just bought a sgi on ebay and love it.

Re:Linus too Harsh

[ryanvm]

I need more than 4GB RAM (3.5 if I want it stable) for video editing and 3D rendering.

Guess what - you're an anomaly. And making an inexpensive product that satisfies a 1% niche is just plain foolish. Having a 64-bit processor on the desktop is the technological equivalent of a slapping a big-ass spoiler on your rice-burner. It's pointless.

Intel knows this, and by the time the desktop is ready, you can bet your ass they'll have a decent 64-bit chip waiting. I hate to break it to you, but Intel did not become the world's leading processor company by making poor business decisions. They're probably one of the shrewdest technology corporations in existence.

Re:Linus too Harsh

[Dark Lord Seth]

Nope - they max out at 4GB. I'm not gonna say no one will ever need more than that, but it's not gonna happen in the near future, at least on the desktop.

I remember 1991 and thinking about buying 4mb extra RAM for my 486DX100. Never did it because my current 8mb (or 4, dont remember anymore) was enough to play Quest For Glory 4 & Duke Nukem 3D (if that was on my 486 back then...). Right now I've got 1GB of mem... Back then I didn't even know what a GB even was!

Ironically, QFG4 won't run on this PC. Must be that (n*4)mb extra ram, without a doubt. Shame, was a lovely (though buggy) game :(

Re:Linus too Harsh

[penguinboy]

While the systems can use 4GB of RAM, applications can't have the entire 4GB. RAM must be split into two segments - OS and Apps - usually a 2/2 or 1/3 split.

Re:Linus too Harsh

[MmmmJoel]

I'm still doing fine with my 640k.

I'll pass, thank you.

Re:Linus too Harsh

[tupps]

The thing is there has been so much hype recently about 64bit that people will assume that they need 64bit (of course it will twice as good as 32bit ;-)

Good marketing beats good engineering!

Re:Linus too Harsh

[Dynedain]

I'll take your old guy comments into consideration :)

but fact is, acceptable rendering times have remained constant as technology has gotten better/faster because 3d artists always want to make it more and more real....I'm currently working on a project that is about the same scope, but with a higher level of realism, as the Beauty and the Beast ballroom scene

Re:Linus too Harsh

[Dynedain]

unfortuneately, because I'm in the architecture profession, and have to do quite a bit of graphic work besides 3d/video, I'm stuck w/ 3dsMax on win32

Re:Linus too Harsh

[Dynedain]

guess what? CAD users have been the driving force in high-end workstations for quite a while now....current machines still aren't sufficient enough to do near-photorealistic design in real time....and they won't be for anytime soon. Untill then, this niche market (if I'm an anomoly, why is Autodesk such a huge developer and Microsoft's biggest supporter?) will continue demanding better

Re:Linus too Harsh

[Random Frequency]

the processors are capable of addressing 32bits of data. That doesn't mean that the chipsets have to have enough address lines to satisfy that, it just means that the MMU is capable of doing so.

Re: Linus too Harsh

[Black Parrot]

> The thing is there has been so much hype recently about 64bit that people will assume that they need 64bit (of course it will twice as good as 32bit ;-)

Only your granny would make that mistake. A geek will know that it's 2^32 times as good.

Re:Linus too Harsh

[Random Frequency]

operating kernels split it into non-pageable memory (usually for the kernel), and user-space. The kernel keeps its structures that it needs in this memory. But an operating kernel is completely independant from your application, at least in the sense that user application context + operating kernel providing low-level API to application. If you wrote your own application you could use up all 4GB of ram, you just wouldn't be able to benefit from the commercially/freely availiable operating systems out there.

Re:Linus too Harsh

[bursch-X]

Yep. Who would want to get 64Bit in the first place? That's even less than 640k ;-))))

Re:Linus too Harsh

[benedict]

Most of them do. It's not absolutely required, though --
you could give the kernel its own address space. I think
that OS writers like to leave the kernel resident, though,
because they don't want to pay for all those MMU flushes.

Re:Linus too Harsh

[Fnord]

None of the PowerPCs in Apple machines so far are 64 bit. The PowerPC is, however a branch of the POWER architecture of chips that IBM uses in its RS/6000 and eServer line of high end UNIX servers. Of those chips, the most recent (the Power4) is 64 bit. There are rumors of Apple moving to an IBM made 64 bit chip for the next generation of Macs, as apposed to the ever delayed Motorolla G5.

Re:Linus too Harsh

[ryanvm]

You're an anomaly because you use your computer to do video editing and 3D modeling, not because you use AutoCad.

I've been around AutoCad users for the last 6 years (machine shop and city government), and I've concluded that most people using AutoCad aren't using it anywhere near its potential.

Besides, Windows can barely keep track of 4GB of RAM as it is. I can guarentee you that Windows will be shitting all over itself for the first 18 months after Win64 is released.

Re:Linus too Harsh

[sjames]

But, isn't one of those situations he mentions in the interview (namely, running a large database server) what this chip is designed to be doing?

The thing is, x86-64 would do that just as well, cost less, and be more versatile as well.

What's being attacked is building an expensive chip to fill a small niche when a cheaper chip could fill a larger niche (including the small one).

Re:Linus too Harsh

[MonaLisa]

> Sure, but it doesn't really do it significantly better than
> some of the more common RISC architectures (Sparc, >Power, Alpha), and it's a lot more expensive.

This is bullshit. The Itanium2 slaughters the Ultrasparc 3 by factors of 3-4, and is 25% or so better than POWER4, and is a LOT cheaper than either one of these. You call the Alpha cost effective? It can cost nearly $100K for a loaded dual processor Alpha box, and the dual Itanium2 is still faster for close to an order of magnitude less money. I have 6 Itanium2 machines and more than 30 p690 POWER4 machines at my disposal and develop computationally intensive code on all of the above and more every day. You can buy a 900Mhz Itanium2 workstation for under $5K. The Pentium4 is a better deal at under $2K, but it is about half the performance of the cheapest Itanium2, and you're stuck at 32 bits. Anyone that would buy a high-end workstation will recompile, so emulation mode performance is absolutely meaningless.

Re:Linus too Harsh

[HeghmoH]

Heh, yeah, you're really lucky your reply got modded up. I read the original post and thought you were either a moron or an asshole. :-)

Re:Linus too Harsh

[s-orbital]

Good God, man...
Thou shalt not use Linus' name in vain!

Re:Linus too Harsh

[EvilTwinSkippy]

(In my best geeser voice...)

I remember those good old days. My parent's 386 packerd bell churning away for a week or two to render an image.

Kids have it too easy these days with 3d Studio and Maya. Well back in my day I had to code my scenes in C damnit. We had to write our own graphics drivers, and make interupt calls to listen to the mouse. If we had a mouse dag nabbit. That was back when 3d meant you could draw a wireframe with a Z axis.

Kids these days. They have it so easy. Hitting the internet with their Pentium IV's with a gigabyte of RAM. Hell, my first computer had 128Kb of RAM. It operated at 4.7 Mhz. And we didn't have hard drives back then, we had to keep all of our stuff on floppy disks. We didn't have the internet. If we were lucky we had a bulletin board, at a whopping 4800 baud.

And we were grateful...

Re:Linus too Harsh

[mholt108]

What on earth are you running. You cannot mean the video edit software so I guess you must be referring to 3D rendering. So why not just buy a couple of machines and render farm it. Hell I wouldnt want my 3D renders running on my video edit machine anyway - esp with low hardware costs.

Re:Linus too Harsh

[mholt108]

As opposed to those who come across as morons and assholes???

Re:Linus too Harsh

[Dynedain]

there are a lot more CAD packages out there besides AutoCAD (even though I do use it quite a bit) and 3D modeling of realworld objects for production purposes is included in the CAD descriptor, regardless of what CAD/CAM package you use.

Re:Linus too Harsh

[Dynedain]

I'm primarily running 3DStudio, Combustion, AutoCAD, Macromedia Studio, Photoshop, FormZ, and FileMaker Pro.

And yes, I use all of them on a day to day basis. When you need to render a single still image 24"x36"x150dpi (19.4 million pixels)....renderfarms are out of the question. And when you have to develop photrealistic animations....well, you get the idea

And as for the video, try working on full-HDTV (1920x1080) in raw Targa or Tiff format. Less than 15 seconds of footage and the RAM buffer is filled.

Re:Linus too Harsh

[Jeff DeMaagd]

Sure, but it doesn't really do it significantly better than some of the more common RISC architectures (Sparc, Power, Alpha), and it's a lot more expensive.

Uh, Itanium 2's really aren't _that_ expensive, are they, at least compared to the lot you stated? I thought that an HP I2 workstation could be had for $8000, which isn't too bad for a 64 bit workstation. New Alphas certainly aren't cheap either, I have no idea about the latest Sparcs and Powers.

Re:Linus too Harsh

[Fujisawa Sensei]

Funny that's what DEC said about the Alpha and look where they are today.

Re:Linus too Harsh

[andrewski]

Read: I WANT more than 4GB RAM for video editing and 3D rendering.

Re:Linus too Harsh

[DunbarTheInept]

These days people are doing 3D at higher resolutions than before, so the better technology goes to compensate for that instead of going to reduce the amount of RAM needed.

Re:Linus too Harsh

[DunbarTheInept]

If you are saying it doesn't make BUSINESS sense for intel to cater to a small market like that, it's true. But that's not how you phrased it. You said it makes no sense for this guy to have what he has on his desktop and that's not necessarily true. It just doesn't make business sense to support it when few people have that need (But if this guy is one of that few, it was wrong of you to say his need was pointless. Not to him it isn't.)

Re:Linus too Harsh

[jbolden]

My first computer was a Commodore Pet with 3k of ram and it ran at less than 1 mhz. When the 128K 4.7mhz IBMs came out next to a few high end systems like the Dec Rainbow they were top of the line.

Re:Linus too Harsh

[puetzk]

if you want to allow fast syscalls (trust me, you do) you need to keep the kernel mapped permanently to cheapen the context switch from app to kernel. You also probbly want to separate physical memory (mapped into the kernel space directly) and virtual space, so that you can have swap and mmap'ed files. You also probably need to keep some address space to map I/O devices into, and some for DMA buffers (unless you really want to give up DMA to get that last memory). What with all the memory on modern video cards, mapping them (to say nothing of the AGP window) is pretty huge too.

So, unless you want to rewrite a lot of stuff, and throw performance completely down the toilet, you need most of that 4GB address space for things other than app VM space. The current linux split is 1G/3G (1 gig to map physical ram into the kernel and store kernel data structures), 3G of total app address space into which devices, files, swap, or physical ram pages can get mapped. You can also set linxu up for 2/2 I think (which gives you more physical ram at the expense of what each app can use) or 4G/PAE (which takes the performance hit and separates the app and kernel the apps get all 4G themselves, and the kernel uses PAE to map up to 32G in a separate way). But the performance hit is very significant unless your app uses almost no system calls or I/O (device I/O has to get copied around into lowmem for this case).

Re:Linus too Harsh

[jbolden]

If you are doing HDTV you have got to look at SGI. They have been supporting HDTV for years and they have nice software for it. If you have to do other stuff at work get two boxes. PCs are not ready for HDTV video yet.

Re:Linus too Harsh

[DunbarTheInept]

I hate SGI because of all the stuff NOT related to 3d that they really suck at - like system administration and getting timely updates. To give an example of what I mean they were the last major Unix vendor to finally move off of the old sendmail.conf file format and onto the newer m4 macro-based format, which made it impossible to implement sendmail security bug fixes suggested by net security houses, since they were all couched in terms of the newer sendmail format that didn't work on SGI's. (at the time.) All in all I think SGI really knows its stuff when it comes to 3D, but they should have concentrated on 3D software and hardware for OTHER people's OS'es instead of trying to publish a unix OS themselves and wasting effort on something they weren't as good at. For programming, Irix rocks. For adminning, it's a royal pain. Unfortunately the second is required before you can do the first.

Re:Linus too Harsh

[puetzk]

bingo - you can separate the kernel and give the space back to the app, but it's very significantly slower. Not as bad as swapping, but far too much to make sense as a general trade.

Re:Linus too Harsh

[jbolden]

Actually if you subtract off the cost of the cache Itanium 2's are less expensive than x86s. Intel just doesn't sell low cache configurations.

Re:Linus too Harsh

[jbolden]

I'm a ram fan. On my 386-40 I started with 8m and boosted to 20m. AmiPro, Mathematica, Windows 3.1 a huge cache... actually ran quite well. Of course then came the fire and memory got real expensive so my Pentium-60 only had 16m

Re:Linus too Harsh

[oconnorcjo]

Good marketing beats good engineering!

Maybe most people (most of the time) will not have a need for the advantages of a 64 bit CPU but it could come in handy and even be critical for some select users AND THERE IS NO REAL DOWNSIDE to 64 bit CPU's. Program footprints and cache/memory usage may become higher but computers have bigger and cheaper harddrive/RAM/(L1/L2 caches) that more than compensate for it. Once at 64 bits, there is nobody who could claim a need for MORE but people have found that 32 bits is not always enough. It just makes sense that all future CPU's be 64 bit as a standard and I am disappointed that Intel has draged thier butt for so long (and I mean before Itanium and something more "backward" compatable) and really happy that AMD is filling the gap that Intel ignored.

Re:Linus too Harsh

[scotch]

Sparc chips are also for workstations - which usually fit nicely on desktops. Like on mine.

Re:Linus too Harsh

[CapnFreedom]

But, isn't one of those situations he mentions in the interview (namely, running a large database server) what this chip is designed to be doing?

Sure, but it doesn't really do it significantly better than some of the more common RISC architectures (Sparc, Power, Alpha), and it's a lot more expensive.

Do you have any data to back that up?

According to this press release, the current record for the TPC-Cbenchmark on a 32-way machine is held by an NEC server with Itanium 2's.

Re:Linus too Harsh

[kyrre]

You remember somewhat wrong. Duke Nukem 3D was relased in '96. 3D Realms quotes the date to be January 29th. And 91 is a probably bit early for 486dx -100 to.

Re:Linus too Harsh

[SN74S181]

you can separate the kernel and give the space back to the app

Yeah, you can, but it's a hassle every time the machine insists you take the application floppy out of the drive and put in the DOS disk to reload command.com.

Re:Linus too Harsh

[Dynedain]

no, need

when the system exhausts physical ram and resorts to the page file, rendering time goes through the crapper.....meaning i have to wait longer to continue to the next step....meaning my employer loses money from my downtime.....and it also means that the client must wait longer for urgent results....which again means my employer loses money

I have a friend who loves to extol the difference between need and want....my future audio and server rack-mount system at home is a want, this is a need. Untill architects can design their buildings in real time at photorealistic quality with full detail, they won't be satisified with computing power. And even then they will still want to have still-off goals of full engineering calculations automated with every change.

Re:Linus too Harsh

[Dynedain]

we dont do enough of that kind of work to warrant purchasing an SGI (at least not according to the bean counters)....however, we do do enough of it to wish x86 hardware was further in development than it is

Re:Linus too Harsh

[psamuels]

AND THERE IS NO REAL DOWNSIDE to 64 bit CPU's. Program footprints and cache/memory usage may become higher but computers have bigger and cheaper harddrive/RAM/(L1/L2 caches) that more than compensate for it.

Man, what a load of crock. The downside is that program footprints and cache/memory usage may become higher. The fact that you can spend money and compensate for these things on a 64-bit CPU implies that you could just as well spend that same money and improve performance on your old 32-bit platform. What was your point again?

Your argument sounds a lot like "my SUV isn't any more expensive to operate than your compact, since gas prices have come down".

Certainly, there are ways 64-bit processing can speed things up. Memory access beyond 2 or 4 GB, if needed by your target application, is one such. Certain scientific processing is another. And if you can have a 64-bit platform without paying the code size cost, like you can with the AMD Hammer in 32-bit mode, it's probably a good thing overall. But it's just plain stupid to say that everyone will benefit from 64 bits, or that the 64-bitness somehow comes for free.

Re:Linus too Harsh

[PSUdaemon]

But, isn't one of those situations he mentions in the interview (namely, running a large database server) what this chip is designed to be doing?

He was comparing it to a P4 though, not any 64 bit chips.

Re:Linus too Harsh

[jedrek]

4800 baud? Damn, life in the fast lane.

I remember 300.

Re:Linus too Harsh

[Vulture_]

Which means MOL is going to break horribly. Great.

Re:Linus too Harsh

[awol]

Au contraire, there are a number of reasons why 64bit is a good thing. One in particular is that God created integers and irrational numbers and all the rest is the work of the devil. 64bit means that there are a whole bunch of numbers that we used to have to store as floats (for pure size issues) that we can now store as integers and the math just got much more accurate (and simpler)

Re:Linus too Harsh

[Ryan Amos]

Ugh! I totally know what you mean. I ran an ISP off a bank of O2s we bought from a flopping graphics house, and I eventually ended up just compiling everything myself. You really learn to appreciate Linux and the ilk (which is why I eventually talked the owner into selling the SGIs to buy cheap x86 boxen) when the vendor support for your OS blows.

Re:Linus too Harsh

[Lumpy]

I need more than 4GB RAM (3.5 if I want it stable) for video editing and 3D rendering

Funny... How at work we have several High end AVID editing stations.. the stuff they use to produce movies and big time things($160,000.00 for the cheap one), not the low end DV crap.. and they don't need 4GB of ram. All of them have 1GB of ram and really don't use it. The daughterboards that do the processing and the 3d rendering dont have even 100 meg of ram on them..

You either have the absolute worst video editing system on the planet or you have it so messed up that it needs to be reinstalled.

Editing HDTV format(1024x768) content with 6.1 surround audio AND adding 3d video transitions (not just lame 3d rendering... wrapping live video onto a 3d object something that takes much more processor and ram) NEVER touches the swap space in the AVID's I maintain...

you either have something that the pro's dont use and is super double secret squirrel new or you are horribly mistaken.

Re:Linus too Harsh

[linux11]

The computer industry has come to expect that Morre's law not only applies to processor speed but also to memory. Anotherwords, there has been an a doubling in the amount of memory approx. once every 18-24 months. A home/small office computer in 1979 contain approx. 64K of memory. Now, 24 years later, it is expected between 12 to 16 iterations will have taken place. In reality, the industry is between 13-15 iterations where several workstations come with 512 Megs of RAM upgradable to 1 Gig and Dell is already shipping workstations with up to 1.5 Gig of RAM. While you might argue if anyone needs that much memory, such an arguement should also question if anyone need a 2Ghz or 3Ghz computer. As computer speed increases, the amount of memory also needs to increase otherwise the usefulness of the increase speed will exceed the amount of data available to take advantage of it. The bottom line is that if the data is not available in memory then the additional clock cycles should be considered as nothing more than additional NOOPs.

So, given the current trend of increase in memory on workstations, it would not be surprising if there is demand for workstations to exceed 4GB of memory by 2006. Aside from the ever cludgy PAE work-around, Intel does not seem ready to deliver such a workstation. At the same time, IA64 is not preferable to proven architechures such as SPARC or PPC for large databases and does a poor job in performing as being backward compatible with IA32. Thus, it does not fit well in a niche in the current server enviroment and will not be ready soon enough when the workstation enviroment demands it.

What I find the most interesting that no one seems to be discussing is that MicroSoft seems to be trying to remove their dependence on Intel. MicroSoft already showed that they no longer are dedicated to Intel when they provided support for AMD's 3D-Now. With their push to move from Win32 to .Net IL-code and the purchase of Connectix, they may be positioning themselves for the possiblity of releasing a Windows for PPC. This will provide MS an architechure to build from with a more proven track record than IA64 and without several of the limitations of IA32. At the same time, the purchase of Connectix would allow them to provide legacy compatiblity with IA32 code.

Re:Linus too Harsh

[Duds]

Find sufficiently stupid people and you can convince them it's 2^32 times as good :)

Re:Linus too Harsh

[pmz]

If AMD manages to get a toe-hold on the desktop with their 64-bit solution, the chances are a lot better x86-64 will migrate up the food chain than ia64 will migrate down.

Looking at history, I think this is very true. All the major RISC architectures started out in workstations first. For example, the Sun 4 workstations occurred long before enterprise servers were even concieved. Only within the past several years have the mega-SMP RISC-based UNIX servers been encroaching on mainframe territory. In other words, they started small and let the markets drive them up.

With the Itanium, Intel seems to be trying to take it all in one big bite.

Re:Linus too Harsh

[Chelloveck]

"The finance department has analyzed your computing needs and decided to give you a 286 PC. That should be sufficient for the 3D-rendering you need to do. Besides, how many times are you going to do 3D-rendering in your carrer?"

"Once, if I hurry."

Dilbert, 6/21/95, by way of the comp.graphics.animation FAQ.

Re:Linus too Harsh

[Broodje]

We had a working Telex machine in our basement. My dad helped me build a kit ZX81. It had 1k of memory. It didn't have a cassette to store things so we played "Hunt the Wombat" for a week before turning the computer off. Then we would spend evenings entering in code for "Eliza". On a speak-and-math keyboard. Good times :) -broodje

Re:Linus too Harsh

[Broodje]

Hunt the Wumpus. Damn I shoulda previewed.

Re:Linus too Harsh

[WNight]

No, the point is that you can throw in features that will slow some things down 64bit as long as you're on a general upward curve because the average consumer will buy the machine and it'll still be faster than their last one. Not as fast, perhaps, as if they'd bought a 32bit machine, but fast enough they won't notice.

If gas prices were dropping 25% a year, your compact would always be cheaper to operate than his SUV, but in two years or so, his SUV would be cheaper than your compact is now, and if those were the two points in his budget, his SUV is now as cheap as it needs to be. In other words, that 64bit computer may be 5% slower on most tasks, but as long as the 25% (or whatever) useful speed increase you see per year means that it's fast enough to play Doom3, nobody will notice.

As for how much slower a 64bit machine is, it's debatable. If you do nothing but manipulate 64bit pointers, it might be half the speed. In high-performance code that chews through a lot of data, it's unlikely to be measurable because you're going to set a single pointer and read data linearly for a while. I suspect that except for a few unrealistic benchmarks the difference will be 2% or less.

I wonder, in any given snapshot of L1 or L2 cache, how much consists of pointers?

Re:Linus too Harsh

[PCBman!]

So, what's performance like for an Itanium2 in a 128 CPU machine used for financial computing? Will it match a comparable Sun box? ;-) Remember, Sun's strength isn't what they can do with 1 CPU, it's what they can do with hundreds and thousands of them.

Re:Linus too Harsh

[mOdQuArK!]

I remember 300.

I liked 300. I could read the entrre UUCP newsfeed at that time over a 300 baud modem w/o ever using ^S/^Q (took about 6 hours).

1200 baud was a lot more challenging, but I could barely keep up. Then the newsfeed starting to grow...and grow...

Re:Linus too Harsh

[delus10n0]

Editing HDTV format(1024x768) content with 6.1 surround audio AND adding 3d video transitions (not just lame 3d rendering... wrapping live video onto a 3d object something that takes much more processor and ram) NEVER touches the swap space in the AVID's I maintain

AHAHAHAHAHA I just have to call bullshit on this entire post, I'm sorry. You don't know what you're talking about. Since when is 1024x768 a "HDTV Format" ? As far as I know, the only official standard vertical HDTV resolutions are 480i/p, 720i/p, and 1080i/p.

I'm seriously doubting you have the hi-end AVID setup (which by the way isn't $160k like you said) because we have one here at work (the $15k starter model, no high-def, just DV) that definitely benefited from the 2 gigs of RAM and dual Xeon's we upgraded to last year. The RAM helps when dealing with a lot of video clips, and the dual Xeon's cut our rendering time more than half. Don't believe me on the RAM? Try it yourself. Downgrade your supposed 1 gig of RAM (to perhaps 256 megs?) and see if you're taking a performance hit while editing.

By the way, if you really do have a high-end AVID setup, the fancy 3d wrapping you're talking about is all done in the AVID hardware board itself, it barely (if ever) hits your CPU and RAM. And if you really do have this system, keep in mind that not everyone out there can afford such a beast.

Re:Linus too Harsh

[quigonn]

Well, actually the Itanium 2 (insiders call it "The Itanic") is a good example for a bad CPU. The pipeline is way too long (20 steps), and because of that, the CPU loses 20 % of the performance (since only about 90 % of all jumps/branches are predicted correctly, and one out of ten instructions is a jump/branch instruction). It's getting even worse for games and compilers. The bundle concept also brought a lot of problems, namely code bloat: on such a "microlevel" programs often cannot be parallelized very well, so the empty "slots" in the bundle must be filled with NOPs. This is usually 33 to 66 % of the whole binary code! Imagine, binary code full of NOPs! A good example is the statement

return a=='\r' || a=='\n' || a==' ' || a=='\t';

When generating code with gcc, the IA64 version takes up 128 bytes, while the code generated for x86-64 takes up only 30 bytes. And the gcc produces good code that fills up the bundles in an optimal way!

Re:Linus too Harsh

[Dynedain]

thanks for responding so I didn't have to poke the holes in his argument

and yes, I work for one of those companies that does enough different high-end graphics/animation work to warrant a top-of the line PC workstation, but not enough of any particular kind of video/graphics work to warrant buying specialized hardware components....meaning we don't do enough for screen/film editing to warrant the purchase of an AVID board

Re:Linus too Harsh

[Brendan Byrd]

You don't use SGI machines for non-graphics work. Where are you doing trying to use sendmail or running a frelling ISP on those things? They are Silicon GRAPHICS machines. They do not say Silicon Servers machines.

My old ISP (Aye-Net) uses those damn SGIs for an ISP. Why? I don't know. GRAPHICS GRAPHICS GRAPHICS. They are NOT servers!

Re:Linus too Harsh

[DunbarTheInept]

Try telling that to SGI, who tried selling their machines as servers as well as desktops. One of the side effects of having machings with good graphics ability is that you also produce machines that are good a number crunching in general. The place I am referring to was a biochemistry research facility who used big SGI servers because they crunched numbers fast, and because there was a lot of scientific visualization software for SGI. But even scientists need their e-mail and web services working, and when you have a honking huge SGI in house, you make use of it.

Re:Linus too Harsh

[John Bayko]

You snipped "running a database server" from the original post. Yes, UltraSPARC III is poor for numeric computing, and Power4 is also crippled because the dual-core CPUs share cache. But running databases, the top HP Itanium 2 system just nudges out the top IBM Power4 system (I can't find the reference, sorry - both were 32 CPU systems I think).

Sun declines to participate in those benchmarks because a) officially they don't think they reflect expected workload, or b) they do too badly. On the other hand, the 128 CPU Fujitsu SPARC-64 still beats them both.

The point being, running databases as the original poster was talking about, the Itanium 2 is nothing special.

Re:Linus too Harsh

[be-fan]

The original post argued that once people needed to go past 2GB of RAM, 32-bit processors would be insufficient. The person who replied to him said that the number was 4GB, because a 32-bit processor could address 4GB. I pointed out that it doesn't matter if the processor can address 4GB, because it needs some address space for other devices, which limits the total RAM to 2GB. The point isn't how much the processor can address, because we're talking about RAM limits here. And that RAM limit is (for practical purposes) 2GB.

Re:Linus too Harsh

[bobbozzo]

When you need to render a single still image... renderfarms are out of the question.

I don't know about 3DS, but POVRay can render 1 frame on a many-server farm.

It breaks the image into tiles.

Re:Linus too Harsh

[sbaker]

I do 3D graphics for flight simulation - and just today, we started looking into PC's with more than 2Gb because our next planned system needs at least that. Give it one more generation and 3/4Gb won't be enough.

Think high resolution satellite photography - with half meter per pixel (or less), textures of 1M x 1M resolution are likely. 1M x 1M x (R+G+B) + MIPmaps == 4Gb. You can page from disk and use various compression schemes (in fact, you have to) - but it's a significant challenge with fast moving, low altitude flight and high frame rate realtime 3D rendering and you need a bunch of memory to cache enough data to allow for rapid changes in direction. 4Gb won't be enough main memory to keep up with our customer's needs within a year or so.

64bit CPU's on the desktop are long overdue IMHO. The biggest obstacle will be finally breaking the binary compatibility people have come to expect since the 8088 CPU. Those of us who have Linux and the source code for everything that matters will be in good shape - but for Windoze users, it's not going to be a pretty sight - 32 bit emulation technology will have to be pretty good.

wow

[BigBir3d]

Linus being opinionated and brash? Never!

Re:wow

[pi_rules]

Heh... just wait for Theo to chime in...

Re:wow

[Vulture_]

I was going to comment on that myself. Linus never seems to have harsh words about anything -- not BitMovers (of BitKeeper fame), not Microsoft, not anything.

This will surely go down in the Linux history books.

Re:wow

[scottj]

Theo has already spoken.

Re:Where's the Harsh Words for Transmeta?

[Anonymous Coward]

There's Crusoe products out, available on the consumer market, priced at reasonable points.
They delivered a revolutionary product. It's up to the consumers now to choose to make use of it or not.

How to improve x86

[MBCook]

Now I'm no programming guru, but it seems to me that the x86-64 architecture is a great one. In fact, the only thing that I could see being done to improve it would be to add more general purpose registers. I believe that the new registers are all GP (IIRC), but I think that makeing them ALL GP (even the older ones) would be good, and maybe bring up the number of registers to a good round 32 or something. Am I missing something glaring wrong? If you're going to toss out all of the x86 stuff (like ia-64), I think you should be able to emulate it in hardware about as fast as current x86 processors can. When Apple switched to PPC, couldn't they emulate 68k code about as fast (or at least faster than 1/2 the speed of) the fastest 68k chips?

Re:How to improve x86

[_typo]

but I think that makeing them ALL GP (even the older ones) would be good, and maybe bring up the number of registers to a good round 32 or something. Am I missing something glaring wrong?

Well, the only reason why the other registers aren't GP on x86 is that there are instructions that use them implicitly. If you don't care about these instructions you can use them as regular registers.

As an example the EDI register is used by the SCAS* instructions as a pointer to memory. If you don't care about the instructions that use this register like that you're free to do regular operations on the EDI register, it has no limitations on what you can do with it.

You're right to say that there are few registers though. Before I learned x86 I learned MIPS and there you got all the glory of 28+ GP registers. In the simple examples we did I never needed to push and pop from the stack.

Re:How to improve x86

[PD]

Current x86 processors already emulate the x86 architecture. Converting every x86 instruction into a RISC type instruction takes a lot of effort and transistors. A big reason why Intel would like to switch processors is so they can clean up the mess that evolved out of the old 8086 CPU. They tried it once with the i860 (or was it i960?) and now they are trying it again.

If they emulated the old x86 stuff, they'd lose any advantage of a clean start.

AMD on the other hand, can't afford to make a clean start, so they have to stick with the old x86 instruction set and extend it.

Re:How to improve x86

[VAXman]

Did you read the source for the Inquirier article?

Linus spends a lot of time debunking the "more registers is better" myth. X86 implementations have been addressing this issue for a long time, both by register renaming and by having extremely fast L1 data caches (esp. on P4). Adding more registers will not help speed up code much at all - and anyways requires a recompile and won't help improving legacy code.

Re:How to improve x86

[WetCat]

I don't understand why do we have registers at all right now
Flat memory model where you can do operations
like
mov
add
and a good cache - hoopla! No registers needed!

Re:How to improve x86

[be-fan]

What you're missing is that x86 chips have a ginormous amount of internal rename registers (128 in a P4). The bump to 16 *visible* registers in the Athlon-64 is to allow the compiler optimizer to give more information to the CPU about variable usage. I'm guessing that AMD found that more than 16 visible GPRs really didn't help the compiler's allocation routines any.

Re:How to improve x86

[be-fan]

I was thinking about this ( this thread). The biggest reason I can see for not doing this is access latency. Accessing a cache line requires a lookup operation that takes several clock cycles (7 on a P4's L1 cache). Register access is one clock cycle. If you have a tiny L0 cache, made up of register-like memory, you need to use fully associative memory to make lookups as fast as possible. Fully associative memory is expensive, and would probably be very hard to make run at high clock speeds.

Re:How to improve x86

[WetCat]

May be adding "hint commands" may help
for example
HINTLOCAL
mov L1 L2
add L2 L3 L5
HINTNOLOCAL
mov L5 L4
and all locations between HINTLOCAL and HINTNOLOCAL
commands will be assigned cache index numbers.

Re:How to improve x86

[VAXman]

P4 is 2 cycles not 7, for L1. The L2 is 7.

Re:How to improve x86

[Minna Kirai]

We still need registers, at least to make the opcodes be decently small.

When you do an "add" command, c=a+b, how do we tell the CPU where the 3 arguments come from? From main memory? Somehow store the addresses to 3 different integers (plus the opcode itself) inside a 64 bit op?

Some kind of "register" is needed, just so that the asm code doesn't get bloated up by constantly referencing to distant pieces of RAM.

(Now, one could propose a design with, say, 64K of fast L1 cache, and have all opcodes reference values inside that cache. But in a system like that, you're essentially using 8000 registers! Many more than even RISC chips provide. And Linus says that lots of registers are not really helpful)

Re:How to improve x86

[PeterM from Berkeley]

I attended an information session by someone from AMD at UCB. It was my understanding from his presentation that the tricks they were using to get up to 16 registers without compromising the ability to run existing 32-bit code made it impossible to get past 16 registers.

They would've liked to have 32 registers, but it simply couldn't be done in a backward-compatible way.

If you want more information on this, and more than a guess, AMD has much information up on its website.

Re:How to improve x86

[Penguin Follower]

They tried it once with the i860 (or was it i960?) and now they are trying it again.

I think it was the i860... The i960 is what I have on my scsi-raid card - as it was meant for embeded stuff I believe.

Re:How to improve x86

[WetCat]

Why do you need the opcodes to be decently small?

Re:How to improve x86

[Minna Kirai]

RTA. Linus says:

a rather dense encoding, which means that you win on icache. It's a bit hard to decode, but who cares? Existing chips do well at decoding, and thanks to the icache win they tend to perform better - and they load faster too

Smaller opcodes save space in all levels of storage: network, disk, RAM, and cache. And most importantly, they speed up the movment of code between RAM and the CPU's instruction cache, which makes everything go faster.

Re:How to improve x86

[WetCat]

Ok.
Advantages of flat scheme:
- easy to create compiler
- do not need very tricky register optimizations
- easy to create chip logic
Disadvantages of flat scheme:
- large instruction word.
- Need intelligent cache or hints

Large instruction word is (on my opinion) not a huge disadvantage - now the price of memory is cheap, and if you make bus wider, the speed of loading the code will be the same.
And may be the compilers can gap this disadvantage
by more efficient code (one operation "add" instead of three: load into register, add, save).

Re:How to improve x86

[jbolden]

You are both right. The i860 was a high power vector chip; the idea that was popular at the time was either i860 as a coprocessor. For example you often saw 486/i860 motherboards where technically the whole system wasn't really a microprocesor anymore.

Once it became clear that the i860 was going to be used mainly as a coprocessor Intel was able to strip some stuff out and make i960 which had close to the same coprocessor performance but at a much lower cost.

Re:How to improve x86

[iabervon]

Linus says that all those pushes and pops turn out to be a good thing for x86; it means that Intel puts their effort into cache and memory performance, which are good for other things, too, rather than register file interconnects, which is only good for in-processor stuff. With an efficient cache and a small number of registers, you get really good performance on the few most common variables, and pretty good performance on the top thousand. With 32 registers, you get good performance on the 32 most common variables; you don't get as good performance on the top few, nor on the 33rd, nor do you get as good batch performance going through bunches of memory.

Re:How to improve x86

[psamuels]

Large instruction word is (on my opinion) not a huge disadvantage - now the price of memory is cheap, and if you make bus wider, the speed of loading the code will be the same.

What do the following have in common?

• cache size
• memory bandwidth
• cache associativity
• absolute memory usage

Answer: things that cost real money, and the lack of which will hurt you quite tangibly, after you have doubled the instruction word size. The last perhaps least, but still.

Your "pro" arguments aren't very convincing either:

- easy to create compiler

Not if the compiler wants to conserve memory bandwidth. If you don't want to completely blow your caches and TLB, you'll still have to be careful to cluster your variables appropriately. Maybe you meant: easy to create proof-of-concept, non-optimising compilers.

- do not need very tricky register optimizations

A solved problem - read the article.

- easy to create chip logic

Another solved problem. Any chip real estate you hope to gain would be more than made up by the necessary increases in L1 cache and cache controller logic.

If you really think using memory instead of registers is the way of the future, go read up on the SPARC architecture and "register windows". Not a new idea, and, while clever, not particularly more effective than classic CISC registry + stack designs.

Re:How to improve x86

[Vulture_]

From the Power Macintosh entry in FOLDOC:

Existing 680x0 code (both applications and device drivers) run on Power Macintosh systems without modification via a Motorola 68LC040 emulator. The performance of these unmodified applications is equivalent to a fast 68040-based Macintosh, e.g. a fast Macintosh Quadra.

The conclusion is that the PowerPC (even early ones used in the original PowerMacs) was so much faster than the 68K that the latter could be emulated without any trouble.

Re:How to improve x86

[Vulture_]

One thing large register sets are especially good for, however, is emulation: the PowerPC's 32-odd general-purpose register set is a big part of why Virtual PC is so much faster than Bochs.

Re:How to improve x86

[Anonym0us Cow Herd]

No, the first PPC601's emulated the 68LC040 (SP?) chips, the ones that were used in the performas at that time. Definitely not the same class as the "real" '040 processor.

The emulation was of the instruction set of the 68LC040. They did not emulate the performance. The emulated performance was better than that of a 68LC040.

Let me paint a higher contrast example. I could use a modern fire-breathing Athlon machine to emulate, say a, TRS-80. That is a Z80, 8-bit machine running at about 2 MHz. Now my emulator would emulate the exact Z80 instructions, executing them faithfully. The execution speed, however, would vastly exceed the performance of the old Z80 hardware executing those same instructions.

See my point?

Apple choose to emulate the 68LC040 chip because it had fewer instructions. All known 68000 Mac software would run on it, because that software would check for, and was prepared for the absence of some features, such as a math coprocessor. So a software program would come along and say, "Oh, no fast math coprocessor, I'll just have to make slow calls into Apple's SANE library to do math." Of course, as soon as you called a SANE library routine, it was natively coded in PowerPC and was blazingly fast, and might even use any hardware assistance at the PPC level.

Re:How to improve x86

[David Greene]

This is a short-sighted view. More registers is better, up to a point. More registers generally means fewer instructions, meaning a shorter critical path length and faster execution. More registers also means fewer cache accesses, which can save power and design cost (number of cache ports, etc.).

Hardware register renaming addresses none of these issues. It is there to address the false dependency problem and is useful no matter how large the logical register set is.

Re:How to improve x86

[David Greene]

When you do an "add" command, c=a+b, how do we tell the CPU where the 3 arguments come from? From main memory? Somehow store the addresses to 3 different integers (plus the opcode itself) inside a 64 bit op?

Some kind of "register" is needed, just so that the asm code doesn't get bloated up by constantly referencing to distant pieces of RAM.

A student here did an experiment looking at an instruction set with 1 register: the stack pointer. All instruction operands were 32-bit addresses (or base+offset encoded in 32 bits). It turns out that with simple code compression strategies, even a dumb compiler (i.e. one that doesn't try to minimize stack space usage for temporaries) can produce code that's about the same size or smaller than RISC code.

Re:How to improve x86

[David Greene]

Advantages of flat scheme:
- easy to create compiler
- do not need very tricky register optimizations

This is not an issue at all. Back in the 80's Bell Labs published some papers about the "C Machine" which had a hardware stack cache that replaced the register allocator in the compiler. Good performance was achieved, but this was in the days before register allocation was as well formalized as it is now. It's not really that difficult to write a compiler register allocator these days. Other transformations like instruction scheduling are much more difficult.

- easy to create chip logic

Despite what others have said, this is an issue, though perhaps not the fatal one some make it out to be. Not only is the circuitry complex, but it sucks power and lengthens the pipeline.

Disadvantages of flat scheme:
- large instruction word.
- Need intelligent cache or hints

And may be the compilers can gap this disadvantage by more efficient code (one operation "add" instead of three: load into register, add, save).

Yes, it does help that the instruction count is reduced. But you need something more, like code compression. We're going to start seeing that sort of thing in embedded devices in the not-too-distant future.

Re:How to improve x86

[SmittyTheBold]

It was actually much faster, what killed emulation on the early Power Macintosh was the context switching.

As the OS was slowly converted from 680x0 code to PPC, the real speed advantage was because fewer context siwtches were needed.

VAX is definitely the best

[fozzy(pro)]

The best architecture is still VAX. Clearly string operations at the processor levels is what any procesor needs to be the best and fastest ;}

Re:VAX is definitely the best

[snStarter]

For the expensive memory environment for which it was designed the VAX was fabulous. And it was designed to be scalable as well.

You can snicker at the CISC VAX architecture, but it ran multi-user in less RAM than many processors today have CACHE. Remember 2 MB of RAM was a lot when the 11/780 was introduced. 600 MB drives were considered HUGE and were the size of washing machines.

Its scalable architecture let a copy of VMS from the lowliest processor be physically mounted on the most capable and boot just fine.

It had BCD instructions too, not just string.

But Gorden Bell got a lot more right than he got wrong. And the compact and orthogonal instruction set of the VAX looks pretty good today.

Re:VAX is definitely the best

[SN74S181]

Hell, I ran multiuser with five users on my Altos 586 (not a pentium, it was an 8086 machine that had five terminal ports). It was an 8086 machine with 512K of RAM and (get this) Microsoft Xenix (from before SCO).

Re:VAX is definitely the best

[EvilTwinSkippy]

We hate the damn thing, but a vax from 1986 is STILL running our digital planetarium projector.

And you know, it doesn't do a half bad job. If only someone around here know vax enough to do anything BUT the planetarium shows...

Re:VAX is definitely the best

[hughk]

The VAX architecture did end up being subsetted and some of the string instructions were dumped (to be implemented via emulation, or in-line code generated during compilation). However, block moves stayed.

The main point about the VAX arcitecture is that there was very close liasion between the OS architects and the hardware developers, the result being a secure operating system that worked well with little reources.

Interestingly enough, VMS did get ported to the Alpha, and some of the OS level MACRO-32 assembler code ended up being compiled for the Alpha. Some of the biggest apps still run on OpenVMS Alpha, and I await with trepidation the port to Itanium.

Re:VAX is definitely the best

[warpSpeed]

The best architecture is still VAX. Clearly string operations at the processor levels is what any procesor needs to be the best and fastest

Perhaps we need to embed Perl on this Chip. That would surly get the best performance... "imagine a"... oh never mind

Re:When is the...

[Uart]

probably some time after the AMD chip...

Just a little reminder

[NedTheNerd]

the fact that linus works for a chip maker doesnt really matter because he dosn't develop the chips. he gets paid there to develop the linux kernel.

Re:Just a little reminder

[ActiveSX]

If I remember correctly, he writes the x86 emulator (the 'code morphing' part) that runs on the Crusoe's bare hardware.

Re:Just a little reminder

[NedTheNerd]

didnt he develop mp support for linux because transmeta used them to help develop their chip? have some information to clarify exactly what he does?

the return of "worse is better"

[banky]

Worse is better

although the original essay talks about Unix and the LISP machines, it just keeps being true. Linus talks about the "charming oddities", well there you go: worse is better. Try for perfection, and the real world will eat you alive.

I also think he's right about the masses being what matter; I think Intel is still thinking about the data centre, not Joe Sixpack, with Itanium.

Re:the return of "worse is better"

[On Lawn]

One of my favorite all-time quotes from a flame war was about this topic.

"While they sit in ivory towers, the mongols are multiplying in the hills. Soon, the towers will lay waste and the hordes will have moved on victorious."

Of course he was talking about the ivory tower of PERL, and how the TCL was going to become the dominant force in scripting language. But I've loved the allegory ever since.

--------------------
OnRoad: Becuase hacking funner with a hacksaw.

Re:the return of "worse is better"

[Anonymous Coward]

With each new generation Intel says, "This is for servers, not for desktops." This was true with the 80286 & '386, but they ended-up on desktops. "For servers, not desktops," is an expression of Intel's
wish to get into servers. 64-bits are already on alot
of desktops, but they aren't Intel's chips.

Re:the return of "worse is better"

[ryanvm]

I think Intel is still thinking about the data centre, not Joe Sixpack, with Itanium.

The problem is that Joe Sixpack doesn't need more than 4GB of RAM. Why in the hell should ANY company be trying to get 64-bit processors on the desktop?

It will be AT LEAST 3 years before desktops with more than 4GB of RAM become common.

Re:the return of "worse is better"

[kfg]

Well, I don't think there's any question that worse is always more profitable, and in a profit driven setting will always come out on top.

You can get your product to market faster, and with fewer up front development costs, get a foothold in the market ahead of the competition and then punt.

How do you think Microsoft got where they are? They were always considered the cheaper alternative, although a "toy" OS.

But "real" OS's cost a lot of money. DOS and Windows were cheap and at least got things done, even if they didn't get them done "right."

There's nothing wrong with inventing hammers, but while you're working on it you still use a rock to drive nails, rather than giving up building houses.

(And no, don't ask me where we got the nails from if we don't have hammers, and I guess we use trained beavers to mill and cut the lumber. Look, just leave me alone, it was a *metaphor,* OK?)

KFG

Re:the return of "worse is better"

[BeBoxer]

Of course he was talking about the ivory tower of PERL

PERL is an ivory tower? Wow, that must've been some flame war. Last I checked Perl stood for "Practical Extraction and Report Language", and I'm pretty sure that "Practical" is not a member of the set "Ivory Tower". It's a great quote, I just wouldn't every guess is was about Perl and Tcl. x86 vs. RISC maybe. But not Perl, unless you consider it one of the hordes. :-)

Re:the return of "worse is better"

[Anonymous Coward]

"lay waste" means precisely the opposite of "lie in ruins" -- it means "inflict devastation" / "inflict devastation upon".

The second rendering is because you can use the phrase transitively: "Caesar lay waste the village". (Not lay waste upon or lay waste to.)

I just thought I'd point that out. Your sentence as quoted doesn't make sense.

Re:the return of "worse is better"

[danoaks15]

I think it should be targeted more towards Joe Keg.

Re:the return of "worse is better"

[timeOday]

PERL is an ivory tower? Wow, that must've been some flame war.

Well, it was only in comparison to tcl. Anything looks well-thought-out by comparison. Turns out string rewriting + side effects isn't all it's cracked up to be. I'm usually not a language bigot, but does tcl have ANY redeeming qualities?

Re:the return of "worse is better"

[EvilTwinSkippy]

Well, I'm on the TCL side of the fued.

And for the record, the only way to do graphics in PERL is by using Tcl's TK API. (Same for Python.)

The sign that our world is a truely twisted place: a TCL package exists to load PERL modules, and a PERL module exists that will load TCL.

Open Source at work.

Re:the return of "worse is better"

[EvilTwinSkippy]

I think you hit the nail on the head with that last post.

(BANG BANG BANG BANG)

Re:the return of "worse is better"

[sunking]

Are you sure you want to put that on the "record"? It's wrong. There are numerous GUI libraries for Perl and Python. Tk was first, but is now just one among many. GTk.pm for example.

-sam

Re:the return of "worse is better"

[EvilTwinSkippy]

Gotta remember to put some oregano on my words for when I have to eat them.

Re:the return of "worse is better"

[Fnkmaster]

Geez, some people really take things too literally. If they looked at Perl and said "we can make something worse than this", they are some sick, sick fucks.

Perl IS the "worse is better" language.

Tcl goes so far to the "worse" end, it comes back around the circle at "utterly fucking miserable".

Re:the return of "worse is better"

[DunbarTheInept]

Tcl: redeeming qualities: It had 1 and only 1 - the Tk toolkit. Tcl was the first scripting language to support a GUI on top. That's the ONLY reason it ever became popular, as far as I can tell. Once Tk got ported to more sane scripting languages, the interest in tcl faded.

Re:the return of "worse is better"

[slamb]

And for the record, the only way to do graphics in PERL is by using Tcl's TK API. (Same for Python.)

For the record, you're wrong.

Please look at wxPython and Perl's entire user interface section of CPAN.

Please do the tiniest bit of research before you post. It would have been enough.

Re:the return of "worse is better"

[drinkypoo]

I hope he's more right about itanic than he was about perl.

Re:the return of "worse is better"

[platypus]

I don't know if it's in the article, because I read the original on lklm, and linus writes in one post that he didn't want to say worse is better.
Instead he talked about how some perceived shortcomings of x86 had to be introduced in "better" architectures too.

So, i'd say it's not about "worse is better", but about "what you think is theoretically better isn't better at all when applied in reality".

Re:the return of "worse is better"

[Darren Winsper]

Because starting the transition after you've hit the brick wall is probably not a good idea.

Re:the return of "worse is better"

[jmenezes]

Microsoft can make sure that you'll need more than 4GB pretty soon....

Re:the return of "worse is better"

[Anonym0us Cow Herd]

"For servers, not desktops," is an expression of Intel's wish to get into servers.

No, it's a wish to sell a very high-margin chip.

A classic monopolist trick. Segment your market.

By creating a seperate market segment for one particular line of chip, if that market segment has lots of dollars to spend, then Intel can milk those dollars. Hey, this is a high performance chip, but sold into a limited market willing to pay for high performance, so we can make insanely high margins.

Unfortunantly, some heathens want high performance desktops. Bastards. Wrecking Intel's high-margin aspirations.

Segment the market. That's why we have WinXP Home, WinXP Embedded, WinXP Pro, WinXP Server, WinXP DataCenter, etc.

Red Hat seems to be learning the same trick.

Why is this segmenting the market? Because it's the same basic parts. We offer a "high-end" printer and a "entry-level" printer. The difference? Which pully some belt is attached to. An old IBM trick. The "field upgrade"? Just move which pully the belt is attached to while pretending to be busy.

Re:the return of "worse is better"

[groomed]

Only you can only actually use about 2/3GB using 32 bits.

Re:the return of "worse is better"

[msfodder]

Actually tcl has a very nice event loop,an incredibly introspective interpreter, easily understandable and readable syntax, a very nice set of utility packages, and expect. Personally, I don't think you know enough about tcl to fill a thimble, but are another slashdrone in a frenzy. Prove me wrong. Let's see your miserable tcl code.

Re:the return of "worse is better"

[msfodder]

What exactly don't you like about tcl 8.4?
You don't like an event loop, a vfs, and easy command oriented syntax?
Oh, you were talking 12 years ago and tcl 7.6 right?
Don't get me talking about Perl 12 years ago. What a non-topic that would be huh?

Re:the return of "worse is better"

[msfodder]

When's the last time you coded anything in tcl/tk?
Just curious to see how far out in the shit sea
you are.

Re:the return of "worse is better"

[DunbarTheInept]

6 years ago. I doubt the things that made it suck went away, since they are part of the inherent design philosophy. Like using whitespace as the only separator between terms, and having no syntax more complex than a list of whitespace separated terms. Those things in and of themselves made it terrible. The emphasis seemed to be on making life easier for the parser maker, not the language's users.

Re:the return of "worse is better"

[Fnkmaster]

First, you took seriously a post that was clearly at least partially tongue-in-cheek. Second, you made me a Foe because I don't have the same preference in programming/scripting languages as you. Third, you are resorting to ad hominem attacks and suggesting that I'm a bad programmer without a thimbleful of knowledge about ME.

Either you are trolling, or you are a reactionary idiot. And by the way, I've built several pretty large, complicated AOLserver/Tcl apps, back in the day when this was considered one of the best ways to build a database-backed web application. My experience with it was that I could write perfectly fine Tcl code by myself. Trying to work collaboratively on an application with others was nearly impossible when they kept "upvar"ing all over the place. I'm not going to get into a flame war about Tcl, because it would be a rehash of flamewars that have already been had, and I can't prove or disprove that Tcl is or is not readable - just tell you my qualitative observations about its use in group development projects.

Oh yeah, and I've had this debate with some of the early Ars Digita employees and other old-school hardcore Tcl community members, and even most of them are forced to agree that for most projects, there are better tools for the job. Hell, Ars Digita's entire VERY SUCCESSFUL business model was built around building dynamic web pages using a language that resulted in code nobody else could decipher, so they could lock their customers into expensive support contracts. Once they tried transitioning over to Java (the post Phil Greenspun era) the company tanked - because nobody will pay MIT students and recent grads 100 dollars an hour to write JSPs when they can get somebody in India to do it for 10.

Re:the return of "worse is better"

[msfodder]

A moderated 'five' for what is basically an attack on tcl deserves no less.

I am sorry if you feel there was a personal
attack rather than a deep disgust with your
fairly vulgar sentiment.
I'm not going to discuss a development
experience(ars-digita), or your experience
with older versions of tcl or aol's bastard web/tcl mix

I will talk about upvar though.
If you find yourself losing reference to
variables that are being refernced indis
criminately by the rest of your team, it
is a development problem.
There should be guidelines.
Tcl has plenty of power to avoid this given
that it is treated seriously, and not like a
a shell script.

If you feel that there is a problem with upvar
references: I will agree. I have had a few
problems with it.
There are some clever workarounds: including
a limited loop by level for the name
reference,wrapped with catch, that gets around
bad programming and planning.

There are also namespaces. I don't understand
why they weren't being used to iron out your
difficulties.


In any case congratulations on trashing tcl
publicly and with considerable success.

Re:the return of "worse is better"

[msfodder]

That's what I thought.
Try here: http://www.tcl.tk/software/tcltk/8.4.html
What you think of as limitations allow an
unusual degree of flexibility.

Re:the return of "worse is better"

[dublin]

Tcl has a lot of redeeming qualities, the first that come to mind are:

1) It's not just a language, it's a library, so it's really quite easy to add or extend scripting language support into whatever applicaiton you happen to be writing. This is something that's really not nearly so doable with anything else.

2) I've yet to find anything that gets more done with fewer lines of code. I'm not really very good at Tcl, but there's a good reason many Tcl bigots calim it stands for "Try Coding Less" - the language really does offer awesome leverage.

3) Tk. There's nothing else like it. Sure, you can use Tk with Perl, Python, or something else, but if you're going to carry around the Tcl infrastructure anyway to run your GUI environment, why not just keep things clean and write the app in Tcl, too?

4) A truly excellent set of tools and libraries that recognize the importance of text-based processing to an even greater degree than Perl. Good examples are expect and the /rdb-derived Starbase database that allows fast operation on ASCII formatted dagta tables using the stream/operator paradigm.

Like I said, I'm not even a Tcl bigot - and certainly not an expert Tcl programmer, but the language has some very significant real-world advantages that should not be ignored. Look at it again, and you might form a different opinion.

The only reason Tcl isn't far more popular is that it doesn't have the strident advocacy crowd that both blesses and plagues the Perl community...

Intel is irrelevant anyway

[d00dman]

As much as we depend on intel to push cpu manufacturing techniques to new heights, they have fallen down in the desktop market anyway. Ive lost count on how many new units they've added for poor lowlevel optimizers to keep up with. This with the slap in the face of reduced instructions per tic in the p4 so they could juice up the multiplier and sell "faster"mhz cpu's at double the price is more than enuf for me to stop watching them. Im far more interested in the new power5 coming out of IBM for a 64bit architecture to pay attention to. BTW, what ever happened to alpha 21364? is a 64bit cpu really newsworthy?

Re:Intel is irrelevant anyway

[questionlp]

The 21364 processor, aka EV7/EV79, are out and available in several AlphaServer models:

• AlphaServer ES47
• AlphaServer ES80
• AlphaServer GS1280

On the workstation side, you have the AlphaStation ES47.

Re:Intel is irrelevant anyway

[be-fan]

p4 so they could juice up the multiplier and sell "faster"mhz cpu's at double the price is more than enuf for me to stop watching them.
>>>>>>>>>
Actually, the high multiplier is there because SSE code is extremely regular, and it is pretty easy to keep the system's SSE pipelines filled. The high multiplier (and fast memory bus) allows the P4 to just churn through FP code. Check out the P4's spec FP marks sometime.

Re:Intel is irrelevant anyway

[EvilTwinSkippy]

Back in '98 when I was an EE major, we studied the IA-64 in our computer architecture class. It didn't take long for me to realize that damn thing was going to fly like a brick.

My first model was to try to calculate Easter on assembler. Sure all of that data can sit in a register, with room to spare. The problem is getting the INSTRUCTIONS in and out. Since the damn thing is so superpipelined, you get to drop in one instuction, wait, drop an address to the register, wait, load data into register, wait, ...

I developed my EASTER test after a disasterous presentation where I had to demonstrate a processor architecture I had designed. It worked great for vector math, but it crawled on everything else...

Now if they are hiring dropout EE majors to design their next chip, I'll be happy to give them my resume.

Re:Intel is irrelevant anyway

[phel666]

Only on slashdot could we have a heading like this.

Transmeta and x86-64

[neuroslime]

"It's worth noting that Torvalds' employer, Transmeta, has licensed x86-64 so he is likely to have access to Hammer hardware." This sounds really interesting. Any ideas what it means?

Re:Transmeta and x86-64

[tunah]

Damn, Transmeta should just move here, there are a whole bunch of "Hammer hardware" shops, and now their jingle is stuck in my head...

Re:Transmeta and x86-64

[fitten]

It means that Linus's employer has licensed a technology, so he will obviously badmouth a competing technology.

I mean... with all the folks who constantly stare dreamy-eyed at Linus, anything he says will instantly be aped by his following. What better way for Transmeta to sell their chips than to have such a spokesman?

Re:Transmeta and x86-64

[MShook]

And I think Transmeta wrote an emulator for the x86-64 ISA on their processors thus allowing people to test/debug what would become the Opteron and friends.

Chip Maker

[LongJohnStewartMill]

Of course, Linus works for a chip maker

And if trends continue, it could be Old Dutch.

Re:Chip maker

[KewlPC]

Of course, Linus works in America, where McDonalds makes French fries, not chips.

Re:Chip maker

[SN74S181]

The right wingers are calling them Freedom Fries now to be anti-French.

The French, however, don't hold any claim at all on the food product Americans call the French Fry. I would predict they'd be offended if you called a french fry 'French cuisine'.

It's a somewhat humorous situation.

Of course, Linus works for a chip maker...

[StevenMaurer]

So he is more likely to know what he's talking about.

Personally, I'm getting a bit tired of all the inane cynicism that passes for reflective commentary in modern society. While it's true that the world has its villians, it is more true that people often just hold opinions irrespective of their economic interest. I for one, trust that Linus is among these favored many.

(Not joking this time)

Re:Of course, Linus works for a chip maker...

[MSBob]

Exactly. Especially given that Linus' company is trying to corner the mobile cpu market while the subject of the discussion, the Itanium processor is strictly a server cpu. Those two markets seem as far apart as humanly possible. But what can you do about amateur "new media journalists"?

Re:Of course, Linus works for a chip maker...

[binner1]

I would mod your .sig +1 Insightful!

-Ben

Re:Of course, Linus works for a chip maker...

[glwtta]

Personally, I'm getting a bit tired of all the inane cynicism that passes for reflective commentary in modern society.

Was that an example?

Re:Of course, Linus works for a chip maker...

[evilviper]

I think it is fair to throw in a tag line that points out the particular potential biases someone may have. In fact, it's the only way you can figure out why members of congress REALLY do/say what they do.

In this case, however, I don't think the fact that Linus works for a chip maker would matter. He doesn't work for the competitor (AMD), so I don't think there is any possible financial gain in it for him... that is, unless he is applying for a job at AMD.

Re:Of course, Linus works for a chip maker...

[drinkypoo]

Personally, I'm tired of people who don't realize that cynicism is a good way not to get boned up the ass by someone you thought was your friend, and expect us all to be loving hippie peaceniks.

Now sure, Linus seems to be a great guy, and I'm not saying he isn't, but he still has his slant to things, conscious or not, deliberate or not, malicious or not. So it does pay to keep all things in perspective. He appears to be more benevolent than most, a competent programmer, and a personable individual, but he is also an employee of transmeta, and that affects what he says or doesn't say.

Re:Of course, Linus works for a chip maker...

[CausticWindow]

it is more true that people often just hold opinions irrespective of their economic interest

Have you ever heard of the American Dream? Or were you talking about foreigners? In this case you might be right, but always remember that an americans first and foremost duty is to make the economy grow, at what ever cost.

And please, don't call me 'morally bankrupt' or something like that. Sad metaphors won't do anybody any good.

the benifits of 64bit processors?

[nailchipper]

what will the 'masses' do with a 64-bit processor? the best reason to move up to 64bits is to increase maximum memory, and althought memory is now cheap, its not that cheap!

32bit processors can have up to 4GB of RAM. The most memory i know someone to have is 1GB, and computers most often come with half of that, 512MB. We still have a long way before we hit the 4GB ceiling (a long while!).

I am actually a tad worried for AMD, since they plan on coming out with the x86-64 pretty soon. And i dont know who will actually buy it (or need to buy it).

64bit processors belong where they are most needed, specialized machines.

Re:the benifits of 64bit processors?

[u19925]

i have used several PCs/Sparcs and in all of them, before discarding, I have upgraded memory to 2x to 4x times originally it came with. We don't need more than 4 GB now; but if you were to buy a computer now, you need to make sure that you would be able to upgrade ram to 4x. This means if your need is greater than 1 GB, then 32 bit system is not suitable for you. At present, all my home and work machines (new ones) are ordered with 1 GB. This is at the border of 4x memory expansion possible with 32 bit system. So in a year or so, I will definitely not buy another 32 bit machine.

Re:the benifits of 64bit processors?

[questionlp]

There are 32-bit x86 processors that can handle more than 32-bit memory addressing, the Intel Xeon processors come to mind (which can address up to 36-bits)... the only problem is that the application and OS needs to support windowing or PAE (Physical Address Extension) to allow use of > 4GB of memory.

The only problem with windowing and use of PAE is that there is a long delay (from the processor's point of view) to shift the window compared to accessing something within that window. On the bright side, the delay isn't nowhere as bad as having to go to virtual memory and paging files.

Re:the benifits of 64bit processors?

[gig]

DVD's are 4+GB, hard disks are 100+GB, so why wouldn't you want your CPU to be able to talk to more than 4GB of RAM? 32 to 64 bits is an exciting transition because you go from 4GB of RAM (which is small enough that you could fill it with the contents of one DVD) to an enormous amount that we can't even imagine filling yet.

It's just that the transition to 64-bits seems like more trouble than it's worth if you use Wintel stuff. That's because Intel's 64-bit chips sucks, AMD's is not out yet, and Microsoft is not even UNIX-compatible yet, and certainly isn't stable, even on the IA32 platform. For PowerPC we are just going to slide right into 64-bits and 3D and video and audio and scientific visualization workstations that move ridiculous amounts of data in real-time.

Re:the benifits of 64bit processors?

[silas_moeckel]

Hrm I'm running at least 2 on a workstation (4 512 meg sticks) and as much as I can cram into a server (PIII servers have 1 gig chips cheap enough) Cmon a modern video card has 128 megs of ram on it with the exception of RamBus ram is cheap comparitivly. Run under Linux and Ram can be one of the largest speed ups out there I runn about a 1 gig used memory heap on my workstation and another 2 gigs that ends up beind drive cache for a mid size scsi raid and that cache makes all the difference in the long run.

Re:the benifits of 64bit processors?

[TFloore]

Benefit? That's easy... anyone that owns a digital camera.

Because you'll be buying a new one eventually... and in a couple years, you'll be buying 20megapixel digital cameras for $400. In other words, all your favorite geeks will have one.

And they'll want to edit these pictures on their computers. You wouldn't think that would need so much memory...

But.

Try it with 10 pictures at once, cause you want to see which has the best overall shot of everyone in your group standing in front of your friend that had a cool wipeout skiing.

You make a couple minor changes in 7 of the pictures, adjust color balance, change brightness, red-eye reduction, stuff like that. Your image editing app of course has multiple undo. (Don't they all?)

You copy a few of the images around, shoving them through the clipboard.

4 copies each (multiple undo, remember) of 10 images each at 80MB per image (32-bit color on 20megapixels...) that's... 4x10x80MB = 3.2gig of ram you just used.

Just for editing 10 pictures from your $400 consumer digital camera.

Now do you see why you want a 64-bit cpu that handles more than 3gig of ram for a single process?

(Yes, I purposely assumed that a simple "adjust color balance" requires a complete seperate copy of the image for undo, and it probably doesn't... but you get the point now, don't you?)

Re:the benifits of 64bit processors?

[groomed]

Actually the real ceiling is lower than 4 GB, since not all of the 32 bits can be used for user applications. So the maximum amount of usable RAM is something like 2 or 3 GB. There are extensions (PAE) to go beyond 4 GB to 64 GB (36 bit), but then you lose some flexibility in how the memory can be used (generally applications can use approx. 3 GB _portions_ of the 64 GB), much like "Extended memory" and that stuff. Personally I do lots of audio editing and I recently upgraded my machine to 2 GB. I would love to be able to seamlessly go to 8 GB or even 16 GB on x86...

Itanium is a pain to optimize

[Billly Gates]

This is the problem with gcc and the architecture in general. Its very had to optimize code with it. Even with Intel's compiler optimized code is only marginally faster if any compared to a top of the line pIV. Gcc obviously will perform alot worse then Intel's own compiler and its the only one Linux can compile with.

Sun has an interesting( biased) peace on Itanium. If I were buying a server I would avoid Itanium like the plauge. It is possible that Intel could even cancel the whole project and leave customers high and dry. Not to mention software availability is a problem.

I prefer the risc architecture. I like the idea of keeping things simple and efficient which is alot like structured programming. VLIW does not follow this ethic.

Re:Itanium is a pain to optimize

[HiThere]

More computer power will easily find uses, but there are significant questions as to whether or not the 64 bit chip is the correct way. It probably is, if done right, but I'm not sure that an X86 descendant could do it right. I doubt that we will ever go to 128 bit chips. There are reasons that the 360 series and descendants basically maxed out at 64 bits, and CDC at 60. Addressing is only one of the things that a cpu does.

I would maintain that any high end chip built today should be 64 bits, with an instruction set designed to aid parallel processing with multiple chips. (Bus design, etc., is just as crucial, but that doesn't let out chip design!) Also, the instruction set should make C compilation trivial. Perhaps it could even be turned into an assembler task rather than compilation, except when you wanted to optimize. Consider that this would be enough instructions to contain direct representations of most of glibc and kdelibs. So the question becomes, "How much faster does code execute if it's compiled into CPU instructions?" If it's significanlty faster, then perhaps it should stdlibc, etc. (well, the equivalents) should be built into the CPU as individual op codes. But that's secondary. Opcodes to implement "grid computing" or "Beowulf clusters" or something else similar should be the main focus.

Another thing that the instruction space could be used for is making virtual machines trivial. Most of the jvm, the python virtual machine. and their NET counterpart could be created as instructions. (Or perhaps it could include a native implementation of Parrot? ... that could be fun.) The interpreters, then, would only need to execute the expensive security instructions that aren't needed in secure environments. Memory management built into the assembler level? Why not! (Yes, you would need to be able to disable it...probably.) And although pointer arithmetic might need to be allowed (would it?), pointers could be tracked, and allocated blocks of storage, so that memory leaks/overflows could be prevented.

These are just thoughts off the top of my head, but they would make much better use of the instruction space than many possibilites.

Re:Itanium is a pain to optimize

[tugrul]

Heh, one thing to consider about that Sun piece is that similarly clocked Itanium 2s clobber UltraSparc IIIs by a factor of about 2 on SPEC int/fp.

And servers sporting Itaniums should have all the bandwidth/features/etc the Sun apologists love pointing out that IA32 machines lack.

Sun can't be too happy about that. They can only hope enough customers have critical programs they lost the source to =P

Re:Itanium is a pain to optimize

[MtViewGuy]

While the Itanium looks great on paper, the very fact you have to pretty much kibosh a large fraction of your legacy code (probably most of it!) to take full advantage of the CPU is going to make the CPU a long-term non-starter.

Yes, the Sun UltraSparc III isn't as fast, but at least with the UltraSparc III you can use the large base of legacy code written for the SPARC CPU architecture with little or no modification. The same applies to IBM's POWER architecture--there is a lot of legacy code that works on IBM's 64-bit POWER code base, not to mention the fact IBM has spent massive sums to money to port Linux and IBM mainframe OS'es over and create excellent POWER architecture programming tools. With both Sun and IBM unveiling next-generation SPARC and POWER architecture CPU's later this year, application programmers can use the code available NOW to create new applications that run on the new CPU designs pretty easily.

Re:Itanium is a pain to optimize

[tugrul]

But what if you happen to be a user of one of the architectures that is being terminated for the Itanium? Where are you going to go? Intel & family are probably more than happy to help you move over. If they manage to create enough of a customer base, and maintain their performance margins, its only a matter of time for Sun.

Do you really expect Sun to produce cpu tech that puts Intel to shame?

Re:Itanium is a pain to optimize

[Jordy]

I prefer the risc architecture. I like the idea of keeping things simple and efficient which is alot like structured programming. VLIW does not follow this ethic.

Now wait a second there. Today's "RISC" implementations aren't exactly RISC anymore and are horribly complex (ever look at the modern MIPS?).

The entire point of the RISC revival in the early 80's was moving the complexity of the hardware into the compiler and was a backlash against CISC solutions that were so complex they spanned multiple chips.

The second "RISC" chips implemented superscalar and out-of-order executions was the day pure RISC died. The chips started doing things that the compiler didn't issue instructions for.

It could be said that EPIC is closer to the RISC philosophy than current RISC chips. While you can't control the processor exactly, you can at least hint at branching and caching. The complexity has moved to the compiler, where it belongs (if you subscribe to the RISC philosophy).

Re:Itanium is a pain to optimize

[greenrd]

There is already enough room in a 32-bit instruction word to create millions of opcodes, even allowing for those that have embedded flags, register numbers etc. Moreover, "64-bit" (IIRC) isn't really about the size of the instruction word, but about the flat address space (and other stuff, but the flat address space is the fundamental thing). So that's nothing to do with 64-bit.

At first your idea sounds like a good idea to reduce code size, but probably the reason why it hasn't been done yet is that TANSTAAFL. You need to implement all that libc stuff as either microcode or actual hardware, and the code size improvements don't outweigh the chip real estate, chip design, testing, etc. costs.

Re:Itanium is a pain to optimize

[HiThere]

The questions is: "Is microcode faster?"

Many people have maintained that well implemented microcode executes much faster than the equivalent assembly code. If this is true, then including frequently used routines as op codes would dramatically speed things up. (If not ... well, if not then not.)

OTOH, there are also claims that increasing the microcode op codes increases the transistors needed by the chip. In that case you might get a speed demon that nobody could afford. But in that case, enhancements to parallel processing *really need* to be created as op codes. Currently once you start adding multiple processors, you end up spending most of your CPU cycles just coordinating things. (That's why most architectures limit things to about 8 CPUs.)

A problem, however, is that there isn't yet much agreement on the best way to achieve massive robust parallelism. So choosing the right set of op codes could be quite a gamble. And it's still what needs to be optimized for high end systems. (I think that address spaces larger than 2^64 will always be silly. Address spaces that large will need to be partitioned for other reasons. Better would be to have an on-board cache of, say, 2^16 bytes, local RAM addressing for (2^32 -2^16)B, and shared RAM addressing for anything higher (e.g., RAM on a shared bus). Anything larger than that... well, each CPU has it's own local 2^32 bytes, each local system has it's own 2^64 bytes, and for more ram use IP6 addressing, or it's successor.)

Even that is probably excessive. CPUs should probably deal with only a limited amount of RAM. 2^32 is probably sufficient. The reason that it looks like they need more is that we are focused on uni-processor systems, which is not where things are headed. But there's a bottleneck that needs to be solved before we can really move to parallel systems. The high end systems probably will need to be 64 bit systems, or at least more than 32 bit, but 64 bits is probably the limit. At least, in the past whenever computers started to exceed 64 bit words, some other approach turned out to be better. (You could, of course, use a trick, and address at the word level rather than at the byte level. That would octuple the amount of addressible local ram. But it would probably not be a particularly useful approach. A better choice would be to figure out the character size that would be used (16 bits? 32 bits?) and make that the addressible unit for most instructions. (And have a complete, if not efficient, set of instructions that could address things all the way down to the bit level.)

hmm...

[kennyj449]

Can't say I disagree with Linus's logic, but I don't know if this was that great of a decision politically-speaking. It might not matter, but if anything linux *needs* support from big players like Intel and vice versa in order to grow. This won't necessarily hurt, but I doubt it can help matters on the Intel front.

Re:Where's the Harsh Words for Transmeta?

[Anonymous Coward]

>>They delivered a revolutionary product.

It's not 'revolutionary', if there is no revolution.

People toss this word about like it means 'incremental change'. The Industrial Revolution was a revolution because it entirely changed the way people live and work. How is anything Transmeta done even remotely close to something of this level? It's not.

Take it with a boulder of salt.

[caouchouc]

The Inquirer.com isn't exactly a bastion of responsible reporting.

It doesn't look like an interview took place at all. It looks like they took some choice quotes out of context from the kernel development mailing list to spur some pageviews.

Re:Take it with a boulder of salt.

[questionlp]

As other posts have stated, The Inquirer's report comes from the Linux Kernel mailing list. It's not an interview like the submitter stated, but rather excerpts of messages that Linus posted and responses to his posts.

Re:When is the...

[sweetooth]

If I recall correctly the Crusoe processor is 128bit . It is simply executing 32bit code through "code morphing"

You know it.

[grub]

Netcraft confirms it: Itanium is dying.

One more crippling bombshell hit the already beleagured Itanium community when Slashdot confirmed that Linus thinks Intel dropped the ball with Itanium. Itanium now powers 0.00% or all servers. Coming on the heels of a Netcraft survey which plainly states that Itanium has gained absolutely NO market share. This reenforces what we've known all along: Itanium is collapsing in complete disarray.

You don't need to be a Kreskin to predict Itanium's future. The writing is on the wall: Itanium faces a bleak future, in fact there won't be any future at all because Itanium is dying. Intel has dumped millions into Itanium, red ink flows like a river of blood.

All major surveys show that Itanium has steadily held its ground at 0.00% use while millions of other processors are produced daily. If Itanium is to survive at all it will be among CPU dilettante dabblers and hangers-on. Nothing short of a miracle could save Itaniu, at this point in time. For all practical purposes, Itanium is dead.

Re:You know it.

[MBCook]

What are you, mad man? Last month the Itanium powered 0% of all servers on the internet. This month it powers 0% of all servers on the internet.

0% * 10,000% = 0%

Therefor, the Itanium grew 10,000% last month. The Itanium is a major hit! Get your numbers straight man. Geeze.

:)

Re:You know it.

[stor]

You have a Perl script to autogenerate that I assume?

Cheers
Stor

Re:You know it.

[johny_qst]

So when did netcraft polling of webservers cover all chips in use? Given that the Itanium/Itanium2 architecture is focused toward high-end database and terminal-server use, wouldn't most of those machines be on intranet's where netcraft won't spot them?

Re:You know it.

[Anonymous Coward]

Cool! So if I want to extrapolate back to the growth rate for the previous month, let's see:

0 / 0 = ...

Hmm, looks like I need a new CPU after all. :(

Re:the reason the Itanic is a bomb..

[umofomia]

Trouble is Windows runs on i386 and uh uh uh, it runs on i386 and uh uh uh. Well, it only runs on souped up versions of the 80386, and I'll bet it'll never run on anything else.

Completely untrue. Microsoft has builds of Windows in ia64 and even AMD's 64-bit architecture. They certainly will be released with Windows Server 2003.

This is probably a troll, but...

[tunah]

Slang:

Mickey-mouse == poor quality, inconsistent

Outfit == organization, company.

Code size?

[srichman]

Can someone please explain to me why "code size matters"?

Cost? Memory is cheap. Hard drive space is cheap.

Execution speed? Make your instruction cache bigger. Goes with the territory.

Download time? You'll find that RISC programs are more compressible than their CISC counterparts, so this shouldn't be much of a problem.

So, really, why is code size important? I'm sure there's something I'm missing here, but code size strikes me as something that was a lot more important "back in the day," when memory was more precious.

Re:Code size?

[hpa]

Code size matters because *cache* isn't cheap. Worse, you can't make L1 cache arbitrarily fast without slowing down your chip big time.

Re:Code size?

[Stumbles]

It matters because it means the program will run more efficently, at least thats what I think Linus is getting at. Just because memory may be cheap, CPUs today run hot as an iron and have boatloads of cache. Does not provide an excuse to write crappy bloated code. Code size if not now, should be an important issue.

Re:Code size?

[ChadN]

Number 2 (make cache bigger) is easier said than done, and works against number 1 (cost).

Re:Code size?

[maugt]

Memory is cheap, but the architectures to try and contain all of the memory certainly are not. Try telling your fortune 100 customer that they need to go buy a bigger sun/hp box because you need 80gb of ram to run your application and they start making you reduce memory consumption.

The "memory is cheap" thing is silly, and just encourages people to be lazy and not layout data structures in the optimal way, and/or use efficient data containers.

Re:Code size?

[VAXman]

To quote Linus: "And I further bet that using a native distribution (ie totally ignoring the power and price and bad x86 performance issues), ia-64 will work a lot worse for people simply because the binaries are bigger. That was quite painful on alpha, and ia-64 is even worse - to offset the bigger binaries, you need a faster disk subsystem etc just to not feel slower than a bog-standard PC."

Yeah, RISC workstations always seemed sluggish to me for interactive use. Not sure if it's really due to the increased time to load binaries, or some other optimization issue.

Re:Code size?

[mrm677]

Code size matters because *cache* isn't cheap. Worse, you can't make L1 cache arbitrarily fast without slowing down your chip big time.

This is irrelevant with the trace cache in the Pentium4. Instructions are decoded into micro-ops, by "traces" which are sequences of executed ops, and stored in the cache. Compact x86 CISC instructions are not stored in the trace cache.

Re:Code size?

[pmz]

Yeah, RISC workstations always seemed sluggish to me for interactive use. Not sure if it's really due to the increased time to load binaries, or some other optimization issue.

UNIX is fairly conservative about when it allocates memory relative to Windows. It is intended to allow higher overall throughput of users and applications, but Windows is really a single-user OS that sees a more limited set of applications. The evidence for this is the tricks Windows employs, such as preloading Office files, and the way it sucks up RAM and swap so much for no apparent reason.

The main advantage to UNIX's strategy is that the maximum possible resources will always be available. This is definitely not true with Windows.

Re:the reason the Itanic is a bomb..

[nomadic]

Don't forget the Alpha...

Re:MS

[tunah]

Very good, but you put the punchline in the title!

So what if it's been 7 seconds since I last posted a comment?

Chip maker

[jsse]

Of course, Linus works for a chip maker

I knew it! All dotcomers end up working in Mcdonald.

but the chip is a BARGAIN!

[TheGratefulNet]

look here:

pricewatch

almost $3000 for the chip. wow, and for so many mhz, too...

Re:but the chip is a BARGAIN!

[questionlp]

Two of the processors are in there are Itanium 2 processors, the other two are the first Itanium processors. Still, compare the prices of those processors to say a Sun UltraSparc III 900MHz or the newer 1+ GHz processors (from the Sun Store, a 1.05GHz USIIIcu with 8MB cache lists for just under $7000), or even Alphas, PA-RISCs and POWER4/POWER4+... it doesn't look at bad.

For those who don't need a 64-bit processor but could still use 36-bit addressing and PAE, you have the Xeon MP processors that run around $3700 for a 2GHz processor with 2MB L3 cache.

Re:but the chip is a BARGAIN!

[Best_Username_Ever]

almost $3000 for the chip. wow, and for so many mhz, too...

But mhz doesn't really mean much, just ask Intel :-)

I am *positive* I saw Linus saying on lkml ...

[Maimun]

that alpha and ia64 are the most advanced
architectures. Now tried to find a ref
to that with google, but could not. But
I swear, I saw it once. Maybe a year ago...

Re:Why 64 bit

[grub]

Actually that's a good question. I think chipmakers should slow down a bit and enjoy life. Perhaps meet halfway with a 48 bit chip...

what matters

[1nv4d3r]

Code size matters. Price matters. Real world matters

If only on-chip instruction set morphing mattered...

(sorry, but it's true...he's living in a glass house on this one.)

If Slashdot wanted more ad money...

[Anonvmous Coward]

...all they'd have to do is have a series of Linus editorials about how he hates Intel, Microsoft, *AA, Blizzard, and spam. It's easy money that lotsa ppl will show up to post their .. uh.. thoughtful comments and cycle the ads!

(it's a joke, smile.)

Itanium2 is the fastest floating-point processor

[mrm677]

Check the latest SPEC CPU benchmarks. The Itanium2 has the fastest floating-point score and is no slouch in the integer tests either. It will improve. Linus will eat his words in a few years.

Re:Most home users run Windows.

[Anonvmous Coward]

"Did anybody notice a 2X performance boost moving from Windows 3.1 on 16bit MS-DOS to a nominally 32bit Windows 95 OS?"

I did. There was so much less time in between crashes that I learned to move quickly!

Well, that fud filled anti-MS joke should earn me a Karma point or two.

Re:Why 64 bit

[Billly Gates]

The memory limit is soon approaching and this is a nice thing to have.

Would you really want to return to the dos himem.sys, memmaker, extended and expanded memory, and autoexec.bat hacks again? Sure they were not needed for the first several years of DOS when people had only 512 kb of ram but the situation changed quickly. Its this is what first turned me off from Microsoft. If I had 8 megs of ram and had 6 free why couldn't I run dune2? Do I not have a 32-bit chip? I had to create a custom boot disk with autoexec.bat just to run the game. That is screwed up.

A Hammer is nice just like a 386 was nice to have run 16-bit software. They were particularly usefull in Windows3.11 since it actually had 32-bit disk access while everything else was 16-bit. The hammer is fast at running 32-bit software and is easily upgradable if customers want to add ram. They do not understand techno mumble jumbo. Its not like you can explain the base of 2 math when Joe just wants to purchase a 4 gig ram stick and wonders why Windows wont recognize all the ram.

What he says is true...

[Chordonblue]

So where does that leave Transmeta? Hmmmmm?

Inquirer does not do the post justice

[NullProg]

The read from theinquirer.net is all wrong. The slashdot story line is also wrong. It does not state at all what it implies. Here is the link to what Linus actually wrote:

http://www.ussg.iu.edu/hypermail/linux/kernel/03 02 .2/1909.html

Now, I agree with Linus on the PPC MMU issue. Can anyone tell me what he means by "baroque instruction encoding"? I have been doing x86 and 68k assembler for a long time, I have never heard of this.

Enjoy,

Re:Inquirer does not do the post justice

[wmshub]

Can anyone tell me what he means by "baroque instruction encoding"?

"Baroque" in this case means "overly complicated, usually in a bizarre way." If you ever wrote an x86 assembler or disassembler, you would know exactly what Linus was talking about.

Re:Inquirer does not do the post justice

[privbit]

You've obviously never done any instruction decoding -- it's a colossal mess on x86. In particular, the lack of a uniform instruction length makes for a nightmare whenever one wishes to write software that involves binary rewriting. (Binary rewriting is much easier on any of the RISC architectures.)

And x86 is just _so_ fugly. What else could one call "real" mode? Or "virtual wire" mode? Or segmented paging? Or the TSS? Or conforming code segments? Or ASCII Adjust AX After Multiply? And we haven't even gotten to the real fugliness: the PC architecture. Give me a shotgun and a time machine, and set the dial for Boca Raton, 1980!

Re:Inquirer does not do the post justice

[cant_get_a_good_nick]

I think you think "baroque instruction encoding" is some official term. It's just Linus' explanation for the BS of x86 instructions and how they seem to be laid out. The way the registers are segmented, and (if I remember, it's been years since any x86 assembler) you have upper byte of the lower word, lower byte of the lower word, and the upper word, because it went from a 16 bit chip to a 32 bit chip. 680x0s were 32 bit registers from day 1, just the address bus wasn't 32 bit initially (24 bit only, but 32 bit address registers). Some x86 instructions only can be used on certain registers (because of space and money constraints on implementing them gloabally in the original 8086 days). Anything you can do in D1 on a 680x0, you can do with D5. Anything you can do with A0, you can do with A6, though you probably don't want to do it with A7 (stack pointer). The 680x0 is a very orthogonal chip, with very few special cases. The x86 is riddled with them.

Re:Inquirer does not do the post justice

[leroybrown]

Can anyone tell me what he means by "baroque instruction encoding"?

well, you know what they say: if it ain't baroque, don't fix it.

i am going straight to hell for that one.

Re:Inquirer does not do the post justice

[evilviper]

I feel ashamed for laughing at that one... It's been a long day.

Re:Inquirer does not do the post justice

[NullProg]

If you ever wrote an x86 assembler or disassembler, you would know exactly what Linus was talking about.

Umm, no I don't understand. Linus has never been good at translating his native language into english. Nothing against Linus here.

Yes, I have coded assembler for x86. I started coding assembler for the C6502 in 1981. My first Intel chip started out being the 8086 in 1987. I've written TSR DOS code, and Windows/Linux drivers over the years. I have M68k print drivers with my name on them (proprietary embedded system).

Are we getting into the RISC/CISC wars again?

Explain to me why the "Baroque" is overly complicated? Yes, it seems to me that the x86 instruction set has some overhead. Less than the 68k chip. Is that what Linus meant?

Enjoy,

Re:Inquirer does not do the post justice

[cbiffle]

Probably (IANLT) he's referring to the various prefix encodings and variations for instructions. From my x86 manual, "Machine language instructions...vary in length from 1 to as many as 13 bytes. ...There are over 20,000 variations."

Now, granted, that rather large number probably includes different target registers, but compared to (to use your example) the 68k, the x86's encoding format is just -weird-:
16-Bit:
-An opcode. Either 1 or 2 bytes.
-Some flags and/or target register. 1 byte, optional
-Displacement. 0-2 bytes.
-Immediate. 0-2 bytes.

32-Bit:
-Optional address size prefix byte.
-Optional operand size prefix byte.
-Like above, but with 0-4-byte displacement/immediate and optional scaled index byte.

Now consider the fact that many opcodes implicitly reference registers. Decoding this instruction set by hand would be a royal bitch, and it's exactly the sort of configuration that RISC targeted for demise.
However, Linus makes a good point in the e-mail, which is (paraphrased) that the x86 encoding is basically a very good compression algorithm for its code. While the RISC machines that use 32 or 64-bits for every instruction may be more regular, their code does tend to be larger.

The ironic thing, in my mind, is that the IA-64's encoding is in many ways -more- baroque than the x86s! Instructions in bundles, bundles in groups (or is it the other way around? I never remember), flags at the end to specify how to interpret the instructions before -- it's an interesting take on VLIW, in that it doesn't specify the number of execution units, but YUCK. :-)

Re:Inquirer does not do the post justice

[NullProg]

Thank You. No arguments. Isn't this what slasdot was created for?

Enjoy,

Re:Inquirer does not do the post justice

[NullProg]

You've obviously never done any instruction decoding
Oh, yes I have. My favorite tool at the moment happens to be the watcom dis-assembler and gdb.

Binary rewriting is much easier on any of the RISC architectures.
Yes it is.

And x86 is just _so_ fugly. What else could one call "real" mode? Or "virtual wire" mode? Or segmented paging?
It's how I make my living.I don't enjoy it, it's just how I earn my paycheck.

Re:Inquirer does not do the post justice

[devnull17]

Wasn't that from a Disney movie?

Re:Inquirer does not do the post justice

[privbit]

You've obviously never done any instruction decoding Oh, yes I have. My favorite tool at the moment happens to be the watcom dis-assembler and gdb.

Let me rephrase: you haven't written any code that attempts x86 instruction decoding. I have; it's about 1200 lines of C -- and that's just to get the damn instruction width...

Re:Inquirer does not do the post justice

[Shimbo]

Explain to me why the "Baroque" is overly complicated?

That's not quite got the sense of it spot on. Baroque is really exactly the right word for it though. Baroque is an over ornamented style; wherever there is any space, they would put some decoration in (similar to the later Gothic style).

If you take the ARM architecture (IIRC) there are four conditional flags on each instruction. If you set them to 'never' then the instruction becomes a NOOP. That means the ARM has 2^28 different NOOP's.

The point is that is simple to disassemble ARM instructions. However, the price of this simplicitly is that there are 2^28-1 redundant instructions. So clearly ARM code can be compressed relatively easily; and the cache bandwidth saved might be a bigger win than the decompression time.

The thing is, what you have then looks much more like x86. Harder to decode but no idle bits. We may be getting back to the RISC/CISC argument in that it may be that interpreting CISC codes with a RISC like engine (P4 style) may actually be better than a pure RISC design. As we all well know, Linus is a pragmatist, real world efficiency beats architectural purity.

Re:Inquirer does not do the post justice

[renoX]

Hello,
What is the problem with PPC MMU exactly?

And do you know if the TLB of the PPC is tagged or not?

It is a shame that 80x86 uses non-tagged TLB, doing a cache-flush of the TLB each time you change to a new process must be quite costly..

Re:Inquirer does not do the post justice

[NullProg]

Here is a note from Linus on the subject.
http://www.ussg.iu.edu/hypermail/linux/k ernel/0302 .2/1910.html

Here is a good description of the PPC MMU:
http://www.xilinx.com/ipcenter/processor_cen tral/e mbedded/mmu.htm

It's probably not a problem for the majority of programmers, including myself.

Enjoy,

Re:Inquirer does not do the post justice

[renoX]

I don't see the PPC mentionned in the note from Linus.
And the description of the PPC MMU seems quite normal to me.
A page based MMU common which looks to me the same as any MMU for RISC-style CPU.

Re:Inquirer does not do the post justice

[antifun]

Clever.

But your sig refers to assonance.

Re:Inquirer does not do the post justice

[NullProg]

I'm sorry, I should have posted this link.
http://www.iar.unlp.edu.ar/~fede/revistas/l j/Magaz ines/LJ9/0036.html

Excerpt from an interview with Linus.


LJ: I heard there were two efforts going on for Linux being ported to the PowerPC and the Mac, and that one effort was put on hold because of lack of information from Apple. Do you think the effort is stalled, or do you know if there is still real progress being made?

Linus: I have no idea on the PowerPC port. I have only seen the occasional reports (the latest one indeed saying that they had no knowledge about the IO interfaces). Apple isn't known for disclosing technical information and IBM doesn't seem to have any PowerPC machine out yet (except for the RT which doesn't follow PReP). I don't know what will happen with the PowerPC (with regard to Linux or anything else for that matter). I saw a report about IBM now also considering the Pentium again.

LJ: What is PReP or a PReP machine?

Linus: PReP stands for "PowerPC Reference Platform"--essentially a unified external interface to the PowerPC chip, defining the external bus and the BIOS interface. It's an IBM standard, but even IBM doesn't have any machines out there that follow that standard yet. IBM does have machines with the PowerPC chipset, but those are in their RT line of Unix computers, and have their own bus architecture around the chip (essentially the same one that the POWER series of processors had which were the predecessors of the PowerPC chip).

LJ: Because you know the kernel better than anyone else, how do you feel about the port? Do you think it will be an easy port? Do you think it will run as well on a PowerPC as on the Intel architecture?

Linus: Oh, the PowerPC chip itself shouldn't be the problem. The memory management of the chip is rather strange (and ugly, imho), but that can be considered an extended TLB and the PowerPC port could well use the same memory management architectures, etc., as the current i386 version. The port should obviously run quite quickly on the chip.

The surrounding hardware (and thus the device drivers) will prove to be more problematic unless something comes up (e.g., IBM finally releases a PReP machine and actually gives enough technical documentation on it).

LJ: What is TLB?

Linus: TLB: Translation Lookaside Buffer. It's essentially a small cache inside the processor that caches the page tables, so that the processor doesn't need to look up the virtual-physical mapping in the page tables each time it does a memory access.

The i386 has a TLB with 18 entries (don't quote me on that, but it's something of that order), that it uses to cache the 2-level page tables that define the virtual-memory layout. When a TLB cache miss occurs, the i386 will then (in hardware) look up the virtual mapping in the page tables, and fill in the TLB.

The PowerPC uses a slightly different approach--it won't do a page table lookup when it misses its TLB. Instead, it will look up a new TLB entry from a hash table that has been filled in by the operating system. The operating system can use whatever page table it wants to generate that hash table.

As a final example, let's take the Alpha: it has only a TLB and does any TLB miss lookup in software (the PAL-code). So you can chose your own way of implementing the page tables. (You could do a hash-table plus a physical page table like the PowerPC, or you could go to the page tables directly, like the i386.)

Enjoy,

Re:Inquirer does not do the post justice

[renoX]

Thanks a lot!

Linus is right this MMU seems strange!

Re:Inquirer does not do the post justice

[dublin]

"Baroque" in this context is prety clearly intended to be a perjorative reference to unneeded and unnecessary complexity and ornamentation.

But Linus' transmetaphor is not really the right one, though, because the x86 instruction set isn't merely baroque, but downright rococo, the style in which every possible surface is covered with ornamentation for its own sake.

Is it just me, or is the rococo ennui getting a little deep in here? :-)

In any case, there's a very good reason why everyone that I know that's worked with an Intel white box refers to the chip as "Itanic" - by all reports, it's really pretty much impossible to build good, solid applications with the flaws present in the existing chips and compilers, and even if they worked as designed, it would still be two orders of magnitude more difficult than it has any right to be.

I know two formerly-committed Itanium developers (all with enough pull to get comp'ed white box hardware) who have gone back to SPARC/Solaris for thier 64-bit apps, and two more that are only sticking with it because HP and/or Intel are paying them to complete a crappy port just so they can calim something runs on it...

Re:Obsessive - You've got it wrong

[MBCook]

Linus isn't saying he won't let it in. He's simply saying that the thinks it's not a good arch based on technical merit. He'll let it in. He never said he wouldn't. He's just saying he doesn't like the way the chip was designed (what choices they made, etc).

And Itanium prices are just insane!

[MtViewGuy]

I think the problems with the Itanium boils down to this:

1. The CPU's are insanely expensive. They make the majority of x86-architecture Intel Xeon CPU's look like a bargain.

2. Where are the server applications that take advantage of the Itanium CPU? They're not exactly widely available, to say the least.

3. Programming for Itanium is still a somewhat iffy proposition.

Meanwhile, AMD's Athlon 64/Opteron offers these advantages:

1. The CPU will definitely NOT be insanely expensive to purchase.

2. Programming for the AMD x86-64 architecture is not going to require kiboshing a bunch of legacy programming tools and starting from scratch--it is a straightforward process to convert today's programming tools to take full advanratge of the x86-64 native mode.

3. Because the programming tools are so readily available, both operating systems and applications for the Athlon 64/Opteron will be available widely by the time the new AMD CPU's are finally released for sale. Already, UnitedLinux is porting Linux to run in x86-64 native mode, and Microsoft is very likely readying versions of Windows XP Home/Professional and Windows 2003 Server that will run in x86-64 native mode.

Meanwhile, Intel supposedly has a 64-bit x86-architecture CPU codenamed Yamhill that has developed. However, given we don't know how Yamhill implements 64-bit x86 instructions Intel will have to do some VERY serious convincing to Linux kernel programmers and to Microsoft to write Yamhill-native code--and Intel is far behind the AMD efforts.

Re:And Itanium prices are just insane!

[MBCook]

Wasn't Yamhill supposed to be Intel's back-burner x86-64 project? Personally, it looks a little like Intel is betting the farm (at least pride wise) on their ia-64. The thread makes a good point that the x86-64 is much more likely to seep up into high end servers from low end servers and desktops than ia-64 is to drip down to low end servers and desktops. Intel might yet have to "give up" and go x86-64 to stay compeditive in the desktop/server CPU market.

Re:And Itanium prices are just insane!

[antiprime]

The same things happened when the pentium was introduced.

1. they were expensive

2. there was no software that took advantage of new pentium-specific instructions

3. there was a dearth of pentium dev tools

Meanwhile, the 486 seemed to meet everyone's needs. When pentiums were running at 90 MHz, companies offered cheap, souped up 486 chips running at 120+, for years after the pentium was introduced.

Also, there seems to be some confusion about address space and RAM. Having a 32 bit address doesn't just limit you to 4GB of RAM (without bending over backwards). There are reasons why you want your address to be larger than the amount of RAM you plan to support. Basically, a program might want to say to the operating system: when I ask for the information in this range of 'memory' addresses, what I really want is the information in this range of this file on disk. It's a little difficult to explain why this is a good thing, unless you're a programmer and already know why. It just is.

Re:And Itanium prices are just insane!

[MtViewGuy]

I have to disagree with your assessment about the Pentium CPU at the time it was introduced.

Remember, the Pentium CPU runs x86 architecture code natively, so it did not require an expensive starting-from-scratch mentality to take fully advantage of the CPU like you have to do with the Itanium CPU. In short, programs that ran on the 80486 CPU could run on the Pentium CPU with no modifications.

Re:And Itanium prices are just insane!

[RzUpAnmsCwrds]

Opteron will more likely be closer to the prices of Athlon MP - higher, but still sub $1000.

Re:And Itanium prices are just insane!

[sjames]

Pentium was nowhere near as expensive (Itanium is around $10K). Pentium could run your existing '486 code faster than your '486 without recompiling. Treating a pentium as a 'turbo' 486 was reasonable enough.

The many various souped up '486s could just barely keep up with the pentium. They were only worth considering if you JUST bought a 486 MB and needed a speed boost on a budget. Most preferred to get the pentium board and have room for a CPU upgrade later (ahh the days when a motherboard could support more than 6 months worth of CPU upgrades).

I can think of many good uses for a nice large address space. For 10 grand, I have a hard time cost justifying most of them. If AMD can come in for 5 or less next quarter, SOLD! Intel could make the sale as well, but they show no evidence that they're trying.

Re:And Itanium prices are just insane!

[marm]

Pentium could run your existing '486 code faster than your '486 without recompiling.

Not significantly faster. The Pentium required compiler support to keep its two integer pipelines filled. Without that support it really wasn't any faster than a 486 - the integer pipelines were all but identical to the one on the 486. The Pentium had a faster external bus and more L1 cache, but the 486 had higher clockspeeds.

It was a bit of a disappointment really - at launch the 486DX4-75 kept up with the 66MHz Pentium, the 486DX4-100 spanked it, and the 486s were cheaper. Then the compiler support came, and the Pentiums started shifting.

Then they did it again with the PPro, which ran old 16-bit code much slower than the Pentium, although it was crazyfast for everything else (and still, IMHO, Intel's nicest CPU).

Then they did it again with the P4, which runs x87 FP code way slower than the P3 or Athlon and had to wait for compilers to generate SSE2 code before showing its potential.

Intel has a history of doing this, and I fully expect things to get better for the Itanium once compiler support improves. The situation is, in all sorts of ways, similar to how things were when the PPro came out - the CPU doesn't run old code well, it's power hungry, very expensive, marketed as a server CPU but still not selling. The PPro was also the last really major design departure before the Itanium.

The difference is that when the PPro came out, Intel didn't have AMD threatening to walk off with the technology leadership. While Intel was turning the unfashionable PPro into the very fashionable PII, AMD was still selling unimpressive 486s and K5s and was in the process of buying NexGen for the 6x86/K6. This time AMD has a whole lot more to bring to the table.

Re:And Itanium prices are just insane!

[jbolden]

Pentium 90's outperformed 486-120s by a long shot. The Pentium was 2x as fast as the 486 (and that was running 386 code, running Pentium optomized code it was even faster). They also weren't all that expensive. When Intel first introduced the 60,66,75 lineup the 66s and 60s were not that expensive but the 75s were; same as today you pay a huge premium for the fastest chip. I think I paid a little over $2k for a Pentium 60 600mb hd 16 megs of ram (ram was really expensive because of the fire otherwise I would have gotten more).... from IBM (their Ambra line).

Re:And Itanium prices are just insane!

[SN74S181]

1. The CPU's are insanely expensive.

I have a box of 8087, 80287, and 80387 chips in my collection of old parts.

They were all insanely expensive at one time.

Every chip is insanely expensive when it first comes out.

1. the chip comes out
2. some people use it
3. the price drops some
4. some more people use it
5. goto 3

(Yeah, I know. grep 'goto' in the Linux kernal source tree sometime....)

Re:And Itanium prices are just insane!

[0x0d0a]

However, given we don't know how Yamhill implements 64-bit x86 instructions Intel will have to do some VERY serious convincing to Linux kernel programmers and to Microsoft to write Yamhill-native code

There's very little asm in the Linux kernel, and I suspect the same holds true for the NT kernel. The largest problem is porting the compiler.

Re:And Itanium prices are just insane!

[MtViewGuy]

However, have you seen the pricing for Itanium CPU's? They run into several thousand dollars just for one CPU depending on model.

It makes even the Pentium 4 3.06 GHz part look like a downright bargain in comparison.

Small wonder why both Sun and Linus Torvalds have dismissed this chip.

Re:And Itanium prices are just insane!

[jweatherley]

(Yeah, I know. grep 'goto' in the Linux kernal source tree sometime....)

1. the chip comes out
2. some people use it
3. the price drops some
4. some more people use it
5. goto 3

I see the problem with 'goto':

6. ???
7. Profit!!! // Never reach this line :(

Re:And Itanium prices are just insane!

[Yankovic]

Well, I'm not sure if you've heard of them, but Windows Server 2003 and SQL Server are available for Itanium. And they run the second fastest database machine ever, for the lowest price per TPC benchmark (adding up to literally millions of dollars of savings)

http://tpc.org/tpcc/results/tpcc_perf_results.as p? resulttype=noncluster

Re:And Itanium prices are just insane!

[oldsk8r]

IA64 systems are not actually that bad when compared to Xeon boxes. One of my Xeon boxes (2x2.4Ghz 4GB ram, raid 5) cost about 20000USD, one of my top end IA64 boxes (4x800Mhz, 8GB ram, raid 5) cost about 30000USD. While the Xeon is bay far the fastest of the two when doing one task it just doesn't cut it when loaded. The IA64 scales up well and is just what is needed for the memory hungry image serving that I use it for. Of course, if Intel put the same memory bus stuff in the Xeon it might be a different story.

Re:And Itanium prices are just insane!

[sjames]

I was there when it all happened. The problem with DX4 etc was that the memory bandwidth wasn't scaled up, just the core.

There was some cutting edge price penelty, but that fell off fairly quickly.

PPRO OTOH did suffer all of those problems. Really, it never did take off, it just got quietly swept under the rug by PII. Of course, Itanic is already on rev 2 and still isn't flying.

I do think Intel may have a problem with AMD here. They're betting that only big databases want 64 bit, many other users are saying 'Oh yeah?!!". AMD is listening.

Re:And Itanium prices are just insane!

[_fuzz_]

Intel will have to do some VERY serious convincing to Linux kernel programmers and to Microsoft to write Yamhill-native code

Ya, just like all the other chip manufacturers had to convince Linux kernel developers to port Linux to their architecture. What? People did it on their own without IBM, DEC, Intel, AMD, Sun, etc. breathing down their necks? Why would anyone port to a new architecture unless the maker of that architecture was pressuring them to do so? Oh right, because most of GNU/Linux is written by hobbiests who do stuff because it's fun.

Re:And Itanium prices are just insane!

[_fuzz_]

hobbiests [sic] were able to port software to those other systems because ancient boxes were available at affordable prices or sitting unused at schools. Where can hobbyists get cheap Itanium boxes now?

The original poster suggested that Intel would have to lobby hobbyist kernel developers to port Linux to their desktop 64-bit solution, not the Itanium for which a port already exists. The desktop solution will almost certainly be just as affordable as high-end workstations are today and hobbyists will do the port on their own.

Re:And Itanium prices are just insane!

[RzUpAnmsCwrds]

Ok, that proves me wrong.

So Opteron is to be more of a competitor to Itanium than a replacement for Athlon MP.

Does anyone know if AMD has a replacement for Athlon MP planned? Will Athlon 64 be released in a 2-way version? I see that there will be Athlon MP "Barton" as well as Opteron, but I don't see any Hammer powered Athlon MP (perhaps a Clawhammer based part?)

I think Itanium has improved is competition

[sielwolf]

Isn't much of CPU pricing relative from the Biggest/Baddest Chip? Didn't the advent of an IA-64 chip push down the price of all 32 bit chips? In this way it made it's competition more viable for that much longer (and hurt the few things that made it worthwhile to get).

Re:the reason the Itanic is a bomb..

[Tomble]

Don't forget the Alpha...

Yes, they did have some ports of NT to the Alpha architecture didn't they. Except I hear they dropped that support after a while.

And perhaps most importantly, when have you ever seen or even heard of any actual user software for Windows/Alpha?

Perhaps I just never looked in the right places (after all, why should I, I don't use windows, and I don't have an Alpha. Got a little Sparcstation, but that's nowt to be proud of...).

Re:Most home users run Windows.

[addaboy]

No, because win95 is a piece of shit OS, but you point is valid. AMD should take this opportunity to stick to Intel however. Intel's been playing this game with comsumers' mind that the bigger the number the better the processor. Turnabout is fair play and I hope AMD takes this opportunity to bombard the computer buying public with 64 bit ads. I'd love to see Intel's answer to that, "uuhhhhh, bigger is better only if it says Intel Inside, yeah that's the ticket!"

YABDDRP

[yerricde]

but when was the last time a one step upgrade gave any system a 2x performance.

Darn right. Even the upgrade from NES to GameCube doesn't push the frame rate of Super Mario above 60fps.

when i went from single channel ddr to dual channel ddr i did not see 2x performance

That's because you're playing "double" mode, which is designed for one person on both channels. You have to play "couple" mode with a friend in order to hit 2x the arrows with dual-channel Dance Dance Revolution.

Re:When is the...

[Libor Vanek]

Don't forget that Crusoe and Itanium are targeted for TOTALY different markets. Crusoe is intented for low-powered PDA/Tablet/Notebooks while Itanium is high-end-wanna-be.

Re:the reason the Itanic is a bomb..

[Ponty]

And the PPC...

Re:the reason the Itanic is a bomb..

[snack-a-lot]

There's some here and here.

Re:Obsessive - You've got it wrong

[MrLint]

I wonder if this is more of the "throw more tech at it and it doesnt matter how bad it is we'll ram thru by sheer will" method of hardware (and software) design?

Re:Itanium2 is the fastest floating-point processo

[Master Bait]

Those spec scores are telling because the whole thing fits in the Itanic's level 2 cache.

Linux-kernel Mailinglist

[miketang16]

As was previously mentioned, this is from the linux-kernel mailing list. I would also like to add a humorous phrase that Linus used on that list. "Engineering-masturbation"

Ya gotta love the guy!

which architectures?

[Anonymous Coward]

MIPS is behind Itanium in performance. HP-PA is behind Itanium in performance. SPARC3 is behind Itanium in performance. SPARC64V is behind Itanium in performance. Alpha has higher specint but lower specfp. Power has higher specint but lower specfp. Both major current IA32 processors have higher specint, but they are slaughtered on specfp.

That's without even mentioning TPC or Java benchmarks which make Itanium look just as good or better.

Re:which architectures?

[PurpleFloyd]

Ooooh, benchmarks. Any company can pick and choose good benchmarks for their chip; you aren't even giving numbers. I want to see some real-world numbers, preferably ones that relate to the Itanium2's ability to handle non-preprocessed code (as other posters have mentioned, trying to work with anything dynamic throws all of Itanium's fancy explicit parallelization out the window) Put up or shut up.

Re:which architectures?

[blair1q]

Wrong. They design chips to improve scores on benchmarks. Otherwise you wouldn't be able to tell they got better.

Re:Why 64 bit

[nomadic]

they were not needed for the first several years of DOS when people had only 512 kb of ram

Wha? I would have given my right arm for 512kb. Mine had 128k. Next step up had 256k. Geeze, 512k? We'd have been in happyland...

code size does matter

[brdsutte]

The smaller a memory (whatever the manufacturing process), the faster a single access can be made and the lower its power consumption per access will be.

The fundamental reason is that the chip interconnections are on average longer for larger memories and that these connections behave like resistor-capacity systems. The longer the connection, the higher the RC constant, and the slower the component. The slowdown of longer lines can be overcome by increasing the voltage, but then power consumption (and accordingly heat dissipation) will increase dramatically, resulting in all kinds of problems. That's basically why storing data or code in smaller memories is good for speed and power consumption.

By the way, if smaller memories would not have important benefits, no chip producer would ever spend more than half of the chip area on up to three levels of caches. Of course small memories are useful only as long as the hot code of programs fit in them.

Hope this helps.

Re:Itanium2 is the fastest floating-point processo

[Goalie_Ca]

Perhaps this is just another "technical" and "synthetic" benchmark. It's all about real world performance, like Linus said, and there are many other shortfalls to the chip and its architecture.

Re:Itanium2 is the fastest floating-point processo

[mrm677]

The SPEC benchmarks are real-world. That's the point of them, and they've been used over the last 10 years to judge the real performance of a processor.

Itanium 2

[hackus]

I think Itanium/Itanium2 are radical departures in x86 design, and they do not come without risks.

These risks are calculated, and I think it is a bit much for Linux to say iNTEL engineers learned nothing from the past.

Much of the Itanium design, is reliant on processes that haven't even been perfected yet....(0.9 Micron etc silicone).

As process technology catches up with Itanium, and the bugs get worked out over the next 2-3 years, I think you will see Itanium in the server room and also on high end desktops.

Not only that but they will out perform anything the market at the time they are introduced.

-Hack

Re:Itanium 2

[EvilTwinSkippy]

Frankly, all of my Ghz dual headed machines spend most of their life waiting for the network card. My email server MIGHT hit a load of .4 on a busy day.

What I REALLY need in my data center is stuff that runs cooler, without so many fans that go bad, catch fire, short out, etc.

Re:Most home users run Windows.

[charon_on_acheron]

"uuhhhhh, bigger is better only if it says Intel Inside, ...!" ...with blue men and people in iridescent environment suits dancing around it.

Re:Most home users run Windows.

[captredballs]

Don't forget that Itaniums are clocked far lower than P4's. The difference is that Intel doesn't plan on marketing 64bit chips to the consumer for a couple years, while AMD has their sights set earlier due to the expected lifespan on the Athlon-family and that their future is bet on 64bits.

I guess the main thing to note is that the P4 will be around for a least two years longer, where you can't say the same thing about Athlon family, at least at the high end.

Also coming into the picture is that Apple may have 64 bit workstations in ~ a year.

A chipmaker ready to kick the bucket.

[glrotate]

I'd be much more interested in readying why Linus thought Transmetta was such a flop.

Re:Where's the Harsh Words for Transmeta?

[heptapod]

Yes, revolutionary.

Just like the Segway.

Any of you read Fortune?

[AxelTorvalds]

The Feb 17th issue broke it down nicely. You can read it on their web site. Basically. The conventional wisdom is that there are exactly 2 players in the 64bit arena: IBM and Intel. IBM isn't jumping on the Itanic either, at least not in any big way other than building some low end servers with it.

AMD is the wildcard. If x86-64 is the bomb and takes off like AMD is betting on it. Intel lost the 64bit war for many years. IBM and maybe even Sun will quietly (well sun doesn't do jack shit quietly) push x86-64 for the low end while IBM POWER4 and POWER5 and POWER6 down the road run the big end.

Basically Intel needs something like Sun to jump on it IA64 to really give it some credibility and they don't sound real eager to. IBM sounds like they are down for the fight. Alpha, MIPS, PARISC are all pretty dead; long term and relatively speaking. Meanwhile, if Intel doesn't get on the shit quick then they'll have to support x86-64 too and that's the real death blow to IA64.

Re:Any of you read Fortune?

[bstadil]

Sun will quietly (well sun doesn't do jack shit quietly)

Look at this story today about Sun using Mobile Opterons in their new Blade offering.

Re:Any of you read Fortune?

[evilviper]

Meanwhile, if Intel doesn't get on the shit quick then they'll have to support x86-64 too

Years later, computer historians will raise the Itanic... *rimshot*

Sorry about that. Anyhow, if Intel's efforts would fall flat, I think they still have the option of developing the Alpha and just calling it their own "new" chip.

Perhaps they can code-name it "Lazarus"... *rimshot*

I really would be great irony to see the Alpha come full circle. ie:

HP drops the Alpha processor family.

HP ports OpenVMS from Alpha to Itanium.

Intel's next 64-bit chip is the Alpha.

HP ports OpenVMS from Itanium to Alpha.

Re:the reason the Itanic is a bomb..

[penguinboy]

And MIPS. Last seen in NT4.

Linus holding on to his security blanket?

[rmdyer]

Sounds just like the Linus of Charlie Brown holding tight to that security blanket.

Kids will be kids, but unless they are cartoons, they eventually grow up.

But, alas, I tend to agree with him. I just don't get RISC chips. Why they want to remove things that make programming easier is beyond me.

+2 cents contributed.

Re:Linus holding on to his security blanket?

[squiggleslash]

I just don't get RISC chips. Why they want to remove things that make programming easier is beyond me.

It's not stuff that "makes programming easier" that gets removed in RISC, its the more complex try-to-do-everything instructions which are a pain to implement in silicon and which ultimately can just as easily be done via a sequence of simpler instructions that may well, for a programmer who's actually programming at that level, be easier to understand.

Early on the chief advantage of the approach was that you could use the freed silicon for things like extra registers, and that's exactly the approach taken by Acorn (now ARM) and the PowerPC range. Would you prefer to have eight registers and a single byte copy-block instruction, or 64 registers and have to replace that copy-block instruction with (*gasp*) three simpler instructions?

(Actually, I guess that depends on how good your cache is. There's no such thing as a free lunch)

Re:Linus holding on to his security blanket?

[KewlPC]

Why they want to remove things that make programming easier is beyond me.

One of the things about a true RISC processor is that it has no microcode, no microengine, etc. The instructions run directly on the bare hardware.

This means that the instructions that would require a microengine to implement get taken out of the instruction set.

Additionally, RISC favors a more simplified instruction set design (using simple memory address modes instead of complex ones, can only load/store directly to or directly from registers, etc.) with LOTS of general purpose registers, which, as far as assembly programming goes, actually make things easier. In reality, most of the instructions that get left out would never have been used, so it's a waste to include them. The x86 instruction set, for example, is chock full of opcodes that nobody uses.

The only real disadvantage to RISC is the larger code size.

But ask anybody who has done assembly language programming on both x86 and a decent RISC architecture which of the two they prefer, and x86 will most always lose out.

Re:Linus holding on to his security blanket?

[4024490502]

Would you prefer to have eight registers and a single byte copy- block instruction, or 64 registers and have to replace that copy-block instruction with (*gasp*) three simpler instructions?

You obviously know much more about cpu architecture than I do, so perhaps you could help me with something I don't totally understand: I don't doubt that RISC architechture is simpler, but isn't the executable code for a RISC cpu much larger than the code for a non-RISC cpu? For some things that can be done in one instruction on a CISC cpu, it takes several on a RISC. This would seem to me to take both more code for a program and be more intensive on the system bus by transfering the extra instructions. Am I wrong?

Re:Linus holding on to his security blanket?

[james_shoemaker]

> The only real disadvantage to RISC is the larger code size.

Isn't there also a cost in context switching saving all those registers?

Re:Linus holding on to his security blanket?

[KewlPC]

It depends on the processor.

Although I've never done assembly programming on them, SPARC CPUs have hardware contexts, so as long as you're not running more processes than your SPARC CPU has hardware contexts, the large register set doesn't hurt performance when switching between processes.

Re:Linus holding on to his security blanket?

[Molz]

As he said, there is no free lunch.

As I remember it from my Comp Arch and Org class, RISC takes up more room for instructions, but makes up for it with the number of things you can do in one clock cycle via pipe-lining. You also get the added benefit that all of your instructions are of a fixed size. So your fetch and decode hardware is much simpler.

There is no free lunch; you can have a much simpler arch that is easier to produce (or should be), or you can have a more complex arch that has a smaller code footprint, but its complexity makes it bigger, hotter, and harder to produce.

Re:Linus holding on to his security blanket?

[norton_I]

Yes, RISC programs tend to be longer (sometimes considerably) than CISC programs. There are actually two (main) reasons for this. First, as you mentioned, you need to replace single instructions (usually ones that do memory-to-register operations) with multiple operations (such as a load followed by an math operation). Second, the instructions themselves tend to be longer, since most (all?) RISC archetectures have exclusively 4-byte opcodes - usually something like 1 byte for the opcode, a few bits for flags, and the remaining for up to three arguments. (register numbers or immediate values). CISC archetectures have varying length opcodes, some a signle byte and some several bytes.

There are a couple of mitigating factors here. First, compilers are usually not very good at using some of the more complicated combined instructions, so they go unused, inflating CISC code to match RISC code. Second, careful optimization of RISC code can identify repeated or unecessary memory operations, and eliminate them. When the memory operations are tied to the arithmetic (or other) operation, that is not possible. Finally, since RISC archetectures generally have large register files and all registers are equivelent, fewer operations are needed to shuffle bits around to where they can be worked on, whereas i386 has a lot of operations that only work on certain registers (though far less than earlier incarnations).

I used to be a big fan of Intel cutting life support on the 386 archetecture, because RISC is so obviously cleaner and nicer. However, I have started to believe the AMD hype about x86-64, which is basically along the lines Linus talks about here. RISC vs. CISC doesn't really matter any more, and the i386 archetecture is not so bad. If you A) add some more general purpose registers, B) eliminate most of the remaining register usage restrictions, and C) Ditch the worst (looking and performing) FPU on the market in favor of almost anything else, you have yourself a very servicable archetecture. Extend the registers and addressing to 64 bits, and you have something that has a lot more room to grow. That is what the x86-64 is, and despite all the rumors that Intel has their own 64 bit extension to x86, if they don't actually release soon people will start to adopt x86-64 and they will be in the unenviable posistion of having AMD dictate the future of their product line.

I have heard frequently that something like only 5% of the transistors on the PPro core were tied to the "i386ness" of the core. I assume with the P4 that number is even less. It seems then that the instruction set is not as big of a deal as we would like to think.

The thing that puzzles me about ia64 is: if the whole point is to "make the compiler do it", and none of the fancy instruction reordering is done in silicon, why is it so expensive?

Re:Linus holding on to his security blanket?

[GlassHeart]

Actually, the proponents of RISC were not terribly concerned about the assembly language programmer. In fact, one of the early advantages of RISC was pipelining, which is actually quite a bit harder to program for, compared to non-pipelined CISC.

What they counted on was that fewer and fewer people would be writing in assembly, and the complications can be hidden behind a good compiler. What they also failed to foresee was that a RISC/CISC hybrid like the later x86 chips got nearly the best of both worlds.

Re:Linus holding on to his security blanket?

[TheLink]

Ask anyone who has done assembly language programming on x86 and a decent CISC and x86 will always lose out too.

But the x86 has evolved a lot since the bad old days. You could regard the ugly stuff as vestiges of a primitive form and stick to saner modes.

A larger code size can be a significant disadvantage nowadays. Imagine CISC as compressed RISC opcodes. The current situation is the CPU is VERY much faster than the RAM or even the 2nd level cache. So it's not a big deal to have to decompress (decode/expand to RISC) instructions in the CPU. You gain overall processing throughput that way.

As long as that situation remains, larger code size is a significant issue. It means fewer programs in memory.

True RISC processors you talk about are declining. Most are becoming more pragmatic. Which is what Linus is talking about.

Re:Linus holding on to his security blanket?

[TA]

It's expensive because of the huge amount of cache on the chip. Without it the performance would be abysmal. The difference between cheap and expensive chips is almost entirely dictated by the amount of cache.

Re:Linus holding on to his security blanket?

[squiggleslash]

I knew someone would bring up pipelining.

Pipelining has nothing, per-se, to do with RISC. It has to do with speed, and it happens that much of the attention that was focussed on RISC was there because it was seen as an inherently faster architecture than CISC. As a result, many RISC chips were being designed by people who just wanted a fast CPU, which is why technologies like pipelining were incorporated into them.

Not every RISC chip does pipelining (and not every chip that does does it all the time in a "you must always plan your branch before it executes" type way), and there's no reason to leave pipelining out of a CISC design, other than it being a bugger to program for.

Re:Linus holding on to his security blanket?

[naasking]

Isn't there also a cost in context switching saving all those registers?

Yes indeed. Fortunately, the register save advantage is offset by other factors in the x86 architecture which still leave it worse off than RISC. Let me give you some numbers to put this in perspective.

User to supervisor mode transition times:
Pentium: 40-60 cycles
Pentium III: a few hundred cycles
Pentium IV: 2000 cycles

PowerPC: 5-20 cycles (depending on chip)
MIPS: 4 cycles (IIRC)

2000 cycles just to switch processor modes! The highest cost in context switching for the x86 is user-supervisor transitions which are far more numerous than actual context switches. Furthermore, x86 does not implement a tagged TLB which means the TLB must be fully flushed on every context switch (an incredibly expensive operation). The simpler instruction set of RISC chips frees more silicon to implement performance enhancing features like tagged TLBs.

Re:Linus holding on to his security blanket?

[JollyFinn]

On most electrical design except extremely commodity cheap thingies, the manufacturing costs are neglible. For instance 300mm die should costs about
30$ and then there is packaging and testing costs more. But 3 things are expensive.
a) NRE= the costs per design revision you start manufacturing = 1M$ per revision
b) design costs of the chip divided to all chips.
c) MARKETING COSTS!!!!!!

Besides IA-64+x86 on same chip is doomed to be more complex to design than pure x86 or pure IA-64. Currently intel does mixture chips.

Re:Linus holding on to his security blanket?

[ratboy666]

The main problem is that there is no free lunch. The laws of thermodynamics will bite your ass. If the code is bigger, it still has to be fetched from memory, and the processor still has to parse through it. If there is MORE code, then either (1) there is more power dissipation (heat), or a lower clock frequency. Instructions may be predicated (and are, in the ia64), but the damn code STILL needs to be fetched. A better idea would be to modify the run-time code (ala Java hotspot, or Transmeta code-morphing). The problem is made worse by the current crop of compilers: For example:

if (nasty_error)
{
do_some_error_recovery;
}

Most compilers have NO idea that the error recovery code is going to be rarely used, and should be moved out of line to avoid fetching.

The SUN C compiler does have a "#pragma rarely_used" which may be applicable, but is limited (I believe it works on functions only).

So, the problem with very wide RISC is code size, which gives us a heat problem.

HP/UX has (as far as I know) a PA-RISC to PA-RISC morpher that gets linked into applications. That seems like a reasonable solution to the clunky compilers. Of course, I want the option to have a very big address space, AND run-time optimization , AND the ability to give more semantic information to my compiler. Maybe next year...

Ratboy.

Re:Linus holding on to his security blanket?

[squiggleslash]

You left out testing.

Testing for a complex chip is a hell of a lot more time consuming (and thus expensive) than testing a little 74LSxxx gate, no matter how much silicon is involved, and with a CPU the consequences of a failure to test something properly can be severe.

Re:Linus holding on to his security blanket?

[GlassHeart]

Pipelining has nothing, per-se, to do with RISC.

I know that. However, RISC designs in general are easier to pipeline, and it was one obvious thing you could do to achieve similar or better performance at the same CPU clock over CISC.

In particular, I bring up pipelining to refute your earlier statement:

[...] easily be done via a sequence of simpler instructions that may well, for a programmer who's actually programming at that level, be easier to understand.

My point is that RISC is generally not easier to program at assembly level, because so many of them are pipelined. The designers were instead counting on good compilers hiding that from most programmers.

Re:Linus holding on to his security blanket?

[squiggleslash]

I still disagree. For example, the ARM has no such issues with pipelining. The problem you're describing is not inherent in RISC design, it's inherent in designs for CPUs where speed is the number one concern. In the latter case, those CPUs are usually happen to be RISC, with pipelining and large caches.

Pipelining existed before IBM's original RISC design (the 701? I can't remember, it's been a while. A revision eventually made its way to the ill-fated PC/RT) The 6502 had it, for instance. The latter however did hold up execution when faced with a branch instruction, as do many modern implementations of pipelining.

Everyone I know who has programmed the ARM says it's a beautiful processor to program for, more pleasant and programmer friendly than the 680xx series, which is quite something.

Reasons for using RISC designs varies. In Acorn's case, the original intention was to have a modern CPU whose design was under their control. In the PowerPC's case, a scalable architecture that could reasonable replace the 680xx range and compete with Intel's near monopoly ix32 architecture, which had a RISC design largely because that was in-vogue at the time. There's the CLIPPER, a CPU whose primary attribute is reliability, and where RISC was critical to ensuring it was simple enough to be clearly understood and clearly predictable and easily testable. I seriously doubt the latter even has a pipeline.

Merely because speedy CPU designers have tended to go for RISC designs doesn't mean that RISC is purely a way of creating fast CPUs. And it doesn't mean that unrelated optimizations designed to keep a CPU running as fast as possible are a necessary part of being a RISC design.

Re:Linus holding on to his security blanket?

[GlassHeart]

Reasons for using RISC designs varies. In Acorn's case, [...] control. In the PowerPC's case, a scalable architecture that could reasonable replace the 680xx range and compete with Intel [...]. There's the CLIPPER, a CPU whose primary attribute is reliability [...]

As you can see, then, none of them emphasize ease of programming at the assembly level, contrary to what you earlier suggested. The underlying design assumption was that most users will be programming in HLLs. Pipelining is just one the most obvious examples of such a feature that exhibits this assumption.

So please, the point is not that RISC and pipelining are tied together. The point is, as shown by many pipelined RISC designs, that the designers care more for other attributes than ease of programming in assembly.

Re:Linus holding on to his security blanket?

[squiggleslash]

I have never suggested that any of the designs emphasize ease of programming. What I've said is that there is not necessarily a trade off, RISC does not imply making it difficult to program. And the ARM is an example of a RISC CPU that is, by consensus, easy to program.

Remember, I was originally responding to someone who argued that RISC was merely "removing things that make programming easier". I said that wasn't the trade, and I stand by that. Unless you want to uninvent the ARM ;-)

Re:Itanium2 is the fastest floating-point processo

[dpletche]

SPEC scores tell me almost nothing useful. The code to run SPEC benchmarks is emitted by tricked-out compilers whose whole purpose is to emit hand-crafted assembly code specifically tuned to run those SPEC benchmarks. It doesn't tell me anything about how well common programs and subsystems perform at common tasks. You might as well buy a family car based on the quarter-mile time at the racetrack for a like-model car with a supercharger and dangerously-tweaked ignition timing, burning 120 octane racing fuel.

In five years, if the Itanium isn't a huge success, will you eat your words?

Anyone remember the Pentium Pro?

[a-freeman]

Back when it was released, it was roundly maligned for offering shitty performance for Win95 users. "Buy a Pentium 233MMX" all the magazines screamed.

Well, the PPro turned out to be one of the best chips of its day, and the 200Mhz version performed within 5% of the Pentium II 300mhzs that were released 18 months later. I still have dual-PPro system running my CVS/MP3/print/etc. server.

Linus may be a god in the linux software universe, but I wouldn't discount Intel on this just yet.

Re:Anyone remember the Pentium Pro?

[1010011010]

The great thing about the PPro is that is ran the binary Pentium software images unmodified, and with decent performance.

IA-64 doesn't.

Re:Anyone remember the Pentium Pro?

[warrior]

There comes a time when you have to chuck backwards compatibility in the name of progress. The problem is we've got all this existing software that's been tailored for x86. Right now we're experiencing similar problems in the automotive industry, which is much more stodgy than the semiconductor biz. We're stuck with ancient internal combustion behemoths because of people's unwillingness to accept change. Likewise, we're stuck with cpu tech that's relatively much older than our crappy auto tech given the pace of the semiconductor industry.

Let x86 go! Live in the now! Itanium is a great CPU. Sure, the first iteration sucked, but look at it in the same light that you view electric automotive designs. Now take a step back and look at Itanium II. Itanium II is currently the leading performance CPU for floating point code by a small margin over Power 4 ( which, I might add, costs 2-4x more than an Itanium system ). In four months time Intel is said to be releasing a frequency bump to Itanium II with even more L2 cache. IA-64 performance scales almost linearly with frequency! (and no, you don't even have to recompile to reap the benefits of increased frequency) When Dell saw that the Itanium II performance rumours were true, they did a 180 and are now playing catchup to other vendors. IBM has hedged their bets by building Itanium II systems, Sun is dying, and Opteron will be DOA.

Re:Anyone remember the Pentium Pro?

[atrus]

Actually, I have a dual PPro 200 (512K cache) running as my gateway/printserver/fileserver myself :) Love the machine, never caused a problems, solid as a rock, and not dead slow either.

Re:Anyone remember the Pentium Pro?

[modulo]

Like, how the Pentium Pro didn't have a 16-bit selector cache, and the PII put it back in?

Which was progress?

Re:Anyone remember the Pentium Pro?

[MtViewGuy]

The thing that hurt Windows 95/98/98SE on a Pentium Pro was the fact these are still in many ways 16/32-bit hybrid operating systems. No wonder why they weren't that great on Pentium Pro machines.

However, Windows NT and Windows 2000 definitely worked great on a Pentium Pro system if you had enough RAM installed. I've run Windows 2000 Professional on a Pentium Pro 200 MHz (256 KB L2 cache) system and its performance was actually quite good, mostly because the whole OS took advantage of the 32-bit optimizations on the PPro CPU.

Besides, the Pentium Pro CPU core became the basis for the Pentium II, Pentium III and pre-P4 core Celeron CPU's.

Re:Anyone remember the Pentium Pro?

[Sentry21]

Well, the PPro turned out to be one of the best chips of its day, and the 200Mhz version performed within 5% of the Pentium II 300mhzs that were released 18 months later. I still have dual-PPro system running my CVS/MP3/print/etc. server.

This probably has something to do with the fact that the PPro was a new core, but the PII and PIII used that same PPro core. Same reason I've been dying to get ahold of a good PPro system - lower power use than the PII/III servers out there, but still good performance.

--Dan

Re:Anyone remember the Pentium Pro?

[phriedom]

"Well, the PPro turned out to be one of the best chips of its day, and the 200Mhz version performed within 5% of the Pentium II 300mhzs that were released 18 months later."

The difference this time is that the equivalent desktop processor isn't 18 months behind, it is ahead. That is was killed Intel's first try back when it was called Merced it was so late that it underperformed against the P3s and cost a lot more. Another interesting point about your P-Pro there is that (so I am told by people who probably know) it failed because putting a large amount of cache right on the die instead of separate tested cache outside the CPU package improves the speed of the cache, but increases the scrap, because any time cache is bad you have to throw out the entire processor. That made the P-Pro more expensive and ensured that it wouldn't sell well. Gee, that sounds just like the newest IA-64 chip with giant amounts of cache and matching high price, doesn't it?

Re:Anyone remember the Pentium Pro?

[MarcQuadra]

Chips based on Itanium will be 4 inches square and suck 120 watts of juice. Intel consistently designs CPUs that are big, hot, and inelegant. Intel produces the 'combustion engine' of the CPU market, it's big, inefficient, and uses a lot of juice. The P4 puts out more heat than a comparable athlon, and it needs a giant dumb heat sink.

Look at the PowerPC architecture, you can run a G4 without a fan and get great performance. The PPC 970 (based on Power4) will be a seriously smooth CPU, trust me. And AMD is heading in that direction, with more ops/cycle and more elegant design since the Athlon came out.

Intel suffers from CPU-Design bloat, if you ask me. They're more concerned with selling it than getting it right.

Linus on IA64

[davydmadeley]

At a recent QA, Linus was asked a question as to what he thought on IA64. He went on to tell a story about developers of the processor asking him if he could see a use for some of it's features. He replied with "errr, no!".

Even better...

[ubugly2]

...The shipping is free.

intel should buy transmeta

[Cheeze]

Intel (or AMD) should buy transmeta.

i hope something like that is in the works.

intel should turn transmeta into their server line of CPU's, and specifically design them around linux.

come one guys, if you play together, great yields ye shall receive.

Re:intel should buy transmeta

[SN74S181]

intel should turn transmeta into their server line of CPU's, and specifically design them around linux.

And they should use Transmeta parts because their 'server line' should be extremely low power? Are you talking about wireless servers duct taped under the seats on city busses or what??

x86 will win...and that's too bad

[Pemdas]

x86 -- it's cheap, fast, available, and compatible. That's why it consistently wins in the marketplace.

That doesn't mean it's the best solution. Merely the one that's going to win. Architecturally speaking, x86 is one of the biggest loads of crap to come along since...well...hmmm...I can't think of anything crappier off the top of my head.

Extreme register pressure. Segmentation models that make you want to retch. Hacks (PAE, anyone?) that leave any sane designer gibbering incoherently.

If you read the thead, Linus' main argument seems to be "to get good performance, all the other architectures have had to do complex things in hardware, so there's no real hardware simplification in going with a 'better' architectural design. Plus variable length opcodes are a natural cache optimization!"

I respect Linus a great deal, but he's talking out of his ass here. I agree that IA-64 may be best relegated to some academic's wet dream, but just about any of the major RISC architectures are big wins over x86. Intel and AMD have worked miracles with x86 to get it to run fast, but at a staggering engineering cost. The teams working on RISC chips tend to be a fraction of the size to come out with a high-performance chip. If the RISC houses had an engineering team of comperable size (and access to the same bleeding edge lithography processes) it would easily be worth an extra 25% in performance, minimum.

If you look in the embedded world, just about anything that requires serious embedded performance is RISC based (MIPS/ARM, mostly), simply because it decreases the engineering work involved by an order of magnitude. Plus, writing low level software for just about any RISC chip is loads easier than for x86.

Unfortunately, x86 is here to stay for the foreseeable future. Intel killed Alpha, not by buying it, but by doing a great job of pushing cheap x86 performance to the same level as Alpha, often surpassing it in later years. The same thing is happening to the other workstation-class RISC vendors, and, honestly, to Itanium, too. I don't see any reason to believe the march to x86 hemogeny outside the embedded world is likely to slow anytime soon.

Re:x86 will win...and that's too bad

[TFloore]

Intel and AMD have worked miracles with x86 to get it to run fast, but at a staggering engineering cost. The teams working on RISC chips tend to be a fraction of the size to come out with a high-performance chip. If the RISC houses had an engineering team of comperable size (and access to the same bleeding edge lithography processes) it would easily be worth an extra 25% in performance, minimum.

I don't think you read the same thing I did.

Linus doesn't seem to be saying "if the teams were on equivalent footing, x86 would still win."

Instead, he's saying (in part, among other comments) "because x86 has such huge volumes, Intel/AMD can afford to optimize it to a point that it beats all the 'better' low-volume games in town. And that will never change as long as x86 maintains high volumes."

Of course, he's also saying that those 'better' architectures aren't really all that much better. And in some cases he thinks they are worse.

But he is not making statements of "in a fairy world where they are on equal footing" because Linus lives in the real world, and cares about how things work in the real world.

Re:x86 will win...and that's too bad

[RzUpAnmsCwrds]

It may not be the best option.

But it's cheap, available, compatable, fast, and damn common.

Both AMD and Intel have shown that x86 can be a high performance architecture. Sure, it took resources. But less than 3% of the transistors on a P4 or Athlon are devoted to converting instructions to microcode.

So, what's the problem? It's cheap, compatable, fast, and available. What more could you want from a CPU?

We can't play the game of "if [insert RISC architecture here] had won". It didn't. So are we to abandon 20 years of compatiblilty to change to a "more efficent" architecture?

Intel thinks so. EPIC is radically diffrent. And we see where it's gotten them.

AMD does not. They take x86, clean it up, make it smarter, and call it x86-64. It's imperfect. But it's also fully x86 compatible. That means that twenty years of software are compatable with it. That means that I can take Windows Server 2003 or Windows XP or Redhat 8.0 or any other x86 OS and run it. And it runs well. Damn well. P4 3.06GHZ HT well.

Don't want to migrate all your software? Opteron and Athlon 64 are the perfect answer. Great 32-bit performace, and 64-bit functionality for the OS and apps that support it.

Someone could switch my computer with a Crush-K8 powered Athlon 64 system, steal my disks, reload my OS (Windows XP Pro 32-bit), and I could come back the next day and not notice it.

Compatability exists because the past doesn't just go away. That's why x86 still exists. That's why I believe that Hammer will be a smash hit (excuse the pun).

Re:x86 will win...and that's too bad

[drinkypoo]

AMD has been pushing RISC chips with an x86 decoder (secret ring?) at us since the K5. The K6 is a full-risc CPU with an x86 decoder on it, I don't know how RISCy the K5 is but I know it's mostly. Guess what, Athlon follows the trend, same deal. This is how AMD has solved the hard work of making x86 work... emulation :P

Re:x86 will win...and that's too bad

[La Temperanza]

Well, I know I would prefer a chip- or a whole PC- that didn't need any fans in it to keep the thing from becoming heat-piping-hot silicon soup. They're noisy and they break too easily. Until then, I am stuck with my original iMac.

Re:x86 will win...and that's too bad

[BerntB]

So, what's the problem? It's cheap, compatable, fast, and available. What more could you want from a CPU?

Not getting my lunch back up when learning the assembler?

All the beer in Ireland or Belgium wouldn't make me get a job to write compilers for that processor architecture.

Also, as the other comment said -- the extra transistors make 'em eat batteries in portable applications (where you can't just get a bigger fan).

Re:x86 will win...and that's too bad

[bobbozzo]

All the beer in Ireland or Belgium wouldn't make me get a job to write compilers for that processor architecture.

Are you saying you would like to write compilers for Itanium???

My understanding is it's extremely difficult to get optimal performance out of it.

Uh... it's already there

[Anonymous Coward]

ia64 is in the mainline kernel. At least Debian and Red Hat have released, stable distributions for it. Red Hat even sells support for it.

ia64 is "in there" as much as alpha and sparc, even if it isn't quite as well tested.

Re:Why not a 69-bit chip?

[ubugly2]

If you overclocked it it would eat itself..

Re:Itanium2 is the fastest floating-point processo

[geekinexile]

"Linus will eat his words in a few years."

I guess those would be the words where he says it will take Itanium a few years to catch up with x86?

Re:Why 64 bit

[Billly Gates]

My father was a software engineer and project manager. I was a kid at the time so I got really expensive toys he brought home from work. :-)

Not only did I have an XT with 512 kb but back in only 85 or 86 my father brought home a 286 IBM AT with a whopping 2,000 kb aka 2 megs of ram, 40 meg hard drive and a full color monitor! The word meg was not used commonly at the time so I called it 2000 kb. All my friends had appleII's and commodores with 128k of ram and I had 2 fucking megs! hehe

Then I learned about the limitations of 16-bit operating systems and memory access. 2 megs were a waste on the system. The expanded memory hack worked but most programs later on only worked with extended memory which the 286 could not do. Then he bought a 486 but unless os/2 was loaded on it I had to deal with the same limitations. He was pissed that I loaded a pirated version of os/2 and wanted windows 3.11 back on. Bawawawa. Glad I am an adult now.

Blow

[quintessencesluglord]

Hmmm, not being a "true" geek (would not even consider... Don't know any programming languages), I notice sales of video game consoles aren't particularly sluggish (allbeit a slow running 128 bit). Sony promises a 256bit machine in a few years, and I imagine it will sell very well too (as well as any of the other competitors).

On top of being a top flight gaming machine (which is the lionshare of the consumer computer market), it will probably be able to do all of the things people use their desktops for now. And it will probably do it at about half the price. In which case, why do I even need a desktop (except damnit, I can't run Wavelab. Certainly an OS clone will follow)?

I think couching the argument in terms of Intel vs. AMD, etc. is shortsighted. I have heard the arguments of "you don't need more power", and historically, they has been proven wrong (the first killer app will sell the hardware).

Intel, please get your affairs in order. The last gasp of a dying breed.

Re:the reason the Itanic is a bomb..

[wideBlueSkies]

NT was built on the i860 first, then ported to the i386 arch. More accurately, MS engineers emulated the i860 untill the chip was ready.

MS did this to make their new OS more or less platform independant. They didn't want to get 'stuck' on the x86.

Slashdot story here . Article here .

Re:Why 64 bit

[nomadic]

My first computer was a PC Junior. 128k of RAM, and I'm not sure how fast it went but it would have been 4.77 mhz at the fastest (and probably a little less). I loved that little machine.

Then I learned about the limitations of 16-bit operating systems and memory access. 2 megs were a waste on the system.

It sounded good at least...

TPC would say differently

[Yankovic]

The second highest rated TPC box in the world is running Itaniums...

http://www.tpc.org/tpcc/results/tpcc_perf_result s. asp?resulttype=noncluster

AMD was going to enjoy life @ 48bits

[Anonymous Coward]

Actually that's a good question. I think chipmakers should slow down a bit and enjoy life. Perhaps meet halfway with a 48 bit chip...

That isn't as silly as it sounds. AMD was doing exactly that: working on a chip which would support x86 8, 16 & 32bit CISC code, as well as supporting its own high-performance 48bit RISC instruction set. They gave up on the project, instead going the hole hog with 64bits when they realised their 64bit CPU project was an attainable target for them.

Re:AMD was going to enjoy life @ 48bits

[Cleveland Steamer]

Actually, if you look at the x86-64 spec, you'll see that it uses 48-bit virtual addressing, and 40-bit physical addressing. Virtual addresses are sign-extended to the full 64 bits.

Re:offtopic

[MSBob]

The plural version is actually correct for any version of English besides the US English.

Listen to Torvalds about making money

[jbischof]

because he knows.

Linux made him ... oh wait nevermind.

Transmetta makes a lot of ... oops there I go again.

Intel is a company that time and time again proves it knows how to make money. It may not always support the crowds it should (like /. readers and superusers) but they are still making money.

Sure there are lots of difficulties going to a new ISA. Especially at the server level. And yes Itanium has had some performance problems, especially in its first revision, but then again when was the last time you saw a company produce a 1st generation microprocessor and have it do well?

IA64 offers tons of advanced ILP concepts and OS concepts that, when correctly implemented, can increase performance drastically. (if your looking for examples, data speculation, control speculation, predication, registers with kernel access only, rotating register files, a much larger register set, etc).

The problem may be, it puts a lot of complexity into the Compilers, and compiler technology isn't good enough for Itanium yet.

But then again, what do I know, Linus has made more money than I have. I just like arguing the other side while everyone else screams about how the Itanium will die.

Re:Listen to Torvalds about making money

[powerlinekid]

Linus is certainly well doing perfectly fine with money. He may not be Bill Gates but I'm sure hes worth more than 99% of people here on slashdot. Remember how much stock was given to him when Linux started taking off. I think he made a killing in VA stock before it dropped (didn't he buy is Z3 with that?). He also has stock in RedHat if IRCC.

Re:Listen to Torvalds about making money

[Ninja Programmer]

• Intel is a company that time and time again proves it knows how to make money.

Yeah, by relegating each successive x86 architecture to the role of "back up plan" and pushing forward some "new idea" like i432, i860/i960, and now Itanium.

The fact is, although their formula for success is so god damned bloody obvious (sell more x86s) they only managed to realize this almost by accident.

• Sure there are lots of difficulties going to a new ISA.

And as any other CPU endeavour will attest, you can't fix the ISA, except to add instructions in afterwards (and even then you have "legacy applications" problems.)

• Especially at the server level. And yes Itanium has had some performance problems, especially in its first revision, but then again when was the last time you saw a company produce a 1st generation microprocessor and have it do well?

Alpha? Sparc? MIPS? All of them topped the performance charts when they were first introduced, and typically by margins *much* higher than Itanium 2's current FP lead in Spec FP.

• IA64 offers tons of advanced ILP concepts and OS concepts that, when correctly implemented, can increase performance drastically.

Yeah unfortunately it requires that you write your software in a completely different way, or have compilers using "the hand of god" techniques.

• (if your looking for examples, data speculation,

Something available from transmeta's CPUs.

• control speculation,

More commonly referred to as "branch prediction".

• predication,

Conditional moves -- yawn.

• registers with kernel access only,

Are you sure that this is unique to IA-64? We know for a fact that x86-64 will at the very least, reserve FS and GS for ring-0 access.

• rotating register files,

As opposed to the more general "renamed registers".

• The problem may be, it puts a lot of complexity into the Compilers, and compiler technology isn't good enough for Itanium yet.

Has it occurred to you that perhaps it *cannot* get good enough? The results you see are the most herculean efforts from the combined HP and Intel compiler teams. Its not like there is some magical compiler solution -- they already have state of the art in compiler technology in what they have today.

Re:Listen to Torvalds about making money

[EvilTwinSkippy]

Considering that the memory bus is the major obstacle to performance, I couldn't give a rats ass about processor speed or capability.

I want a low-power quiet machine that can play my DVD's and run open-office. Explain how any of this dicksizing to 64 bits gets me there?

Re:Listen to Torvalds about making money

[drinkypoo]

At least two PowerPC families (G3 and G4) have registers which are accessible only to the kernel in the proper modes.

Re:Listen to Torvalds about making money

[metallic]

He sold his RedHat stock options and bought a nice house for him and his family in California. That's worth at least half a mil.

Re:Listen to Torvalds about making money

[jbischof]

Alpha? Sparc? MIPS? All of them topped the performance charts when they were first introduced

True, they did look much better when they came out, however as processors advance further and further, trying to tweak out every last bit of performance, the gains provided by a new architecture will be smaller. Sure Itanium made some mistakes but with further revisions it gets better and better. It is showing drastic performance increases from iteration to iteration mostly because Intel is learning from some mistakes it made early on.

"the hand of god" techniques

I don't know exactly what you are referring to, however I don't know why compiler technology shouldn't be expected to advance just like processors are.

control speculation, More commonly referred to as "branch prediction".

Control speculation isn't really branch prediction, it is executing an instruction before its dependency (on and if statment) is resolved. Then if wrong, the result is simply discarded, so there is no branch prediction.

predication, Conditional moves -- yawn.

Itanium takes predication a step further, it allows for two potential branches to be run in parallel and the speculation prevents a branch, that would otherwise be run. Thus it's predication prevents branches and dreaded branch mispredictions.

rotating register files, As opposed to the more general "renamed registers"

Almost all of the registers in the Itanium can be easily rotated for stack access (including floating point registers). General renaming logic requires time and more die space.

Has it occurred to you that perhaps it *cannot* get good enough?

I think this is a naive view. Compilers can get as good as we want them to. I think it is an easy out to say that the cannot get any better. Sure the idea has occured to me, and it may be true. However, I do think you are right in that it shouldn't be claimed that Itanium's performance problems are the compiler's fault. The compiler shouldn't be the scapegoat either way, but the technology should continue to improve.

Good post, you bring up good points, I don't know why you got moderated as Troll.

Re:Listen to Torvalds about making money

[Krieger]

> Intel is a company that time and time again proves > it knows how to make money. It may not always
> support the crowds it should (like /. readers and > superusers) but they are still making money.

Because the i960, which is a VLIW processor that Intel was trying to make was *so* successful.

Intel has made a lot of money, and frequently knows what to do, but also makes lots of blunders.

Witness the consecutive screwups with Rambus, the i820 chipset, and problems ramping the PIII in relatively recent history.

It is very likely that Intel has made a mistep with the Itanium, however their cash stockpile may just allow them to foist the Itanium on us anyways.

Re:Listen to Torvalds about making money

[jbischof]

I don't consider Rambus to be a mistake really, maybe a marketing blunder in getting people to accept it. ramping PIII? there was one missed release date, but they ramped it as far as they wanted to.

I do agree though, they make a lot of mistakes, but they still make money and do lots of things right.

Re:Listen to Torvalds about making money

[bobbozzo]

ramping PIII? there was one missed release date

Plus a recall. (on the 1.13GHz PIII Coppermine, IIRC.)

Re:Listen to Torvalds about making money

[bobbozzo]

Well, I hope it's worth more than that, as a 4-bedroom house in most CA middle class neighborhoods is $400,000+ now.

Not that I'm saying he's not "rich"... I don't know what he's worth on paper. I'm sure he's making at least $150,000 for Transmeta.

Plus, he can literally work at any company of his choice. That's gotta be worth something.

Now that was funny....

[biscuit67]

Next he'll be telling us the x86 instruction set is elegant! Ha ha ha ha! Risc has more advantages than just being closer to the 'hardware' it's also generally a more elegant instruction set. The x86 instruction set has barely any consistency (other than being crap). It is NOT elegant. It does not allow compilers to do much code optimization to utilize registers better (since it barely has any). For a good instruction set, check out the ARM. We have, unfortunately, been stuck with this dog of an instruction set due to intel. It's hideous. Next he'll be telling us that the ISA bus is the best thing since sliced cheese (or is it fondue), and that we never had any need for PCI etc etc etc.

Re:Now that was funny....

[bursch-X]

I'm afraid he did already, brrr
http://www.ussg.iu.edu/hypermail/linux/kernel/0302 .2/1909.html

ARRGH!

[pr0ntab]

Let me repeat this one more time:

NO GAMING CONSOLE IS 128-bit (nor will they be 256-bit)
The PS2 is a 32-bit system. It has a 32-bit wide address space and word space. It happens to have a quad-word SIMD execution unit. By this logic, the MMX-enabled pentium is also 128-bit.

Okay... got that out of my system.

What the 64-bit address space WILL do is make OS design simpler. This is an important win for developers. I understand OS start-up times will be vastly improved because applications, libraries, etc. will all be able to load at static addresses in memory, all precomputed. It'll also make database-as-filesystems easier to implement.

Forget gaming machines, this is BIG stuff, a big step, and Intel is foolish to ignore it.

Re:ARRGH!

[wayne606]

Check out what SGI is doing with the Itanium - http://www.sgi.com/servers/altix/index.html - with 64 bits and a very fast communication backplane (which they have) you can run huge multi-threaded computations using shared memory. On a 32-bit machine you have to use message passing and that's harder and less natural for some of these applications.

I know, you're saying "that's a tiny segment of the market compared to PS2's". But wait 5 years and the cool new gaming machine will be doing the same thing. A flight simulator that does a high-resolution compressible flow CFD calculation in real time - I'm sure that will sell a few copies.

Re:ARRGH!

[Queuetue]

A flight simulator that does a high-resolution compressible flow CFD calculation in real time - I'm sure that will sell a few copies.

I'm sure it will. Because of the gameplay, controls, graphics, action, music and price. Not because someone spent 6 months getting it physics-correct.

Re:ARRGH!

[0123456]

"Not because someone spent 6 months getting it physics-correct."

I think you underestimate the flight sim fans... it's not as though MS Flight Sim is known for its great graphics and gameplay.

Re:offtopic

[ATMAvatar]

Intel is a single entity, not a Star-Trek race.

Are you sure?

A Slashdot Sin...

[SleezyG]

I know it's not very nerd-like to say that Linus is wrong and that AMD sucks, but in the case of the Itanium, that is exactly how I feel. Intel/HP's Itanium architecture is perhaps the most advanced processor to hit the market and has tremendous potential (from a Computer Architecture point of view). Because it's so new, its performance will be aweful, but shall improve with time. Anyone remember the SuperSparc? It performed horribly and was soon replaced by the UltraSparc. As will the Itanium II replace the Itanium.

As for the emulation/legacy code argument, I say screw it. gcc is already ported to IA-64. And as a Linux user, most of my favorite open source programs can be ported with little difficulty.

Re:A Slashdot Sin...

[EvilTwinSkippy]

Well, except for all of those device drivers and low-level kernel routines that make assembler calls...

Re:A Slashdot Sin...

[SN74S181]

How many of the older crofty device drivers will matter?

Is there going to be Sound Blaster 16 support in the Linux Itanium kernal?

Re:A Slashdot Sin...

[phriedom]

Merced was due in '99, so IA-64 isn't really all that new and this isn't really the first generation. Having the best product doesn't matter very much if it is so late that a "good enough" alternative is already entrenched. Neither one of us is really dealing with Linus' point though.

I completely disagree

[Edmund Blackadder]

First of all it is not very smart to try to reduce code size by putting complicated instructions in the processor architecture.

A succesfull architecture may be used for 20 years, and there is no way you can know which complex instructions will be most usefull/popular in several years. And when you start making upgraded chips for a design, these complex instructions will be a real pain in the ass.

The x86 architecture is a perfect example - it is a mess and many of its instructions are not used at all. The x86 is succesful because the way history played out - it was put on the first pcs, and the incredible numbers of precessors sold allowed intel to put more development money into that architecture than any body else was able to put into theirs. And large initial investments, and large sales numbers mean that individual chip prices can be lower.

Nevertheless, the alpha and some of sun's chips can still compete with intel in the server environment, with much smaller investments and worse production technology. That basicly shows the weakness of the x86 architecture.

When you have multiple pipelines and multiple stages per pipeline the size of your chip will grow exponentially to the number and complexity of your instuctions. Eventually adding more pipelines will be pointless and then you are reduced to adding cache as the only way you can improve your architecture.

For a Risc architecture, multiple pipelines will cost less overhead and more can be used. Processor performance can be increased by adding more pipelines without having to increase speed.

Intel has the money and the clout to make a succesful risc architecture. It is brave of them to do it, but from an engineering point of view it is the only right thing to do.

AMD will support x86 because they do not have the clout to force a new architecture on the world. It is a completely understandable policy, but then again will result in worse performance (unless their engineers are somehow much more brilliant than intel's).

Of course the real world matters and in the real world almost everyone uses x86. But if someone can change that it is intel.

Re:I completely disagree

[EvilTwinSkippy]

Dude, you are forgetting about the MEMORY BUS.

Have a pipeline party for all I care, but the reason PC's have been historically slow has been because they use cheap RAM, and older IO bus techonologies. Open up an SGI from 1996 and you will see an SDRAM chip that PC's didn't start using until 1998. Look at an AIX box from 1990, and you'll see (gasp) PCI when PC's were running ISA.

What we learned with RISC is that creating smaller, faster instructions requires hitting the memory bus more often, negating most improvement in throughput.

And BTW Intel has had it's ears boxed in by customers before. Anyone remember the 80186. That chip did away with the goofy little endian addressing scheme. Since it broke all the software thusfar written for the 80086, sales plummeted until the release of the 80286, which reinstated little endian.

Re:I completely disagree

[Junks Jerzey]

First of all it is not very smart to try to reduce code size by putting complicated instructions in the processor architecture.

A small team of undergraduates can architect an FPGA solution that beats high-end Pentium 4s by a factor of ten for specific problems. They'd never be able to design a general purpose CPU to get the same performance, however. Similarly, the reason 3D video cards have leapfrogged CPUs in terms of performance is because the former is much more specific in nature.

The general trouble with desktop CPUs is that they're designed in a vaccuum, to do everything passably well, but nothing spectacularly. This is why you often see hig-end PCs struggling to keep up with $150 game consoles.

The definition of "complicated instructions" has changed drastically over the years. RISC nuts see a subroutine-call-with-stack-push as complicated, so they break it into a whole bunch of instructions. Other archictectures, such as the ARM, can do this in a single cycle. Floating point math is hugely complicated from a hardware point of view. You have to stick a giant shifter in there to normalize the results, and we're talking about greater than 32-bit mantissas with 64-bit floats.

Re:I completely disagree

[JollyFinn]

So your favourite chip wouldn't do any AI or anything like that. Its optimized software why game consoles do well, its all because software knows EXACT hardware limitations and optimizes for them exacly.

Floating point math is simple, scheduling instruction dependencies is not, and overdoing x86 flags dependencies is worse. (Unless you do it in software;)

Re:I completely disagree

[bobbozzo]

AMD..., but then again will result in worse performance (unless their engineers are somehow much more brilliant than intel's).

Don't forget the original Athlon kicked serious PIII butt, and is still keeping up with the P4.

Re: Offtopic, but another analogy

[bursch-X]

There's nothing wrong with inventing hammers, but while you're working on it you still use a rock to drive nails, rather than giving up building houses.

The problem with M$ is that their approach was more along the lines of:
"Rocks are out? Hammers are in? Let's make a Hammer!" and they went and built a hammer-shaped rock. duh.

I don't know much but

[cranos]

It seems to me that the AMD way is the smarter way. If you wanted to start porting apps to 64 bit architectures you would want as smooth a transition as possible.

Please keep in mind I know nothing about CPU design so I could quite possibly be talking out my arse here.

Re:the reason the Itanic is a bomb..

[ergo98]

Yes, they did have some ports of NT to the Alpha architecture didn't they. Except I hear they dropped that support after a while.

They also had support for MIPS, however a funny thing happens when the same software is available on different platforms: People gravitate to the platform that gives the biggest bang for the buck (which is why you don't see OS X for the PC: Apple has always basically been a software company that gets people to buy their hardware for the software, and if the same software was equally available on a more powerful, less expensive platform, you can be sure that Mac sales would dry up). It just so happened that among the CPUs that Windows NT targeted, the Intel platform won the battle, however if the battle had turned out differently, and Intel hit some sort of roadblock while the other chip makers stormed forward, I assure you we'd be using that variant of NT today.

Linus drank the kool-aid

[blair1q]

Torvalds is no longer to be trusted. His position as a profitmaking employee of a money-losing corporation nullifies his credibility.

Re:Linus drank the kool-aid

[NullProg]

Torvalds is no longer to be trusted. His position as a profitmaking employee of a money-losing corporation nullifies his credibility.

You have never met or heard Linus speak have you.

Enough said.
Enjoy,

Re:Linus drank the kool-aid

[EvilTwinSkippy]

I don't know. I'd wait until the 3.1 rev of the Kernel before I make an trastic statements like that.

Never forget this

[NDPTAL85]

Sarcasm is invincible.

didnt intel sell some rights.......

[doublehelix_nz]

....... to AMD to use its SE2 instruction set??/
IIRC they did, so Intel has everything thing to gain from AMD jumping in head first.

im sure intel (and AMD in 3years) could whip out a 10ghz cpu, at a cheep cost. but it wouldnt be economical (ie miss out 3 generations of CPU revenue)intel have many years of R&D under there belt... AMD are so young they are still using suspenders..........

d_h

oh yea, my reasoning is that the AMD 64bit, has twice the bits of a 32bit cpu, so it will produce 4x the heat :P:P

Re:didnt intel sell some rights.......

[vidarh]

Intel was founded 1968 and AMD in 1970, so what was your point about AMD being "so young"?

Re:didnt intel sell some rights.......

[bobbozzo]

Actually, AMD was founded in 1969.

Pretty funny . . .

[Anonymous Coward]

but this is like reading the comments after John Carmack has posted some remarks on graphics chips. There's always a rush of people to claim "I know its not trendy, but he's full of shit". Ah, the rebel without a cause . . . the problem being, of course, that there are some people who actually have accomplished significant achievements. These people, such as Linus or Carmack, will always get a listen from those of us who are less technically inclined because they have proven that they have at least SOME idea of what they are talking about, whereas the critics are nobodies.

After all, if you're so smart, how come you haven't done anything anyone else would notice? Or, put another way, the world is full of people who Know Better. These people will tell you, until they are blue in the face, that they Know Better. We can take their word that they Know Better, because they told us this themselves. But if you can't demonstrate that you Know Better where the rubber meets the road, then, well, you really don't have much to say, do you?

Does Linus know eveything there is to know about cpu architecture? Nope. He doesn't even know everything there is to know about Linux. But he does know a lot more than the average bear, and unlike the peanut gallery lurking on internet message boards, he has demonstrated that he knows a lot. If Linus doesn't like the itanium, that's a kick in the teeth to intel regardless of whether your imaginary compiler works a lot better on the itanium than on x86.

Re:Pretty funny . . .

[The_Dougster]

but this is like reading the comments after John Carmack has posted some remarks on graphics chips. There's always a rush of people to claim "I know its not trendy, but he's full of shit". Ah, the rebel without a cause . . .

I know enough to know that Linux, Carmack, and Stallman know way more about their respective fields than I ever will. But having used their things, I know some subset of it. I have run The Hurd and compared it to GNU/Linux and, well, frankly Linus is right. Linux works better now than Hurd does, and really thats what matters. You take what works and use it. Sure, I can toy with Hurd for some exotic computing occasionally, but when it comes to surfing, emailing, slashdotting, or fragging, I'm booting to Linux (Debian Woody, for that matter). You have to use the best available stuff or else you are stupid.

Yes, I can get all visionary and idealistic too, I like the underdog. For me its Hurd, for you it might be BeOS whatever. When I'm at work, I'm running Windows2000 because thats what I have and thats what I have to use, and frankly, its proper for a corporate environment if they could ever figure out how to get the damn server configured properly. [pant pant... ok mellow... mellow]

Yeah. There's a lot of rebels on /. for sure. The Linux kernel is dead! Long live the Linux kernel!

Just a little confused

[AHumbleOpinion]

the fact that linus works for a chip maker doesnt really matter because he dosn't develop the chips. he gets paid there to develop the linux kernel.

"he gets paid" is the key point. If the chips don't sell he doesn't get paid.

Re:Just a little confused

[NedTheNerd]

but what does it matter itanium is part of a totaly difrent market than what itanium is targed at Itanium = overpiced servers and poor software compatablility transmeta = small cheap cool long runing laptops

Re:Just a little confused

[AHumbleOpinion]

It's the companies not the chips. Since Intel's mobile pentiums threaten the existence of Transmeta a Transmeta employee may be a little biased against Intel itself and any of Intel's products. Human nature.

Re:Just a little confused

[NedTheNerd]

unless if your more like me and dont really have loyalty to anything :). I can see where your coming from. It just seems to me like he is the kind of person that would try to rise above basic instincts and give it an honest review. I might think his opinion is biased if I knew he worked on their chips as of now I don't think he does.

Re:Itanium2 is the fastest floating-point processo

[blair1q]

The fact that the benchmark is tuned to run the benchmark is tautological. Of course it is. That's no argument. As compared with prior attempts to optimize hardware for a specific software usage, this is the best ever.

Actually, as I think about it...

[The_Dougster]

What they ( both AMD and Intel ) should do is set up the cores so that in 32-bit mode you get Symmetric Multiprocessing (SMP), but you could couple the cores for 64-bit mode.

Man I am so smart I think I'll grab another beer and gloat about it.

Deerfield

[Hythlodaeus]

Present Itanium offerings are not competing in the same market as Opteron. Opteron is positioned in the Xeon domain. Deerfield - the low-wattage, low-cost version of the Madison Itanium2 core - will be the bellwether for IA64's market penetration outside of very customized supercomputing jobs. It is on Intel's roadmap for Q3. If Intel's conception of "low-cost" coincides with real peoples' idea of low cost, IA64 could within a few years take a signifigant share of the Xeon market segment, where it can sit comfortably until software vendor acceptance grows to the point that IA64 can become a mainstream desktop option. People focus on Intel saying "no 64 bit desktop until 2007" while forgetting that they are intending IA64 not x86-64 on the desktop later in the decade.

Linus..

[irabinovitch]

Ya, but he works for trasmeta. If he were trying to pimp the company he works for he'd be pushing some Transmeta chip not AMD's stuff. Then again I could be wrong and there could be some connection between AMD and Trasmeta or some "The enemy of my enemy is my ally" type of deal.

Re:Linus..

[vidarh]

Read the article, will you. Transmeta has licensed AMD's x86-64 technology, and thus have everything to gain from low market acceptance for the Itanium.

Re:Linus..

[irabinovitch]

Ya, I noticed that this morning when I reread the article.

Microsoft will decide the outcome of this battle

[RelliK]

Without Windows for x86-64, AMD is dead. No, Linux will not save it. However, the moment Microsoft releases Windows for x86-64, Itanic is history. The market will overwhelmingly favour x86-64 because of the much lower price (I expect at least 3-4 times lower, cosidering that the Itanic CPU alone sells for over $3000), and perfect backwards compatibility. Itanic's ia32 support is so pathetically slow that it may as well not exist, so a move to Itanic requires you to replace _all_ your software, which ain't cheap, while x86-64 allows you to do incremental upgrades. So, taking simple economics into account, Itanic will go the way of that ship and AMD will emerge the winner... provided there is a version of Windows for x86-64. Without that there is no point of talking about "64 bit desktop" market because it just won't exist. So what is Microsoft doing?

Re:Hee hee hee... I just bought an AMD system!

[davidstrauss]

You might want to look into a Radeon 9700 Pro. Your old card is probably a major bottleneck for gaming. New Total System Cost: $900.

That's just the beginning.

[Rimbo]

Sometimes, just becomes someone HAS an economic interest in something, and IS interested in seeing something fail/succeed, does not automatically invalidate the point he/she makes. Linus didn't just put forth an unsubstantiated rumor or point of view; he backed his points up with facts and reasoning. If he is biased, show facts and reasoning to counter the bias, or else you are no better than the FUD-mongers when you write him off.

Question

[Perekkiofono]

With Itanium will my volume slider on XP box, opens in less than 5 sec ?

Do we...

[t0ny]

If you get, for example, a 64 bit AMD processor, do you need to run softare compiled for that processor?

Linus is too young to remember

[imnoteddy]

From the article:
Torvalds wrote that Intel had made the same mistakes "that everybody else did 15 years ago"
when RISC architecture was first appearing.

RISC first showed up on the commercial radar screen almost twenty years when MIPS Computer Systems
was formed. But people at Stanford (and Berkeley, IIRC) had been publishing papers about
RISC for four or five years before that, and people at IBM were working on it even before that.

And the CDC 6600 was a RISC machine in the 1960s. If you don't believe me, ask Cray's Chief Scientist Burton Smith.

In seeking the unattainable, simplicity only gets in the way. -- Alan Perlis

Re:When is the...

[sweetooth]

Yeah, that's a given. I was just trying to point out that the Crusoe is already a 128 bit processor. So you won't be seeing a 64 bit Crusoe any time soon. Maybe a Crusoe executing instructions intended for an X86-64, but that's just an extension of the code morphing software. Even then I think the new astro chip would be more likely for that application since it looks to be meant for high density low cost blade servers with more punch than the Crusoe.

Why the AMD logo?

[Psykechan]

Some guy from Transmeta badmouths Intel's new processor and Slashdot files this under AMD?

I know that AMD has something to gain here but shouldn't this be under a different topic? Maybe when it gets reposted it'll be correct.

Linus is right

[g4dget]

In addition to problems with code size and price, the fact that code generation for it appears considerably harder than for Pentium and that it effetively doesn't offer useful backwards compatibilitly make it a very undesirable chip.

64bit is very important in my opinion, both on the server and on the desktop, but not at any cost. And the cost with Itanium is simply too high.

Uggh....what does really matter?

[zerofoo]

Who is Itanium good for? Who is G4 or Power4 good for? What is X86 good for?

That's like asking what is a saw, hammer and screwdriver good for...they each have an application.

All these architectures have their good points and bad points. I've written sparc and x86 assembler and I can't say that they are better or worse than each other....just different.

At this point the hardware is MOOT. Unless algorithms get significantly better soon, the hardware won't matter. Sure, we'll get mega memory address space with any 64-bit architecture, but what does that get you? More memory address space? Big deal...so you've got big memory space...that won't make NP=P any time soon.

-ted

x86-64 is not a simple recompile

[TFloore]

It is still a full port, if you want to get the benefits of the 64-bit architecture. If you want to keep running 32-bit x86 code, don't even bother recompiling. But don't make the mistake of thinking that switching 32-bit x86 code over to x86-64 is a simple re-compile.

It is still a port, with all that is included in that awful word.

Do you understand how little 64-bit safe code there is that runs on 32-bit x86 systems? Most of the linux kernal is already 64-bit safe, because it has been ported to so many other 64-bit architectures already. And it still wasn't a simple "just recompile it".

Speaking specifically to C programs here, porting from 32-bit to 64-bit is not a fun process. A variable declared as "int" switches in allocation size. This is good and bad.
fread (fp, sizeof(int), &var); //(forgive me if I have the parameters backwards, I'm doing this from memory. And notice that I'm a bad programmer, I didn't check the return value.)
Congratulations, you just killed all your existing data files. And if you happened to read a 32-bit pointer from that data file (any structures that you write directly that contain a pointer write a pointer... you'll throw the pointer value away when you read the structure back in, but you still have to read the proper data size), and then assign a pointer to it... Oh, you're going to have all sorts of fun playing with that.

Yes, this may only be an issue with "bad" C code that assumes it will ever only run on a 32-bit platform... That probably covers 99% of all x86 C code out there, for any OS you care to name.

Don't pretend it will be easy moving from 32-bit x86 to x86-64. For most programs, I assure you, it will be non-trivial. Anything that does direct memory allocation will have to be checked very carefully. Anything that does binary file i/o will have to be checked very carefully. Oh, and anything that uses "magic" numbers will have to be checked... Have you ever used an if conditional for an int of the form
if (i == 0xFFFFFFFF)
congrats, you just assumed 32-bit for your architecture.

64-bit clean code is the exception, not the rule.

Re:x86-64 is not a simple recompile

[psamuels]

Speaking specifically to C programs here, porting from 32-bit to 64-bit is not a fun process. A variable declared as "int" switches in allocation size. This is good and bad.

You had me until that part. While it is technically possible for a compiler and runtime environment to use a 64-bit int size, I am not aware of any that actually do. Precisely because of portability problems with legacy code. Instead, the common convention (which I know is used in HP-UX, Digital Unix, Linux and IRIX, and probably most other 64-bit platforms as well) is that an int is 32 bits, and a long int is 64 bits, as are all pointer types. (This is known as the LP64 model.)

The three biggest 32-bit-isms / portability problems I've seen: (a) assuming you can stuff a pointer value into an int (correct answer: either use a union, or (as seen in the Linux kernel) a long int); (b) [not strictly a 32-bit-ism] ignoring alignment issues which may exist for anything bigger than a char; (c) not handling sign extension properly in implicit casting (on 32-bit platforms such casting often doesn't change the word size).

Re:x86-64 is not a simple recompile

[radish]

I knew there was a reason I was a Java programmer...

Re:x86-64 is not a simple recompile

[TFloore]

While it is technically possible for a compiler and runtime environment to use a 64-bit int size, I am not aware of any that actually do.

Hmm. Okay, thanks.

I couldn't remember if I had issues with "int" on a 64-bit platform because it wasn't the "natural word size" of the platform (and therefore wasn't the same size as a pointer there) or because it changed the data type size and screwed up my reads. Thanks for correcting my crappy memory. (I had issues with data type size with logicals in fortran, but I tend to think that was a compiler error because it changed between compiler versions on the same architecture as well as between architectures. Guess I was thinking of that.)

Incidentally, I have issues with a 32-bit "int" on a 64-bit platform. An "int" should be the natural word size of the architecture you are running on. If you want a 32-bit int explicitly, use a specific variable declaration for that size. If you want a 64-bit int, use a specific declaration for that size. If you want natural word size of the architecture, "int" should give it to you. Yes, this can make porting more difficult... so learn to use "short int" when you want 16-bits, and other variable declarations to explicitly note required data types.

Hmm... http://www.opengroup.org/public/tech/aspen/lp64_wp .htm gives a nice description of LP64 and other 32/64-bit programming models. Thanks for making me go look at it again. (Can you tell from the above paragraph that I'm really used to ILP32?)

And while you're correcting my mistakes... Is __int32 and __int64 portable across platforms/compilers? I never can remember.

Re:x86-64 is not a simple recompile

[JCMay]

Have you ever used an if conditional for an int of the form
if (i == 0xFFFFFFFF)
congrats, you just assumed 32-bit for your architecture.

That's why you do a "if(i==~0)" instead!

Re:x86-64 is not a simple recompile

[smallpaul]

Many programs were ported to 64bit years ago for Itanium et. al. AMD can't make the porting process go away, but they can make it as easy as possible by keeping the instructions the same.

Re:x86-64 is not a simple recompile

[greed]

I couldn't remember if I had issues with "int" on a 64-bit platform because it wasn't the "natural word size" of the platform

Kids these days.... :-)

I remember the fight between one compiler vendor who had sizeof(int)==2 and another who had sizeof(int)==4 on the same CPU, the same OS. The first one argued that the external data bus was 16 bits, so it was a 16 bit machine, 16 bit ints. The other said the register file is 32 bits wide, so 32 bit machine.

They're both bust and people use GCC now, but sizeof(int) isn't a new problem for C.

This time people thought about compatibility a lot more. And several compilers have flags to warn you about 32-64 portability issues when compiling on 32 bit, so the core-dump isn't as big a surprise.

Re:x86-64 is not a simple recompile

[DeadInSpace]

Yes, this may only be an issue with "bad" C code that assumes it will ever only run on a 32-bit platform... That probably covers 99% of all x86 C code out there, for any OS you care to name.

For any OS I care to name? I daresay that a lot of software for GNU/Linux is 64-bit clean. Not all software ofcourse, but certainly more than one percent.

Don't forget that GNU/Linux and it's software is ported to and actually used on a large number of platforms. Consider Debian GNU/Linux; it's latest release (3.0 aka Woody) has 8500 packages, for a total of 11 architectures, which includes 32 and 64 bit architectures in various endiannesses too. And all the 8500 packages (give or take a few, some are platform-specific) are compiled for and tested on all those architectures.

The same goes for NetBSD, FreeBSD and OpenBSD; it's the same software that runs on it.

Re:x86-64 is not a simple recompile

[craigwilkie]

I remember the fight between one compiler vendor who had sizeof(int)==2 and another who had sizeof(int)==4 on the same CPU, the same OS. The first one argued that the external data bus was 16 bits, so it was a 16 bit machine, 16 bit ints. The other said the register file is 32 bits wide, so 32 bit machine.

What about the Analog Devices SHARC, where: -

sizeof(long) = sizeof(short) = sizeof(char) = 1,

but they are all actually 32 bits.

Re:x86-64 is not a simple recompile

[cras]

That's why you do a "if(i==~0)" instead!

Or if (i == (unsigned int)-1)

Re:x86-64 is not a simple recompile

[JCMay]

But how long is an int? Not knowing the type of i, but wanting to check to see if *all* its bits are set to 1, would not my solution work better?

Re:x86-64 is not a simple recompile

[cras]

Well .. Problem with ~0 is that it's pretty much the same as just using -1. In both cases you're comparing signed integer to unsigned integer. ~0U would then be same as (unsigned int)-1 again. Also ~ probably isn't fully portable with signed integer types.

Re:x86-64 is not a simple recompile

[lavv17]

There are other 64 bit architectures that linux already runs on just fine. And most programs included with ix86 linux distributions also work on 64 bit archs (e.g. alpha).

There are quite easy guidelines on how to write portable programs, and most good programmers follow it, just because it is right thing to do. Of course, shit happens and without testing on different platforms (be it 64/32 bit issue or big/little endianness) it is almost impossible to guarantee that a program will work on some random platform.

Fortunately, in open source world people can fix problems arising on a new cpu/platform even when the author(s) does not have access to that platform.

Re:Hee hee hee... I just bought an AMD system!

[The_Dougster]

You might want to look into a Radeon 9700 Pro. Your old card is probably a major bottleneck for gaming. New Total System Cost: $900.

Nah. Using an nForce2 chipset I'll go with an nVidia option. I happen to have a GeForce4MX-440 DDR AGP 8X card here that will probably work for now. I always buy older graphics cards because I don't use Windows. Therefore I wait a year, the price drops, and the Linux drivers materialize.

Heck, I was cutting edge Linux OpenGL way back when... I compiled Mesa 2.6 for my Voodoo2 and was rocking with Quake2 years and years ago. Ah those days of yore...

Re:Microsoft will decide the outcome of this battl

[Rudolf]

So what is Microsoft doing?

I don't know about "x86-64" but Windows XP is currently available as a beta release for Itanium 2, according to
this HP site.

Re:Microsoft will decide the outcome of this battl

[Ozan]

So what is Microsoft doing?

According to this table nothing..? Unless MS refers to x86-64 as Itanium technology.

Re: *I* need 64-bit to use more RAM for...

[Frobnicator]

You say you need more than 4GB for video editing and 3D rendering?

Sorry while I rant, but you just stomped on one of my nerves. (Unless your comment about neededing that much RAM was a complaint about Adobe or their direct *cough* compeitors -- sucks to be you.)

<Old Geezer Mode> In one case, not long ago, a fellow lab-rat Eric Mortenson had sold his research and tools to Adobe, but part of the poorly-written agreement said that he couldn't upgrade his work station. So he finished his Ph.D on a 386 with 32-MB of RAM, while the rest of us in the lab were using Pentium 3's, DEC Alpha's, and various SGI boxs. Eric's algorithms ran great on the newer PC's even though he couldn't develop them on the new boxes. Other with Adobe (NOT on that web site interestingly enough) needed the DEC Alphas (64-bit machines) with scads of memory and much more running time to do a similar implementation of Eric's algorithms. </Old Geezer Mode>

3D rendering doesn't take that much RAM. As a 3D graphics researcher and developer, I have worked with models where individual objects were multi-gigabytes (meshes+textures and volumes) but even then, having 1GB of RAM was more than enough for us to reach 20-30 FPS realtime on a box with NT4 and first- and second-generation 3D cards. Software rendering with very realistic detail was a little slower (3-5 fps) but was fine for writing movies. Progressive geometry & texture transmission, continuously calculated view-dependant detail levels, and other current and not-so-current research would solve the memory problems in 3D. Don't believe me? Go to Visualization 2003 and see if the leading researchers are finding RAM as their primary bottleneck. It is a bottleneck of course, but processing speed, caches, and the system BUS limitations are far more troubling.

As for video editing, you only need enough memory for the tools, a few frames, and whatever operations you are performing. In every case that I've had to do video editing, I've seen two classes of tools -- those that take gobs of memory and try to copy the entire video clip into RAM and end up thrashing for memory -- and those that intellegently figure out what is needed and use only the memory needed for the app.

An example of the first, an Adobe AfterEffects rendering a simple math function over time was only able to render 30-seconds because it wanted to buffer the AVI file in memory and ran out of RAM (2GB) after a several-hour rendering. An example of the second, a simple home-brew compositor that used the Windows multimedia API to write the AVI to disk -- the same machine and the same set of images required about 45 minutes to render the entire clip.

So instead of saying:

I need more than 4GB RAM (3.5 if I want it stable) for video editing and 3D rendering.

I would suggest you say " I need to buy tools that are properly designed and implemented for my class of computer. "

Frob.

Re:Microsoft will decide the outcome of this battl

[mudrat]

It would be very risky for Microsoft not to provide a version if windows for x86-64. Microsoft are already facing major competition in their server market from free *nix. If they allowed the competition access to free reign on a very fast and powerful architecture, they would be taking a major risk.

Microsoft need to weigh up development costs against the risk the *nix/x86-64 will become very popular and decide whether its worth their while to compete with a version of Windows. I would guess it is.

Wasn't it desktops that put Intel on top?

[xixax]

> Probably not, but a lot more desktops get sold
> than high-end servers. If AMD manages to get
> a toe-hold on the desktop with their 64-bit
> solution, the chances are a lot better x86-64
> will migrate up the food chain than ia64 will
> migrate down.

After all, isn't this also one reason why we are looking at x86 everywhere instead of a world filled with Sparc/Alpha/PPC? Intel could offer x86-64, but how much smller would their Itanium market be? Quite a dilemma, they would need to hurt Itanium sales to keep the desktop.

Are they selling the bread to keep the silver on the table? (not my quote)

Re:the reason the Itanic is a bomb..

[JWSmythe]

Ok, I'll confess. I was one of the WinNT 4.0 Alpha users.. This was years ago, when WinNT 4.0 was current, so excuse my memory if I have some little details wrong.

I worked for a hosting company that wanted to migrate from BSDi to Windows ({sigh}).

The boss heard that DEC Alphas were fast, and they'd run either OS, so he bought 8 Alpha workstations, and one Alpha Server.. (It's been years, don't ask the models). I believe the AlphaServer was 500Mhz, and the workstations were 333Mhz, but I could be mistaken.

So, we ran Digital Unix on them for a while. Then pulled them out of service and started putting WinNT 4.0 on them..

Windows was pathetically slow on those machines, in comparison to them with Digital Unix, or in comparison to my Pentium 133Mhz workstation. Even in comparison to Pentium 166Mhz machines running BSDi 3.0, the Alphas were very slow, even though the Alphas were stuffed full of memory.

They were too slow to do anything significant with. I believe all the workstations were put into service as PDC and BCD's.. The AlphaServer was left in service as a Digital Unix fileserver.

As I remember, Microsoft had a falling out with Digitial, and Microsoft dropped the support for the Alpha's.. If I remember right, they stopped supporting them at WinNT4 Service Pack 3.

I *BELIEVE* all the Windows software was ported to Alpha. Everything else had to run through an emulator that they included. Well, it tried to. Most programs would crash it, or hang the machine. I don't know what to blame, Windows, the Emulator, or Digital. :)

I was never particularly fond of the DEC Alphas. I didn't like Digital Unix much at all, and the power-that-be wouldn't even let me consider Linux on them.

I didn't stay there long. I got into a shop changing FROM Windows to Linux.. We're a happy Linux network now.

Re:Why 64 bit

[Inspector Lopez]

Already been done. Check out the Harris H-series computers, which have a 24 bit single precision int and a 48 bit long int.

It's a fine, fine system, in which single and double precision floats take up 48 bits, but have different precision.

You'll be especially happy to learn that the OS was called VOS for "Vulcan Operating System." The peripheral model was that "everything is a tape drive" which means that you can rewind your files.

MIPS is not dead

[EvilTwinSkippy]

I'm looking at a very popular MIPS based architecture that is in 40 million households in the united states.

That would be the Playstation 2.

Throw in the playstation 1 and we might be up to 100 million.

Re:MIPS is not dead

[AlainSchr]

Were speaking about 64 bit here...

The Playstation 2 MIPS processor uses a 32bit core, as the Playstation (1) does. btw. The MIPS processor in the Playstation (1) does not even have an MMU.

And that MIPS is still alive in the embedded area is fact, beside that ARM is far more successful.

Re:MIPS is not dead

[EvilTwinSkippy]

Granted, the point I should have been trying to make is that Processors are not all things to all applications.

The fact that you CAN drop all of those functions into a giant coffee heater in the center of the board, doesn't make it a great idea. That is, unless you also include the RAM (like IBM mainframes do.) And even then, if you have a highly I/O based application, you really don't need a beefy CPU. You just need a traffic cop to watch the bus.

Sometimes it affects point of view

[Galvatron]

I don't think many were proposing that Linus was attempting to manipulate us for his own ends. However, sometimes the work you do can influence your thinking.

Take my grandfather for example. He worked as a transportation lawyer, back in the bad old Interstate Commerce Commision days. The ICC was created to regulate railroad monopolies, but was eventually coopted by the railroads to keep out trucking competition. In order to establish a new shipping route, you needed to prove to the ICC that there was a "need" for this new shipping route. Clearly, it was an absurd, anti-competitive system. My grandfather retired shortly before the industry was deregulated. However, to this day, he still believes that the ICC was a good thing, because being dependant on its existance for a job made him a believer.

The point is, when you have an economic interest in something, it can start to affect how you think about things. The wealthy tend to want tax cuts, and the poor tend to want spending increases, but most of them are probably not conciously supporting those positions for their own selfish ends. They truly believe that what's good for them is the right thing for everyone, it's a natural justification process for humans, and I wouldn't think less of Linus for the tricks his subconcious might play on his mind

Re:Sometimes it affects point of view

[phriedom]

You make a good point, and it is well thought out and expressed. It is possible that Linus is biased and isn't aware of his bias. However, you are still just saying that he MIGHT be biased, without actually dealing with the substance of his arguement, or showing us any evidence of bias. That seems like unfair criticism to me.

Now to all of slashdot I would say, "Be aware that Linus works for Transmeta, go ahead and look for bias, but don't allege it unless you have good reason." But thats just my opinion.

Baroque

[Galvatron]

See here. First definition, third entry. Reprinted below:

Extravagant, complex, or bizarre, especially in ornamentation

Re: *I* need 64-bit to use more RAM for...

[DunbarTheInept]

The stats you quote are meaningless without the resolution and color depth given. 20-30 FPS at 320x320x16 is a totally different animal from 20-30 FPS at 2048x1024x256, for example, and the difference is precisely in memory usage.

Re:Itanium2 is the fastest floating-point processo

[EvilTwinSkippy]

I worked for Kulicke and Soffa for a few years in College. One of our products was a large bonder that they were planning to buy because NOTHING ELSE COULD ACCOMODATE A CHIP THAT SIZE.

It's like the damn Space shuttle. The only reason it is that complicated is because it wasn't all that well thought up in the beginning. Intel has historically been known as the first with the worst.

Now if only Motorola could save us now...

Re:go AMD

[arose]

That's GNUAMD. TLA belong together.

Depends on your point of view if Itanium sucks

[demachina]

The key point about Itanium is that it is a horrible general purpose processor but it is a serious contender to be very good processor for supercomputing. It has very good floating point performance and the EPIC architecture is designed to be very good on Fortran, especially vectorizable Fortran which is very prevelent in HPC applications. What Linus said is correct in the context of Itanium as a general purpose processor, but its doesn't give Itanium the credit its due as a floating point supercomputer which is the only place its going to sell and is what it was designed for.

It will probably never be very good for most C and C++ apps. Pointer aliasing in particular will give the Itanium compiler fits. Unless you manually tell the compiler there are no two pointers accessing the same memory the compiler can't safely or effectively pack the parallel instructions in the VLIW and that is the essential to good performance in VLIW.

You do have to really question the sanity of some execs at Intel and HP for spending the staggering sums they've spent on Itanium. Supercomputing just isn't big enough a market for them to have any chance to recoup their investment in our lifetime and they aren't going to sell it in to the mass market as Linus said.

For a general purpose 64 bit processor to run existing C and C++ applications AMD is going to win hands down. But as many have noted its not likely most people are going to really need a 64 bit processor anytime soon so Intel will probably do just fine selling 32 bit x86 processors for a while.

Behavior changes belief

[jbolden]

One of the more interesting things in psychology is the attitude people have towards their beliefs. What they think they do is:

a) evaluate a situation
b) come to a conclusion
c) act on that conclusion

In reality what they tend to do is:

a) evaluate a situation
b) act on that evaluation
c) derive a conclusion from the action

Could you imagine...

[krray]

With the Power5 coming from IBM ... and if, only if, Linus took that job offer by Jobs. Not his gig, that's cool.

We came this close }.{ to having Mac OS X being Linux based... We'd all be singing, "It's a Mac world after all.."

Either way ... the Power5 will be running my next Mac (G4 being my first :) and I can't wait to sink my Linux teeth into it too. I'm also very interested in what BSD will do on it...

Windows? Nah. I'll let Mickey try it. He'll use anything. I wonder if IBM will let Windows even run on it? Oh the games they could play... Lotus, Quicken , shall I go on?

Re:Could you imagine...

[SN74S181]

We'd all be singing, "It's a Mac world after all.."

Now you're sounding like a horror flick made in Disneyland.

What was that about Mickey??

Re:Microsoft will decide the outcome of this battl

[hxnwix]

Using the 64 bit question as leverage against intel by hinting it favors one architecture or the other from time to time.

And what if MS pulls a dos 6.0 and sits on the 64 bit question for years, insisting everyone fork out for the new millenium's dos4gw. Do you think people would stand for it? Screw segmentation, even if the kernel does it transparently. I'd rather walk my grandmother through a netbsd install on an sgi crimson via postcard than code with segmentation in mind again. It's not freaking nineteen nintyone anymore.

Think Server Storage

[EXTomar]

One application where 64-Bit addressable would be welcomed in open arms is server application. If you can directly map gigabyte drive arrays you skip some of the hit on the OS level of doing something else to calculate offset. While it maybe dubious to make desktop applications 64-bit addressable things like databases and drive drivers would benifit from the full support.

price?

[jbolden]

I don't follow your logic here. I don't see how implementing complex routines that the microcode is going to have to turn into lots of instructions in the CPU is any better than the current system. Also with these gigantic libraries I'd assume the chip yield would be tiny.

I don't see how this makes sense from a price / value perspective. What's the advantage?

Intel and Microsoft

[jbolden]

Intel killed Alpha

I agree with most of your post but this line deserves comment. Dec hurt Alpha and Compaq killed it. It was Dec not Intel that couldn't decide if they were supporting NT x86 boxes or low end Alphas. It was Dec not Intel that wouldn't bring the cost of the GEM down. It was Dec not Intel that didn't address the memory cost issue.

It was Compaq not Intel that told the Alpha customers that Alpha had no future. Intel did the opposite and violated a ton of patents because they thought there were great ideas in Alpha architecture.

Intel and Microsoft often get the blame / credit for their competitors dropping the ball. Dec/Compaq killed Alpha and IBM killed OS/2.

ISA and cheap memory bus

[jbolden]

Don't forget this was an accident. Originally IBM had pushed for Microchannel would have solved the bus problem. The clones killed IBM and it took years for the PCs to get reasonable bus standards (essentially Intel took IBM's role over).

Re:ISA and cheap memory bus

[drinkypoo]

Microchannel sucked too, it had the same problems as eisa, you needed stupid configuration floppies all the time. A bus needs autoconfiguration, and in that sense, NuBus was superior even to EISA (NuBus was only 11MHz though) but really my favorite bus is the Amiga's Zorro III, which I seem to recall being fairly quick, and the OS did autoconfiguration by loading software drivers from adapter memory and executing them as user space processes, the same way as it loads routines from its internal ROM (whence is loaded half the OS, most of the windowing routines and such.)

Driver updates are in the form of patches; you boot, and then you run the patch util which uses the OS' Patchlist functionality to make clean trap entries. Ahh, AmigaDOS, we loved ye so well, and C= mismarketed your home into nothingness. Those bastards :(

Re:ISA and cheap memory bus

[greed]

I don't recall ever needed configuration floppies on an RS/6000 for the MCA bus. The operating system and bring-up hardware would manage interrupts and memory allocation. If the adapter had any specific customization, you did it through "smit chdev" or just chdev -l tr0 -a ring_speed=16 oops what's that still doing in my brain....

Re:ISA and cheap memory bus

[drinkypoo]

Unfortunately, I supported a wide variety of 286-based PS/2 systems (and a few 486-based PS/Valuepoints) in a token ring environment using IBM 4mbps token cards. We also had four or five 386s. Anyway, when you changed hardware the PS/2 PC BIOS wanted floppies to do configuration.

I'm glad they did a better job on the MCA RS/6ks but they didn't do a very good job in PC-land.

Re:Microsoft will decide the outcome of this battl

[SN74S181]

Microsoft can provide a Server OS for Itanium and x86-64. They can balk on providing a desktop OS for either architecture.

Doing so, they can let the market shake out which processor, or both, is best. However, most people seem to agree (I am NO expert to have an opinon on the matter) that Itanium will be better than x86-64 as a server CPU. Why drag along the legacy x86 stuff for Server platforms where compatability with Fred's ancient shareware crap isn't needed? 'Legacy support' is largely a Desktop issue for Microsoft. Cuz they don't have a hell of a lot of a server legacy.

Not quite

[Rui del-Negro]

There are two issues here:

1. There is no difference in the speed it takes to transfer data, because the bus is wider. There is also no difference in the time it takes to process data, because registers are also wider. There is a decrease in cache performance (because addresses take up more space). All other things (CPU design, clock speed, etc.) being equal, this hit would be of about 5%. It would only apply to programs running in 64-bit mode, though (the Hammer can still run in 32-bit mode, and can use 8, 16 and 32-bit pointers even in 64-bit mode, in certain instructions).

2. AMD's x86-64 Hammer doesn't just increase the register size to 64 bits. It adds several new registers, that can (with minor adjustments in the compilers) give a pretty good speed improvement (I'd say about 10% for the same clock speed, although this will depend a lot on the specific program). It also improves the prefetch and adds SSE2 support (one of the few areas where the P4 has an edge). This should give the Hammer approximately a 20-25% improvement over an Athlon XP at the same clock speed (more, if SSE2 is used).

RMN
~~~

Re:Most home users run Windows.

[jbolden]

Apple may have 64 bit workstations in ~ a year.

IBM has set the release date for the i970 at 2nd quarter 2003, mass production for 3rd-4th quarter. We could be seeing 64 bit apples in 4 months.

That's not the issue

[Rui del-Negro]

The problem is... if you give a Xeon 3MB of cache and a 64-bit memory controller, it'll sink the Itanic without breaking a sweat.

Which is why Intel can't release a 64-bit desktop chip to compete with AMD and IBM: they'd kill their own Itanium sales. IMO, they are going to regret this; they are giving AMD and IBM a very big opportunity. If Intel released a 64-bit Xeon, they would lose some money, but AMD and IBM would lose a lot more. As Microsoft knows very well, in the long run, keeping your competition under control is more important than maximising your profits.

RMN
~~~

Re:Itanium2 is the fastest floating-point processo

[scotch]

"Complete bullshit" == "+3: Informative" on Slashdot. People that buy Itaniums and the like frequently care about SPEC* because cpu intensive applications frequently behave like some combination of those numbers. If all you care about the Desktop you can keep your Quake3 and Photoshop benchmarks. (Not aimed at you, more to granparent).

Does it run Windows?

[BagMan2]

That's the real key. Now days, recompiling well written software for different CPU's is trivial, provided the OS API is the same. If Windows runs on an Itanium well, I can likely just recompile my software and be done. If it can emulate 80x86 well enough to let me run old Windows programs, that's game-set-match.

I realize /. doesn't like the view of the world through Microsoft colored glasses, but that's the reality that is out there. If it runs their software quickly, users couldn't care less about what the CPU type is, and that includes high-end server applications as well.

Re:Does it run Windows?

[vidarh]

And provided that your app will work cleanly on a 64bit architecture, which is certainly not a given (int vs pointer size assumption and alignment issues being common problems).

ITANIC?

[Hugonz]

Only just falling short of calling the processor Itanic

Well...you just did. Trying to help Linus?

Re:the reason the Itanic is a bomb..

['The '.$L3mm1ng]

when have you ever seen or even heard of any actual user software for Windows/Alpha

Miranda, an excellent ICQ client (with support for other protocols, even the Windows network messaging service, via plugins), has been avaible for WinNT/Alpha for quite some time.

Why is Linus always on the wrong side of debates?

[Anonymous Coward]

Does Linus really get off on trolling or something?

I guess you can attribute his anti-Itanium stance to the fact that he collects his paycheck from an x86-64 licensee, but that wouldn't explain all the nonsense he spouts on the gcc mailing list, his opposition to kernel debuggers (because people who use debuggers aren't 31337 enough), etc.

The fact of the matter is that the Itanium line delivers superior performance at a lower price than its competitors, while maintaining that elegant architecture that Linus decried.

CISC doesn't make programming easier

[Trepidity]

Well, CISC makes programming a compiler easier, yes. But you only have to do that once. The idea here is that a RISC chip with a horribly complex compiler is a win over a CISC chip with a simple compiler, because the compiler can do a lot of stuff at compile-time, using a big window (the entire program if necessary), while the CISC chip has to do everything at run-time using a small window (the current instruction plus any lookahead). This makes deep pipelines increasingly slow. Sure, it's a gigantic pain in the ass to properly order instructions for pipelining, but the compiler is in a better position to do this efficiently than the CPU is (and what's more, it only has to do it once, instead of at run-time).

Re:CISC doesn't make programming easier

[J. Random Software]

A microengine can take full advantage of all hardware resources that are actually present (register renaming, out-of-order and speculative execution, known pipeline depth) while a compiler can only use resources that are mandated by the instruction set. As for the drawbacks of having the instruction scheduler on the critical path (which imposes the window limit), Transmeta may be on to something....

Re:the reason the Itanic is a bomb..

[psamuels]

Windows was pathetically slow on those machines, in comparison to them with Digital Unix, or in comparison to my Pentium 133Mhz workstation. Even in comparison to Pentium 166Mhz machines running BSDi 3.0, the Alphas were very slow, even though the Alphas were stuffed full of memory.

I've never run NT on Alpha, but my understanding is that Microsoft took the easy way out and ran NT basically as a 32-bit OS. Linux, OTOH, fully supports 64-bit and has done so ever since the Alpha port matured. Microsoft finally had to bite the bullet and fix their 32-bit-isms when then came out with Win2k for ia64, but that was years later.

The Alpha also gets you on unaligned memory accesses - if you and your compiler are not careful, you can force some very slow OS traps. I wouldn't be surprised if your applications were slow partly because of this.

I was never particularly fond of the DEC Alphas. I didn't like Digital Unix much at all, and the power-that-be wouldn't even let me consider Linux on them.

Hmmm, what's not to like about Digital Unix? I always thought it was quite nice, as proprietary Unixes go. It was slower than Linux, due to its microkernel layer.

Re: *I* need 64-bit to use more RAM for...

[Dynedain]

When I say 3D rendering I don't mean openGL/DirectX rendering....I mean full raytraced, reflection/refraction with global illumination, complex shaders, etc. With scenes as complex as I'm working with, I'm still looking at rendertimes of upwards of an hour per frame.

And as for video editing. Take a 1920x1080 (max HDTV) clip in raw 1 targa per frame format, add gradients, filters, masks, particle effects, 3d camera movements and lighting, and tell me you can buffer more than a few seconds in RAM. Don't believe me? Go download the demo version of Combustion from Discreet and try it.

Re:Why 64 bit

[bovinewasteproduct]

The expanded memory hack worked but most programs later on only worked with extended memory which the 286 could not do.

The 80286 could indeed run in extended memory mode. I quite happily ran both Coherent and Xenix 286 on a OLD NEC APC IV. 286-12, 640KB base with a 2MB extended memory card maxed out (my dad worked for NSM at the time). What the 286 did NOT have was a flat address mode; This meant that you had to use Bondage & Domination opps I meant segment & offset to address your memory.

BWP

I gotta ask:

[haggar]

(forefeiting my modpoints for this thread): Linus doesn't like the Itanium (neither do I), he is in control of what gets into the kernel, and he probably is benevolent enough to let Itanium-specific changes to flow in. BUT, does his negative view of Itanium pose any potential problem for Linux on Itanium?

Re:here's a question....

[jda487]

yes, this thread is probably redundant and crap, but i felt i needed to say it.

Re:This is a troll

[darqchild]

Absolutely Nothing, but it was funnier than your comment and this comment put together

Linus will "eat his words"

[dusty123]

A fast FP is nice. But this does not matter for the majority of applications. I am no guru but I don't think, FP is that important for database and webservers. The scientific market is quite small, so how would the Itanium be placed?

Well, if I remember it correctly, _the_ OS guru, Tanenbaum, said something like "Linux is obsolete".

Look where we are now.

Dreaming and being idealistic is a good thing: It pushes creativity and motivation.

But do never forget that dreams are subjective. Maybe you can persuade similar thinking folks. But can you convince a world where objectivity rules?

People don't care about superiour and clean designs. They care about speed, price and reliability. And they are right this way. Blaming them on being short-sighted is something that is _really_ obsolete.

Linus never forgot these facts. I think this is one of his biggest strengths.

A really good CPU benchmark summary

[3770]

Go here for a really good summary of current CPUs.

Re:the reason the Itanic is a bomb..

[RAMMS EIN]

There is a point in saying Windows is tied to IA32, though. Windows, and most of the software commonly used with it, is distributed only in binary form. If all of a sudden there are two more architectures (IA64 and x86-64) to support, this is going to be a strain on the vendors. If Intel is aiming at the server market, whereas AMD goes for the desktop, this will not be so much of a problem, as both segments typically use different software anyway. Hawever, chances are that both AMD and Intel will go for both segments. This can only be beneficial to open-source software, which can typically adapt to any architecture, provided a compiler exists.

My sympathy is with AMD, because they honor the Holy Principle of downward compatibility, where Intel provides emulation, which, alas, is horribly slow. It is true that IA64 is a cleaner architecture, but in my view it's just Evil and Rude; Alpha and MIPS have had it from the start. Having said that, my next chip is probably going to be a Transmeta Astro or a G4; I am sick of coolers.

---
All generalizations are false.

No Power4 or 5 due in Macs

[Senjaz]

There is no chance of seeing a Power 4 or 5 in an Apple machine. They are IBMs high end server processors.

The PPC970 however is a different matter. Based on the Power 4 core with AltiVec, minus the on chip level 3 cache and multiple cores (though going back to multiple cores is a possibility when they improve their fabrication to 90nm from 130nm)

Question about FP

[tigersha]

OK, here is a question. Both current IE32 archs are better than AI64 on specint but worse on SpecFP.

However, AFAIK (I could be and probably is, wrong) a large part of this is because the way the FP unit on IA32 works. The original spec was for the 386 with an EXTERNAL FPU unit, the 387. This mandated an instruction set design that forced all the FP data through an external pipe and an internal stack on the FPU. When the 486 had the FPU on board the same instruction set was used for backwards compatibility ad infinitum and we are still living with that legacy. So in theory, if Chipzilla and MD designs a better FPU instruction set for IA 32 it could be much better. The problem lies in the way programs address the FP unit which is not necessary.

Of course, floating point numbers have more bits than 32 (64 or 80 as I recall) so the 64 bit data bus and processing ability may also make a difference.

Anyone care to elaborate? Or did I fall off the bus somewhere in the last 5 years. I last programmed FPU code for a 387 :)

Re:When is the...

[Carewolf]

An playstation 2 is 256bit or what? These are different bit sizes than the ones 32 vs 64 refers to. In the 32 vs 64 I am preatty sure Crusoe is only 32 bit. X86-64 is going to have 64bit addressspace, Cruseo has 128 bit instructionsize and PS2 has 256 bit memory bus. Completly different things!

Re:When is the...

[Puu]

Just to add detail:

PS2 is based on a 32-bit MIPS core (plus the real powerhouses, the two 4x32-bit / 1x128-bit Vector Units), but the memory bus affair is more complex. The main RAM is in two 16-bit Rambus banks, then there's a lot of internal 128-bit, 64-bit and 16-bit buses in the Emotion Engine, then there's the 2560-bit monster bus to the embedded memory in the Graphics Synthesiser...

So PS2 is hard to classify by bus width.

multiuser

[dpilot]

OK. We ran timesharing on my Radio Shack CoCo with 64k and OS/9. (The MicroWare OS/9, a Unix clone of long ago, not the new Mac thing.) One user on the console, one user on the bit-banger serial port. Not much throughput, but never criticize a dog for misspelling a word. Later I got the hardware serial port, and that might have made the exercise almost meaningful.

Re:Itanium2 is the fastest floating-point processo

[praedor]

So...are you saying that the Itanium2 will be Doom III certified? Now if only the video card guys would come up with a Doom III certified card with dual 1.1 GHz chips we'll be able to actually play the game when it is released.

Some cynicism

[Koos Baster]

> Of course, Linus works for a chip maker...
> So he is more likely to know what he's talking about.

Briliant thought. Along the same lines:

Of course, a soldier works for a war maker...
So he is more likely to know what he's talking about.

Sure - ask a soldier what it's like to kill people; he'll spell out the details. Now ask him to give a balanced and unprejudiced account of the pros and contras of attacking - say - Iraq... Even an answer from the current Bush administration would make more sense!

No doubt Linus is not doing a PR campaign while actually believing in Itanium's superiority, but your critique againts "cynicism" and "reflective commentary" just doesn't make sense.

Hmm. If only some people would reflect...

--
If pro is the opposite of con, what is the opposite of progress?

RISC Rules

[afantee]

IBM Power4+ at 1.4 GHz is about 20% faster than P4 at 3 GHz for floating point operations. And according to http://www.theinquirer.net/?article=7973 Power5 will be 4 times faster than Power4 and debut at 1.5 GHz or higher. I can't wait to see Power5 inside a big iron Apple Xserve.

The floating point power of Itanium 2 at 1 GHz is about 50% more than P4 at 3GHz, and Intel knows that clock rate is not equal to processing power.

While virtually every top microprocessor designer outside Intel laughs at the x86 architecture, Linus just loves it for some reason, which is why he never bother to tweak the Linux kernel for anything other x86.

And incidentally, Linus also had some very nasty comments about Mac OS X and Mach Microkernel a year or two ago. Does it ever occur to him that Apple, IBM and Intel might know better on these things?

Re:RISC Rules

[MikeBabcock]

Its surprised me any number of times that the first instruction set the Crusoe chip was designed to emulate (assuming they ever write translation software for other platforms at all) was the x86.

I would have thought that in the embedded and low-power market you'd get a better response out of having GHz StrongARM-compatible chips. Perhaps that market is already saturated? (compared with x86 though??)

Re:Itanium2 is the fastest floating-point processo

[Sinical]

And it's, what, only a hojillion times more expensive than a P4 that gets about 75% of the same score? It only consumes about 150W of power, weighs 2.3743 metric tons with the heatsink on, and sterilizes small children.

Whoopty-do: you don't think, given essentially unlimited dollars (Intel and HP have spent, what, 5 or 6 billion on this, right?) that someone else could have come up with a processor that scores 30% better on SPEC than a commodity processor?

I hate SGI, but I have an EIGHT processor box that consumes less power than a SINGLE processor Itanium 2. And while 600MHz R14ks suck, they don't suck that much.

Re:Obsessive - You've got it wrong

[SpaceJunkie]

You mean the one that IBM architecture with AT legacy devices attached has always used. I own two PC's, no Macs, but I have no misconceptions about the roots and limitations.
Unfortunately real technological development will always be hindered by commercial and egotistical issues.
And lets be honest - that whole backwards commpatibility thing is a bit of a chicken-bone in the throat. At least with linux you can recompile most of the software to run on a new architecture.
Looking at that graph - the scatter - I didnt see the G4 or PPC chips there. I personally think the better future is parallel processors as opposed to faster, more expensive, more power hungry superchunks.
Right now I think more development in software engineering would push the tech barrier furthar than the chip developments.
Most software cant even take advantage of current processors as well as it should yet.

Re:Most home users run Windows.

[irc.goatse.cx troll]

Intel dosnt realise we already have the speed we need. I'm not going to upgrade to a faster proc when my current proc is fast enough- however, I would upgrade to a 64bit proc for all the new benifits of that.

GCC for IA-64

[Per Abrahamsen]

Does it produce code that is any good?

Except for some very specialized applications, GCC generated code is within 15% of ICC generated code on IA-32. My application is actually 5% faster when compiled with GCC.

I'd be very surprised if the same is true for IA-64.

Re:you need to learn some grammar

[darien]

Just to be the ultra-pedant, the subjunctive is a mood, not a tense. It works like a tense though.

YOU FORGOT FEW BITS...

[JollyFinn]

As x86 instruction decoder wants FEW extra bits in cache in order to allow multiple issue, actually, thats atleast 3 per byte. Now the trace cache is even worse. So I don't care if you can crank more instrcutions in your 32kb cache, I'm more interested, if your cache is double the size, and you can fetch and decode twice as many instructions, like real issues. BTW: L1 instruction cache can be quite huge, as its only small branch prediction penalty.

That's one reason I loved BeOS's int32, etc.

[PurplePhase]

I always knew what the size was going to be with int32 and int64 and the like. I've always wondered why more groups (OSes? PLs?) don't make these kinds of types explicit. I mean, for a 64-bit arch, what do you use for a 32-bit int? Do they add another primitive type to C/C++/Java/any other PL?

Why not use the obvious?

8-PP

MOD THIS UP.

[Futurepower(R)]

MOD THIS UP. Good Info!

C99 Solves This

[istartedi]

The C99 standard has a lot of answers for this, such as intN_t where N=8,16,32... etc. They even have intptr_t for those who wish to convert void* to int and back. Also, intmax_t which holds whatever the largest integer data type is, and a few other special types. If you don't have <inttypes.h> on your system, read the standard, roll your own (which isn't hard), and USE IT.

Re:C99 Solves This

[WNight]

> Think free as in "working for IBM without getting paid".

The misconception here is caused by not realizing that while IBM benefits from GNU/Linux, the GPL means that it's not exclusively IBM who benefits. Hell, even Microsoft could benefit if they pulled their collective head out of their ass.

Having a popular, free, multi-platform OS doesn't help one company, or hurt another, it helps the consumers by ensuring that there's a healthy selection of companies to work with. IBM might be benefitting now (good for them) but they're also ensuring that neither they, nor any other computer company, will be so dominant again.

Re:C99 Solves This

[istartedi]

The misconception here is caused by not realizing that while IBM benefits from GNU/Linux, the GPL means that it's not exclusively IBM who benefits. Hell, even Microsoft could benefit if they pulled their collective head out of their ass.

I use IBM as a stand-in for "business". I suppose I could have said "corporate america", but using a concrete example like IBM makes it more vivid. No, MSFT would not benefit. They would have to exchange a highly lucrative business model for one that's dubious at best.

Having a popular, free, multi-platform OS doesn't help one company, or hurt another,

It helps the class of companies that consume software, and hurts the class of companies that produce it. For a service-oriented company like IBM, it's helpful. For them, software is just something they can spend hours tweaking and customizing, and milk billables for each hour. For Microsoft it hurts because for them software is a product.

it helps the consumers by ensuring that there's a healthy selection of companies to work with.

If you can show me hard statistical analysis to indicate that when GPL'd software enters a class of applications, the diversity increases, then I'll concede your point. This is a tricky thing to prove either way. The pro-GPL advocates will point to all the Linux distros, the anti-GPL advocates will point to the fact that all the Linux distros are just variations on a theme, which is something less than true diversity.

IBM might be benefitting now (good for them) but they're also ensuring that neither they, nor any other computer company, will be so dominant again.

No they aren't. There is nothing that can prevent a GPL'd software from dominating a sector. Worse yet, once that occurs, competition is limited to those who can either compete based on the GPL's limited business model, or who can produce packages of sufficient quality to justify charging a premium above zero cost.

Re:C99 Solves This

[WNight]

No, MSFT would not benefit. They would have to exchange a highly lucrative business model for one that's dubious at best.
For Microsoft it hurts because for them software is a product.

MSFT could easily benefit. They've proven that people don't care what they buy, as long as it has an MS label on it. If they ripped half their OS out and replaced it with LGPL'd components they'd still be able to charge just as much but their maintenance costs on that software would be lower.

Even if they switched over night to Linux, and just sold a .NET framework and a WinXP theme for X, they could legitimately sell it for what they sell XP for now. How is that not benefit? (And theoretically it's value-added, so the consumer would benefit too.)

show me hard statistical analysis to indicate ...

There's no "hard statistical evidence" for most things we know. GNU/Linux improved the diversity of operating systems. Everything that was there before, is still there, and now there's Linux as well. How does that not improve diversity?

There is nothing that can prevent a GPL'd software from dominating a sector.

If a company can't actually innovate and find a way to improve their product over the current state of the art, then sure, GPL'd software will win out. Microsoft talks about how they need to be free to innovate, surely their product is better than everything else because of this... Any company providing anything of value (something that can't be cloned in ten minutes) can sell it, companies not provide any value above what the free tools provide, will go away.

We treat "industry" these days like a fragile and whiny child. God forbid anything "hurts the industry". It's crap. If "the industry" can't produce a better product than a bunch of volunteers, they don't deserve to be in business.

Your sig talks about how work on GPL'd software helps businesses, but your message talks about how it hurts them. Which is it?

Re:C99 Solves This

[istartedi]

LGPL'd is a different animal now isn't it? It's almost as good as BSD. No, MSFT couldn't just sell stuff for X. *NIX users would poo-poo it, and Windows* users don't run X.

2nd point about diversity: That's what they call a "static analysis". Sure, if you just add a new, popular, GPL'd OS it increases diversity at that point in time. However, the dynamics of this is that it creates a disensentive for people to enter, or to stay, in the OS market. A lot of people on /. blame MSFT for the death of BeOS, but I think the blame rests squarly on Linux, which competed in the "alternative OS" space with BeOS.

3rd point about companies adding value simply isn't true for GPL'd software. MSFT could add all the value it wanted to Linux, but at the end of the day every geek who cares will still be "can you burn me a copy?" to their friends. No sale.

4th point about industry whining: Of course *everybody* whines. The squeaky wheel gets the grease. It's just a tactic. What do you think the Free Software people are doing when they complain about something MSFT does?

If "the industry" can't produce a better product than a bunch of volunteers, they don't deserve to be in business.

If volunteers can't produce a better a better product than the industry, they don't deserve immunity from laws against product-dumping and anti-trust. Actually, *nobody* deserves immunity from product-dumping and anti-trust. I've quoted that part of your post because it's a popular argument used by FS advocates. Businesses aren't saying they are "entitled" to be in business without creating a competitive product. What they *are* saying is that they deserve to compete on an equal and fair footing in terms of price and market share, in accordance with anti-trust and other established practices. In other words, please explain how a variety of hardware companies bundling Linux for free is more fair and beneficial to consumers than one software company bundling IE.

My sig is about how people who buy into the "GPL will make me free" mentality are really just prostituting themselves. My message is about how *some* types of businesses profit at the expense of others, and why I believe that this shift in business model will not be beneficial to the general public in the long run.

Re:C99 Solves This

[WNight]

If volunteers can't produce a better a better product than the industry, they don't deserve immunity from laws against product-dumping and anti-trust.

So if someone in my neighborhood owns a lawn-care service I shouldn't be able to do this free for my inlaws?

If there's a consultant willing to debug windows problems I should be required to bill my grandmother a competitive rate?

If there's a portable-seat vendor at a concert I shouldn't be able to sit on the grass?

Those propositions are ridiculous, yet they're a direct and obvious extension of not being able to create something for free without being under business laws.

I think IBM's actions in donating to open source projects should be investigated as possibly being dumping, but applying these rules to non-businesses is nuts.

[I] blame MSFT for the death of BeOS
"can you burn me a copy?" - Hypothetical Geek

If geeks aren't willing to pay for anything, a proposition of yours, then Linux wouldn't cut into the market share for BeOS. Only non-free operating systems are in this market, and as such, Linux couldn't possibly be to blame.

every geek who cares will still be "can you burn me a copy?" to their friends. No sale.

And let's return to this... You make it sound as if the software business is futile because some copying equates to everyone copying. How is Microsoft making money now? The answer is that people pay for their software despite cheaper and free alternatives, including warez copies, and there's no reason to think that customers would all stop paying if Microsoft released Linux software.

please explain how a variety of hardware companies bundling Linux for free is more fair and beneficial to consumers than one software company bundling IE.

Quality of products aside, bundling Linux with a computer makes it a usable product, much like shipping cars with tires and gas. And there's no attempted lock-in where Linux depends on undocumented hardware to function; those systems don't produce intentional error messages when used with a non-Linux OS as a form of FUD.

And, fundamentally, things done for free must be evaluated differently than those done for profit. Providing helpful instructions to a stranger is no different, except in scale, from providing an operating system to allow them to use their computer.

Re:C99 Solves This

[istartedi]

If you want to mow your granny's lawn, that's fine. OTOH, if a bunch of wealthy landowners got together and decided to subsidize free lawn-mowing for everybody in Fairfax county, that's a different story. I agree that applying business laws to nebulous associations like the Free Software movement is a dicey proposition, but when something looks like a duck and quaks like a duck, it's a duck and from the point of view of consumers and businesses, the Free Software movement is a big honking duck. As another guy said, think of it as "GPL Incorporated".

In your next argument, you say that BeOS didn't compete with Linux because they were in different markets--"free" and "non free". That's ridiculous. Software is software. Would you say that IE didn't compete with Netscape because Netscape was in the "unbundled" market?

To rebut your final argument: Nuking an entire city is no different than shooting the enemy with a rifle, except in scale. :)

Re:C99 Solves This

[WNight]

As another guy said, think of it as "GPL Incorporated".

Until I get my cheque, I'm going to have a hard time thinking of it as a business. It seems a lot like friends helping friends, except for IBM and a few companies.

I think IBM and Sun should be investigated for dumping, releasing Linux and Open Office is pretty obviously aimed at MS. But, after you've proved that both are completely guilty, slap them on the wrist, fine them $100M each, and let them pay the fine with copies of their software. If you're applying the same laws it's only fair that you apply the same penalties...

you say that BeOS didn't compete with Linux because they were in different markets

You yourself claimed that geeks don't pay for software. And to some degree it's true, not because they need to pirate, but because so much good software is free. So which OS is going to compete more with BeOS? BeOS costs money, and was largely about their new intuitive interface. It was made by Mac people. Without Linux I might have been a BeOS user, but probably not. The only thing drawing me away from windows games is Free-as-in-Freedom software. But, if Windows didn't exist and the only choices on x86 were Linux and BeOS (both circa '99) almost all of the non-geeks (a much larger crowd) would be on BeOS. MS also has the larger market by far.

Therefore, if you were to remove one of the competitors to help BeOS, I think MS would have been the one to go.

Nuking an entire city is no different than shooting the enemy with a rifle, except in scale.

I agree. If you scaled up the rifle analogy until everyone in the city was dead, nuking them would have had little practical difference. Dead is dead.

Re:Microsoft will decide the outcome of this battl

[istartedi]

The Intel chip won't sell for $3000 in 2 years. The are just milking the early adapters, who are probably also patient enough to put up with some bugs, as long as Intel remedies it with a new chip (!). You know there will be bugs.

Granted, this is a steeper premium than say, the new PIV vs. PIII, but it's a leap up in architecture and it's aimed at servers. I say, Itanium $500 or less in 2 years.

Re:Why 64 bit

[BenV666]

Would you really want to return to the dos himem.sys, memmaker, extended and expanded memory, and autoexec.bat hacks again?

You betcha, do you know how many people I impressed as an 8 year old kid creating those fancy config.sys and autoexec.bat files? ;)

Just develop on three systems.

[Dr. Manhattan]

When you're writing the portable parts of an application, compile and test on three different platforms. That's what I did; IA32 Linux, 32-bit SPARC Solaris, and OpenVMS Alpha (64-bit). That covers both endians along with 32 and 64-bit. 95% of the portability problems were caught within five minutes of writing them. (Along with the memory access bugs that work on one memory layout but fail on another, the misuse of a library call that works in one implementation but not another, etc.)

That app has since been ported to FreeBSD, IRIX, HP-UX, AIX, Tru64, and Netware. The Netware was tough (no pthreads) but the Unixes were, like, five minutes to get the right link statements and such into the Makefile.

OT sig - Re:Itanium 2 is great

[u38cg]

Your engineering might be cool, but your pipe band sucks ass. Boring, boring, boring. They're more boring than Windows.

Boring.

Wow...

[TaleSpinner]

Both barrels, the pistol, and then a baseball bat.
Go Linus!

baroque from the jargon file

[pjp6259]

This is common hacker jargon. If you've never seen it before, you should relay check out the jargon file here
is one reference.

And this is what it says:

baroque
adj.
[common] Feature-encrusted; complex; gaudy; verging on excessive. Said of hardware or (esp.) software designs, this has many of the connotations of elephantine or monstrosity but is less extreme and not pejorative in itself. "Metafont even has features to introduce random variations to its letterform output. Now that is baroque!" See also rococo.

Re:3D Rendering...

[Brendan Byrd]

That's because you're using the wrong computer. You should be using a SGI.

Re: *I* need 64-bit to use more RAM for...

[Frobnicator]

When I say 3D rendering I don't mean openGL/DirectX rendering....I mean full raytraced, reflection/refraction with global illumination, complex shaders, etc.

Reflection and refraction, global illumination and inside raytracing? That's not memory intensive, it's CPU intensive. Complex scenes? Raytracing being limited by RAM? Must be interesting research with very large 3D models that you're doing, because I've seen raytracings of multi-gigabyte objects; progressive loading and LRU discards are more than sufficient.

High-quality raytracing of complex scenes is extremely CPU intensive, not memory intensive. More memory beyond 4 GB won't help you there unless you have extremely complex scenes. Yes, it will take a long time per frame, and yes, 64-bit processors will help improve compute time, but more memory is *not* needed there, a better processor is needed.

and tell me you can buffer more than a few seconds in RAM.

Video editing doesn't need a few seconds at a time in RAM for most applications. That was the point I was trying to make. So you picked an image size of about 64-MB; big deal. Assuming you have full-screen processing kernels [filters and masks, in your words], gradients that are implemented as images instead of formulae, and movement and lighting that are not processed as simple matrix ops, then you are doing a great deal of wasteful processing. There are processors designed to do that -- and those are NOT the Intel x86 or Itanium chipset or the AMD chipsets. Memory isn't the problem, the choice of algorithms and processors is.

I'll say it again -- chose applications that match your class of machine. If your problem doesn't match the machine you are on, get a different machine. Don't think that just because a PC is good for word processing and web browsing that it is good for video editing, because it isn't.

frob.

Re:3D Rendering...

[Dynedain]

read my other comments to see why an SGI is not appropriate for the work I am doing.

Re: *I* need 64-bit to use more RAM for...

[Dynedain]

We dont do enough video editing to warrant a dedicated high-end video setup

We dont do quite a bit of super high poly+raytrace work...but because its architectural, it rules out most software packages (Maya sucks for trying to model buildings, and I need to work quite a bit with the industry standard-AutoCAD)

I know full well that my machine isn't optimal for video editing...we purchased Combustion, not Inferno or Flame. I also must use the workstation for web development and graphic design as well (and some network admin stuff)....in short, my time is to divided for my company to purchase a machine optimized for each of the myriad of tasks I must do....which is why we have a maxed out x86 solution....because the machine (and my time) is needed for more than one task

Re: *I* need 64-bit to use more RAM for...

[Dynedain]

that should be "we do quite a bit..."

should've hit preview

Re:Java and the x86-64

[J. Random Software]

Unfortunately, every JVM will suffer a speed hit to implement 32-bit arithmetic on a 64-bit machine, all because a class of programmers out there have proven unable to cope with specifications like "at least 32 bits".

Re:Employment =? Suicide

[blair1q]

You're a pinheaded literalist and a coward.

The phrase has been used in innocuous context for a couple of decades.

Grow up.

Re:Most home users run Windows.

[dbrutus]

Not quite that soon. Apple has some serious bad history of product shortages and one of the nice things about 'the new apple' is that it doesn't happen as much as it used to.

IBM will start production and Apple may have internal machines running 64 bit versions of Mac OS X in a few months but they certainly aren't going to announce until they have a nice stack of machines waiting for the tidal wave of users to come at them.

Re:Where's the Harsh Words for Transmeta?

[John Bayko]

How is anything Transmeta done even remotely close to something of this level?

It has the potential. Revolutions aren't always noticed right away, but the idea of translating the instruction from one CPU to another, and running almost the same speed as the original, is something that has never been done both commercially and successfully before.

The implications of this are more profound than it first seems. First, this removes the requirement that CPUs be particularly compatible with anything. In fact, the some of the Transmeta CPUs aren't compatible with each other - yet they all run the same programs.

This frees up the design incredibly. For comparison, the Transmeta CPUs (which Linus writes code morphing software for) and the IA-64 (which he thinks is crap) are both VLIW architectures, with about the same issue width and number of registers, and so on. They are more similar to each other than either is to the x86.

However, the Transmeta CPUs leave a lot of things like the ordering of instructions and handing of exceptions exposed to software. The code morpher takes care of those jagged edges, making them disappear - as a result, the CPU implementation is very simple but very effective.

In comparison, the IA-64 needs to explicitly specify what instruction combinations are allowable in the input packets, needs to store exception information (there are at least 128 bits that do nothing but remember if an exception happened when using a register), and so on. The result is that the sharp jaggie bits now look like soft jaggie bits, yet the machanisms needed to keep the whole thing consistant bogs it down. I don't think an IA-64 could be implemented at all in a CPU as simple as Transmeta's.

The second important thing is that the CPU is not tied to a single instruction set. I think Transmeta has made a mistake in not including support for other instruction sets, but it has demonstrated that it can. I remember reading that the first demo showing a Transmeta CPU running Doom was written in x86 machine language, except for the inner loop which was written in Java bytecode. Every iteration the CPU+software switched instruction sets without missing a frame.

If Transmeta is aiming for the low power, embedded marketplace, the dominant player there is ARM, not x86. If they could offer the ability to mix popular embedded ARM code with popular desktop x86 code, they might have a real winner there.

But as yet, the revolutionary aspects of the Transmeta designs are unexploited, and mostly even unnoticed. But I'm convinced that even if they don't do it, it will get done another way, whether it's Java, .NET, some Open Source project (Parrot?), or something that's not even noticed yet (Tao Group Elate?). But I think they are revolutionary.

Re: *I* need 64-bit to use more RAM for...

[jericho4.0]

When you talking about 3D models, the memory required to hold the frambuffer pales in comparision to the amount needed to hold the models. The OP wasn't making a point about video cards.

64 bit pointers

[John Bayko]

Most home users are going to see a performance drop from 64 bits. 64-bit code needs 8 bytes to hold every pointer.

Not quite - the registers hold the pointer, the code usually only holds an offset which is added to a base register. The offset is often smaller (most RISC processors only load 16 bits of a constant at a time), but this depends on the execution model that's used - memory segments can be limited to 4GB for user programs, so offsets don't need to be larger than 32 bits, even on a 64 bit CPU.

Also, some CPUs have 32 bit modes - AMD's x86-64 actually lets 32-bit and 64-bit code segments share the CPU (the OS must be 64 bits for this to work).

Re:Most home users run Windows.

[jbolden]

I disagree with you a 100%. IMHO Apple would much rather have i970 model Powermacs in August and be filling orders right through to November than not releasing until January.

Remember there release of the 1.4ghz G4, they put a 1 month delay on it. The 17" iMac took about a month before stores could get any...

Re:Most home users run Windows.

[dbrutus]

A month is one thing, three or five months is something else entirely. I'm guessing that *a lot* of people, mac users or not will be wanting PPC 970 based macs.

Re:Itanium2 is the fastest floating-point processo

[bobbozzo]

Actually, the Alpha EV7 may be even faster, but HP is suppressing benchmarks.
See http://www.theinquirer.net/?article=7034 for more info.

OSS projects in classroom

[curri]

The problem is that most OSS projects are too big for a classroom project (basically equivalent to a 2-week project in the real world; we have 12-14 weeks but the students have 5 or 6 things [classes,work] to do, and you usually need to teach them something before they can start with the project).

At least that's my problem :) (I'm a prof at SPSU)

Remember the Intel 432?

[stonewolf]

About every 10 years or so Intel produces a politically correct processor. That is, a processor that would make any academic proud, but that is totally useless. In 1980 they built the 432. Google on it to find out how twisted this thing was. Later, they did the i860 (academically perfect, practically useless). Now, they have produced the Itanium.

It won't kill them. And, in 10 years someone will post a message like this on /. pointing to the 432, the 860, the Itanium, and some new politically correct processor that has slipped out of Intel

Stonewolf

Yes, but remember this...

[ilctoh]

These are true, but I didn't have time to research them completely...

• In 1899, a US patent officer suggested closing the patent office because "everything that can be invented has already been invented."
• In the days of the 386, someone (can't remember who) said something to the effect of "why bother trying to make faster processors? The world has all of the power they need in the 386!:
• In the days of DOS, someone said something to the effect of "What could you possibly want to do that requires more than 640K of memory?"

Of course, this argument would be better if I had the time to look up the people who made these observations, but the point is still the same. Right now, I'm happy with my Duron 1300MHz, but then again I once thought that the 486 was the best idea since the keyboard. Who knows, maybe 5-10 years from now, all home PCs, work stations, servers, even Beowulf Clusters will be using 64-bit chips. And we'll all be wondering, "How on earth did I survive with that Duron shit?"

Re:the reason the Itanic is a bomb..

[JWSmythe]

I've never run NT on Alpha, but my understanding is that Microsoft took the easy way out and ran NT basically as a 32-bit OS. Linux, OTOH, fully supports 64-bit and has done so ever since the Alpha port matured. Microsoft finally had to bite the bullet and fix their 32-bit-isms when then came out with Win2k for ia64, but that was years later

It's very possible that it went that way.. I know it was painful to run NT4 on there, which would explain a bit.

The Alpha also gets you on unaligned memory accesses - if you and your compiler are not careful, you can force some very slow OS traps. I wouldn't be surprised if your applications were slow partly because of this.

We were just running Microsoft apps on there (IIS, and the domain controller stuff), so if they were slow, it was Microsoft's fault.

Hmmm, what's not to like about Digital Unix? I always thought it was quite nice, as proprietary Unixes go. It was slower than Linux, due to its microkernel layer.

It was just little annoyances.. Like, we had to do some creative work to get the GUI not to load, and it didn't do virtual terminals, so when I was on the console, I couldn't switch between tasks very gracefully. If I wanted to do stuff in two windows, I had to go back to my desk and SSH in.. There were other things, but I can't remember them now.. I do remember it was an absolute pain in the ass to get a DPT RAID controller installed, even with DPT's help.

Re:the reason the Itanic is a bomb..

[omynous]

NT 3.51 ran on MIPS, PowerPC, Alpha and x86.

I know because in 1993-6, I was working for MKS of MKS Toolkit fame and we compiled the Toolkit on all 4 platforms. By 1996, we were back to doing mostly x86, because of platform support withdrawal. (although I believe they were still making it on all 4 platforms when I left.)

Microsoft learned plenty about poor cross-platform compatibility when they wrote OS/2, and didn't make the same mistakes with Windows. Of course, they made others instead :-).

MS Windows for PowerPC 970? Anyone?

[tjstork]

Hey, WinNT ran on a PowerPC a long time ago. Maybe its time to make a comeback?

If not, there's always a 64 bit WinCE. Everyone needs a 64 bit handheld with a GUI so they can get awesome drag and drop with a stylus!

Re:How to improve x86 -- more registers

[oldCoder]

If you're changing architectures, adding more code-visible registers just makes sense. Linuses idea that making something deliberately slow so that you're forced to make something else faster just doesn't hold up.

Hopefully the person thanked <deity>, not some diet guru...

Re:Why 64 bit

[esper_child]

ahh fond memories the AT brings back. I remember mine having about 5megs (1 on board and 4 sipps). Prohaps I should boot it up again and see if it still works.