Path: utzoo!attcan!uunet!snorkelwacker!apple!rutgers!att!mcdchg!ddsw1!igloo!nevin
From: nevin@igloo.scum.com (Nevin Liber)
Newsgroups: comp.lang.misc
Subject: Quickpick construct (was: How to make a language downward-extensible?)
Message-ID: <2882@igloo.scum.com>
Date: 4 Oct 90 05:29:39 GMT
References: <7935@scolex.sco.COM> <29047:Sep2816:51:1290@kramden.acf.nyu.edu> <7950@scolex.sco.COM> <18718:Oct120:03:0090@kramden.acf.nyu.edu>
Reply-To: nevin@igloo.UUCP (Nevin Liber)
Organization: Igloo public access unix, Northbrook IL
Lines: 45

In article <18718:Oct120:03:0090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <7950@scolex.sco.COM> seanf (Sean Fagan) 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!  Let me give you a
few scenarios to illustrate my point:

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.  When he switches machines, the machine-dependent code will
still be picked even though it is no longer correct.

There is no way to "prove" that two different routines perform the same
task.  What happens if you find a bug?  You then have to figure out
which alternative was compiled, fix it, and hope that the same
alternative is picked again (after all, it may not be as efficient
after you put your fix in).  From a reliability point of view, you
would have to compile and test all the different combinations of code.
Unless the product is very small, this gets to be very boring and time
consuming.

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.  Most loops are
not interated a fixed number (by this I mean known at compile time) of
times.  Given anything bigger than a trivial loop, the compiler would
be doing no better (and possibly worse) than without this redundant
information.


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.
-- 
	NEVIN ":-)" LIBER
	nevin@igloo.Scum.com  or  ..!gargoyle!igloo!nevin
	(708) 831-FLYS
California, here I come!	Public Service Announcement: Say NO to Rugs!