🚀 go-pugleaf

In article <1b1f3pINNde6@early-bird.think.com>, bromley@think.com (Mark Bromley) writes:
|> In article <1992Oct8.124228.10449@kth.se> kff@dentex.tds.kth.se (Karl-Filip Faxen) writes:
|>
|> >Then a good
|> >compiler should be able to come up with an evaluation order that is at
|> >least as efficient in terms of resource (eg memory) consumption,
|> >locality and (when the machine can take advantage of it) parallelism,
|> >as any I could come up with myself with a reasonable amount of work.
|> 
|> My somewhat uninformed but not completely naive opinion is that this is
|> expecting way too much from the compiler, and that in fact some level of
|> control of resources is almost as much a part of the algorithmic process as
|> specifying data dependencies.

It is quite possible that you're not completely and utterly wrong. On the
other hand, things are progressing in that direction, albeit slowly. Think
of register allocation, for instance: I don't think that I would do much
better than a modern intermodule register allocator that based its
decisions on profile information, especially not without spending a clearly
unreasonable amount of work. 

Early examples of what I think of are e.g. the work being done on making 
instruction schedulers taking register pressure into account, and blocking
optimizations for registers or caches.

The problem of whether something like this could be made to scale to larger
datastructures than scalar variables and larger segments of text than procedure
bodies is of course an open, and in my opinion, very interesting one.

|> Note that I am somewhat biased in this matter.  The company I work for has
|> managed to do quite well by taking almost exactly the opposite point of
|> view from that expressed above.

I know. We've got a CM-2 at our school. 

|> I think there is a happy medium somewhere between the two extremes.

It may be that annotations are a good idea, separating data dependencies
from resource management decisions. Fortran D could be seen as an example
of this, as can the Yale group's (Paul Hudak et al) work on parafunctional
programming.

Cheers,
         Karl-Filip

------------------------------------------------------------
Make the frequent case fast, and the fast case frequent!