September 2005 - Glasgow-haskell-users

RE: .hc files for building ghc-6.4 on amd64 ?
by Simon Marlow 12 Sep '05

12 Sep '05

On 06 September 2005 15:33, Wilhelm B. Kloke wrote: > I have a FreeBSD box running FreeSD-amd64-6.0. Is there anybody who > can give me a set of .hc files (probably from linux x86_64) to build > GHC? I tried to follow the instructions to crossbuild from > FreeBSD-i386, > but my attempts failed for reasons I don't understand. I have an account on a box, but haven't yet had time to do the port. If you let us know where your build got stuck, we might be able to help you out. Cheers, Simon

2 1

RE: Profiling and analysing space usage
by Simon Marlow 12 Sep '05

12 Sep '05

On 02 September 2005 17:09, Bulat Ziganshin wrote: > Hello Alistair, > > Thursday, September 01, 2005, 6:36:09 PM, you wrote: > >> The heap profile graph for this program shows an initial peak, and >> then the graph is flat at 8Mbytes, which I think is the space >> allocated to the two STArrays (2 arrays, 1 million chars each, 4 >> bytes per char?). So it looks as though any allocation for the loop >> function is GC'd very soon after it's allocated. > > Char uses 4 bytes because it must hold any Unicode character, which is > about 1 million :) use Word8 or CChar STArray is a lazy array, which means that each element of the array is a pointer to another closure. However, the reason you only see 4 bytes per character is because GHC has a static table for Char values < 256, so all the characters end up being shared, and you're left with 4 bytes per char for the pointers, at least when all the array elements are evaluated. Interestingly, a fully evaluated STArray Char takes the same amount of dynamic space as an STUArray Char. It is slower to access, though. Cheers, Simon

1 0

profile not showing it all?
by Niels 09 Sep '05

09 Sep '05

Hi, since my application takes up way to much memory, i decided to profile it (compile d it with -prof and -auto-all). After running it with +RTS -hc, it shows a graph that reaches a peak at around 85mb. However, when i check the memory usage with 'top' i see the application reach over 300mb. What am i missing here? PS the application is a large attribute grammar that performs program analysis on an AST that represents an application. regards, Niels.

5 9

VHS plugin bug
by Adam Molnar 06 Sep '05

06 Sep '05

Hello, I don't know whether this project is still maintained, but I hope so. :-) There seems to be a really annoying bug in the VHS plugin v0.1 (http://www.cin.ufpe.br/~haskell/vhs/download.html) that can be reproduced in VS.Net 2003 under Windows XP Pro SP2 in the following steps: 1) create a new Haskell App-project: module Main where main :: IO () main = return() 2) create 2 function signatures: module Main where f :: Int -> Int g :: Int -> Int -- *** at this point the devenv crashes, or after inserting a new line after "f :: Int -> Int" main :: IO () main = return() Please note that turning off "Auto list options" and "Parameter Information" didn't solve the problem. --- Also, there seems to be some resource-leak in the plugin, because after closing the devenv stays in memory and can only be shut down using the task-manager. Adam

3 3

.hc files for building ghc-6.4 on amd64 ?
by Wilhelm B. Kloke 06 Sep '05

06 Sep '05

I have a FreeBSD box running FreeSD-amd64-6.0. Is there anybody who can give me a set of .hc files (probably from linux x86_64) to build GHC? I tried to follow the instructions to crossbuild from FreeBSD-i386, but my attempts failed for reasons I don't understand. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257

1 0

Accessing new heap costs more than old?
by Adrian Hey 05 Sep '05

05 Sep '05

Hello folks, I wonder if anybody can shed any light on the strange behaviour I've been seeing with some of my benchmarks. The story is.. While measuring execution times of various AVL routines on random data I found that insertion was taking far longer than deletion (over twice as long). This is surprising because if anything deletion is the more complex operation. Anyway after much struggling and experimentation with different options/inlining etc I failed to fix this so tried the same tests with Data.Intmap and got similar unexpected results. But I've now found that the root cause seems to be a subtle difference in the two tests. For insertion the test was cummulative, so each new insertion was on the tree resulting from the previous insertion. But for deletion the deletion was always done on the same tree. If I modify the insertion test to work the same way as deletion then sure enough, insertion is faster than deletion (as I would expect). The same is true for Data.IntMap too. (The insertion speeds for the two modes differ by a factor of 2.8..2.9 for both Data.Tree.AVL and Data.IntMap). But I can't think of a plausible explanation for this. The overall heap burn rate should be about the same in each case, as should the overall amount of live (non-garbage) heap records. I thought maybe it might be a cache effect, but if anything I would expect caching to favour the cummulative mode (new allocations should displace old from the cache AFAIK). Also profiling shows that the cumulative case performs slightly fewer allocations (as I'd expect because it starts with an empty tree). Anyway, just thought I'd mention it in the hope that there might be something that can be done about it. The cummulative case seems like it would be more typical of real world code, so taking a factor of 3 or so performance hit is undesirable IMHO, but may well be unavoidable :-( Regards -- Adrian Hey

2 3

Re: GHCI Problem
by Sven Panne 05 Sep '05

05 Sep '05

Am Sonntag, 4. September 2005 16:26 schrieb Dominic Steinitz: > Can anyone tell me why ghci has this problem whereas ghc itself doesn't and > how I fix it. > > Thanks, Dominic. > > [dom@tility LAMH]$ ghci -package hsql-mysql > ___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell 98. > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \____/\/ /_/\____/|_| Type :? for help. > > Loading package base-1.0 ... linking ... done. > Loading package hsql-1.6 ... linking ... done. > Loading package hsql-mysql-1.6 ... ghc-6.4: can't load .so/.DLL for: c > (/usr/lib/libc.so: invalid ELF header) > [...] It looks like the package description of hsql-mysql explicitly mentions "-lc" for linking (or something like that). Simply removing that superfluous flag should fix the problem, but I'm only guessing here, as I've never used that package. Cheers, S.

