6 ms·

This is very much needed to make gpu more mainstream.

by Ihmahr 13y ago

phren0logy 13y ago
I'm not sure if you are joking (given that it is a lisp, which is notoriously not mainstream), but my limited experience with GPU programming with the existing tools has been pretty painful. I, for one, welcome this development.
- bajsejohannes 13y ago
  Yes, anything to make it easier to get started. I've tried before, but got lost in figuring out which SDK to download. Too bad this toolkit doesn't help in that process. Happily, writing this answer I discovered that OS X 10.7+ ships with OpenCL already! Can't believe I missed that last time. For anyone else wanting to try it, the first example is pretty straight forward: https://developer.apple.com/library/mac/#documentation/Performance/Conceptual/OpenCL_MacProgGuide/XCodeHelloWorld/XCodeHelloWorld.html https://developer.apple.com/library/mac/#documentation/Perfo... (You'll also want the code examples at https://developer.apple.com/library/mac/#documentation/Performance/Conceptual/OpenCL_MacProgGuide/ExampleHelloWorld/Example_HelloWorld.html https://developer.apple.com/library/mac/#documentation/Perfo... )
  - pi18n 13y ago
    Are GLSL and OpenCL equally capable?
    - bajsejohannes 13y ago
      Not exactly sure what you're asking, but GLSL and OpenCL are for two different domains: GLSL for graphics and OpenCL for calculations that are not intended to show up as graphics. They both run on the same hardware, but I don't have enough (or really any) experience with OpenCL to say if it feels more or less powerful than GLSL. Edit: It turns out that I have no OpenCL hardware support (mid 2011 MBA), so I guess the hardware isn't necessarily completely similar (i.e. it can support GLSL and not OpenCL)
      - Impossible 13y ago
        This isn't entirely true. As of OpenGL 4.3 (latest spec), OpenGL adds compute shaders as well. Their primary usage is to make interopt with the graphics pipeline less painful than it would be with OpenCL, but in theory you could use OpenGL (or DX11 on Windows) compute shaders for non-graphics tasks, and they'd have roughly the same capabilities as CUDA or OpenCL.
  - octo_t 13y ago
    OpenCL is used to JIT OpenGL calls based on the hardware. Its magic.
  - reeses 13y ago
    The OpenCL implementation provided by Apple is less than ideal. It lacks a number of optimizations that are provided by, for example, AMD's OpenCL driver packages for Linux and Windows. That, coupled with the wretched GPU options available on the Mac Pro, make the current stack not really cost effective. (I think a 5770 is still $250.) However, it is better than CPU-only. I've found slaving a cheap Linux box with expensive GPUs to be a much more gratifying experience.
    - eholk 13y ago
      I've done most of my development on a Mac, but I keep finding many bugs in Apple's OpenCL implementation. Intel's seems to follow the standard most closely, which is useful for keeping me honest.
- burke 13y ago
  The lisp part isn't necessary (or necessarily helpful), but it's certainly an improvement on embedding C-as-a-string in more C. ...though I am concerned that abstracting this stuff too much makes it less obvious how to optimize for the GPU. This may be a language for people that already have a solid grasp on GPU programming.
  - octo_t 13y ago
    >> embedding C-as-a-string in more C Um. OpenCL/Cuda look absolutely nothing like that.
    - _pmf_ 13y ago
      >> embedding C-as-a-string in more C >Um. OpenCL/Cuda look absolutely nothing like that. Absolutely right. You can also include an external C file from C++ [1]; that makes it so much prettier. [1] http://developer.amd.com/tools-and-sdks/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/introductory-tutorial-to-opencl/ http://developer.amd.com/tools-and-sdks/heterogeneous-comput...
- xkcdfanboy 13y ago
  The language has nothing to do with it. LISP, C, Mathematica (which is LISP-like), etc.. The hard part is dealing with local vs global vs const vs private memory, and the intricacies of global work-groups count vs work-group work size. I won't go further but to say, the GPU is very specialized and the frameworks out there like OpenCL take a little bit of learning before you can use them effectively and performantly.
- Ihmahr 13y ago
  Not joking.
