From harendra.kumar at gmail.com  Tue Dec  1 10:48:14 2015
From: harendra.kumar at gmail.com (Harendra Kumar)
Date: Tue, 1 Dec 2015 16:18:14 +0530
Subject: ghci - running functions defined in a where clause
Message-ID: <CAPW+kkbjhwEXwR1-0DO+73WB4fy8jfVZsjm0TE=9isaEavMtZA@mail.gmail.com>

In ghci, is there a way to address and run functions defined in the where
clause of a function? I do not see those functions available in the scope.
Is this supported?

I can imagine two classes of functions in a where clause. Functions which
refer to the bindings in the surrounding scope and those which do not refer
to any outside bindings. I guess the latter should be easier to support if
we can refer to it or bring it in the current scope somehow.

Thanks,
harendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151201/362c716d/attachment.html>

From thomasmiedema at gmail.com  Wed Dec  2 14:38:21 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Wed, 2 Dec 2015 15:38:21 +0100
Subject: build ghc without ghci libraries?
In-Reply-To: <1448890954159-5823292.post@n5.nabble.com>
References: <1448890954159-5823292.post@n5.nabble.com>
Message-ID: <CAD3WKgh2Thaqgku+pqNMqde3_ae6BQHd7Qg-pD+0NMQGH_a-Qg@mail.gmail.com>

On Mon, Nov 30, 2015 at 2:42 PM, Jeremy <voldermort at hotmail.com> wrote:

> I'm currently removing *.o after building ghc to save space (I don't need
> them for what I'm doing). Is there a straightforward way to tell GHC not to
> build them in the first place, such as --disable-library-for-ghci does for
> cabal
>

Not really. But you can try adding `--disable-library-for-ghci` to the line
in rules/build-package-data.mk that starts with `"$$(ghc-cabal_INPLACE)"
configure ...`.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151202/03eacbee/attachment.html>

From alpmestan at gmail.com  Wed Dec  2 18:58:55 2015
From: alpmestan at gmail.com (Alp Mestanogullari)
Date: Wed, 2 Dec 2015 19:58:55 +0100
Subject: Segfault when doing hs_init()/hs_exit() multiple times
Message-ID: <CADZnDvDXSK9+vmtsoYi513UiVtAJXLcSGhs06yXvL9qqtrwi1Q@mail.gmail.com>

Hello everyone,

I'm currently calling Haskell code from C. My goal is to apply a Haskell
function to each element of some dataset that I get from outside
Haskell-land. For now, before I make this fancier and more efficient, the
plan is to just bring the RTS up with hs_init, call my Haskell function
(exporter to C with 'foreign export ccall [...]') on the element and
finally shut the RTS down, doing this for every element.

When running this, I realized the RTS was running into a segfault when
calling the Haskell function on the second element. This led me to believe
it wasn't possible to call hs_init()/hs_exit() multiple times in the same
program. But then I checked the Haskell 2010 report, FFI section [1], and
it says:

*The function hs_init() initialises the Haskell system and provides it with
the available command line arguments. Upon return, the arguments solely
intended for the Haskell runtime system are removed (i.e., the values that
argc and argv point to may have changed). This function must be called
during program startup before any Haskell function is invoked; otherwise,
the system behaviour is undefined. Conversely, the Haskell system is
deinitialised by a call to hs_exit(). Multiple invocations of hs_init() are
permitted, provided that they are followed by an equal number of calls to
hs_exit() and that the first call to hs_exit() is after the last call to
hs_init(). In addition to nested calls to hs_init(), the Haskell system may
be de-initialised with hs_exit() and be re-initialised with hs_init() at a
later point in time. This ensures that repeated initialisation due to
multiple libraries being implemented in Haskell is covered. *

Which means, if I understand correctly, that what I want, while very
inefficient, should work fine.

I've put together a minimal example that exhibits the problem, which can be
found at https://github.com/alpmestan/simple-c-export :

- https://github.com/alpmestan/simple-c-export/blob/master/run-haskell.c
shows the C code that brings the RTS up and down, with some printf
statements to show what's going on.

- https://github.com/alpmestan/simple-c-export/blob/master/Foo.hs shows the
trivial Haskell function I'm exposing.

-
https://github.com/alpmestan/simple-c-export/blob/master/simple-c-export.cabal
contains the build options I'm compiling the code with

When running this on my machine (OS X, ghc 7.8.3 and 7.10.2), I always get:

$ cabal run simple-c
Preprocessing executable 'simple-c' for simple-c-export-0.1...
Linking dist/build/simple-c/simple-c ...
Running simple-c...
#0 - Launching RTS...
#0 - RTS started! Calling Haskell function...
0
#0 - Killing RTS now...
#0 - RTS killed!
#1 - Launching RTS...
#1 - RTS started! Calling Haskell function...
Segmentation fault: 11

Is there something special I should do to make this work, that I'm
overlooking? Or is this a bug (that I should report on Trac, I guess) ?

Thanks in advance for any clarification on this.

-- 
Alp Mestanogullari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151202/113e4671/attachment.html>

From karl.cronburg at gmail.com  Wed Dec  2 19:41:11 2015
From: karl.cronburg at gmail.com (Karl Cronburg)
Date: Wed, 2 Dec 2015 14:41:11 -0500
Subject: Segfault when doing hs_init()/hs_exit() multiple times
In-Reply-To: <CADZnDvDXSK9+vmtsoYi513UiVtAJXLcSGhs06yXvL9qqtrwi1Q@mail.gmail.com>
References: <CADZnDvDXSK9+vmtsoYi513UiVtAJXLcSGhs06yXvL9qqtrwi1Q@mail.gmail.com>
Message-ID: <CADFviKAQKZ7jT4fE9-bzFq3fmZcbOHVRSMKv=dm-uSwc-TV8VA@mail.gmail.com>

I was having the same problem a while back. If you turn on debugging
symbols and give it to gdb, you
get that the seg fault is happening when the RTS attempts to allocate after
the second initialization:

    Program received signal SIGSEGV, Segmentation fault.
    0xf7f6f4f9 in allocate (cap=cap at entry=0xf7f92b40 <MainCapability>,
n=n at entry=2) at rts/sm/Storage.c:812
    812 rts/sm/Storage.c: No such file or directory.
    (gdb) bt
    #0  0xf7f6f4f9 in allocate (cap=cap at entry=0xf7f92b40 <MainCapability>,
n=n at entry=2) at rts/sm/Storage.c:812
    #1  0xf7f5c603 in rts_mkInt32 (cap=0xf7f92b40 <MainCapability>,
i=-11921) at rts/RtsAPI.c:69
    #2  0xf7cdea7a in pointer_test () from ../../ia32/build/
libHSpads-haskell-1.1-6fKCdLtCMO82em71etbiu1-ghc7.10.2.so
    #3  0x5655579c in main (argc=1, argv=0xffffd244) at Pointer.c:11

