I wrote this ray tracer, but it's really slow. How would I make it multithreaded?
#How to Multithreading
still bison
clever iris
std.Thread
still bison
I've only ever done mulithreading using JavaScript's Worker. Is there any detailed guide on how to use std.Thread?
clever iris
looks like ziglings has a couple exercises on it
This is also a great intro to a lot of the common footguns around synchronization etc: https://deadlockempire.github.io/
still bison
std.Thread probably can't compile to web assembly
dire galleon
i have never written a raytracer before, but make sure you cant do any other optimizations first before doing something like multi threading
river vortex
raytracing benefits quite well from multithreading and it's not that difficult to parallelize
clever iris
why doubt lol
you can be pretty naive with parallelizing raytracing and get decent results
river vortex
x = # threads, y = thousands of rays per second
biggest reason it stops growing as quickly is likely that my cpu has efficiency cores
anyway, once you figure out how to launch threads and use locks, you basically just need to come up with a way to divide the image up so each thread gets a roughly equal amount of work
clever iris
simplest way is probably to tile it and add tiles to a queue protected by a mutex
river vortex
x = # threads, y = thousands of rays per second
biggest reason it stops growing ...
yeah that's what i'm doing here
i originally divided the image into equal slices, but that works very badly if not all threads are running at the same speed
the queue handles that situation well
clever iris
actually that's maybe not the simplest way, but it is probably the best way heh
tiles work best when your memory is tiled too, so each thread should render into its own small image, then push that to another queue that the main thread can read from to construct the final image
river vortex
yep
obviously anything that multiple threads access needs to have a lock on it, but for performance reasons, it's also good to try to keep threads from writing even to nearby areas of memory at the same time unless they have to
clever iris
which is easy and fast because your entire critical section is basically just "push to a queue, pop from a queue, done"
river vortex
obviously anything that multiple threads access needs to have a lock on it, but ...
so giving each one a way to do work locally within its own tile is convenient
clever iris
obviously anything that multiple threads access needs to have a lock on it, but ...
the only thing multiple threads need to access is the queues
oh right that's what you were saying
sorry
yeah, queue of tiles is easy and fast :)
tbh a raytracer is possibly the best thing you could choose for learning parallelism
it's not quite embarassingly parallel, but it's also pretty easy to implement well
still bison
mutexes and locks, more words that I don't know what they mean
empty aurora
just as the name sounds like
it locks the object so that when other thread try to access it, it needs to wait for it to be unlocked first before accessing it
The section where it is locked and you access or modify the object is called the "Critical Section"
river vortex
mutex and lock mean the same thing