View mode: basic / threaded / horizontal-split · Log in · Help
April 23, 2010
Things I Learned from ACCU 2010
* Not all functional programming languages do concurrency well. Haskell and 
OCaml in particular have severe fundamental problems with it such that 
parallelizing your code makes it slower. Erlang and Clojure parallelize well, in 
that performance scales up proportionally as cores are added.

* The future of multi-core hardware is to not have any shared memory, each core 
will have its own address space. Message passing looks like the future.

* Monads have nothing in particular to with I/O. All monads are are a way to 
insert code to pre-process arguments going to a function, and insert code to 
post-process the result coming out of that function.

* Probably nobody understands how to use C++0x atomics correctly, or ever will.

* People really understand and get testing and how it improves programming.
April 23, 2010
Re: Things I Learned from ACCU 2010
Walter Bright wrote:
> * People really understand and get testing and how it improves programming.

For example, this hilarious video was shown by James Bach, who created it:

http://www.youtube.com/watch?v=M37VOKIaDUw
April 23, 2010
Re: Things I Learned from ACCU 2010
Walter Bright:

>* Not all functional programming languages do concurrency well. Haskell and OCaml in particular have severe fundamental problems with it such that parallelizing your code makes it slower.<

What kind of problems have you seen in Haskell?
I have read several articles about parallel code written in Haskell, and its situation doesn't look so bad.


>Erlang and Clojure parallelize well, in that performance scales up proportionally as cores are added.<

There is no way for this to be true in general. "Scalability" is a lot a characteristic of the algorithm (and the way its subparts exchange data), not the language.
And if you care of performance Erlang is not the best:
http://proliferationofniches.blogspot.com/2008/07/multi-core-problem.html
Erlang is good for other things, like reliability.


>Message passing looks like the future.<

Message passing is one future. There is no single silver bullet to solve the concurrency/parallelism problems. Different algorithms will need different solutions: message passing (actors, agents), data parallelism (AVX registers, GPU cores, vector operations, parallel loops, etc), dataflow programming (http://en.wikipedia.org/wiki/Dataflow_programming ), etc. D will need several solutions in its core language, std lib, external libs.


>* Monads have nothing in particular to with I/O.<

Right. They are used for the I/O in Haskell, but they are a quite more general concept that can be used for other purposes too.


>* People really understand and get testing and how it improves programming.<

And D unit testing is not good enough yet :-)
I think dynamic languages have shown why testing is so useful (for statically compiled languages too).

Bye,
bearophile
April 23, 2010
Re: Things I Learned from ACCU 2010
Walter Bright Wrote:

> * Not all functional programming languages do concurrency well. Haskell and 
> OCaml in particular have severe fundamental problems with it such that 
> parallelizing your code makes it slower.

Do you have a reference on that? I'll produce one to the contrary:
http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/29#smoking-4core

> * Monads have nothing in particular to with I/O.

Right.

> All monads are are a way to 
> insert code to pre-process arguments going to a function, and insert code to 
> post-process the result coming out of that function.

That's a much too narrow view. While it may apply roughly to some uses of monads, even something as simple as the Maybe monad doesn't fit into this mental model anymore.

I'd really recommend spending a few days with Haskell. Even if it may not be the language you'll want to spend the rest of your life with, there's no denying that a lot of interesting ideas and research is going into Haskell. (As an aside, I'm generally a bit put off by the hostility towards programming language research and theory in the D community. "We don't need no stinking theory, we'll just roll our own ad-hoc solution which will work much better because ivory-tower academics are completely out of touch with reality anyway." Bleh.) If you try to put ideas of pure functional programming into D, I think it would be a good idea to at least be somewhat familiar with the way the reigning king of that particular niche does it.

-- Clemens
April 23, 2010
Re: Things I Learned from ACCU 2010
bearophile wrote:
> Walter Bright:
> 
>> * Not all functional programming languages do concurrency well. Haskell and
>> OCaml in particular have severe fundamental problems with it such that
>> parallelizing your code makes it slower.<
> 
> What kind of problems have you seen in Haskell? I have read several articles
> about parallel code written in Haskell, and its situation doesn't look so
> bad.

It wasn't me, it was Russell Wider. He wrote a parallel pi calculating program 
in several languages, and then tried it with 1, 2, 4, and 8 cores. The more 
cores, the longer the Haskell program took. Charting the core use showed that 
only one core would run at a time.

