I totally agree with you John. I just felt that some do think (teachers in this case) that perforpance was not an issue at all.
2007/2/20, John Francis <[EMAIL PROTECTED]>: > > 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. > 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). > > 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 > -- 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
