- Glasgow-haskell-users

Invariants for GHC.Event ensureIOManagerIsRunning
by Edward Z. Yang 18 Apr '12

18 Apr '12

Hello all, I recently ran into a rather reproduceable bug where I would get this error from the event manager: /dev/null: hClose: user error (Pattern match failure in do expression at libraries/base/System/Event/Thread.hs:83:3-10) The program was doing some rather strange things: - It was running the Haskell RTS inside another system (Urweb) which was making use of pthreads, sockets, etc. - The Haskell portion was linked against the threaded RTS, and doing communication with a process. and is rather complicated (two compilers are involved). But the gist of the matter is that if I added a quick call to ensureIOManagerIsRunning after hs_init, the error went away. So, if the IO manager is not eagerly loaded at the call to hs_init, how do we decided when it should be loaded? It seems probably that we missed a case. Edward P.S. I tried reproducing on a simple test case but couldn't manage it.

3 2

faking universal quantification in constraints
by Nicolas Frisby 17 Apr '12

17 Apr '12

I'm simulating skolem variables in order to fake universal quantification in constraints via unsafeCoerce. http://hpaste.org/67121 I'm not familiar with various categories of types from the run-time's perspective, but I'd be surprised if there were NOT a way to use this code to create run-time errors. Is there a way to make it safer? Perhaps by making Skolem act more like GHC's Any type? Or perhaps like the -> type? I'd like to learn about the varieties of types from the run-time's perspective. I know Dimitrios Vytiniotis is trying to implement these legitimately in GHC, but I don't know much about that project's status, nor any documentation indicating how to try it out in GHC HEAD (e.g. what's the syntax?). Is there a page on the GHC wiki or something to check that sort of thing? I wonder how far this Forall_S trick can take me in the interim towards Vytiniotis' objective functionality when paired with a (totally safe) class for implication. > class Implies (ante :: Constraint) (conc :: Constraint) where > impliesD :: Dict ante -> Dict conc Thanks, Nick

3 7

What do the following numbers mean?
by Jurriaan Hage 10 Apr '12

10 Apr '12

