- Glasgow-haskell-users

RE: Accessing new heap costs more than old?
by Simon Marlow 12 Sep '05

12 Sep '05

On 05 September 2005 19:38, Adrian Hey wrote: > On Monday 05 Sep 2005 5:42 pm, Jan-Willem Maessen wrote: >> This agrees with my theory. > > Thanks, I'm sure this must be the explanation. I guess the moral of > the story is that for comparative benchmarks you really do need to > make sure you're comparing like with like. Very small differences in > test method can have a significant impact on running time it seems. Can you confirm the hypotheses by inspecting the output from +RTS -sstderr, which tells you the breakdown of GC vs. mutator time? Cheers, Simon

2 1

RE: profile not showing it all?
by Simon Marlow 12 Sep '05

12 Sep '05

On 09 September 2005 15:58, Niels wrote: > Bulat Ziganshin wrote: >> i don't know what value shows the -xc oprion, but memory usage in >> ghc-compiled program are increased because by default used "copying" >> garbage collection algorithm. using option "+RTS -c" will >> significantly reduce memory usage, which will make program faster if >> it currently needs swapping. you can also force, for example, using >> of compacting algorithm when memory usage grows more than 200 mb with >> options "+RTS -M1G -c20". see "4.14.2. RTS options to control the >> garbage collector" in ghc docs for details > running the profilingbinary (that was compiled with -prof -auto-all) > with the -c option resulted in; > > top: showing a max of 161mb memory usage > profiled-graph: showing a peak at a little more than 80mb > > i guess these results are more or less normal? It does however mean > that my datastructures are pretty harsh on the garbage collector, > doesnt it? The difference between the residency displayed by the heap profiler and the actual memory residency can be attributed to several factors (some of which have already been mentioned, I thought I'd list them for completeness): - overhead of profiling itself, which currently runs at 2 extra words per heap object. At a guess, that probably results in about a 30% overhead. - generational garbage collection. A major GC in the standard copying collector will usually require 3L bytes of memory, where L is the amount of live data. This is because by default (see the +RTS -F option) we allow the old generation to grow to twice its size (2L) before collecting it, and we require additionally L bytes to copy the live data into. When using compacting collection, this is reduced to 2L, and can further be reduced by tweaking the -F option. Additionally the allocation area (generation 0) takes 512Kb by default. - The stack isn't counted in the heap profile by default. See the +RTS -xt option. - The program text itself, the C stack, any non-heap data (eg. data allocated by foreign libraries, and data allocated by the RTS), and mmap()'d memory are not counted in the heap profile. Cheers, Simon

2 2

GHC 6.4 for a Debian distro
by Iavor Diatchki 12 Sep '05

12 Sep '05

Hello, I would like to install the following tools on a Debian Linux distribution (testing flavor): GHC 6.4, alex, happy, darcs (I use Hugs from CVS, so I don't want to install the Debian version) I would also like to be able to update/remove any one of these tools independently (I know enough about the tools to know that they do not need each other to work). Can I achieve this by using debian packages? I can get darcs, happy, and alex to work, but the only GHC 6.4 package I could find (in unstable) conflicts with the others. It also seems to depend on Hugs for some reason. I was able to get a working GHC 6.4 by using "alien" on the Fedora RPMs, but this seems like a rather embarassing (for the Debian distro) solution. Am I doing something wrong here? -Iavor

2 1

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 07 Sep '05

07 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