3 ms·

Do you mean it doesn't use explicit mutexes? I don't see any way this model would avoid using mutexes (or some mutex-like construct) under the hood, in which ca

Do you mean it doesn't use explicit mutexes? I don't see any way this model would avoid using mutexes (or some mutex-like construct) under the hood, in which case I'm not sure I see the advantage. The term "fork/join cycle" is intriguing and meaningless to me as a non-Julia user. What exactly is this cycle?

dragontamer 6y ago
Well, I only visit Julia now and then. I've been programming various parallel programs though for myself. > The term "fork/join cycle" is intriguing and meaningless to me as a non-Julia user. What exactly is this cycle? https://www.researchgate.net/profile/Alina_Kiessling/publication/265109968/figure/fig3/AS:669520771420164@1536637599233/The-Fork-and-Join-Model-OpenMP-programs-start-with-a-master-thread-running.png https://www.researchgate.net/profile/Alina_Kiessling/publica... There are many forks-and-joins across a program, when you're doing the fork-and-join paradigm. Each time the threads need to communicate, you join, and then use the "master" thread to pass data to all of the different units. ------------- For example, most video-game engines issue a fork to calculate the verticies of all objects in the video game (the fork turns into a GPU call). This is called the vertex-shader. Once all the verticies are calculated, the GPU joins these threads together, and the main-program / game engine continues. The next step is the geometry shaders: so the CPU forks (aka: spawn thousands of GPU threads), and joins on the results of the geometry shaders. (Tesselation may spawn more vertexes. Ex: you model a rope as a square, but then the geometry shader turns the square into a rope-shape at this stage) Then the pixel shaders. For every pixel of your 1080 x 1920 screen, a GPU SIMD-thread is forked off, and each pixel's final color is calculated based on the results of vertex-shaders and geometry shaders before it. Each of these cycles is a fork-join cycle. Thousands of threads spawning, thousands of threads joining, the CPU calculating some synchronization data together, and then spawning thousands of threads again. (In practice, modern game engines are now async for speed reasons. But the general fork/join model is still kinda there if you squint)

dragontamer 6y ago

Well, I only visit Julia now and then. I've been programming various parallel programs though for myself. > The term "fork/join cycle" is intriguing and meaningless to me as a non-Julia user. What exactly is this cycle? https://www.researchgate.net/profile/Alina_Kiessling/publication/265109968/figure/fig3/AS:669520771420164@1536637599233/The-Fork-and-Join-Model-OpenMP-programs-start-with-a-master-thread-running.png https://www.researchgate.net/profile/Alina_Kiessling/publica... There are many forks-and-joins across a program, when you're doing the fork-and-join paradigm. Each time the threads need to communicate, you join, and then use the "master" thread to pass data to all of the different units. ------------- For example, most video-game engines issue a fork to calculate the verticies of all objects in the video game (the fork turns into a GPU call). This is called the vertex-shader. Once all the verticies are calculated, the GPU joins these threads together, and the main-program / game engine continues. The next step is the geometry shaders: so the CPU forks (aka: spawn thousands of GPU threads), and joins on the results of the geometry shaders. (Tesselation may spawn more vertexes. Ex: you model a rope as a square, but then the geometry shader turns the square into a rope-shape at this stage) Then the pixel shaders. For every pixel of your 1080 x 1920 screen, a GPU SIMD-thread is forked off, and each pixel's final color is calculated based on the results of vertex-shaders and geometry shaders before it. Each of these cycles is a fork-join cycle. Thousands of threads spawning, thousands of threads joining, the CPU calculating some synchronization data together, and then spawning thousands of threads again. (In practice, modern game engines are now async for speed reasons. But the general fork/join model is still kinda there if you squint)