June 2002 - Glasgow-haskell-users

Status of GHC with gcc 3.x ?
by C.Reinke 20 Jun '02

20 Jun '02

What is the status of GHC with gcc 3.x (on Sun)? The 5.02.3 ANNOUNCE said "now works with gcc 3.x", but we still seem to have problems here (having switched to gcc 3.1): > uname -a SunOS myrtle 5.8 Generic_108528-14 sun4u sparc SUNW,Ultra-4 > gcc --version gcc (GCC) 3.1 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > ghc-5.02.3 --version The Glorious Glasgow Haskell Compilation System, version 5.02.3 > cat hello.hs module Main where main = putStrLn "Hassle?" > ghc-5.02.3 -O hello.hs > a.out Bus error (core dumped) Both compilation via an older gcc and compilation without -O produce working executables. Is this a know issue? Fixed in 5.04?-) Claus

1 0

RE: [HOpenGL] HOpenGL and --enable-threaded-rts
by Simon Peyton-Jones 20 Jun '02

20 Jun '02

| > Another possibility that Simon and I have discussed is to provide a | > sort of forkIO that says "create a Haskell thread | permanently bound to | > an OS thread". Much more expensive than normal forkIO. More like | > having a permanent secretary at your beck and call, rather than the | > services of a typist from the typing pool. | | So calling C from this thread would happen inside that OS thread, | callbacks would happen in that OS thread, and the RTS would | continue to | run while that OS thread is blocked? | How much overhead would that create? I wouldn't like much additional | overhead for my OpenGL programs :-(. Would this require an OS | mutex lock | for every heap allocation, or is there a better way? The idea would be that we'd keep the invariant that only one OS thread can be executing Haskell at any moment. So no mutex locks on allocation or thunk entry. Suppose we call one of a Haskell-thread-with-a-dedicated-OS-thread a "Haskell super-thread". At any moment, a vanilla OS worker thread is executing Haskell threads. It keeps picking a new Haskell thread, running it for a while, then picking a new one. OK, so it decides that the next Haskell thread to run is a super-thread. The OS thread hands off control to the dedicated OS thread bound to the super-thread. The dedicated OS thread runs the super-thread. When its time slice is up, the dedicated OS thread picks a new Haskell thread to run, but it doesn't run it! No, it hands off control to a vanilla OS worker thread instead. The intention is zero overhead if there are no super threads. There'll be an OS thread switch whenever the super-thread is scheduled, but that's life. Havn't worked out the details, but it looks possible. Sigbjorn: any comments? You'd implemented all this thread-y stuff. Simon

4 3

RE: [HOpenGL] HOpenGL and --enable-threaded-rts
by Simon Peyton-Jones 20 Jun '02

20 Jun '02

Simon and I have discussed this multi-threading question a bit. This message tries to summarise the story as we understand it. GHC's approach to threading ~~~~~~~~~~~~~~~~~~~~ Make certain you read the "Supporting multi-threaded inter-operation" section of the GHC commentary http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/rts-libs/multi-thread. html The current GHC model has the basic assumption that OS threads are inter-changeable. One Haskell thread may be executed by one OS thread or by many; you just can't tell. There is a good reason for this: the current OS thread may block in some I/O call (getChar, say), and we don't want that to block all Haskell threads. If you want all Haskell threads executed by a single OS thread, then you don't want --enable-threaded-rts, and your I/O calls may block all Haskell threads. There is no notion of a Haskell-thread-local location right now. We don't know how to make it type-safe. If you want that, you have to define your own environment monad, which isn't too hard. Or use implicit parameters, also not hard. GLUT's approach to threading ~~~~~~~~~~~~~~~~~~~~~ Simon and I don't understand GLUT's requirements at all clearly. Why is the context thread-local? Because different threads can have different contexts? Do you really need that? If not, would it suffice to make all the threads have (a pointer to) the same context)? Much the tidiest thing is to make the context an explicit parameter to GLUT calls. Or, if there is only one context of interest, keep it in a process-global location (not thread-local) and, sigh, heave it into the thread-local location before every GLUT call. In short, we don't understand GLUT well enough to be able to propose a solution. I hope that the above remarks may help the GLUT experts understand GHC well enough to write down a summary of what is going on. Try not to rely on someone having read all the past mail! Simon | -----Original Message----- | From: Sven Panne [mailto:Sven_Panne@BetaResearch.de] | Sent: 18 June 2002 15:06 | To: hopengl(a)haskell.org | Cc: GHC List | Subject: Re: [HOpenGL] HOpenGL and --enable-threaded-rts | | | Simon Marlow wrote: | > [...] a given Haskell thread can even migrate from one OS thread to | > another during its execution. | | Uh, oh! %-( Under which circumstances exactly? I fear this | will give loads of fun with many C libraries out there, so | it's important to know... | | Cheers, | S. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

2 1

RE: simple backtraces in ghci
by Simon Peyton-Jones 20 Jun '02

20 Jun '02

| numbers for you, if you want. I was wondering if there was | any chance of something like this getting hard coded in. I | would want this turned off by default for compiled code, but | for code loaded in ghci, I find it very useful... see "Template metaprogramming in Haskell" on my home page, Section 8.1. Not implemented yet, but it's coming. S

1 0

RE: [HOpenGL] HOpenGL and --enable-threaded-rts
by Simon Peyton-Jones 20 Jun '02

20 Jun '02

| My proposal is to leave dealing with thread-local state to | the library | binding (in this case, HOpenGL). This requires just a little support | from the RTS. The library binding would have to include C-language | routines that get called by the RTS at certain points: | * when the RTS starts executing Haskell code in an OS thread | (grabCapability) | * when the RTS stops executing Haskell code in an OS thread | (releaseCapability) | * when the RTS is about to spawn a new thread in response to | a callback (scheduleThread_). That might be ok provided there was a single context "in play". In effect, your proposal amounts to keeping a process-global context, and zapping it into the Current Haskell Worker Thread whenever it grabs a capability, correct? But if there's a single global context, why does it need to be thread-local? Another possibility that Simon and I have discussed is to provide a sort of forkIO that says "create a Haskell thread permanently bound to an OS thread". Much more expensive than normal forkIO. More like having a permanent secretary at your beck and call, rather than the services of a typist from the typing pool. Simon

3 2

RE: [HOpenGL] HOpenGL and --enable-threaded-rts
by Simon Marlow 20 Jun '02

20 Jun '02

> This sounds like a lot of work and a porting nightmare (what do you > mean Linux/Win32/HPUX/... doesn't have thread manipulation function X, > it's available on FreeBSD/Win32/... What if there are other forms > of thread-local state (e.g., errno)? What about setjmp/longjmp?). Yes, these are all problems. However, there is a nice abstraction of the OS thread API in GHC's RTS, thanks to Sigbjorn. So I'm sure this API could be extended to include some thread-local state operations. > The only viable solution I can see is to provide a way to capture the > calling thread (as a first class entity) when you call into Haskell > and to explicitly specify whcih thread to use when you call out from > Haskell. (Hmmm, sounds like callcc for C :-)) The trouble is, that is *way* too much overhead for a C call. HOpenGL does lots of these, and I strongly suspect that adding a full OS-thread context switch (well two, including the return) for each one would be a killer. Cheers, Simon

