At 05:19 PM 3/29/2001 +0100, Dave Mitchell wrote:
>Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> > Somewhat tangentially: this reminds me of a message a week ago or so
> > (can't find it anymore in my inbox) which proposed writing C (or C++)
> > code for Perl 6 so that "modern CPU architectures are happy" (no
> > pipeline stalls because of "if"-s, etc.) Hello? This is a very
> > high-level language we are writing, not a DSP core. Optimizing by
> > choosing good algorithms and data structures, yes, microoptimizing,
> > maybe, only after the code works first, and even then we would be
> > following the mirage since CPU architectures do evolve, and in
> > general, for large codebases, the C compilers are much, much, better
> > in optimizing than humans. Yes, a human can sit down and read
> > the databooks and optimize a simple algorithm to hell and back.
> > But megabytes of source code? Get real.
>
>That may have been me:
>
>http://archive.develooper.com/perl6-internals%40perl.org/msg02685.html
>
>(PDD for coding conventions)
>
>The main thrust of that was whether a PDD on coding conventions
>should have sections on:
>* Coding style
>* Naming conventions
>* Commenting conventions
>* Portability guidelines
>* Performance guidelines
>
>Based on your comments above (which I hearily agree with), I guess
>we can safely dispense with that last entry.
Don't. Hand-optimizing the C code's pretty silly generally, but there are
some reasonable rules of thumb that can gain enough of a performance boost
to be worthwhile. Not returning values when not needed, cutting down on the
number of parameters (especially ones that end up being a constant, and the
same constant, every time), and proper alignment and grouping of structures
are all done with little programmer cost but good benefit.
Structure alignment and grouping is probably the big one that'll reap the
most benefit for the smallest cost. If you have two fields that would fit
in your average cache line (8 or 16 bytes) then keeping them together makes
sense. Keeping structures of a size such that they align nicely in cache
lines is also a good thing.
No, these won't buy us a 20% speed increase, but if something as simple as
a struct reordering buys us a few tenths of a percent it seems worth the
little effort it takes to do it.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
