4 ms·

And now for something completely different: running Lisp on GPUs [pdf]

69 points by espeed 7y ago

dTal 7y ago
"CuLi and test applications will be published on the webserver of the Johannes Gutenberg University Mainz under https://version.zdv.uni-mainz.de" https://version.zdv.uni-mainz.de" but the link is dead. Anyone know where this can be found? It's a really interesting project that has practical implications for a little hobby project I'm working on.
- actondev 7y ago
  are you sure about the practical implications? Quoting the abstract: "At the moment, Lisp programs running on CPUs outperform Lisp programs on GPUs"
  - dTal 7y ago
    You're right it seems - as written, the parsing overhead from the requirement to make the entire system run the GPU makes it impractical. A hybrid system could outperform CPU or GPU alone. What I really want is a scheme->GLSL shader compiler - much narrower and more tractable.
    - jakeogh 7y ago
      This is likely unrelated, but your comment makes me think of clasp: https://github.com/clasp-developers/clasp https://github.com/clasp-developers/clasp
    - ohpauleez 7y ago
      In case you haven't seen the applications of nanopass compilers to do similar things, specifically harlan, here you go: https://github.com/eholk/harlan https://github.com/eholk/harlan
    - BubRoss 7y ago
      What would it give you to compile scheme to glsl? Glsl is already a pretty direct yet high level representation of shaders. Why put another layer on top of it?
    - absrnd 7y ago
      Check out Hypergiant (Scheme -> GLSL) http://wiki.call-cc.org/eggref/4/hypergiant http://wiki.call-cc.org/eggref/4/hypergiant or CEPL (common lisp -> GLSL) https://github.com/cbaggers/cepl https://github.com/cbaggers/cepl
pjc50 7y ago
Looks like a graduate thesis project, where they ran out of time before they could really explore the capabilities of the system. Slightly disappointing that they seem to have implemented threading but not vectorisation, which would be more suited; does anyone have resources on auto-vectorising Lisp?

69 points by espeed 7y ago

dTal 7y ago

"CuLi and test applications will be published on the webserver of the Johannes Gutenberg University Mainz under https://version.zdv.uni-mainz.de" https://version.zdv.uni-mainz.de" but the link is dead. Anyone know where this can be found? It's a really interesting project that has practical implications for a little hobby project I'm working on.

actondev 7y ago
are you sure about the practical implications? Quoting the abstract: "At the moment, Lisp programs running on CPUs outperform Lisp programs on GPUs"
- dTal 7y ago
  You're right it seems - as written, the parsing overhead from the requirement to make the entire system run the GPU makes it impractical. A hybrid system could outperform CPU or GPU alone. What I really want is a scheme->GLSL shader compiler - much narrower and more tractable.
  - jakeogh 7y ago
    This is likely unrelated, but your comment makes me think of clasp: https://github.com/clasp-developers/clasp https://github.com/clasp-developers/clasp
  - ohpauleez 7y ago
    In case you haven't seen the applications of nanopass compilers to do similar things, specifically harlan, here you go: https://github.com/eholk/harlan https://github.com/eholk/harlan
  - BubRoss 7y ago
    What would it give you to compile scheme to glsl? Glsl is already a pretty direct yet high level representation of shaders. Why put another layer on top of it?
  - absrnd 7y ago
    Check out Hypergiant (Scheme -> GLSL) http://wiki.call-cc.org/eggref/4/hypergiant http://wiki.call-cc.org/eggref/4/hypergiant or CEPL (common lisp -> GLSL) https://github.com/cbaggers/cepl https://github.com/cbaggers/cepl

pjc50 7y ago

Looks like a graduate thesis project, where they ran out of time before they could really explore the capabilities of the system. Slightly disappointing that they seem to have implemented threading but not vectorisation, which would be more suited; does anyone have resources on auto-vectorising Lisp?