- Glasgow-haskell-users

RE: Native Threads in the RTS
by Simon Marlow 29 Nov '02

29 Nov '02

> Or, we can adopt a much weaker semantics than Wolfgang > intended and have: > > $0 <= bindees(f) - uses(f)$ > > This would allow several currently running, active Haskell threads to > all be bound to the same foreign thread. When any of these threads > makes a foreign call, the other threads could all keep running and > they would only block if they too tried to make foreign calls. From > an implementation point of view, this requires: > > 1) That foreign threads are _not_ used to execute Haskell code. > > 2) That we maintain a lock on foreign threads so that only one > Haskell thread tries to use it at a time. > > I see two potential problems with this (but would like to hear which, > if either, dominates your thoughts): > > 1) If foreign threads cannot be used to execute Haskell code, foreign > calls require (OS-level) context switches which are expensive. > > 2) Adding an implicit lock to foreign calls might surprise > programmers. Another problem, from an implementation point of view, is that we would have to surround "unsafe" foreign calls with a lot of context-switching gumph, in case the calling Haskell thread is bound to a native thread. I really think we don't want to do this. The "thread groups" idea is similar, but only allows one of the Haskell threads in a group to be executing at any one time. This means you can run the Haskell thread using its native thread, and you don't have to context switch on every C call. However, I believe it would be tricky to implement this correctly in the scheduler (not impossible, just tricky and hard to test). Cheers, Simon

3 2

RE: Native Threads in the RTS
by Simon Marlow 29 Nov '02

29 Nov '02

> > This is all getting highly confusing, as it seems we're working with > > different ideas of what's on the table. Alastair: you seem to be > > working on your own proposal - could you write it down either as a > > complete proposal or diffs to Wolfgangs? > > I did. You sent comments on it and I sent back a cleaned up version. > Here it is again. My apologies - I didn't notice you'd already proposed 'foreign import bound' so I thought you were working with a definition that we hadn't seen. Never mind. Cheers, Simon

1 0

RE: Native Threads in the RTS
by Simon Marlow 29 Nov '02

29 Nov '02

> Simon Marlow: > > > Another problem, from an implementation point of view, is that we > > would have to surround "unsafe" foreign calls with a lot of > > context-switching gumph, in case the calling Haskell thread is bound > > to a native thread. I really think we don't want to do this. > > Note that you only have to do this to foreign calls of the form: > > foreign import bound foo :: ... > > since any other calls are free to use whatever thread they feel like. Umm, this is new... the proposal doesn't have "foreign import bound", although it does have a parenthetical comment that indicates that it might be considered: There are now two kinds of foreign exported [and foreign import wrapped] functions: bound and free. and later on: When a foreign imported function is invoked [by Haskell code], the foreign code is executed in the native thread associated with the current Haskell thread, ... So currently the idea is that every foreign import is executed by the native thread bound to the current Haskell thread, if any. This is all getting highly confusing, as it seems we're working with different ideas of what's on the table. Alastair: you seem to be working on your own proposal - could you write it down either as a complete proposal or diffs to Wolfgangs? Cheers, Simon

2 1

RE: incremental linking?
by Simon Marlow 28 Nov '02

28 Nov '02

