<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.1">
</HEAD>
<BODY>
Hi Simon,
<BLOCKQUOTE TYPE=CITE>
<PRE>
> OK, the code I have checked out from the repository contains this in
> "rts/sm/Storage.h":
>
> extern bdescr * pinned_object_block;
>
>
> And in "rts/sm/Storage.c":
>
> bdescr *pinned_object_block;
Ah, I was looking in the HEAD, where I've already fixed this by moving
pinned_object_block into the Capability and hence making it CPU-local.
The patch that fixed it was
Tue Dec 1 16:03:21 GMT 2009 Simon Marlow <<A HREF="mailto:marlowsd@gmail.com">marlowsd@gmail.com</A>>
* Make allocatePinned use local storage, and other refactorings
</PRE>
</BLOCKQUOTE>
<BR>
The version I have checked out is 6.12 and that's why I haven't seen this patch.<BR>
Are there any plans for including this patch in the next GHC release?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Yes, this was also fixed by the aforementioned patch.
Bear in mind that in the vast majority of programs allocatePinned is not
in the inner loop, which is why it hasn't been a priority to optimise it
until now.
</PRE>
</BLOCKQUOTE>
I guess the code which makes use of ByteStrings (especially, when it splits them into many smaller substrings) calls to allocatePinned very frequently even within inner loops.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
TSO-local would be bad: TSOs are lightweight threads and in many cases
are smaller than a block. Capability-local is what you want.
</PRE>
</BLOCKQUOTE>
Ah... Yes, capabilities are a far better choice.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Right, but these are not common cases that need to be optimised. newCAF
is only called once per CAF, thereafter it is accessed without locks.
</PRE>
</BLOCKQUOTE>
Can't recall from the top of my head, but I think I had a case when newCAF was used very actively in a simple piece of code. The code looked like this:<BR>
<BR>
sequence_ $ replicate N $ doSmth<BR>
<BR>
The Cmm code showed that it produced calls to newCAF and something related to black holes. And when I added "return ()" after that line, the black holes new calls to "newCAF" have disappeared. It was on 6.12.1, I believe. I still have no idea why it happened and why these black holes where necessary, but I'll try to reproduce it one more time and show you an example if it has any interest for you.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
It may be that we could find benchmarks where access to the block
allocator is the performance bottleneck, indeed in the parallel GC we
sometimes see contention for it. If that turns out to be a problem then
we may need to think about per-CPU free lists in the block allocator,
but I think it would entail a fair bit of complexity and if we're not
careful extra memory overhead, e.g. where one CPU has all the free
blocks in its local free list and the others have none. So I'd like to
avoid going down that route unless we absolutely have to. The block
allocator is nice and simple right now.
</PRE>
</BLOCKQUOTE>
<BR>
I suppose I should check out the HEAD then and give it a try, because earlier I had performance issues in the threaded runtime (~20% of overhead and far more noise) in an application which was doing some slicing, reshuffling and composing text via ByteStrings with a modest amount of passing data around via "Chan"s.<BR>
<BR>
On a slightly different topic: please could you point me to a place where stg_upd_frame_info is generated? I can't find it in *.c, *.cmm or *.hs and guess it is something very special.<BR>
<BR>
With kind regards,<BR>
Denys Rtveliashvili
</BODY>
</HTML>