CPU hogging in the current master

[Robert Helling]

On 26.09.2013, at 05:42, Linus Torvalds <torvalds at linux-foundation.org> wrote:

Linus,

> a) the one-liner patch to profile.c just says "we don't bother 
>    calculating TTS at 10s granularity, just do one-minute one"
> 
> b) stop doing the (very expensive) pow() calculation every time.
> 
> The two are independent, and it could be two separate commits, but I think 
> both of these fall under the issue of "don't waste CPU time", so here it 
> is as one patch.
> 
> I think (a) is pretty obvious, no need to expose on that any more.
> 
> But (b) is slightly more complicated. It re-organizes the saturation 
> calculations to be in my opinion clearer: we used to have the "one second" 
> case completely separate from the "generic interval" case, and this undoes 
> that.
> 
> It *does* keep the special static cache for the one-second buehlmann 
> factors, and expands that with a *dynamic* cache for each tissue index 
> that contains the previous value of the buehlmann factor for a particular 
> duration.
> 
> The point is, usually we end up using some fixed duration, so the cache 
> hit ratio is quite high. And doing a memory load from a cache is *much* 
> faster than calculating exponentials.
> 
> Somebody should double-check that I didn't do anything bad when I 
> re-organized the math, but quite frankly, I think my code is easier to 
> read than the old code. Not that that protects us from typos or thinkos.

I take this as a prompt to comment. I think both the idea and the code are right. I also agree that the point for treating one second special is probably also gone. I did some quick testing comparing the responsiveness between your version and one where I commented out the test for the special one second case. Of course the latter should be slightly faster when the interval is not one second while it is slower in the one second case (as the if condition and the look up is more complicated) but I couldn't notice any difference in snappiness when selecting the trimix dives from the test cases (the case that started that thread) while in the planner planning for a five hour dive the continuous update seems to be a bit faster with the special 1s case. But that difference is so small that I would sacrifice it in the interest of simpler logic in the code.

Since now, for the TTS calculation we only compute in multiples of minutes there is I think still a case for not computing it for every sample but only once or twice per minute of bottom time but I would not bother too much since at least for my taste and my recently bought IMac it is already fast enough.

Best
Robert

-- 
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO
Robert C. Helling     Elite Master Course Theoretical and Mathematical Physics
                      Scientific Coordinator
                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik
                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339
                      http://www.atdotde.de

Enhance your privacy, use cryptography! My PGP keys have fingerprints
A9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    and
DCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130926/20462c5f/attachment.sig>