vault_ 13y ago
Things like NumbaPro[1] and OpenACC[2] are going to go much further towards making gpu programming more mainstream than a lisp dialect. NumbaPro is a python library that let's you JIT python into CUDA or CPU vector extensions via decorators. OpenACC is similar (or possibly developed out of) OpenMP in that it takes a directive driven approach to accelerating code. Given a loop you can add a pragma above it with instructions of how it should run a GPU and it will make it happen. [1] http://docs.continuum.io/numbapro/ http://docs.continuum.io/numbapro/ [2] http://www.openacc-standard.org/ http://www.openacc-standard.org/ EDIT: I forgot to mention that I believe we'll be seeing less writing of GPU code directly and more using of libraries that do the hard work for you. Some algorithms on GPUs are quite tricky to get right, and even with a language that makes them easy to express they are non-trivial to design and test. (Nvidia already provides Thrust with cuda which provides a nice STL like library that implements a lot of common routines) [3] http://docs.nvidia.com/cuda/thrust/ http://docs.nvidia.com/cuda/thrust/
- iskander 13y ago
  >Harlan already has native support for rich data structures, including trees and ragged arrays. Very soon the language will support higher order procedures. Structured data and nonuniform computations are very hard to express right now on the GPU and typically require a long and terrible process of "creative" CUDA programming. Harlan seems to be pushing the boundaries of what sorts of GPU programs we can effectively/efficiently implement. But, because the syntax is unusual, you're saying it's irrelevant compared to NumbaPro...which is what, a thin wrapper over elementwise array operations?
  - vault_ 13y ago
    Syntax is syntax, whether it's Lisp or C. What I mean is I hardly think that a new language is what GPU programming needs to break into the mainstream. What I believe GPU programming needs is tools that people can easily add to their current environments or that they can easily extend their current algorithms with. NumbaPro, OpenACC, and Thrust allow that. In addition, the reason it's hard to express structured data and nonuniform computation is because those aren't things GPU architecture excels at. It excels at doing uniform operations over large chunks of memory. I'm sure that Harlan is pushing the boundary of what you can do on a GPU, but it's not going to exceed the limitations imposed by the hardware.

This is very much needed to make gpu more mainstream.

by Ihmahr 13y ago

This is very much needed to make gpu more mainstream.

I'm not sure if you are joking (given that it is a lisp, which is notoriously not mainstream), but my limited experience with GPU programming with the existing tools has been pretty painful. I, for one, welcome this development.

bajsejohannes 13y ago
Yes, anything to make it easier to get started. I've tried before, but got lost in figuring out which SDK to download. Too bad this toolkit doesn't help in that process. Happily, writing this answer I discovered that OS X 10.7+ ships with OpenCL already! Can't believe I missed that last time. For anyone else wanting to try it, the first example is pretty straight forward: https://developer.apple.com/library/mac/#documentation/Performance/Conceptual/OpenCL_MacProgGuide/XCodeHelloWorld/XCodeHelloWorld.html https://developer.apple.com/library/mac/#documentation/Perfo... (You'll also want the code examples at https://developer.apple.com/library/mac/#documentation/Performance/Conceptual/OpenCL_MacProgGuide/ExampleHelloWorld/Example_HelloWorld.html https://developer.apple.com/library/mac/#documentation/Perfo... )
- pi18n 13y ago
  Are GLSL and OpenCL equally capable?
  - bajsejohannes 13y ago
    Not exactly sure what you're asking, but GLSL and OpenCL are for two different domains: GLSL for graphics and OpenCL for calculations that are not intended to show up as graphics. They both run on the same hardware, but I don't have enough (or really any) experience with OpenCL to say if it feels more or less powerful than GLSL. Edit: It turns out that I have no OpenCL hardware support (mid 2011 MBA), so I guess the hardware isn't necessarily completely similar (i.e. it can support GLSL and not OpenCL)
    - Impossible 13y ago
      This isn't entirely true. As of OpenGL 4.3 (latest spec), OpenGL adds compute shaders as well. Their primary usage is to make interopt with the graphics pipeline less painful than it would be with OpenCL, but in theory you could use OpenGL (or DX11 on Windows) compute shaders for non-graphics tasks, and they'd have roughly the same capabilities as CUDA or OpenCL.
