Slashdot Mirror
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.
Is not simple enough ??
I find it hard to believe ANYTHING derived from LISP could simplify anything.
float.kfc shows the basic Scheme-style syntax.
I wonder why it uses .kfc as its extension...
I think you mean Indiana University, mods.
I've skimmed the docs on GPipe because I've been playing with OpenGL and Haskell to do some fractal rendering on the GPU - but of course, the haskell part was just a wrapper around OpenGL function calls loading GLSL shader code. It doesn't seem to be a "shader programming language" so much as a graphics engine that uses the shader pipeline as a backend.
Indian -> Indiana University..
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.
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.
Non-Linux Penguins ?
Incoming lawsuit from Harlan Ellison in 3...2...1
http://michaelsmith.id.au
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.
Ah...Comtrya! Comtrya!
Worst. Signature. Ever.
Syntax Error: "LISP" and "Simplifies" found in the same article.
Lisp.. functional language - Scales well, immutable objects, Well known in Academia ... Runtimes should take care of the how and we focus on the what
Declarative
This is for supercomputing and as such fits in academia and has to scale hence.. .Lisp
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.
Why is it that every single story about something new, whether justified or not, is always met with a torrent of naysayers?
it doesn't simplify it any, it's just yet another flavor someone wants to use.. Just like a lot of languages like Python, which really doesn't bring anything new to the table, except for some people's own love for a syntax they like..
Faster always trumps "easier" in the end. Few languages are programmatically easier than C, it remains to be seen if that is the case here. Often "easier" means "able to do things without an underlying understanding of the architecture", and that's not condusive to Good Eats. (apologies to Alton Brown)
I had a brief foray into Java, but I am amazed at the mileage I've gotten out of the C programming language and it's relatives. (C++, ObjC).
..don't panic
And perhaps from KFC as well... KFC's argument, "Programming languages come and go, but fried chicken is for ever".
LISP? Really?! Were they _trying_ to make the GPU less accessible?
"Consensus" in science is _always_ a political construct.
I had the misfortune to inherit a series of instrument controllers and data collection routines written in Scheme, with hooks into legacy Fortran. A couple of engineers had kept their love of Scheme since university, and 25 years later elected to implement production code in it. Why? Because of the elegance of the grammar, which simplified their job .... because they were steeped in Scheme. When they left the shop, there was no one among the other 50 experienced engineers who had been anywhere near Lisp/Scheme since school. WTF? Who was the PM that allowed a dumb ass engineering decision like that?
I suspect Harlan will see a lot of action in CS departments, and a handful of professionals subjecting their coworkers to it.
Luke, help me take this mask off
Will Quebecois programmers have to use .pfk as an extension?
www.clarke.ca
BTW, there are numerous alternative syntaxes [for Lisp-like languages] around, but none of them was ever successful
Not even JavaScript?
...and I must scream.
As such [Lisp] is readable by programmers and incidentally executed by a machine. In many ways it's almost like writing pseudo code, just in a strange syntax. [...] For a more mainstream language that might fill the same slot I can only think of python.
Yeah, Python is like writing pseudocode too, only without the strange syntax. "Is that the pseudocode?" "No, that's the main function." Yet there are plenty of people on Slashdot who are staunch haters of leading whitespace as block delimiters, despite it being clearer to (human) readers than the parenthesis counting of Lisp.
There is another library in python which also eases gpu programming called Theano. http://deeplearning.net/software/theano/
Lisps, like Scheme and Harlan, can be made readable.
Look at the Readable Lisp S-expressions Project, which extends traditional Lisp notation and adds capabilities such as infix and traditional f(x) style formatting. We provide open source software (MIT license) implementations, including one that can be used as a preprocessor. So, you can have your Harlan and stuff like infix too.
Without these syntax improvements you're right. Very few developers will be happy writing complicated math expressions without infix. And a lot of code that uses GPUs will have significant math expressions.
- David A. Wheeler (see my Secure Programming HOWTO)
The beauty in using a lisp is that in about an hour I could rewrite a couple Common Lisp macros and delete a dozen others to emit code for this instead of the crapfest that currently emits OpenCL. Then the macros implementing DSL's (which the relevant apps themselves are actually written in, except one that's in Python emitting code for a lispy DSL) won't notice or care. Lisp functions are for solving problems; lisp macros are for describing them succinctly. If you're lost in a maze of parens you're doing it entirely wrong.
But I won't, for one reason. Chez only gives you a real compiler if you pay for it. They could have used Gambit or Bigloo or PLT/Racket or Chicken, or a Common Lisp like SBCL but they picked the one that's only useful for toy apps unless you pay. As sexy as it may be being able to describe everything declaratively, I'm not going to pay just to be able to properly benchmark the resultant code to see if Harlan is usable, and a lisp running under interpretation instead of machine code and forcing me to deliver the resultant app with an entire fucking development runtime as if it were still the 1970's makes me want to puke. But Kent unfortunately has a history of using IU to try to sell copies of Chez, so I'm entirely unsurprised. Hopefully this sort of thing will be less common when R7RS gives Scheme a real module system so so much Scheme code isn't tied to a particular implementation.
Replace "structure" with "object" and you'll see why most programmers think in terms of arrays of structures and not structures of arrays.
Anyhow, for me that shows an intrinsic limitation of object oriented languages and why C still rules strong. When you run into the limitations of the hardware, you get to a point where object oriented languages are a limiting factor in optimization.
When I started learning how to program neural networks in the 1980s, I realized that by turning object oriented programs inside out one could get orders of magnitude better performance. That's where the power of C with its flexibility in handling pointers come into play.
Instead of declaring neurons as objects containing inputs, weights, and activation values, I declared arrays of weights, inputs, and activations. That way, calculating the activation of a neuron became a dot product of an array of inputs with an array of weights. The dot product is a common operation that is well optimized in any CPU.
Hate. Let me tell you how much I've come to hate this language since I began to code in it. There are 387.44 million parentheses ensconced around pages and pages of convoluted s-expressions that fill my programs. If the word 'hate' was engraved between each pixel of each character of those thousands of lines it would not equal one one-billionth of the hate I feel for functional programming at this micro-instant. For you. Hate. Hate.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
And people wonder how come getting a Ph.D in CS versus Mechanical Engineering, EE, ChemE, Physics, etc., is a circle jerk waste of time.
People always say it's the parens, but it's not. It's the prefix notation. The first thing that your program does is buried way down in the tree. IMHO, that's why most people find it hard to analyze non-trivial Lisp functions.
(print (eval (read)))
OK, easy. You gotta read, then evaluate, then print the result. In this regard, Lisp is like Forth--not too hard to understand if you write simple, meaningful functions and combine them. I think more Forth programmers are aware of the problem though. Lisp programmers will happily write 20 lines that they understand, but you're chasing through a rats nest to find that ever-elusive first thing the program does
Now I'm not saying S-expressions are never good. When the hierarchy is what you care about, fine. When chronological sequence is being modeled though... wheew. Fuggedaboutit. Maybe I can turn myself into the kind of a person that quickly finds the proper chronology in the code; but why bother when there are much more readable ways to express it?
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Oh, the danger of spitballing code online. About an hour later I'm watching TV and thinking about my last post. Then I recall that the order of evaluation in C is unspecified.
Thus, even if you did try to write C in prefix style, the order in which things are evaluated is potentially botched. In a pure functional language this doesn't matter. Either that, or Lisp specifies an order of evaluation even if you might have side effects. I think. I'd better shut my mouth before I look any more stupid; but the original point stands--C doesn't lend itself to that kind of thing. It's a "portable assembler". One thing happens. Then another, then another, etc...
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
It's actually named after Veit Harlan.