So my solution was to just leave the RTS initialized. What's the downside
of leaving it initialized throughout
the entire execution of your program? If the RTS / GC is smart enough it
should know not to waste time
doing a GC when no Haskell code has been run?

I too would be interested though in being able to clean up the RTS from C
when I know no Haskell code will
be run again anytime soon.

-Karl Cronburg-

On Wed, Dec 2, 2015 at 1:58 PM, Alp Mestanogullari <alpmestan at gmail.com>
wrote:

> Hello everyone,
>
> I'm currently calling Haskell code from C. My goal is to apply a Haskell
> function to each element of some dataset that I get from outside
> Haskell-land. For now, before I make this fancier and more efficient, the
> plan is to just bring the RTS up with hs_init, call my Haskell function
> (exporter to C with 'foreign export ccall [...]') on the element and
> finally shut the RTS down, doing this for every element.
>
> When running this, I realized the RTS was running into a segfault when
> calling the Haskell function on the second element. This led me to believe
> it wasn't possible to call hs_init()/hs_exit() multiple times in the same
> program. But then I checked the Haskell 2010 report, FFI section [1], and
> it says:
>
> *The function hs_init() initialises the Haskell system and provides it
> with the available command line arguments. Upon return, the arguments
> solely intended for the Haskell runtime system are removed (i.e., the
> values that argc and argv point to may have changed). This function must be
> called during program startup before any Haskell function is invoked;
> otherwise, the system behaviour is undefined. Conversely, the Haskell
> system is deinitialised by a call to hs_exit(). Multiple invocations of
> hs_init() are permitted, provided that they are followed by an equal number
> of calls to hs_exit() and that the first call to hs_exit() is after the
> last call to hs_init(). In addition to nested calls to hs_init(), the
> Haskell system may be de-initialised with hs_exit() and be re-initialised
> with hs_init() at a later point in time. This ensures that repeated
> initialisation due to multiple libraries being implemented in Haskell is
> covered. *
>
> Which means, if I understand correctly, that what I want, while very
> inefficient, should work fine.
>
> I've put together a minimal example that exhibits the problem, which can
> be found at https://github.com/alpmestan/simple-c-export :
>
> - https://github.com/alpmestan/simple-c-export/blob/master/run-haskell.c
> shows the C code that brings the RTS up and down, with some printf
> statements to show what's going on.
>
> - https://github.com/alpmestan/simple-c-export/blob/master/Foo.hs shows
> the trivial Haskell function I'm exposing.
>
> -
> https://github.com/alpmestan/simple-c-export/blob/master/simple-c-export.cabal
> contains the build options I'm compiling the code with
>
> When running this on my machine (OS X, ghc 7.8.3 and 7.10.2), I always get:
>
> $ cabal run simple-c
> Preprocessing executable 'simple-c' for simple-c-export-0.1...
> Linking dist/build/simple-c/simple-c ...
> Running simple-c...
> #0 - Launching RTS...
> #0 - RTS started! Calling Haskell function...
> 0
> #0 - Killing RTS now...
> #0 - RTS killed!
> #1 - Launching RTS...
> #1 - RTS started! Calling Haskell function...
> Segmentation fault: 11
>
> Is there something special I should do to make this work, that I'm
> overlooking? Or is this a bug (that I should report on Trac, I guess) ?
>
> Thanks in advance for any clarification on this.
>
> --
> Alp Mestanogullari
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151202/ca559f62/attachment.html>

From karl.cronburg at gmail.com  Wed Dec  2 19:58:56 2015
From: karl.cronburg at gmail.com (Karl Cronburg)
Date: Wed, 2 Dec 2015 14:58:56 -0500
Subject: Segfault when doing hs_init()/hs_exit() multiple times
In-Reply-To: <CADFviKAQKZ7jT4fE9-bzFq3fmZcbOHVRSMKv=dm-uSwc-TV8VA@mail.gmail.com>
References: <CADZnDvDXSK9+vmtsoYi513UiVtAJXLcSGhs06yXvL9qqtrwi1Q@mail.gmail.com>
 <CADFviKAQKZ7jT4fE9-bzFq3fmZcbOHVRSMKv=dm-uSwc-TV8VA@mail.gmail.com>
Message-ID: <CADFviKAr7Ep5=xiLYiJC+XKA2a132n4zyAGiG-bpsGSzAc2=Cg@mail.gmail.com>

Upon further investigation:

    *"The FFI spec requires the implementation to support re-initialising
itself after being shut down with hs_exit(), but GHC does not currently
support that."*

https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/bugs-and-infelicities.html#infelicities-ffi

So it's a known issue / shortcoming.

-Karl Cronburg-

On Wed, Dec 2, 2015 at 2:41 PM, Karl Cronburg <karl.cronburg at gmail.com>
wrote:

