[M3devel] user threads

[Tony Hosking]

Mika, it is not surprising that your lock-on-every variable update  
will cost a lot in any non-user-level threading scheme.  You should  
consider using different mechanisms for this degree of locking in  
Scheme (based on some of the non-blocking lock implementations for  
Java perhaps).  I don't expect any implementation of locking for a  
multi-core/-processor will ever perform as well as user-level threads.

On 29 Apr 2009, at 16:53, Mika Nystrom wrote:

> Ok, it works!
>
> Numbers:
>
> Timings in milliseconds, three samples, filesystem "warmed up" by
> doing one dummy run before launching the real ones.
>
> -unsafe means that I use non-locking Scheme environments, otherwise
> they lock for every variable update.
>                                                             ave
> CM3 last week, kernel threads, -unsafe   1460  1482  1437   1460
> CM3 last week, kernel threads,           2392  2402  2376   2390
> CM3 this week, kernel threads, -unsafe   1455  1458  1490   1468 (*)
> CM3 this week, user threads,   -unsafe    914   934   914    921
> CM3 this week, user threads,              967   965   986    973
> PM3                            -unsafe    678   657   682    672
> PM3                                       709   714   700    708
>
> (*) not entirely sure this got linked correctly.
>
>    Mika
>
>
> Jay writes:
>>
>> User threads seem to work on on FreeBSD/x86 7.0.
>> Mika can you report back the perf cm3 vs. pm3?
>> Still, kernel threads have been around a long time and imho should  
>> be strongly favored..
>>
>>
>> Kernel threads should be a /little/ faster than they were --  
>> PushEFrame removed from successful heap allocations. And should be  
>> further improvable via __thread where it is supported -- probably  
>> not FreeBSD 4.
>> x, sometimes older is not better. :)
>>
>>
>> I've temporarily switched FreeBSD/x86 to userthreads by default but  
>> I think that's just an experiment and should be undone shortly,  
>> maybe work out some other story for easily switching between them,  
>> or just k
>> eep the existing story of "you get to rebuild everything".
>>
>>
>> Tony, can you look into GetGCRatio? I removed the call to it. The  
>> "fatal" pragma invokes PushEFrame apparently.
>>
>>
>> We should now "fix" Win32 and pthreads to not have GetActivation  
>> initialize on-demand, just leave Init to initialize always. This  
>> should shave a few more cycles from PushEFrame.
>>
>>
>> - Jay