Crystal: Any plan or roadmap of multi-thread?

[ariesdevil]

Submitting questions

Any plan or roadmap of multi-thread ?

[bararchy]

From crystal lang org

The next big thing is parallelism, with core team members ggiraldez and juanedi working heavily on it, based on the work started by waj. We are happy to have a working version of the compiler built with multi-thread support, with a similar model to Go: a fixed thread pool that executes tasks from fibers, including goodies such as work-stealing. Work on this is still experimental, and there are quite a few breaking changes to define, such as explicit Thread handling; but most of the compiler and standard library specs are currently green. Kemal’s author sdogruyoleven managed to run the web framework in multiple threads already. However, there is still much work to do on testing and performance, to ensure the contention produced by distributing the workload on multiple threads does not offset the speed gain.

[ariesdevil]

Thanks for answer.

[Sija]

@ariesdevil See relevant page on the wiki.

[asterite]

Closing, answer closed. Such questions go better in google groups.

[ylluminate]

Seems that the wiki entry above and such are a bit dated. What's the current status?

[joshuapinter]

[Sija]

IIRC @ysbaddaden had sth up his sleeve... Perhaps he would spill the beans about how are the _things_ going along?

[ysbaddaden]

(whispering: https://github.com/crystal-lang/crystal/compare/master...ysbaddaden:feature/mt)

Warning:

• it's highly experimental (must pass -Dmt when compiling) and likely to crash or hang forever;
• requires to patch bwgc;
• disables select;
• MT adds a bunch of overhead, so running a HTTP::Server on 4 threads (on a quad-core) is maybe ~30% faster than without MT, which is very disapointing when starting 4 processes (no MT) with SO_REUSEPORT is 400% faster (no overhead).

[joshuapinter]

Thanks for the update, @Sija and @ysbaddaden!!

I'm new to the scene but two questions on MT:

1. Is the overhead of MT static or a one-off cost? i.e. If you ran it on a 8-core machine, would the overhead be the same, fixed amount and, thus, the performance would be faster?

2. Given the disappointing performance gains with MT, are there ways to improve this or is this kind of a dead end?

On a side note, I can't express how excited I am about this language. Coming from over a decade of Ruby and Rails, I feel right at home and could see myself and our company using this as an integral part of our mature Rails app. So, a quick thanks to all of you for your efforts. 🙏

[ysbaddaden]

The overhead is having to do checks that we don't have to when there is no parallelism. These checks involve locks to access/modify shared data structures (runnable queues, mutexes, channels, ...). That creates contention points: threads are blocked, waiting to do something, don't make any progress it slows down the whole process.

There is room for improvement. For example use a Chase & Lev circular queue for scheduler runnables, Dmitry Vyukov's bounded mpmc queue for channels, ...

But that's only part of the problem. Fearless concurrency (and more importantly parallelism) is also at stake: sharing mutable data structures across fibers should be prohibited or proved/assumed to be safe.