[Openmcl-devel] Speed, compilers and multi-core processors

[Brian Mastenbrook]

On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote:

> My ignorance of compiler design is breathtaking, but could multi-core
> compiler techniques be used to compensate for Intel's register-starved
> architecture?

In a word, no.

The problem with Intel's register-starved architecture is that as a
compiler author it's difficult to work with a very small set of
registers without overflowing to locations on the stack. Dealing with
temporaries on the stack, while usually quite performant due to register
renaming at the hardware level, gets quite difficult to juggle
especially if your compiler was originally developed on an architecture
where there are enough registers to always leave a few open for
temporaries.

Talking about "multi-core compiler techniques" is a bit like "alchemy"
right now. Nobody's really quite sure what works, especially when it
comes to languages that mere mortals can write. There's also quite a bit
of tension between the desire for functional programming as a means to
save ourselves from mutable shared state and the intrinsic dependency of
garbage collection on same.

The relationship between multi-core and the register-poor x86
architecture isn't great, except that it probably increases the number
of things you've got to keep in a register and thus exacerbates the
issue.

For what it's worth, x86-64 isn't all that register-starved, which is
why some programs show a great improvement when compiled for 64-bit even
when you'd expect only a performance loss due to the increase in pointer
width. It's not quite like working on PowerPC or SPARC, but it isn't
half bad. As a practical matter, it's probably safe to assume that any
system with more than two cores (real or virtual hyper-threaded) is
64-bit; all of Intel's existing CPUs certainly hold to this pattern.
-- 
Brian Mastenbrook
brian at mastenbrook.net
http://brian.mastenbrook.net/