On 2/20/07, John Francis <[EMAIL PROTECTED]> wrote: > > People can get carried away by the search for performance. > As a rough-and-ready rule of thumb I don't generally bother to > try too hard for anything less than a factor of two in speed, > especially if doing so would add to the complexity of the code.
Thats true for us too, except for the core processing engine, in which 10% can mean alot. > Avoid obvious inefficiencies, of course, and try to use an > approach that optimizes data locality. But structuring the > inner loop of an algorithm to match today's processors (or, > even worse, writing it in assembly code) is generally a bad > idea - modern compilers generally attain within 10% of the > optimal instruction stream (and know how best to change this > when processor design changes). Most of our inner loop is very mathemetically oriented, so structuring the way the data is fed into the operations lets the compiler find things like vectorized instructions in some of today's advanced processors. For a very specific gain, it might be worth it to tune the assembly language, but its rare. > > And, of course, you need to know where to focus your effort. > I've just redesigned one (particularly bad) implementation > to get about two orders of magnitude in performance. I'm > sure that with another week of effort I could probably get > another factor of two (or maybe three) out of this code, at > a significant cost in clarity (and risk of obscure bugs). > But I'm not going to bother, because the current design is > now only about 1/3 of the total processing time (instead > of dominating everything). Even if I reduced the time that > is spent in this code to nothing, that would still only net > about 25%-30% of a performance gain in the total system. > > > > On Tue, Feb 20, 2007 at 06:35:51PM +0100, Thibouille wrote: > > This seems to me a lot more reasonable, if not mandatory. > > > > 2007/2/20, Gonz <[EMAIL PROTECTED]>: > > > At my work we have to count bytes very carefully. Our product has to > > > analyze objects with tens or even hundreds of millions of entities in > > > real time, the representation of those entities has to be very > > > compact, otherwise you can run out of memory quickly. The inner most > > > loop of the program itself has to be extremely efficient, otherwise an > > > inefficiency somewhere can cost hours of CPU time. And we are > > > competing with other vendors who are trying to get any margin of speed > > > or memory advantage to make a sale. > > > > > > rg > > > > > > > > > On 2/19/07, Thibouille <[EMAIL PROTECTED]> wrote: > > > > Today it is the opposite, I realize at school teachers always tought > > > > us that performance wasn't a big deal since power of computers was > > > > going up so much anyway. > > > > > > > > In my limited experience, it made people not care at all about > > > > performance which is pretty puch stupid. Of course spending a byte > > > > more or less here and there is a silly question but no care about > > > > performance !? > > > > > > > > Never understood their POV. Maybe it goes all too fast for them ;) > > > > > > > > > > > > 2007/2/19, P. J. Alling <[EMAIL PROTECTED]>: > > > > > I worked on projects where saving a couple of bytes in a character > > > > > string ended up in hardware/storage savings figures in the Millions of > > > > > dollars. The Y2K problem was mostly the result of that kind of > > > > > analysis. > > > > > > > > > > Bruce Dayton wrote: > > > > > > Kind of reminds me of the Y2K problem - the older programmers > > > > > > thought > > > > > > they wouldn't need to deal with it, so didn't...until... > > > > > > > > > > > > Since you know you are going to end up with the problem, why not > > > > > > just > > > > > > come up with a solution now, instead of having to go back and fix it > > > > > > later? The solutions aren't really too tough. > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > -- > > > > > > > > > > The more I know of men, the more I like my dog. > > > > > -- Anne Louise Germaine de Stael > > > > > > > > > > > > > > > -- > > > > > PDML Pentax-Discuss Mail List > > > > > [email protected] > > > > > http://pdml.net/mailman/listinfo/pdml_pdml.net > > > > > > > > > > > > > > > > > -- > > > > > > > > Thibault Massart aka Thibouille > > > > ---------------------- > > > > *ist-D,Z1,SuperA,KX,MX, P30t and KR-10x ;) ... > > > > > > > > -- > > > > PDML Pentax-Discuss Mail List > > > > [email protected] > > > > http://pdml.net/mailman/listinfo/pdml_pdml.net > > > > > > > > > > -- > > > PDML Pentax-Discuss Mail List > > > [email protected] > > > http://pdml.net/mailman/listinfo/pdml_pdml.net > > > > > > > > > -- > > > > Thibault Massart aka Thibouille > > ---------------------- > > *ist-D,Z1,SuperA,KX,MX, P30t and KR-10x ;) ... > > > > -- > > PDML Pentax-Discuss Mail List > > [email protected] > > http://pdml.net/mailman/listinfo/pdml_pdml.net > > -- > PDML Pentax-Discuss Mail List > [email protected] > http://pdml.net/mailman/listinfo/pdml_pdml.net > -- PDML Pentax-Discuss Mail List [email protected] http://pdml.net/mailman/listinfo/pdml_pdml.net
