Ben Gamari | 7 Feb 19:13 2016

[ANNOUNCE] GHC 8.0.1 release candidate 2


Hello everyone,

The GHC Team is very pleased to announce the second release candidate of
the Glasgow Haskell Compiler 8.0.1 release. Source and binary
distributions as well as the newly revised users guide and Haddock
documentation can be found at

    http://downloads.haskell.org/~ghc/8.0.1-rc2/

This is the second in a series of release candidates leading up to the 8.0.1
release and fixes many of the issues reported in -rc1. These fixes
include,

  * A re-rewrite of the pattern checker by George Karachalias. The new
    checker should have far more predictable performance characteristics
    while sacrificing minimal reasoning power. This should resolve a
    large number of the issues felt in -rc1.

  * Richard Eisenberg has been hammering out all manner of
    type-application- and TypeInType-related issues (#11335, #11416,
    #11405). There is still more work to do here, however (e.g. #11471).

  * Matthew Pickering has restored support for multi-clause pattern
    synonyms (#11367)

  * A latent bug in the constraint solver which popped up as a build
    failure in xmonad-contrib in -rc1 has been fixed (#11379)

  * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a
(Continue reading)

Philip Dexter | 22 Jan 00:14 2016
Picon
Gravatar

Were usage types ever in GHC

I've recently been digging around to see if there has ever been any 
attempt to perform any sort of data reuse optimization in functional 
languages.

Along with many other papers, I've come across `Once upon a type' as well 
as `Once upon a polymorphic type'. They both mention a desire to include a 
similar system in GHC.

Then in `Playing by the rules: rewriting as a practical optimization 
technique in GHC' I see usage types mentioned in section 5.3:

"""
To express this, GHC adds extra usage type arguments to map, both at its 
definition and at its call sites. Once this is done, a specialised version 
of map can be compiled for the case when the usage-type argument is 
“once”, and a rule generated to match such calls, in exactly the same way 
as for specialising overloading.
"""

I can't tell if this is simply a hypothetical optimization or if this 
really happened at one point in the history of GHC.

I was hoping somebody could shed some light on this topic

Was a usage type system or something similar (e.g. linear type system) 
ever present in GHC?

If it was then why was it taken out (unless I'm missing something, this 
optimization is not happening today)? I could guess at this and say that 
the gains weren't worth the overhead, but perhaps there's another reason.
(Continue reading)

Ben Gamari | 13 Jan 17:19 2016

Dropping bzip2 release tarballs?

tl;dr do you rely on the .bz2 release tarballs on downloads.haskell.org?
      If so, let us know!

Hello everyone,

As you may have noticed, a few releases ago we started producing
xz-compressed binary distributions in addition to the usual bzip2
tarballs.

While preparing 8.0.1-rc1 it was suggested that we move to distributing
xz tarballs exclusively. Not only would this move reduce storage and
bandwidth demands on our infrastructure but it would also simplify the
job of producing the distributions. Indeed there is plenty of precendent 
for projects who have moved exclusively to xz (the Linux kernel and git
being two examples).

Of course, these reasons alone aren't sufficient to abandon those who
might rely on our bzip2 tarballs. If you feel strongly that we should
continue to distribute bzip2 tarballs, please let us know.

Thanks!

- Your friendly GHC packaging gnomes
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
(Continue reading)

Henning Thielemann | 10 Jan 00:49 2016
Picon

Re: Optimization of IORefs and STRefs - comparison to g++


How about just using alloca, peek and poke - like C guys do in order to 
get C's speed?
Henning Thielemann | 9 Jan 23:57 2016
Picon

suppress warning "Defined but not used: type variable ‘x’" in GHC-8.0


GHC-8.0 emits several new warnings of this kind:

    Defined but not used: type variable ‘x’

for declarations like

    type instance Snd x y = y

Enthusiastically, I started to replace unused type function arguments by 
underscores, only to find out that older GHC versions do not accept that. 
With what option can I disable this warning? Or can it be removed from 
-Wall for now?
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Mateusz Kłoczko | 3 Dec 02:10 2015
Picon

Optimization of IORefs and STRefs - comparison to g++

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
Attachment (EfficientMutability.zip): application/zip, 6419 bytes
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Alp Mestanogullari | 2 Dec 19:58 2015
Picon
Gravatar

Segfault when doing hs_init()/hs_exit() multiple times

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
Harendra Kumar | 1 Dec 11:48 2015
Picon

ghci - running functions defined in a where clause

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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Jeremy | 30 Nov 14:42 2015
Picon

build ghc without ghci libraries?

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, instead of deleting them after the fact? (I do need ghci support for
template haskell.)

To clarify, I'm building GHC itself, not using GHC to build a package.

--
View this message in context: http://haskell.1045720.n5.nabble.com/build-ghc-without-ghci-libraries-tp5823292.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
Evan Laforge | 3 Nov 18:47 2015
Picon

record field names vs. -fwarn-unused-binds

[ ccing haskell-cafe since while it's a ghc flag, I'll bet most
compilers have an equivalent ]

I really like -fwarn-unused-binds because it frequently finds bugs
where I forgot to call something or use some value.  If I put an
export list on, it can find dead functions I forgot to delete.
However, there's one case where it frequently gives false positives,
and that's unused record field names.  The problem is that I sometimes
use record field names as documentation, but the record itself is
internal and small, so I'm comfortable using positional pattern
matching to open it (and in fact that can be safer, since then
warn-unused-binds will make sure I used all the fields).  But GHC sees
these as unused functions, so it warns about them.  I can work around
by putting underscores on field names I haven't used yet, but it's a
hassle to go edit them when I want to use them.  The warning can be
useful if it indicates an unused field, but since fields can also be
extracted via the positional syntax it's not reliable.  The other use
of the warning for dead code or functions you forgot to use doesn't
apply to record accessors because they're trivial and compiler
generated.

So, would it be reasonable to exclude record field accessors from
-fwarn-unused-binds?  Or is there another way to work around it?  I
guess GHC doesn't have a "suppress warning" pragma like Java does, but
even if we did it wouldn't be much better than changing the name, and
more likely to get stale.
Mateusz Kłoczko | 31 Oct 14:39 2015
Picon

Fwd: GHC 7.10.2 and 7.8.4 - optimization flags do not force recompilation.

Hello

I would like to ask one question about optimization flags.
For different n, executing ghc --make -On MyCode.hs doesn't force recompilation for both GHC 7.10.2 and 7.8.4.

Is this intended behaviour ? Or am I missing something ?

Regards,
Mateusz Kłoczko

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Gmane