> I was having the same problem a while back. If you turn on debugging
> symbols and give it to gdb, you
> get that the seg fault is happening when the RTS attempts to allocate
> after the second initialization:
>
>     Program received signal SIGSEGV, Segmentation fault.
>     0xf7f6f4f9 in allocate (cap=cap at entry=0xf7f92b40 <MainCapability>,
> n=n at entry=2) at rts/sm/Storage.c:812
>     812 rts/sm/Storage.c: No such file or directory.
>     (gdb) bt
>     #0  0xf7f6f4f9 in allocate (cap=cap at entry=0xf7f92b40
> <MainCapability>, n=n at entry=2) at rts/sm/Storage.c:812
>     #1  0xf7f5c603 in rts_mkInt32 (cap=0xf7f92b40 <MainCapability>,
> i=-11921) at rts/RtsAPI.c:69
>     #2  0xf7cdea7a in pointer_test () from ../../ia32/build/
> libHSpads-haskell-1.1-6fKCdLtCMO82em71etbiu1-ghc7.10.2.so
>     #3  0x5655579c in main (argc=1, argv=0xffffd244) at Pointer.c:11
>
> So my solution was to just leave the RTS initialized. What's the downside
> of leaving it initialized throughout
> the entire execution of your program? If the RTS / GC is smart enough it
> should know not to waste time
> doing a GC when no Haskell code has been run?
>
> I too would be interested though in being able to clean up the RTS from C
> when I know no Haskell code will
> be run again anytime soon.
>
> -Karl Cronburg-
>
> On Wed, Dec 2, 2015 at 1:58 PM, Alp Mestanogullari <alpmestan at gmail.com>
> wrote:
>
>> Hello everyone,
>>
>> I'm currently calling Haskell code from C. My goal is to apply a Haskell
>> function to each element of some dataset that I get from outside
>> Haskell-land. For now, before I make this fancier and more efficient, the
>> plan is to just bring the RTS up with hs_init, call my Haskell function
>> (exporter to C with 'foreign export ccall [...]') on the element and
>> finally shut the RTS down, doing this for every element.
>>
>> When running this, I realized the RTS was running into a segfault when
>> calling the Haskell function on the second element. This led me to believe
>> it wasn't possible to call hs_init()/hs_exit() multiple times in the same
>> program. But then I checked the Haskell 2010 report, FFI section [1], and
>> it says:
>>
>> *The function hs_init() initialises the Haskell system and provides it
>> with the available command line arguments. Upon return, the arguments
>> solely intended for the Haskell runtime system are removed (i.e., the
>> values that argc and argv point to may have changed). This function must be
>> called during program startup before any Haskell function is invoked;
>> otherwise, the system behaviour is undefined. Conversely, the Haskell
>> system is deinitialised by a call to hs_exit(). Multiple invocations of
>> hs_init() are permitted, provided that they are followed by an equal number
>> of calls to hs_exit() and that the first call to hs_exit() is after the
>> last call to hs_init(). In addition to nested calls to hs_init(), the
>> Haskell system may be de-initialised with hs_exit() and be re-initialised
>> with hs_init() at a later point in time. This ensures that repeated
>> initialisation due to multiple libraries being implemented in Haskell is
>> covered. *
>>
>> Which means, if I understand correctly, that what I want, while very
>> inefficient, should work fine.
>>
>> I've put together a minimal example that exhibits the problem, which can
>> be found at https://github.com/alpmestan/simple-c-export :
>>
>> - https://github.com/alpmestan/simple-c-export/blob/master/run-haskell.c
>> shows the C code that brings the RTS up and down, with some printf
>> statements to show what's going on.
>>
>> - https://github.com/alpmestan/simple-c-export/blob/master/Foo.hs shows
>> the trivial Haskell function I'm exposing.
>>
>> -
>> https://github.com/alpmestan/simple-c-export/blob/master/simple-c-export.cabal
>> contains the build options I'm compiling the code with
>>
>> When running this on my machine (OS X, ghc 7.8.3 and 7.10.2), I always
>> get:
>>
>> $ cabal run simple-c
>> Preprocessing executable 'simple-c' for simple-c-export-0.1...
>> Linking dist/build/simple-c/simple-c ...
>> Running simple-c...
>> #0 - Launching RTS...
>> #0 - RTS started! Calling Haskell function...
>> 0
>> #0 - Killing RTS now...
>> #0 - RTS killed!
>> #1 - Launching RTS...
>> #1 - RTS started! Calling Haskell function...
>> Segmentation fault: 11
>>
>> Is there something special I should do to make this work, that I'm
>> overlooking? Or is this a bug (that I should report on Trac, I guess) ?
>>
>> Thanks in advance for any clarification on this.
>>
>> --
>> Alp Mestanogullari
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151202/7c9334be/attachment-0001.html>

From alpmestan at gmail.com  Wed Dec  2 20:10:23 2015
From: alpmestan at gmail.com (Alp Mestanogullari)
Date: Wed, 2 Dec 2015 21:10:23 +0100
Subject: Segfault when doing hs_init()/hs_exit() multiple times
In-Reply-To: <CADFviKAr7Ep5=xiLYiJC+XKA2a132n4zyAGiG-bpsGSzAc2=Cg@mail.gmail.com>
References: <CADZnDvDXSK9+vmtsoYi513UiVtAJXLcSGhs06yXvL9qqtrwi1Q@mail.gmail.com>
 <CADFviKAQKZ7jT4fE9-bzFq3fmZcbOHVRSMKv=dm-uSwc-TV8VA@mail.gmail.com>
 <CADFviKAr7Ep5=xiLYiJC+XKA2a132n4zyAGiG-bpsGSzAc2=Cg@mail.gmail.com>
Message-ID: <CADZnDvBkcWcQV+14tA3Bve1kcToWK_9xr9iaZ+aWnYdirC9vAw@mail.gmail.com>

Oh, this page didn't pop up during my googling, earlier. Thanks! I guess
I'll just arrange for the RTS to be initialized and shutdown only once. I'd
love to know why GHC decided to diverge from the Report on this, if anyone
knows.

On Wed, Dec 2, 2015 at 8:58 PM, Karl Cronburg <karl.cronburg at gmail.com>
wrote:

> Upon further investigation:
>
>     *"The FFI spec requires the implementation to support re-initialising
> itself after being shut down with hs_exit(), but GHC does not currently
> support that."*
>
> https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/bugs-and-infelicities.html#infelicities-ffi
>
> So it's a known issue / shortcoming.
>
> -Karl Cronburg-
>
> On Wed, Dec 2, 2015 at 2:41 PM, Karl Cronburg <karl.cronburg at gmail.com>
> wrote:
>
>> I was having the same problem a while back. If you turn on debugging
>> symbols and give it to gdb, you
>> get that the seg fault is happening when the RTS attempts to allocate
>> after the second initialization:
>>
>>     Program received signal SIGSEGV, Segmentation fault.
>>     0xf7f6f4f9 in allocate (cap=cap at entry=0xf7f92b40 <MainCapability>,
>> n=n at entry=2) at rts/sm/Storage.c:812
>>     812 rts/sm/Storage.c: No such file or directory.
>>     (gdb) bt
>>     #0  0xf7f6f4f9 in allocate (cap=cap at entry=0xf7f92b40
>> <MainCapability>, n=n at entry=2) at rts/sm/Storage.c:812
>>     #1  0xf7f5c603 in rts_mkInt32 (cap=0xf7f92b40 <MainCapability>,
>> i=-11921) at rts/RtsAPI.c:69
>>     #2  0xf7cdea7a in pointer_test () from ../../ia32/build/
>> libHSpads-haskell-1.1-6fKCdLtCMO82em71etbiu1-ghc7.10.2.so
>>     #3  0x5655579c in main (argc=1, argv=0xffffd244) at Pointer.c:11
>>
>> So my solution was to just leave the RTS initialized. What's the downside
>> of leaving it initialized throughout
>> the entire execution of your program? If the RTS / GC is smart enough it
>> should know not to waste time
>> doing a GC when no Haskell code has been run?
>>
>> I too would be interested though in being able to clean up the RTS from C
>> when I know no Haskell code will
>> be run again anytime soon.
>>
>> -Karl Cronburg-
>>
>> On Wed, Dec 2, 2015 at 1:58 PM, Alp Mestanogullari <alpmestan at gmail.com>
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I'm currently calling Haskell code from C. My goal is to apply a Haskell
>>> function to each element of some dataset that I get from outside
>>> Haskell-land. For now, before I make this fancier and more efficient, the
>>> plan is to just bring the RTS up with hs_init, call my Haskell function
>>> (exporter to C with 'foreign export ccall [...]') on the element and
>>> finally shut the RTS down, doing this for every element.
>>>
>>> When running this, I realized the RTS was running into a segfault when
>>> calling the Haskell function on the second element. This led me to believe
>>> it wasn't possible to call hs_init()/hs_exit() multiple times in the same
>>> program. But then I checked the Haskell 2010 report, FFI section [1], and
>>> it says:
>>>
>>> *The function hs_init() initialises the Haskell system and provides it
>>> with the available command line arguments. Upon return, the arguments
>>> solely intended for the Haskell runtime system are removed (i.e., the
>>> values that argc and argv point to may have changed). This function must be
>>> called during program startup before any Haskell function is invoked;
>>> otherwise, the system behaviour is undefined. Conversely, the Haskell
>>> system is deinitialised by a call to hs_exit(). Multiple invocations of
>>> hs_init() are permitted, provided that they are followed by an equal number
>>> of calls to hs_exit() and that the first call to hs_exit() is after the
>>> last call to hs_init(). In addition to nested calls to hs_init(), the
>>> Haskell system may be de-initialised with hs_exit() and be re-initialised
>>> with hs_init() at a later point in time. This ensures that repeated
>>> initialisation due to multiple libraries being implemented in Haskell is
>>> covered. *
>>>
>>> Which means, if I understand correctly, that what I want, while very
>>> inefficient, should work fine.
>>>
>>> I've put together a minimal example that exhibits the problem, which can
>>> be found at https://github.com/alpmestan/simple-c-export :
>>>
>>> - https://github.com/alpmestan/simple-c-export/blob/master/run-haskell.c
>>> shows the C code that brings the RTS up and down, with some printf
>>> statements to show what's going on.
>>>
>>> - https://github.com/alpmestan/simple-c-export/blob/master/Foo.hs shows
>>> the trivial Haskell function I'm exposing.
>>>
>>> -
>>> https://github.com/alpmestan/simple-c-export/blob/master/simple-c-export.cabal
>>> contains the build options I'm compiling the code with
>>>
>>> When running this on my machine (OS X, ghc 7.8.3 and 7.10.2), I always
>>> get:
>>>
>>> $ cabal run simple-c
>>> Preprocessing executable 'simple-c' for simple-c-export-0.1...
>>> Linking dist/build/simple-c/simple-c ...
>>> Running simple-c...
>>> #0 - Launching RTS...
>>> #0 - RTS started! Calling Haskell function...
>>> 0
>>> #0 - Killing RTS now...
>>> #0 - RTS killed!
>>> #1 - Launching RTS...
>>> #1 - RTS started! Calling Haskell function...
>>> Segmentation fault: 11
>>>
>>> Is there something special I should do to make this work, that I'm
>>> overlooking? Or is this a bug (that I should report on Trac, I guess) ?
>>>
>>> Thanks in advance for any clarification on this.
>>>
>>> --
>>> Alp Mestanogullari
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>>
>>>
>>
>


