- Glasgow-haskell-users

Library-vs-local performance
by Scott Dillard 24 Jun '08

24 Jun '08

Hi, I've got a library that I'm in the process of uploading to hackage (waiting for account) but the darcs repo is here: http://graphics.cs.ucdavis.edu/~sdillard/Vec I notice a slight drop in performance when I install the library using cabal. Maybe 10-20%, on one particular function. This is in comparison to when the library is 'local', as in, the source files are in the same directory as the client application. What could be causing the performance drop? The function in question requires impractical amounts of inlining (This is something of an experiment), but I don't see how installing it as a library affects that. The functions to be inlined are small, surely available in the .hi files. Its only when they are applied do they agglomerate into a big mess - 80-200K lines of core. The function in question is invertMany in examples/Examples.hs. Scott

3 10

Re: Recursive functions and constant parameter closures (inlining/strictness analyzer question)
by Max Bolingbroke 23 Jun '08

23 Jun '08

> I've been wondering if a nice option would be to be able to feed profiler > information in at compile time and have it override the heuristics. > > That way, inlining, specialization, SAT, etc., decisions could be made based > on how the code actually gets used during a typical run of the program. > > Cheers! -Tyson Yes, that is the ultimate solution to resolving those things that are traditionally unknown by a compiler, and profile directed optimization could certainly be exploited by GHC (imagine having the compiler automatically run Quickcheck/HUnit tests to exercise the code..). See http://msdn.microsoft.com/en-us/library/e7k32f4k.aspx for details of a practical implementation of this strategy. I wouldn't be suprised if industrial virtual machine JIT compilers were making use of this sort of thing too. Another strategy is to having the runtime dynamically adjust how code is executed based on profiling information. See e.g. Adaptive Evalution of Non-Strict Programs by Robert Ennals (http://berkeley.intel-research.net/rennals/pubs/thesis.pdf) In the case of SAT this might involve the runtime switching to the non-SATed version of a function if it looks like most calls to it had a low iteration count. Cheers, Max

1 0

-O in 6.8.3
by Serge D. Mechveliani 20 Jun '08

20 Jun '08

Hello, This is on the recent topic of very eager inlining in ghc-6.8.3. I wrote recently that (1) 6.8.3 takes 7 times more of heap than 6.8.2 to complile under -O a certain small-size module RsePol_ (let us call it M.hs), (2) even the needed ~70 Mb in 6.8.2 looks unnaturally large. After thinking a bit, I take back (2). For `making' M under -Onot -- all right, it must suffice about 20 Mb. But -O allows deeper optimization, this needs more inlining, inlining pieces between modules, inlining instances (to some extent). I expect that -O needs for compilation not more than about 5 times greater expence in memory and time than -Onot. ghc-6.8.2 satisfies this. And 6.8.3 does not, its ratio is about 35 on the example of RsePol_.hs What is the developer's idea abot -O/-Onot cost ratio for RAM and time? What is the difference between ghc-6.8.2 and ghc-6.8.3 ? The former does not inline instances under -O and the latter does inline? As to the 10-20 % of the result code increase, I am calm about this -- if something it bought by this. But I am not an expert and do not see in what point 6.8.3 is better, at least the DoCon performance is not greater. I do not know, maybe some bugs are fixed, and a bug fix often costs some code increase, and a bug fix is good. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

HUnit
by Richard Giraud 19 Jun '08

19 Jun '08

I've converted the literate Haskell documentation and filled in the gaps for HUnit. I've posted the darcs repository with the changes and the new documentation at http://richardg.name/ Please email me with any feedback and/or patches that you might have. In a bit, I'll submit the patches for inclusion into the GHC repository. Richard G.

2 2

6.8.3 against DoCon
by Serge D. Mechveliani 19 Jun '08

19 Jun '08

Dear GHC developers, I wonder whether ghc-6.8.3 is better than 6.8.2. Because 6.8.2 makes DoCon-2.11 under -M400m. And 6.8.3 does not suffice -M500m. It breaks with the heap exhaustion at the module RsePol_. -------------------------------------------------- Moreover, repeated make docon again breaks with the heap exhaustion for -M500m. So this memory is spent to compile a single current module. -------------------------------------------------- The last (difficult) module is RsePol_. And `make' is slower than in 6.8.2, at least at this module. I do not believe that a reasonable compiler may need more than 500 Mb for compiling this poor RsePol_. Second, for the candidate version I reported to the e-mail lists the two problems. The second one was about this memory and time strangeness in compiling RsePol_. Now, you issue an official release, without even considering the second problem. I do not know, maybe this RsePol_ is somehow too irregular (with overlapping instance, etc.), maybe, DoCon is guilty. But as ghc-6.8.2 handles DoCon all right, why do not you investigate this difference in 6.8.3 ? Actually, ghc-6.8.3 does not support DoCon. I wonder what to do. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 3

Low-level array performance
by Dan Doel 18 Jun '08

18 Jun '08

Greetings, Recently, due to scattered complaints I'd seen on the internet, I set about to rewrite the fannkuch [1] benchmark on the Great Computer Language Shootout. The current entry uses Ptr/Addr#, malloc, etc. so it's not particularly representative of code one would actually write in Haskell these days. Over the past few days, I've written several versions of the benchmark, and collaborated a bit with local speed guru Don Stewart, but an entry that bests the current entry does not seem to be in the cards currently. So, I thought I'd write about some of the issues, and hopefully get some encouraging news about the situation. Issue 1: STUArrays aren't optimized as fully as one might ideally expect. This isn't so much of an issue, I suppose, except possibly for an environment like the shootout. I wrote versions of the benchmark (and particular pieces of the overall benchmark, as well) for both STUArrays, and MUArrays from dons' new uvector [2] library. The STUArray versions are consistently slower, and a look at the core reveals that STUArray code contains significantly more boxing than uvector. This isn't a big deal, as there's no reason not to use uvector, aside from it not being blessed by being in the GHC distribution. However, I thought I'd bring it up in case anyone hasn't heard of the library yet. Issue 2: Reading from/writing to a MutableByteArray# is slower than an Addr# This is, I think, the crux of the issue. The main content of the benchmark is reversing/shifting items in an array. To get a somewhat easier look at the core, I boiled things down to a benchmark that just reverses a small array many times. In the interest of further reducing things, I wrote a version of the benchmark that uses raw Addr#s, and a version that uses raw MutableByteArray#s. I've attached both versions. The fannkuch benchmark (input 11) with byte arrays runs in around 12 seconds on my machine. To get the reversal benchmark to around that time, I can tell it to, for instance, reverse a 10-element array 250 million times. Those same inputs to the Addr# version of the reverse benchmark result in a runtime of 7 to 8 seconds, so there's a significant discrepancy at the level the benchmark actually runs at (the current fannkuch entry that uses Addr#/Ptr takes around 9 seconds, so there's other stuff going on in the benchmark evening them out, but this is likely the source of the difference between the two). uvector performance on the reversal benchmark is comparable with MutableByteArray#, so the practical slowdown using a library for actual public consumption seems to be in the fact that it's based on byte arrays (STUArray again falls further behind by retaining too many boxes). So, to wrap things up: dons and I were rather curious about the performance differences between MutableByteArray# and Addr#, as one might expect them to be comparable, both being low-level, raw pointer type structures; the code for using the two is nearly identical. (If one were to raise an Issue 3, it'd likely be that, even with Addr# and malloc, which is currently the fastest Haskell solution, we're not that fast. A glance at that shootout list reveals that we're beat by a myriad of Java-based languages, Python (Psyco), Ada, Ocaml, Eiffel, Lisp (SBCL), Clean, and of course C++, C, Fortran, etc. Is there any hope of getting performance improvements that will push us up in that list? I've heard that people are working on improved code generation, but I don't know if that can help with this sort of thing (or if it's more of a runtime system area). While writing this mail, it came to mind that this is also a potential source of slowness in the sorting 'library' I've been writing for uvector. I already have some routines that are competitive with/beat qsort from glibc, but GNU's C++ STL introsort implementation has remained untouched. However, if reads/writes simply take twice as much time in Haskell as they do in C++, my results aren't as surprising.) Anyhow, thanks for any light that can be shed on the subject. 1: http://shootout.alioth.debian.org/gp4/benchmark.php?test=fannkuch 2: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uvector

5 10

Default class method inlining bug (wasn't this fixed?)
by Scott Dillard 18 Jun '08

18 Jun '08

Something strange happened and the body of my previous email was lost. I've re-sent it here. The attachments are there. http://www.haskell.org/pipermail/glasgow-haskell-users/2008-June/014973.html ===== Hi, I'm seeing the following bug revived in 6.8.2 and 6.8.3: http://hackage.haskell.org/trac/ghc/ticket/672 I use a default definition for class method, one that calls methods of dependent (super?) classes. Of course I'm embarrassed it took me so long to realize I didn't _need_ the class in the first place, I could just write a plain polymorphic function that calls those methods. Regardless, looks like a bug to me. Two files are attached, Test.hs and Vec.hs. Search for "BUG IS HERE" in Test.hs. There is a class and an instance declaration. Compile as-is to see the correct result. Comment out the method definition in the instance declaration to see the bug. If someone confirms, I'll open a ticket. Scott

1 0

Fundeps, instances and inference
by Scott Dillard 18 Jun '08

18 Jun '08

Hi, I've been fidgeting with a fixed-length list library, for things like 3d vectors/points, rgba tuples, etc. The data type is data a :. b = (:.) a b deriving (everything reasonable) infixr :. Nothing in that type specifies that for the partially instantiated type t1:.t2:.t3, t1 and t2 should be equal. (Like Int:.Int:.() for a 2D integer point.) But t1 and t2 will always will be equal, at least I want them to always be equal, and everything useful I can think of needs them to be equal. (Note I won't actually store things in these data types. This is just a way of defining operations. Packed arrays and vectors will be converted to/from these types in a stream-fusioney kind of way. That's the plan, at least.) Anyway, I don't need to force them to be equal because all of the functions for these list-like things come in the form of classes, and those classes have fundeps, and the fundeps let me enforce type constraints. The problem I'm having is making these constraints work nicely with inference. I'm not sure exactly whats going on, which is why I'm asking the list. For an example, folding: -- the fold function/class class Fold a v | v -> a where fold :: (a -> a -> a) -> v -> a foldl :: (b -> a -> b) -> b -> v -> b foldr :: (a -> b -> b) -> b -> v -> b -- base case of the recursion, () is like [] instance Fold a (a:.()) where fold f (a:._) = a foldl f z (a:._) = f z a foldr f z (a:._) = f a z -- inductive case. Pick one of the "instance" declarations below... instance Fold a (a:.u) => Fold a (a:.a:.u) where -- I1 instance Fold a (a2:.u) => Fold a (a:.a2:.u) where -- I2 fold f (a:.v) = f a (fold f v) foldl f z (a:.v) = f (foldl f z v) a foldr f z (a:.v) = f a (foldr f z v) Now, both of those instance declarations work. The first one (I1) specifies that all of the list elements should be the same type, "a". The second (I2) doesn't say that right away, because one is 'a' and the other is 'a2.' However the fundep (v->a) will force a and a2 to match, so from orbit the two instances appear the same. In practice, I1 does not cause the type checker to infer the type of list elements, while I2 does. So, in ghci, if you do foldr (:) [] (1:.2:.3:.()) With I1 you'll get an error like "no instance for Fold a (t :. t1 :. t2 :. ()).." But with I2, it will infer 1 2 and 3 to all be of type "Num a => a" and will evaluate the expression to [1,2,3]. So the question is "Why?" For simple things like fold, map, etc., I can massage the instance declarations so that the type checker infers things for me, but for more complicated recursions, I'm having trouble. (For example, computing determinants by minor expansion. Not the most efficient way I know, but if I can't figure that out there's no hope for Gaussian elimination.) The functions work, its just the inference that isn't working. I'm forced to annotate things, or at least ensure that the types of the arguments can be inferred from someplace else. Scott

1 0

Symbols in built executables
by Bryan O'Sullivan 18 Jun '08

18 Jun '08

Here's something I just stumbled upon by accident: at least on Linux, GHC emits huge numbers of symbols into the binaries it generates. Here's Haddock, which I compiled without any funny debug options: $ du -h haddock-0.9 4.1M haddock-0.9 $ nm haddock-0.9 | wc -l 37938 $ strip haddock-0.9 $ du -h haddock-0.9 2.7M haddock-0.9 I happened upon this because I'm repackaging GHC 6.8.3 for Fedora, and rpmlint complained that haddock was not stripped. The RPM packager automatically strips binaries using "strip -g", but that wasn't stripping any of the abovementioned symbols. I don't know what the purpose of those symbols might be. Could someone fill me in, please? Can they actually be used for anything?

3 2

Rebuilding ghc
by Dominic Steinitz 17 Jun '08

17 Jun '08

I've built ghc previously and I assumed to keep it up to date I just did darcs pull followed by make but I got errors and according to the rebuilding instructions http://hackage.haskell.org/trac/ghc/wiki/Building/Rebuilding I shouldn't have done that. I therefore followed the instructions but got the following error. By the way darcs-pull all seemed to require a lot of manual intervention. Is there a way of getting the latest patches automatically and building overnight without intervention? Thanks, Dominic. > if ifBuildable/ifBuildable /home/dom/ghc/libraries/boot-packages editline; then \ > cd editline && \ > cmp -s /home/dom/ghc/libraries/Makefile.local Makefile.local || cp /home/dom/ghc/libraries/Makefile.local .; \ > mv GNUmakefile GNUmakefile.tmp; \ > setup/Setup makefile -f GNUmakefile; \ > cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; \ > make -wr && \ > setup/Setup register --inplace; \ > fi > mv: cannot stat `GNUmakefile': No such file or directory > Preprocessing library editline-0.2... > In file included from Editline.hsc:52: > include/HsEditline.h:11: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘v’ > compiling dist/build/System/Console/Editline_hsc_make.c failed > command was: gcc -c -D__GLASGOW_HASKELL__=609 -I/home/dom/ghc/includes -I/home/dom/ghc/gmp/gmpbuild -D__GLASGOW_HASKELL__=609 -Iinclude dist/build/System/Console/Editline_hsc_make.c -o dist/build/System/Console/Editline_hsc_make.o > make[2]: Entering directory `/home/dom/ghc/libraries/editline' > make[2]: *** No targets specified and no makefile found. Stop. > make[2]: Leaving directory `/home/dom/ghc/libraries/editline' > make[1]: *** [make.library.editline] Error 2 > make[1]: Leaving directory `/home/dom/ghc/libraries' > make: *** [stage1] Error 2

7 16