[M3devel] user threads
Mika Nystrom
mika at async.caltech.edu
Thu Apr 30 10:58:58 CEST 2009
I have to re-build everything again? It segfaults on my 5.5 system with that
change.
Btw, here are timings on FreeBSD 5.5
libc_r 1642 ms
pthread 1646 ms
PM3 504 ms
Roughly the same program as before. Slightly different hardware (AM2 I think).
Mika
Jay writes:
>--_57af40c5-3867-4a47-915e-00f808c2e343_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Mika=2C thanks. Want to try the next variation? look at m3-libs/m3core/src/=
>thread/PTHREAD/ThreadPThreadC.c.
>
>See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try switching T=
>HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD 5.x or ne=
>wer.
>
>It won't compile for 4.x we know.
>
>=20
>
>Thanks=2C
>
> - Jay
>
>=20
>> To: jay.krell at cornell.edu
>> Date: Tue=2C 28 Apr 2009 23:53:32 -0700
>> From: mika at async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] user threads
>>=20
>> Ok=2C it works!
>>=20
>> Numbers:
>>=20
>> Timings in milliseconds=2C three samples=2C filesystem "warmed up" by
>> doing one dummy run before launching the real ones.
>>=20
>> -unsafe means that I use non-locking Scheme environments=2C otherwise
>> they lock for every variable update.
>> ave=20
>> CM3 last week=2C kernel threads=2C -unsafe 1460 1482 1437 1460
>> CM3 last week=2C kernel threads=2C 2392 2402 2376 2390
>> CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 1468 (*)
>> CM3 this week=2C user threads=2C -unsafe 914 934 914 921
>> CM3 this week=2C user threads=2C 967 965 986 973
>> PM3 -unsafe 678 657 682 672
>> PM3 709 714 700 708
>>=20
>> (*) not entirely sure this got linked correctly.
>>=20
>> Mika
>>=20
>>=20
>> Jay writes:
>> >
>> >User threads seem to work on on FreeBSD/x86 7.0.
>> >Mika can you report back the perf cm3 vs. pm3?
>> >Still=2C kernel threads have been around a long time and imho should be =
>strongly favored..
>> >=20
>> >=20
>> >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=2C sometimes older is not better. :)
>> >=20
>> >=20
>> >I've temporarily switched FreeBSD/x86 to userthreads by default but I th=
>ink that's just an experiment and should be undone shortly=2C maybe work ou=
>t some other story for easily switching between them=2C or just k
>> >eep the existing story of "you get to rebuild everything".
>> >=20
>> >=20
>> >Tony=2C can you look into GetGCRatio? I removed the call to it. The "fat=
>al" pragma invokes PushEFrame apparently.
>> >=20
>> >=20
>> >We should now "fix" Win32 and pthreads to not have GetActivation initial=
>ize on-demand=2C just leave Init to initialize always. This should shave a =
>few more cycles from PushEFrame.
>> >=20
>> >=20
>> > - Jay
>
>--_57af40c5-3867-4a47-915e-00f808c2e343_
>Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style>
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
></style>
></head>
><body class=3D'hmmessage'>
>Mika=2C =3Bthanks. Want to try the next variation? look at m3-libs/m3co=
>re/src/thread/PTHREAD/ThreadPThreadC.c.<BR>
>See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try switching T=
>HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD 5.x or&nb=
>sp=3Bnewer.<BR>
>It won't compile for 4.x we know.<BR>
> =3B<BR>
>Thanks=2C<BR>
> =3B- Jay<BR><BR> =3B<BR>>=3B To: jay.krell at cornell.edu<BR>>=3B=
> Date: Tue=2C 28 Apr 2009 23:53:32 -0700<BR>>=3B From: mika at async.caltech=
>.edu<BR>>=3B CC: m3devel at elegosoft.com<BR>>=3B Subject: Re: [M3devel] u=
>ser threads<BR>>=3B <BR>>=3B Ok=2C it works!<BR>>=3B <BR>>=3B Numbe=
>rs:<BR>>=3B <BR>>=3B Timings in milliseconds=2C three samples=2C filesy=
>stem "warmed up" by<BR>>=3B doing one dummy run before launching the real=
> ones.<BR>>=3B <BR>>=3B -unsafe means that I use non-locking Scheme env=
>ironments=2C otherwise<BR>>=3B they lock for every variable update.<BR>&g=
>t=3B ave <BR>>=3B CM3 last week=2C kernel threads=2C -unsafe 1460 1482 14=
>37 1460<BR>>=3B CM3 last week=2C kernel threads=2C 2392 2402 2376 2390<BR=
>>>=3B CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 1468 (*)<=
>BR>>=3B CM3 this week=2C user threads=2C -unsafe 914 934 914 921<BR>>=
>=3B CM3 this week=2C user threads=2C 967 965 986 973<BR>>=3B PM3 -unsafe =
>678 657 682 672<BR>>=3B PM3 709 714 700 708<BR>>=3B <BR>>=3B (*) not =
>entirely sure this got linked correctly.<BR>>=3B <BR>>=3B Mika<BR>>=
>=3B <BR>>=3B <BR>>=3B Jay writes:<BR>>=3B >=3B<BR>>=3B >=3BUser=
> threads seem to work on on FreeBSD/x86 7.0.<BR>>=3B >=3BMika can you r=
>eport back the perf cm3 vs. pm3?<BR>>=3B >=3BStill=2C kernel threads ha=
>ve been around a long time and imho should be strongly favored..<BR>>=3B =
>>=3B <BR>>=3B >=3B <BR>>=3B >=3BKernel threads should be a /littl=
>e/ faster than they were -- PushEFrame removed from successful heap allocat=
>ions. And should be further improvable via __thread where it is supported -=
>- probably not FreeBSD 4.<BR>>=3B >=3Bx=2C sometimes older is not bette=
>r. :)<BR>>=3B >=3B <BR>>=3B >=3B <BR>>=3B >=3BI've temporarily =
>switched FreeBSD/x86 to userthreads by default but I think that's just an e=
>xperiment and should be undone shortly=2C maybe work out some other story f=
>or easily switching between them=2C or just k<BR>>=3B >=3Beep the exist=
>ing story of "you get to rebuild everything".<BR>>=3B >=3B <BR>>=3B &=
>gt=3B <BR>>=3B >=3BTony=2C can you look into GetGCRatio? I removed the =
>call to it. The "fatal" pragma invokes PushEFrame apparently.<BR>>=3B >=
>=3B <BR>>=3B >=3B <BR>>=3B >=3BWe should now "fix" Win32 and pthrea=
>ds to not have GetActivation initialize on-demand=2C just leave Init to ini=
>tialize always. This should shave a few more cycles from PushEFrame.<BR>>=
>=3B >=3B <BR>>=3B >=3B <BR>>=3B >=3B - Jay<BR></body>
></html>=
>
>--_57af40c5-3867-4a47-915e-00f808c2e343_--
More information about the M3devel
mailing list