July 2005 - Glasgow-haskell-users

RE: private modules
by Simon Marlow 11 Jul '05

11 Jul '05

On 11 July 2005 10:31, Wolfgang Jeltsch wrote: > I thought, I heard something about a "private modules" feature in > GHC. Was I just dreaming or is there in fact something like this. I > cannot find information about such a thing. If you use Cabal, your package can have "hidden modules" which won't be visible outside your package. Cheers, Simon

1 0

private modules
by Wolfgang Jeltsch 11 Jul '05

11 Jul '05

Hello, I thought, I heard something about a "private modules" feature in GHC. Was I just dreaming or is there in fact something like this. I cannot find information about such a thing. Best wishes, Wolfgang

1 0

RE: option for enabling generalized deriving for newtypes
by Simon Peyton-Jones 11 Jul '05

11 Jul '05

Not at the moment. There could be -- it's just one more thing to implement and document, but it's a relatively easy one. Does anyone else have an opinion? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Wolfgang Jeltsch | Sent: 10 July 2005 18:43 | To: GHC Users ML | Subject: option for enabling generalized deriving for newtypes | | Hello, | | isn't there an option for enabling just generalized deriving for newtypes | without enabling all this other stuff by using -fglasgow-exts? | | Best wishes, | Wolfgang | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

option for enabling generalized deriving for newtypes
by Wolfgang Jeltsch 10 Jul '05

10 Jul '05

Hello, isn't there an option for enabling just generalized deriving for newtypes without enabling all this other stuff by using -fglasgow-exts? Best wishes, Wolfgang

1 0

RE: Performance on amd64
by Simon Marlow 06 Jul '05

06 Jul '05

On 05 July 2005 16:25, John Skaller wrote: > On Tue, 2005-07-05 at 12:39 +0100, Simon Marlow wrote: >> On 05 July 2005 10:38, John Skaller wrote: >> >>> Can someone comment on the Debian package for Ubuntu Hoary >>> providing ghc-6.2.2 with binary for amd64? >> >> You're probably running an unregisterised build, which is going to be >> generating code at least a factor of 2 slower than a registerised >> build. You can get an up to date snapshot of 6.4.1 for Linux/x86_64 >> here: >> >> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1.20050704-x86_64-un >> known-linux.tar.bz2 > > > Thanks, downloading it now.. will try. What exactly is > a 'registered' build? An "unregisterised" build generates plain C which is compiled with a C compiler. The term "registerised" refers to a set of optimisations which require post-processing the assembly generated by the C compiler using a Perl script (affectionately known as the Evil Mangler). In particular, registerised code does real tail-calls and uses real machine registers to store the Hsakell stack and heap pointers. An "unregisterised" build is usually the first step when porting GHC to a new architecture, before support for the "registerised" optimisations is added. GHC's native code generators also generate "registerised" code. >> This build is registerised, but doesn't have the native code >> generator. > > Which would generate the best code? -fvia-C has traditionally produced slightly better code than -fasm, at least on x86. On other platforms it might be the other way around. >> I hope you're not going to conclude *anything* based on the >> performance of ackermann and tak! :-) > > Ackermann is a good test of optimisation of a recursive > function, which primarily require the smallest possible > stack frame. Of course it is only one function, more need > to be tested. > > In fact, this one test has been very good helping me get > the Felix optimiser to work well -- the raw code generated > without optimisation creates a heap closure for every function, > including ones synthesised for conditionals and matches, etc. > If I remember rightly, it took 2 hours to calculate Ack(3,6), > and I needed a friend to use a big PPC to get the result > in two hours for Ack(3,7). > > So ... you could say the Felix optimiser has improved a bit... :) Sure, it's good to look at these small benchmarks to improve aspects of our compilers, but we should never claim that results on microbenchmarks are in any way an indicator of performance on programs that people actually write. > If you would like to suggest other tests I'd be quite interested. > At the moment I'm using code from the Alioth Shootout, > simply because I can -- saves writing things in languages > I don't know (which includes Haskell unfortunately). The shootout has lots of good benchmarks, for sure. Don't restrict yourself to the small programs, though. It's still hard to get a big picture from the results - there are too many variables. I believe many of the Haskell programs in the suite can go several times faster with the right tweaks, and using the right libraries (such as a decent PackedString library). Cheers, Simon

