3 ms·

My point is that while it can sometimes accelerate lua code, it will also (i'd say) decelerate lua code, when the algorithm is not trivially parallelizable (and

My point is that while it can sometimes accelerate lua code, it will also (i'd say) decelerate lua code, when the algorithm is not trivially parallelizable (and that is the majority of cases). So, to get the gpu boost, or evento understand how to implement the algorithm properly, I'd have to drop to the GPU specifics. The main question is then: do terracuda helps with that or will it be the obstacle? (it is not a rethorical question; while I suspect it will be the obstacle, I am interested to hear what is your experience with such cases)

wcrichto 11y ago
I strongly doubt writing Terracuda GPU code would ever decelerate your original application, although it might not be as fast as a hand-written CUDA program (and that's an important distinction!). Terracuda doesn't actually lack that many GPU specifics--really it just doesn't provide access to shared memory constructs which are important for hand-tuned matrix mult kernels and blocked algorithms. And that's in the NVPTX API so it's not a true obstacle, just something I haven't gotten around to writing yet.
- dragandj 11y ago
  But have you tried? I've seen a good share of naive kernels that are slower on a monster gpu than on the cpu. My guess is that most of the code written by users that do not have a clue about the specifics of how gpus work (which is the typical person that terracuda might appeal to) would fall for that trap.
- jakub_h 11y ago
  > although it might not be as fast as a hand-written CUDA program If you're dealing with larger pieces of code at once (that is, if you have a bigger view of what the programmer wants to run, which you should have), one interesting thing you could do is "exploratory compiling". Try different compilation step sequences and transformations, if you have enough invariants in the code. Machine time is cheap and this could yield some interesting results. Of course, the more constrained the language model is, the more opportunities for this. (There's been some interesting results in this area, like superoptimizers for local optimization, but larger scale compilation would probably use something like genetic algorithms, as you're unlikely to have the opportunity for exhaustive searches.)

wcrichto 11y ago

I strongly doubt writing Terracuda GPU code would ever decelerate your original application, although it might not be as fast as a hand-written CUDA program (and that's an important distinction!). Terracuda doesn't actually lack that many GPU specifics--really it just doesn't provide access to shared memory constructs which are important for hand-tuned matrix mult kernels and blocked algorithms. And that's in the NVPTX API so it's not a true obstacle, just something I haven't gotten around to writing yet.

dragandj 11y ago
But have you tried? I've seen a good share of naive kernels that are slower on a monster gpu than on the cpu. My guess is that most of the code written by users that do not have a clue about the specifics of how gpus work (which is the typical person that terracuda might appeal to) would fall for that trap.
jakub_h 11y ago
> although it might not be as fast as a hand-written CUDA program If you're dealing with larger pieces of code at once (that is, if you have a bigger view of what the programmer wants to run, which you should have), one interesting thing you could do is "exploratory compiling". Try different compilation step sequences and transformations, if you have enough invariants in the code. Machine time is cheap and this could yield some interesting results. Of course, the more constrained the language model is, the more opportunities for this. (There's been some interesting results in this area, like superoptimizers for local optimization, but larger scale compilation would probably use something like genetic algorithms, as you're unlikely to have the opportunity for exhaustive searches.)