- Glasgow-haskell-users

Re: Records in Haskell
by Anthony Clayden 28 Jan '12

28 Jan '12

> On Thu, Jan 26, 2012 at 8:02 PM, AntC > <anthony_clayden(a)clear.net.nz> wrote: > > > Ryan Newton <rrnewton <at> gmail.com> writes: > > > > > > > > I admit I'm a big fan of polymorphic extension. But I > > don't love it enough > > for it to impede progress! > > > > Records proposals for Haskell have repeatedly foundered on > the rocks of extensibility. Meanwhile, it seems like > years of experience with field extensibility in OO > languages has shown that it's not an especially good idea, > with authors on programming practice militating for > information hiding instead. > > I don't think it's worth treading that path yet again in > Haskell. > > -Jan Jan, I agree we shouldn't try leaping forward to extensibility yet. I disagree that we should abandon any thoughts of it and produce a stopgap approach for records that won't ever be extensible. The 'proof of concept' I posted to the list last month http://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021298… already includes get and set over polymorphic records and polymorphic fields, I believe, which is half way there. I love Haskell for the way it learns from well-structured mathematical approaches -- in the way I feel OO doesn't. There is a well-structured mathematically sound approach for extensibility, as it happens. It dates back to 1969. It is the 'engine' behind large-scale programming systems all over the world every day. I do and have worked with a lot of them. It's called Relational Algebra, it's based on set theory, it's declarative - which should fit smoothly with Haskell. It has an operation to extend records called 'extend' (!). It has an operation to merge records called 'join'. It has an operation to concatenate records called 'cross-product' You'll probably know it by its 'awkward cousin' SQL. There are many reasons for hating SQL, and there are many reasons why it's a bad fit to OO -- especially because SQL is declarative. There are many reasons to go back to the better-founded mathematical basis that pre-dates SQL. AntC

1 0

Error when building cabal package with template haskell configured for profiling
by Bas van Dijk 27 Jan '12

27 Jan '12

Hello, I would like to profile a cabal package that contains template haskell code. However I get the following error: $ cabal configure --ghc-options="-O2 -prof -auto-all -caf-all" ... $ cabal build ... Dynamic linking required, but this is a non-standard build (eg. prof). You need to build the program twice: once the normal way, and then in the desired way using -osuf to set the object file suffix. What's the best way to solve this? Currently I do a cabal build -v and copy the ghc --make ... command line. Then I first build the program normally (without -prof) and then build it with -prof and -osuf p_o like the error messages suggests. This is annoying however. Is there a ticket for this bug? Bas

2 2

Re: parallelizing ghc
by John Lato 27 Jan '12

27 Jan '12

