🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #1406

Re: Efficient Fortran

#1406
From: Ted Dunning
Date: Tue, 31 Jul 1990 19:35
62 lines
2812 bytes
In article <2419@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

   In article <1990Jul30.183426.26506@lth.se>, bengtl@maths.lth.se (Bengt Larsson) writes:
   > In article <2413@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

   > Are you worried that "more code" will mostly not be executed, and therefore
   > you move it, reverse the test, branch and branch back?

   This is definitely the case.

   > Is the execution time of your code that critical? 

   This block of code is likely to be executed at least tens of thousands of times,
   and quite likely tens of millions.  It is code for refilling a buffer to be 
   used in Monte Carlo calculations.

well, how much is it going to cost?

on a highly pipelined, heavily cached RISC, both alternatives will be
in the cache (and are likely to be in the same page), so the only cost
differential will be the cost of the jump taken vs. not taken.

on many riscs, this will be a penalty of 1-2 cycles because of bubbles
in the pipeline, or because much of the pipeline will have to be
invalidated. 

on the mips, the profiler and optimizer would notice that the branch
is unlikely to be taken, and it would rearrange the code for
optimality. 

on the rs/6000, the jump will probably be executed early in the
pipeline and there will be no penalty.  in fact, the branch will
appear to take 0 cycles.

just for handy reference, let us take one cycle as 50 ns.  this is a
relatively slow machine anymore.

so how much will the penalty be?

   This part of the code ten million, anyhow.

hmmm.... ten million times one cycle comes out to .... 500
milliseconds.

so, mister rubin is SOOOO worried about his monte carlo program that
he will spend all this effort to save half a second of run time on a
program that probably runs for at least minutes.

   > If you can achieve 80% of the speed in 20% of the programming time,
   > isn't it worth it? 

   More likely 30% of the speed in 120% of the programming time.

and then he overestimates his own value and his own effectiveness by
an enormous factor.

i don't think that he has much of an argument when he makes claims
like this.

--
	Offer void except where prohibited by law.
Technical Details
Message-ID: <TED.90Jul31133555@kythera.nmsu.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!lanl!nmsu!opus!ted
References: <1991@key.COM> <2378@l.cc.purdue.edu> <ARS4N0F@xds13.ferranti.com> <1990Jul30.183426.26506@lth.se> <2419@l.cc.purdue.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!lanl!nmsu!opus!ted
From: ted@nmsu.edu (Ted Dunning)
Newsgroups: comp.lang.misc
Subject: Re: Efficient Fortran
Message-ID: <TED.90Jul31133555@kythera.nmsu.edu>
Date: 31 Jul 90 19:35:55 GMT
References: <1991@key.COM> <2378@l.cc.purdue.edu> <ARS4N0F@xds13.ferranti.com> <1990Jul30.183426.26506@lth.se> <2419@l.cc.purdue.edu>
Sender: news@NMSU.edu
Organization: NMSU Computer Science
Lines: 62
In-reply-to: cik@l.cc.purdue.edu's message of 31 Jul 90 13:46:05 GMT