[smallstepforman]

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.

[my-next-account]

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.

[vitaminCPP]

Yeah that was my also my thought.

I always understood that if you give a thread to each actor you get the "active object" design pattern.

[zelphirkalt]

I remember Joe Armstrong saying something like 2kB in his talks, for an Erlang process. That's 1/128 of 256kB.

[my-next-account]

2KiB is a peculiar size. Typical page size is 4KiB, and you probably want to allocate two pages - one for the stack and one for a guard page for stack overflow protection. That means that a fibers' minimal size ought to be 8KiB.

[surajrmal]

You should look into how go manages goroutines. It is indeed 2kib stacks by default without the need for guard pages. They use a different mechanism to determine overflows. Other runtimes can do similar things.

[my-next-account]

Aha, yeah. It utilizes the compiler to insert guards at each function prologue, determining the remaining stack size.

[atgreen]

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.

[praptak]

The stack size is just mmapp-ed address space. It only needs backing memory for the pages actually used by the stack.

[20k]

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