- Glasgow-haskell-users

RE: first stab at -ffunction-sections
by Simon Marlow 19 Nov '02

19 Nov '02

> On Mon, Nov 18, 2002 at 11:55:27AM -0000, Simon Marlow wrote: > > What exactly are you trying to use -ffunction-sections for? > I'm pretty > > sure it won't work as things stand currently, unless you > can guarantee > > to be able to find a text/data boundary symbol for the > garbage collector > > (currently it has to be able to distinguish text from data, > we're in the > > process of lifting the restriction but it's a lot of work). > > Trying to garbage-collect unused functions to reduce the size of the > .text section. You should be aware that -split-objs (the trick we use to build our libraries in lots of little bits) gets most of the benefit that you'd get from using -ffunction-sections. You might get slightly more fine-grained discarding of code with -ffunction-sections, but the effect won't be dramatic (I'm guessing). Also there's the issues of telling the garbage collector and the mangler about it. However, it would be nice to be able to use -ffunction-sections/--gc-sections instead of -split-objs. It's been at the back of my mind to have a go at this someday... Cheers, Simon

2 1

Re: unsafePerformIO and IORefs
by Ashley Yakeley 18 Nov '02

18 Nov '02

At 2002-11-18 11:05, Sven Panne wrote: >global :: a -> IORef a >global a = unsafePerformIO (newIORef a) This is useful, you can do this with it: ref = global Nothing convert :: a -> IO b convert a = do writeIORef ref (Just a) Just b <- readIORef ref return b -- Ashley Yakeley, Seattle WA

2 1

unsafePerformIO and IORefs
by Nicolas Oury 18 Nov '02

18 Nov '02

I want to write something like type State a = IORef a newState :: a -> State a newState v = unsafePerformIO (newIORef v) But I don't want the compileer to inline this nor to inline any application of this. {#NOINLINE newState#} But how can I stop this function to be inlined when applied for example : .... let x = newState 0 in {... code where x is used twice ...} How to be sure that x isn't inlined and that all occurences of x are pointing to the same memory place ? Best regards, Nicolas Oury

4 3

RE: Class/Implicit Param/Module Interface bug
by Simon Peyton-Jones 18 Nov '02

18 Nov '02

These bugs are now fixed in the HEAD. I hope the fixes will make it into 5.04.2 as well. Thanks for identifying them. It was all horribly bogus before. Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 13 November 2002 13:46 | To: Simon Peyton-Jones | Cc: GHC List | Subject: Re: Class/Implicit Param/Module Interface bug | | Actually it's worse than that. This crashes: | | module Main where | { | import A; | | main = let {?p="test"} in putStrLn f; -- BUG: this crashes | -- main = let {?p="test"} in putStrLn g; -- this works | } | | | -- | Ashley Yakeley, Seattle WA

1 0

RE: Bug? [was: Implicit params]
by Simon Peyton-Jones 18 Nov '02

18 Nov '02

Now fixed in the HEAD, and will be in 5.04.2 Thanks for pointing it out. Simon | -----Original Message----- | From: Jorge Adriano [mailto:jadrian@mat.uc.pt] | Sent: 14 November 2002 21:10 | To: Iavor S. Diatchki | Cc: Haskell Cafe; glasgow-haskell-users(a)haskell.org | Subject: Bug? [was: Implicit params] | | On Thursday 14 November 2002 18:47, Iavor S. Diatchki wrote: | > hello, | > | > > Well, actually you must be right since the pure field defines a pure | > > (projection) function... Hmmm, ok, can someone explain this to me, | > > | > > data E s = E{ | > > refi :: STRef s Int, | > > refc :: STRef s Char, | > > m :: Int | > > } | > > | > > -- this is fine, obviously... | > > pure :: E s -> Int | > > pure e = m e | > > | > > -- but this is not... | > > pure2 :: (?e :: E s) => Int | > > pure2 = m (?e) | > > | > > Why exactly isn't this allowed? What is the workaround? | > > Error msg: | > > ------------------------------------------------------------------------ | > > Ambiguous constraint `?e :: E s' | > > At least one of the forall'd type variables mentioned by the | > > constraint | > > must be reachable from the type after the '=>' | > > In the type: forall s. (?e :: E s) => Int | > > While checking the type signature for `pure2' | > > Failed, modules loaded: none. | > > ------------------------------------------------------------------------ - | > >- | > | > this seems like a bug in GHC. Hugs is happy with it. The "s" in the | > pure2 signature is not ambiguous because it is determined when you give | > the value of the implicit parameter. in fact the way i think about | > implicit parameters is simply as a nice notation for computations in the | > environment monad, so in my mind the above two definitions are pretty | > much the same. | | Thanks Iavor! | GHC people, can you confirm this, Is it a bug? I'm using Ghc 5.0.4 SuSE rpms. | Is there a workaround? | | Thanks, | J.A. | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: first stab at -ffunction-sections
by Simon Marlow 18 Nov '02

18 Nov '02

> This could be an artifact of the -j64 (BTW, has anyone else > noticed the > makefiles can only keep 5 or 6 cpus busy at a time much of the time, > and often less?). There are probably still bugs in our build system w.r.t. make -jN. I occasionally use it to build the compiler, but rarely any other parts of the system. What exactly are you trying to use -ffunction-sections for? I'm pretty sure it won't work as things stand currently, unless you can guarantee to be able to find a text/data boundary symbol for the garbage collector (currently it has to be able to distinguish text from data, we're in the process of lifting the restriction but it's a lot of work). Cheers, Simon

1 0

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

18 Nov '02

> We can't currently allow several Haskell threads to really run > simultaneosly [e.g. on two separate processors, or preemtively > scheduled on a single processor], because they always mutate the same > global heap. Currently, GHC switches its green threads only at times > when the heap is in a defined state [not truly preemptively]. There > seems to be some SMP support in the RTS, I don't know if it ever > worked. If anyone wants to fix/finish it, that would be > great, but it's not what I'm proposing here. The SMP support is an experiment that was never finished. There are serious issues to be solved regarding reducing the locking overhead on a shared-memory heap. > My proposal is only a minimum solution intended to resolve > the inherent > incompatibility between the "threaded RTS" and libraries like OpenGL, > which require thread-local-state. I think I'm happy with that, although I don't have the whole context swapped in. That seems to be the conclusion we came to at the last discussion, though: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-June/003592. html Cheers, Simon

1 0

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

18 Nov '02

> I'm still unconvinced that the current optional > RTS support for mixed green/native threads is the right way > to go. It looks to > me like a workaround for poor OS support for really > lightweight threads. It is a workaround for the lack of truly lightweight threads at the OS level. But I don't expect that situation to change, even with the recent improvements on the Linux front. The new RedHat Linux threads folk claim to be able to create 10^5 threads in a couple of seconds, whereas we can create 10^6 threads in about that time (on an old 500MHz machine, too). Cheers, Simon

1 0

RE: Silly question about IORefs and MVars
by Simon Marlow 18 Nov '02

18 Nov '02

> I have a silly question about IORefs and MVars. > > When do we have to use MVars if a var is accessed by multiple > threads. > In fact, I wonder why IORefs updates aren't safe : > it seems that preemptive scheduling takes place during memory > allocation > and I can't see where there could be an allocation (and so a > switch) in > a read or a write of an IORef. The problem is how to read the IORef, modify its contents, and write the new value back without being preempted. You can do this easily with an MVar, but not an IORef. > Related question : how less performant is a MVar comparated to simple > ref. reading/writing an MVar is an out-of-line call, whereas the IORef operations are all inline. I don't know the figures though. Recently we added atomicModifyIORef which should allow IORefs to be used in some cases where MVars were required before. We haven't settled on the exact interface yet, though. Cheers, Simon

1 0

RE: Native Threads in the RTS
by Simon Peyton-Jones 18 Nov '02

18 Nov '02

| I propose adding something like | | forkNativeThread :: IO () -> IO () I haven't talked to Simon about this, but it sounds possible. Three thoughts. First, before doing anything like this I'd like to ask you or someone else, or a group, to write a clear exposition of what the problem is and what the solution is, to add to the GHC user manual. (If there are implementation related questions, they can go into the Commentary.) As you say, this is a topic that we have visited regularly, and it's a slippery one, so I'd like to capture it. Second, there's the question of what it really means. In particular, what if that thread forks further (Haskell, green) threads? Are they too bound to the native thread? A library you call might in principle fork threads to get its job done... Third | If a callback is entered and the current OS thread corresponds to a | native haskell thread, the callback should be executed in the current | OS thread. | Other haskell threads continue to run in the worker thread or in their | own dedicated OS thread. I'm not sure what this means. What is the "current" OS thread? Perhaps an example? Simon

1 0