Slashdot Mirror

← Back to Stories (view on slashdot.org)

Harlan: a Language That Simplifies GPU Programming

Posted by Soulskill on from the i-wonder-if-it's-short-and-angry dept.

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.

6 of 195 comments (clear)

  1. Indiana, not Indian by Dan+East · · Score: 4, Insightful

    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.

    --
    Better known as 318230.
  2. Hmm by DrXym · · Score: 1, Insightful

    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.

    1. Re:Hmm by Anonymous Coward · · Score: 2, Insightful

      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.

  3. Re:dialect of LISP by Bacon+Bits · · Score: 3, Insightful

    It certainly flattens the syntax learning curve.

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

    --
    The road to tyranny has always been paved with claims of necessity.
  4. Re:dialect of LISP by smittyoneeach · · Score: 3, Insightful

    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.

    --
    Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
  5. Re:dialect of LISP by Alomex · · Score: 3, Insightful

    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.