Re: Finalizers & Reference counting.

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,

	Manoj