5 ms·

This isn't so much "Lisp" as "S-expressions via Python." I was expecting it to actually be implemented in Lisp.

gnarbarian 10y ago
It's a step in the right direction. I can't wait to see more accessible languages like lisp built on top of vulkan and opencl. Programming for GPGPU and heterogeneous computing is difficult, unwieldy, and feels primitive (Partly by design). With better languages more people will be able to write powerful abstractions that are also highly concurrent when the resources are available. Pyopencl is also a step in the right direction. It allows you to descend into opencl for the heavy lifting while remaining in the python ecosystem for everything else.
- Athas 10y ago
  What about something like Futhar[0] (which I am working on)? It also has Python interop[1], although not quite as elegant as Lift. [0]: http://futhark-lang.org http://futhark-lang.org [1]: http://futhark-lang.org/blog/2016-04-15-futhark-and-pyopencl.html http://futhark-lang.org/blog/2016-04-15-futhark-and-pyopencl...
  - deleted 10y ago
    [deleted]
  - gnarbarian 10y ago
    Can I write code in futhark which shares memory with objects being rendered in OpenGL? In other words, can it operate directly on objects being rendered? I'd like to be able to write physics simulations that are visualized in 3d without having to copy the points in and out of futharks memory (killing the performance)
    - Athas 10y ago
      Not yet. But you can already write code that shares memory with objects that you also access from hand-written OpenCL code, and since OpenCL can interop with OpenGL, what you are asking for should eventually be possible.
      - gnarbarian 10y ago
        ahh yes. I have done something like that before with pyopencl but it was not pretty: https://www.youtube.com/watch?v=lnOmy1ly6M0&list=PLCN-Ml6vUJ-JTiqdvcHd0vZVSXDpw_RcW https://www.youtube.com/watch?v=lnOmy1ly6M0&list=PLCN-Ml6vUJ...
        Athas 10y ago
        I have exactly that example here: https://github.com/HIPERFIT/futhark-benchmarks/tree/master/accelerate/nbody https://github.com/HIPERFIT/futhark-benchmarks/tree/master/a... All simulation and rendering is done in Futhark, with Python+Pygame for gluing things together. All the particle information stays on the GPU at all times. The only thing being copied back to the CPU is the rendered bitmap, which is then immediately moved back with a Pygame blit operation...
  - bhuztez 10y ago
    Lift does not has python interop. the lift code run in the python shell is interpreted by naive python code. It runs very slow, and consume lots of memory than you might ever expected. As in the matmul example, dot product is calculated in two steps, there will be an 8x8x8 array when interpreted. When compiled, this huge array will be eliminated with the great help of isl ( http://isl.gforge.inria.fr/ http://isl.gforge.inria.fr/ ).
- bhuztez 10y ago
  lift does not use pyopencl. It intends to generate C code that could be easily linked.
bhuztez 10y ago
It depends heavily on isl ( http://isl.gforge.inria.fr/ http://isl.gforge.inria.fr/ ). There is no Lisp bindings around.

It's a step in the right direction. I can't wait to see more accessible languages like lisp built on top of vulkan and opencl. Programming for GPGPU and heterogeneous computing is difficult, unwieldy, and feels primitive (Partly by design). With better languages more people will be able to write powerful abstractions that are also highly concurrent when the resources are available. Pyopencl is also a step in the right direction. It allows you to descend into opencl for the heavy lifting while remaining in the python ecosystem for everything else.

Athas 10y ago
What about something like Futhar[0] (which I am working on)? It also has Python interop[1], although not quite as elegant as Lift. [0]: http://futhark-lang.org http://futhark-lang.org [1]: http://futhark-lang.org/blog/2016-04-15-futhark-and-pyopencl.html http://futhark-lang.org/blog/2016-04-15-futhark-and-pyopencl...
- deleted 10y ago
  [deleted]
- gnarbarian 10y ago
  Can I write code in futhark which shares memory with objects being rendered in OpenGL? In other words, can it operate directly on objects being rendered? I'd like to be able to write physics simulations that are visualized in 3d without having to copy the points in and out of futharks memory (killing the performance)
  - Athas 10y ago
    Not yet. But you can already write code that shares memory with objects that you also access from hand-written OpenCL code, and since OpenCL can interop with OpenGL, what you are asking for should eventually be possible.
    - gnarbarian 10y ago
      ahh yes. I have done something like that before with pyopencl but it was not pretty: https://www.youtube.com/watch?v=lnOmy1ly6M0&list=PLCN-Ml6vUJ-JTiqdvcHd0vZVSXDpw_RcW https://www.youtube.com/watch?v=lnOmy1ly6M0&list=PLCN-Ml6vUJ...
      - Athas 10y ago
        I have exactly that example here: https://github.com/HIPERFIT/futhark-benchmarks/tree/master/accelerate/nbody https://github.com/HIPERFIT/futhark-benchmarks/tree/master/a... All simulation and rendering is done in Futhark, with Python+Pygame for gluing things together. All the particle information stays on the GPU at all times. The only thing being copied back to the CPU is the rendered bitmap, which is then immediately moved back with a Pygame blit operation...
- bhuztez 10y ago
  Lift does not has python interop. the lift code run in the python shell is interpreted by naive python code. It runs very slow, and consume lots of memory than you might ever expected. As in the matmul example, dot product is calculated in two steps, there will be an 8x8x8 array when interpreted. When compiled, this huge array will be eliminated with the great help of isl ( http://isl.gforge.inria.fr/ http://isl.gforge.inria.fr/ ).
bhuztez 10y ago
lift does not use pyopencl. It intends to generate C code that could be easily linked.

bhuztez 10y ago

It depends heavily on isl ( http://isl.gforge.inria.fr/ http://isl.gforge.inria.fr/ ). There is no Lisp bindings around.