If you can't make a language fast, make it parallel • Hacker News Board

Re: If you can't make a language fast, make it parallel

#31

Post by carterschonwald » Sat, Jul 31, 2010, 2:37 AM UTC

kanak wrote: post #19

alec wrote: post #16

Earlier quoted context omitted.

Fortress makes a convincing argument that it must be supported at the language level. It has a smart work splitting algorithm that does for managing parallelism granularity what garbage collection did for managing memory allocation. It works much better when it's baked into the core and is available from the ground up.

> a smart work splitting algorithm Not to detract from anything you said (which I agree with), but when Guy Steele gave a guest lecture at my university on Fortress a few months ago, he said that the work splitting algorithm still needed work, in particular the part that decided the right amount of granularity for the given task (i.e. when to stop splitting the task into smaller subtasks).

shouldn't it also be set up so that different algorithms can be swapped in? I think its pretty accepted at this point that different application scenarios perform better with differently tuned schedulers..

Re: If you can't make a language fast, make it parallel

#32

Post by cjenkins » Sat, Jul 31, 2010, 2:54 AM UTC

jerf wrote: post #29

j_baker wrote: post #22

Earlier quoted context omitted.

"I do not know where Clojure or Scala have a generic cross-process messaging ability, and I'm not saying it's impossible by any means, but it's much easier if you start from scratch with that in mind." I don't understand how. The only difference I see is whether the interprocess communication parts are coded into the language itself or whether they're coded into a library. It could theoretically make the problem more…

For the real answer to this question, attempt to implement a generic serialization syntax for Haskell that requires no work by the user to use. Not even declaring typeclasses. Not even requiring Typeable to be implemented. Just feed it a datatype, and even if the other end has a different version of the software installed (which can happen in a distributed system, after all), it'll all Just Work to some degree. Erlan…

This comment resonates with me especially well today.

I've been attempting to work with GWT and the serialization issues are entertaining (did you implement IsSerializable? is there a no-arg constructor? Do all of the classes your class depend on have the same? Did you remember to recompile the GWT/JS code to update the serialization white list? etc.).

It makes me appreciate more playing with Erlang a while back and shooting data around being so simple.

Re: If you can't make a language fast, make it parallel

#33

Post by astrange » Sat, Jul 31, 2010, 4:15 AM UTC

pufuwozu wrote: post #24

malkia wrote: post #21

Let's face it - it's not the language that is the problem. It would help you, but it would help you only with some percentage of the problems out there. For example - there does not exist a practical language (or design) where you can implement the LZ compression (ZLIB, others) in parallel, so that it gives the same results as the sequential "c" version. It's just that certain algorithms, hence protocols, data struct…

Isn't Pigz a parallel implementation of gzip which is itself based upon LZ77? http://www.zlib.net/pigz/ Hasn't there been a few parallel implementations of bzip2? http://compression.ca/pbzip2/ http://bzip2smp.sourceforge.net/ I understand that parallelism isn't suited for a lot of algorithms but from what I can tell, there's been heaps of successful work in compression. Could you give us some more information? It wou…

Compression algorithms are poorly suited to parallelism, because they remove everything that isn't a data dependency in the input, and parallelism is nothing but a lack of data dependencies.

The trick is to start at the largest chunk possible and go down until you find where they have left in some, uh, non-dependencies - like bzip2 which has independent x*100KB blocks, and video which (usually) has independent frames. You should be able to get 2-4 separate tasks out of that, which is good enough for CPUs.