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.

Comments

dialect of LISP

[Anonymous Coward]

I find it hard to believe ANYTHING derived from LISP could simplify anything.

Re:dialect of LISP

[marcello_dl]

Because lisp-style languages are already simplified to the extreme, you mean? Phew, for a moment I thought I spotted a troll.

Re:dialect of LISP

[smittyoneeach]

The question is whether simplifying the syntax down to a nubbin really flattens the learning curve or not.

Re:dialect of LISP

[aaaaaaargh!]

Yes, it does.

Re:dialect of LISP

[ecotax]

((easy)is)lisp

--------------------- ^ Missing parenthesis

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.

Re:dialect of LISP

[Alomex]

You mean your "deep reason" was to aid a brain addled parser so that it doesn't have to cogitate about what is looking at?

I thought you were aiming higher than that.

Link to a simple example

[Wootery]

float.kfc shows the basic Scheme-style syntax.

I wonder why it uses .kfc as its extension...

Re:Link to a simple example

[zdzichu]

Holk reveals that the name Harlan comes from a mishearing of fried chicken icon Colonel Sanders' first name, Harland, and this association is also why all the file extensions for Harlan programs are .kfc.

Re: Link to a simple example

[Jmc23]

The other half is blowing stuff up.

Indian University?

[Anonymous Coward]

I think you mean Indiana University, mods.

Re:Indian University?

[shikaisi]

I think you mean Indiana University, mods.

No. It's been outsourced.

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.

Re:Indiana, not Indian

[abies]

Scheme/lisp was a bit helpful in the way it has a lot of features simplifying code generation. In fact, lisp is ultimate example of programmers bending towards making things easiest for compilers. It is a lot easier to transform lisp-like code into other representation - you don't really need to write lex/bison-like parser part of the grammar, you can immediately start with transforms.

But it doesn't make it simplier for people using the final language - just for the guy writing the compiler. You have to be masochist to prefer to write

    (define (point-add x y)
        (match x
            ((point3 a b c)
              (match y
                  ((point3 x y z)
                    (point3 (+ a x) (+ b y) (+ c z)))))))

instead of something like

define operator+(point3 a, point3 b) = point3(a.x+b.x,a.y+b.y,a.z+b.z)

Lisp makes writing DSLs easy - but resulting DSLs are still Lisp. In the era of things like XText, which provide full IDE with autocompletion, project management, outlines etc on top of your DSL, there is no real excuse to make things harder then needed

Change in thinking

[dargaud]

I just started doing some GPU programming and the change in thinking that it requires even for very simple things can be hard for programmers. I don't know if this language forces us to think in new terms, but here's a very simple example: we often use arrays of structures. Well, a GPU can optimize computations on arrays but not on structures, so it's better to use structures of arrays... Even is less natural for the programmer. Plenty of small examples like that that don't really depend on the language you use.

Re:Change in thinking

[Rockoon]

Well, a GPU can optimize computations on arrays but not on structures, so it's better to use structures of arrays... Even is less natural for the programmer.

It is only less natural for you because you've ignored the CPU's SIMD extensions all this time.

My question is if in all this time that you have avoided the CPU SIMD extensions, then why is it at all important that you find the GPU's version of it less natural?

(queue the folks that dont realize that SoA SSE code is a lot faster than AoS SSE code, but will now rabidly defend their suboptimal and thus mostly pointless usage of SSE)

A marketeer wrote the article

[Vincent77]

There are several languages that are written on top of OpenCL - that is the whole idea of this API. But if your read the article, it seems this guy was the actual inventor of the wheel.

Same response happened when some guy made Rootbeer and let some marketeer write an alike article. It was suggested that you could just run existing Java-code on the GPU, but that was not true at all - you had to rewrite the code to the rootbeer-API. This Harlan-project is comparable: just beta-software that has not run into the real limits of GPU-computing - but still making big promises that in contrary to their peers they actually will fix the problem.
I'm not saying it can be in the future, but just that this article is a marketing-piece with several promises on future advancements.

Check out Aparapi and VexCL to name just two. There are loads and loads of these solutions - many of these wrappers slowly advance to higher level languages, and have been in the field a lot longer.

Comtrya!

[fellip_nectar]

Ah...Comtrya! Comtrya!

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.

Simplify != LISP

[fygment]

LISP? Really?! Were they _trying_ to make the GPU less accessible?

Re:MOV ES:[BP],#255,ecx,xyz !!

[nospam007]

"MOV ES:[BP],#255,ecx,xyz
Is not simple enough ??"

That's only the old use of those cards, nowadays kids need functions like MakeBitCoins(500) or SETIFindET() and so on.

Re:Python as pseudocode

[grumbel]

The problem with the whitespace is that it makes copy&paste between different block levels extremely troublesome and fragile. It leads to lots of issues that you would never have with a proper block-end statement.