-- 
Alp Mestanogullari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151202/8eb19a64/attachment.html>

From mateusz.p.kloczko at gmail.com  Thu Dec  3 01:10:06 2015
From: mateusz.p.kloczko at gmail.com (=?UTF-8?Q?Mateusz_K=C5=82oczko?=)
Date: Thu, 3 Dec 2015 02:10:06 +0100
Subject: Optimization of IORefs and STRefs - comparison to g++
Message-ID: <CAO1yQHzoZkWiprMfb7L+CzkwVpLChdZ9f3pSkcPD=qt-8_Q_Vg@mail.gmail.com>

Hello!

I've performed a few simple tests using Haskell and C++ on primitives.
I've compilled all Haskell programs with -O2 optimizations, and C++ ones
with -O3
ghc version - 7.10.2, gcc version : 5.1.1

I'm sending the codes in the zip file.

*Problem1* -  100 000 000  iterations.

Time of execution (in seconds):
*Int  pure tail recursion*: 6.911011299962411e-2
*Int# pure tail recursion *: 4.587398100011342e-2
*IORef for loop* 1.1533970820000832
*IORef 'tail' recursion* 1.0696569040001123
*STRef for loop* 1.1545546840006864
*STRef tail recursion* 1.1110019479992843
*C++ *: 2.7e-07

The llvm version could be as fast as C++ one in this problem.

Buuut... then there's *problem 2* (using if or case) - 100 000 000
iterations:
*Int# tail recursion* 1.315346227000191
*IORef for loop*: 2.6442542390004746
*STRef for loop*: 2.669217500999366
*C++*: 0.158056


Here haskell is about 9 times slower than C++.

*Problem 4* - executing the same functionality using bit operations - 100
000 000 iterations:
*Int# tail recursion:* 0.12361123500068061
*C++:* 0.131141

So, Haskell here is as fast as C++.

My question is: can IORefs and STRefs be optimized ? I would like very much
to rely on them, but I would like to achieve great speeds.
Also, is can one achieve good speeds of execution when using cases or ifs ?
If not, what is the other way to do it ? Compiler flags, Cmm optimizations
- they are all welcome.

And the final question - how hard would it be to implement such
optimizations in ghc compiler?

Regards,
Mateusz K?oczko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151203/bf1e72a1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EfficientMutability.zip
Type: application/zip
Size: 4751 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151203/bf1e72a1/attachment.zip>

From ollie at ocharles.org.uk  Mon Dec  7 10:49:48 2015
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Mon, 07 Dec 2015 10:49:48 +0000
Subject: [Haskell-cafe] [Haskell-beginners] DOOM rewritten in the Haskell
 programming language.
In-Reply-To: <op.x88fqdiwpz0j5l@alquantor>
References: <451608938.16111539.1449415275423.JavaMail.yahoo.ref@mail.yahoo.com>
 <451608938.16111539.1449415275423.JavaMail.yahoo@mail.yahoo.com>
 <op.x88fqdiwpz0j5l@alquantor>
Message-ID: <CAGRp5RkNHKip=kswWNFw+5twe9JMeH0pPqu3YfG1BAePnKBbRg@mail.gmail.com>

On Sun, Dec 6, 2015 at 5:19 PM Henk-Jan van Tuyl <hjgtuyl at chello.nl> wrote:

> On Sun, 06 Dec 2015 16:21:15 +0100, David Blubaugh
> <davidblubaugh2000 at yahoo.com> wrote:
>
> > TO ALL,
> > Hello My name is David Allen Blubaugh.  I am currently considering
> > starting a kick-starter project in redeveloping the DOOM source code
> > with the Haskell Programming language using the power of
> > functional-oriented programming......
> > I know that John Carmack was interested in the Haskell programming
> > language and had even recreated wolfenstein 3D using the Haskell
> > programming language. Does anybody have a copy of John Carmack's
> > recreation of wolfenstein 3D using haskell ??? Also would anybody enjoy
> > working with this project ???  What benefits would DOOM have enjoyed had
> > ID software created the DOOM source code in 1993 with Haskell or some
> > other functional-oriented programming language  instead of C/assembly
> > programming languages ???  Thanks,
> > David Allen BlubaughElectrical EngineerATR Associate
>
> I don't know about his source code, but the Games page[0] lists:
>   - hadoom
>       A clone of Doom, using reactive-banana, GTK, and the "diagrams"
> library.
>       https://github.com/ocharles/hadoom


