NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/arch/10609

Internet Message Format | 1992-11-11 | 5.2 KB

Xref: sparky comp.arch:10609 comp.lang.misc:3585
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!news.unomaha.edu!news.mtholyoke.edu!nic.umass.edu!m2c!jjmhome!smds!rh
From: [e-mail] (Richard Harter)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Message-ID: <[e-mail]>
Date: 11 Nov 92 10:05:55 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Richard Harter)
Organization: Software Maintenance & Development Systems, Inc.
Lines: 95

In article <[e-mail]> [e-mail] (Robert Bernecky) writes:
>In article <[e-mail]> [e-mail] (Robert D. Silverman) writes:
>>In article <[e-mail]> [e-mail] (Robert Bernecky) writes:

>>:I write programs for correctness and maintainability first, THEN worry
>>:about little details such as performance. If you create something that's

>>You've probably never done any large scale computing.

>>I measure the run time of my algorithms in MIPS-YEARS.  A MIPS-YEAR
>>is a 1 MIPS machine running for 1 year, or approximately 3.1 x 10^13
>>instructions.  Jobs that take several hundred MIPS-YEARS are not uncommon.

>Bad guess, unless Crays, 3090s (Yes, I know they barely count) and
>a bit of CM-2 don't count.

He's not guessing; he's telling you.  Robert D. Silverman is a well known
mathematician and number theorist.  Facorization of large numbers requires
large amounts of computer time; quite often they are run on multiple
machines.  He's speaking from his own personal knowledge.

>Perhaps your code REALLY is MIPS-years in complexity. OR, it could
>be that failure to design properly leads to that complexity, whereas
>careful thought could reduce it to months or less.

This suggests that you are fundamentally confused; an algorithm may be
very simple and yet will require enormous amounts of computer time.
Conversely it may be very complex and require only a small amount of
computer time.

>Since I don't understand your problem, I can only speculate.

What is the value of uninformed and irrelevant speculation?

>However, I DO know
>that algorithmic excellence is the way to get speed, NOT dinking
>around with what you perceive to be a bottleneck at the bit-diddling
>level. AFTER you have the algorithm right, THEN you start tweaking
>bits. Optimization before design is usually a bad idea.

Did you ever tire of teaching your grandmother to suck eggs?  Bob
is one the most knowledgable people in the world about factorization
algorithms and the associated issues of multiple precision arithmetic,
this bit of pontification is misplaced.  [Not that it isn't a sound
principle -- you should realize that other people may already be aware
of it.]

>>Needless to say, there are people who have to worry about speed FIRST,
>>and that other considerations are (almost) irrelevent.

>Are you saying that speed is more important than correct answers?
>{I don't think so, but I though I had better ask.}

Yes, the answers have to be correct.  But he's right; there are people
who have to worry about speed first and foremost.  Some problems are
real cycle burners.


>>I wish you people would stop insulting Herman simply because his requirements
>>leads to code that is different from your petty and self-righteous
>>pre-conceived notions about coding style.

    I think Bob is off base here.  I understand well enough what
    Herman is doing.  It's non-trivial.  But the problem is not
    in Herman's coding style; I get the strong impression that
    his skills as a programmer are not up the requirements of
    his problem.

>I am not insulting him because of his requirements. (Maybe you have me
>confused with another netter. Then again, perhaps you don't...)
>I am still trying to understand his problem. Once I understand it,
>THEN I can address his coding style. We prefer the use of the term
>"opinionated" when using the first person form of "self-righteous".

>>Not everyone writes commercial code, or code for customers. Maybe it's
>>a research project that will end in a year. Stop being so provincial.

>I can't help it. I live in the province of Ontario.   8^}

>The issue of code for customers or commerce is not the issue. It's an
>issue of understanding. If you every have walked away from some code,
>and come back to it 3 months later, with NO idea of what it does, or
>how it could ever have possibly worked, perhaps you'll understand what
>I'm trying to get at here.

This is a platitude.  What Bob is telling you is that there are problems
which are so computationally demanding that computational efficiency is
far more important than standard programming style guides.  It's all a
matter of trade-offs.  There is a price for programming for clean code;
in most cases the benefits far outweigh the price; sometimes they don't.
--
Richard Harter: SMDS Inc.  Net address: [e-mail] Phone: [phone]
US Mail: SMDS Inc., PO Box 555, Concord MA 01742.    Fax: [phone]
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.