Dear all, I ran a small example program, and this is what I got from using the -s flag: 486,550,118,368 bytes allocated in the heap 323,749,418,440 bytes copied during GC 1,842,979,344 bytes maximum residency (219 sample(s)) 204,653,688 bytes maximum slop 4451 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 924208 collections, 0 parallel, 1861.17s, 1866.05s elapsed Generation 1: 219 collections, 0 parallel, 283.44s, 284.01s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 740.61s (745.45s elapsed) GC time 2144.61s (2150.06s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 2885.23s (2895.51s elapsed) %GC time 74.3% (74.3% elapsed) Alloc rate 656,953,176 bytes per MUT second Can anyone tell me what the exact difference is between 1,842,979,344 bytes maximum residency (219 sample(s)) and 4451 MB total memory in use (0 MB lost due to fragmentation) I could not find this information in the docs anywhere, but I may have missed it. best, Jur

3 2

Code review for new primop's CMM code.
by Ryan Newton 10 Apr '12

10 Apr '12

Hi all, In preparation for students working on concurrent data structures GSOC(s), I wanted to make sure they could count on CAS for array elements as well as IORefs. The following patch represents my first attempt: https://github.com/rrnewton/ghc/commit/18ed460be111b47a759486677960093d71ee… It passes a simple test [Appendix 2 below], but I am very unsure as to whether the GC write barrier is correct. Could someone do a code-review on the following few lines of CMM: if (GET_INFO(arr) == stg_MUT_ARR_PTRS_CLEAN_info) { SET_HDR(arr, stg_MUT_ARR_PTRS_DIRTY_info, CCCS); len = StgMutArrPtrs_ptrs(arr); // The write barrier. We must write a byte into the mark table: I8[arr + SIZEOF_StgMutArrPtrs + WDS(len) + (ind >> MUT_ARR_PTRS_CARD_BITS )] = 1; } Thanks, -Ryan -- Appendix 1: First draft code CMM definition for casArray# ------------------------------------------------------------------- stg_casArrayzh /* MutableArray# s a -> Int# -> a -> a -> State# s -> (# State# s, Int#, a #) */ { W_ arr, p, ind, old, new, h, len; arr = R1; // anything else? ind = R2; old = R3; new = R4; p = arr + SIZEOF_StgMutArrPtrs + WDS(ind); (h) = foreign "C" cas(p, old, new) []; if (h != old) { // Failure, return what was there instead of 'old': RET_NP(1,h); } else { // Compare and Swap Succeeded: if (GET_INFO(arr) == stg_MUT_ARR_PTRS_CLEAN_info) { SET_HDR(arr, stg_MUT_ARR_PTRS_DIRTY_info, CCCS); len = StgMutArrPtrs_ptrs(arr); // The write barrier. We must write a byte into the mark table: I8[arr + SIZEOF_StgMutArrPtrs + WDS(len) + (ind >> MUT_ARR_PTRS_CARD_BITS )] = 1; } RET_NP(0,h); } } -- Appendix 2: Simple test file; when run it should print: ------------------------------------------------------------------- -- Perform a CAS within a MutableArray# -- 1st try should succeed: (True,33) -- 2nd should fail: (False,44) -- Printing array: -- 33 33 33 44 33 -- Done. ------------------------------------------------------------------- {-# Language MagicHash, UnboxedTuples #-} import GHC.IO import GHC.IORef import GHC.ST import GHC.STRef import GHC.Prim import GHC.Base import Data.Primitive.Array import Control.Monad ------------------------------------------------------------------------ -- -- | Write a value to the array at the given index: casArrayST :: MutableArray s a -> Int -> a -> a -> ST s (Bool, a) casArrayST (MutableArray arr#) (I# i#) old new = ST$ \s1# -> case casArray# arr# i# old new s1# of (# s2#, x#, res #) -> (# s2#, (x# ==# 0#, res) #) ------------------------------------------------------------------------ {-# NOINLINE mynum #-} mynum :: Int mynum = 33 main = do putStrLn "Perform a CAS within a MutableArray#" arr <- newArray 5 mynum res <- stToIO$ casArrayST arr 3 mynum 44 res2 <- stToIO$ casArrayST arr 3 mynum 44 putStrLn$ " 1st try should succeed: "++show res putStrLn$ "2nd should fail: "++show res2 putStrLn "Printing array:" forM_ [0..4] $ \ i -> do x <- readArray arr i putStr (" "++show x) putStrLn "" putStrLn "Done."

2 1

GSoC proposal: Units for GHC
by Nils Schweinsberg 04 Apr '12

04 Apr '12

Hi Haskell-Cafe & GHC-users! I'm looking to apply for the GSoC and since I've worked on GHC before I'd like to continue to do so. My proposal would be something that tempted me (as a physics student) for a while: Units for Haskell/GHC. This project has been suggested for a long time on the GHC wiki, and there is already a lot of work done for other languages like ML, F# etc[1]. I have tried to implement e.g. the unification algorithm from the "Types for Units-of-Measure in F#" talk[2] for an abstract syntax tree[3] and it was pretty much straight forward. As I see it, the project would consist of: 1.) Find appropriate rules/algorithms for unit analysis. Most (if not all?) of this should be covered in those papers/talks on [1]. 2.) Applying the rules to the Haskell syntax tree used in GHC. I have approximately 3 years of experience with Haskell, I worked for the database research group[4] at the University of Tübingen (Germany) on the Database Supported Haskell[5] library. I've done most of the coding for the monad comprehension[6] extension, which has been added to the latest GHC release version. I'm already quite familiar with the GHC internals of the compiler/typechecker, and even though I'd have to look up how exactly type interference etc. works in GHC (as I've only *used* it, but never tried to understand/modify it) I'm confident that the work on GHC itself should be doable in the given timeframe. So my questions would be: Do you think this is a appropriate GSoC project? What should I include in the application/project proposal? Anything else? Opinions, suggestions? I realize that I'm kind of late and probably should have written this email a long time ago. But there are still 2 days left for the student application and hopefully I'll get some good feedback by then. - Nils [1]: http://research.microsoft.com/en-us/um/people/akenn/units/index.html [2]: http://research.microsoft.com/en-us/um/people/akenn/units/MLWorkshop2008.pdf [3]: https://github.com/mcmaniac/units/blob/master/src/Unification.hs [4]: http://db.inf.uni-tuebingen.de/team [5]: http://hackage.haskell.org/package/DSH [6]: http://db.inf.uni-tuebingen.de/files/giorgidze/haskell2011.pdf

5 5

A Modest Records Proposal
by Gershom B 02 Apr '12

02 Apr '12

The records discussion has been really complicated and confusing. But I have a suggestion that should provide a great deal of power to records, while being mostly[1] backwards-compatible with Haskell 2010. Consider this example: data A a = A{a:a, aa::a, aaa :: a -> A (a -> a)} data B a = B{aaa :: a -> A (a -> a), a :: A} Now what is the type of this? aaaa aaaaa a aa = aaaaa{a = a, aaa = aa} Using standard Haskell typeclasses this is a difficult question to answer. The types of aaaa for A and B do not unify in an obvious way. However, while they are intensionally quite distinct, they unify trivially extensionally. The obvious thing to do is then to extend the type system with extensional equality on record functions. Back when Haskell was invented, extensional equality was thought to be hard. But purity was thought to be hard too, and so were Monads. Now, we know that function existentionality is easy. In fact, if we add the Univalence Axiom to GHC[2], then this is enough to get function existensionality. This is a well-known result of Homotopy Type Theory[3], which is a well-explored approach that has existed for at least a few years and produced more than one paper[4]. Homotopy Type Theory is so sound and well understood that it has even been formalized in Coq. Once we extend GHC with homotopies, it turns out that records reduce to mere syntactic sugar, and there is a natural proof of their soundness (Appendix A). Furthermore, there is a canonical projection for any group of fields (Appendix B). Even better, we can make "." into the identity path operator, unifying its uses in composition and projection. In fact, with extended (parenthesis-free) section rules, "." can also be used to terminate expressions, making Haskell friendly not only to programmers coming from Java, but also to those coming from Prolog! After some initial feedback, I'm going to create a page for the Homotopy Extensional Records Proposal (HERP) on trac. There are really only a few remaining questions. 1) Having introduced homotopies, why not go all the way and introduce dependent records? In fact, are HERP and Dependent Extensional Records Proposal (DERP) already isomorphic? My suspicion is that HERP is isomorphic, but DERP is not. However, I can only get away with my proof using Scott-free semantics. 2) Which trac should I post this too? Given how well understood homotopy type theory is, I'm tempted to bypass GHC entirely and propose this for haskell-prime. 3) What syntax should we use to represent homotopies? See extend discussion in Appendix C. HTH HAND, Gershom [1] To be precise, 100% of Haskell 2010 programs should, usually, be able to be rewritten to work with this proposal with a minimal set of changes[1a]. [1a] A minimal set of changes is defined as the smallest set of changes necessary to make to a Haskell 2010 program such that it works with this proposal. We can arrive at these changes by the following procedure: 1) Pick a change[1b]. 2) Is it minimal? If so keep it. 3) are we done? If not, make another change. [1b] To do this constructively, we need an order. I suggest the lo mein, since noodles give rise to a free soda. [2] I haven't looked at the source, but I would suggest putting it in the file Axioms.hs. [3] http://homotopytypetheory.org/ [4] http://arxiv.org/ *Appendix A: A Natural Proof of the Soundness of HERP Take the category of all types in HERP, with functions as morphisms. Call it C. Take the category of all sound expressions in HERP, with functions as morphisms. Call it D. Define a full functor from C to D. Call it F. Define a faithful functor on C and D. Call it G. Draw the following diagram. F(X)----F(Y) | | | | | | G(X)----G(Y) Define the arrows such that everything commutes. *Appendix B: Construction of a Canonical Projection for Any Group of Fields. 1) Take the fields along the homotopy to an n-ball. 2) Pack them loosely with newspaper and gunpowder. 3) Project them from a cannon. In an intuitionistic logic, the following simplification is possible: 1) Use your intuition. *Appendix C: Homotopy Syntax Given that we already are using the full unicode set, what syntax should we use to distinguish paths and homotopies? At first, I thought we could avoid providing any syntax for homotopies at all. Haskell is a language with type inference, so we should just be able to infer paths and homotopies behind the scenes by adding homotopies to the type system. That's a very nice answer in theory. But in the real world, when we're writing code that solves actual problems, theoretical niceties break down. What if a user wants to use a nonstandard homotopy? Why should we stop them just because we're too lazy to come up with a good syntax? I then realized that we keep running out of syntax because we've limited ourselves to unicode. Instead, I propose we add a potentially infinite universe of identifiers: youtube videos. For example, the higher inductive type for a circle can be written as: homotopyType http://www.youtube.com/watch?v=dQw4w9WgXcQ where Base ::: http://www.youtube.com/watch?v=dQw4w9WgXcQ Loop ::: http://www.youtube.com/watch?v=J---aiyznGQ Base Base Note that the urls do not use SSL. For portability reasons, I propose that SSL only be enabled as an optional extension.