Same with OCaml.

OCaml has a global interpreter lock which explains its behavior. Russell didn't 
know why the Haskell behavior was so bad. He allowed that it was possible he was 
misusing it.


>> Erlang and Clojure parallelize well, in that performance scales up
>> proportionally as cores are added.<
> 
> There is no way for this to be true in general. "Scalability" is a lot a
> characteristic of the algorithm (and the way its subparts exchange data), not
> the language. And if you care of performance Erlang is not the best: 
> http://proliferationofniches.blogspot.com/2008/07/multi-core-problem.html 
> Erlang is good for other things, like reliability.

With Erlang and Clojure and the parallel pi programming, doubling the number of 
cores doubled the speed. Graphing the core use showed they were utilizing the 
cores simultaneously.

Erlang was slow in general, but it *did* scale well with the number of cores.
April 23, 2010
Re: Things I Learned from ACCU 2010
Clemens wrote:
> Walter Bright Wrote:
> 
>> * Not all functional programming languages do concurrency well. Haskell and
>>  OCaml in particular have severe fundamental problems with it such that 
>> parallelizing your code makes it slower.
> 
> Do you have a reference on that? I'll produce one to the contrary: 
> http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/29#smoking-4core

All I've got is Russel Winder's talk on it, Parallelism: The Functional 
Imperative, with the code and benchmarks. He ran them in real time.

http://www.russel.org.uk/
April 23, 2010
Re: Things I Learned from ACCU 2010
Walter Bright wrote:
> It wasn't me, it was Russell Wider.

That's Russel Winder.
April 23, 2010
Re: Things I Learned from ACCU 2010
Walter Bright:
> It wasn't me, it was Russell Wider. He wrote a parallel pi calculating program 
> in several languages, and then tried it with 1, 2, 4, and 8 cores. The more 
> cores, the longer the Haskell program took. Charting the core use showed that 
> only one core would run at a time.
> 
> Same with OCaml.
> 
> OCaml has a global interpreter lock which explains its behavior. Russell didn't 
> know why the Haskell behavior was so bad. He allowed that it was possible he was 
> misusing it.

You have just the illusion to have learned something about this. Trying to read too much from this single example is very wrong. A single benchmark, written by a person not expert in the language, means nearly nothing. You need at least a suite of good benchmarks, written by people that know the respective languages. And even then, you have just an idea of the situation.

Bye,
bearophile
April 23, 2010
Re: Things I Learned from ACCU 2010
Walter Bright Wrote:

> Clemens wrote:
> > Walter Bright Wrote:
> > 
> >> * Not all functional programming languages do concurrency well. Haskell and
> >>  OCaml in particular have severe fundamental problems with it such that 
> >> parallelizing your code makes it slower.
> > 
> > Do you have a reference on that? I'll produce one to the contrary: 
> > http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/29#smoking-4core
> 
> All I've got is Russel Winder's talk on it, Parallelism: The Functional 
> Imperative, with the code and benchmarks. He ran them in real time.
> 
> http://www.russel.org.uk/

Ah, ok. As bearophile noted, that person seems to have not much experience with Haskell, to put it politely. Obviously I didn't see the presentation and don't want to judge too harshly, but if your summary is an accurate representation of its take-away points, that reeks badly of intellectual dishonesty and FUD. See my link.

Or put another way, would you like someone who has never used D before to do a live presentation on it and come to premature conclusions like this?
April 23, 2010
Re: Things I Learned from ACCU 2010
bearophile wrote:
> Walter Bright:
>> OCaml has a global interpreter lock which explains its behavior. Russell
>> didn't know why the Haskell behavior was so bad. He allowed that it was
>> possible he was misusing it.
> 
> You have just the illusion to have learned something about this. Trying to
> read too much from this single example is very wrong. A single benchmark,
> written by a person not expert in the language, means nearly nothing. You
> need at least a suite of good benchmarks, written by people that know the
> respective languages. And even then, you have just an idea of the situation.


Fair enough, but in order to dismiss the results I'd need to know *why* the 
Haskell version failed so badly, and why such a straightforward attempt at 
parallelism is the wrong solution for Haskell.

You shouldn't have to be an expert in a language that is supposedly good at 
parallelism in order to get good results from it.

(Russel may or not be an expert, but he is certainly not a novice at FP or 
parallelism.)

Basically, I'd welcome an explanatory riposte to Russel's results.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home