If you define correctness as "producing the desired results on one particular version of one particular platform", then you have a recipe for non-robust code that won't survive in the real world.
I think defining correctness as "producing the desired results is pretty reasonable. Sure correct doesn't mean robust, but they are different things and this discussion has been about correctness.
Damn, I've been wasting my time. Now I know you didn't properly read the article. He includes the test programs he used.... Not worth responding to, just reinforces that you never looked at the source code
Yeah, I looked at the code. He replaces the sort says the bug is gone, must be a bug in how the sort is used. Sure seems likely but where is the actual bug. If we are going to spend the time giving a case study of a bug I think showing exactly there the bug is and why it is matters. But I suppose reasonable people can disagree.
The main thing this discussion has shown is the existence of different metrics for program quality, i.e. an error and a bad design, one is wrong the other is undesirable but correct (at least for the current program). Both are bad but in different ways and need to be handled using different techniques.
Conference proceedings don't count for much. I can't see any evidence that you know anything about devloping robust programs. Not that I'd expect you to, it is quite a different game to developing verification software anyway (although if the verification software itself needs tp be robust, then we have a problem).
If that is your opinion. But I should note that IBM, Microsoft, Mozilla, etc. spend a fair bit of money to sponsor and send people to these things. So someone apparently thinks these proceedings count for a fair bit (and companies that care a lot about building robust systems).
There are lots of dangerous but technically correct programs. In fact almost every program written is ill specified and most likely has methods that are used in ways that they were not initially intended.
As for my example, I agree in a "good" program one would always use it according to the given specifications. Doing anything else is breaking modularity and invites errors when making later changes. If you fail to understand the difference between modularity/abstraction (using the semantics provided by the contracts) and correctness (producing desired results) then I cannot help you.
No what Rob demonstrated was that replacing the call to sort made the error go away. But several things were changed here as well (most notably the random number generation and initial seeding were probably altered substantially). So, while he is right that calling sort to get a purmutation is a bad idea and he is (probably) right that the sort was the problem, this is never actually shown in the article. He just assumes that the bug went away so it must mean that the sort was the problem (but as I showed above this need not be the case).
As for your concern for me, I doubt if my code has appeared on TheDailyWTF, but I do know that I recently had some of my work in the ACM proceedings of "Verification Model Checking and Abstact Interpetation" on modeling the semantics of programs for later verification applications. So, I do know a bit about program correctness and specification. How about you?
You do realize there is a difference between code that is dangerous (but technically correct) and code that is actually buggy. As per my quicksort example. Dangerous, but correct.
You are getting intent and results confused. Calling my quicksort routine with an invalid compare function clearly violates the intent of the contract abstractions but functionally produces the correct results. The same may happen with your sqrt(-1) example, it is a bad idea from a modularity standpoint but may be functionally correct.
If you want to talk about if that is the case for the browser selection, well, I am glad you agree that determining if the implementation of the JS quicksort routine causes the bug (or if it is something else) would be a good idea. Unfortunately the author of the article was happy to jump to premature (although not unreasonable) conclusions.
And don't worry about me being a programmer. My code is quite reliable and in fact I do a lot of work on software reliability and correctness.
Look, I agree with you on mis-using the sort routine. Using a method to do something unintended does not cause bugs, it makes them more likely and is bad form. But without further analysis it is not certain if and why the sort is the source of the bug.
As for your challenge see the first example of quicksort from wikipedia:
-------- function quicksort(array)
var list less, greater
if length(array) 1
return array
select and remove a pivot value pivot from array
for each x in array
if x pivot then append x to less
else append x to greater
return concatenate(quicksort(less), pivot, quicksort(greater)) ------
Note that this correctly implements quicksort. By induction on length we show the uniform distribution:
length = 1: trival. length = 2: a 50/50 comparison has a 50% chance of producing either order. length = k: Each element has a 50% chance of being in less and a 50% chance of greater. By induction we will get permutations of each of these uniformly. Since we have a uniform chance of putting each element in each of these (and pivot is selected uniformly at random) the combination of the three will produce all purmutations with equal probability.
So if you want to argue the effects of possible implementation details then that is fine but that was my point. These implementation details are key to determining what actaully caused the problem (which as shown above may not be the sort at all). The article never addresses these only says the problem must be there, then after changing multiple things the problem isn't.
If you want to analyze the behavior of a specific implementation of an algorithm given input that violates the preconditions, then lookup the source code for your javascript interpreter. That may be a fun exercise to do, if you are bored, but it isn't very illuminating unless you want to understand why browser X produced that specific distribution.
Yeah that is exactly what I wanted because the article was about why a particular javascript implementation produced a poor distribution for the browser selection screen in the EU browser ballot. That is a specifc bug in a specific implementation.
I can tell you that failure to do array bounds checking before loads/stores will lead to bugs as well. But that does not explain why a specific bug exists. If you want to discuss poor programming practices that is fine but I did not find this a very enlightening way to do it.
And if you run bubble sort, as described in basic algorithms, it will always terminate (regardless of the comparator) since progress is always made via the loop indexing. In fact termination is often not a function of the loop body behavior. One only needs to show that there is an order (which is not infinitely decending/asscending) on some function of the program state in order to ensure termination. For bubble sort this is just the order on the loop index counter (i).
No there is no guarantee and the article does not specify which sorting algorithm is actually used. But any reasonable sorting algorithm should terminate very quickly even with the incorrect comparison function. Which is one of the reasons I found the article annoying, lots of general claims but very little analysis in the end.
I usually don't post much but for some reason the article struck me as designed to have just enough technical content to seem authoritative but that the intent was simply a chance to get in some cheap shots at Microsoft.
I agree with your general point. The particular implementation was not good. Violating method contracts leads to bugs. Yes, obviously. But issue was poor distribution in the random numbers. And the author never determined why this was the case. Was it the implementation of quicksort, an issue with seeding when run in a tight test harness, as you mention does it used different sorts for different input sizes, etc?
So yes, we have a program that is poorly written and produces the wrong answer. We also have an article that is poorly written and does not explain why the results are what they are (other than don't violate method contracts, which is good advice but not very enlightening).
Most likely I graduated from a different school but I appreciate that you asked.
You are quite right the formal precondition of the sort method is violated and this implementation is quite sketchy in that respect. However, that does not tell us what the distribution errors are caused by. As Rob is making other strange statements like possible non-termination (which should be impossible in any reasonable quicksort), I am not particularly happy to just believe him without a more careful analysis (e.g. seeding, how the test harness was implemented, pivot selection, etc.).
Yes I am well aware of this, in my post I state a "simple quicksort" algorithm which precludes several of the issues you mention and I discusses the possibility of problems in the pivot selection. But as you will note the article does not discuss any of these issues so we have no idea if it is one of these or not (it just claims it must be the sorting).
So we basically have an article that says I ran a benchmark and I can't explain the results so I'll just make up something that sounds good.
And to follow up after re-reading the article he claims that non-termination is possible. But since in quick-sort each recursive call is to a smaller list (we removed the pivot element otherwise the algorithm has real problems) the sort must always terminate.
Now this might not be a very elegant solution and definitely violates the abstract specifications of a sort routine but the problems pointed out by Rob are not actually the real problems. Way to go slashdot, always making sure articles that slag on Microsoft are factually accurate .
Well unless there is something else going on Rob needs to go back to school too. A simple quicksort algorithm with the comparator replaced with a random choice becomes a recursive random partition of the array. A simple inductive argument shows that this will not produce the unbalanced results he found. So the problem is elsewhere (most likely in the RNG seeding or a bias in the pivot selection, if he is running it in a tight loop and the seed is something like, current second, then the same seed may appear several times).
Yes but the issue is all the performance doesn't matter if your researchers aren't using it to solve problems. See http://www.darpa.mil/ipto/programs/hpcs/ for more info on this. This is the big HPC push that IBM, Cray, and SUN are participating in. Also a company that I think is kinda cool http://www.orionmulti.com/ is working on a very common use of HPC tools by non-computer people. They are very focused on providing easy to use ultra low maintainance computational tools primarially for the bio-informatics community. One of the founders of the company worked an LANL on green-desitiny (or something like that) which was designed to be a low power low maintainance super computing resource at LANL.
After all that, the short answer is yes performance is important but there is a lot of work and interest in making sure that this performance can actually be used by the people that are actually solving problems.
Mark
Actually the importance of the raw performance of the machine is on the decline. More emphasis is being placed on the idea that super computers are only useful in the sense that they help researchers solve problems. So there is growing interest in the notion of "time to solution" as a combination of ease of programming for, ease of using, and of course running a data set on the machine.
Hmmm, I have been suspicious of in-order execution models since the Itanium. But you have an excellent point that even with the current branch prediction, OOP execution, etc in the current P4 line the IPC is barely above one. So, perhaps spending silicon on ILP is just not working. I also think you have a very good point about most inherently single threaded applications not needing more computational power.
On the other hand the work I have seen on TLP is not very promising in that is requires a lot of programmer effort. You mention a talk from some of the Intel researchers did they discuss how he thought this problem might be resolved?
Anyway, your post was one of the more insightful I have read in a while, so thanks.
I am not extremely familiar with gcc's support for the Itanium. However, to get good performance out of the chip the compiler has to do a lot of extra work in the scheduler (since the Itanium is an in order processor) and use a lot of special features in the chip that do predicated execution, boosting, etc.
All of these things require substantial changes to large portions of the compiler. This means that the gcc people would have to do a lot of work for a small percentage of users and it goes against the goal of flexibility that gcc has.
I just went to newegg.com on their specials they list a Pentium D starting at $253. The lowest priced X2 is $539. While the AMD is a better performer and has better power consumption it is completely wrong to say you can't get an intel or that it is not at a good price.
Further, the consumer market for desktops seems (from my non-scientific sample) to be centered around $1000 to $1500 price point. The cost and supply issues around the X2 chips makes them rather unattractive for this segment.
In summary I completely agree with the first half of your post (but I think improving emulation and virtualization technology will change the situation. The second half seems to be totally out of touch with the reality of the current processor market.
This is stuningly wrong. I don't have my copy of Patterson and Hennesy next to me but off the top of my head and from a quick wikipedia cross refrenced by some googleing. Virtual memory came from the University of Manchester, the pascal P-code interp is not affilited with IBM and the first virtual machine, and of course the RISC architecture was developed at Berkeley and Stanford by Patterson, Hennesy.
This is just off the top of my head but some of the other firsts look suspicious as well. Maybe others who know can comment. But I just had to clear up some of these egregious statments in the parent.
A big problem that Microsoft faces is that when they release a patch it is reverse engineered to find the vunerability that it fixed. Since a huge number of individual users don't patch regularly (if ever) and corp. users want time to test the patch before rolling it out there is a lag between the patch release and it's deployment.
This of course means that the hole that the patch fixes (which may not have been known about before the patch) can be used to exploit systems for some time. Hence frequent, unscheduled patches can increase infections rates and why Microsoft switched to the monthly scheduled patch rollout.
Seriously, check out microsoft research. They do a lot of "real research". They have some very smart people and they publish a fair amount of quality work in prestigious conferences.
I know in my area of program analysis for reliability/safety that there have been some very subtantial papers (with "new ideas") on predicate abstraction that involve people from msr. It is some cool work and it looks like it will have a real impact on driver/low level code quality.
I think you are over estimating the interest of the research community in working on gcc. The move from the intentionally underdocumented and ill defined intermediate representations to tree ssa is a huge step for gcc. Unfortunately, there is still no real effort to make the platform attractive to do experimental work on.
The McCat compiler from McGill (which is what gcc borrowed the ssa rep from), C-- or the LLVM project all provide a much nicer platform. The internal representation is clearly documented, there are frameworks and examples for writing new passes and most importantly they all allow for whole program compilation.
Until gcc decides to support some of this the project will continue to be ignored by research groups. This might be fine since research compiler work can be fairly ugly and it is just easier to port what works.
Otherwise I agree that the move to ssa form is a critical step for gcc to take and it will enable it to become a "modern" compiler. More emportantly it will enable the inclusion of the large body of compiler work that is based on ssa forms.
I completely agree that unrestricted access to is optimal. I am thrilled about the growing trend for (at least CS) researchers to put their work where anyone can access it.
However, until people are willing to pay for research to be done for the common good things will not change. Given the severe underfunding of the NSF and other agencies it is clear that the public does not care about the current situation.
So if the public is unwilling to fund research and there is no IP protection to encourage the private sector what happens? How does the research get done? How do the new ideas get turned into real products?
Uhh, AMD is shipping the opterons next week. They are supposed to be priced in the range of $1500 an up. The intel Extreme Edition is also quite expensive at about $800 IIRC. The first chance to get affordable dual core chips is when intel ships the Pentium D. They are targeting a price range of around $250-$280. But according to Anandtech (there are several nice articles/benchamsrks there) they run quite hot.
Dunno if this will ever get read but next time you run into a problem like this here is an easier way to get the artice.
First try http://www.citeseer.com/, they often have the paper and even if they don't they list the papers that refrence the one you want. Often later work will have a summary of the paper you want and then some improvements.
If that fails head to the local university library. They have subscriptions to these journals and it is no problem to go photocopy the artice you want.
Slashdot Mirror
If you define correctness as "producing the desired results on one particular version of one particular platform", then you have a recipe for non-robust code that won't survive in the real world.
I think defining correctness as "producing the desired results is pretty reasonable. Sure correct doesn't mean robust, but they are different things and this discussion has been about correctness.
Damn, I've been wasting my time. Now I know you didn't properly read the article. He includes the test programs he used. ...
Not worth responding to, just reinforces that you never looked at the source code
Yeah, I looked at the code. He replaces the sort says the bug is gone, must be a bug in how the sort is used. Sure seems likely but where is the actual bug. If we are going to spend the time giving a case study of a bug I think showing exactly there the bug is and why it is matters. But I suppose reasonable people can disagree.
The main thing this discussion has shown is the existence of different metrics for program quality, i.e. an error and a bad design, one is wrong the other is undesirable but correct (at least for the current program). Both are bad but in different ways and need to be handled using different techniques.
Conference proceedings don't count for much. I can't see any evidence that you know anything about devloping robust programs. Not that I'd expect you to, it is quite a different game to developing verification software anyway (although if the verification software itself needs tp be robust, then we have a problem).
If that is your opinion. But I should note that IBM, Microsoft, Mozilla, etc. spend a fair bit of money to sponsor and send people to these things. So someone apparently thinks these proceedings count for a fair bit (and companies that care a lot about building robust systems).
I'll leave my part at that.
There are lots of dangerous but technically correct programs. In fact almost every program written is ill specified and most likely has methods that are used in ways that they were not initially intended.
As for my example, I agree in a "good" program one would always use it according to the given specifications. Doing anything else is breaking modularity and invites errors when making later changes. If you fail to understand the difference between modularity/abstraction (using the semantics provided by the contracts) and correctness (producing desired results) then I cannot help you.
No what Rob demonstrated was that replacing the call to sort made the error go away. But several things were changed here as well (most notably the random number generation and initial seeding were probably altered substantially). So, while he is right that calling sort to get a purmutation is a bad idea and he is (probably) right that the sort was the problem, this is never actually shown in the article. He just assumes that the bug went away so it must mean that the sort was the problem (but as I showed above this need not be the case).
As for your concern for me, I doubt if my code has appeared on TheDailyWTF, but I do know that I recently had some of my work in the ACM proceedings of "Verification Model Checking and Abstact Interpetation" on modeling the semantics of programs for later verification applications. So, I do know a bit about program correctness and specification. How about you?
You do realize there is a difference between code that is dangerous (but technically correct) and code that is actually buggy. As per my quicksort example. Dangerous, but correct.
You are getting intent and results confused. Calling my quicksort routine with an invalid compare function clearly violates the intent of the contract abstractions but functionally produces the correct results. The same may happen with your sqrt(-1) example, it is a bad idea from a modularity standpoint but may be functionally correct.
If you want to talk about if that is the case for the browser selection, well, I am glad you agree that determining if the implementation of the JS quicksort routine causes the bug (or if it is something else) would be a good idea. Unfortunately the author of the article was happy to jump to premature (although not unreasonable) conclusions.
And don't worry about me being a programmer. My code is quite reliable and in fact I do a lot of work on software reliability and correctness.
Look, I agree with you on mis-using the sort routine. Using a method to do something unintended does not cause bugs, it makes them more likely and is bad form. But without further analysis it is not certain if and why the sort is the source of the bug.
As for your challenge see the first example of quicksort from wikipedia:
--------
function quicksort(array)
var list less, greater
if length(array) 1
return array
select and remove a pivot value pivot from array
for each x in array
if x pivot then append x to less
else append x to greater
return concatenate(quicksort(less), pivot, quicksort(greater))
------
Note that this correctly implements quicksort. By induction on length we show the uniform distribution:
length = 1: trival.
length = 2: a 50/50 comparison has a 50% chance of producing either order.
length = k: Each element has a 50% chance of being in less and a 50% chance of greater. By induction we will get permutations of each of these uniformly. Since we have a uniform chance of putting each element in each of these (and pivot is selected uniformly at random) the combination of the three will produce all purmutations with equal probability.
So if you want to argue the effects of possible implementation details then that is fine but that was my point. These implementation details are key to determining what actaully caused the problem (which as shown above may not be the sort at all). The article never addresses these only says the problem must be there, then after changing multiple things the problem isn't.
If you want to analyze the behavior of a specific implementation of an algorithm given input that violates the preconditions, then lookup the source code for your javascript interpreter. That may be a fun exercise to do, if you are bored, but it isn't very illuminating unless you want to understand why browser X produced that specific distribution.
Yeah that is exactly what I wanted because the article was about why a particular javascript implementation produced a poor distribution for the browser selection screen in the EU browser ballot. That is a specifc bug in a specific implementation.
I can tell you that failure to do array bounds checking before loads/stores will lead to bugs as well. But that does not explain why a specific bug exists. If you want to discuss poor programming practices that is fine but I did not find this a very enlightening way to do it.
And if you run bubble sort, as described in basic algorithms, it will always terminate (regardless of the comparator) since progress is always made via the loop indexing. In fact termination is often not a function of the loop body behavior. One only needs to show that there is an order (which is not infinitely decending/asscending) on some function of the program state in order to ensure termination. For bubble sort this is just the order on the loop index counter (i).
No there is no guarantee and the article does not specify which sorting algorithm is actually used. But any reasonable sorting algorithm should terminate very quickly even with the incorrect comparison function. Which is one of the reasons I found the article annoying, lots of general claims but very little analysis in the end.
I usually don't post much but for some reason the article struck me as designed to have just enough technical content to seem authoritative but that the intent was simply a chance to get in some cheap shots at Microsoft.
I agree with your general point. The particular implementation was not good. Violating method contracts leads to bugs. Yes, obviously. But issue was poor distribution in the random numbers. And the author never determined why this was the case. Was it the implementation of quicksort, an issue with seeding when run in a tight test harness, as you mention does it used different sorts for different input sizes, etc?
So yes, we have a program that is poorly written and produces the wrong answer. We also have an article that is poorly written and does not explain why the results are what they are (other than don't violate method contracts, which is good advice but not very enlightening).
Most likely I graduated from a different school but I appreciate that you asked.
You are quite right the formal precondition of the sort method is violated and this implementation is quite sketchy in that respect. However, that does not tell us what the distribution errors are caused by. As Rob is making other strange statements like possible non-termination (which should be impossible in any reasonable quicksort), I am not particularly happy to just believe him without a more careful analysis (e.g. seeding, how the test harness was implemented, pivot selection, etc.).
Yes I am well aware of this, in my post I state a "simple quicksort" algorithm which precludes several of the issues you mention and I discusses the possibility of problems in the pivot selection. But as you will note the article does not discuss any of these issues so we have no idea if it is one of these or not (it just claims it must be the sorting).
So we basically have an article that says I ran a benchmark and I can't explain the results so I'll just make up something that sounds good.
And to follow up after re-reading the article he claims that non-termination is possible. But since in quick-sort each recursive call is to a smaller list (we removed the pivot element otherwise the algorithm has real problems) the sort must always terminate.
Now this might not be a very elegant solution and definitely violates the abstract specifications of a sort routine but the problems pointed out by Rob are not actually the real problems. Way to go slashdot, always making sure articles that slag on Microsoft are factually accurate .
Well unless there is something else going on Rob needs to go back to school too. A simple quicksort algorithm with the comparator replaced with a random choice becomes a recursive random partition of the array. A simple inductive argument shows that this will not produce the unbalanced results he found. So the problem is elsewhere (most likely in the RNG seeding or a bias in the pivot selection, if he is running it in a tight loop and the seed is something like, current second, then the same seed may appear several times).
Yes but the issue is all the performance doesn't matter if your researchers aren't using it to solve problems. See http://www.darpa.mil/ipto/programs/hpcs/ for more info on this. This is the big HPC push that IBM, Cray, and SUN are participating in. Also a company that I think is kinda cool http://www.orionmulti.com/ is working on a very common use of HPC tools by non-computer people. They are very focused on providing easy to use ultra low maintainance computational tools primarially for the bio-informatics community. One of the founders of the company worked an LANL on green-desitiny (or something like that) which was designed to be a low power low maintainance super computing resource at LANL. After all that, the short answer is yes performance is important but there is a lot of work and interest in making sure that this performance can actually be used by the people that are actually solving problems. Mark
Actually the importance of the raw performance of the machine is on the decline. More emphasis is being placed on the idea that super computers are only useful in the sense that they help researchers solve problems. So there is growing interest in the notion of "time to solution" as a combination of ease of programming for, ease of using, and of course running a data set on the machine.
Mark
Hmmm, I have been suspicious of in-order execution models since the Itanium. But you have an excellent point that even with the current branch prediction, OOP execution, etc in the current P4 line the IPC is barely above one. So, perhaps spending silicon on ILP is just not working. I also think you have a very good point about most inherently single threaded applications not needing more computational power.
On the other hand the work I have seen on TLP is not very promising in that is requires a lot of programmer effort. You mention a talk from some of the Intel researchers did they discuss how he thought this problem might be resolved?
Anyway, your post was one of the more insightful I have read in a while, so thanks.
Mark
I am not extremely familiar with gcc's support for the Itanium. However, to get good performance out of the chip the compiler has to do a lot of extra work in the scheduler (since the Itanium is an in order processor) and use a lot of special features in the chip that do predicated execution, boosting, etc.
All of these things require substantial changes to large portions of the compiler. This means that the gcc people would have to do a lot of work for a small percentage of users and it goes against the goal of flexibility that gcc has.
Mark
I just went to newegg.com on their specials they list a Pentium D starting at $253. The lowest priced X2 is $539. While the AMD is a better performer and has better power consumption it is completely wrong to say you can't get an intel or that it is not at a good price.
Further, the consumer market for desktops seems (from my non-scientific sample) to be centered around $1000 to $1500 price point. The cost and supply issues around the X2 chips makes them rather unattractive for this segment.
In summary I completely agree with the first half of your post (but I think improving emulation and virtualization technology will change the situation. The second half seems to be totally out of touch with the reality of the current processor market.
Mark
So what you are saying is that university research groups do inovative work and release the code to the public.
Mark
This is stuningly wrong. I don't have my copy of Patterson and Hennesy next to me but off the top of my head and from a quick wikipedia cross refrenced by some googleing. Virtual memory came from the University of Manchester, the pascal P-code interp is not affilited with IBM and the first virtual machine, and of course the RISC architecture was developed at Berkeley and Stanford by Patterson, Hennesy.
This is just off the top of my head but some of the other firsts look suspicious as well. Maybe others who know can comment. But I just had to clear up some of these egregious statments in the parent.
Mark
A big problem that Microsoft faces is that when they release a patch it is reverse engineered to find the vunerability that it fixed. Since a huge number of individual users don't patch regularly (if ever) and corp. users want time to test the patch before rolling it out there is a lag between the patch release and it's deployment.
This of course means that the hole that the patch fixes (which may not have been known about before the patch) can be used to exploit systems for some time. Hence frequent, unscheduled patches can increase infections rates and why Microsoft switched to the monthly scheduled patch rollout.
Mark
Seriously, check out microsoft research. They do a lot of "real research". They have some very smart people and they publish a fair amount of quality work in prestigious conferences.
I know in my area of program analysis for reliability/safety that there have been some very subtantial papers (with "new ideas") on predicate abstraction that involve people from msr. It is some cool work and it looks like it will have a real impact on driver/low level code quality.
Mark
I think you are over estimating the interest of the research community in working on gcc. The move from the intentionally underdocumented and ill defined intermediate representations to tree ssa is a huge step for gcc. Unfortunately, there is still no real effort to make the platform attractive to do experimental work on.
The McCat compiler from McGill (which is what gcc borrowed the ssa rep from), C-- or the LLVM project all provide a much nicer platform. The internal representation is clearly documented, there are frameworks and examples for writing new passes and most importantly they all allow for whole program compilation.
Until gcc decides to support some of this the project will continue to be ignored by research groups. This might be fine since research compiler work can be fairly ugly and it is just easier to port what works.
Otherwise I agree that the move to ssa form is a critical step for gcc to take and it will enable it to become a "modern" compiler. More emportantly it will enable the inclusion of the large body of compiler work that is based on ssa forms.
Mark
I completely agree that unrestricted access to is optimal. I am thrilled about the growing trend for (at least CS) researchers to put their work where anyone can access it.
However, until people are willing to pay for research to be done for the common good things will not change. Given the severe underfunding of the NSF and other agencies it is clear that the public does not care about the current situation.
So if the public is unwilling to fund research and there is no IP protection to encourage the private sector what happens? How does the research get done? How do the new ideas get turned into real products?
Mark
Uhh, AMD is shipping the opterons next week. They are supposed to be priced in the range of $1500 an up. The intel Extreme Edition is also quite expensive at about $800 IIRC. The first chance to get affordable dual core chips is when intel ships the Pentium D. They are targeting a price range of around $250-$280. But according to Anandtech (there are several nice articles/benchamsrks there) they run quite hot.
Mark
Me again, forgot trick number 3. Google the papers author. Most CS researchers are good about putting electronic copies of there work online.
Mark
Dunno if this will ever get read but next time you run into a problem like this here is an easier way to get the artice.
First try http://www.citeseer.com/, they often have the paper and even if they don't they list the papers that refrence the one you want. Often later work will have a summary of the paper you want and then some improvements.
If that fails head to the local university library. They have subscriptions to these journals and it is no problem to go photocopy the artice you want.
Hope that helps,
Mark