On 08/12/12 23:12, Yuras Shumovich wrote:
Hi,
I'm working on that issue as an exercise/playground while studding the
GHC internals: http://hackage.haskell.org/trac/ghc/ticket/693
It's not at all clear that we want to do this. Perhaps you'll be able
to put the question to rest and close the ticket!
First I tried just to replace "ccall lockClosure(mvar "ptr")" with
GET_INFO(mvar) in stg_takeMVarzh and stg_putMVarzh and got 60% speedup
(see the test case at the end.)
Then I changed lockClosure to read header info directly when
enabled_capabilities == 1. The speedup was significantly lower, <20%
I tried to hack stg_putMVarzh directly:
if (enabled_capabilities == 1) {
info = GET_INFO(mvar);
} else {
("ptr" info) = ccall lockClosure(mvar "ptr");
}
You should use n_capabilities, not enabled_capabilities. The latter
might be 1, even when there are multiple capabilities actually in use,
while the RTS is in the process of migrating threads.
But got no speedup at all.
The generated asm (amd64):
movl $enabled_capabilities,%eax
cmpq $1,%rax
je .Lcgq
.Lcgp:
movq %rbx,%rdi
subq $8,%rsp
movl $0,%eax
call lockClosure
addq $8,%rsp
.Lcgr:
cmpq $stg_MVAR_CLEAN_info,%rax
jne .Lcgu
{...}
.Lcgq:
movq (%rbx),%rax
jmp .Lcgr
It moves enabled_capabilities into %eax and then compares 1 with %rax.
It looks wrong for me: the highest part of %rax remains uninitialized.
As Axel noted, this is correct.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
