3 ms·
I've worked on a project to compile a domain-specific description language down to both SIMD (by using Intel SPMD Program Compiler) and GPGPU (by using CUDA and
by KMag 6y ago
I've worked on a project to compile a domain-specific description language down to both SIMD (by using Intel SPMD Program Compiler) and GPGPU (by using CUDA and OpenCL) Monte Carlo simulation code. We also have a Scala/Java interpreter for debugging.
Are there workloads that benefit from very wide SIMD vectors that aren't good fits for GPGPUs, as long as the GPUs support 64-bit floats close enough to IEEE-754 for your needs? I understand the overhead in shuffling data between main memory and GPU memory, and synchronization overhead, but most code I'm familiar with that does heavy number crunching suitable for very wide SIMD tends to do that number crunching off on threads that don't have much synchronization with threads doing more general-purpose computation.
On a side note, ISPC's input language is deceptively close to C, but little traps lie in wait. I remember helping an intern debug his port of some of the Java code I wrote over to ISPC, but it turns out that mulitplying a long long by a double in ISPC results in a long long. Our attempt to scale down a random 64-bit integer to the range [0.0, 1.0) was always resulting in 0.0. I get that integer calculations are faster, and I could understand disallowing implicit casts, but making a language so close to C, but with different implicit casting rules is just asking for trouble.
- glangdale 6y agoYou're in a bit of a different domain - I've never really done all that much stuff with heavy number crunching (I've done a bit of work on random forest traversal, but that's more about logic than about FP). And I have never worked with ISPC. I think number crunching workloads are typically quite suitable for GPGPU - I'm certainly not trying to "debunk GPGPU", just saying that there are a lot of integer/logic intensive workloads that involve rapid switching back and forth between control/GPR-based-logic sides and "SIMD tasks" (e.g. Hyperscan switching between NFA/DFA simulation and "acceleration", which was SIMD-based character skipping).
- PaulHoule 6y agoDan Luu does brilliant things parsing strings with SIMD instructions but the programming model is busted if you have to recompile (and maybe hand code assembly) for each chip. I was involved with wrapping up a deep neural net application just as GPGPU was about to take off. We used hand coded SIMD, performance was fine, but we were not going to recode for the next generation from chips, change our error function, or change anything SIMD related.I Before there was MMX computers came with vector units that did not have a programmer visible size, such as the Cray 1 and the vector unit for the 3090 mainframe. As it is, people hardly use vector instructions or if they use them it is something a few generations old so people pay for vector units that they don't use.
- jeffffff 6y agosimd is a better fit than gpu for a lot of data warehousing workloads where you aren't doing much computation on each individual value and it's not worth the overhead of sending the data to the gpu. also true for search index performance optimization.