Re: 100k Threads? (2002)

Re:Re: 100k Threads? (2002) by yetihehe on Saturday September 23, 2023 @07:34AM (#37622318)

Make a ordered_bag ets table and try to insert several thousand records in one ets call. It will block whole VM (spinning one core at 100%, doesn't matter how many you have) for several seconds. It does this because ordered bag needs to find each key in table as it inserts it, resulting in n^2 complexity and this needs to be done atomically. So for 1 000 keys you have 1 000 000 comparisons during a VM-wide lock. Solution - don't insert so many records in one call into ets table.

[ Parent | on HN ]

Re:Re: 100k Threads? (2002) by ninkendo on Saturday September 23, 2023 @08:23AM (#37622648)

I’m more curious to understand how userspace threads can be preemptive. :)

I can think of a few ways:

- The VM just doesn’t JIT and can decide to stop executing a thread by just not interpreting the next piece of bytecode and switching to another green thread instead (this would be pretty slow due to the lack of JIT)

- The VM JITs, but inserts a preamble before every function call saying “Before executing this function, should I switch to another green thread first?”, and thus, so long as you call functions frequently enough, you “preempt” yourself. This is how Go does it, and it’s a well known thing in Go that if you never call a function for a while (like just doing a really huge for loop), the current goroutine doesn’t yield execution and hogs the whole OS thread.

[ Parent | on HN ]

Re:Re: 100k Threads? (2002) by messe on Saturday September 23, 2023 @08:36AM (#37622719)

> - The VM JITs, but inserts a preamble before every function call saying “Before executing this function, should I switch to another green thread first?”, and thus, so long as you call functions frequently enough, you “preempt” yourself. This is how Go does it, and it’s a well known thing in Go that if you never call a function for a while (like just doing a really huge for loop), the current goroutine doesn’t yield execution and hogs the whole OS thread.

I'm not sure of the implementation details, but this hasn't been true for a while in Go. As of Go 1.14, goroutines are asynchronously preemptible, so loops without function calls no longer deadlock the scheduler or GC: https://go.dev/doc/go1.14#runtime

[ Parent | on HN ]

Re:Re: 100k Threads? (2002) by semiquaver on Saturday September 23, 2023 @09:16AM (#37622964)

The docs there hint at how it’s likely done in go: the runtime uses a signal handler to preempt code that hasn’t yielded the scheduler recently enough.

[ Parent | on HN ]

Re:Re: 100k Threads? (2002) by ninkendo on Saturday September 23, 2023 @05:46PM (#37627841)

Interesting! My info is way out of date then. Thanks for the link.

[ Parent | on HN ]

Re:Re: 100k Threads? (2002) by jabl on Saturday September 23, 2023 @09:44AM (#37623153)

IIRC the Erlang VM does the second (schedule on function call). Since Erlang is a functional language and loops are done via recursion, this works out fine.

[ Parent | on HN ]

Re:Re: 100k Threads? (2002) by yetihehe on Sunday September 24, 2023 @06:13AM (#37631737)

Yes, on every function call, also some internal functions implemented in native code are instrumented with those checks. On average thread is switched out after about 2000 "reductions" as they are called. Also there's an optimization, where if you send something to another thread and you are waiting for reply, VM switches instantly to the other thread, which makes some message sending equivalent to a simple function call.

[ Parent | on HN ]

Re:Re: 100k Threads? (2002) by gpderetta on Saturday September 23, 2023 @11:15AM (#37624013)

In principle you can also set a timer that raises a signal and then switch to a different coroutine when it fires. But it is a big can of worms and won't perform great.

[ Parent | on HN ]