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