[Haskell-cafe] Can Haskell outperform C++?

[Gregg Lebovitz]

Ben,

This is precisely the kind of problem I am currently thinking about and 
why I asked for pointers to documents on best practices. The current 
model for gaining the necessary experience to use Haskell effectively 
does not scale well.

Here are some ideas on how to address the knowledge issue:

1) Outstanding best practices documents that capture this knowledge and 
provides useful answers. Organizing this information in an online 
document that can be searched by keyword or index would be really 
helpful. The hard part will be maintaining it. As someone already 
pointed out the wiki entry on performance is already dated.

2) Training presentations derived from #1 that provides lots of examples.

3) Online Training Videos based on #2 above

4) Profiling tools that uses the captured knowledge above, highlights 
problem areas, and provides guidance on correcting them.

As I mentioned in a previous email. I am willing to take on organization 
#1, but I will need help from people on this list. I can start with the 
performance wiki, but we will still need examples of where people get 
into trouble and the ways around them.

Gregg


On 5/16/2012 4:00 PM, Ben Gamari wrote:
> Kevin Charter<kcharter at gmail.com>  writes:
>
> snip
>> For example, imagine you're new to the language, and as an exercise decide
>> to write a program that counts the characters on standard input and writes
>> the count to standard output. A naive program in, say, Python will probably
>> use constant space and be fairly fast. A naive program in Haskell stands a
>> good chance of having a space leak, building a long chain of thunks that
>> isn't forced until it needs to write the final answer.  On small inputs,
>> you won't notice. The nasty surprise comes when your co-worker says "cool,
>> let's run it on this 100 MB log file!" and your program dies a horrible
>> death. If your friend is a sceptic, she'll arch an eyebrow and secretly
>> think your program -- and Haskell -- are a bit lame.
>>
> I, for one, can say that my initial impressions of Haskell were quite
> scarred by exactly this issue. Being in experimental physics, I often
> find myself writing data analysis code doing relatively simple
> manipulations on large(ish) data sets. My first attempt at tackling a
> problem in Haskell took nearly three days to get running with reasonable
> performance. I can only thank the wonderful folks in #haskell profusely
> for all of their help getting through that period. That being said, it
> was quite frustrating at the time and I often wondered how I could
> tackle a reasonably large project if I couldn't solve even a simple
> problem with halfway decent performance. If it weren't for #haskell, I
> probably would have given up on Haskell right then and there, much to my
> deficit.
>
> While things have gotten easier, even now, nearly a year after writing
> my first line of Haskell, I still occassionally find a performance
> issue^H^H^H^H surprise. I'm honestly not really sure what technical
> measures could be taken to ease this learning curve. The amazing
> community helps quite a bit but I feel that this may not be a
> sustainable approach if Haskell gains greater acceptance. The profiler
> is certainly useful (and much better with GHC 7.4), but there are still
> cases where the performance hit incurred by the profiling
> instrumentation precludes this route of investigation without time
> consuming guessing at how to pare down my test case. It's certainly not
> an easy problem.
>
> Cheers,
>
> - Ben
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe