Re: [Haskell-cafe] Re: A suggestion for the next high profile Haskell project

On 12/19/06, ls-haskell-developer-2006@m-e-leypold.de wrote:

Tomasz Zielonka writes:

...

Anyway, don't concentrate on this particular example. All I say is that: - sometimes I get efficient programs in Haskell right away (I my case quite often, but YMMV) - sometimes efficiency doesn't matter I don't think it is contradictory, especially because the two "sometimes" can have a non-empty symmetric difference.

I'd like to add, that speed/efficiency is rather less important in "real world programming" than most people realize. Assume I write program for some clients with a total install base of N machines.

Assume I don't optimize.

If the program runs fast enough but could run faster, I'm wasting my time to optimize. I'd have to charge more money to the licensees / clients without actually delivering a better experience.

Assume now the unoptimized program doesn't run fast enough -- it's slow enough to seriously affect the user experience and the clients start grumbling.

Now, something has to be done: Either the customers have to upgrade their machines (I call that the MS experience ;-) or I have to optimize. The latter also incurs cost which finally has to be factored in the licensing / service fees for the program (if not I'd not be getting revenue from the program and had to close my shop :-).

Now let's ask: When is it better to optimize instead of urging the customer to upgrade?

Obviously when

Cost(Upgrade) > Cost(Optimisation)

for the customer. Those costs are

Cost(Upgrade) = Price of more memory or new PC which is fast enough.

Cost(Optimisation) = Hours_spent * Fee_per_Hour / N

(remember: N was the number of licensed Nodes).

So finally for optimisation to be the better decision, we must have:

Price_New_PC > Hours_spent * Fee_per_Hour / N

With hardware prices being as cheap as they are, hourly rates being not cheap (thanks to that :-), only optimizations pay that are either easy (done fast) or if you have a large number of customers / clients.

There are of course other real world scenarios. For example you may have competitors. I currently write C++ for my day job because in my industry (games) speed is a major "bullet point" on which you get judged. I do think that the trends are conspiring so that Haskell will outrun C/C++ "any day now". Probably not in "fair" comparisons, but easily in the "real world". E.g. when consoles have 40 cores your C++ engine may be faster in single threaded mode, but if the multithreaded version crashes too often to be useful or simply isn't good enough at utilizing the available hardware, the Haskell version (which doesn't crash, and uses all available cores) will win, even if it is multiple times slower in a "fair" benchmark. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862