Re: Coroutines, goroutines
Charles Zhang via Sbcl-devel <[email protected]> Thu, 7 May 2026 10:02:15 +0000 (UTC)
| Newsgroups | gmane.lisp.steel-bank.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============2122252346464895512== Content-Type: multipart/alternative; boundary="----=_Part_7089251_115335882.1778148135387" Content-Length: 10057 ------=_Part_7089251_115335882.1778148135387 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jesse, That=E2=80=99s nice that you=E2=80=99ve also taken a stab at this. I don=E2= =80=99t have much time for detailed code review at the moment (maybe at ELS= next week I could take a look). If it=E2=80=99s possible, if=C2=A0you give= a higher level description of how the implementation works (e.g. specials,= unwind protect, scheduling, gc, backend abstractions), I could already tak= e a look and give some feedback. Best,Charles On Wednesday, May 6, 2026, 5:47 PM, Jesse Bouwman via Sbcl-devel <sbcl-deve= [email protected]> wrote: Hi, I'd like to resuscitate this, uh, thread :), and present a third option= for fiber support, which has been tracking along for a little while on my = SBCL fork: https://github.com/jbouwman/sbcl/tree/sb-fiber-x86-64-pr1https://github.com= /jbouwman/sbcl/tree/sb-fiber-arm64-pr1 (the latter builds on the former) This maybe lies somewhere in between Kartik's (hi Kartik!) work and Anthony= 's: it leaves the scheduler (and io primitives) to the user, by just provid= ing a sb-fiber:fiber-switch operation, alongside other basic lifecycle func= tions. Also, it doesn't support migration between threads. That said, I've stress tested it for a few weeks on some (epoll, kqueue bac= ked) webservices and benchmarks, and it feels reliable now. =C2=A0Switch ti= me is on the order of 100ns, GC pauses scale linearish, with about 500 ms p= ause at 100,000 fibers, on a 36 processor/72 thread x86 machine with 128G o= f memory. A benchmarking script, and the output of a recent run are at=C2=A0https://g= ist.github.com/jbouwman/1c68bf39c2cbdfc403754d8632d25be3 Building either of the branches with --with-sb-fiber should allow the scrip= t to run. I haven't benchmarked ARM64. I'd be happy to correspond with any interested parties about improvements, = it's a delicate area and I'm contain I'm overlooking important factors. Cheers,Jesse On Feb 28, 2026, at 3:39=E2=80=AFPM, Scott L. Burson <[email protected]>= wrote: On Fri, Feb 27, 2026 at 10:07=E2=80=AFPM Scott L. Burson <Scott@sympoiesis.= com> wrote: On Fri, Feb 27, 2026, 8:21=E2=80=AFPM Stelian Ionescu <[email protected]> w= rote: When a fiber is created, we allocate it a single 4kB stack page, placing th= e mprotect'ed guard page next to it, but we spread these out in address spa= ce at, say, 256kB intervals (configurable).=C2=A0 Then when the guard page = is hit, we can grow the stack without moving it.=C2=A0=C2=A0 The resulting fragmentation of the virtual memory space will create all sor= ts of performance problems in the kernel, will prevent the use of hugepages= (transparent or not), cause TLB pressure, etc... It would prevent the use of hugepages, but I'm not convinced of your other = two claims.=C2=A0 [...] Speaking of being only human, I overlooked a more telling point: the number= of kernel segment table entries is unchanged under my proposal, relative t= o what Anthony has implemented, because there's already a guard page for ev= ery fiber stack.=C2=A0 So if we're going to run into kernel performance pro= blems, we'll do so anyway.=C2=A0 But I don't expect that. -- Scott _______________________________________________ Sbcl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sbcl-devel ------=_Part_7089251_115335882.1778148135387 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html xmlns=3D"http://www.w3.org/1999/xhtml" xmlns:v=3D"urn:schemas-microso= ft-com:vml" xmlns:o=3D"urn:schemas-microsoft-com:office:office"><head><!--[= if gte mso 9]><xml><o:OfficeDocumentSettings><o:AllowPNG/><o:PixelsPerInch>= 96</o:PixelsPerInch></o:OfficeDocumentSettings></xml><![endif]--></head><bo= dy> Hi Jesse,<div><br></div><div>That=E2=80=99s nice that you=E2=80=99ve also t= aken a stab at this. I don=E2=80=99t have much time for detailed code revie= w at the moment (maybe at ELS next week I could take a look). If it=E2=80= =99s possible, if you give a higher level description of how the imple= mentation works (e.g. specials, unwind protect, scheduling, gc, backend abs= tractions), I could already take a look and give some feedback.</div><div><= br></div><div>Best,</div><div>Charles<br><br><p class=3D"yahoo-quoted-begin= " style=3D"font-size: 15px; padding-top: 15px; margin-top: 0">On Wednesday,= May 6, 2026, 5:47 PM, Jesse Bouwman via Sbcl-devel <[email protected]= urceforge.net> wrote:</p><blockquote class=3D"iosymail"><div id=3D"yiv84= 76300949"><div>Hi, I'd like to resuscitate this, uh, thread :), and present= a third option for fiber support, which has been tracking along for a litt= le while on my SBCL fork:<div><br clear=3D"none"></div><div>https://github.= com/jbouwman/sbcl/tree/sb-fiber-x86-64-pr1</div><div>https://github.com/jbo= uwman/sbcl/tree/sb-fiber-arm64-pr1</div><div><br clear=3D"none"></div><div>= (the latter builds on the former)</div><div><br clear=3D"none"></div><div>T= his maybe lies somewhere in between Kartik's (hi Kartik!) work and Anthony'= s: it leaves the scheduler (and io primitives) to the user, by just providi= ng a sb-fiber:fiber-switch operation, alongside other basic lifecycle funct= ions. Also, it doesn't support migration between threads.</div><div><br cle= ar=3D"none"></div><div>That said, I've stress tested it for a few weeks on = some (epoll, kqueue backed) webservices and benchmarks, and it feels reliab= le now. Switch time is on the order of 100ns, GC pauses scale lineari= sh, with about 500 ms pause at 100,000 fibers, on a 36 processor/72 thread = x86 machine with 128G of memory.</div><div><br clear=3D"none"></div><div>A = benchmarking script, and the output of a recent run are at https://gis= t.github.com/jbouwman/1c68bf39c2cbdfc403754d8632d25be3</div><div><br clear= =3D"none"></div><div>Building either of the branches with --with-sb-fiber s= hould allow the script to run.</div><div><br clear=3D"none"></div><div>I ha= ven't benchmarked ARM64.</div><div><br clear=3D"none"></div><div>I'd be hap= py to correspond with any interested parties about improvements, it's a del= icate area and I'm contain I'm overlooking important factors.</div><div><br= clear=3D"none"></div><div>Cheers,</div><div>Jesse</div><div><br clear=3D"n= one"></div><div><br clear=3D"none"></div><div id=3D"yiv8476300949yqt20132" = class=3D"yiv8476300949yqt0701323647"><div><div><br clear=3D"none"><blockquo= te type=3D"cite"><div>On Feb 28, 2026, at 3:39=E2=80=AFPM, Scott L. Burson = <[email protected]> wrote:</div><br clear=3D"none" class=3D"yiv847= 6300949Apple-interchange-newline"><div><div dir=3D"ltr"><div dir=3D"ltr">On= Fri, Feb 27, 2026 at 10:07=E2=80=AFPM Scott L. Burson <<a rel=3D"nofoll= ow noopener noreferrer" shape=3D"rect" ymailto=3D"mailto:[email protected]= om" target=3D"_blank" href=3D"mailto:[email protected]">Scott@sympoiesis= .com</a>> wrote:</div><div class=3D"yiv8476300949gmail_quote yiv84763009= 49gmail_quote_container"><blockquote style=3D"margin:0px 0px 0px 0.8ex;bord= er-left:1px solid rgb(204,204,204);padding-left:1ex;" class=3D"yiv847630094= 9gmail_quote"><div><div class=3D"yiv8476300949gmail_quote"><div dir=3D"ltr"= class=3D"yiv8476300949gmail_attr">On Fri, Feb 27, 2026, 8:21=E2=80=AFPM St= elian Ionescu <<a rel=3D"nofollow noopener noreferrer" shape=3D"rect" ym= ailto=3D"mailto:[email protected]" target=3D"_blank" href=3D"mailto:sionesc= [email protected]">[email protected]</a>> wrote:<br clear=3D"none"></div><block= quote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2= 04);padding-left:1ex;" class=3D"yiv8476300949gmail_quote"><u></u><div><div>= <br clear=3D"none"></div><blockquote id=3D"yiv8476300949m_41470040554284158= 20m_-4604271019245447063qt" type=3D"cite"><div dir=3D"ltr"><div>When a fibe= r is created, we allocate it a single 4kB stack page, placing the mprotect'= ed guard page next to it, but we spread these out in address space at, say,= 256kB intervals (configurable). Then when the guard page is hit, we = can grow the stack without moving it. </div></div></blockquote><= div><br clear=3D"none"></div><div>The resulting fragmentation of the virtua= l memory space will create all sorts of performance problems in the kernel,= will prevent the use of hugepages (transparent or not), cause TLB pressure= , etc...</div><div></div></div></blockquote></div><div><br clear=3D"none"><= /div><div>It would prevent the use of hugepages, but I'm not convinced of y= our other two claims. [...]</div></div></blockquote><div><br clear=3D= "none"></div><div>Speaking of being only human, I overlooked a more telling= point: the number of kernel segment table entries is unchanged under my pr= oposal, relative to what Anthony has implemented, because there's already a= guard page for every fiber stack. So if we're going to run into kern= el performance problems, we'll do so anyway. But I don't expect that.= </div><div><br clear=3D"none"></div><div>-- Scott</div><div><br clear=3D"no= ne"></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol= id rgb(204,204,204);padding-left:1ex;" class=3D"yiv8476300949gmail_quote"> </blockquote></div></div> </div></blockquote></div><br clear=3D"none"></div></div></div></div><div cl= ass=3D"yqt0701323647" id=3D"yqt45476">_____________________________________= __________<br clear=3D"none">Sbcl-devel mailing list<br clear=3D"none"><a s= hape=3D"rect" ymailto=3D"mailto:[email protected]" href=3D"m= ailto:[email protected]">[email protected]</a= ><br clear=3D"none"><a shape=3D"rect" href=3D"https://lists.sourceforge.net= /lists/listinfo/sbcl-devel" target=3D"_blank">https://lists.sourceforge.net= /lists/listinfo/sbcl-devel</a><br clear=3D"none"></div><blockquote></blockq= uote></blockquote></div> </body></html> ------=_Part_7089251_115335882.1778148135387-- --===============2122252346464895512== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============2122252346464895512== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sbcl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sbcl-devel --===============2122252346464895512==--