1 0

hat, ghc
by Frederik Eaton 02 Sep '05

02 Sep '05

Is there a way to use Hat with GHC, without 'hmake'? The Hat Tutorial shows 'hmake' being used, but 'hmake' doesn't work for me. The problem is that 'hmake' seems to be looking for 'ghc' based on something other than PATH: $ ghc --make pointtracker.hs Chasing modules from: pointtracker.hs Compiling Util ( ./Util.hs, ./Util.o ) Compiling XSimpleIO ( ./XSimpleIO.hs, ./XSimpleIO.o ) Compiling Main ( pointtracker.hs, pointtracker.o ) Linking ... $ which ghc /home/frederik/.toast-i386/armed/bin/ghc $ hmake -hat pointtracker.hs Fail: Can't find module Graphics.X11.Xlib in user directories . Or in installed libraries/packages at /usr/lib/ghc-6.2.2/imports Asked for by: pointtracker.hs Fix using the -I, -P, or -package flags. Stop - hmake dependency error. i.e., I'm not sure how 'hmake' found /usr/lib/ghc-6.2.2, but this directory is not mentioned in my environment, and it was not my intention to use this version of ghc. Thanks, Frederik -- http://ofb.net/~frederik/

3 5

Profiling and analysing space usage
by Alistair Bayley 02 Sep '05

02 Sep '05

Hello all. Below is a (typically pointless) program, which is a small slice from a larger one I'm profiling. I'm interested in getting the memory usage as small as possible. The loop function (and its analogue in the real program) contributes significantly to the allocation stats. AFAICT, this would be mainly due to a closure built for the if-stmt. The heap profile graph for this program shows an initial peak, and then the graph is flat at 8Mbytes, which I think is the space allocated to the two STArrays (2 arrays, 1 million chars each, 4 bytes per char?). So it looks as though any allocation for the loop function is GC'd very soon after it's allocated. So my questions are: - is my analysis of the space usage correct i.e. allocation in the loop function is very short-lived and nothing to worry about? - is there anything I can do to reduce the memory usage, or is it already minimal, assuming that I'm happy with the size of the STArrays? I realise I could use, say, PackedStrings, but the original program works on lists of (Eq a); I've just chosen Chars for this example so as to eliminate polymorphism from the profiling. Notes: - exporting only main makes a *big* difference to both space and time usage, as does adding type signatures, to eliminate polymophism. This is the only retainer set shown on the profiling graph: SET 2 = {<MAIN.SYSTEM>} COST CENTRE MODULE %time %alloc loop Main 35.1 15.4 alloc_b Main 19.5 7.7 main Main 13.0 30.8 makeArray1 Main 9.1 5.1 loop_if Main 9.1 41.0 inBounds Main 6.5 0.0 test1M Main 3.9 0.0 alloc_a Main 3.9 0.0 module Main (main) where import Data.Array.ST import Control.Monad.ST main :: IO () main = do let src = take 1000000 (repeat 'a') dst = take 1000000 (repeat 'a') d :: Int d = test1 src dst print d test1 :: String -> String -> Int test1 src dst = runST (test1M src dst) test1M :: String -> String -> ST s Int test1M src dst = do srca <- makeArray1 (length src) src dsta <- makeArray1 (length dst) dst loop srca dsta 1 inBounds :: STArray s Int Char -> Int -> Bool inBounds arr i = case bounds arr of (l, u) -> i >= l && i <= u makeArray1 :: Int -> [Char] -> ST s (STArray s Int Char) makeArray1 len str = newListArray (1, len) str loop :: STArray s Int Char -> STArray s Int Char -> Int -> ST s Int loop srca dsta n = do if (inBounds srca n) && (inBounds dsta n) then do a <- {-# SCC "alloc_a" #-} readArray srca n b <- {-# SCC "alloc_b" #-} readArray dsta n {-# SCC "loop_if" #-} if a == b then (loop srca dsta (n+1)) else (return n) else return n

3 2

RE: Profiling under 6.4.1 and Solaris segfaults
by Simon Peyton-Jones 02 Sep '05

02 Sep '05

Does this happen on anything other than Solaris? We don't have local access to Solaris hardware at the moment. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Nils Anders Danielsson | Sent: 29 August 2005 18:04 | To: glasgow-haskell-users(a)haskell.org | Subject: Profiling under 6.4.1 and Solaris segfaults | | Running a simple Hello World program compiled with a GHC 6.4.1 | snapshot (20050820) and profiling turned on (-prof -auto-all) under | Solaris results in a segfault. The core dump is similar to a core dump | posted earlier | (http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg04621.h tml): | | (gdb) where | #0 0x0003df8c in EnterFunCCS () | #1 0x0004a714 in stg_PAP_info () | #2 0x00045538 in schedule () | #3 0x00045ff8 in waitThread_ () | #4 0x00045f48 in scheduleWaitThread () | #5 0x0004258c in rts_evalLazyIO () | #6 0x0003bea8 in main () | | The other core dump was due to not compiling the entire program with | profiling turned on. However, the profiling libraries are installed, | so I see no reason why that should be the case now. On the other hand, | when I compile with -fno-implicit-prelude (and main = main), I don't | get a core dump. | | Have other Solaris users experienced something similar? I don't have | any problems with the Linux snapshot from the same day. | | -- | /NAD | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0