ghc image size

[Mike Gunter]

You may not like this argument but its kind are essential to the
strategic part of engineering.

Since you bring it up, let's consider whether it's worthwhile to
optimize code for time.  I'm less familiar with the costs of labour
but around here (Silicon Valley) labor costs are well in excess of a
cent per second.  When last I checked, good generalist engineering
consultants were charging more than $150/hour (specialists cost more.)
(And remember that, like for disk space, their costs are higher than
their price.)  The rates may have come down somewhat lately but I'm
quite sure costs are still well in excess of one cent per second.

Moreover, lots of programs take many, many seconds to run and get run
many times.  So, optimization for time can save you a lot of expensive
people time over the long haul.  It's worth putting some effort there.

One can make a case for reducing executable size in certain contexts.
For instance, it's not unreasonable to work to make code loaded by web
browsers smaller -- those executables have to be repeatedly moved over
slow links while people are waiting.  In my environment, though, I
don't see much benefit in smaller GHC executables.  Are there contexts
where it matters more?

GHC's resources (the implementation team, the constructive criticism
of users, etc.) are limited.  I'd hate to see them spent on
unimportant things.

        mike
 




> Mike Gunter <m@ryangunter.com> writes:
> 
> > Why is executable size a barrier?  1.64 megabytes (that's the size of
> > the executable I built with GHC most recently) of disk space costs less
> > than half a cent.
> 
> I don't like this argument.  Can I go to a computer store, pay a cent,
> and get a hard disk with space 1.64 megabytes or more?  Until then, I
> can't believe that 1.64 megabytes of disk space costs less than half a
> cent.
> 
> When a compiler does not perform as good as other compilers (e.g., in
> terms of generated code size), it is important to ask: Why does it
> happen? Is there anything we can do to improve it?  Being critical is
> the first step towards progress.  (Of course these questions should be
> asked in a constructive rather than whining way.)  Why would anyone
> optimize code for time --- a second of electricity and labour cost
> less than a cent...
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users