[M3devel] user threads
jay.krell at cornell.edu
jay.krell at cornell.edu
Thu Apr 30 12:17:58 CEST 2009
No need for clean here. Lets punt threads for now and look at typecase.
- Jay (phone)
On Apr 30, 2009, at 1:58 AM, Mika Nystrom <mika at async.caltech.edu>
wrote:
> 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