3 2

Re: [Haskell-cafe] A Modest Records Proposal
by Greg Weber 02 Apr '12

02 Apr '12

Obviously Gregory is not familiar with Homotopy. In fact, its isomorphism predicts that if someone named Greg is involved in a discussion, someone named Gregory will also become involved. Or that is what I get for responding to an e-mail without reading it on April 1st :) On Sun, Apr 1, 2012 at 7:40 AM, Gregory Collins <greg(a)gregorycollins.net> wrote: > Whoosh? :-) > > On Sun, Apr 1, 2012 at 3:54 PM, Greg Weber <greg(a)gregweber.info> wrote: >> >> Hi Gershom, >> >> This sounds very interesting even if I have no idea what you are >> talking about :) >> Please create a proposal linked from this page: >> http://hackage.haskell.org/trac/ghc/wiki/Records >> The first thing you should probably do is explain the programmer's >> point of view. That ensures that we are all going through the >> requirements phase correctly. >> I can assure you that haskell prime would not accept a records change >> until it is first implemented in GHC or another Haskell compiler. >> >> Thanks, >> Greg Weber >> >> On Sat, Mar 31, 2012 at 11:14 PM, Gershom B <gershomb(a)gmail.com> wrote: >> > The records discussion has been really complicated and confusing. But >> > I have a suggestion that should provide a great deal of power to >> > records, while being mostly[1] backwards-compatible with Haskell 2010. >> > Consider this example: >> > >> > data A a = A{a:a, aa::a, aaa :: a -> A (a -> a)} >> > data B a = B{aaa :: a -> A (a -> a), a :: A} >> > >> > Now what is the type of this? >> > >> > aaaa aaaaa a aa = aaaaa{a = a, aaa = aa} >> > >> > Using standard Haskell typeclasses this is a difficult question to >> > answer. The types of aaaa for A and B do not unify in an obvious way. >> > However, while they are intensionally quite distinct, they unify >> > trivially extensionally. The obvious thing to do is then to extend the >> > type system with extensional equality on record functions. >> > >> > Back when Haskell was invented, extensional equality was thought to be >> > hard. But purity was thought to be hard too, and so were Monads. Now, >> > we know that function existentionality is easy. In fact, if we add the >> > Univalence Axiom to GHC[2], then this is enough to get function >> > existensionality. This is a well-known result of Homotopy Type >> > Theory[3], which is a well-explored approach that has existed for at >> > least a few years and produced more than one paper[4]. Homotopy Type >> > Theory is so sound and well understood that it has even been >> > formalized in Coq. >> > >> > Once we extend GHC with homotopies, it turns out that records reduce >> > to mere syntactic sugar, and there is a natural proof of their >> > soundness (Appendix A). Furthermore, there is a canonical projection >> > for any group of fields (Appendix B). Even better, we can make "." >> > into the identity path operator, unifying its uses in composition and >> > projection. In fact, with extended (parenthesis-free) section rules, >> > "." can also be used to terminate expressions, making Haskell friendly >> > not only to programmers coming from Java, but also to those coming >> > from Prolog! >> > >> > After some initial feedback, I'm going to create a page for the >> > Homotopy Extensional Records Proposal (HERP) on trac. There are really >> > only a few remaining questions. 1) Having introduced homotopies, why >> > not go all the way and introduce dependent records? In fact, are HERP >> > and Dependent Extensional Records Proposal (DERP) already isomorphic? >> > My suspicion is that HERP is isomorphic, but DERP is not. However, I >> > can only get away with my proof using Scott-free semantics. 2) Which >> > trac should I post this too? Given how well understood homotopy type >> > theory is, I'm tempted to bypass GHC entirely and propose this for >> > haskell-prime. 3) What syntax should we use to represent homotopies? >> > See extend discussion in Appendix C. >> > >> > HTH HAND, >> > Gershom >> > >> > [1] To be precise, 100% of Haskell 2010 programs should, usually, be >> > able to be rewritten to work with this proposal with a minimal set of >> > changes[1a]. >> > >> > [1a] A minimal set of changes is defined as the smallest set of >> > changes necessary to make to a Haskell 2010 program such that it works >> > with this proposal. We can arrive at these changes by the following >> > procedure: 1) Pick a change[1b]. 2) Is it minimal? If so keep it. 3) >> > are we done? If not, make another change. >> > >> > [1b] To do this constructively, we need an order. I suggest the lo >> > mein, since noodles give rise to a free soda. >> > >> > [2] I haven't looked at the source, but I would suggest putting it in >> > the file Axioms.hs. >> > >> > [3] http://homotopytypetheory.org/ >> > >> > [4] http://arxiv.org/ >> > >> > >> > *Appendix A: A Natural Proof of the Soundness of HERP >> > >> > Take the category of all types in HERP, with functions as morphisms. >> > Call it C. Take the category of all sound expressions in HERP, with >> > functions as morphisms. Call it D. Define a full functor from C to D. >> > Call it F. Define a faithful functor on C and D. Call it G. Draw the >> > following diagram. >> > >> > F(X)----F(Y) >> > | | >> > | | >> > | | >> > G(X)----G(Y) >> > >> > Define the arrows such that everything commutes. >> > >> > >> > *Appendix B: Construction of a Canonical Projection for Any Group of >> > Fields. >> > >> > 1) Take the fields along the homotopy to an n-ball. >> > 2) Pack them loosely with newspaper and gunpowder. >> > 3) Project them from a cannon. >> > >> > In an intuitionistic logic, the following simplification is possible: >> > >> > 1) Use your intuition. >> > >> > >> > *Appendix C: Homotopy Syntax >> > >> > Given that we already are using the full unicode set, what syntax >> > should we use to distinguish paths and homotopies? At first, I thought >> > we could avoid providing any syntax for homotopies at all. Haskell is >> > a language with type inference, so we should just be able to infer >> > paths and homotopies behind the scenes by adding homotopies to the >> > type system. That's a very nice answer in theory. But in the real >> > world, when we're writing code that solves actual problems, >> > theoretical niceties break down. What if a user wants to use a >> > nonstandard homotopy? >> > >> > Why should we stop them just because we're too lazy to come up with a >> > good syntax? I then realized that we keep running out of syntax >> > because we've limited ourselves to unicode. Instead, I propose we add >> > a potentially infinite universe of identifiers: youtube videos. For >> > example, the higher inductive type for a circle can be written as: >> > >> > homotopyType http://www.youtube.com/watch?v=dQw4w9WgXcQ where >> > Base ::: http://www.youtube.com/watch?v=dQw4w9WgXcQ >> > Loop ::: http://www.youtube.com/watch?v=J---aiyznGQ Base Base >> > >> > Note that the urls do not use SSL. For portability reasons, I propose >> > that SSL only be enabled as an optional extension. >> > >> > _______________________________________________ >> > Glasgow-haskell-users mailing list >> > Glasgow-haskell-users(a)haskell.org >> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -- > Gregory Collins <greg(a)gregorycollins.net>