Possibly worth noting that hadoom is not a source-port of Doom - it's
inspired by Doom's approach to level editing (2.5D), but beyond that there
isn't much cross over. For example, I use full triangulation for rendering
via OpenGL, rather than building my own rendering engine. The level format
is also different from WAD.
<http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>

Ollie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151207/0840856c/attachment.html>

From alexander at plaimi.net  Mon Dec  7 10:54:45 2015
From: alexander at plaimi.net (Alexander Berntsen)
Date: Mon, 7 Dec 2015 11:54:45 +0100
Subject: [Haskell-beginners] DOOM rewritten in the Haskell programming
 language.
In-Reply-To: <451608938.16111539.1449415275423.JavaMail.yahoo@mail.yahoo.com>
References: <451608938.16111539.1449415275423.JavaMail.yahoo.ref@mail.yahoo.com>
 <451608938.16111539.1449415275423.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <56656575.8090109@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

David,

I think it would be more valuable to make a DOOM-like game than to
remake DOOM. Especially if you are going to aim for funding. The free
software community has had this problem for years, where we point to
remakes of old games as evidence to viability. It isn't. Nobody will
be swayed by Haskell DOOM. (Although I would, personally, think it
interesting.)

Good luck with your project.
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWZWV0AAoJENQqWdRUGk8B0bMQAKu/4hBeS7Iz23IMIatrc5Jd
hkWm/bG8FRCtiLyETiH9NtUL5RPtmS+s3+o05h6fZZ1VFFfzucygsmOTw27kWApc
ZpZiypv22y7uJsrbyxFgXVp2w6vfp6rrdA+vRSOUp/dmJ+vnn7jVeGUInnlAKX50
WAsEUPx0q4IhGnF/2O3kBuKw/baGvp2kne2IjrgdAJ5qptVEvVoAEpIG3WveTnlP
LQMBwTLrB+TkdTIZWTYUT/e8MYZorU5x6LN+GtKuO28PEEG0jS2IgfNeUnzZjalF
p37Av84UCiIhTQD3LV6Eq1sQThQMVMm/S+qkqZrNL3I/+TbS3Ztf6q7u7zDRCsnr
vum2JR0f9vtGfpd5j3hGVXjQTd0jU3uFdY1kHM0ISGTSKYrOGYs4qsCL/VxPubo8
Lh7YfCltXY+LQkz/Q2FElcd9eM9xYWSOBhPhiudXZ3f+PnkBNRwH03eWk/LHgmhB
MByAdf2WCAU4DK7xpJKkCVsyOlsC17t8CtKDIfnt/RkPUr8108i6KOh6zvDR94Du
lJyQWuCbL7FFb7uXVO7cKTeWJFejd/K5GrQBTBpVEy3xA15c8Kj+9ALWrdJAlion
ktS85eEcp/3IzrNpPby8lhjJvujwzbzny+a9Jdn8ZcybBwpF3+IRSARnb7lJ4Yba
Ca972BfXJnFZXiYARfov
=mGnp
-----END PGP SIGNATURE-----

From sumit.sahrawat.apm13 at iitbhu.ac.in  Mon Dec  7 11:04:56 2015
From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing,
 IIT (BHU))
Date: Mon, 7 Dec 2015 16:34:56 +0530
Subject: [Haskell-beginners] DOOM rewritten in the Haskell programming
 language.
In-Reply-To: <56656575.8090109@plaimi.net>
References: <451608938.16111539.1449415275423.JavaMail.yahoo.ref@mail.yahoo.com>
 <451608938.16111539.1449415275423.JavaMail.yahoo@mail.yahoo.com>
 <56656575.8090109@plaimi.net>
Message-ID: <CAJbEW8MXXQih1_OQWH+Av=-uX2BVpFp2GH8TjNSXG5RMhixHEQ@mail.gmail.com>

I'm interested in game development, and would be willing to learn and
contribute if the project kicks off.

Just showing my support, good luck with the project.

On 7 December 2015 at 16:24, Alexander Berntsen <alexander at plaimi.net>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> David,
>
> I think it would be more valuable to make a DOOM-like game than to
> remake DOOM. Especially if you are going to aim for funding. The free
> software community has had this problem for years, where we point to
> remakes of old games as evidence to viability. It isn't. Nobody will
> be swayed by Haskell DOOM. (Although I would, personally, think it
> interesting.)
>
> Good luck with your project.
> - --
> Alexander
> alexander at plaimi.net
> https://secure.plaimi.net/~alexander
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCgAGBQJWZWV0AAoJENQqWdRUGk8B0bMQAKu/4hBeS7Iz23IMIatrc5Jd
> hkWm/bG8FRCtiLyETiH9NtUL5RPtmS+s3+o05h6fZZ1VFFfzucygsmOTw27kWApc
> ZpZiypv22y7uJsrbyxFgXVp2w6vfp6rrdA+vRSOUp/dmJ+vnn7jVeGUInnlAKX50
> WAsEUPx0q4IhGnF/2O3kBuKw/baGvp2kne2IjrgdAJ5qptVEvVoAEpIG3WveTnlP
> LQMBwTLrB+TkdTIZWTYUT/e8MYZorU5x6LN+GtKuO28PEEG0jS2IgfNeUnzZjalF
> p37Av84UCiIhTQD3LV6Eq1sQThQMVMm/S+qkqZrNL3I/+TbS3Ztf6q7u7zDRCsnr
> vum2JR0f9vtGfpd5j3hGVXjQTd0jU3uFdY1kHM0ISGTSKYrOGYs4qsCL/VxPubo8
> Lh7YfCltXY+LQkz/Q2FElcd9eM9xYWSOBhPhiudXZ3f+PnkBNRwH03eWk/LHgmhB
> MByAdf2WCAU4DK7xpJKkCVsyOlsC17t8CtKDIfnt/RkPUr8108i6KOh6zvDR94Du
> lJyQWuCbL7FFb7uXVO7cKTeWJFejd/K5GrQBTBpVEy3xA15c8Kj+9ALWrdJAlion
> ktS85eEcp/3IzrNpPby8lhjJvujwzbzny+a9Jdn8ZcybBwpF3+IRSARnb7lJ4Yba
> Ca972BfXJnFZXiYARfov
> =mGnp
> -----END PGP SIGNATURE-----
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>



-- 
Regards

Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151207/db2be098/attachment.html>

From voldermort at hotmail.com  Mon Dec  7 12:05:38 2015
From: voldermort at hotmail.com (Jeremy)
Date: Mon, 7 Dec 2015 05:05:38 -0700 (MST)
Subject: build ghc without ghci libraries?
In-Reply-To: <CAD3WKgh2Thaqgku+pqNMqde3_ae6BQHd7Qg-pD+0NMQGH_a-Qg@mail.gmail.com>
References: <1448890954159-5823292.post@n5.nabble.com>
 <CAD3WKgh2Thaqgku+pqNMqde3_ae6BQHd7Qg-pD+0NMQGH_a-Qg@mail.gmail.com>
