- Glasgow-haskell-users

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

STM help
by John Meacham 04 Jul '05

04 Jul '05

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 -- John Meacham - ⑆repetae.net⑆john⑈

3 3

Data.Tree & Typeable
by Jean-Philippe Bernardy 03 Jul '05

03 Jul '05

Dear GHC developpers, Could you please make Data.Tree Typeable-aware by declaring the appropriate instances? Thanks in advance, Jean-Philippe Bernardy.

1 0

RE: Re[2]: ANNOUNCE: GHC survey results
by Konovalov, Vadim 30 Jun '05

30 Jun '05

> btw, in Pugs sources > (http://search.cpan.org/CPAN/authors/id/A/AU/AUTRIJUS/Perl6-Pugs-6.2.7.tar.g z) > there is Unicode.hs module wich can classify and convert full range of > Unicode symbols under any OS. i don't understand - is this module > already included in GHC 6.5? if not, it would be good addition that file reads: -- Based on the GHC.Unicode library, Copyright 2005, Dimitry Golubovsky. -- See GHC's LICENSE file for the full license text. That said, it is part of GHC?

1 0

RE: resolving Show instance
by Simon Peyton-Jones 30 Jun '05

30 Jun '05

path gets the inferred type path :: forall a. [a] This polymorphic type is instantiated once when it is passed to 'subterm' and again, quite separately, when it is passed to 'shows'. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 30 June 2005 11:58 | To: glasgow-haskell-users(a)haskell.org | Subject: resolving Show instance | | Who knows, please, why does there happen, now and then, the effects | of the following kind? | | The ghc-6-4-branch-June-15-2005 compiler cannot resolve the Show | instances in the following program | (using overlapping and `undecidable' instances): | | ------------------------------------------- | import Dumatel | main = putStr (shows path $ shows (subterm path t) "\n") | where | th = bool defaultVariableWeight defaultInitialOpId weightDecls lpo | where | weightDecls = [] | | t = parseSingleOrBreak th "bool" "x & (not x)" :: Term | | path = [] -- :: SubtermPath | ------------------------------------------- | | | It cannot choose the Show instance for path = []. | But | 1) the above `putStr' line contains a subexpression | shows (subterm path t) "\n", | | 2) the imported modules contain the declarations | | subterm :: SubtermPath -> Term -> Term | ... | type SubtermPath = [Integer] | | Hence, it should derive the type for path : [Integer]. | | Also setting path = [1] | or path = [] :: SubtermPath | instead of the line | path = [] | satisfies the compiler. | | This is not a problem for me to guess to add `:: SubtermPath'. | This is a question of curiosity. | The compiler sees to which function `path' is fed to, and sees the | argument types of this function. Hence, why does not it find the | type for `path' ? | | I am sure that much simpler example is possible | (the imported universe is complex), maybe even without overlaps. | But maybe, people can explain the effect right for this example as | it is? | The report is | | ------------------------------------------ | Overlapping instances for Show [a] | arising from use of `shows' at GHCBug.hs:5:15-19 | Matching instances: | Imported from GHC.Show: instance (Show a) => Show [a] | Imported from Prelude3: instance Show [Equation] | Imported from Prelude3: instance Show [Term] | (The choice depends on the instantiation of `a' | Use -fallow-incoherent-instances to use the first choice above) | In the first argument of `($)', namely `shows path' | In the first argument of `putStr', namely | `((shows path) $ (shows (subterm path t) "\n"))' | In the definition of `main': | main = putStr ((shows path) $ (shows (subterm path t) "\n")) | where | path = [] | th = bool defaultVariableWeight defaultInitialOpId weightDecls lpo | where | weightDecls = [] | t = parseSingleOrBreak th "bool" "x & (not x)" :: Term | -------------------------------------------------------- | | | Thank you in advance for explanations. | | ----------------- | Serge Mechveliani | mechvel(a)botik.ru | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

resolving Show instance
by Serge D. Mechveliani 30 Jun '05

30 Jun '05

Who knows, please, why does there happen, now and then, the effects of the following kind? The ghc-6-4-branch-June-15-2005 compiler cannot resolve the Show instances in the following program (using overlapping and `undecidable' instances): ------------------------------------------- import Dumatel main = putStr (shows path $ shows (subterm path t) "\n") where th = bool defaultVariableWeight defaultInitialOpId weightDecls lpo where weightDecls = [] t = parseSingleOrBreak th "bool" "x & (not x)" :: Term path = [] -- :: SubtermPath ------------------------------------------- It cannot choose the Show instance for path = []. But 1) the above `putStr' line contains a subexpression shows (subterm path t) "\n", 2) the imported modules contain the declarations subterm :: SubtermPath -> Term -> Term ... type SubtermPath = [Integer] Hence, it should derive the type for path : [Integer]. Also setting path = [1] or path = [] :: SubtermPath instead of the line path = [] satisfies the compiler. This is not a problem for me to guess to add `:: SubtermPath'. This is a question of curiosity. The compiler sees to which function `path' is fed to, and sees the argument types of this function. Hence, why does not it find the type for `path' ? I am sure that much simpler example is possible (the imported universe is complex), maybe even without overlaps. But maybe, people can explain the effect right for this example as it is? The report is ------------------------------------------ Overlapping instances for Show [a] arising from use of `shows' at GHCBug.hs:5:15-19 Matching instances: Imported from GHC.Show: instance (Show a) => Show [a] Imported from Prelude3: instance Show [Equation] Imported from Prelude3: instance Show [Term] (The choice depends on the instantiation of `a' Use -fallow-incoherent-instances to use the first choice above) In the first argument of `($)', namely `shows path' In the first argument of `putStr', namely `((shows path) $ (shows (subterm path t) "\n"))' In the definition of `main': main = putStr ((shows path) $ (shows (subterm path t) "\n")) where path = [] th = bool defaultVariableWeight defaultInitialOpId weightDecls lpo where weightDecls = [] t = parseSingleOrBreak th "bool" "x & (not x)" :: Term -------------------------------------------------------- Thank you in advance for explanations. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: ANNOUNCE: GHC survey results
by Simon Marlow 29 Jun '05

29 Jun '05

On 28 June 2005 14:11, Bulat Ziganshin wrote: > Tuesday, June 28, 2005, 1:58:13 PM, you wrote: > >> http://www.haskell.org/ghc/survey2005-summary.html >> There's a lot to take in, but it's an interesting read. Enjoy! > > thank you all, processing all the 600 answers was not easy work :) > > i have several comments regarding results of this survey: > > 1) GHCi compiles to bytecode several times faster than GHC makes > unoptimized compilation. can unoptimized GHC compilation just create > bytecode (as Ocaml does)? Do you really mean "several times faster"? My impression is that it's a few percent faster, if at all. Some measurements would be good. We've thought about compiling to persistent byte code in the past, but the gains never seemed to be worth the effort: we'd need a byte-code serialiser and loader. > 2) is your plans to support x86-64 platform includes Windows (and all > other sorts of Unix), or it's for Linux only? Definitely Windows too. I hear the cygwin/mingw tools are still unstable on Windows x64, though. > 3) many users complaining about non-compatibility between GHC > versions. if they mean library interfaces changes then how about using > Pesco's library versioning scheme? (see > http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory) I've read that article, and I think it's an interesting idea. I can't disagree with the arguments put forward, but somehow, the cure seems a bit painful. Cheers, Simon

3 2