Path: 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: Date: 31 Jul 90 19:35:55 GMT References: <1991@key.COM> <2378@l.cc.purdue.edu> <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 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.