Re: How bad is the PowerPC backend?
On 2/9/09, David Brown wrote: > > Which CPU is the x86? The modern x86 CPUs (such as Core2) will be > significantly faster than the PowerPC, even at comparable clock rates. > Have you just compared even C code tests? > I think that goes a long way towards explaining it... a simple C loop that I tried runs for 4.5s on the PC and 30s on the Mac. So probably this isn't GHC's fault. Thanks for the suggestion. Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "In fact, a sense of essence is, in essence, the essence of sense, in effect." -- Douglas Hofstadter ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How bad is the PowerPC backend?
On 2/9/09, Bulat Ziganshin wrote: > Hello Tim, > > > Monday, February 9, 2009, 11:16:22 PM, you wrote: > > > So is the PPC backend really this bad, or should I be looking for > > something weird with the hardware or configuration on the Mac? > > > check GC times too. one possibility is that GC takes much more time > due to smaller L2 cache > Hmm, doesn't seem to be happening with this example. On the Mac, I get (running with +RTS -s -RTS): 11.86 MUT time (13.95s elapsed) 0.08s GC time (0.15s elapsed) %GC time 0.6% (1.1% elapsed) and on the PC: 1.07s MUT time (1.34s elapsed) 0.01s GC time (0.02s elapsed) %GC time 1.1% (1.6% elapsed) so GC doesn't seem to explain the large difference in running times. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Maybe I don't want to meet someone who shares my interests. I hate my interests." -- Ghost World ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How bad is the PowerPC backend?
Hello Tim, Monday, February 9, 2009, 11:16:22 PM, you wrote: > So is the PPC backend really this bad, or should I be looking for > something weird with the hardware or configuration on the Mac? check GC times too. one possibility is that GC takes much more time due to smaller L2 cache -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How bad is the PowerPC backend?
Hello, For obscure reasons, I'm running some benchmarks both on an x86 machine (2.20 Ghz, 2 GB of RAM, Linux 2.6.22-15) and on a PowerPC Mac (1 Ghz, 512 MB of RAM, Mac OS 10.5). I noticed that even some pretty simple programs run much slower on the Mac than on the PC. For example, the following program (edited down from the "life" nofib benchmark): - limit xs = go [] xs go acc (x:y:xs) | x==y = acc ++ [x] | otherwise = go (acc ++ [x]) (y:xs) go acc [x] = acc ++ [x] go acc [] = error "limit" main = print (length (limit (iterate (\ x -> if x == 1 then x else (x+1)) 1))) --- runs in about 1.5 seconds on the PC, and 14 seconds on the Mac. This is with ghc -O2, version 6.10.1. The numbers are about the same on either machine whether I use -fvia-C or -fasm. The Mac does have a lot less RAM, but I can see that the program isn't swapping. So is the PPC backend really this bad, or should I be looking for something weird with the hardware or configuration on the Mac? Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I don't like your I-can-use-anything-as-an-adjective attitude." -- Larry Wall ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: my experience with ghci debugger extensions
Hi, Simon Marlow wrote: If you felt like working on this yourself, possibly with Pepe, then we'd be happy to support in any way we can. Thanks. It may happen though it is not probable. I do not know the code so anything non-trivial is a significant effort and my free weekends and evenings are sparse :-( If I would do anything, should it be posted here, sent to Pepe, or attached to the ticket? Is it a habit to indicate in the ticket that somebody started coding it actually (especially if it takes longer to implement)? Peter, it is best if you attach everything to the ticket. If you want to signal that you started coding on a ticket, just take ownership of it. As for as /:next/ command: Like Pepe indicated, I do not have idea how to do it without working _result and without dynamic stack. Though dynamic stack should not be that hard since how otherwise could profiler count ticks for cost centers. And dynamic stack would be great. It would create new options where to store lists of free variables of selected expressions :) Having (a kind of messy approximation of) a dynamic stack is possible with a variant of the cost center stacks mechanism used for profiling. But the downside is that code and libraries would need to be compiled for debugging. Nevertheless, I believe that having a true dynamic stack would make debugging so much simpler. Ok, I did not understand this part a bit till I did not skim over http://www.haskell.org/~simonmar/papers/ghci-debug.pdf Maybe that paper should be mentioned on the wiki pages about debugger. Something like: "If you do not understand why ghci debugger is limited in such a strange way read this." Debugging for lazy functional languages is a hard problem. The GHCi debugger is no panacea. But you are right in that the current state of things can be improved in several ways. However, the Simons have already enough things in their hands; it is up to us to step forward and help. Unfortunately, my time is also very limited, as I am trying to get a degree here. I am happy to support Peter and anyone else who wants to hack on the debugger, and I will continue maintaining the code around :print. But right now I don't think I can find the time to work on the tickets brought up in this discussion. Cheers, pepe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: my experience with ghci debugger extensions
Hi Simon, Simon Marlow wrote: If you felt like working on this yourself, possibly with Pepe, then we'd be happy to support in any way we can. Thanks. It may happen though it is not probable. I do not know the code so anything non-trivial is a significant effort and my free weekends and evenings are sparse :-( If I would do anything, should it be posted here, sent to Pepe, or attached to the ticket? Is it a habit to indicate in the ticket that somebody started coding it actually (especially if it takes longer to implement)? So #1531 is tricky to fix, unfortunately. The implementation of _result is a bit of a hack in the first place. The fundamental problem is that a tick expression looks like this case tick of _ -> e where 'e' is not necessarily exactly the same as the expression that was originally inside the tick. We are careful to maintian the property that the tick is evaluated iff the original expression is evaluated, but that's all. _result is bound to e, which may or may not be what you wanted. One way to fix it would be to add extra constraints on what the simplifier can do with tick expressions. I don't like the sound of that because (a) I doni't know exactly what restrictions we'd have to add and (b) this amounts to changing the semantics of Core (i.e. changing which transformations are valid). Ok, I did not understand this part a bit till I did not skim over http://www.haskell.org/~simonmar/papers/ghci-debug.pdf Maybe that paper should be mentioned on the wiki pages about debugger. Something like: "If you do not understand why ghci debugger is limited in such a strange way read this." A breakpoint condition on _result: My guess is that in about half of the cases I can just put them on a free variable on some other location just as comfortably. In other cases I'm out of luck :) As for as /:next/ command: Like Pepe indicated, I do not have idea how to do it without working _result and without dynamic stack. Though dynamic stack should not be that hard since how otherwise could profiler count ticks for cost centers. And dynamic stack would be great. It would create new options where to store lists of free variables of selected expressions :) Maybe there's another way to fix it, but I can't think of one right now. If by simplifier you did not mean straight translation to core, then I assume you wanted to try to just skip over all the optimizations (simplifications?). Was it hard to do it or was the performance impact so bad that it was not worth the addition of a command line switch? Thanks for reading the post about debugging, now there is at least a chance that it will be better once. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: length of module name affecting performance??
http://hackage.haskell.org/trac/ghc/ticket/2884 On Feb 9, 2009, at 10:53 AM, Wolfgang Jeltsch wrote: Am Montag, 29. Dezember 2008 12:54 schrieb Simon Peyton-Jones: What a great bug -- I would never have predicted it, but in retrospect it makes perfect sense. Record selectors had better get fixed. Can I read somewhere about what caused this bug? What is its trac URL? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: :info features
On Sat, Feb 07, 2009 at 12:39:03AM -0500, Brandon S. Allbery KF8NH wrote: > On 2009 Feb 5, at 5:49, Remi Turk wrote: >> SPJ agreed with the idea itself, but suggested an alternative set of >> commands: >> >> :info Show-- See class definition only >> :instances Show -- See instances of Show > (...) >> However, it would make ":i" ambiguous, which is rather sad. > > :class Show -- unique prefix :cl, already many such collisions > :instance Show That could work, but then how to get information about types as opposed to classes? Its not in the above example, but "Show" actually stands for an arbitrary typeclass _or type_. However, as igloo pointed out on the ticket, abbreviations don't actually have to be unique: "For example, :b means :break even though we also have :back, :browse and :browse!. " [1] That would personally lead me to prefer the :info/:instances combo, with :i as an abbreviation of :info. Groeten, Remi [1] http://hackage.haskell.org/trac/ghc/ticket/2986#comment:4 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: length of module name affecting performance??
Am Montag, 29. Dezember 2008 12:54 schrieb Simon Peyton-Jones: > What a great bug -- I would never have predicted it, but in retrospect it > makes perfect sense. Record selectors had better get fixed. Can I read somewhere about what caused this bug? What is its trac URL? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
