Harlan: a Language That Simplifies GPU Programming

hypnosec writes "Harlan – a declarative programming language that simplifies development of applications running on GPU has been released by a researcher at Indiana University. Erik Holk released his work publicly after working on it for two years. Harlan's syntax is based on Scheme – a dialect of LISP programming language. The language aims to help developers make productive and efficient use of GPUs by enabling them to carry out their actual work while it takes care of the routine GPU programming tasks. The language has been designed to support GPU programming and it works much closer to the hardware." Also worth a mention is Haskell's GPipe interface to programmable GPUs.

Indiana, not Indian

[Dan East]

According to the story it is Indiana University, not Indian University.

I wonder if scheme was in some way necessary or conducive to running on the gpu, or if that was an arbitrary choice. I still have nightmares of car and cdr from way back when.

Hmm

[DrXym]

Lisp code is practically unreadable thanks to all the parentheses without good formatting and even then looks totally foreign to people brought up on C or Java. For example all the computations are completely backasswards thanks to polish notation. A better language for GPU programming would be one which at least retains the essence of C and provides convention based techniques and inference to relieve some of the effort of writing out OpenCL kernels.

Re:Hmm

[Anonymous Coward]

And C is virtually unreadable to anyone brought up with Smalltalk and Ada, so what's your fucking point? It takes something like three days maximum to get used to prefix notation, so learn it if you want to use the tool, and get over with your irrational and insubstantial syntax preferences.

Re:dialect of LISP

[Bacon Bits]

It certainly flattens the syntax learning curve.

The algorithm learning curve on the other hand....

Re:dialect of LISP

[smittyoneeach]

What, the unity of data and code?
Sure, it's academically cooler not to kick your design out of the Garden of Eden, but let's not kid ourselves: besides performance, the other reason Lispy systems haven't conquered is that it's darn hard to have a business model that DOESN'T separate code and data to at least some degree.
This is more an observation than a value judgement about the "rightness" of the situation.

Re:dialect of LISP

[Alomex]

Right, because the only possible way to equate data and code is to wrap it around in an untold number of parentheses. For example if we were to change

(define X (blah blah))

to

define X = blah blah

there is no possible way we could all agree that define returns a list and save the parentheses. /sarcasm

Reality is there is no deep reason to layer scheme with so many parentheses outside the lack of imagination of scheme fanatics.