Backwards compatability. From what I've been reading in the past about processors, this is the key "feature" that keeps system speeds down. It's one of the reason RISC processors are faster than their x86 counterparts.
It's not so much the backwards compatability as the fact that the ISA was not designed properly in the first place. Actually, the x86 is pretty close to being a really good compiler target. The offset+base+index*scale addressing can be put to good use. The problem is the non-orthogonality of the instruction set (rep movs takes a byte count only in ECX, etc.).
The 386 was somewhat unfortunate because it seems to have come along "too early." My hope is that AMD will do one of two things:
Drop the 16 bit segmented architecture and emulate it in software when needed.
Emulate the whole blasted x86 in software a la Compaq's FX!32 or HP's Dynamo.
Dynamic compilation (or "JIT" or whatever) has come a long way in recent years. I hope AMD takes note of it. By moving the more ugly parts of x86 into software, AMD can hopefully design a more efficient core for whatever 64-bit ISA they dream up. If it's built on x86, then AMD should put the 32-bit and 64-bit parts in hardware (adding the appropriate opcodes and formats to get a truly orthogonal ISA) and do everything else in software.
As those of you who have read some of my postings may have noticed, I am (or at least try to be) a devout Christian and pretty vocal about it. I am also in some sense a scientist, althought out of date and not professional. Is there a conflict? No.
There is no conflict.
Amen!
For the Catholic (both from the Vatican and from others) view on science and religion, see http://www.cco.caltech.edu/~newma n/sci-faith.html. Contrary to popular belief, the Church is not full of Luddites.
I just commented on the fact that most people who are involved in computers are generally not the people who get involved with philosophy or running for political office as a whole.
I strongly disagree with this statement. In fact, I have found many engineering types to be quite philosophical and politically active. Look at RMS.:)
All joking aside, engineers tend to be a very well-educated group, interested in a lot more than technical stuff. Find a group of CSE majors and count how many are involved with creating music. I'll bet it's over half.
Then ask them about novels, movies, opera, art, Plato and Aristotle. You'll find out they know a lot more than what happened in the latest SciFi media.
Experienced software engineers are conservative because they have experience. There are many examples of fixing things that ain't broke and ending up with something worse.
Things which may seem antiquated will always have a place because they were written for a specific purpose.
C was written to be a fast, almost assembly-level language suitable for designing operating systems. A more dynamic language can't give you the same speed (C++ comes very close, even with virtual functions, and you can always code in a procedural style).
Lynx was designed to be an ultra-fast web browser (there are any times I'd much rather use lynx on my dailup connection than Netscape!)
CLI's were designed to be fast, highly-efficient interfaces to the machine. I can very efficiently get a sorted (by any criteria) list of all my program files containing the keyword "switch" using a CLI.
Now this is not to say new development shouldn't be encouraged. That attitude is somewhat shortsighted. I'm arguing that dismissing existing technologies as "out of date" is just as shortsighted. Companies still use COBOL, BASIC and FORTRAN!
Nowhere is a 1 (one) used as a variable - they're all lowercase L.
Which illustrates my point beautifully. I did not write "one," I wrote "ell." This is exactly why the use of such variable names is terrible practice. Any example code using it is essentially useless. It's much more confusing than it ought to be.
It worries me when books on algorithms and data structures can't present clear code (pseudo or otherwise).
My complaint is not with the fact that the language changes. I probably should have left out the line you quoted from my original post. My mistake.
My beef with the book is that it uses a horrible coding style that makes the examples hard to understand. That and the fact that many examples are just plain wrong (and not just in the corner cases, either).
I didn't particularly care for the writing style, as I found the explanations to be unnecessarily confusing. By that's really a matter or personal preference. The Cormen book, I think, is a much better introduction (for me, anyway).
This is a very well-written text with clear and detailed explanations. The pseudocode takes a bit of getting used to, but I like the fact the the algorithms are presented in a language-neutral fashion. This is the book that helped me understand alorithms, O notation and the tradeoffs between data structures.
Plus, it's a big book and covers pretty much everything your average hacker would ever want, and more.
Sedgewick basically takes a generic template and substitutes the language of the day, producing Algorithms in [Language].
The examples in this book are horrible. It is the only textbook I've seen that uses "l" (the letter) as a variable. Many of the examples are just plain broken.
To its credit the book does cover a wide range of topics, but I've read much better texts on algorithms and data structures.
Now this is interesting, and something I had not heard before. Do you have a pointer to a thread somewhere, or can you give a summary? What is lacking in the EGCS IR?
Optimization today requires that the compiler rerder instructions using internal knowledge of how the processor works, provide branch prediction information, instruction packing into compatible groups
In other words, code scheduling.:)
prefetch and invalidation support
Does EGCS do prefetching? How's it done on the Alpha? On the MIPS it's simply a load to $0, I believe.
code for recovery from speculative execution failure
I'm not sure what you're getting at here. The 21264 is an O-O-O machine. For Merced this sort of thing is going to be critical. And I suppose if you want to use some profile information and optimize for that, this could come into play.
I don't believe EGCS makes use of any profiling. That seems to be a big missing piece.
Superscalar architecture have vastly changed the way that optimization works, and VLIW Merced promises to change it even more.
This is true, but it is amazing how much of a difference the simple "classical" optimizations can make. Things like Common Subexpression Elimination, Loop Invariant Code Motion (both grouped under Partial Redundancy Elimination) and Induction Variable optimizations are important. EGCS only recently got a global CSE optimizer!
I assume this is the GEM compiler we're talking about.
Just why is EGCS so much worse than GEM? Is it because of backend very machine-specific optimizations (code scheduling, for example), or is it simply because EGCS does not support all the (mostly) machine-independent optimizations that GEM does?
The reason I ask is that getting EGCS up to speed with the same optimizations as GEM not only helps it on Alpha, it helps it on other platforms as well.
To phrase the question another way: What is the biggest missing piece in EGCS? Analysis? Optimization? Better machine models?
The issue isn't with Sony designing the chip; it's with manufacturing problems. Supposedly they've been working on the chip for years now, and the design is finished.
Bingo. The Emotion Engine is a huge sucker. The thing is 279mm^2 at 0.25 microns. I'm not sure what a Pentium III or Athlon measures, but the MPR I have here states that 180mm^2 is considered dangerously large. Yeilds are probably not going to be too good on this thing.
What _is_ gcc's problem on RISC machines? Is it the code scheduler (or other very machine-dependent parts), or simply the fact that gcc didn't (and probably still doesn't) have nearly the same level of (mostly) machine independent optimizations? Only just recently did egcs get global CSE and alias analysis. These sorts of things make a big difference on load-store machines.
My bet is that gcc 2.95 does MUCH better on Alpha, but maybe still not as good as the native compiler.
Boh! Forgot to add one important bit of speculation (based on absolutely no information I have):
McKinley may not have an x86 grafted onto its back. Merced supports PA-RISC through dynamic translation a al FX!32. My guess is that putting two separate processor cores (or decoders at least) on the same chip is no easy feat. Two designs must be verified rather than one. With HP doing the design, they may have just chucked the x86 entirely. Intel can always use dynamic translation or compilation (which they are working on) for those few remaining x86 apps that people will want to run on McKinley.
Why did Intel go to HP for the ISA? Because HP already had it from the work done on PlayDoh. Why reinvent the wheel? Intel wanted a new ISA to replace x86. Since it has failed in every endeavor to do so in the past, it makes sense to go to a company with more experience.
As for Intel not innovating with the x86 -- you've got to be kidding. The P6 core was quite a leap for the old workhorse. The Pentium is nowhere near the complexity level of the PentiumPro and everything based on it. And my hats go off to Intel for being able to use virtually this same P6 core in every new processor released since the PPro came out (not counting Pentium-MMX of course). It's a good design, as Intel proved x86 could compete with the RISC guys, which no one thought possible at the time.
HP is not the only company touting McKinley over Merced. Intel, too, has presented this view in the past, though not as publicly. Intel's chief architect for IA-64 gave a talk here during which he indicated having a similar sentiment. He also made a vague assertion about those template bits in the bundles not necessarily being a good idea, though he of course did not elaborate.
As for why HP would be saying this so publicly now, I can only present some speculation based on rumors and other bits of information:
HP (specifically the engineers there) is quite upset about Intel stealing the show. Merced is seen as an Intel chip, with HP languishing in the background. Intel is now starting to market "its" McKinley chip, and HP probably wants to nip it in the bud.
HP has far, far more experience in the compiler arena than Intel, and spent years working on PlayDoh, from which IA-64 draws heavily. Their compiler guys are really top notch, with lots of experience in VLIW, predication, software pipelining, etc. It's possible that with HP doing the McKinley design, they were better able to design the hardware for the compiler rather than the other way around.
McKinley may be a more dynamic (O-O-O perhaps?) implementation of IA-64. Less reliance on the compiler provides time for the problems to be worked out. And there are a lot of them.
The second implementation is usually better that the first. It's a simple matter of having more experience with the instruction set.
I've never really understood this argument. If WINE is going to discourage companies from porting products, they why aren't they porting now, when WINE is still several years off from being remotely stable for the average user?
If WINE gives me access to more software under Linux, then I say that's great! If some companies won't port their software because of it, then it is their loss. A better, native version will pop up and it will probably be free.
I don't know about anyone else, but I don't use WINE to run new applications or to get "real work" done. I use it to run legacy apps that are no longer supported or for quick jobs when someone sends me a document requiring Powerpoint or something. Linux has just about everything else I need and it does it better.
The main problem I see with this or any totally open review system is that the credibility of the reviewer comes into question.
When I review papers for a conference, the on-line forms require that I rate myself as a reviewer (often as an "expert" or not). The conference committee members are made up of respected researchers and there is an implicit assumption that these members will pick reviewers that know what they are talking about.
If I rate myself a non-expert, I cannot recommend a paper for acceptance or rejection. I can only make comments and weak suggestions (i.e. a "weak accept" or "weak reject"). Is this good or bad? I could argue it either way.
I'm not saying that a totally open review process can't work. I'm just saying it needs to have some thought put into it. Ultimately the conference committee members are responsible for choosing the papers (based on the reviews they receive and their own opinions). Who takes on that responsibility in an open system?
One final point is that nothing prevents researchers from publishing material on the web. I often see pre-published papers made available for download. The consumer understands that the papers have not gone through a formal review process yet.
Re:I thought the problem was GPL compatibility?
on
qt 2.0 released
·
· Score: 1
For any distribution that includes KDE, could QT be considered a "system library" (or whatever the term is)? That would resolve the GPL problem, no?
This is important to me, as I'm devloping some free software and am at the point where I need to choose a toolkit. I'd like to release under GPL, and I'd like to use QT, as it is the most "C++" toolkit I've found (wxWindows is not _quite_ as nice, IMHO).
But this is usually better code, because the number of instructions executed dynamically is less if the loop is entered (which is probably the case). The while loop requires two branches in the loop (back-to-top and condition-check) which the do-while requires only one (condition-check/exit-loop).
Yes, there are more conditional branches, but fewer instructions are executed overall. The overhead of the if should be rather small, as it is probably executed much less than the loop code.
You are implying that Netscape should change their security model.
Yes, I am, along with many others. My original point was to discredit Novell's statement that Open Source reduces security.
If they did change their security model to fit your view of how they should run their company, then what you propose (releasing the source code) would improve their security.
Ok, I'm glad we can agree on that.
Just releasing the source code would reduce the security of their product, not improve it.
Ahh, now I see the crux of your argument. You are arguing that releasing the source code without adequate means to reap the rewards will reduce security. This is true.
But you're playing word games. What many people don't understand is that opening the source to a product is a process. The simple act of posting the source code is not what people here are advocating. They are advocating the Open Source process - the peer review that has served the scientific community so well for centuries.
To put it another way, Novell would have to listen to its customers. It's a novel concept, but one who's time has come.
Slashdot Mirror
It's not so much the backwards compatability as the fact that the ISA was not designed properly in the first place. Actually, the x86 is pretty close to being a really good compiler target. The offset+base+index*scale addressing can be put to good use. The problem is the non-orthogonality of the instruction set (rep movs takes a byte count only in ECX, etc.).
The 386 was somewhat unfortunate because it seems to have come along "too early." My hope is that AMD will do one of two things:
Dynamic compilation (or "JIT" or whatever) has come a long way in recent years. I hope AMD takes note of it. By moving the more ugly parts of x86 into software, AMD can hopefully design a more efficient core for whatever 64-bit ISA they dream up. If it's built on x86, then AMD should put the 32-bit and 64-bit parts in hardware (adding the appropriate opcodes and formats to get a truly orthogonal ISA) and do everything else in software.
It will be interesting to see what happens.
--
Amen!
For the Catholic (both from the Vatican and from others) view on science and religion, see http://www.cco.caltech.edu/~newma n/sci-faith.html. Contrary to popular belief, the Church is not full of Luddites.
--
All joking aside, engineers tend to be a very well-educated group, interested in a lot more than technical stuff. Find a group of CSE majors and count how many are involved with creating music. I'll bet it's over half.
Then ask them about novels, movies, opera, art, Plato and Aristotle. You'll find out they know a lot more than what happened in the latest SciFi media.
--
SLS :)
--
Things which may seem antiquated will always have a place because they were written for a specific purpose.
Now this is not to say new development shouldn't be encouraged. That attitude is somewhat shortsighted. I'm arguing that dismissing existing technologies as "out of date" is just as shortsighted. Companies still use COBOL, BASIC and FORTRAN!
--
Which illustrates my point beautifully. I did not write "one," I wrote "ell." This is exactly why the use of such variable names is terrible practice. Any example code using it is essentially useless. It's much more confusing than it ought to be.
It worries me when books on algorithms and data structures can't present clear code (pseudo or otherwise).
--
My beef with the book is that it uses a horrible coding style that makes the examples hard to understand. That and the fact that many examples are just plain wrong (and not just in the corner cases, either).
I didn't particularly care for the writing style, as I found the explanations to be unnecessarily confusing. By that's really a matter or personal preference. The Cormen book, I think, is a much better introduction (for me, anyway).
--
This is a very well-written text with clear and detailed explanations. The pseudocode takes a bit of getting used to, but I like the fact the the algorithms are presented in a language-neutral fashion. This is the book that helped me understand alorithms, O notation and the tradeoffs between data structures.
Plus, it's a big book and covers pretty much everything your average hacker would ever want, and more.
--
Sedgewick basically takes a generic template and substitutes the language of the day, producing Algorithms in [Language].
The examples in this book are horrible. It is the only textbook I've seen that uses "l" (the letter) as a variable. Many of the examples are just plain broken.
To its credit the book does cover a wide range of topics, but I've read much better texts on algorithms and data structures.
--
--
In other words, code scheduling. :)
prefetch and invalidation support
Does EGCS do prefetching? How's it done on the Alpha? On the MIPS it's simply a load to $0, I believe.
code for recovery from speculative execution failure
I'm not sure what you're getting at here. The 21264 is an O-O-O machine. For Merced this sort of thing is going to be critical. And I suppose if you want to use some profile information and optimize for that, this could come into play.
I don't believe EGCS makes use of any profiling. That seems to be a big missing piece.
Superscalar architecture have vastly changed the way that optimization works, and VLIW Merced promises to change it even more.
This is true, but it is amazing how much of a difference the simple "classical" optimizations can make. Things like Common Subexpression Elimination, Loop Invariant Code Motion (both grouped under Partial Redundancy Elimination) and Induction Variable optimizations are important. EGCS only recently got a global CSE optimizer!
--
Just why is EGCS so much worse than GEM? Is it because of backend very machine-specific optimizations (code scheduling, for example), or is it simply because EGCS does not support all the (mostly) machine-independent optimizations that GEM does?
The reason I ask is that getting EGCS up to speed with the same optimizations as GEM not only helps it on Alpha, it helps it on other platforms as well.
To phrase the question another way: What is the biggest missing piece in EGCS? Analysis? Optimization? Better machine models?
--
Bingo. The Emotion Engine is a huge sucker. The thing is 279mm^2 at 0.25 microns. I'm not sure what a Pentium III or Athlon measures, but the MPR I have here states that 180mm^2 is considered dangerously large. Yeilds are probably not going to be too good on this thing.
--
What _is_ gcc's problem on RISC machines? Is it the code scheduler (or other very machine-dependent parts), or simply the fact that gcc didn't (and probably still doesn't) have nearly the same level of (mostly) machine independent optimizations? Only just recently did egcs get global CSE and alias analysis. These sorts of things make a big difference on load-store machines.
My bet is that gcc 2.95 does MUCH better on Alpha, but maybe still not as good as the native compiler.
Does anyone have hard data on this?
--
--
Just out of curiosity, when did OCT do the translation? At runtime, after exection or some other time? Do you have any references?
--
McKinley may not have an x86 grafted onto its back. Merced supports PA-RISC through dynamic translation a al FX!32. My guess is that putting two separate processor cores (or decoders at least) on the same chip is no easy feat. Two designs must be verified rather than one. With HP doing the design, they may have just chucked the x86 entirely. Intel can always use dynamic translation or compilation (which they are working on) for those few remaining x86 apps that people will want to run on McKinley.
--
As for Intel not innovating with the x86 -- you've got to be kidding. The P6 core was quite a leap for the old workhorse. The Pentium is nowhere near the complexity level of the PentiumPro and everything based on it. And my hats go off to Intel for being able to use virtually this same P6 core in every new processor released since the PPro came out (not counting Pentium-MMX of course). It's a good design, as Intel proved x86 could compete with the RISC guys, which no one thought possible at the time.
--
As for why HP would be saying this so publicly now, I can only present some speculation based on rumors and other bits of information:
--
If WINE gives me access to more software under Linux, then I say that's great! If some companies won't port their software because of it, then it is their loss. A better, native version will pop up and it will probably be free.
I don't know about anyone else, but I don't use WINE to run new applications or to get "real work" done. I use it to run legacy apps that are no longer supported or for quick jobs when someone sends me a document requiring Powerpoint or something. Linux has just about everything else I need and it does it better.
--
When I review papers for a conference, the on-line forms require that I rate myself as a reviewer (often as an "expert" or not). The conference committee members are made up of respected researchers and there is an implicit assumption that these members will pick reviewers that know what they are talking about.
If I rate myself a non-expert, I cannot recommend a paper for acceptance or rejection. I can only make comments and weak suggestions (i.e. a "weak accept" or "weak reject"). Is this good or bad? I could argue it either way.
I'm not saying that a totally open review process can't work. I'm just saying it needs to have some thought put into it. Ultimately the conference committee members are responsible for choosing the papers (based on the reviews they receive and their own opinions). Who takes on that responsibility in an open system?
One final point is that nothing prevents researchers from publishing material on the web. I often see pre-published papers made available for download. The consumer understands that the papers have not gone through a formal review process yet.
This is important to me, as I'm devloping some free software and am at the point where I need to choose a toolkit. I'd like to release under GPL, and I'd like to use QT, as it is the most "C++" toolkit I've found (wxWindows is not _quite_ as nice, IMHO).
Yes, there are more conditional branches, but fewer instructions are executed overall. The overhead of the if should be rather small, as it is probably executed much less than the loop code.
This is ok as long as a is dead after the loop. If not, an extra decrement will have to be generated.
This is a great example of how tricky optimization can be.
Yes, I am, along with many others. My original point was to discredit Novell's statement that Open Source reduces security.
If they did change their security model to fit your view of how they should run their company, then what you propose (releasing the source code) would improve their security.
Ok, I'm glad we can agree on that.
Just releasing the source code would reduce the security of their product, not improve it.
Ahh, now I see the crux of your argument. You are arguing that releasing the source code without adequate means to reap the rewards will reduce security. This is true.
But you're playing word games. What many people don't understand is that opening the source to a product is a process. The simple act of posting the source code is not what people here are advocating. They are advocating the Open Source process - the peer review that has served the scientific community so well for centuries.
To put it another way, Novell would have to listen to its customers. It's a novel concept, but one who's time has come.