SBCL Fibers – Lightweight Cooperative Threads(atgreen.github.io)
96 pointsby anonzzzies10 hours ago8 comments
  • smallstepforman4 hours ago
    256Kb stack per Fiber is still insane overhead compared to Actors. I guess if we survey programming community, I’d guesstimate that less than 2% of devs even know what the Actor model is, and an even smaller percentage have actually used it in production.

    Any program that has at least one concurrent task that runs on a thread (naturally they’ll be more than one) is a perfect reason to switch to Actor programming model.

    Even a simple print() function can see performance boost from running on a 2nd core. There is a lot of backround work to print text (parsing font metrics, indexing screen buffers, preparing scene graphs etc) and its really inefficient to block your main application while doing all this work while background cores sit idle. Yet most programmers dont know about this performance boost. Sad state of our education and the industry.

    • atgreen3 hours ago
      256k is just's just a placeholder for now. The default will get reduced as we get more experience with the draft implementation. The proposal isn't complete yet.
    • my-next-accountan hour ago
      Actors are a model, I have no clue why you're saying that there is a particular memory cost to them on real hardware. To me, you can implement actors using fibers and a postbox.

      I've no idea what the majority of programmers know or do not know about, but async logging isn't unknown and is supported by libraries like Log4j.

    • 20k3 hours ago
      Fibers are primarily when you have a problem which is easily expressible as thread-per-unit-of-work, but you want N > large. They can be useful for eg a job system as well, and in that case the primary advantage is the extremely low context switch time, as well as the manual yielding

      There are lots of problems where I wouldn't recommend fibers though

  • nothrabannosir5 hours ago
    I strongly recommend having a look at the mailing list to get some context:

    https://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/CAF...

    and

    https://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/CAC...

    This will certainly speak to some people taking part in some of the more controversial discussions taking place on HN recently, to put it mildly.

    • anonzzzies4 hours ago
      Hmm, must have missed that ; tried to find. There was a SBCL discussion a few days ago but didn't read much controversial things in that? I'm a fanboy though so possibly i'm blind to these things.
  • matthewfcarlson9 hours ago
    I personally like the name fiber better than green threads. But everywhere I’ve worked in user space cooperative threads, it’s always been green threads.
    • lll-o-lll6 hours ago
      They are different things perhaps? Fibers imply strict cooperative behaviour; I have to explicitly “yield” to give the other fibers a go, green threads are just runtime managed threads?
  • HexDecOctBin7 hours ago
    Is there a similar document for the memory arena feature? I tried searching the official documentation, but found scant references and no instructions on how and when to use it.
  • theParadox423 hours ago
    I really thought this was gonna be a sick material science paper. Still cool though
  • lukasb4 hours ago
    Serious question - I thought LLMs were bad at balancing parentheses?
    • atgreen3 hours ago
      They are much better these days.
  • pestatije5 hours ago
    SBCL - Steel Bank Common Lisp
  • justinhj9 hours ago
    They should be called Anthony Green Threads. Seriously though, great to see.