<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Mika, thanks. Want to try the next variation? look at m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c.<BR>
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.<BR>
It won't compile for 4.x we know.<BR>
<BR>
Thanks,<BR>
- Jay<BR><BR> <BR>> To: jay.krell@cornell.edu<BR>> Date: Tue, 28 Apr 2009 23:53:32 -0700<BR>> From: mika@async.caltech.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] user threads<BR>> <BR>> Ok, it works!<BR>> <BR>> Numbers:<BR>> <BR>> Timings in milliseconds, three samples, filesystem "warmed up" by<BR>> doing one dummy run before launching the real ones.<BR>> <BR>> -unsafe means that I use non-locking Scheme environments, otherwise<BR>> they lock for every variable update.<BR>> ave <BR>> CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460<BR>> CM3 last week, kernel threads, 2392 2402 2376 2390<BR>> CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*)<BR>> CM3 this week, user threads, -unsafe 914 934 914 921<BR>> CM3 this week, user threads, 967 965 986 973<BR>> PM3 -unsafe 678 657 682 672<BR>> PM3 709 714 700 708<BR>> <BR>> (*) not entirely sure this got linked correctly.<BR>> <BR>> Mika<BR>> <BR>> <BR>> Jay writes:<BR>> ><BR>> >User threads seem to work on on FreeBSD/x86 7.0.<BR>> >Mika can you report back the perf cm3 vs. pm3?<BR>> >Still, kernel threads have been around a long time and imho should be strongly favored..<BR>> > <BR>> > <BR>> >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.<BR>> >x, sometimes older is not better. :)<BR>> > <BR>> > <BR>> >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<BR>> >eep the existing story of "you get to rebuild everything".<BR>> > <BR>> > <BR>> >Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently.<BR>> > <BR>> > <BR>> >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.<BR>> > <BR>> > <BR>> > - Jay<BR></body>
</html>