The feature freeze for the 2.5 version of the Linux kernel will be this coming Halloween, but the time until the first actual 2.6 kernel will hit kernel.org is much longer than that - in a talk given on the Geek Cruise, Linus announced that the first release could be expected in June 2003, eight months from now. It's nice to see that such a long time has been planned for bug-fixing and stabilizing the kernel.
The most important new feature, according to Linus, are the changes and cleanups to the block layer; one can probably expect some problems to surface in this area, too, but outside of that, the code "looks fairly stable", Linus said.
C|net has the full story, which also has other interesting tidbits.
disaster??
you want more "interesting" things to be in real life, or would you rather want something more practical...?? i wish i hit a jackpot and spend it on space flights... thats interesting... but i'd rather earn every single penny of it, and then think of a hawaiin trip maybe... atleast that'd be more practical, and something i could actually look forward to...
linus is perfectly right when he says that its a drastic technology to work at immediately... THAT way, amd has chosen a better line of working towards the future...
you have a love-hate issue with ia-64, thats none of linus' problem... and frankly, not anybody else's... so keep those emotions to your self...
rbs
Re: What?
Linus, just like everyone else, is entitled to his own opinion - and from what I recall, he has explicitely stated in the past that while he does not like the IA-64 design, this will in no way affect the linux kernel - IA-64 support will be as good as the team working on it, just like it is for almost any architecture the kernel supports these days.
--
schnee
Re: Linus on IA-64. Disaster.
"... is designed to leave all complications related to instruction parallelism to the compiler ..."
Bingo. There are not yet mature, robust compilers for IA-64 even from Intel.
"... That's why if IA-64 fails and AMD wins, we would all lose. Because all the desktops will still be using more than a decade old technology."
It would be very unfortunate, and unfortunately many things that have been technically superior have failed in the market for various reasons (timing, marketing, existing inertia, ...).
"He could still go as far to say "AMD's approach is more interesting", whereas their approach is the least innovative. They simply didn't do anything interesting."
He could, but would you trust a layman source like CNet to quote him correctly in the right context? Linus is a fairly pragmatic person, and in the area of kernel development it's no wonder a kernel developer would prefer AMD-64 to IA-64. Switching is expensive.
The parts where he was quoted is all true of the status-quo today. IA-64 is expensive, slow, and what he didn't mention was that it generates a lot of heat and requires a huge amount of power. Thats exactly why it isn't being used in big data centers now, and companies like Google who are extremely power sensitive have said it's DOA for them.
"He also had funny ideas about the development model of OSs :
can be reached through http://kerneltrap.org/node.php?id=11"
I don't see anything "funny" about it, his perspective is fairly consistent with one from evolutionary biology. It may not be an appropriate model to think of in certain circumstances, but it isn't some crackpot junk.
"All these make me shudder and love BSDs even more. Their core group is lot more knowledgeable when it comes to computer science concepts."
Ah, suddenly the rest of your post makes sense now.
you said it all
You're using the point that there are not robust, mature compilers against the IA64 architecture. Why are you so pessimistic of IA64's future if code generated by an immature compiler on an early implementation appears to be the fastest computing platform available for a lot of tasks?
People forget that Intel are among the best and easily the most powerful in their field with most of the best people, the most experience, the most money. Maybe all their engineers are suddenly incapable of designing cpus. That would explain why IA64 is so crap. It doesn't explain why IA64 cpus are really fast though.
Re: you said it all
Note that I didn't state any position of my own. However, the issue with compilers is one of many things that could motivate a pessimistic outlook of IA-64. It seems obvious that for it to become widely accepted they are going to have to play catch-up for awhile -- the complication being that it may take so long that they'll have to revive an x86-based choice (Yamhill?) to compete in the interim.
I suspect that Linus and those with similar views thinks that if it comes to that, it may prove to be impractical. And/or that the improvement isn't significant enough to justify the switch. I don't find such a viewpoint unreasonable at all, nor would I equate it with a lack of knowledge about IA-64 or "computer science concepts" as the OP mentioned.
Re:...
Well it was more than a little obvious. Not just the fact that you were arguing against someone. Anyway, seeing as IA64 is in the head of the pack performance wise, they'll be just "catching up" a bigger lead.
You really are underestimating money. Intel has a lot of it, they have a huge market share, they can basically force IA64 weather anyone else likes it or not... Oh and they can also pay for the best engineers in the field which is why IA64 processors are actually really good.
IA-64
What's so special about the IA-64? VLIW and hinting's cute but the pay off is no backward compatibility, that's not a bit issue in open source but most of the industry's running Windows and that's why the Itanium isn't selling.
There are plenty of technically interesting chips out there (PPC, Alpha) so it's not hard to come up with an interesting design. What is hard is coming up with a good design that is immediately useful.
Knowledgeable or an upset Fanboy?
"Linus' comments on IA-64 in this article makes me think how knowledgeable he is when it comes to processor design. IA-64 is slow? IA-64 must be the fastest mass produced processor. Because it is designed to . . That's why it's such a design feat, and it's one of the most amazing things in processor history."
How about letting us know a bit about your own experiences in chip design.
Why must IA-64 be the fastest? Just because the design sounds nifty doesn't mean it is, where are the benchmarks to prove it?
"That's why if IA-64 fails and AMD wins, we would all lose. Because all the desktops will still be using more than a decade old technology."
I'll agree with the idea of getting rid of x86 legacy designs, but its debatable whether IA-64 is the right replacement.
For a while the PowerPC looked to be a worthy successor but Motorola hasn't been able to keep up with either AMD or Intel's Mhz for several years now. It was both efficient and fast, in Mhz and per MHz. The Alpha was fast but was very hot, and wasn't very suitable for the average consumer.
"He is also working for Transmeta which is probably completely unfamiliar with IA-64. And they would probably wither and die much sooner than Linus expects IA-64 to. He should probably argue how big a design mistake Transmeta is making and how their processors are crawling first before he belittles IA-64."
"Unfamiliar" Do you really think Chip companies and their staff don't investigate the designs of their competitors? Maybe thats why they're doing so badly :). Even Via's C3 seems to be getting more use than the former talk of the town Transmeta.
Hmmm, have I just been trolled?
IA64 is too static
My best friend is deep into CPU architectures. He's a college prof
and attends all the various conventions and things.
His main beef with the IA64 is that the chips have been way to
"static" so far. In talking about this, what he means is that the
Pentium, II/III/4/, Athlon, etc, all emply out-of-order execution
in order to efficiently process instructions and to spread them all
across their execution units. This mechanism was pioneered by the
Alpha chips back int he late-80's early-90's to get a lot more
instruction level parallelism out of the code.
The Itanium does not do this (that I'm aware of). It depends on
the compiler to do this work. It simply executes the instructions
coming in - if the compiler can't find an instruction to fill a
slot, then that slot is wasted.
Since the compiler can't know what *data* the CPU is going to be
fed with, there's no way it's ever going to be able to generate
the best mix of instructions for filling the execution units.
So , the Itanium is a "static" design. It can't adopt to the
incoming data. Now the Itanium 2 may have fixed some of this,
I don't know. But it's going to be a *really* hard problem.
In the time it takes Intel/HP to get this sorted out, it's entirely
possible that the marketplace may decide to go with a more backwards
compatible solution like AMD's. In which case Intel/HP have an
Itanic on their hands.
Pete
IA-64, how it works...
Well, that's the point though. It's not something that is to be fixed. The compiler tries to rearrange the instructions so that the maximum parallelism is achieved and hints the processor (that's the difference between VLIW and EPIC) about some minor details how to execute them better. If you assume you have a very good compiler, you wouldn't mind some time slots are wasted. Because you can't do any better than that.
Naively speaking, if you consider, compiler has lots of time to find a good arrangement, we usually don't really care how fast compiler comes with a result. We just care how fast the resulting code runs. But if the processor (via out of order execution) reorders them, because of this time constraints and complexity of such an optimized reordering algorithm, the parallelism that could be achieved is much less.
So instead of adding circuitry (which increases the number of transistors and thus the heat, etc) that would optimize out of order execution, they put more floating point, integer and logic units. In the end, during one cycle the processor does a lot more provided the compiler did a good job. But compilers get smarter everyday and we don't usually resort to home made compilers:) That's why in theory (and if you look at the SPEC benchmarks in practice) EPIC should perform faster. There're other optimizations that you can do with such a CPU, called predication and speculation. You can find some info at:
http://www.intel.com/pressroom/archive/backgrnd/sp101497.HTM
Well anyway, like someone else in this thread said, Intel has many good engineers working on it, and spent $5 billion on it. They're probably doing a darn good job on what they're designing.
And many of the guys that worked for Alpha are now at Intel. And some of the ideas in Alpha are apparently going to be used in Montecito and Chivano (the 4th and 5th generation Itaniums):
http://news.com.com/2100-1001-826527.html
Alp
you missed my point
The point is the the compiler can't know what data the program will run with, without running the program. Now, many good compilers actually will try and run the program to try and figure this type of stuff out, but the reality is that the compiler can NEVER test every possible combination of inputs to the program, or even, really, anything but a vanishinly small sample.
Ergo, the compiler can do a reasonable job of arranging instructions so that they fill all the slots, but it's ability to fully utilize all the possible processing elements of the CPU is limited.
This is one of the main the reasons this type of architecture wasn't tried before. CPU designers know that the compiler can only do so much, so they add out-of-order execution to their CPUs to make up for it.
Now, EPIC/VLIW will work great in situations where their are no branches and it's pure straight-line processing. This is because the compiler can see this and generate the optimal set of instructions. Hence the great (although unrealistic) SPEC numbers.
Real life programs, if anything, have moved away from straight-line code and have gotten even more branch heavy. This is especially true on todays GUI desktops and extensive use of Java/C++. This penalizes the VLIW/EPIC architecture that doesn't have dynamic scheduling.
And adding more processing units does no good if the compiler can't make use of them. It *would* do more good (to a certain extent) if the CPU could dynamically make use of them, but Itanium doesn't do that.
In terms of Intel having money to push something through - they do, but only to a certain extent. See, for example, RAMBUS. We all know how well that did.
And, as for the Alpha guys being at Intel - well, the really good Alpha guys are already at AMD. They left a long time ago and are one of the reaons AMD is having success with Athlon.
Pete
blah
Rambus isn't a good example because 1. it doesn't cause any software incompatibilities, 2. intel doesn't have such chipset domination or produce ram.
And what, do you think it is forbidden that any IA64 implementation ever use out of order processing? You can't say "EPIC" doesn't have OOOP, thats like "IA32" doesn't have OOOP. The whole point of OOOP is that it is transparent at the instruction level. True, Itanium doesn't but thats about as far as it goes.
Rambus is an excellant example
Bzzz, you missed it again.
The point I was making with Rambus was that Intel could not shove it down the industries throat like someone (you?) earlier implied they could do with IA64. Rambus is no different than IA64, and as there are both chipset and software incompatibilites with IA64, that will make it even more difficult to get people to accept IA64 (since they have to change out the whole box). Blows your point out of the water.
As far as OOOP goes, Itanium does not have it. I don't know that Itanium2 has it either (I kind of doubt it). And my point, which you also missed, is that the compiler can NOT magically figure out what data the code will run with, so IA64 needs OOOP to scale its performance. And adding OOOP is going to be one complex beast, making the chip even bigger and hotter. And at the same time AMD is going with evolutionary design rather than revolutionary design and winning market share all over the place.
No it isn't
And what exactly did I miss again? Intel can't dictate the use of Rambus a. because it isn't in the memory business b. Rambus is transparent to software.
Do you think if software compatibility didn't matter the x86 would still be around with CPUs like the Alpha to contend with?
I really don't care if you have shares in AMD or what just be reasonable. It isn't even a given that AMD will have a 64-bit version of windows to run. Not to mention they're going to run out of money.
And no, the compiler can't "magically" figure out what data the code will run with, OOOP doesn't have anything to do with branch prediction / speculation, idiot. The compiler has to optimise _instruction_ dependancies, the compiler is the thing that generates the instructions. Data doesn't have anything to do with that or OOOP. Data is about branch prediction.
And OK, I'm not a CPU designer, but neither are you so stop pretending you are. Eg. Why would you imply that an OOOP IA64 implementation would be more complex than an OOOP x86-64 implemenatation? It might be right, but you have no idea.
Re: No it isn't
Please, let's keep this civil - you may disagree on whether IA-64 or x86-64 is the better architecture and also on which of these will succeed in the long-term, but I don't think there's a need to get personal.
--
schnee
I apologise
I'm happy to end the thread on that note. Anyway only time will tell.
I cannot believe that.
I simply cannot believe that a pack of experienced engineers, who have added out-of-order execution to a 20 years old architecture, have not previewed the performance hit on a very expensive development as IA-64. Obviously if it is true that there is not execution out of order in itanium.
IA-64 fast?
On the point about IA-64 being fastest mass produced processor I must disagree: the high-end servers have used faster chips for a long time already. Processors like MIPS and Alpha.
The transmeta core is VLIW, just like the Itanium (ia64)
The transmeta core is VLIW, just like the Itanium (ia64)
EPIC is an VLIW implementation.
The itanium architecture is a VLIW implementation, with the added feature of EPIC. Obviously you need a long instruction word to get various instructions packaged in.
Transmeta core can be VLIW, i do not know, but there is a great jump from that to get intructions parallelized explicitely.
IA-64 architecture
Wierd, the trend with the current X86 family had been to put more and more smarts into the hardware.
With IA-64 all of a sudden the hardware becomes stupid and the compiler becomes the critical path.
It seems to me like Intel is trying to make money even more money by selling a compiler along with a cpu. Nice marketing racket if you ask me.
VLIW vs EPIC
Software compilation to VLIW is more advanced idea, becose, if number of devices in CPU will be changed, you should recompile you software. (For example - in next generation of EPIC cpu you will have more integer operations modules, but reducing of float point devices count. If code designed for bigger count of float point devices, it will be executed slower, becose you need more cycles).)
risc vs cisc vs epic, it's all transistors
As Ars Technia said when comparing the power 5 vs ultra sparc iv vs transmeta's latest contraption - transistor density has dwarfed any architecture improvements. Andy Grove said it himself in his book regarding the RISC vs CISC battle...
June??
How did second quarter 2003 become June. And remember it's free software, it will be late, and there will be huge pieces of code dumped in there in the last minute...
Re: June??
Simple:
Q1 - January, February, March
Q2 - April, May, June
Q3 - July, August, September
Q4 - October, November, December
I don't see how you could have missed it unless you can't do basic math.
Re: June??
Sorry - my mistake. It should've said by June 2003, not in June 2003.
--
schnee
Re: June??
Fixed. :)
Re: June??
Thanks. :)
--
schnee