headers
Christian Maeder | 1 Mar 2011 10:08
Picon
Favicon

Re: ANNOUNCE: GHC 7.0.2 Release Candidate 2

Am 28.02.2011 21:47, schrieb Ian Lynagh:
> On Mon, Feb 28, 2011 at 04:08:55PM +0100, Christian Maeder wrote:
>> Am 28.02.2011 13:33, schrieb Christian Maeder:
>>> Am 20.02.2011 22:16, schrieb Ian Lynagh:
>>>>
>>>> We are pleased to announce the second release candidate for GHC 7.0.2:
>>>>
>>>>     http://www.haskell.org/ghc/dist/7.0.2-rc2/
>>>
>>> I'm surprised this is already the second release candidate for GHC
>>> 7.0.2. The first release candidate was announced 16.12.2010 (and forgotten).
> 
> Well, we couldn't have another first RC  :-)
> 
>>> Shouldn't there be a third candidate to be sufficiently tested?
> 
> There's a trade-off. Building testing, uploading, etc, another RC would
> be another 0.5-1 days work, and would put the release back by another
> week (which also puts back the HP release, the 7.2.1 release, and at
> this rate even the 7.4 release!).
> 
>> I could not test much yet, due to
>> http://hackage.haskell.org/trac/ghc/ticket/4972
>> and
>> http://hackage.haskell.org/trac/ghc/ticket/4973
> 
> You mean that these stop you testing with the RC, rather than that you
> think they're still broken in the 7.0 branch, right? You don't say what
> package (and version of the package) you're using in #4972, so I can't
> test it myself.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Maeder | 1 Mar 2011 11:09
Picon
Favicon

ghc-7.2.1 was: Re: ANNOUNCE: GHC 7.0.2 Release Candidate 2

Am 28.02.2011 21:47, schrieb Ian Lynagh:
[...]
> week (which also puts back the HP release, the 7.2.1 release, and at
> this rate even the 7.4 release!).

Why are you talking about a 7.2.1 release and even 7.4? The GHC trac
does not even have descriptions for those. Instead there's a milestone
for 7.0.3 (although without description, too.)

What important achievement (apart from the tickets listed) should I
expect from a 7.2.1 release compared to 7.0.2 (or 7.0.3)?

Thanks Christian
Permalink | Reply | 1 comment |
headers
Simon Marlow | 1 Mar 2011 11:46
Picon

Re: Tracing idea

On 21/02/2011 01:08, Edward Z. Yang wrote:
> Excerpts from Tyson Whitehead's message of Sun Feb 20 07:14:56 -0500 2011:
>> I believe a back trace on the actual call stack is generally considered not
>> that useful in a lazy language as it corresponds to the evaluation sequence,
>> That is, it is demand centric while written code is production centric
>
> Yeah, such a buffer wouldn't be very useful for end-users; I'm thinking more
> in terms of going "backwards in time" for the STG execution.

Yes, that might be useful.  However it would require compiling all the 
libraries with that option too - so it would be an internal debug option 
for use with a live GHC build, not something you could use with a 
pre-built GHC (well, you could use it, but you wouldn't get traces for 
library code).

Cheers,
	Simon
Permalink | Reply | 1 comment |
headers
Simon Marlow | 1 Mar 2011 12:05
Picon

Re: ghc-pkg regression (or deliberate change)?

On 22/02/2011 22:38, Tyler Pirtle wrote:
> Hi there,
>
> I'm using a system with an older version of GHC (6.8.3), and invoking
> ghc-pkg against a non-existing file in -f:
>
> $ haskell/ghc/v683/k8/lib/ghc-6.8.3/ghc-pkg.bin --global-conf
> haskell/ghc/v683/k8/lib/ghc-6.8.3/package.conf -f
> /tmp/nonexistent.Foo.package.conf register /tmp/Foo.package_spec
>
> ghc-pkg happily creates the file referenced with -f and fills it with
> these contents:
>
>
> [InstalledPackageInfo {package = PackageIdentifier {pkgName =
> "hsS-SFoo", pkgVersion = Version {versionBranch = [1,0], versionTags =
> []}}, license = AllRightsReserved, copyright = "", maintainer = "",
> author = "", stability = "", homepage = "", pkgUrl = "", description =
> "", category = "", exposed = False, exposedModules = [], hiddenModules
> = [], importDirs = [], libraryDirs = [], hsLibraries = [],
> extraLibraries = [], extraGHCiLibraries = [], includeDirs = [],
> includes = [], depends = [], hugsOptions = [], ccOptions = [],
> ldOptions = [], frameworkDirs = [], frameworks = [], haddockInterfaces
> = [], haddockHTMLs = []}
> ]
>
>
> GHC 7.0.1 it appears does not do the same thing:
>
> $ haskell/ghc/v701/k8/lib/ghc-7.0.1/ghc-pkg --global-conf
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Mar 2011 12:13
Picon

Re: SMP parallelism gains inferior than expected