3 2

It's bug time!
by Simon Marlow 06 Jul '05

06 Jul '05

Folks, Here at GHC HQ we've decided the bug list is getting a bit on the long side. Furthermore, we plan to put out 6.4.1 in about a month, so it seems like a good time to have a bug-squashing session. The sourceforge bug list is here: http://sourceforge.net/tracker/?group_id=8032&atid=108032 Anything that isn't explicitly assigned to someone is up for grabs, and we'd welcome further information on *any* bug, assigned or not. If you have a sourceforge login and want to be added to the dev list for GHC, let us know. Even if you don't have a sourceforge login and would like to tackle a bug, just post here. Don't pay too much attention to the priorities at the moment, although anything less than 5 we have deemed to be non-critical and not necessary for 6.4.1. Of course, feel free to yell if you disagree. After the bug squashing, we plan to have a performance-fest. We have plenty of performance issues outstanding (in fact, if you know of a specific perf problem, please submit it as a bug). Cheers, and happy hunting... Simon(s)

1 0

RE: Performance on amd64
by Simon Marlow 05 Jul '05

05 Jul '05

On 05 July 2005 10:38, John Skaller wrote: > Can someone comment on the Debian package for Ubuntu Hoary > providing ghc-6.2.2 with binary for amd64? You're probably running an unregisterised build, which is going to be generating code at least a factor of 2 slower than a registerised build. You can get an up to date snapshot of 6.4.1 for Linux/x86_64 here: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1.20050704-x86_64-un known-linux.tar.bz2 This build is registerised, but doesn't have the native code generator. > I'm asking because I'm unexpectedly getting really bad > performance as you can see here: > > > http://felix.sourceforge.net/current/speed/en_flx_perf_0005.html > > and here: > > > http://felix.sourceforge.net/current/speed/en_flx_perf_0011.html > > These links are unstable, this one should always have > the latest results: > > http://felix.sourceforge.net/current/speed/en_flx_perf.html > > The compilation is using: > > ghc -O3 -fvia-C -optc -O3 > > which can probably be tweaked, any advice on that appreciated. I hope you're not going to conclude *anything* based on the performance of ackermann and tak! :-) Cheers, Simon

2 3

Performance on amd64
by John Skaller 05 Jul '05

05 Jul '05

Can someone comment on the Debian package for Ubuntu Hoary providing ghc-6.2.2 with binary for amd64? I'm asking because I'm unexpectedly getting really bad performance as you can see here: http://felix.sourceforge.net/current/speed/en_flx_perf_0005.html and here: http://felix.sourceforge.net/current/speed/en_flx_perf_0011.html These links are unstable, this one should always have the latest results: http://felix.sourceforge.net/current/speed/en_flx_perf.html The compilation is using: ghc -O3 -fvia-C -optc -O3 which can probably be tweaked, any advice on that appreciated. The actual test script measures real time performance by running programs at random.. there are lots of samples, the graphs are statistically reliable, and the randomness should eliminate most biases. For ackermann, the test is actually measuring how many words are required in the stack per call: the more the slower. For takfp, ghc is way behind, and Ocaml is actually way ahead since I think it uses doubles where the C based systems are using single precision (this affects the size of a stack frame) .. not sure about ghc, is Float a C float or a double in ghc? I may try to build from source if this is expected to provide better performance. -- John Skaller <skaller at users dot sourceforge dot net> Download Felix: http://felix.sf.net

1 0

RE: STM help
by Simon Marlow 04 Jul '05

04 Jul '05

