[M3devel] user threads

[Jay]

Mika, thanks. Want to try the next variation? look at m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c.

See THREAD_LOCAL, THREAD_LOCAL_SLOW, THREAD_LOCAL_FAST? Try switching THREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD 5.x or newer.

It won't compile for 4.x we know.

 

Thanks,

 - Jay

 
> To: jay.krell at cornell.edu
> Date: Tue, 28 Apr 2009 23:53:32 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] user threads
> 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090429/36b615fb/attachment-0002.html>