[gclist] Finalizers & Reference counting.
Thu, 29 Aug 2002 12:46:45 -0500
Greg Hudson wrote (Thu, Aug 29, 2002 at 11:05:10AM -0400) :
> Linus probably knows more about gcc than I do, but I think spending lots
> of time in the kernel may have skewed his judgment. Visible performance
> problems in the real world almost always stem from algorithms with poor
> scaling characteristics (O(n^2) or worse, where n is actually growing
> large). Not cache locality, not "hot spots" which need to be
> hand-optimized, not anything like that.
> Kernel programmers live in a world where cycle-counting optimizations
> may make sense: every program on the system uses the kernel, so every
> clock cycle you save in a common system call shaves off a little bit of
> time for every program anyone runs. libc programmers live in the same
> world. Everyone else should be looking at their algorithms and ignoring
> the rest.
I agree somewhat with your philosophy that
application writers should not waste time being
bean counters, trying to squeeze out 1% here
and 2% there.
On the other hand, I don't think you can
forget about the hardware and the system
that your app runs on. Or about working
sets and locality of reference.
It's quite possible to have two programs
that use algorithms of the same time complexity
but which have radically different memory access
patterns, causing a huge difference in performance.
You can most easily see this happening in numerical
applications on parallel computers, and I'm
sure you can see it in GC and other "real-world"
non-kernel/non-library applications too.
Predicting performance on modern
hardware can be tough with caches and
predictors. Hardware multithreading (e.g.,
Pentium 4 hyperthreading) can make it even more so.
The idea is not to spend all your time
worrying about low-level stuff but
to use good profiling tools so you
can see where your app spends time
when it runs on modern systems and
then try to do CPU/cache/TLB-optimizations
if they are causing problems.
That's what the GCC folks are trying
to do right now, to find the
source of the problem. Linus is
definitely biased, though :)
My 2 cents,