2 ms·

Ah, I think you’re talking about applying genetic algorithms to self modifying code. In that case you’d want to run the self-modifying code in a VM; if you’re

Ah, I think you’re talking about applying genetic algorithms to self modifying code. In that case you’d want to run the self-modifying code in a VM; if you’re just putting random instructions after another, you’ll most likely just have segfaults, invalid memory addressing, and worse. With a simple VM, you could fit it in a GPU kernel (keep in mind the language limitations) and then you’ll have no issues launching your huge batch in parallel. I don’t know if genetic program generation has any useful applications however. Personally I am more interested in applying genetic algorithms to machine learning, i.e. neuroevolution. A few examples include NEAT and Uber’s reinforcement learning research.

zackmorris 6y ago
Ya the method I want to try is transpiling Lisp to C and then running that on GPU (so no segfaults). As far as I can tell, the problem is that I can only run 10,000 copies of the same shader, not 10,000 different shaders at once on the same data. This is the closest I can come to a "proof" that today's hardware is on the wrong branch of the search space of possible hardwares. I'm hoping to be proven wrong though, and that someone knows a way to run say 16 or more different shaders simultaneously on a GPU. Maybe there is a way to encode the variations in sub-shaders and run those at the same time or something? Edit: a few more links about running concurrent GPU kernels: https://stackoverflow.com/a/53341888/539149 https://stackoverflow.com/a/53341888/539149 https://stackoverflow.com/a/52978372/539149 https://stackoverflow.com/a/52978372/539149 https://community.amd.com/t5/opencl/opencl-concurrent-kernel-execution/td-p/112686 https://community.amd.com/t5/opencl/opencl-concurrent-kernel... https://community.khronos.org/t/concurrents-kernels-in-opencl/7604 https://community.khronos.org/t/concurrents-kernels-in-openc... http://ecosimulation.com/chrisgregg/Publications/Fine-GrainedResourceSharing.pdf http://ecosimulation.com/chrisgregg/Publications/Fine-Graine... http://docs.potionmagic.eu/per.pdf http://docs.potionmagic.eu/per.pdf Unfortunately, concurrent kernels execution is only possible with CUDA on NVIDIA graphics cards. For other cards, OpenCL does not offer this functionality. Looks like it may only be possible on NVIDIA, according to the last link. Since this was the first thing I wanted to do with OpenCL, it doesn't bode well for the standard or AMD. As a software developer, I see this issue a lot. What happened is, their public interface is too thick so doesn't reflect the actual capabilities of the hardware. I hit this with OpenGL too way back before ES2 and shaders were mainstream. I just wanted direct access to some of the matrix hardware math but couldn't get to it. I'd vote to scrap current GPU implementations and move to a pure 2D or 3D grid of compute units (a bit like AWS EC2) running something like Docker. Then write OpenGL, OpenCL, Vulkan, Metal and the rest as niche libraries implementing use cases above the runtime. That would give us bare metal access to get real work done with languages like C, Rust, MATLAB, Julia, Erlang, Go, etc and finally drop the distinction between CPU and GPU.

zackmorris 6y ago

Ya the method I want to try is transpiling Lisp to C and then running that on GPU (so no segfaults). As far as I can tell, the problem is that I can only run 10,000 copies of the same shader, not 10,000 different shaders at once on the same data. This is the closest I can come to a "proof" that today's hardware is on the wrong branch of the search space of possible hardwares. I'm hoping to be proven wrong though, and that someone knows a way to run say 16 or more different shaders simultaneously on a GPU. Maybe there is a way to encode the variations in sub-shaders and run those at the same time or something? Edit: a few more links about running concurrent GPU kernels: https://stackoverflow.com/a/53341888/539149 https://stackoverflow.com/a/53341888/539149 https://stackoverflow.com/a/52978372/539149 https://stackoverflow.com/a/52978372/539149 https://community.amd.com/t5/opencl/opencl-concurrent-kernel-execution/td-p/112686 https://community.amd.com/t5/opencl/opencl-concurrent-kernel... https://community.khronos.org/t/concurrents-kernels-in-opencl/7604 https://community.khronos.org/t/concurrents-kernels-in-openc... http://ecosimulation.com/chrisgregg/Publications/Fine-GrainedResourceSharing.pdf http://ecosimulation.com/chrisgregg/Publications/Fine-Graine... http://docs.potionmagic.eu/per.pdf http://docs.potionmagic.eu/per.pdf Unfortunately, concurrent kernels execution is only possible with CUDA on NVIDIA graphics cards. For other cards, OpenCL does not offer this functionality. Looks like it may only be possible on NVIDIA, according to the last link. Since this was the first thing I wanted to do with OpenCL, it doesn't bode well for the standard or AMD. As a software developer, I see this issue a lot. What happened is, their public interface is too thick so doesn't reflect the actual capabilities of the hardware. I hit this with OpenGL too way back before ES2 and shaders were mainstream. I just wanted direct access to some of the matrix hardware math but couldn't get to it. I'd vote to scrap current GPU implementations and move to a pure 2D or 3D grid of compute units (a bit like AWS EC2) running something like Docker. Then write OpenGL, OpenCL, Vulkan, Metal and the rest as niche libraries implementing use cases above the runtime. That would give us bare metal access to get real work done with languages like C, Rust, MATLAB, Julia, Erlang, Go, etc and finally drop the distinction between CPU and GPU.