Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Harlan: a Language That Simplifies GPU Programming

Soulskill posted about a year ago | from the i-wonder-if-it's-short-and-angry dept.

Programming 195

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.

cancel ×

195 comments

Sorry! There are no comments related to the filter you selected.

MOV ES:[BP],#255,ecx,xyz !! (1)

Anonymous Coward | about a year ago | (#44193171)

Is not simple enough ??

Re: MOV ES:[BP],#255,ecx,xyz !! (1, Funny)

Anonymous Coward | about a year ago | (#44193281)

I think that's supposed to be: ecx, xyz, M-O-U-S-E

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

Anonymous Coward | about a year ago | (#44193325)

A M-O-U-S-E bit my sister once.

Re:MOV ES:[BP],#255,ecx,xyz !! (3, Funny)

nospam007 (722110) | about a year ago | (#44194059)

"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.

dialect of LISP (4, Funny)

Anonymous Coward | about a year ago | (#44193175)

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

Re:dialect of LISP (5, Funny)

marcello_dl (667940) | about a year ago | (#44193251)

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 (2)

smitty_one_each (243267) | about a year ago | (#44193259)

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

Re:dialect of LISP (2)

aaaaaaargh! (1150173) | about a year ago | (#44193451)

Yes, it does.

Re:dialect of LISP (3, Insightful)

Bacon Bits (926911) | about a year ago | (#44193597)

It certainly flattens the syntax learning curve.

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

Re:dialect of LISP (1)

ebno-10db (1459097) | about a year ago | (#44193925)

Then why bother with parentheses? Binary is an even simpler syntax.

Re:dialect of LISP (1)

Anonymous Coward | about a year ago | (#44193593)

That's a question. The question is why does LISP persist with that syntax. There is a very very deep reason for this which you should discover for yourself. Once you've discovered that, the learning curve will be irrelevant for two reasons. The less important reason being you'll already be over it ;)

Re: dialect of LISP (1)

Anonymous Coward | about a year ago | (#44193651)

Why does LISP syntax persist? That's easy, because programming languages are developed by geeks, and geeks think LISP is cool. (And it _is_ cool -- but that doesn't make it a good model for productive programming.)

Re:dialect of LISP (3, Insightful)

smitty_one_each (243267) | about a year ago | (#44193711)

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 (3, Insightful)

Alomex (148003) | about a year ago | (#44193783)

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 (0)

Anonymous Coward | about a year ago | (#44193845)

However, that should read

define X = blah(blah)

because you forgot to quote the list. You've saved one set of parentheses and no character to type (because of '=' and your statement needs a line ending).

Another question is whether you are able call a function with itself as an argument in your preferred language...

Re:dialect of LISP (1)

Alomex (148003) | about a year ago | (#44193971)

Only if you persist in using parentheses everywhere. If you really think about it the supposed symmetry between data and code is not really there, hence the quote. In other words no matter how hard you try to make it look like they are the same either you end up quoting data or you represent functions explicitly via the f( ) convention.

The advantages of the latter are that (1) mimics math notation and (2) keeps the number of parentheses down.

Another question is whether you are able call a function with itself as an argument in your preferred language...

Algol had that already in the 60s without need for endless parentheses.

Re:dialect of LISP (0)

Anonymous Coward | about a year ago | (#44193967)

Instead of misguiding people online you would be better off studying SICP.
Of course there is a very deep reason to correctly nest your code (and data) with these parentheses.
Remember that in the end the parser all that knows are pairs (A . B) where B can be a pair and through
this you construct lists. Now it is exactly this reasoning that lets you structure your code in pairs (or lists) too
and through this syntactic unification you get all the interesting functionality that scheme enables.
 

Re:dialect of LISP (2)

Alomex (148003) | about a year ago | (#44193991)

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.

Re:dialect of LISP (0)

Anonymous Coward | about a year ago | (#44194019)

enjoy your C++ ;p

Re:dialect of LISP (1)

lxs (131946) | about a year ago | (#44193295)

((easy)is)lisp

Re:dialect of LISP (3, Funny)

ecotax (303198) | about a year ago | (#44193467)

((easy)is)lisp

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

Re:dialect of LISP (1)

dbIII (701233) | about a year ago | (#44193643)

Wrong (very wrong (indeed it is as wrong as that incident last week (last week being in June)))

Re:dialect of LISP (1)

Charliemopps (1157495) | about a year ago | (#44193803)

You likely write code in a syntax that was derived from Lisp every day and don't even realize it.

Link to a simple example (2)

Wootery (1087023) | about a year ago | (#44193191)

float.kfc [github.com] shows the basic Scheme-style syntax.

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

Re:Link to a simple example (5, Informative)

zdzichu (100333) | about a year ago | (#44193209)

Holk reveals [theincredibleholk.org] 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 (1)

Wootery (1087023) | about a year ago | (#44193309)

And now I know ;P

Re: Link to a simple example (-1)

Anonymous Coward | about a year ago | (#44193353)

And knowing is half the battle...

Re: Link to a simple example (2)

Jmc23 (2353706) | about a year ago | (#44193479)

The other half is blowing stuff up.

Quebec (1)

aclarke (307017) | about a year ago | (#44193927)

Will Quebecois programmers have to use .pfk as an extension?

Re:Link to a simple example (0)

Anonymous Coward | about a year ago | (#44193235)

Maybe it's a small nugget of code.

Re:Link to a simple example (0)

Anonymous Coward | about a year ago | (#44193421)

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

I wonder why they decided to use the indentation in a way to make the code less readable.

(module
  (define (main)
    (print (+ 0.125 0.125))
    (print (int->float 42))
    (return 0)
  )
)

End parenthesis should be on the same indentation as the line with the start parenthesis whenever they are on separate lines, unless you enjoy spending hours to find where the missing parenthesis should be placed.
Mixing indentation depth is also a great way to make code unreadable.

Re:Link to a simple example (1)

aaaaaaargh! (1150173) | about a year ago | (#44193477)

Putting closing parentheses on one line like in the original code is standard convention in most LISP and Scheme languages. The editor takes care of the closing parentheses for you and will give you constant visual feedback on the level you're at and where the opening paren is (e.g. by color coding). Indentation and pretty-printing will also be automatic in any reasonable, modern editor (such as e.g. vim or Emacs).

Re:Link to a simple example (0)

Anonymous Coward | about a year ago | (#44193641)

This completely defeats the argument "simple syntax". If you need the IDE to be able to parse it, then it is anything but not simple.

Re:Link to a simple example (0)

Anonymous Coward | about a year ago | (#44193909)

I don't know, you just seem like another guy who doesn't know what he's talking about. Apart from the fact that LISP (after Forth) has just about the simplest syntax imaginable, there was no argument about "simple syntax" anyway. We were talking about ease of use and readability. In my experience people who claim that S-expression syntax is complicated or hard to understand have never actually used any LISP/Scheme system for more than briefly toying around. Seriously, I have never met anyone who actually used LISP for a longer time and complained about its syntax. (BTW, there are numerous alternative syntaxes around, but none of them was ever successful because people didn't feel a need for them.)

ECMAScript is the M-expression realized (1)

tepples (727027) | about a year ago | (#44194025)

BTW, there are numerous alternative syntaxes [for Lisp-like languages] around, but none of them was ever successful

Not even JavaScript [stackoverflow.com] ?

Re:Link to a simple example (1)

tepples (727027) | about a year ago | (#44194045)

The editor takes care of the closing parentheses for you

Perhaps a LISP-specific editor does, but the editor that ships with a computer does not. Even basic features such as automatic copying of leading whitespace from the previous line aren't omnipresent among editors that ship with computers.

Re:Link to a simple example (-1, Troll)

Jmc23 (2353706) | about a year ago | (#44193491)

No. No they shouldn't. This isn't C and a programmer that doesn't use a computer to keep track of his parentheses isn't much of a programmer.

Re:Link to a simple example (0)

Anonymous Coward | about a year ago | (#44193603)

Seeing something immediately is always preferable to anything a computer can do for you.

Re:Link to a simple example (1)

Charliemopps (1157495) | about a year ago | (#44193827)

Stop using notepad to do your coding and this ceases to be a problem.

Indian University? (3, Informative)

Anonymous Coward | about a year ago | (#44193195)

I think you mean Indiana University, mods.

Re:Indian University? (3, Funny)

shikaisi (1816846) | about a year ago | (#44193527)

I think you mean Indiana University, mods.

No. It's been outsourced.

Re:Indian University? (1)

paxprobellum (2521464) | about a year ago | (#44193879)

Came here to say this.

GPipe (1)

Anonymous Coward | about a year ago | (#44193197)

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.

Re:GPipe (1)

Weezul (52464) | about a year ago | (#44193247)

Is the haskell compiler actually generating the shader code?

Re:GPipe (1)

abies (607076) | about a year ago | (#44193351)

I think it can, but seems it is so complicated and unreadable that sample project at https://github.com/csabahruska/GFXDemo [github.com] is using gsl for shaders...

nitpicking (0)

Anonymous Coward | about a year ago | (#44193205)

Indian -> Indiana University..

Re: nitpicking (0)

Anonymous Coward | about a year ago | (#44193675)

Is that the American Indiana University or the East Indiana University? ;-)

Indiana, not Indian (4, Insightful)

Dan East (318230) | about a year ago | (#44193211)

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 (4, Interesting)

abies (607076) | about a year ago | (#44193329)

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 [eclipse.org] , 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

Re:Indiana, not Indian (1, Flamebait)

vikingpower (768921) | about a year ago | (#44193397)

In the era of things like XText [eclipse.org] , 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

Bullshit. Did you ever try and actually design, write, develop and maintain an industrial-strenght DSL with Xtext ? If yes, then I would be interested to hear from your experience. If not, hear mine: it is hell.

Re:Indiana, not Indian (1)

Goaway (82658) | about a year ago | (#44193437)

I always found it deeply ironic that SICP, of all books, starts out with the statement that "Thus, programs must be written for people to read, and only incidentally for machines to execute", and then goes on to use Scheme.

Re:Indiana, not Indian (0)

Anonymous Coward | about a year ago | (#44193529)

It's not so ironic really.
Lisp and other languages like SML are meant to concentrate on the algorithm, not the implementation.
As such it 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.
That's why a lot of american unis use it for their introduction to programming courses.

Those languages are just rather different than what most people are used to and are as such rejected by many.
I guess some will find it easier to adapt to the different model of thinking as well.

For a more mainstream language that might fill the same slot I can only think of python.

Re:Indiana, not Indian (0)

Anonymous Coward | about a year ago | (#44193613)

For a more mainstream language that might fill the same slot I can only think of python.

Sorry, any language with "global by default" is automatically disqualified from consideration :)

Re:Indiana, not Indian (1)

akanouras (1431981) | about a year ago | (#44193685)

He said Python, not Javascript.

Re:Indiana, not Indian (-1, Redundant)

Jmc23 (2353706) | about a year ago | (#44193463)

Dude, just because you don't know how to write good lisp doesn't mean others can't. Nor do you seem to understand how to write a decent dsl in lisp or that you can make the syntax anything that you want including the mess you wrote at the end. I feel like gouging my eyes out looking at what you wrote. It's the lisp strawman again.

Re:Indiana, not Indian (0)

Jmc23 (2353706) | about a year ago | (#44193517)

;) oops, /. really needs an edit. Forgot my emoticon!

Re:Indiana, not Indian (1)

abies (607076) | about a year ago | (#44193647)

Please note that lisp stuff above is taken from Harlan - so if you complain about it being ugly, please take it with the guy who came up with Harlan in first place. It _might_ be possible to do better DSL in Lisp, but I was complaining about the route which Harlan has taken.

Re:Indiana, not Indian (1)

Charliemopps (1157495) | about a year ago | (#44193865)

I dunno, I always liked LISP. There's more typing but it seems logical to me. And the ease of transforming it to something else shouldn't be down played. I've got one API that I have to use frequently that uses LISP like code for sales reports... and often I have to dump that into an excel spreadsheet for some of my sales people... so I wrote a script that did it for me. It's actually really simple. I couldn't imagine doing that with any other language. I just copy the code, run my script, paste into excel and I've got a working spreadsheet that does the same thing the LISP report did.

Re:Indiana, not Indian (0)

Anonymous Coward | about a year ago | (#44193915)

Why wouldn't you import the excel object model and use it directly, or export to some separated value/xml file instead of pasting?

Re:Indiana, not Indian (1)

10101001 10101001 (732688) | about a year ago | (#44193795)

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

See, that makes a lot more sense. :)

I wonder if scheme was in some way necessary or conducive to running on the gpu, or if that was an arbitrary choice.

I'd say it's a mixture of both. On the one hand, Professor R. Kent Dybvig [indiana.edu] is one of the editors behind R6RS [r6rs.org] (and earlier editions) and author of Chez Scheme. In general, IU uses Scheme as one of the major languages to teach things including compiler design, so basically a CS alumni from IU is almost always a Schemer (or perhaps an anti-Schemer from the experience :)). That boils down to the point that Scheme is basically a much simplified version of Lisp (basically, the reverse of Lisp in complexity) which can function as a functional language (with all the inherent thread-safe features) if you're careful about not using mutable functions on your data, and Scheme readily supports 1st order and anonymous functions. Given that GPUs (and Cell processors) are basically very apt for those properties, it'd seem to be quite a good fit. Having said all that, there's probably plenty of other functional languages that are as good or even better for the job--the very scope of Scheme being such a cut down language good for teaching also tends to make it a pain to actually use in any production environment because of a lack of libraries, so I hope Harlan is designed to hand off the non-GPU work to another language.

I still have nightmares of car and cdr from way back when.

Can't really help you there. Personally, car and cdr ended up making linked-list so intuitive for me that I'm often perplexed why anyone has so much trouble with them, especially with memory leaks and the like. :/

Change in thinking (4, Informative)

dargaud (518470) | about a year ago | (#44193217)

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 (2)

Rockoon (1252108) | about a year ago | (#44193415)

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)

Re:Change in thinking (0)

Jmc23 (2353706) | about a year ago | (#44193441)

I hope you realized you responded to a code monkey who didn't understand a word you said.

Re:Change in thinking (0)

Anonymous Coward | about a year ago | (#44193483)

(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)

Perhaps you actually harbor a vituperative wish for the benighted, ignorant folks to be forced to stand in line (to what end?), but if you were to cue the ignoramuses then they could come to sling their vituperations upon *you*.

If done properly it could be quite the social event. I'm thinking "Flash Mob to Excoriate Rockoon", with disco dancing (just to add surreality).

Re:Change in thinking (0)

Anonymous Coward | about a year ago | (#44193519)

Looks like he struck a nerve.

Re:Change in thinking (0)

Anonymous Coward | about a year ago | (#44193539)

the guy had a point. you don't even need to go to simd to make the point. arrays of should be pretty natural for a coder.

if you see someone representing a bitmap as an array of objects with 8 bit members r,g,b,a.. and then someone manipulating the same data as just an array of bytes(or 32bit whatevers).. you should know that the other way is a code monkey way and the other one is the right one even if the book says it's confusing.

Re:Change in thinking (0)

Anonymous Coward | about a year ago | (#44193567)

ZOMG, wait! So, what you're saying is that AoS != SoA, kind of like "queue" != "cue"?

As in, all of these terms have separate, distinct definitions that do not overlap? And it matters which one you use because they're not interchangeable?

Mind blowing.

Re:Change in thinking (0)

Anonymous Coward | about a year ago | (#44193665)

No, it's less natural because it's less natural. AoS is a pain in the ass and doesn't integrate with basic host-language idioms. You avoid it like the plague unless you (a) can really benefit from optimal SIMD code because your memory accesses are or will be optimal (b) can take the cost of making the host-language talk to these weird data structures, including poorer L1 usage for many higher-level uses and/or two reformatting steps and (c) can prove those things will remain true for the maintenance lifetime of the project. Unless you can answer yes to all these, you're doing premature optimization. And none of this applies unless you are on a platform that lacks a decent swizzle instruction (SSE - check). Your processor will perform FPU and swizzle operations in parallel, so accessing SoA can be just as fast as all this AoS nonsense, and has zero integration cost to the rest of the program. You need something that can unpack bytes and shorts in one instruction though, as found just about everywhere except Intel, unless all your data is 32 bits wide (see: L1 cache, optimal usage of).

rabidly defend their suboptimal and thus mostly pointless usage of SSE

No, you need AoS on SSE. That's why SSE sucks so badly compared to AltiVec or SPU.

Re:Change in thinking (0)

Anonymous Coward | about a year ago | (#44193715)

I just realized I swapped AoS and SoA everywhere in my comment :) Hope it doesn't affect readability too badly :)

Re:Change in thinking (0)

Anonymous Coward | about a year ago | (#44193505)

Well, my 2cents worth....In terms of databases, column based storage versus row based storage often goes hand in hand with list based processing. Eg kdb. So, I am guessing that lisp is the ideal language for this new thinking required.

Re:Change in thinking (1)

dmbasso (1052166) | about a year ago | (#44194035)

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.

Except for Python/NumPy and Matlab programmers (and perhaps Fortran, idk, never used it).

I was pleasantly surprised when I adapted my Python code (some image processing / neural network stuff) to use OpenCL, and without much effort achieved a 70% reduction in processing time.

Oh no (0)

MichaelSmith (789609) | about a year ago | (#44193321)

Incoming lawsuit from Harlan Ellison in 3...2...1

Re:Oh no (0, Funny)

Anonymous Coward | about a year ago | (#44193347)

No shit. Do these people know who they named their language after?

If you thought Carl Sagan overreacted when Apple used 'Sagan' as an (internal!) code name, you ain't seen nothin' yet. Prepare for a broadside of cease-and-desist orders from the original BHA (ButtHead Author.)

Posted anonymously because hey, life's too short to tangle with this particular asshole.

Chicken (1)

mynameiskhan (2689067) | about a year ago | (#44193777)

And perhaps from KFC as well... KFC's argument, "Programming languages come and go, but fried chicken is for ever".

Re:Chicken (0)

Anonymous Coward | about a year ago | (#44193899)

And perhaps from KFC as well... KFC's argument, "Programming languages come and go, but fried chicken is for ever".

Yeah! What's the matter Colonel Sanders? - Chicken?

A marketeer wrote the article (4, Informative)

Vincent77 (660967) | about a year ago | (#44193349)

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 [slashdot.org] . 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 [google.com] and VexCL [github.com] to name just two. There are loads [khronos.org] and loads [streamcomputing.eu] of these solutions - many of these wrappers slowly advance to higher level languages, and have been in the field a lot longer.

Comtrya! (2)

fellip_nectar (777092) | about a year ago | (#44193359)

Ah...Comtrya! Comtrya!

Syntax Error (1)

Anonymous Coward | about a year ago | (#44193367)

Syntax Error: "LISP" and "Simplifies" found in the same article.

Language choices (0)

Anonymous Coward | about a year ago | (#44193379)

Lisp.. functional language - Scales well, immutable objects, Well known in Academia
Declarative ... Runtimes should take care of the how and we focus on the what

This is for supercomputing and as such fits in academia and has to scale hence.. .Lisp

Re:Language choices (0)

Anonymous Coward | about a year ago | (#44193661)

Declarative is completely subjective. An if...else statement is declarative, since you tell what do you want and the compiler takes care of the how. Declarative vs. Imperative is completely meaningless.

Hmm (1, Insightful)

DrXym (126579) | about a year ago | (#44193387)

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 (2, Insightful)

Anonymous Coward | about a year ago | (#44193513)

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:Hmm (0)

Anonymous Coward | about a year ago | (#44193617)

The number of C users exceeds the number of smalltalk/ada users by 5 orders of magnitude?

Re:Hmm (1)

DrXym (126579) | about a year ago | (#44193621)

My point Einstein, is that C is the language that CUDA, Cell, OpenCL and OpenGL SL are derived from. So it's a rather useful property of MagicNewLanguage if it is similar to what people are accustomed to already, preferably allowing them to express the same concepts in a terser but similar form. Assuming that is, that the person who created MagicNewLanguage stands any hope of persuading people to use it.

Practical Example (1)

cmholm (69081) | about a year ago | (#44193851)

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.

Re:Hmm (1)

splutty (43475) | about a year ago | (#44194037)

I suspect one of the main reasons for using Lisp/Scheme style notation, is that almost all GPU programming anyone would want to do are (based on) mathematical equations.

For mathematicians, a Lisp notation is actually a lot more logical and easier than a C notation. (At least the older ones :)

The whole concept of iterations in calculations is a bit awkward in C (with all the parenthesis, yes...) in comparison to Lisp (where they're fairly well delineated blocks if properly indented)

Yes, you can mostly do the same in C, but I'd bet most mathematicians have more experience with ADA/Lisp than with C :)

Chicken/Egg sort of thing, then, now that I've typed all this out.

News for luddites (0)

Anonymous Coward | about a year ago | (#44193457)

Why is it that every single story about something new, whether justified or not, is always met with a torrent of naysayers?

Re:News for luddites (1)

gl4ss (559668) | about a year ago | (#44193547)

Why is it that every single story about something new, whether justified or not, is always met with a torrent of naysayers?

because the article is filled with references to "snob" languages? can I use this language easily from with c++? java? .net? in android?

Re:News for luddites (0)

Anonymous Coward | about a year ago | (#44193801)

Because Slashdot does not exist to echo positive feelings back and forth until we're all at +5 insightful for comments of "+1", "yay!" and "Great job, buddy!". Most of the naysaying comments here are pointless (all of the people complaining about Lisp, etc), but even those are orders of magnitude better than what yeasayers would produce.

kafi25 (-1)

Anonymous Coward | about a year ago | (#44193473)

helo,
http://www.univ-ouargla.dz
http://bu.univ-ouargla.dz
http://elearn.univ-ouargla.dz
http://dspace.univ-ouargla.dz
http://manifest.univ-ouargla.dz
http://revues.univ-ouargla.dz
http://annuaire.univ-ouargla.dz
http://labo.univ-ouargla.dz
http://facultes.univ-ouargla.dz
http://fsnv.univ-ouargla.dz
http://fsecg.univ-ouargla.dz
http://fdsp.univ-ouargla.dz
http://fshs.univ-ouargla.dz

BS (1)

SuperDre (982372) | about a year ago | (#44193521)

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..

Re:BS (0)

gl4ss (559668) | about a year ago | (#44193565)

I think curly braces were on short supply.

  (define (main)
        (let* ((bodies (make-points 1000))
                      (start (nanotime))
                      (forces (nbody bodies))
                      (stop (nanotime)))
            (print "Computed ")
            (print (length forces))
            (print " forces in ")
            (print (/ (- stop start) 1000000))
            (println "ms"))
        (return 0)))

actually, I'll bet you 100 bucks it was written on a mac osx. how did you make that guess before checking? well fuck the mac keyboard doesn't have the curly braces printedon them! so of course it's simpler if you don't have to use them :D

(tested on Mac OS X 10.6 (Snow Leopard)
Mac OS X 10.7 (Lion)
Mac OS X 10.8 (Mountain Lion))

Re:BS (1)

angel'o'sphere (80593) | about a year ago | (#44193635)

American Mac keyboards have {} [] printed on them.
It is only european (all or only german?) that don't have.
Also keep in mind, Lisp was invented long before Macs.

Re:BS (1)

gl4ss (559668) | about a year ago | (#44193669)

it's probably all european, since scandinavian keyboards miss the prints. funny thing is that it doesn't help at all that they're missing them, they just thought it would look cooler if they weren't printed on them..

or is it all modern mac keyboards? I seem to recall that the older pre-steve-batshit-crazied macs had them?

Re:BS (1)

angel'o'sphere (80593) | about a year ago | (#44193983)

That has nothing to do with Mac or not Mac, it is a keyboard layout problem. Yes, PC keyboards access them via ALT-GR and show the keys ...

Non programmers don't need [] {} at all, so non programmers don't miss them.

OTOH americans have not the special chars we put on the [] {} places, like german Umlauts (sorry can not show them here as /. will eat them).

Re:BS (1)

ybanrab (2556762) | about a year ago | (#44193659)

I'd like a keyboard printed hash # (alt-3, replaced on keyboard with £) but both UK Apple keyboards in front of me have () [] {} ?

http://www.apple.com/keyboard/ [apple.com]

Re: BS (1)

CadentOrange (2429626) | about a year ago | (#44193705)

I don't get this. I have curly braces on my Mac keyboard...

C is dead. Long live C! (1)

xtal (49134) | about a year ago | (#44193755)

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).

Re:C is dead. Long live C! (0)

Anonymous Coward | about a year ago | (#44193989)

Eventually, the speed that your programs run will not be determined by how optimized individual pieces are, but by how parallel you made it. I personally do not want to live in a world where I have to hand manage mutexes, threads, processes, etc.

C is not going to survive that eventuality in the mainstream, but will find its way into the closet of languages of the past.

Simplify != LISP (3, Funny)

fygment (444210) | about a year ago | (#44193837)

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>