5 5

cabal install version selection
by Christian Höner zu Siederdissen 02 Apr '12

02 Apr '12

Hi everybody, I fail to remember or re-google the package version selection for cabal, if no version constraints are given. If I depend on "iteratee", and there are no constraints, does it take the lowest version? When I pushed the newest version of the RNAFold package, the log showed iteratee-0.1.0 to be used, which failed of course: http://hackage.haskell.org/packages/archive/RNAFold/1.99.1.0/logs/failure/g… It got really weird, however when I saw that the dependency BiobaseVienna-0.2.2.3, which is the one actually using iteratee, was built correctly. Of course, seeing the error of my way, I have started adding more version constraints to every package I maintain. Gruss, Christian

3 2

Code review for new primop's CMM code?
by Ryan Newton 30 Mar '12

30 Mar '12

Perhaps a question mark is more appropriate in the title. It is a code review I am seeking, not one on offer ;-). On Thu, Mar 29, 2012 at 12:56 AM, Ryan Newton <rrnewton(a)gmail.com> wrote: > Hi all, > > In preparation for students working on concurrent data structures GSOC(s), > I wanted to make sure they could count on CAS for array elements as well as > IORefs. The following patch represents my first attempt: > > > https://github.com/rrnewton/ghc/commit/18ed460be111b47a759486677960093d71ee… > > It passes a simple test [Appendix 2 below], but I am very unsure as to > whether the GC write barrier is correct. Could someone do a code-review on > the following few lines of CMM: > > if (GET_INFO(arr) == stg_MUT_ARR_PTRS_CLEAN_info) { > SET_HDR(arr, stg_MUT_ARR_PTRS_DIRTY_info, CCCS); > len = StgMutArrPtrs_ptrs(arr); > // The write barrier. We must write a byte into the mark table: > I8[arr + SIZEOF_StgMutArrPtrs + WDS(len) + (ind >> > MUT_ARR_PTRS_CARD_BITS )] = 1; > } > > Thanks, > -Ryan > > -- Appendix 1: First draft code CMM definition for casArray# > ------------------------------------------------------------------- > stg_casArrayzh > /* MutableArray# s a -> Int# -> a -> a -> State# s -> (# State# s, Int#, a > #) */ > { > W_ arr, p, ind, old, new, h, len; > arr = R1; // anything else? > ind = R2; > old = R3; > new = R4; > > p = arr + SIZEOF_StgMutArrPtrs + WDS(ind); > (h) = foreign "C" cas(p, old, new) []; > > if (h != old) { > // Failure, return what was there instead of 'old': > RET_NP(1,h); > } else { > // Compare and Swap Succeeded: > if (GET_INFO(arr) == stg_MUT_ARR_PTRS_CLEAN_info) { > SET_HDR(arr, stg_MUT_ARR_PTRS_DIRTY_info, CCCS); > len = StgMutArrPtrs_ptrs(arr); > // The write barrier. We must write a byte into the mark table: > I8[arr + SIZEOF_StgMutArrPtrs + WDS(len) + (ind >> > MUT_ARR_PTRS_CARD_BITS )] = 1; > } > RET_NP(0,h); > } > } > > -- Appendix 2: Simple test file; when run it should print: > ------------------------------------------------------------------- > -- Perform a CAS within a MutableArray# > -- 1st try should succeed: (True,33) > -- 2nd should fail: (False,44) > -- Printing array: > -- 33 33 33 44 33 > -- Done. > ------------------------------------------------------------------- > {-# Language MagicHash, UnboxedTuples #-} > > import GHC.IO > import GHC.IORef > import GHC.ST > import GHC.STRef > import GHC.Prim > import GHC.Base > import Data.Primitive.Array > import Control.Monad > > ------------------------------------------------------------------------ > > -- -- | Write a value to the array at the given index: > casArrayST :: MutableArray s a -> Int -> a -> a -> ST s (Bool, a) > casArrayST (MutableArray arr#) (I# i#) old new = ST$ \s1# -> > case casArray# arr# i# old new s1# of > (# s2#, x#, res #) -> (# s2#, (x# ==# 0#, res) #) > > ------------------------------------------------------------------------ > {-# NOINLINE mynum #-} > mynum :: Int > mynum = 33 > > main = do > putStrLn "Perform a CAS within a MutableArray#" > arr <- newArray 5 mynum > > res <- stToIO$ casArrayST arr 3 mynum 44 > res2 <- stToIO$ casArrayST arr 3 mynum 44 > putStrLn$ " 1st try should succeed: "++show res > putStrLn$ "2nd should fail: "++show res2 > > putStrLn "Printing array:" > forM_ [0..4] $ \ i -> do > x <- readArray arr i > putStr (" "++show x) > putStrLn "" > putStrLn "Done." > >

