News for hackers. Stuff that matters.

A comment on And now for something completely different: running Lisp on GPUs [pdf]. Parent comment

Re:And now for something completely different: running Lisp ... by actondev on Thursday May 30, 2019 @09:46AM (#20051054)
are you sure about the practical implications? Quoting the abstract: "At the moment, Lisp programs running on CPUs outperform Lisp programs on GPUs"
[ Parent | on HN ]
Re:And now for something completely different: running Lisp ... by dTal on Thursday May 30, 2019 @10:13AM (#20051302)
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.

[ Parent | on HN ]
Re:And now for something completely different: running Lisp ... by jakeogh on Friday May 31, 2019 @03:24AM (#20058858)
This is likely unrelated, but your comment makes me think of clasp: https://github.com/clasp-developers/clasp
[ Parent | on HN ]
Re:And now for something completely different: running Lisp ... by absrnd on Friday May 31, 2019 @06:06PM (#20065449)
Check out Hypergiant (Scheme -> GLSL) http://wiki.call-cc.org/eggref/4/hypergiant

or

CEPL (common lisp -> GLSL) https://github.com/cbaggers/cepl

[ Parent | on HN ]
Re:And now for something completely different: running Lisp ... by ohpauleez on Friday May 31, 2019 @07:25AM (#20059897)
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
[ Parent | on HN ]
Re:And now for something completely different: running Lisp ... by BubRoss on Friday May 31, 2019 @10:41AM (#20061309)
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?
[ Parent | on HN ]