> > > More fun with Haskell-in-the-large: linking time has become the > > > main bottleneck in our development cycle. The standard solution > > > would be to use an incremental linker, but it seems that gnu does > > > not yet support this:-| > > > > Hmm, I've never heard of linking being a bottleneck. Even > GHC itself > > links in about 3-4 seconds here. One common problem is > that linking on > > a network filesystem takes a *lot* longer than linking > objects from a > > local disk. It's always a good idea to keep the build tree > on the local > > disk, even if the sources are NFS-mounted. > > I also have this problem, and while being on a local disk > rather than NFS > helps, it doesn't help all that much. For large projects, I > usually have > time to get a cup of coffee while linking (admittedly only four doors > away, but...). When on NFS, I have time to go to the local > coffeehouse... Ok, it looks like we need to investigate this. NFS isn't the problem in itself: I realised that our GHC installation is NFS-mounted on the machine I tried the experiment on, and it makes very little difference (although Linux's NFS implementation is a bit fast & loose when it comes to caching, I seem to recall). Those who experience long link times (longer than a few seconds), please reply with your - platform / OS version - versions of relevent things (GHC, GCC, binutils). - time to link 'main = print "hello"'. Does starting up GHCi take a long time? Would someone like to strace (or truss, or ktrace or whatever) the ld process and see what it is doing for all that time. Is it CPU or I/O bound? Cheers, Simon

2 1

RE: Native Threads in the RTS
by Simon Marlow 28 Nov '02

28 Nov '02

Simon P.J. writes: > Can you give an example of when a native thread is associated > with more than one Haskell thread? I gave an example in my previous message. It's when a bound Haskell thread makes a foreign call which re-enters Haskell via a bound foreign export. > You don't say (and I'm not sure if you mean) > > If a bound native thread blocks, all of its associated Haskell > threads are blocked too "When Bagpuss goes to sleep, all his friends go to sleep too." :-) (apologies to those who never watched British childrens TV in the 70s). Actually, for any given native thread, only one of its bound Haskell threads can be runnable, the others must all be blocked waiting on the result of a foreign call. So you don't really have to worry about a native thread being bound to multiple Haskell threads; this would be quite tricky to implement in the scheduler anyway. Cheers, Simon

1 0

RE: Template Haskell
by Simon Peyton-Jones 28 Nov '02

28 Nov '02

If you look in the manual you'll see that it says you can only compile-time-call a function that is in a separate module. So put 'pr/gen/parse' in a separate module and you'll be fine. The manual may not be very clear... pls help me improve it. S | -----Original Message----- | From: Mike Thomas [mailto:miketh@brisbane.paradigmgeo.com] | Sent: 27 November 2002 06:19 | To: glasgow-haskell-users(a)haskell.org | Subject: Template Haskell | | Hi there. | | Could somebody please let me know where I've gone wrong in the program below | (yesterday's CVS HEAD stage 3 compiler on Windows)? | | ------------- TH - printf.hs --- | | module Main where | | import Language.Haskell.THSyntax | | data Format = D | S | L String | | main = putStrLn ( $(pr "Hello") ) | | parse :: String -> [Format] | parse s = [ L s ] | | gen :: [Format] -> Expr | gen [D] = [| \n -> show n |] | gen [S] = [| \s -> s |] | gen [L s] = string s | | pr :: String -> Expr | pr s = gen (parse s) | | | ------------- Command Line ----- | | /c/cvs/i386-unknown-mingw32/stage3/ghc/compiler/ghc-inplace -fglasgow-exts - | package haskell-src printf.hs -o printf.exe | | ------------- GHC output--------- | | printf.hs:7: | Stage error: `pr' is bound at stage 1 but used at stage 0 | In the first argument of `putStrLn', namely `($[splice](pr "Hello"))' | In a right-hand side of function `main': | putStrLn ($[splice](pr "Hello")) | In the definition of `main': main = putStrLn ($[splice](pr "Hello")) | | ----------------------------------- | | Thanks | | Mike Thomas. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

RE: incremental linking?
by Simon Marlow 28 Nov '02

28 Nov '02

> On Wed, Nov 27, 2002 at 09:50:56AM -0000, Simon Marlow wrote: > > > > More fun with Haskell-in-the-large: linking time has become the > > > main bottleneck in our development cycle. The standard solution > > > would be to use an incremental linker, but it seems that gnu does > > > not yet support this:-| > > > > Hmm, I've never heard of linking being a bottleneck. > > The runtime loader stuff I'm working on[1] takes around 10 > seconds to compile ... and 3 minutes to link it with libHSbase > and libHSrts. (This is on a 500MHz PIII). Linking is a huge > bottleneck once you start linking in the Haskell libraries; ld > takes up enormous amounts of CPU time resolving symbols, > I think. > > 1. > http://www.algorithm.com.au/wiki/hacking/haske> ll.ghc_runtime_loading 3 minutes???!! I just downloaded your example code, did './configure && make' and the link step took about 3 seconds. This is also on a 500MHz PIII. Are you sure you're not getting libHSbase over NFS? There may be something that ld is doing that causes a lot of NFS traffic. Cheers, Simon

3 2

Re: Native Threads in the RTS
by Wolfgang Thaller 27 Nov '02

27 Nov '02

Simon Marlow wrote: > I don't see the problem with forking a new Haskell thread for each > foreign export, and associating it with the current native thread if > the > foreign export is marked "bound". It does mean we can get multiple > Haskell threads bound to the same native thread, but only one can be > runnable at any one time (this is an important invariant from the point > of view of the implementation, I believe). Of course, you're right. Simon Peyton-Jones wrote: > I offer myself as such a guinea pig. I'm afraid I don't understand it > yet. It's hard to describe precisely. Comments below. Yes, I do need a guinea pig ;-) . I really have trouble expressing my ideas accurately, and I keep changing them. > Better start with some definitions, for > 'Haskell thread' > and 'native thread' > > I think I know what you mean, but better to be sure. Well, yes. I didn't manage to come up with a decent definition for it yet. I intend "native thread" to be the thing you get using pthread_create on unix, and "Haskell thread" to be the same thing as it currently is in the GHC RTS. Can anyone think of a way of defining that in a way that is accurate, general and understandable? > | If there is one, this Haskell thread is used to execute the callback. > > OK, so this is where I get completely confused. A Haskell thread is > not > (currently) an execution platform. Oops... The best way to confuse other people is to be confused yourself ;-) --- I had a slight misconception about the RTS there --- I think I've corrected that. =============================== Threads Proposal, version 4 Goals ~~~~~ Since foreign libraries sometimes exploit thread local state, it is necessary to provide some control over which thread is used to execute foreign code. In particular, it is important that it should be possible for Haskell code to arrange that a sequence of calls to a given library are performed by the same native thread and that if an external library calls into Haskell, then any outgoing calls from Haskell are performed by the same native thread. This specification is intended to be implementable both by multithreaded Haskell implementations and by single-threaded implementations and so it does not comment on which particular OS thread is used to execute Haskell code. Definitions ~~~~~~~~~~~ A native thread (aka OS thread) is a thread as defined by the operating system. A Haskell thread is [*** FIXME - How shall I put this? ***] the thing you see from Haskell land. Design ~~~~~~ Haskell threads may be associated at thread creation time with either zero or one native threads. Each Native thread is associated with zero or more native threads. If a native thread is associated with one or more Haskell threads, exactly one of the following must be true: *) Exactly one Haskell thread associated with the native thread is executing. *) The native thread is executing foreign code. *) The native thread and all Haskell threads associated with it are blocked. The thread that main runs in, threads created using forkIO and threads created for running finalizers or signal handlers are not necessarily associated with a native thread. However, an implementation might choose to do so. There are now two kinds of foreign exported [and foreign import wrapped] functions: bound and free. The FFI syntax should be extended appropriately [which of the two should be the default, if any?]. When a "bound" foreign exported function is invoked [by foreign code], a new Haskell thread is created and associated with the native thread. The new associated Haskell thread is then used to execute the callback. When a "free" foreign exported function is invoked, the implementation may freely choose what kind of Haskell thread the function is executed in. It is not specified whether this thread is associated with a particular OS thread or not. When a foreign imported function is invoked [by Haskell code], the foreign code is executed in the native thread associated with the current Haskell thread, if an association exists. If the current Haskell thread is not associated to a native thread, the implementation may freely decide which thread to run the foreign function in. The existing distinction between unsafe, safe and threadsafe calls remains unchanged. A new library routine, forkNativeThread :: IO () -> IO ThreadID, should spawn a new Haskell Thread (like forkIO) and associate it with a new native thread (forkIO is not guaranteed to do this). It may be implemented using the FFI and an OS-specific thread creation routine. It would just pass a "bound" callback as an entry point for a new OS thread. Issues ~~~~~~ Finalizers and signal handlers cannot be associated with a particular native thread. If they have to trigger an action in a particular native thread, a message has to be sent manually (via MVars and friends) to the Haskell thread associated with the native thread in question. This introduces a change in the syntax for foreign export and foreign import "wrapper" declarations (a bound/free specifier is added). I think we should have a default option here. I'm not sure which, however. Also, the objection that "bound" and "free" can be confused with the lambda calculus terms still holds.