- octo_t 13y ago
  OpenCL is used to JIT OpenGL calls based on the hardware. Its magic.
- reeses 13y ago
  The OpenCL implementation provided by Apple is less than ideal. It lacks a number of optimizations that are provided by, for example, AMD's OpenCL driver packages for Linux and Windows. That, coupled with the wretched GPU options available on the Mac Pro, make the current stack not really cost effective. (I think a 5770 is still $250.) However, it is better than CPU-only. I've found slaving a cheap Linux box with expensive GPUs to be a much more gratifying experience.
  - eholk 13y ago
    I've done most of my development on a Mac, but I keep finding many bugs in Apple's OpenCL implementation. Intel's seems to follow the standard most closely, which is useful for keeping me honest.
burke 13y ago
The lisp part isn't necessary (or necessarily helpful), but it's certainly an improvement on embedding C-as-a-string in more C. ...though I am concerned that abstracting this stuff too much makes it less obvious how to optimize for the GPU. This may be a language for people that already have a solid grasp on GPU programming.
- octo_t 13y ago
  >> embedding C-as-a-string in more C Um. OpenCL/Cuda look absolutely nothing like that.
  - _pmf_ 13y ago
    >> embedding C-as-a-string in more C >Um. OpenCL/Cuda look absolutely nothing like that. Absolutely right. You can also include an external C file from C++ [1]; that makes it so much prettier. [1] http://developer.amd.com/tools-and-sdks/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/introductory-tutorial-to-opencl/ http://developer.amd.com/tools-and-sdks/heterogeneous-comput...
xkcdfanboy 13y ago
The language has nothing to do with it. LISP, C, Mathematica (which is LISP-like), etc.. The hard part is dealing with local vs global vs const vs private memory, and the intricacies of global work-groups count vs work-group work size. I won't go further but to say, the GPU is very specialized and the frameworks out there like OpenCL take a little bit of learning before you can use them effectively and performantly.
Ihmahr 13y ago
Not joking.

vault_ 13y ago

Things like NumbaPro[1] and OpenACC[2] are going to go much further towards making gpu programming more mainstream than a lisp dialect. NumbaPro is a python library that let's you JIT python into CUDA or CPU vector extensions via decorators. OpenACC is similar (or possibly developed out of) OpenMP in that it takes a directive driven approach to accelerating code. Given a loop you can add a pragma above it with instructions of how it should run a GPU and it will make it happen. [1] http://docs.continuum.io/numbapro/ http://docs.continuum.io/numbapro/ [2] http://www.openacc-standard.org/ http://www.openacc-standard.org/ EDIT: I forgot to mention that I believe we'll be seeing less writing of GPU code directly and more using of libraries that do the hard work for you. Some algorithms on GPUs are quite tricky to get right, and even with a language that makes them easy to express they are non-trivial to design and test. (Nvidia already provides Thrust with cuda which provides a nice STL like library that implements a lot of common routines) [3] http://docs.nvidia.com/cuda/thrust/ http://docs.nvidia.com/cuda/thrust/

iskander 13y ago
>Harlan already has native support for rich data structures, including trees and ragged arrays. Very soon the language will support higher order procedures. Structured data and nonuniform computations are very hard to express right now on the GPU and typically require a long and terrible process of "creative" CUDA programming. Harlan seems to be pushing the boundaries of what sorts of GPU programs we can effectively/efficiently implement. But, because the syntax is unusual, you're saying it's irrelevant compared to NumbaPro...which is what, a thin wrapper over elementwise array operations?
- vault_ 13y ago
  Syntax is syntax, whether it's Lisp or C. What I mean is I hardly think that a new language is what GPU programming needs to break into the mainstream. What I believe GPU programming needs is tools that people can easily add to their current environments or that they can easily extend their current algorithms with. NumbaPro, OpenACC, and Thrust allow that. In addition, the reason it's hard to express structured data and nonuniform computation is because those aren't things GPU architecture excels at. It excels at doing uniform operations over large chunks of memory. I'm sure that Harlan is pushing the boundary of what you can do on a GPU, but it's not going to exceed the limitations imposed by the hardware.