Message-ID: <1449489938397-5823721.post@n5.nabble.com>

Thanks, that worked great.



--
View this message in context: http://haskell.1045720.n5.nabble.com/build-ghc-without-ghci-libraries-tp5823292p5823721.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From ben at well-typed.com  Wed Dec  9 12:17:24 2015
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 09 Dec 2015 13:17:24 +0100
Subject: [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
Message-ID: <874mfrlstn.fsf@smart-cactus.org>


Hello everyone,

We are pleased to announce the release of GHC 7.10.3:

    https://downloads.haskell.org/~ghc/7.10.3/

There can be found source tarballs and binary distributions for 64-bit and 32-bit
modern Linux (GMP 5.0 or later), CentOS (GMP 4.0), Windows, and 64-bit
Mac OS X platforms. These binaries and tarballs have an accompanying
SHA256SUMS file signed by my GPG key id (0x97DB64AD). Significant
fixes in release include changes to the simplifier's treatment of
rules, the handling of Mac OS X frameworks, and support for response
files to work around the restrictive command line length limit on
Windows. As always, a full accounting of the changes present in this
release can be found in the release notes [1].

The previous release, 7.10.2, was well-behaved save a couple notable
bugs; while we have merged a good number of bug fixes in 7.10.3 they
were were largely low risk and so we expect that this release should be
similiarly stable.

A notable exception is the upgrade of the Windows compiler toolchain to
GCC 5.2. Typically we would refrain from making such large changes in a
point release but Windows users have been long suffering at the hand of
the old toolchain (e.g. lack of response file support, #8596, and lack
of SEH support). We expect that this change should fix far more than
breaks.

Unfortunately, due to some oversights in the release process there are
two source tarballs for this release. The first,
ghc-7.10.3-src.tar.{bz2,xz}, does not include the release notes in the
users guide. This is fixed in the second patchlevel release,
ghc-7.10.3a-src.tar.{bz2,xz}. It is recommended that users wanting a
source release use the ghc-7.10.3a-src tarballs.

GHC 7.10.3 will very likely be the last release in the GHC 7 series. In
the coming weeks we will be beginning the release process for GHC 8.0,
which will include a number of exciting features including the merger of
kinds with types, injective type families, imporved DWARF debugging
information, applicative-do syntax, a Strict language extension synonyms
mechanism, and more. See the GHC 8.0.1 status page for details [2].

Happy compiling!

Cheers,

- Ben


[1] http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide//release-7-10-3.html
[2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151209/d8af9de6/attachment.sig>

From voldermort at hotmail.com  Wed Dec  9 13:51:44 2015
From: voldermort at hotmail.com (Jeremy)
Date: Wed, 9 Dec 2015 06:51:44 -0700 (MST)
Subject: [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
In-Reply-To: <874mfrlstn.fsf@smart-cactus.org>
References: <874mfrlstn.fsf@smart-cactus.org>
Message-ID: <1449669104809-5823933.post@n5.nabble.com>

Towards the end of
http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide//release-7-10-3.html:

1.7.3. Known bugs
    At the time of release there is a fix in the Cabal upstream respository,
although it is not yet present in a release. 

"fix" is hyperlinked to itself, and it doesn't say what the fix is for.



--
View this message in context: http://haskell.1045720.n5.nabble.com/ANNOUNCE-Glasgow-Haskell-Compiler-version-7-10-3-tp5823925p5823933.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From ben at well-typed.com  Wed Dec  9 13:58:19 2015
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 09 Dec 2015 14:58:19 +0100
Subject: [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
In-Reply-To: <1449669104809-5823933.post@n5.nabble.com>
References: <874mfrlstn.fsf@smart-cactus.org>
 <1449669104809-5823933.post@n5.nabble.com>
Message-ID: <87poyfk9l0.fsf@smart-cactus.org>

Jeremy <voldermort at hotmail.com> writes:

> Towards the end of
> http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide//release-7-10-3.html:
>
> 1.7.3. Known bugs
>     At the time of release there is a fix in the Cabal upstream respository,
> although it is not yet present in a release. 
>
> "fix" is hyperlinked to itself, and it doesn't say what the fix is for.
>
Yes, indeed; this remark no longer applies but sadly made it into the
release notes. I'm working on fixing this (which unfortunately means
we will have a 7.10.3b).

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151209/132b3f1d/attachment.sig>

From mail at joachim-breitner.de  Wed Dec  9 14:28:48 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 09 Dec 2015 15:28:48 +0100
Subject: [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
In-Reply-To: <1449669104809-5823933.post@n5.nabble.com>
References: <874mfrlstn.fsf@smart-cactus.org>
 <1449669104809-5823933.post@n5.nabble.com>
Message-ID: <1449671328.24444.0.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 09.12.2015, 06:51 -0700 schrieb Jeremy:
> "fix" is hyperlinked to itself, and it doesn't say what the fix is
> for.

that is intended. fix is inherent self-referential, and furthermore
polymorphic.

Greetings,
Joachim

PS: SCNR?


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151209/f3531da9/attachment.sig>

From felipe.lessa at gmail.com  Wed Dec  9 16:56:58 2015
From: felipe.lessa at gmail.com (Felipe Lessa)
Date: Wed, 9 Dec 2015 14:56:58 -0200
Subject: [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
In-Reply-To: <1449671328.24444.0.camel@joachim-breitner.de>
References: <874mfrlstn.fsf@smart-cactus.org>
 <1449669104809-5823933.post@n5.nabble.com>
 <1449671328.24444.0.camel@joachim-breitner.de>
Message-ID: <56685D5A.70506@gmail.com>

On 09-12-2015 12:28, Joachim Breitner wrote:
> Hi,
> 
> Am Mittwoch, den 09.12.2015, 06:51 -0700 schrieb Jeremy:
>> "fix" is hyperlinked to itself, and it doesn't say what the fix is
>> for.
> 
> that is intended. fix is inherent self-referential, and furthermore
> polymorphic.
> 
> Greetings,
> Joachim
> 
> PS: SCNR 

Took me a good while to fully comprehend this joke :).  I wonder if it
was intended by the author of that line.

Cheers,

-- 
Felipe.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151209/369564d9/attachment.sig>

From ben at well-typed.com  Wed Dec  9 20:23:49 2015
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 09 Dec 2015 21:23:49 +0100
Subject: [Haskell-cafe] [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
In-Reply-To: <CA+u6gbw0eCsdvxvr3JiJE7wC1z2ACGQtmys9EQZYcsOGFZ6DyA@mail.gmail.com>
References: <874mfrlstn.fsf@smart-cactus.org>
 <CA+u6gbw0eCsdvxvr3JiJE7wC1z2ACGQtmys9EQZYcsOGFZ6DyA@mail.gmail.com>
Message-ID: <87zixjid62.fsf@smart-cactus.org>

Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> writes:

> On 9 December 2015 at 23:17, Ben Gamari <ben at well-typed.com> wrote:
>>
>>
>> [1] http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide//release-7-10-3.html
>
> The links to Trac issues in that page seem to redirect to the same page.
>
Indeed, I'm trying to work out what went wrong here.

I am quite looking forward to being able to drop DocBook in 8.0.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151209/08ce6004/attachment.sig>

From juhpetersen at gmail.com  Thu Dec 10 04:13:43 2015
From: juhpetersen at gmail.com (Jens Petersen)
Date: Thu, 10 Dec 2015 13:13:43 +0900
Subject: [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
In-Reply-To: <874mfrlstn.fsf@smart-cactus.org>
References: <874mfrlstn.fsf@smart-cactus.org>
Message-ID: <CAEDGBqLLBAP9wmmfGJ+s3Nu+3dWA_vWUHLBEKfyP2h5f+bQuRA@mail.gmail.com>

On 9 December 2015 at 21:17, Ben Gamari <ben at well-typed.com> wrote:
> We are pleased to announce the release of GHC 7.10.3

Awesome, thank you!

I have build it for Fedora and RHEL/CentOS in my Fedora Copr repo:

  https://copr.fedoraproject.org/coprs/petersen/ghc-7.10.3

The repos also include cabal-install.

Cheers, Jens

From tkn.akio at gmail.com  Fri Dec 11 10:26:06 2015
From: tkn.akio at gmail.com (Akio Takano)
Date: Fri, 11 Dec 2015 10:26:06 +0000
Subject: Optimization of IORefs and STRefs - comparison to g++
In-Reply-To: <CAO1yQHzoZkWiprMfb7L+CzkwVpLChdZ9f3pSkcPD=qt-8_Q_Vg@mail.gmail.com>
References: <CAO1yQHzoZkWiprMfb7L+CzkwVpLChdZ9f3pSkcPD=qt-8_Q_Vg@mail.gmail.com>
Message-ID: <CAOGQyFtk=yrm=vNJZWtfDoPd2HHSdWg+ENMH+WG_OaMErg9HGQ@mail.gmail.com>

Hi Mateusz,

IORef and STRef are boxed references. That is, they are a mutable cell
that contains a pointer to some immutable Haskell value. When you
increment a (STRef Int), you first dereference the pointer, allocate a
new immutable heap object to represent the new integer value, then
mutate the reference to point to the new object. This costs much more
than updating a plain mutable integer.

As far as I know there is no particularly popular library that
provides mutable references like this. As a workaround, you can create
a 1-sized unboxed mutable vector using the vector package, and use it
like a reference.

On 3 December 2015 at 01:10, Mateusz K?oczko
<mateusz.p.kloczko at gmail.com> wrote:
> Hello!
>
> I've performed a few simple tests using Haskell and C++ on primitives.
> I've compilled all Haskell programs with -O2 optimizations, and C++ ones
> with -O3
> ghc version - 7.10.2, gcc version : 5.1.1
>
> I'm sending the codes in the zip file.
>
> Problem1 -  100 000 000  iterations.
>
> Time of execution (in seconds):
> Int  pure tail recursion: 6.911011299962411e-2
> Int# pure tail recursion : 4.587398100011342e-2
> IORef for loop 1.1533970820000832
> IORef 'tail' recursion 1.0696569040001123
> STRef for loop 1.1545546840006864
> STRef tail recursion 1.1110019479992843
> C++ : 2.7e-07

On this one, g++ manages to eliminate the loop entirely, but GHC doesn't.

>
> The llvm version could be as fast as C++ one in this problem.
>
> Buuut... then there's problem 2 (using if or case) - 100 000 000 iterations:
> Int# tail recursion 1.315346227000191
> IORef for loop: 2.6442542390004746
> STRef for loop: 2.669217500999366
> C++: 0.158056
>
>
> Here haskell is about 9 times slower than C++.

The main difference on this comes from the fact that GHC does not
optimize (n `remInt#` 2#) into (n `andI#` 1#). There is a ticket [0]
that contains some discussion of this issue.

[0]: https://ghc.haskell.org/trac/ghc/ticket/5615

Hope this helps,
Takano Akio

From michael at snoyman.com  Fri Dec 11 10:38:01 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Fri, 11 Dec 2015 10:38:01 +0000
Subject: Optimization of IORefs and STRefs - comparison to g++
In-Reply-To: <CAOGQyFtk=yrm=vNJZWtfDoPd2HHSdWg+ENMH+WG_OaMErg9HGQ@mail.gmail.com>
References: <CAO1yQHzoZkWiprMfb7L+CzkwVpLChdZ9f3pSkcPD=qt-8_Q_Vg@mail.gmail.com>
 <CAOGQyFtk=yrm=vNJZWtfDoPd2HHSdWg+ENMH+WG_OaMErg9HGQ@mail.gmail.com>
Message-ID: <CAKA2JgKt-7nLFZ_HjNqX67ofpear6DcPrjDyyyXCdMZnm9mhRw@mail.gmail.com>

My mutable-containers package has unboxed and storable references actually.

On Fri, Dec 11, 2015, 12:26 PM Akio Takano <tkn.akio at gmail.com> wrote:

> Hi Mateusz,
>
> IORef and STRef are boxed references. That is, they are a mutable cell
> that contains a pointer to some immutable Haskell value. When you
> increment a (STRef Int), you first dereference the pointer, allocate a
> new immutable heap object to represent the new integer value, then
> mutate the reference to point to the new object. This costs much more
> than updating a plain mutable integer.
>
> As far as I know there is no particularly popular library that
> provides mutable references like this. As a workaround, you can create
> a 1-sized unboxed mutable vector using the vector package, and use it
> like a reference.
>
> On 3 December 2015 at 01:10, Mateusz K?oczko
> <mateusz.p.kloczko at gmail.com> wrote:
> > Hello!
> >
> > I've performed a few simple tests using Haskell and C++ on primitives.
> > I've compilled all Haskell programs with -O2 optimizations, and C++ ones
> > with -O3
> > ghc version - 7.10.2, gcc version : 5.1.1
> >
> > I'm sending the codes in the zip file.
> >
> > Problem1 -  100 000 000  iterations.
> >
> > Time of execution (in seconds):
> > Int  pure tail recursion: 6.911011299962411e-2
> > Int# pure tail recursion : 4.587398100011342e-2
> > IORef for loop 1.1533970820000832
> > IORef 'tail' recursion 1.0696569040001123
> > STRef for loop 1.1545546840006864
> > STRef tail recursion 1.1110019479992843
> > C++ : 2.7e-07
>
> On this one, g++ manages to eliminate the loop entirely, but GHC doesn't.
>
> >
> > The llvm version could be as fast as C++ one in this problem.
> >
> > Buuut... then there's problem 2 (using if or case) - 100 000 000
> iterations:
> > Int# tail recursion 1.315346227000191
> > IORef for loop: 2.6442542390004746
> > STRef for loop: 2.669217500999366
> > C++: 0.158056
> >
> >
> > Here haskell is about 9 times slower than C++.
>
> The main difference on this comes from the fact that GHC does not
> optimize (n `remInt#` 2#) into (n `andI#` 1#). There is a ticket [0]
> that contains some discussion of this issue.
>
> [0]: https://ghc.haskell.org/trac/ghc/ticket/5615
>
> Hope this helps,
> Takano Akio
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151211/7b2b1c5e/attachment.html>

From thomasmiedema at gmail.com  Mon Dec 14 00:12:39 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Mon, 14 Dec 2015 01:12:39 +0100
Subject: Discovery of source dependencies without --make
In-Reply-To: <547889A8.9030803@hupel.info>
References: <54744DB5.30306@hupel.info>
 <1416911354.1435.13.camel@joachim-breitner.de>
 <5476FA03.1070303@ro-che.info> <5476FD9B.6010407@hupel.info>
 <etPan.547766a4.5bdd194b.5d3c@mbp.local>
 <547837D0.6020205@hupel.info>
 <618BE556AADD624C9C918AA5D5911BEF3F3ED457@DB3PRD3001MB020.064d.mgd.msft.net>
 <547889A8.9030803@hupel.info>
Message-ID: <CAD3WKggAVk4j0xmOSSh7xSJVbkv7tDCp-=4G6BZ5MoW-AVkUcw@mail.gmail.com>

On Fri, Nov 28, 2014 at 3:41 PM, Lars Hupel <lars at hupel.info> wrote:

> Let's say the hypothetical feature is selected via the GHC flag
> "--topo-sort". It would add a step before regular compilation and
> wouldn't affect any other flag:
>
>   ghc -c --topo-sort fileA.hs fileB.hs ...
>
> This would first read in the specified source files and look at their
> module headers and import statements. It would build a graph of module
> dependencies _between_ the specified source files (ignoring circular
> dependencies), perform a topological sort on that graph, and proceed
> with compiling the source files in that order.
>

GHC 8 will have support for Frontend plugins. Frontend plugins enable you
to write plugins to replace
GHC major modes.

E.g. instead of saying

    ghc --make A B C

you can now say:

    ghc --frontend TopoSort A B C

You still have to implement TopoSort.hs yourself, using the GHC API to
compile A B C in topological order, but some of the plumbing is taken care
of by the Frontend plugin infrastructure already.

Take a look at this commit, especially the user's guide section and the
test case:
https://github.com/ghc/ghc/commit/a3c2a26b3af034f09c960b2dad38f73be7e3a655.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151214/408c5a8c/attachment.html>

From ezyang at mit.edu  Mon Dec 14 00:33:24 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sun, 13 Dec 2015 16:33:24 -0800
Subject: Discovery of source dependencies without --make
In-Reply-To: <CAD3WKggAVk4j0xmOSSh7xSJVbkv7tDCp-=4G6BZ5MoW-AVkUcw@mail.gmail.com>
References: <54744DB5.30306@hupel.info>
 <1416911354.1435.13.camel@joachim-breitner.de> <5476FA03.1070303@ro-che.info>
 <5476FD9B.6010407@hupel.info> <etPan.547766a4.5bdd194b.5d3c@mbp.local>
 <547837D0.6020205@hupel.info>
 <618BE556AADD624C9C918AA5D5911BEF3F3ED457@DB3PRD3001MB020.064d.mgd.msft.net>
 <547889A8.9030803@hupel.info>
 <CAD3WKggAVk4j0xmOSSh7xSJVbkv7tDCp-=4G6BZ5MoW-AVkUcw@mail.gmail.com>
Message-ID: <1450053129-sup-474@sabre>

I missed context, but if you just want the topological graph,
depanal will give you a module graph which you can then topsort
with topSortModuleGraph (all in GhcMake).  Then you can do what you want
with the result.  You will obviously need accurate targets but
frontend plugins and guessTarget will get you most of the way there.

Edward

Excerpts from Thomas Miedema's message of 2015-12-13 16:12:39 -0800:
> On Fri, Nov 28, 2014 at 3:41 PM, Lars Hupel <lars at hupel.info> wrote:
> 
> > Let's say the hypothetical feature is selected via the GHC flag
> > "--topo-sort". It would add a step before regular compilation and
> > wouldn't affect any other flag:
> >
> >   ghc -c --topo-sort fileA.hs fileB.hs ...
> >
> > This would first read in the specified source files and look at their
> > module headers and import statements. It would build a graph of module
> > dependencies _between_ the specified source files (ignoring circular
> > dependencies), perform a topological sort on that graph, and proceed
> > with compiling the source files in that order.
> >
> 
> GHC 8 will have support for Frontend plugins. Frontend plugins enable you
> to write plugins to replace
> GHC major modes.
> 
> E.g. instead of saying
> 
>     ghc --make A B C
> 
> you can now say:
> 
>     ghc --frontend TopoSort A B C
> 
> You still have to implement TopoSort.hs yourself, using the GHC API to
> compile A B C in topological order, but some of the plumbing is taken care
> of by the Frontend plugin infrastructure already.
> 
> Take a look at this commit, especially the user's guide section and the
> test case:
> https://github.com/ghc/ghc/commit/a3c2a26b3af034f09c960b2dad38f73be7e3a655.

From jan.stolarek at p.lodz.pl  Mon Dec 21 17:52:34 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Mon, 21 Dec 2015 18:52:34 +0100
Subject: RFC: explicit support for GADTs in Template Haskell
Message-ID: <201512211852.34425.jan.stolarek@p.lodz.pl>

GHC Users,

I am working on adding proper support for GADTs in Template Haskell. By proper I mean that GADTs 
data constructors will no longer be encoded using H98 data constructors, but will be represented 
explicity. 

GADTs allow to declare several constructors with the same signature:

data T where
  MkT1, MkT2 :: T

The question is whether to represent such constructors in TH syntax as:

  (1) GadtC [Name] [StrictType] Name [Type]  -- or:
  (2) GadtC  Name  [StrictType] Name [Type]

Note the difference in first field. (1) is closer to the original syntax, as it stores the list of 
all names in a single declaration, as was originally written in the source code. (2) requires to 
have a separate `GadtC` for each constructor even if constructors were declared together, as in 
the example above.

I would like to hear from TH users which of these two representations you prefer. At the moment I 
have implemented (1) as it directly represents source syntax. The downside of (1) is that 
information whether several data constructors were declared together is not recoverable during 
reification, and so reifying T will yield:

data T where
  MkT1 :: T
  MkT2 :: T

Janek

---
Politechnika ??dzka
Lodz University of Technology

Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?
prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.