🚀 go-pugleaf

In article <2882@igloo.scum.com> nevin@igloo.UUCP (Nevin Liber) writes:
> In article <18718:Oct120:03:0090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >Yes, I'm aware of that; programs are almost always recompiled for new
> >hardware. The point is that you don't need the original programmer
> >slobbering over each new chip to figure out whether it's faster with
> >algorithm X or algorithm Y. You let the compiler do the job for you.
> But this solution would be a maintenance nightmare!

Maybe it would be. However, it's infinitely better than the situation
you get with ifdefs. (All your complaints about maintenance apply
equally well to ifdefs.)

> Suppose Joe Programmer writes two routines to perform the same task:
> one of them is portable but slower and the other is quick but machine-
> dependent.

No! I'm not talking about extending the language in any way other than
quickpick. I can't magically solve the problem of people writing
non-portable code, but I'm also not saying that the compiler should
provide non-portable constructs.

Quite the opposite: quickpick itself is perfectly portable. In fact, it
should *encourage* the development of portable code. Most of the time
that I use machine-dependent constructs or assembly, it's because I'm
unable to get the compiler to recognize any portable idiom for a fast
assembly construct. Part of the quickpick idea is that every compiler
should provide *some* way to do *everything* (within reason).

> There is no way to "prove" that two different routines perform the same
> task.  What happens if you find a bug?

It's certainly no worse than the ifdef situation. I think it's quite a
bit better, since the optimization decisions are entirely local. There's
no global HAVE_BITCOUNT symbol to look out for, no possibility of typos
in an ifdef; instead, there's just a small section of code that does one
well-defined thing in several different ways.

> Thirdly, I suspect that there are very few routines which would benefit
> from this type of hand-optimisation, because it assumes that the compiler
> can tell how long it will take to execute a given loop.

It's unfortunate that people are so blind to the benefits of hand
optimization. Fine, you stay away from quickpick; just let me write my
code efficiently. Piercarlo, do you want to argue this one again?

Sure, I see examples of code that my compiler can't understand, let
alone optimize. But I also see lots of examples that it can understand.
Compilers are getting smarter; some of them can even use profiling
information to figure out how often a loop is executed.

> Rather than adding constructs to help facilitate inline
> hand-optimisation, I would like to see people writing simpler, easy to
> understand code so that the compilers have a better chance at
> optimising, since compilers tend to do it better than humans anyway.
> Making hand-optimisation easier now will porbably get in the way of
> better optimisers later.

Obviously you program in APL.

---Dan