Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 May 2003 16:45:44 +0200
From:      Alexander Leidinger <Alexander@Leidinger.net>
To:        freebsd-performance@freebsd.org
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Optimizations.
Message-ID:  <20030515164544.6ade3b2e.Alexander@Leidinger.net>
In-Reply-To: <20030515123033.GP45118@garage.freebsd.pl>
References:  <20030515123033.GP45118@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 15 May 2003 14:30:33 +0200
Pawel Jakub Dawidek <nick@garage.freebsd.pl> wrote:

> IMHO optimization in FreeBSD's code has too low priority.
> Maybe is time to think about some 'optimiztion team' creation?

The actual goal is to finish the "SMPng"-feature (and other new 5.x
technologie). After that  the "roadmap" (there's no official one, but if
you read -current you read sometimes about what is written on the TODO
lists) says something about optimizing those features. You know,
premature optimization is evil, do you?

> value is. They should have experience in old-school optimization (there are
> many places where '* (2^n)' could be changed to '<< n' and many places where

Are you sure? Compare the produced code, if the value is known to be a
power of 2 at compile time, this optimization gets already performed by
the compiler. Regardless of the fact that todays compilers already do a
good job with such easy optimizations, not every place where you could
improve the produced code is worth to improve in such a way (if you
improve the code by 1ms but the complete "action" takes 1000ms it isn't
worth... and optimizing algorithms gives you most of the time much more
bang for the bucks...). Personally I prefer readability of the algorithm
instead of speed in such situations.

The actual performance difference between gcc and icc doesn't comes from
such optimizations, its from using SIMD code and from scheduling the
instructions in a different way (on a P4 you get huge benefits from
this), so the time is better spend on improving those aspects of gcc
instead.

Bye,
Alexander.

-- 
     The three Rs of Microsoft support: Retry, Reboot, Reinstall.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7



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