🚀 go-pugleaf

In article <1de9ckINNfj7@life.ai.mit.edu> tmb@ai.mit.edu writes:
>
>I do write and use long-running programs (weeks, months) that use
>multiple workstations extensively in my work.
>
>For such programs, I find that correctness and maintainability are of
>paramount importance.  Efficiency, on the other hand, is of much
>less importance.  If I run my program once for 9 weeks, I'm going to be
>much better off than if I speed it up by 30% but have to run it twice
>(for a total of 12 weeks) because I introduced some error.

Sorry, I think correctness/maintainability and efficiency are usually
orthogonal and one can usually have both.  I don't think paying
attention to efficiency has anything to do with whether or not it is a
good idea to "test" a program by letting it run for six weeks.  And
I'd expect that the speedup from "no attention to efficiency" to
"reasonable attention to efficiency" is often much more than 30%.  A
little profiling and tuning can go a long way.  And I usually run my
programs a lot more than twice.

Also, I find that rewriting code to improve its efficiency sometimes
helps me turn up bugs, if doing the "same thing" a different way gives
me a different result.  Careful profiling can also give useful data
for debugging.

When I write code, I'll try to get it running correctly first, and then
worry about efficiency, but I do eventually worry about it.  The programs
I'm developing take up to a few days on a small parallel supercomputer or
cluster of fast workstations.  And most of the code I write is reused a
lot, so tuning it impacts everything I do.  I would not start a long run
with new code without testing it first.

>I think the idea that scientific programmers have to squeeze every last
>cycle out of their machines is a myth passed on from generation to
>generation and is out of touch with the modern economic realities of
>programming. The only people who have to squeeze every last cycle out
>of their programs are real-time programmers and software/hardware
>vendors who are concerned with looking good on benchmarks.

That is an odd myth; I'd say that scientific programmers write a lot
of bad "efficient" code mainly because they write bad code, period.  I
know enough of them that are plenty eager to get as many cycles as
they can, but wouldn't spend a half-hour profiling their garbage code
to see why it takes so long in the first place.

        - David Hinds
          dhinds@allegro.stanford.edu