headers
Jason Dusek | 1 Mar 2008 08:56
Picon
Gravatar

Re: static constants -- ideas?

Bryan O'Sullivan <bos <at> serpentine.com> wrote:
> The trick I usually use in cases like this is to compile the
> data as C code and link against it, then access it from
> Haskell via a Ptr.

  For my particular application, I really need to ship a single
  static binary that has it all -- data as well as algorithms --
  so I'm going with the FFI. It's too bad that I end up working
  in the IO monad much of the time. I hope we'll have massive
  static constants someday soon!

--

-- 
_jsn
Permalink | Reply | 2 comments |
headers
Jay Scott | 1 Mar 2008 21:24

Re: static constants -- ideas?

Jason Dusek jason.dusek <at> gmail.com:
>Bryan O'Sullivan <bos <at> serpentine.com> wrote:
>> The trick I usually use in cases like this is to compile the
>> data as C code and link against it, then access it from
>> Haskell via a Ptr.
>
>  For my particular application, I really need to ship a single
>  static binary that has it all -- data as well as algorithms --
>  so I'm going with the FFI. It's too bad that I end up working
>  in the IO monad much of the time. I hope we'll have massive
>  static constants someday soon!

unsafePerformIO should be safe on constants, right? It has worked for
me, at least.

  Jay
Permalink | Reply | 1 comment |
headers
Jason Dusek | 2 Mar 2008 01:39
Picon
Gravatar

Re: static constants -- ideas?

On Sat, Mar 1, 2008 at 12:24 PM, Jay Scott <jay <at> satirist.org> wrote:
> Jason Dusek jason.dusek <at> gmail.com:
> unsafePerformIO should be safe on constants, right? It has worked for
> me, at least.

  Unfortunately, reading in the list does not allow me to ship a
  single binary. It's not file reading, though, that forces me
  in to the IO Monad -- it's pointer dereferencing.

--

-- 
_jsn
Permalink | Reply | 0 comments |
headers
Jason Dusek | 2 Mar 2008 01:42
Picon
Gravatar

Re: static constants -- ideas?

Simon Peyton-Jones <simonpj <at> microsoft.com> wrote:
> It's not quite as stupid as it sounds...have another go when
> you see that #2002 is fixed.

  Thanks for pointing me to that -- in the meantime, I'd still
  rather write C and Haskell than plain C++!

--

-- 
_jsn
Permalink | Reply | 0 comments |
headers
Remi Turk | 3 Mar 2008 10:18
Picon
Picon
Favicon

GHC code generation micro-optimisation patch

Hi,

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.

The long story is that in

compiler/codeGen/CgUtils.hs:mk_switch, an extra case is added to
detect and treat specially the case analysis of 2 constructor
datatypes.[1]

Previously, case analysis of 2 constructor data types looked as
follows in C--:

	_tmp = R1 & 3;
	if (_tmp >= 2) goto snd_con_lbl;

With this patch, it generates the following:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Marlow | 3 Mar 2008 13:30
Picon

Re: GHC code generation micro-optimisation patch

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
Permalink | Reply | 0 comments |
headers
Don Stewart | 3 Mar 2008 23:21
Favicon
Gravatar

Re: static constants -- ideas?

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gregory Wright | 4 Mar 2008 15:13
Picon

ANN: ghc 6.8.2 from MacPorts


After what many would consider an unconscionable delay, I am happy to  
announce
that ghc 6.8.2 is available from MacPorts.

The ghc 6.8.2 port is available for Tiger/ppc, Tiger/intel and Leopard/ 
intel.  Users with
Leopard/ppc are out of luck until for now, for reason discussed  
earlier on this list.

In partial recompense for their patience, users will get a ghc with  
more patches
than any previous MacPorts ghc.

A few notes:

	The file locking bugs #1992 and #2134 are fixed.  Bug #1992 was a  
simple
	lock logic error and should be killed dead.  Bug #2134 was the result  
of a lazy readFile
	holding a lock for an unpredictable time.  There may be more cases  
like this one,
	and I would appreciate a note from anyone who come across a lock  
error during building.

	Users on Leopard/intel must upgrade to 10.5.2 to avoid an OS bug  
which under
	unusual circumstances would repeatably (and mysteriously) crash the  
build.
	This was first noticed running the building in an eshell under
(Continue reading)

Permalink | Reply | 20 comments |
headers
Justin Bailey | 5 Mar 2008 02:07
Picon
Gravatar

Assembly decoding help?

I'm trying to get a feel for the assembly output by GHC on my
platform. Below is a module containing one function and the associated
assembly. I've put in comments what I think is going on, but I'd
appreciate it if anyone could give me some pointers. I'd really like
to know three things:

  * Why does _Add_unsafeShiftR_info check if (%esi) is 3?
  * What's going on in _s86_info?
  * At the end of _s87_info, 8 is added to %ebp and then jumped to. Is
that a jump to the I# constructor and, if so, how did it's address get
to that offset from %ebp?

Thanks in advance for any assistance!

Justin

--- cut here ----

# Compiled with
#
#  ghc -c Add.hs -fext-core -keep-s-files -fasm -O2 -ddump-to-file
-ddump-stg -ddump-cmm
#
# Platform: Windows XP.
# Processor Pentium 4.
# GHC Version: 6.8.2.
#
# > {-# OPTIONS_GHC -fglasgow-exts -fbang-patterns  #-}
# > module Add (unsafeShiftR)
#
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stefan O'Rear | 5 Mar 2008 02:38
Picon

Re: Assembly decoding help?

On Tue, Mar 04, 2008 at 05:07:03PM -0800, Justin Bailey wrote:
> I'm trying to get a feel for the assembly output by GHC on my
> platform. Below is a module containing one function and the associated
> assembly. I've put in comments what I think is going on, but I'd
> appreciate it if anyone could give me some pointers. I'd really like
> to know three things:
> 
>   * Why does _Add_unsafeShiftR_info check if (%esi) is 3?
>   * What's going on in _s86_info?
>   * At the end of _s87_info, 8 is added to %ebp and then jumped to. Is
> that a jump to the I# constructor and, if so, how did it's address get
> to that offset from %ebp?
> 
> Thanks in advance for any assistance!

It would be more helpful if you didn't try to go from Haskell to
assembly in one step - it's a lot easier to understand each big step of
the GHC pipeline individually.

Haskell
|
\-> Core (ghc -ddump-simpl Foo.hs > Foo.core; or -fext-core if you want
         something ugly but parsable; an unrestricted but simple
	 expression-functional language)
    |
    \-> STG (ghc -ddump-stg ...) (Much more regular than Core; more like
            functional C)
	|
        \-> C-- (ghc -ddump-cmm) (just what it says: Simplified C for
	        compiler writers.  The universal assembly language for
(Continue reading)

Permalink | Reply | 0 comments |

Gmane