[M3devel] user threads

[Mika Nystrom]

By the way, *all* my CM3 timings have my Typecase modification,
which isn't checked in to the distribution.  I think they would all
be about 400 ms slower if they didn't have that.

A bit of "poor man's profiling" shows the program still spending
quite some time in RTType.IsSubtype (called from CheckIsType).
I think that accounts for most of the remaining difference between
PM3 and CM3.

     Mika

Mika Nystrom writes:
>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