The problem seems to boil down to this: - write a thread that performs an IO action whenever the contents of a set of TVars changes. Providing this functionality as part of STM seems to be wrong, because it relies on a particular implementation of STM (or a simulation of that behaviour). It would be difficult to incorporate this in the semantics, because the semantics doesn't currenly say anything about the change-detecting optimisation - so the behaviour of the new combinator would have to be specified explicitly. Another purely STM solution that you didn't mention is this: - have one TVar that records the "something changed" condition; every write to a TVar in the widget tree also sets this flag to true; the updater thread waits for the "something changed" flag to become True, calculates the screen redraw, then sets the flag to False again. - The difficulty then is optimising away the redraws when only hidden parts of the widget tree have changed - you could do this by having a "visible" flag on every widget, set by the updater thread. If an update occurs to a hidden widget, the changed flag is not set. If a widget changes such that it might have become visible, it must set the changed flag. I know this is an extra TVar per widget and more operations for each update, but I think it's the right thing. There are no unnecessary traversals of the widget tree, and redraws happen no more often than necessary. Cheers, Simon On 03 July 2005 20:17, John Meacham wrote: > I am attempting to use the STM to rewrite the screen handling code in > ginsu, which frankly, I am a little embarassed of :) > > The basic needs are: > - fully concurrent > - all curses calls must go through a single thread (otherwise it gets > real complicated) > - atomic updates to multiple parts of the screen at once. > - efficient update mechanism, screen _must not_ be needlessly redrawn. > > > So, my idea was basically, > > have a screen update thread, this is the only one that will make > curses > calls. > everything else communicates with the screen by modifying TVars > holding > data values like so > > data Widget = HBox { subWidgets :: [TVar Widget] } | Text { body :: > TVar String } > > and the screen is represented by a top level 'TVar Widget' > > > > This gives the first three requirements very nicely, you can > atomically > update several widgets or tex boxes, and everything is very concurrent > in a good way. > > The problem comes in when trying to implement an efficient update > mechanism, the problem is that I can't figure out how to wait on only > the relevant changed TVars. > > The structure of my curses thread would look like (essentially): > > > cursesThread head = do > atomically $ do > tv <- readTVar head > doit <- render tv -- returns an IO action > which draws the screen, > calling readTVar on subwidgets. > return doit > doit > -- What to put here to block on relevant changes? > cursesThread head > > The problem is that many TVars may contribute to the final screen, one > can change a TVar several widgets down and the screen should be > updated. > In addition, the screen should not be redrawn if a TVar for an > offscreen > or hidden widget changes. other threads should be able to update state > without worrying about the UI. > > Now, i can think of a couple things, neither of which I like very > much. > > - create a wrapper monad around STM that accumulates a list of TVars > read. This is just unappealing for a variety of reasons. > - have render return some sort of keys to compare values too and retry > if they are all equal to their old values. this would > double the work, one pass to draw it, another pass to figure out we > need to block. it would also really complicate the code. > > > Now, the other reason these options are undesirable, is that the STM > mechanism collects the exact information I need. AFAIK there is just > no > way to get at it. the STM must keep a log of all TVars read in order > to > know what to wait on when retrying. What I need is a way to somehow > atomically commit (assuming the transaction succeeds) and then be able > to block on the depended on TVars > > > This could be done with the addition of a simple primitive: > > - | behave exactly like 'atomically' except after the transaction > succeeeds, run the action on the result, and then block until > one of the TVars read by the transaction changes. > > atomicallyBlock :: STM a -> (a -> IO b) -> IO b > > > I think this could be very useful in general, but perhaps there is > something I am not seeing? I am still figuring out idioms to use with > STM. > > > John

1 0

GHC API: Access to nativeCodeGen?
by Peter A Jonsson 04 Jul '05

04 Jul '05

Hello, I would like to use nativeCodeGen outside of GHC to generate code from an IR. The IR would be produced by a third party program, not the GHC frontend. Looking at CVS HEAD I can see that GHC.hs exports plenty of things (for the GHC API I presume), but I can't find anything that lets me input some sort of IR and have ASM in return. Am I missing it somewhere or is there no way to input IR and get ASM in return? If there isn't, is such a feature planned/wanted? If such a feature isn't planned, I would appreciate any ideas on how to to accomplish the same thing. I have no problems with having a build tree of GHC laying around if that makes things easier. It would be a nice bonus if it made my maintenance burden low. / Peter

2 3