April 23, 2010
Clemens wrote:
> I tried to have a look at it (not that I'm anything near a Haskell expert), but this link just gives me an empty directory:
> http://www.russel.org.uk/Bazaar/Pi_Quadrature

I'll see if Russel will email me the code.
April 23, 2010
On Fri, 23 Apr 2010 11:16:29 -0300, Clemens <eriatarka84@gmail.com> wrote:
[snip]
>
> I tried to have a look at it (not that I'm anything near a Haskell expert), but this link just gives me an empty directory:
> http://www.russel.org.uk/Bazaar/Pi_Quadrature

Try http://www.russel.org.uk:8080/Bazaar/Pi_Quadrature/changes
April 23, 2010
Clemens, el 23 de abril a las 09:06 me escribiste:
> > 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?

Like using one of the corner cases where the GC really sucks. =)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
For long you live and high you fly
But only if you ride the tide
And balanced on the biggest wave
You race towards an early grave.
April 23, 2010
Walter Bright, el 23 de abril a las 06:30 me escribiste:
> Clemens wrote:
> >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?
> 
> D is meant to give good results even for people who are not experts at it. If someone wrote a straightforward D app and it gave such poor results, I'd take it (and have taken such) as a problem that D needs to improve upon.

Is very easy to make naive programs that have serious performance problems because of the GC. You have to be almost an expert to tune that programs to make the run fast. Ask bearophile and dschima for examples =)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hey you, dont help them to bury the light
Don't give in without a fight.
April 23, 2010
Walter Bright:

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

Being easy to learn to use is not one of the qualities of Haskell. If you want to write efficient programs in Haskell you need lot of brain, you can see it also from the large amount of discussions here:
http://www.haskell.org/haskellwiki/Great_language_shootout
So I think you need experience and knowledge to do anything significant in Haskell, not just highly parallel programs.


>Basically, I'd welcome an explanatory riposte to Russel's results.<

If you want an explanation then I think you have to ask in (for example) an Haskell newsgroup, etc.


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

Being Haskell not easy, it's even possible for me to not understand the explanation if some Haskell expert eventually explains me why that Haskell program was slow :-)

Bye,
bearophile
April 23, 2010
bearophile wrote:
> Being Haskell not easy, it's even possible for me to not understand the
> explanation if some Haskell expert eventually explains me why that Haskell
> program was slow :-)

It's statements like this (and I've heard this repeatedly) that makes me wonder what the value of Haskell actually is to conventional programming tasks and regular programmers.
April 23, 2010
Leandro Lucarella wrote:
> Walter Bright, el 23 de abril a las 06:30 me escribiste:
>> Clemens wrote:
>>> 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?
>> D is meant to give good results even for people who are not experts
>> at it. If someone wrote a straightforward D app and it gave such
>> poor results, I'd take it (and have taken such) as a problem that D
>> needs to improve upon.
> 
> Is very easy to make naive programs that have serious performance problems
> because of the GC. You have to be almost an expert to tune that programs
> to make the run fast. Ask bearophile and dschima for examples =)


Relatively inexperienced D programmers should be able to apply straightforward solutions to common programming problems and expect correct behavior and reasonably acceptable performance.

I doubt we will always be able to achieve that, but we should always be working towards it.
April 23, 2010
Walter Bright wrote:
> Robert Jacques wrote:
>> On Fri, 23 Apr 2010 11:10:48 -0300, Walter Bright <newshound1@digitalmars.com> wrote:
>>
>>> Michael Rynn wrote:
>>>> OK where's the naive version of the D Pi program that scales up with 1,2,4 cores? How far off are we? Is the concurrency module working with it yet?
>>>
>>> Nobody's written a library function to parallelize a map/reduce yet.
>>
>> Dave Simcha has.
>> Code: http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/parallelFuture.d 
>>
>> Docs: http://cis.jhu.edu/~dsimcha/parallelFuture.html
> 
> Cool!

Unfortunately, it currently fails to compile with D2.
April 23, 2010
"Walter Bright" <newshound1@digitalmars.com> wrote in message news:hqsn2j$1s29$1@digitalmars.com...
> bearophile wrote:
>> Being Haskell not easy, it's even possible for me to not understand the
>> explanation if some Haskell expert eventually explains me why that
>> Haskell
>> program was slow :-)
>
> It's statements like this (and I've heard this repeatedly) that makes me wonder what the value of Haskell actually is to conventional programming tasks and regular programmers.

Not that I have an opinion either way, but FWIW, very similar things could probably be said for C++.

-------------------------------
Not sent from an iPhone.


April 23, 2010
Nick Sabalausky wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:hqsn2j$1s29$1@digitalmars.com...
>> bearophile wrote:
>>> Being Haskell not easy, it's even possible for me to not understand the
>>> explanation if some Haskell expert eventually explains me why that Haskell
>>> program was slow :-)
>> It's statements like this (and I've heard this repeatedly) that makes me wonder what the value of Haskell actually is to conventional programming tasks and regular programmers.
> 
> Not that I have an opinion either way, but FWIW, very similar things could probably be said for C++.

I know, and that creates an opportunity for other languages!