🚀 go-pugleaf

bs@gauss.mitre.org writes:
> rbe@yrloc.ipsa.reuter.com writes:
> > Optimization before design is usually a bad idea. 
>
> Spouting aphorisms adds little to this discussion. Especially since you
> are assuming facts not in evidence. (i.e. you are assuming that the
> optimization came before the design).

What Rubin codes in the privacy of his own VAX is his own business.

But he is trying to use his code as an example to convince the rest of
us that we should pay for our computer manufacturers to incorporate
"get bit from bitsream" and "generate exponential rv" instructions,
and to add all sorts of bells and whistles to our programming
language. If he wants to make such an argument convincingly, he has
to write clear, readable code.

In fact anybody who wants to make such an argument to add hairy
features to a programming language in order to achieve higher
performance has to do more than just present a piece of code. He
really should present:

 * a straightforward, readable, clear implementation of the
   piece of code containing the alleged bottleneck so that
   people know what the problem is

 * a realistic (or at least believable) driver that uses the code

 * actual profiling information using the driver that demonstrates
   that the alleged bottleneck actually uses up a significant amount
   of time

 * some readable discussion, analysis, and evaluation of the results;

   in the case of hardware features, this should include:

   + a discussion of several known architectures, cycle times, cost of
     additional hardware/VLSI real estate, etc.;

   in the case of software features, this should include:

   + a discussion of why optimizers can't currently handle this case,

   + how the feature interacts with the optimizer--does it perhaps
     inhibit other optimizations?,

   + why other language constructs can't handle it,

   + statistics (or at least a believable argument) from actual
     programs that show that the feature is used frequently enough
     that it warrants incorporation into the language (occasional
     hacks can be put into assembly language),

   + considerations of syntax, considerations of scoping and
     referential transparency, etc.

Such a discussion serves to try to convince others not only that the
feature is worthwhile to consider, but also that the proponent has
actually the knowledge and experience to make an informed proposal.

Anything else is just handwaving and doesn't convince me.

					Thomas.