

New Scheme-Based GPU Programming Language - wx196
http://devopsangle.com/2013/07/09/new-scheme-based-gpu-programming-language-set-to-turn-chips-into-supercomputers/

======
moomin
I'm sorry, stuff like this just annoys me: "Lisp is the ultimate example of
programmers bending towards making things easiest for compilers."

No. It makes it easier for parsers. Like that macro you want to write. If you
think the hardest part of a compiler is the parser, boy you're in for a shock.

~~~
tater
Not to mention GPUs have no stack, no recursion.

~~~
larsberg
You can compile away those issues with a sufficiently smart compiler!

[https://dl.acm.org/citation.cfm?id=2364563](https://dl.acm.org/citation.cfm?id=2364563)

(Caveat: I'm the author of that paper)

------
tehwalrus
This would be very useful; I've written some OpenCL code (called from Python,
but I coded the Kernel and set up the buffers in C myself) and it's full of
pitfalls; much harder than just "here's an array, here's a procedure. run it
in parallel for me."

I beleive there are already ways to do this (IIRC, F#'s original demo showed
off trivially parallelisible functions), but a simple interface (i.e.
something that looks like a high level language with a REPL etc) is key. As
someone who's generally excited about anything that makes you write Scheme, or
anything that integrates with Python, I'll be keeping an eye on Harlan!

~~~
aa0
The reason it's harder is because it deals with device specifics as well as
type of memory and mapping, queues, workgroup size.. etc.. This framework
might be cute but all it really is doing is what compiler vectorizes have done
for ages.

------
kaoD
Previous discussion:
[https://news.ycombinator.com/item?id=5970975](https://news.ycombinator.com/item?id=5970975)

I'm very excited about this. I think Functional Programming is good at
expressing parallelizable concepts (FP is inherently parallelizable since it
avoids shared state) and always wondered why I had to C my way through
parallelization.

------
mullr
The project in question:
[https://github.com/eholk/harlan](https://github.com/eholk/harlan)

------
dschiptsov
Very clever design decisions. The "high level" code should be written in a
smallest and cleanest language possible, and then compiled, via C, into all
that mess they called OpenCL.

~~~
aa0
Hah. OpenCL is no mess. It has a very specific spec for achieving performance.
A big part of it is the data transfer from host to device and mapping or
read/writing.

These high level abstractions aren't decisive on any of that and will cause
pain and angst when you are really pressed for performance. C is the best for
OpenCL if you want real performance.

------
nightcracker
Ironically the screenshot shows Python code.

