Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Jun 2000 17:53:52 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        "Daniel C. Sobral" <dcs@newsguy.com>
Cc:        "Anatoly Vorobey" <mellon@pobox.com>, "Zach Brown" <zab@zabbo.net>, hackers@FreeBSD.ORG
Subject:   Re: Optimization
Message-ID:  <200006060053.RAA89067@apollo.backplane.com>
References:   <200006060031.JAA00841@daniel.sobral>

next in thread | previous in thread | raw e-mail | index | archive | help
:> > > > Alternative A:
:> > > > 
:> > > > 	x = table[i].x;
:> > > > 	y = table[i].y;
:> > > > 
:> > > > Alternative B:
:> > > > 
:> > > > 	d = table[i];
:> > > > 	x = d & MASK;
:> > > > 	y = d >> SHIFT;

    In general I wouldn't bother spending time trying to hand-optimize
    the code like this, especially if the result is less readable.   The 
    difference is going to be in the noise verses the cost of a cache miss.
    Just use method #A.

    But if you really want to, keep in mind that simple ALU operations 
    such as addition, subtraction, and, or, and xor, are typically cheap.
    Shift instructions are often more expensive (depending on whether the
    cpu implements a barrel shifter or not).  

    If you want to optimize code on a modern cpu the best thing to do is
    to pay careful attention to memory cache issues and choose the right
    algorithms... and pretty much ignore everything else.  What that means,
    in general, is that you should try to cluster memory items that are
    referenced together.  This will almost certainly result in a much
    greater performance benefit then trying to save a few 1-cycle instructions
    here and there.

    If you want to optimize code in a reasonably-portable way you should
    also stay away from introducing new shift instructions.

    It takes a relatively sophisticated benchmark to really determine cache
    load.  Writing a little tightly-looped timing program will give you false
    results.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006060053.RAA89067>