June 2008 - Glasgow-haskell-users

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

Haddock, .lhs, and GHC
by Richard Giraud 16 Jun '08

16 Jun '08

Hello I did a little digging on this issue and didn't find a definitive answer. According to the Haddock page in the wiki, Haddock is the de facto way of documenting files [http://haskell.org/haskellwiki/Haddock] Does this mean that literate source files should be discouraged? They seem to be fairly common, especially in conjunction with Cabal (i.e., Setup.lhs). They also appear in quite a few beginner tutorials, which can send new users down the wrong path (e.g., http://haskell.org/haskellwiki/How_to_write_a_Haskell_program) Is there an effort and/or intent to move the GHC sources away from .lhs entirely? --- The reason I ask is: I'm looking at the Test.HUnit modules and there are no Haddock annotations. I thought I'd help document the modules but, when I had a look at the source files, I found they were .lhs instead of .hs. There is already some documentation in the files but it's not visible to Haddock. What's the best way to proceed in a case like this? 1. Shoe-horn in the Haddock annotations by putting them in the code sections (e.g., > -- | Document comment...) but this seems a little cumbersome, especially if these comments show up in the published form of the .lhs file. 2. Rename to the files to .hs and touch up the files so they compile, then add the Haddock annotations. 3. Another option? --- I get the feeling that HUnit isn't getting much attention. Is that because it's "done" or because it's obsolete and will soon be removed? Thanks, Richard G.

4 6

Problems interrupting IO with -threaded
by Judah Jacobson 16 Jun '08

16 Jun '08

Hi all, I'm writing a program that reads input from the user but should also handle a ctrl-c. My attempt is below; the program forks a thread to read one character of input, and kills that thread upon receiving a sigINT. It works fine compiled without -threaded, but with -threaded it blocks forever after a ctrl-c. I know that in general, foreign calls are not interruptible; but the documentation for Control.Concurrent and System.Timeout suggests that I/O operations are a special case. In particular, the documentation for System.Timeout.timeout says: "Standard I/O functions like hGetBuf, hPutBuf, Network.Socket.accept, or hWaitForInput appear to be blocking, but they really don't because the runtime system uses scheduling mechanisms like select(2) to perform asynchronous I/O, so it is possible to interrupt standard socket I/O or file I/O using this combinator." So is the behavior that I'm seeing correct? If so, it seems odd to get better concurrency without the threaded runtime. If not, I can file a bug for this. I used ghc-6.8.2 and HEAD on OS X 10.5 (x86). Thanks, -Judah -------------- module Main where import Control.Monad import System.Posix.Signals import Control.Concurrent import Control.Concurrent.MVar import System.IO main = do hSetBuffering stdin NoBuffering hSetEcho stdin False mv <- newEmptyMVar let handler = putMVar mv Nothing installHandler sigINT (CatchOnce handler) Nothing tid <- forkIO (myGetChar mv) c <- takeMVar mv when (c==Nothing) $ do killThread tid putStrLn ("Result: " ++ show c) myGetChar mv = do c <- getChar putMVar mv (Just c)

4 5

6.8.3: make framework-pkg doesn't work
by Deborah Goldsmith 15 Jun '08

15 Jun '08

I tried building 6.8.3, and just "make" worked, but when I tried "make framework-pkg" I got stuff like this: > <com.apple.tools.info-plist-utility> "/Users/chak/Code/ghc/ > distrib/MacOS/Info copy.plist" -expandbuildsettings -o /Users/debbie/ > Work/source/ghc-6.8.3/distrib/MacOS/build/Release/GHC.framework/ > Versions/608/Resources/Info.plist I don't have a user named "chak" on my system, so it looks like there are some hardwired paths in the Xcode project for this target. I'm trying "make framework-binary-dist" and that appears to be working better. Deborah

1 0

Record syntax and INLINE annotations
by Bryan O'Sullivan 13 Jun '08

13 Jun '08

I have a curious situation. I've defined a data type using record syntax, and my module exports one of the accessor functions. I notice that GHC is not inlining any of the others, even though they are not exported. Furthermore, while poking around to see if I could bend it to my will, I found that I couldn't figure out where to place an INLINE annotation for an accessor function defined via record syntax such that the compiler would accept it. For now, I've dropped back to non-record syntax, my hand-crafted accessors are being inlined as I'd expect, and I win a few percent in performance. If anyone could shed a wee bit of light, I'd be most grateful.

3 4