On Thu, Mar 29, 2001 at 11:29:16AM -0500, Dan Sugalski wrote:
> 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:
(Sorry if I sounded too blunt, the other stuff in the PDD was fine.)
> >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
[snip]
Yes. Rules of thumb are good, sort of like common lore of how
CPUs in general work. I would like to add the overall principle of
optimizing for speed first (that is, at the expense of space, e.g.
by using wide integer types) (worry about space later, if needed),
and avoiding division/modulus. Perhaps the rule #0 would be:
measure before you optimize. Concentrate on the hotspots, instead
of wasting your time honing some obscure rarely executed code.
An additional coding guideline could be:
* Extensibility guidelines
(This is not the same as 'portability.')
One particular detail I've noticed cropping up would be to avoid using
char* (or {char*,length}) if it is feasible to later use a SV*
(perl5-speak) at the same spot. An example: UTF-8 hash keys in Perl5.
The same goes for flag fields: only if you can be fairly certain
that the number of flags never exceeds 32, should you use an int.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
