Hi Simon,
I've tested with current master (commit 6f4a073) and the link time is
back down. In fact the compile time seems fast in general, and an
unrelated ld error which I hadn't yet tracked down has disappeared
too.
Thanks for the quick patch!
Conrad.
On 16 February 2012 19:45, Simon Marlow
Hi all,
On Thu, Feb 16, 2012 at 4:59 PM, Johan Tibell wrote:
> On Thu, Feb 16, 2012 at 4:52 PM, Alex Mason wrote:
>> How difficult do you think it would be to implement this in GHC?
>
> Quite easy I think. All the difficulty is in getting good benchmarks.
The computeRep function in compiler/bas
> However, the GHC API doesn't provide a way to do this directly (I hadn't
> really thought about this when I suggested the idea before, sorry). The GHC
> API provides support for compiling multiple modules in the way that GHCi and
> --make work; each module is added to the HPT as it is compiled.
On Thu, Feb 16, 2012 at 3:45 AM, Simon Marlow wrote:
> Will be fixed in 7.4.2:
>
> http://hackage.haskell.org/trac/ghc/ticket/5878
Nice, thanks for the quick fix!
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haske
On Thu, Feb 16, 2012 at 4:25 PM, Johan Tibell wrote:
> I've been thinking about this some more and I think we should
> definitely unpack primitive types (e.g. Int, Word, Float, Double,
> Char) by default.
Initially we could hide this feature behind a new
-funbox-strict-primitive-fields, but I def
On Thu, Feb 16, 2012 at 5:03 PM, Alex Mason wrote:
> Of course, that makes sense. Do we already have a way to specify that a field
> should be lazy? I can imagine programs where we don't want this behaviour,
> and people would need an escape hatch (or their programs might run slower, or
> even
Of course, that makes sense. Do we already have a way to specify that a field
should be lazy? I can imagine programs where we don't want this behaviour, and
people would need an escape hatch (or their programs might run slower, or even
not terminate). I know we've got lazy patterns with ~, do we
Welcome back to reality Don! ;)
On Thu, Feb 16, 2012 at 4:56 PM, Don Stewart wrote:
> Couldn't you measure it by changing base to use data Int = I# {-# UNPACK #-}
> Int# and see what happens?
I'm not sure what this would mean. Int# is already unpacked.
-- Johan
On Thu, Feb 16, 2012 at 4:52 PM, Alex Mason wrote:
> Sounds like it's definitely worth playing with. I would hesitate to use the
> shootout benchmarks though, simply because anything there is already going to
> be unpacked to the hilt.
That was the point of number (2) above. By disabling their
Couldn't you measure it by changing base to use data Int = I# {-# UNPACK
#-} Int# and see what happens?
On Thursday, February 16, 2012, Alex Mason wrote:
> Hi Johan,
>
> Sounds like it's definitely worth playing with. I would hesitate to use
> the shootout benchmarks though, simply because anythi
Hi Johan,
Sounds like it's definitely worth playing with. I would hesitate to use the
shootout benchmarks though, simply because anything there is already going to
be unpacked to the hilt.
How difficult do you think it would be to implement this in GHC?
Cheers,
Alex
On 17/02/2012, at 11:25,
On Thu, Feb 16, 2012 at 4:42 PM, Johan Tibell wrote:
> 1. In theory the user could create a cut-n-paste copy of the data
> structure and specialize it to a particular type, but I think we all
> agree that would be unfortunate (not to say that it cannot be
> justified in extreme cases.)
I thought
FWIW
jhc has always unboxed everything smaller or equal to the size of a pointer
unconditionally. It's all about the cache performance.
John
On Thu, Feb 16, 2012 at 4:25 PM, Johan Tibell wrote:
> Hi all,
>
> I've been thinking about this some more and I think we should
> definitely unpack p
On Thu, Feb 16, 2012 at 4:25 PM, Johan Tibell wrote:
> The worry is that reboxing will cost us, but I realized today that at
> least one other language, Java, does this already today and even
> though it hurts performance in some cases, it seems to be a win on
> average. In Java all primitive fiel
Hi all,
I've been thinking about this some more and I think we should
definitely unpack primitive types (e.g. Int, Word, Float, Double,
Char) by default.
The worry is that reboxing will cost us, but I realized today that at
least one other language, Java, does this already today and even
though i
> I haven't checked, but ...
I checked, and your solution works. In the context of a larger program,
getting NOLINE pragmas in all the right places would be challenging,
wouldn't it?
I found a bug report on the GHC Trac [1] in which Simon explains the
importance of evaluating the thunk before cal
On Thu, Feb 16, 2012 at 02:55:13PM -0600, Austin Seipp wrote:
> 64-bit GHC on OS X gives me this:
>
> $ ghc -fforce-recomp -threaded finalizer
> [1 of 1] Compiling Main ( finalizer.hs, finalizer.o )
> Linking finalizer ...
> $ ./finalizer
> waiting ...
> done!
> waiting ...
> running f
> This seems to be an explanation of why a finalizer might run later than
expected (or not run at all). But his paste shows that it runs *earlier*
than what he expected.
What he said.
> 64-bit GHC on OS X gives me this:
>
> ...
>
> However, it's a different story when `-O2` is specified:
>
> ...
64-bit GHC on OS X gives me this:
$ ghc -fforce-recomp -threaded finalizer
[1 of 1] Compiling Main ( finalizer.hs, finalizer.o )
Linking finalizer ...
$ ./finalizer
waiting ...
done!
waiting ...
running finalizer
done!
However, it's a different story when `-O2` is specified:
$ ghc -O
Quoting Antoine Latter :
On Thu, Feb 16, 2012 at 2:04 PM, Michael Craig wrote:
When I read the docs for System.Mem.Weak, it all seems to make sense. But
then this code doesn't run as I expect it to when I turn on
-threaded: http://hpaste.org/63832 (Expected/actual output are listed in the
past
On Thu, Feb 16, 2012 at 2:04 PM, Michael Craig wrote:
> When I read the docs for System.Mem.Weak, it all seems to make sense. But
> then this code doesn't run as I expect it to when I turn on
> -threaded: http://hpaste.org/63832 (Expected/actual output are listed in the
> paste.)
>
> I've tried th
When I read the docs for System.Mem.Weak, it all seems to make sense. But
then this code doesn't run as I expect it to when I turn on -threaded:
http://hpaste.org/63832 (Expected/actual output are listed in the paste.)
I've tried this on 7.4.1 and 7.0.4 with the same results. Can someone
enlighten
I have similar issues to this in jhc due to its pervasive caching of
compilation results. Basically I must keep track of any potentially
ABI-changing flags and ensure they are consistently passed to every
compilation unit and include them in the signature hash along with the
file contents. I make s
Hello Simon, thanks for your attention :)
On 02/16/2012 04:25 PM, Simon Marlow wrote:
>> I found that earlier versions of hsc2hs included HsFFI.h into the
[...]
>> As I understand, this situation means that while the ghc itself and
>> haskell programs compiled by it are largefile-capable, any thi
On 15/02/2012 19:51, Evan Laforge wrote:
On Wed, Feb 15, 2012 at 11:17 AM, Eugene Crosser wrote:
On 02/15/2012 09:59 PM, Evan Laforge wrote:
Unfortunately, the result is I (apparently) can't use it now. Here's
how that happens: The change was to remove the dependency on HsFFI.h.
Evan, *if
On 15/02/2012 12:31, Eugene Crosser wrote:
Hello all,
I am new here, but I want to report what I suspect may be a problem.
I ran into it while using some third-party package from hackage on a
32bit Linux with ghc 7.4.1. I discovered that off_t fields in the .hsc
files in the package where inter
Will be fixed in 7.4.2:
http://hackage.haskell.org/trac/ghc/ticket/5878
Cheers,
Simon
On 16/02/2012 05:10, Evan Laforge wrote:
Thanks for bringing this up. I've been having the same problem and was
thinking there was something wrong with my system. I have 3 main files
and one util that
27 matches
Mail list logo
