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

Glen Foy lisp at clairvaux.org
Mon May 18 15:50:02 UTC 2009


On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote:

> 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.

Thanks for the info.

The quality of the responses on this list is really quite remarkable.






More information about the Openmcl-devel mailing list