[M3devel] user threads

[Mika Nystrom]

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