On 24/02/2011 13:26, José Pedro Magalhães wrote:
> (Forwarding to haskell-cafe)
>
> Hi,
>
> I have a program that computes a matrix of Floats of m rows by n
> columns. Computing each Float is relatively expensive. Each line is
> completely independent of the others, so I thought I'd try some simple
> SMP parallelism on this code:
>
> myFun :: FilePath -> IO ()
> myFun fp =
>    do fs <- readDataDir fp
>       let process f = readFile' f >>= parse
>           printLine = putStrLn . foldr (\a b -> show a ++ "\t" ++ b) ""
>           runDiff l = [ [ diff x y | y <- l ]
>                       | (x,i) <- zip l (map getId fs), myFilter i ]
>       ps <- mapM process fs
>       sequence_ [ printLine x | x <- runDiff ps _`using` parList rdeepseq_ ]
>
> So, I'm using parList to evaluate the rows in parallel, and fully
> evaluating each row. Here are the timings on a Dual Quad Core AMD 2378
>  <at> 2.4 GHz, ghc-6.12.3, parallel-2.2.0.1:
>
> -N      time (ms)
> none    1m50
> 2       1m33
> 3       1m35
> 4       1m22
> 5       1m11
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roman Leshchinskiy | 1 Mar 2011 12:55
Picon
Picon
Favicon

Re: Faster Array#/MutableArray# copies

Simon Marlow wrote:
>
> For small arrays like this maybe we should have a new array type that
> leaves out all the card-marking stuff too (or just use tuples, as Roman
> suggested).

Would it, in theory, be possible to have an "unpacked" array type? That
is, could we have constructors for which the length of the closure is
determined dynamically at runtime?

Roman
Permalink | Reply | 2 comments |
headers
Simon Marlow | 1 Mar 2011 13:09
Picon

Re: Faster Array#/MutableArray# copies

On 01/03/2011 11:55, Roman Leshchinskiy wrote:
> Simon Marlow wrote:
>>
>> For small arrays like this maybe we should have a new array type that
>> leaves out all the card-marking stuff too (or just use tuples, as Roman
>> suggested).
>
> Would it, in theory, be possible to have an "unpacked" array type? That
> is, could we have constructors for which the length of the closure is
> determined dynamically at runtime?

Certainly, but the amount of effort to implement depends on what you 
want to support. e.g. do you want to support {-# UNPACK #-} on primitive 
array types in a constructor field?  That's probably quite hard.  I 
believe Duncan Coutts has been thinking along similar lines, we talked 
about it once.

Or were you thinking of something more restricted?

Cheers,
	Simon
Permalink | Reply | 1 comment |
headers
Sean Leather | 1 Mar 2011 14:11
Picon

Re: ghc-7.2.1 was: Re: ANNOUNCE: GHC 7.0.2 Release Candidate 2


On Tue, Mar 1, 2011 at 11:09, Christian Maeder wrote:
Why are you talking about a 7.2.1 release [...]?

What important achievement (apart from the tickets listed) should I expect from a 7.2.1 release compared to 7.0.2 (or 7.0.3)?

http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/19604

Regards,
Sean
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Permalink | Reply | 0 comments |
headers
Roman Leshchinskiy | 1 Mar 2011 16:50
Picon
Picon
Favicon

Re: Faster Array#/MutableArray# copies

Simon Marlow wrote:
> On 01/03/2011 11:55, Roman Leshchinskiy wrote:
>
>>
>> Would it, in theory, be possible to have an "unpacked" array type? That
>>  is, could we have constructors for which the length of the closure is
>> determined dynamically at runtime?
>
> Certainly, but the amount of effort to implement depends on what you
> want to support. e.g. do you want to support {-# UNPACK #-} on primitive
> array types in a constructor field?  That's probably quite hard.  I
> believe Duncan Coutts has been thinking along similar lines, we talked
> about it once.

I can see that supporting this would be rather hard:

data T a = T {-# UNPACK #-} (Array# a)

We would have to allow Array# to point to the middle of a closure and it's
far from obvious how to initialise this since we don't have Array#
literals.

> Or were you thinking of something more restricted?

Yes, I was thinking of some special syntax. Something along these lines:

data T a = T {a}

f x = T {x x x}
g (T {x y z}) = x
h (T xs) = xs{0}

I'm not seriously suggesting this syntax, this is just to demonstrate the
general idea. In the last function, it shouldn't be possible to do
anything with xs except indexing and taking the length.

This would be much easier, right?

Of course, we would also want this for byte arrays...

Roman
Permalink | Reply | 0 comments |
headers
Nathan Howell | 1 Mar 2011 18:29
Picon

Re: Faster Array#/MutableArray# copies

On Mon, Feb 28, 2011 at 9:01 AM, Simon Marlow <marlowsd <at> gmail.com> wrote:
Ideally you'd want the heap check in the primop to be aggregated into the calling function's heap check, and the primop should allocate directly from the heap instead of calling out to the RTS allocate(). All this is a bit much to expect LLVM to do, but we could do it in the Glorious New Code Generator...

It's probably (certainly) better to do it in the code generator but it is rather easy to perform in LLVM and might be a worthwhile optimization during LTO/LTCG.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Permalink | Reply | 0 comments |

Gmane