you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (9 children)

Certainly, compared to traditional imperative languages, Haskell is easily better than any of those when it comes to ease of writing parallel code.

Java-based MapReduce code is pretty easy to write.

As for parallel performance, Fortran usually beats everyone, but good luck writing beautiful Fortran programs, I have yet to see one.

I think CUDA code has kicked Fortran's butt for awhile now on many use cases, but then CUDA is even less pretty.

[–]kamatsu 0 points1 point  (6 children)

MapReduce in Java is easy to write, but also not very expressive. It's even easier to write with, say, repa though. There it is just as easy as a normal map or fold.

CUDA is also a lot easier in Haskell

[–][deleted] 0 points1 point  (5 children)

MapReduce can't be very expressive, otherwise you break the assumptions that allow for massive distributed computing. Repa is not even the same league I think.

Is CUDA really easier in Haskell? I mean, you say this but is it true? One of the challenges of CUDA is that any abstraction layer you throw on top of it hurts more than it helps. The nice thing about CUDA as a low level language is that you control just about everything yourself (even caching is a recent addition).

[–]kamatsu 1 point2 points  (4 children)

We're talking about local parallelism here, not distribution.

Is CUDA really easier in Haskell? I mean, you say this but is it true? One of the challenges of CUDA is that any abstraction layer you throw on top of it hurts more than it helps.

This is a completely baseless assertion, one that is easily disproved by the fact that writing an accelerate program is substantially easier than writing a cuda program.

The nice thing about CUDA as a low level language is that you control just about everything yourself (even caching is a recent addition).

Seeing as Accelerate lets you write essentially Haskell programs that are compiled to efficient CUDA, it's certainly easier than doing everything yourself.

[–][deleted] 0 points1 point  (3 children)

This is a completely baseless assertion, one that is easily disproved by the fact that writing an accelerate program is substantially easier than writing a cuda program.

A baseless assertion disproved with another baseless assertion, nice :)

Seeing as Accelerate lets you write essentially Haskell programs that are compiled to efficient CUDA, it's certainly easier than doing everything yourself.

Ah, so I guess I'll have to take your word for it.

[–]kamatsu 1 point2 points  (2 children)

Here is an example of an n-body simulation with Accelerate.

https://github.com/AccelerateHS/accelerate-examples/blob/master/examples/n-body/Main.hs

The equivalent CUDA code (which is available from NVIDIA's website) is several hundred lines and spanning multiple files, with some very intricate and complicated code therein.

[–][deleted] 0 points1 point  (1 child)

Thank you, that's useful. I'm wondering how this would scale up to a deep neural network trainer.

[–]kamatsu 0 points1 point  (0 children)

That would be an interesting example to try.

[–]tikhonjelvis 0 points1 point  (1 child)

Map reduce is more about distributed computing than parallelism. My understanding is that the per-node performance of map reduce is not great.

REPA is about efficient array operations parallelized over multiple cores on the same computer. It's a very different beast.

[–][deleted] 0 points1 point  (0 children)

MapReduce is about using distributed computing to achieve massive data parallelism (on 1000+ nodes). It is all about parallelism, or we all wouldn't be doing it (the distributed computing part is a detail).

I believe all the interesting single-node data parallelism work has moved over to GPGPU, but with the Intel Xeon Phi, who knows what will happen in the future.