controlling resource usage

D. Tweed
Fri, 7 Sep 2001 17:42:06 +0100 (BST)

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


can on some processor setups be slower than


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________________________________________________________ |tweed's law:  however many computers
email:      |   you have, half your time is spent
work tel: (0117) 954-5250       |   waiting for compilations to finish.