On Fri, 7 Sep 2001, Richard Uhtenwoldt wrote:
Finally, are we all in agreement that it would be a great thing if someone invented a Haskell-like language as good as Haskell at hiding resource usage when resource usage is unimportant, but that made it easier to control resource usage than Haskell does when resource usage is important?
Of course it's not just in functional languages that performance demands can require rewriting shorter, more comprehensible code in less obvious ways. (My favourite example of something so completely non-intuitive is the Intel example from within a Sieve of Eratosthenes program that for(i=0;i<lim/step;++i){ prime[i*step]=0; } can on some processor setups be slower than for(i=0;i<lim/step;++i){ if(prime[i*step]!=0){ prime[i*step]=0; } } due to cache coherency issues.) In that context, there was an old suggestion of Don Knuth's that program source code should in the idealized future not just contain the final, optimized code (with perhaps the original code in comments) but as a kind of set of layers each representing the same semantic program but with increasing orders of optimisation, and links between `things' annotated with a label placed by the programmer explaining why the transformation between an unoptimised version `thing' and an optimised `thing'. The nice bit about this would be that the development environment would be equipped with a subsystem that could almost always establish (possibly using the the label on the link) if the two things had the same semantic effect, and a naive system that could try and produce (maybe using brute force pattern modification) the changes to the optimised version corresponding to changes to the unoptimised version. The nice thing about this is that it would allow changes to the code (due to say changing requirements, or ideas for better algorithms) to be made first to the simple version and then the areas of the optimised version that needed changing would be automatically brought to the programmers attention. (The system for trying to change the optimised code automatically is just there to stop the system becoming really annoying every time you do something something like int i=1; _______\ int i=2; int j=2; / int j=1; to the unoptimised code. The reason I think this would be a good idea is because I don't really object that much to having to optimise code that's performance critical, I just dislike the way that I never manage to keep both the original and optimised version in sync and so end up having to maintain the optimised code directly. I suspect that such a system is still at least 25 years away from feasiblity though :-( ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers email: tweed@cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.