Re: GHC code generation micro-optimisation patch

[Simon Marlow]

Remi Turk wrote:


during the past semester I followed a seminar on the Efficient
implementation of functional languages by Jeroen Fokker at the
University Utrecht. During that course we worked on a feedback
directed GHC optimisation, but that got me interested in another
possible GHC backend micro-optimisation:

The short story is this:

An 8 line patch to GHC, tested with ghc 6.8.2 on nofib, ignoring all
results with a  0.5s runtime, yields an average runtime and
compile time improvement of about 0.6%.
The worst nofib slowdown is 5%, and the best speedup 8%
Whether this is acceptable/enough for inclusion, is of course not
up to me.


Hi Remi - thanks very much for the patch.  It certainly looks worthwhile. 
I have some pending changes myself to mk_switch - it turns out that we're 
doing quite a bad job of compiling 3-way comparisons too (look at the code 
for fib sometime), so I'll try to incorporate your change into my refactorings.


Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: static constants -- ideas?

[Don Stewart]

jason.dusek:
   I have an awkward programming problem -- I need to take a
   dictionary, parse it, build a bunch of intermediate lists and
   then make maps and tries out of the list. A programming
   problem because it's taken me a fair amount of effort to pull
   together the parser and list generator -- and awkward
   because a 69000 item list, [(String, [(String, String)])],
   does not compile under GHC (stack overflow). (It's not likely
   to compile under anything else, either!)

Here's an example of the approach Bryan outlined, which does seem to
work for files as large as gcc can handle:

* generate your big Haskell Map
* serialise it with Data.Binary, and Codec.Compression.GZip to a file
* compile the data into a C const array, and link that into Haskell
* decode it on startup, ressurecting the Haskell data.

The C source looks like:

const uint8_t beowulf[] = { 
31, 139,   8,   0,   0,   0,   0,   0,   0,   3, 124, 189,  75,
150,  46,  54,  93, 193,  96, 144, 241, 168, 172, 238, 214,   0,
...

http://code.haskell.org/~dons/code/compiled-constants/cbits/constants.c

which is the gzip, Data.Binary encoded version of a Map ByteString Int.
Then the Haskell code need only access this array as a Ptr Word8, wrap
that as a Bytestring, then run Data.Binary over the result to rebuild
the Map. As you can see here:

http://code.haskell.org/~dons/code/compiled-constants/Constants.hs

I've put a couple of examples of how to access C-side serialised Haskell
values in a package here:

http://code.haskell.org/~dons/code/compiled-constants/

Cheers,
  Don
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users