https://kotlinlang.org logo
#advent-of-code
Title
# advent-of-code
j

Jakub Gwóźdź

12/13/2023, 9:02 PM
I have a question with parallelisation. let’s say that my regular part2 in day 12 (the springs vel “1D nonograms”) looks like this:
Copy code
fun part2(input: Input) = input.map { calc(it.repeated(5).trimDots()) }.sum()
seems like a candidate to do the mapping concurrently, so no core is slacking, but no matter if I implement it via java8 .parallelStream, or runBlocking/async/awaitAll, my results are actually worse. in the above example from 40ms sequential to ~70ms in parallel. Is it to be expected on such small work pieces? I aim to fit all 50 stars under 1 second total, but we’re merely halfway there and I’m already there 🙂
t

Tomasz Linkowski

12/13/2023, 9:11 PM
In my opinion, it's simply the overhead of scheduling the work, including internal synchronization of either Stream's ForkJoinPool or whatever executor Kotlin uses under the hood. For such short-lived pieces of work, it just doesn't seem worthwhile.
j

Jakub Gwóźdź

12/13/2023, 9:33 PM
probably a lot of it comes from suspending world. I saved a lot after refactoring from DeepRecursiveFunction (which is suspending) to normal recursion
e

El Anthony

12/13/2023, 10:16 PM
I tried a parallel solution and it took longer too. I think it's because the problem is very easy to solve, it takes almost no time, and the overhead of starting and synchronizing coroutines should be higher.
5 Views