[M3devel] user threads

[Tony Hosking]

Jay, I think you are trying to optimize the unoptimizable if I  
understand that Mika uses locking as heavily as he seems to.

On 29 Apr 2009, at 17:05, Jay wrote:

> 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/20090430/a4eb7cc0/attachment-0002.html>