1 0

[sajith@gmail.com: Google Summer of Code: a NUMA wishlist!]
by Sajith T S 29 Mar '12

29 Mar '12

Greetings, I originally posted this message to haskell-cafe, and was told that this list might be a more appropriate place to seek feedback. I'm curious to know what people think of this proposal. Thanks in advance! Regards, Sajith. ----- Forwarded message from Sajith T S <sajith(a)gmail.com> ----- Date: Sun, 25 Mar 2012 22:49:52 -0400 From: Sajith T S <sajith(a)gmail.com> To: The Haskell Cafe <haskell-cafe(a)haskell.org> Subject: Google Summer of Code: a NUMA wishlist! Dear Cafe, It's last minute-ish to bring this up (in my part of the world it's still March 25), but graduate students are famously a busy and lazy lot. :) I study at Indiana University Bloomington, and I wish to propose^W rush in this proposal and solicit feedback, mentors, etc while I can. Since student application deadline is April 6, I figure we can beat this into a real proposal's shape by then. This probably also falls on the naive and ambitious side of things, and I might not even know what I'm talking about, but let's see! That's the idea of proposal, yes? Broadly, idea is to improve support for NUMA systems. Specifically: -- Real physical processor affinity with forkOn [1]. Can we fire all CPUs if we want to? (Currently, the number passed to forkOn is interpreted as number modulo the value returned by getNumCapabilities [2]). -- Also kind of associated with the above: when launching processes, we might want to specify a list of CPUs rather than the number of CPUs. Say, a -N [0,1,3] flag rather than -N 3 flag. This shall enable us to gawk at real pretty htop [3] output. -- From a very recent discussion on parallel-haskell [4], we learn that RTS' NUMA support could be improved. The hypothesis is that allocating nurseries per Capability might be a better plan than using global pool. We might borrow/steal ideas from hwloc [5] for this. -- Finally, a logging/monitoring infrastructure to verify assumptions and determine if/how local work stays. (I would like to acknowledge my fellow conspirators and leave them unnamed, lest they shall be embarrassed by my... naivete.) Thanks, Sajith. [1] http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurre… [2] http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurre… [3] http://htop.sourceforge.net/ [4] http://groups.google.com/group/parallel-haskell/browse_thread/thread/7ec1eb… [5] http://www.open-mpi.org/projects/hwloc/ -- "the lyf so short, the craft so long to lerne." -- Chaucer. ----- End forwarded message ----- -- "the lyf so short, the craft so long to lerne." -- Chaucer.

3 9