7 ms·
This looks super interesting! I've been working on a Raytracer in C++ and I was recently looking into a threading library which I can use to parallelize the ren
by krat0sprakhar 10y ago
This looks super interesting! I've been working on a Raytracer in C++ and I was recently looking into a threading library which I can use to parallelize the rendering. Surely going to try this out in the coming weekend.
Unsolicited suggestion - while benchmarks and the motivation are important for a threading library, a code snippet of a simple parallel program on the home page would be something that I'd love to see.
Great job, though!
- saman_b 10y agoThanks! good point; now that I look at the page, there is not a single sample code in there. I'll update it soon.
- krat0sprakhar 10y agoAwesome! As an example, Rayon[0] does a very good job (IMHO) at this. [0] - https://github.com/nikomatsakis/rayon https://github.com/nikomatsakis/rayon
- saman_b 10y agoThanks, oh all those fancy functions. I need to improve the interface a bit, as for now everything is only based on using uThreads as the unit of concurrency. e.g., this is a recursive Fibonacci: https://github.com/samanbarghi/uThreads/blob/master/test/Fibonacci.cpp https://github.com/samanbarghi/uThreads/blob/master/test/Fib... and a fork-and-join Fibonacci: https://github.com/samanbarghi/uThreads/blob/master/test/FibonacciFJ.cpp https://github.com/samanbarghi/uThreads/blob/master/test/Fib... There is no fork-and-join in uThreads yet, and I created it using create and join. The interface will improve in the future :)
- zokier 10y agoIsn't raytracing almost completely CPU-bound? Seems like a odd use-case for green threads, which afaik are more commonly used for IO-bound tasks.
- krat0sprakhar 10y agoYou're absolutely right - raytracing is CPU-bound. However, one can still parallelize per-pixel rendering computations on separate cores. Here's an example of a path-tracer written in Go, spawning a new go-routine for this very use-case https://github.com/fogleman/pt/blob/master/pt/renderer.go#L64-L65 https://github.com/fogleman/pt/blob/master/pt/renderer.go#L6...
- comex 10y agoIf you just want to start num-CPUs threads like that code does, there is no advantage of green threads over regular ones, std::thread in C++. If you want to start a thread per pixel or something, green threads could work, but it's probably more efficient to keep track of state manually.
- CyberDildonics 10y agoYes, using green threads for ray tracing is basically nonsense, since keeping actual threads busy is no overly difficult.
- tomjakubowski 10y agoIt's not nonsense if, to render each pixel, you issue an HTTP request containing the scene/eye data and requested pixel coordinate, and wait for a response to come back from your magic render farm that lives in "the cloud". Now your "ray tracer" is totally I/O bound! :-)
- edvinbesic 10y agoNot sure if /s, but, to rasterize a 1920x1080 image you would make 2073600 HTTP requests? Sound reasonable.
- Someone 10y agoDouble that if you want to PUT the pixels on a screen.
- rsp1984 10y agoIt sounds to me like what you'd need for ray tracing is a fork/join threading model with a master and several worker threads. OpenMP provides exactly that and is a widely supported standard. I'm curious: Why would you use anything else?
- CyberDildonics 10y agoFork and join is one type of concurrency technique, but to think you wouldn't need anything else is silly. Non shared memory concurrency and pipelined concurrency are two more techniques that can be used.
- rsp1984 10y agoI was stating this in the context of ray tracing. Why not just use OpenMP and be done with it?
- CyberDildonics 10y agoI answered that question. OpenMP fork-join concurrency can be useful for certain parts of a ray tracer depending on the overall architecture. It is far from the only way and can have many draw backs when it comes to overhead, synchronization and memory locality.