Re: My take on ARC

From: Doug Tolton (doug_at_nospam.com)
Date: 10/20/03 

Date: Mon, 20 Oct 2003 20:02:41 GMT

Erann Gat wrote:

> In article
> <myfirstname.mylastname-2010031111110001@k-137-79-50-101.jpl.nasa.gov>,
> myfirstname.mylastname@jpl.nasa.gov (Erann Gat) wrote:
>
>
>>I couldn't find a good place in the ARC thread to hang this comment so I
>>just decided to punt and start a new thread.
>
>
> Just thought of something else:
>
> One of the premises of ARC's design is that speed doesn't matter because
> today's machines are so fast. I don't accept this premise. Speed only
> doesn't matter if you're not doing production work. If you're doing
> production work speed does matter because as soon as you start to process
> in volume your machine costs are directly proportional to your speed. If
> you can process customer requests twice as fast you only need half as many
> machines.

Sorry, I very much disagree with this perspective. I do a *great*
amount of production work, and very few problems require more machine
speed. The largest cost of owning a machine and solving most business
problems do not relate to machine speed, they are directly tied to
programmer or operator productivity.

Processing a customer request is almost always directly proportional to
the amount of time it takes for the operator or programmer to do their
task. Rarely is the computation portion the significatn determining
factor. Perhaps this is bigger deal at NASA, but it is just not the
case in the business world. If it were the case, why are people not 10
to 20 times more efficient now than they were 5 to 7 years ago when we
were running on 300 Mhz machines? Because computational efficiency
doesn't translate very well to overall efficiency.

> Yes, hardware is cheap, but the cost of the hardware is only a
> tiny fraction of the TCO of a machine. You have to find a place to put
> it, pay for the air conditioning, pay a sysadmin to maintain it and
> replace it every two years or so.

If this is true, why don't you write everything in Assembly? Because it
will take 50 times as long to get it done. At the rate things are going
in 5 or 10 years everyone will be running 50 to 100 ghz machines. If
you are contemplating building a language that will be useful on systems
that are thousands of times faster than current machines, designing to
optimize programmer time is a better design choice than optimizing
machine time. This is IMO why Lisp is experiencing a revival, it is
*far* more efficient for programmer time than say C.

> When you start to get into serious
> volume a factor of 2 in speed can make a real difference in the bottom
> line, which will, I think, be salient in ARC's initial target market of
> spam filtering. So I'm a little concerned about that aspect of ARC's
> design too. In particular, I think that Paul's focus on minimalism and
> intellectual purity at the expense of speed is going to prevent ARC from
> e.g. being able to do an AREF is O(1) time, which I think could end up
> being a serious limitation.
I'm sorry, I just disagree with this conclusion. As time advances
machine time is becoming less and less of a factor. Human time on the
other hand has had very little optimization over the years. Look at
Visual Basic for example. It was a shockingly simplistic language, with
terrible optimization, yet it exploded in popularity. The reason was
that you could build a windowed application (albeit slow) in a very
small fraction of the time you could build it in C.

>
> Paul's response to this is that efficient compilation is an orthogonal
> concern, and I largely agree with this. However, Paul's method for
> writing the langauge specification is to write what is essentially a
> reference implementation. The problem is that a reference implementation
> doesn't include any information about which apects of the behavior of the
> reference implementation are essential and which ones merely
> coincidental. (John McCarthy pointed this out during Paul's
> presentation.) By the time you get done building both numbers and arrays
> out of lists it may be very hard to back a compiler optimization out of
> that that will allow O(1) arefs. And even if you succeed you've now spent
> a lot of effort solving a purely artificial problem; what the net benefit
> would be is still unclear to me. Paul seems to take it on faith that if
> you keep things simple then Good Things will follow. I don't necessarily
> disagree, but the problem is that keeping things simple can result in an
> "impedance mismatch" with a complicated world.

I think he is designing for the complicated world. I have read a great
many of his articles, and specifically his writing is what brought me to
Lisp. His main focus is on making people more productive, and allowing
programmers to work efficiently with high level concepts. Seriously
compiler optimization is nice, but ultimately spending one month on a
problem that will reduce your run time by an hour is only useful if the
time savings will be more than the invested time over the long haul.

I think this is where technology loses frequently. From a business
point of view, machine optimization is really a very low cost compared
to human time. 

-- 
Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")

Relevant Pages

  • Re: HLA v1.93 is now available
    ... Optimization is Strategy Optimization. ... You're claiming that an assembly language programmer using HLA ... Only in *your* assembler. ... FASM does branch displacement optimization. ...
    (alt.lang.asm)
  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... what experienced programmers do, ... the compiler doesn't have the free pass to /assume/ that the function ... Nobody has recommended doing all optimization by hand to my knowledge. ... Compiler behavior in optimization simply has no place in a language ...
    (comp.programming)
  • Re: EXE hangs!
    ... "Steve Richfie1d" wrote: ... No 'optimization' is complete without measurement, ... Any competent programmer can and does write decently 'optimized' code. ... good idea where the bottleneck - "Why" was always a surprise. ...
    (microsoft.public.vb.enterprise)
  • Re: design of analog circuits using genetic algorithm
    ... And so does circuit design. ... using optimizers (genetic algorithms or more traditional ones) to *tweak* ... Have you done genetic optimization of circuit values? ... simulated annealing codes though fun to watch on toy problems. ...
    (sci.electronics.design)
  • Re: HLA v1.93 is now available
    ... clown? ... Optimization is Strategy Optimization. ... control of the programmer. ... Why on earth would an Assembler have to save that room, ...
    (alt.lang.asm)