How Go runtime makes concurrent code simple

5 years ago I showed a way to fight with "all-threads-busy" problem while writing Hopac code. The same problem exists on JVM as well. The root is in the cooperative concurrency model, which is based on thread pools, async/futures/etc. are scheduled to run on them. So, if an async is blocked by an IO call of if it's just executing some computation, the OS thread is not able to do anything else: the scheduler is unable to "pause" such a blocked async and execute anothe one. So, asynchronous code on .NET, JVM, Rust, etc. is inherently unsafe: it's not guaranteed that all existing asyncs progress.

The things are different in Go runtime: the scheduler is preemptive, so it can "pause" goroutines at any point: not only at function calls, at loops, but on just any execution point (almost). This makes writing concurrent code dead easy: there's no "async" functions, lambdas or blocks of code, every function or call are the same, being them executed in "main" thead or in a goroutine.

Let's look at the mention above code being written in Go:

No let!, await, async, do!, StartAsTask, match! and so on. Need to run some code concurrently? Add go keyword. Done.

Comments

Павел Мартынов said…
Hey Vasily! How are you? Just searched some info on Rust's async and found this blog post :-).

> So, if an async is blocked by an IO call of if it's just executing some computation, the OS thread is not able to do anything else: the scheduler is unable to "pause" such a blocked async and execute another one.

I believe there is a simple yet elegant solution for Scala's futures from stdlib: blocking { ... } section. You just wrap a long sync IO in blocking and ExecutionContext will not spend it's computation threads on it. Or you can use a separate ExecutionContext for IO futures if you want more control.
December 12, 2024 at 11:33 AM
Vasily said…
Я нормально :)

А в Гоу по сути вытесняющая многозадачность, т.е. шедулер может прервать выполнение гоурутины не только на вводе-выводе, но даже в плотном цикле вычислений. В итоге мы имеем все лучшее от мира системных тредов и кооперативной многозадачности (асинки в дотнете, скале и так далее): легковесные гоурутины с поведением тредов. Это настолько шикарно, что надо самому пробовать. Никаких асинков, никого мэппинга, флэтмэппинга, на дай бог блокировки в асинке, сложная обработка ошибок, деление функций на обычные и асинхронные и так далее.
December 16, 2024 at 1:44 PM
Павел Мартынов said…
Да, согласен, надо пробовать. В Kotlin в стандартной библиотеке есть корутины, но не знаю на сколько оно эквивалентно тому, что в Go, тоже не пробовал
December 16, 2024 at 4:15 PM
Post a Comment

Popular posts from this blog

Haskell: performance

It turned out that it's not Haskell who was slow in my previous Fibonacci test. It was my lack of Haskell knowledge. Haskell has two integral types - Int, which has bounds -2147483648..2147483647 and Integer, which is unbounded. Both types implement Integral type class, so out fib function can be defined in terms of this type class: OK, now we can test performance of the function parametrizing it with the two concrete types. Integer first: We get our previous result ~15 seconds which is rather slow. Now test it with Int type: Whoa! The Int type is ~6 times faster than Integer! And with result of 2.8 seconds Haskell's took the third position in our small rating :) Current list (in seconds): C# - 1.26 F# - 1.38 Nemerle - 1.45 Haskell - 2.8 Clojure - 9 Erlang - 17 Ruby - 60 Python - 120
Read more

Regular expressions: Rust vs F# vs Scala

Image
Let's implement the following task: read first 10M lines from a text file of the following format: then find all lines containing Microsoft namespace in them, and format the type names the usual way, like "Microsoft.Win32.IAssemblyEnum". First, F#: Now Rust: After several launches the file was cached by the OS and both implementations became non IO-bound. F# one took 29 seconds and 31MB of RAM at peak; Rust - 11 seconds and 18MB. The Rust code is as twice as long as F# one, but it's handling all possible errors explicitly - no surprises at runtime at all. The F# code may throw some exceptions (who knows what kind of them? Nobody). It's possible to wrap all calls to .NET framework with `Choice.attempt (fun _ -> ...)`, then define custom Error types for regex related code, for IO one and a top-level one, and the code'd be even longer then Rust's, hard to read and it would still give no guarantee that we catch all possible exceptions. Up...
Read more

Hash maps: Rust, F#, D, Go, Scala

Image
Let's compare performance of hashmap implementation in Rust, .NET, D (LDC) and Go. Rust: F#: As you can see, Rust is slower at about 17% on insersions and at about 21% on lookups. Update As @GolDDranks suggested on Twitter , since Rust 1.7 it's possible to use custom hashers in HashMap. Let's try it: Yes, it's significantly faster: additions is only 5% slower than .NET implementation, and lookups are 32% *faster*! Great. Update: D added LDC x64 on windows It's very slow at insertions and quite fast on lookups. Update: Go added Update: Scala added Compared to Scala all the other languages looks equally fast :) What's worse, Scala loaded all four CPU cores at almost 100% during the test, while others used roughly single core. My guess is that JVM allocated so many objects (each Int is an object, BTW), that 3/4 of CPU time was spend for garbage collecting. However, I'm a Scala/JVM noob, so I just could write the whole b...
Read more