3 ms·

So, is this some kind of super-JIT (binary translator) that translates and vectorizes x86 code and then passes it on to GPUs and FPGAs? Automated X86 to GPU na

by vardump 11y ago

So, is this some kind of super-JIT (binary translator) that translates and vectorizes x86 code and then passes it on to GPUs and FPGAs? Automated X86 to GPU native translation is looking more and more feasible, with some caveats. Especially SIMD operations are a natural fit. But the issues... GPUs are sequentially very slow. Single thread execution is over an order of magnitude slower than for CPUs. Latency between host CPU and GPU is usually significant, measured even in milliseconds. Other than memory bandwidth, CPUs are catching up on GPUs anyways. If x86 SIMD keeps getting wider, we might be just a few years away from CPU and GPU processing power parity. But FPGAs... Does it place and route itself, or use something like OpenCL as a backend? Or does it make "netlists" out of x86 code and somehow make existing FPGA tools to compile them to chip fabric? Anyways, when it comes to this product and FPGAs, I believe only when I see!

qubex 11y ago
This reminds me of a late 1990s/early 2000s company called Starbridge Systems that commercialised FPGA-based "Hypercomputers" embodying what I took to be a compile-to-FPGA technology (trademarked Pensa if I remember correctly). It seems to be long-gone and defunct but this is the best reference I was able to find on the web: http://www.forbes.com/2003/03/25/cz_dl_0325star2.html http://www.forbes.com/2003/03/25/cz_dl_0325star2.html
mtweak 11y ago
Most automatic code generation to GPUs can be summarized as glorified autovectorization. This includes the bunch of work converting Java to CUDA and C to OCL/CUDA. Autovectorization paired with automatic injection of OMP pragmas can be a great way to introduce increased parallelization. For FPGAs, OpenCL support is still very new. Both Altera (now Intel) and Xilinx have toolchains that compile OpenCL source into gates through first highlevel synthesis and then taking the output through the normal synthesis, implementation, bitstream flow. It's a huge development that should increase adoption of FPGAs for more common use which is why we're excited about it. Mazhar Bitfusion.io

by vardump 11y ago

qubex 11y ago

This reminds me of a late 1990s/early 2000s company called Starbridge Systems that commercialised FPGA-based "Hypercomputers" embodying what I took to be a compile-to-FPGA technology (trademarked Pensa if I remember correctly). It seems to be long-gone and defunct but this is the best reference I was able to find on the web: http://www.forbes.com/2003/03/25/cz_dl_0325star2.html http://www.forbes.com/2003/03/25/cz_dl_0325star2.html

mtweak 11y ago

Most automatic code generation to GPUs can be summarized as glorified autovectorization. This includes the bunch of work converting Java to CUDA and C to OCL/CUDA. Autovectorization paired with automatic injection of OMP pragmas can be a great way to introduce increased parallelization. For FPGAs, OpenCL support is still very new. Both Altera (now Intel) and Xilinx have toolchains that compile OpenCL source into gates through first highlevel synthesis and then taking the output through the normal synthesis, implementation, bitstream flow. It's a huge development that should increase adoption of FPGAs for more common use which is why we're excited about it. Mazhar Bitfusion.io