[krat0sprakhar]

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!

[rsp1984]

It 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]

Fork 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]

I was stating this in the context of ray tracing. Why not just use OpenMP and be done with it?

[CyberDildonics]

I 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.

[zokier]

Isn'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]

You'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#L6...

[comex]

If 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]

Yes, using green threads for ray tracing is basically nonsense, since keeping actual threads busy is no overly difficult.

[tomjakubowski]

It'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]

Not sure if /s, but, to rasterize a 1920x1080 image you would make 2073600 HTTP requests? Sound reasonable.

[Someone]

Double that if you want to PUT the pixels on a screen.

[saman_b]

Thanks! good point; now that I look at the page, there is not a single sample code in there. I'll update it soon.

[krat0sprakhar]

Awesome! As an example, Rayon[0] does a very good job (IMHO) at this.

[0] - https://github.com/nikomatsakis/rayon

[saman_b]

Thanks, 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/Fib... and a fork-and-join Fibonacci: 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 :)