🚀 go-pugleaf

In article <2718@igloo.scum.com> nevin@igloo.UUCP (Nevin Liber) writes:

>You seem to ignore making the programmers work reasonably
>efficient.  If it takes you half an hour to rewrite, compile, and test
>a routine so that it saves one millisecond, that routine had better be
>used at least 1.8 MILLION times just to break even!

An excellent analysis.  It's pretty easy for a routine in a program which is
used by 10,000 people to be run 1.8 million times.  Each user only has to
run it 180 timesi, or once every working day for less than a year.

If the routine is imbedded in an iteration, then it talkes even less people
to break even.

>I'll even suppose that the cost of your coding time is negligible
>compared to the cost of computer time.  How much CPU time do you spend
>in an editor?  Or doing an extra compile or two because you feel it
>necessary to hand-optimize?  If, for example, this averages to 15 CPU
>seconds per optimization, you had better be shaving at least that much
>off of the final CPU run time.  Otherwise, your SYSTEM (you + computer)
>is not being reasonably efficient.

Again an excellent analysis.  However, I have to quibble with your definition
of SYSTEM.  I think the SYSTEM should be (you + computer + users).  Often
there are a lot more users than you and the computer.  So, if you save 15
seconds of run time and you have 1000 users, then it's worth 15*1002 seconds
of time to perform the optimization.  That's about 4 hours.  If the system
has 10,000 users, its worth 40 hours, or about a half a programmer-week.

>This has many prices to it.  Since you tend to ignore issues like code
>maintenance and portability, I'll focus on some more direct costs.
>Putting these features into the language increases the complexity of
>the compiler, and hence the compiler uses more computing resources.
>Are you really going to make your code that much more efficient, to
>make up for a compiler that takes, say,  5-10 times longer (both CPU
>time and real time) than, a C compiler?  This is very doubtful.

Still another excellent analysis!  We shouldn't have to put up with a
5 times degradation in compile time.  Of course, Unix C programmers have
been putting up with this much degradation for a long time.  Think C on
the Mac is about 10 times faster than typical UNIX C compilers.  So we
need to make our C compilers much faster.  Perhaps we could, in part,
achieve that by bootstrapping them from a truely efficient language?

			Bruce Karsh
			karsh@sgi.com