> From: Evan Laforge <qdunkan(a)gmail.com> > > On Wed, Jan 25, 2012 at 11:42 AM, Ryan Newton <rrnewton(a)gmail.com> wrote: >>> package list for me. ?The time is going to be dominated by linking, >>> which is single threaded anyway, so either way works. >> >> What is the state of incremental linkers? ?I thought those existed now. > > I think in some specific cases. I've heard there's a microsoft one? > It would be windows only of course. Is anyone using that with ghc? > > gold is supposed to be multi-threaded and fast (don't know about > incremental), but once again it's ELF-only. I've heard a few people > talking about gold with ghc, but I don't know what the results were. > > Unfortunately I'm on OS X, I don't know about any incremental or > multithreaded linking here. Neither do I. On my older machine with 2GB RAM, builds are often dominated by ld because it starts thrashing. And not many linkers target Mach-O. I've been toying with building my own ld replacement. I don't know anything about linkers, but I'd say at least even odds that I can do better than this. John L.

3 2

Re: Is it true that an exception is always terminates the thread?
by John Lato 27 Jan '12

27 Jan '12

> From: Heka Treep <zena.treep(a)gmail.com> > Subject: Re: Is it true that an exception is always terminates the > thread? > To: "Edward Z. Yang" <ezyang(a)mit.edu> > Cc: glasgow-haskell-users <glasgow-haskell-users(a)haskell.org> > Message-ID: > <CAMChDeP5mv7pu8+MbR_NZzm3vCF-3AqxY7PiOHBA8R91yWCyrQ(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > 2012/1/23, Edward Z. Yang <ezyang(a)mit.edu>: >> Excerpts from Heka Treep's message of Mon Jan 23 13:56:47 -0500 2012: >>> adding the message queue (with Chan, MVar or STM) for each process will >>> not >>> help in this kind of imitation. >> >> Why not? Instead of returning a thread ID, send the write end of a Chan >> which the thread is waiting on. You can send messages (normal or >> errors) using it. >> >> Edward >> > > Yes, one can write this: (others have commented on your actor implementation already) I'm not certain I understand your comment about synchronization; the STM implementation handles all of that. Unless you mean that you'd rather not write the "atomically"'s when writing to the TChan. But you can define: > ! :: TChan a -> a -> IO () > chan ! msg = atomically $ writeTChan chan msg This allows you to write: > test = do > mbox <- spawn actor > mbox ! "1" > mbox ! "2" > mbox ! "3" which seems to be exactly what you want. For the record, it's probably possible to do this with async exceptions, but I would not want to maintain it. For one, async exceptions are how GHC implements a lot of thread management stuff (e.g. the ThreadKilled exception). You would need to be careful that your code doesn't interfere with that. Another concern is the thread mask state, which needs to be handled carefully. For example, if you perform an "interruptable operation" while processing the message (e.g. blocking IO), another message could be received at that point, which I believe would abort processing of the first message. If you use "uninterruptableMask", then as I read the docs you can't block *at all* without making the thread unkillable. Doing this with async exceptions would be tricky to get right. STM is the best approach. John L.

5 5

Is it true that an exception is always terminates the thread?
by Heka Treep 27 Jan '12

27 Jan '12

I try to mimic Erlang like this: -------------------------------------------------------------------------------- {-# LANGUAGE FlexibleInstances #-} import Prelude hiding ( catch ) import Control.Monad import Control.Concurrent import Control.Exception spawn = forkIO wait = forever $ threadDelay (maxBound :: Int) receive = catch wait (!) = throwTo instance Exception String test = do let actor = receive putStrLn p <- spawn actor p ! "1" p ! "2" p ! "3" -- > test -- 1 -- <interactive>: "2" -------------------------------------------------------------------------------- but raise an exception terminates the thread. This is quite natural, of course. What I need is a messages -- something that works just like exceptions but don't stop a thread's computations. I mean, the scheduler knows about asynchronous exceptions, adding the message queue (with Chan, MVar or STM) for each process will not help in this kind of imitation. It's possible to solve this problem with the exceptions or with something? Or the message communication should be implemented as a new feature in the RTS?

4 7

Re: Records in Haskell
by Anthony Clayden 27 Jan '12

27 Jan '12

Ryan Newton <rrnewton <at> gmail.com> writes: > > I admit I'm a big fan of polymorphic extension. But I don't love it enough for it to impede progress! > > Regarding extension: In trying to read through all this material I don't see a lot of love for "lacks" constraints a la TRex. > Cheers, > -Ryan > Hi Ryan, I think the "lacks" constraint is sadly misunderstood, and in fact something like it will be needed eventually. [A thousand apologies for the multiposts! somewhere between gmaniac and pipermail, half my posts are going missing: I was only just warming up this far. Try again ... again ... third time] (If anybody who knows the internals of Hugs/TRex is listening, it would be great to get confirmation of the following.) As you say, it relates to whatever might happen for polymorphic records, so is outside the scope of what SPJ is trying to address in this thread. On the other hand, let's try to avoid developing an approach for 'Records in Haskell' that has to be undone when/if we get more polymorphic. >From all the suggestions in the current thread, I'm expecting the approach will include a Has class with methods get and set. It would be sweet if in future the same Has class could be extended to extended(!) records, anonymous records, renamed labels, projections on records, merged records (as you'd get from a relational join), etc. Specifically: Has r l t => ... really must mean there's exactly one field labelled l in record r, at type t (which is a constraint on whatever merged/extended term r is) compare TRex's (r\l) => ... Rec {| l : t | r |} ... which really means there's exactly one field labelled l in the Rec, at type t In hindsight, I think it was unfortunate that the original TRex paper [1] used the word "lacks" in context of its notation for constraining the record structure. (I'm looking especially at section 2.1 'Basic Operations'.) In all the operations, the types always include a Rec term with _both_ l and r. They don't all have a term of a 'bare': Rec {| r |} TRex is trying to avoid a positional specification of the record fields (which is 'implementation determined'/hidden from the programmer). But I think of 'bare' r as representing a record with a 'hole' at whatever position l is in the full record. (So the constraint (r\l) means: you're going to find a Rec with exactly one l in it; if you also find a Rec with 'bare' r, that means the same Rec, but with a 'hole'.) The HList guys picked up the word "lacks", and adapted it (successfully in context of what they were doing) to build 'Type Indexed Hlist's -- that is, record-like structures with exactly one field labelled l. Perhaps TRex should have used a notation something like: (rr :> l @ t) => Rec {| rr |} ... -- HasUnique rr l t ... Rec {| rr \ l |} ... -- rr with a hole in place of l You say: > As one anecdote, I've been very pleased using Daan Leijen's scoped labels approach My anecdote: the new approaches and extensions to type inference in GHCi have been frustratingly slow in arriving and maturing. But we now have working superclass constraints, including type equality (~), and some heavy-weight type inference. I've built a toy (and somewhat limited) polymorphic record system (with Has/get/set), which: treats Data types as records; and treats tuples as anonymous (type-indexed) records; and implements project, extend and merge. It relies on overlapping instances (so I don't mention it in polite company -- at least it doesn't use FunDeps to boot!). I achieve the effect of 'HasUnique' through instance resolution: if there's more than one occurence of label l in the record term, GHC bitches. (This is fragile: I can't use IncoherentInstances, and sometimes UndecidableInstances gives trouble.) [1] A Polymorphic Type System for Extensible Records and Variants, Gaster/Mark P. Jones, 1996.

1 0

FW: A Garbage Collection Question
by Simon Peyton-Jones 26 Jan '12

26 Jan '12

Can anyone help Burak? Simon -----Original Message----- From: burak ekici [mailto:ekcburak@hotmail.com] Sent: 24 January 2012 08:12 To: Simon Peyton-Jones Subject: A Garbage Collection Question Dear Dr. Jones, this time I am disturbing you to ask a question about how garbage collection is being managed in parallel GHC? When I use, (compositional) original strategies to parallel any part of a code, what I expect is that none of the created sparks has to be pruned, instead they should be all converted. Since, it is not possible to adopt WEAK policy in this type of strategies, due to losing the potential parallelism. (ref: Seq no more: Better Strategies for Parallel Haskell) However, in my experiments most of created sparks are getting pruned, although I use compositional strategies. Here you can see mentioned part of code, below. What could be the reason? I would be appreciated, if you shed light on the issue? Sorry for the disturbance! Kind regards, Burak. CODE: instance NFData a => NFData [a] where rnf [] = () rnf (x:xs) = rnf x `pseq` rnf xs karatsuba _ [] _ = [] karatsuba _ _ [] = [] karatsuba currentDepth xs ys | (l < 32 || currentDepth >= limit) = mul xs ys | otherwise = (x `add` (replicate l False ++ (z `add` (replicate l False ++ y)))) `Main.using` strategy where l = (min (length xs) (length ys)) `div` 2 (xs0, xs1) = splitAt l xs (ys0, ys1) = splitAt l ys x = (normalize (karatsuba (currentDepth+1) xs0 ys0)) y = (normalize (karatsuba (currentDepth+1) xs1 ys1)) z = (normalize (karatsuba (currentDepth+1) (add xs0 xs1) (add ys0 ys1))) t = (normalize (karatsuba (currentDepth+1) xs0 ys0)) u = (normalize (karatsuba (currentDepth+1) xs1 ys1)) v = z `sub` t `sub` u strategy res = (rnf x) `par` (rnf y) `par` ((rnf z) `par` (rnf t) `par` (rnf u)) `pseq` (rnf v) `pseq` (rnf res)

3 2

Re: Runtime performance degradation for multi-threaded C FFI callback
by John Lato 23 Jan '12

23 Jan '12

Hi Simon, I'm not certain that your explanation matches what I observed. All of my tests were done on a 4-core machine, executing with "+RTS -N", which should be the same as "+RTS -N4" I believe. With 1 Haskell thread (the main thread) and 4 process threads (via pthreads), I saw a significant performance degradation compared to 5 Haskell threads (main + 4 via forkIO) and 4 process threads. As I understand your explanation, if C callbacks are scheduled according to available capabilities, there should be no difference between these situations. I observed this with GHC-7.2.1, however Daniel Fischer reported that, with ghc-7.2.2, he observed different behavior (which matches your explanation AFAICT). Is it possible that the scheduling of callbacks into Haskell changed between those versions? Thanks, John L. > From: Simon Marlow <marlowsd(a)gmail.com> > Subject: Re: Runtime performance degradation for multi-threaded C FFI > callback > To: Sanket Agrawal <sanket.agrawal(a)gmail.com> > Cc: glasgow-haskell-users <glasgow-haskell-users(a)haskell.org> > Message-ID: <4F1D2F4D.9050709(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 21/01/2012 15:35, Sanket Agrawal wrote: >> Hi Edward, >> >> I was just going to get back to you about it. I did find out that the >> issue was indeed one GHC thread dealing with 5 C threads for callback >> (1:5 mapping) - so, the C threads were blocking on callback waiting for >> the only GHC thread to be available. I updated the code to do 1:1 >> mapping - 5 GHC threads for 5 C threads. That proved to be almost >> linearly scalable. > > This is almost right, except that your callbacks are not waiting for a > GHC *thread*, but what we call a "capability", which is roughly speaking > "permission to execute Haskell code". The +RTS -N option chooses the > number of capabilities. > > I expect that with -N1, your program is spending a lot of time just > switching between the different OS threads. > > It's possible that we could make the runtime more flexible here. I > recently made it possible to modify the number of capabilities at > runtime, so it's conceivable that the runtime could automatically add > capabilities if it is being called from multiple OS threads. > >> John Latos suggested the above approach two days back, but I didn't get >> to test the idea until now. >> >> It doesn't seem to matter whether number of GHC threads are increased, >> if the mapping between GHC threads and C threads is not 1:1. I got 1:1 >> mapping by doing forkIO for each C thread. Is it really possible to do >> 7:5 mapping (that is 7 GHC threads to choose from, for 5 C threads >> during callback)? I can't think of a way to do it. Not that I need it. I >> am just curious if that is possible. > > Just think of +RTS -N7 as being 7 *locks*, not 7 threads. Then it makes > perfect sense to have 7 locks available for 5 threads. > > Cheers, > Simon

3 4

Straight-line single assignment in C--
by Edward Z. Yang 23 Jan '12

23 Jan '12

Hello all, I was wondering if the following style of register assignment ever shows up in C-- code generated by GHC: a = R1 I32[a] = 1 a = R2 I32[a] = 2 That is to say, there are two disjoint live ranges of a: we could rename all instances of a in the first and second lines to something different without affecting the semantics (although maybe affecting register allocation and stack spilling.) asdf = R1 I32[asdf] = 1 a = R2 I32[a] = 2 But C-- is not in SSA form, and even when no loops are involved it seems that some naughty code generator could reuse a variable. This is pretty inconvenient, because I want to record this information a = R1 // used only once I32[a] = 1 a = R2 // used only once I32[a] = 2 in a map: a -> used only once But since the register names go all the same place this may end in tears. If multiple assignment is rare enough in straight line code, I might be able to take the conservative approach and just say a -> used multiple times Which I don't think will cause any problems in the inlining step later. But I don't have a good sense for this. Edward

2 2

Runtime performance degradation for multi-threaded C FFI callback
by Sanket Agrawal 23 Jan '12

23 Jan '12

I posted this issue on StackOverflow today. A brief recap: In the case when C FFI calls back a Haskell function, I have observed sharp increase in total time when multi-threading is enabled in C code (even when total number of function calls to Haskell remain same). In my test, I called a Haskell function 5M times using two scenarios (GHC 7.0.4, RHEL5, 12-core box): - Single-threaded C function: call back Haskell function 5M times - Total time 1.32s - 5 threads in C function: each thread calls back the Haskell function 1M times - so, total is still 5M - Total time 7.79s - Verified that pthread didn't contribute much to the overhead by having the same code call a C function instead, and compared with single-threaded version. So, almost all of the increase in overhead seems to come from GHC runtime. What I want to ask is if this is a known issue for GHC runtime? If not, I will file a bug report for GHC team with code to reproduce it. I don't want to file a duplicate bug report if this is already known issue. I searched through GHC trac using some keywords but didn't see any bugs related to it. StackOverflow post link (has code and details on how to reproduce the issue): http://stackoverflow.com/questions/8902568/runtime-performance-degradation-…

3 4