NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/lang/misc/3538

Text File | 1992-11-08 | 2.9 KB | 59 lines

Newsgroups: comp.lang.misc
Path: sparky!uunet!ukma!usenet.ins.cwru.edu!agate!stanford.edu!leland.Stanford.EDU!dhinds
From: [e-mail] (David Hinds)
Subject: Re: Hardware Support for Numeric Algorithms
Message-ID: <[e-mail]>
Sender: [e-mail] (Mr News)
Organization: DSG, Stanford University, CA 94305, USA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 6 Nov 92 23:00:30 GMT
Lines: 47

In article <[e-mail]> [e-mail] 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
          [e-mail]