Re: [Caml-list] ocaml doesn't need to optimize on amd64??

[Kuba Ober <ober.14@osu.edu>]

On Thursday 10 January 2008, you wrote:
> Kuba Ober wrote:
> >On Wednesday 09 January 2008, you wrote:
> >>On Wed, Jan 09, 2008 at 09:22:00AM -0500, Kuba Ober wrote:
> >>>Jon & al,
> >>>
> >>>why do you think that OCaml doesn't need to do certain
> >>>optimizations on amd64? Or does it apply only to 64 bit mode?
> >>>I run my benchmarks on amd64 (in 32 bit mode) and OCaml is worse
> >>>off than gcc.
> >>
> >>Register pressure.  The extra eight registers in AMD64 make a huge
> >>difference to a lot of code generators.  Of course, to access them
> >>you need to run in 64 bit mode.
> >
> >Don't current x32 processors "emulate" extra registers anyway? I don't
> > know what's the preferred way of telling the on-chip code dissector that
> > you intend the data to say in virtual registers, but it must be something
> > simple, like common, fixed memory locations or stack locations accessed
> > in a certain way. I'm sure if you google on Intel's site you'll find it.
> > In any event, the x32 chips have a notion of "many" virtual registers,
> > it's just the old x32 opcodes that don't have it. Isn't it so?
>
> Short answer: no.
>
> The problem is that the code generated code needs to spill and fill
> registers on 32-bit x86 a lot more.  The extra registers are usefull in
> reordering instructions, and executing things in parallel (at the
> instruction level), but they can't avoid the memory accesses.  Now,
> there are a lot of tricks the CPUs play in order to reduce the costs of
> these memory accesses, but they can't eliminate the memory accesses.
> And that's the problem: you've now increases the memory pressure of the
> CPUs.

If a thread keeps those "virtual registers" in an isolated memory page that's 
accessed by nothing else, the CPU's caching will barely need to access the 
memory, as there won't be pressure from other cores or CPUs in the system to 
actually use that memory for anything. It will only get evicted to RAM if the 
cache pressure is high.

The "spill and fill" problem is really only appropriate in the context of the 
x86 registers actually existing somewhere. As far as I know, they are a 
virtual concept, there's no piece of silicon in modern x86 CPUs that can be 
called "the AX register". The actual opcodes referencing ax, bx, ... 
registers is recompiled on the fly by the CPU into a RISC-like code running 
on many more registers. Sure, the code rewriter has to work harder when 
there's more opcodes to move stuff around, but I think that it's implemented 
to actually recognize certain opcode patterns as "virtual register accesses".

I don't have any hard references on hand, but that's my impression so far. I 
can try and dig up relevant Intel references.

Cheers, Kuba