1 0

RE: incremental linking?
by Simon Marlow 27 Nov '02

27 Nov '02

> More fun with Haskell-in-the-large: linking time has become the > main bottleneck in our development cycle. The standard solution > would be to use an incremental linker, but it seems that gnu does > not yet support this:-| Hmm, I've never heard of linking being a bottleneck. Even GHC itself links in about 3-4 seconds here. One common problem is that linking on a network filesystem takes a *lot* longer than linking objects from a local disk. It's always a good idea to keep the build tree on the local disk, even if the sources are NFS-mounted. > Alternative a: use someone else's incremental linker, e.g., Sun's > ild (ghc's -pgml option appears to have its own idea about option > formatting, btw) - this doesn't seem to work - should it? You'd probably want to call the incremental linker directly rather than using GHC - what exactly does it do, BTW? What files does it generate? > Alternative b: convince ghc to link objects in stages, e.g., on a > per-directory basis - gnu's ld seems to support at least this kind > of partial linking (-i/-r). Not quite as nice as a fully incremental > linker, but would probably save our day.. Yes, this works fine. We use it to build the libraries for GHCi. Cheers, Simon

3 2

RE: incremental linking?
by Simon Marlow 27 Nov '02

27 Nov '02

> Unfortunately, we're not talking seconds, but coffee-breaks of > linking times on our Sun (yes, the stuff is in the range of a large > compiler - we're fortunate enough to be able to build on rather > substantial third-party packages, think haskell-in-haskell frontend > distributed over unusually many modules + strategic traversal > support + our own code). > > And yes, I was worried about NFS-mounting first, especially since > linking on our Sun takes even longer than on our PCs (long breaks > instead of short ones;-), but moving .hi and .o to local tmp-space > didn't speed things up (then again, it's a large machine, and our > disk setup is likely to be more complex than I know - I'll have to > check with our admins). It does sound like it's taking rather too long, I'd investigate further. > > > Alternative a: use someone else's incremental linker, e.g., Sun's > > > ild (ghc's -pgml option appears to have its own idea about option > > > formatting, btw) - this doesn't seem to work - should it? > > > > You'd probably want to call the incremental linker directly > rather than > > using GHC - what exactly does it do, BTW? What files does > it generate? > > Calling it via GHC seemed the best way to ensure that it gets > everything it needs (what else would be the purpose of -pgml?). Ah I see - it's just like a normal linker, except it takes a previous version of the executable and attempts to just re-link the bits it needs? GHC has some built-in assumptions about the linker: it must accept gcc-style command line options. This probably isn't true of the incremental linker, so you could either (a) write a wrapper around it, or (b) arrange to call the incremental linker through gcc. I can't remember if (b) is possible, but a quick scan of the docs suggested that gcc doesn't have the equivalent of -pgml so (b) might be out. BTW, -pgml is usually just used to select a different version of gcc (as with -pgmc). > > Alternative b: convince ghc to link objects in stages, e.g., on a > > per-directory basis - gnu's ld seems to support at least this kind > > of partial linking (-i/-r). Not quite as nice as a fully incremental > > linker, but would probably save our day.. > > Yes, this works fine. We use it to build the libraries for GHCi. > > Presumably directed via Makefiles? > Could this please be automated for ghc --make? It's easy: $ ld -r -o All.o A.o B.o C.o ... Cheers, Simon

1 0