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

[Sebastian Sylvan]

On 12/19/06, ls-haskell-developer-2006 at m-e-leypold.de
<ls-haskell-developer-2006 at m-e-leypold.de> wrote:
>
> Tomasz Zielonka <tomasz.zielonka at gmail.com> 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