5 6

when is compilation necessary
by Hal Daume III 19 Jun '02

19 Jun '02

suppose i have three modules: > module Foo(foo) where > foo x = x + 1 > module Bar(bar) where > import Foo > bar x = foo (x+1) > module Main(main) where > import Bar > main = print (foo 5) Now, suppose I change Foo.hs so that "foo x = x + 2". If I ghc --make on Main, it will build Foo, then Bar, then Main, then link. Is all of this necessary or can I (manually) just rebuild Foo and then relink? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

New MacOS X snapshot
by Wolfgang Thaller 19 Jun '02

19 Jun '02

I've uploaded a new snapshot of GHC for MacOS X at http://www.uni-graz.at/imawww/haskell/GHC.dmg It's a few days behind current CVS, but it also includes a change that I haven't yet commited to CVS (using a framework named HaskellSupport.framework which contains libdl and libgmp), The main reason I've made a snapshot now is that someone asked me for help with the old snapshot from March... Is it possible to announce this on the GHC news page so that people don't accidentally download the old snapshot (which should be removed from the haskell.org server)? Cheers, Wolfgang

1 0

simple backtraces in ghci
by Hal Daume III 19 Jun '02

19 Jun '02

Hi all, Currently, I've been using the following hack to do backtraces: namedEx :: String -> a -> a namedEx fname x = unsafePerformIO $ Exception.catch (x `seq` return x) (\ex -> ioError (UserError (fname ++ " : " ++ show ex))) At which point, if I have a function foo ... = ..., I change it to foo ... = namedEx "foo" $ ... For instance: foo l = namedEx "foo" $ if head (bar l) == 1 then True else foo (tail l) bar l = namedEx "bar" $ head l This way I effectively get a backtrace as is offered in Java, SML/NJ, Python and countless other languages. I know that GHC is somewhat intelligent about handing Exception.assert, where it will automatically insert module names and line numbers for you, if you want. I was wondering if there was any chance of something like this getting hard coded in. I would want this turned off by default for compiled code, but for code loaded in ghci, I find it very useful... - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

RE: Giving profiled object files a different extension (was: RE: Profiling suggestion)
by Simon Marlow 19 Jun '02

19 Jun '02

> Hal Daume III <hdaume(a)ISI.EDU> writes: > > > For what it's worth (I don't know whether defaulting -prof > to mean '-prof > > -osuf p_o -hisuf p_hi' was going to be adopted or not), but > I'm against > > it. > > Yep. I don't remember if I was the one raising the issue or just > participating, but I'm perfectly satisfied with the -osuf and -hisuf > options (which I hadn't discovered at the time). > > (I still advocate generating a warning/error when GHC is used to link > profiling and non-profiling object files, though. But as it never > happens anymore, it's not a big deal.) Thanks for the feedback. I don't think we'll change the default, but we will add some kind of consistency checking at some point. Cheers, Sim

1 0