- Glasgow-haskell-users

Re: Having to use -static flag under Win32 with 4.08 & Cygwin 1.1.6
by Reuben Thomas 18 Dec '00

18 Dec '00

> From: Jeremy Shute [mailto:shutej@rpi.edu] > I've been perusing the documentation looking for what I've done wrong... Nothing; the docs aren't quite up-to-date. > 7. Confirmed that these files exist nowhere on the partition. Messed > around some more to no avail, came across static flag and tried that: We don't supply the DLLs any more, because they subtly and rarely don't work for reasons I don't fully understand (though I've spent a long time trying to). If you really want them (why?) you'll have to build them. -- http://sc3d.org/rrt/ | maximiste, n. pessimiste

1 0

Having to use -static flag under Win32 with 4.08 & Cygwin 1.1.6
by Jeremy Shute 16 Dec '00

16 Dec '00

Hi, I've been perusing the documentation looking for what I've done wrong... 1. I got the latest versions of both Cygwin and GHC. 2. I installed Cygwin on a clean partition, F: 3. I installed GHC in /usr/share/ghc/ (on F:, of course) 4. I copied the Perl binary over to /bin, and pointed the bang in the ghc script to the location of the binary (I found this a necessary step). 5. I got a little test program from the web: {--------------------------------------} module Main where main = putStrLn "Hello, World!" {--------------------------------------} 6. Tried to compile said program: $ ghc main.hs Output file not specified, defaulting to "main.exe" gcc: F:/usr/share/ghc/lib/Main.dll_o: No such file or directory gcc: F:/usr/share/ghc/lib/PrelMain.dll_o: No such file or directory 7. Confirmed that these files exist nowhere on the partition. Messed around some more to no avail, came across static flag and tried that: $ rm Main.hi main.o $ ghc -static main.hs Output file not specified, defaulting to "main.exe" $ ./main.exe Hello, World! 8. Think I'm onto something so look around for an additional installation step I perhaps did not take, such as building libraries from source shipped with the distro. Nope, can't find any. I can't imagine why that would even be necessary, to support Win32 on Alphas maybe? So alas, here I sit frustrated, waiting for comp.lang.functional, and I figured I'd try you guys. Has anyone else had this problem? If not, perhaps you still have an idea of what's going on? This would be much appreciated... Jeremy Shute

1 0

RE: C stack
by Simon Marlow 15 Dec '00

15 Dec '00

> Hi, > > I'm trying to write an interface for a C library that > uses a Boehm type garbage collector. So, I need to get > the address of the bottom of the C stack. In a C > application this would look something like: > main() > { > int bottomOfStack; > } > Where "&bottomOfStack" would be the thing I need. So, > I'd want some function like: > bottomOfStack :: IO Addr > > Would it be possible at all to make an interface to > a C library that uses Boehm's garbage collection ? > What Boehm's algorithm does is traverse the C stack > at each garbage collect marking all accessible > nodes and then sweeping all unmarked nodes. Would > this cause problems with the C code generated by > ghc ? I don't forsee any problems with the C stack - the stack pointer stays static during execution of Haskell code, and only moves when we do a C call or return to the RTS. Don't forget to tell the GC to traverse the Haskell heap too - GHC keeps this in mmapped address space. See fptools/ghc/rts/MBlock.c for the details. Cheers, Simon

2 1

RE: Fun with GHC's optimiser
by Simon Peyton-Jones 15 Dec '00

15 Dec '00

PArrays.$w$snewPArray = \ ww :: PrelGHC.Int# w :: PrelBase.Int -> case PrelGHC.newIntArray# @ PrelGHC.RealWorld ww PrelGHC.realWorld# of wild { (# s2#, mba# #) -> let { eta :: PrelBase.Int __A 0 __C eta = PrelBase.$wI# ww } in case PrelGHC.-# ww 1 of sat { __DEFAULT -> case PrelGHC.># 0 sat of wild1 { PrelBase.True -> PArrays.$wPArray @ PrelBase.Int eta (__coerce PrelGHC.ByteArray# mba#); PrelBase.False -> case w of w1 { PrelBase.I# ww1 -> case PrelGHC.writeIntArray# @ PrelGHC.RealWorld mba# 0 ww1 s2# of s2#1 { __DEFAULT -> case PrelGHC.-# ww 1 of wild2 { 0 -> PArrays.$wPArray @ PrelBase.Int eta (__coerce PrelGHC.ByteArray# mba#); __DEFAULT -> let { a4 :: (PArrays.PArray PrelBase.Int) __A 0 __C a4 = PArrays.$wPArray @ PrelBase.Int eta (__coerce PrelGHC.ByteArray# mba#) } in __letrec { $wgo :: (PrelGHC.Int# -> PrelGHC.State# PrelGHC.RealWorld -> (PrelGHC.State# PrelGHC.RealWorld, PArrays.PArray PrelBase.Int)) __A 2 __C $wgo = \ w2 :: PrelGHC.Int# w3 :: (PrelGHC.State# PrelGHC.RealWorld) -> case PrelGHC.writeIntArray# @ PrelGHC.RealWorld mba# w2 ww1 w3 of s2#2 { __DEFAULT -> case PrelGHC.-# ww 1 of sat1 { __DEFAULT -> case PrelGHC.==# w2 sat1 of wild11 { PrelBase.True -> (# s2#2, a4 #); PrelBase.False -> case PrelGHC.+# w2 1 of sat2 { __DEFAULT -> $wgo sat2 s2#2 } } } }; } in case $wgo 1 s2#1 of wild3 { (# ds, r #) -> r } } } } } } } | However, we came across one problem (read, lack of | optimisation on GHC's part), which leads to tedious | duplication of a lot of code in our array library. | Basically, GHC does not recognise for tail recursive | functions when certain arguments (accumulators maintained in | a loop) can be unboxed. This leads to massive overheads in | our code. Currently, we circumvent the inefficiency by | having manually specialised versions of the loops for | different accumulator types and using RULES to select them | where appropriate (based on the type information). I will | send you some example code illustrating the problem soon. Yes please. Meanwhile, in the head, if you specify -O2 you'll get better code for some of your loops, namely the ones that repeatedly evaluate a free variable every time round the loop. The loop is duplicated and everything is nice. Here's a tiny example: g :: Int -> Int g x = let h 0 = 0 h y = if x==0 then y else h (y+1) in h 88 This now compiles to: LC.g = \ x :: PrelBase.Int -> case x of wild { PrelBase.I# x1 -> case x1 of wild1 { 0 -> PrelBase.$wI# 88; __DEFAULT -> __letrec { $wh :: (PrelGHC.Int# -> PrelBase.Int) __A 1 __C $wh = \ ww :: PrelGHC.Int# -> case ww of wild2 { 0 -> LC.lit; __DEFAULT -> case PrelGHC.+# wild2 1 of sat { __DEFAULT -> $wh sat } }; } in $wh 89 } } You mentioned something like this before. The amount of code duplication is controlled by -fliberate-case-threshold20 (say) The default is set pretty low. And it all only happens with -O2. All in the HEAD. The pass is call simplCore/LiberateCase. Simon

2 2

C stack
by Jan Kort 14 Dec '00

14 Dec '00

Hi, I'm trying to write an interface for a C library that uses a Boehm type garbage collector. So, I need to get the address of the bottom of the C stack. In a C application this would look something like: main() { int bottomOfStack; } Where "&bottomOfStack" would be the thing I need. So, I'd want some function like: bottomOfStack :: IO Addr Would it be possible at all to make an interface to a C library that uses Boehm's garbage collection ? What Boehm's algorithm does is traverse the C stack at each garbage collect marking all accessible nodes and then sweeping all unmarked nodes. Would this cause problems with the C code generated by ghc ? Jan

1 0

Transitive inlining
by Manuel M. T. Chakravarty 11 Dec '00

11 Dec '00

In the context of the array library, we stumbled over another problem. Does GHC transitive inlining across modules? Let's say, we have the following scenario: module B (foo) where {-# INLINE foo #-} foo .. = ...bar... {-# INLINE bar #-} bar .. = ... module L (baz) where import B {#- INLINE baz #-} baz .. = ...B.foo... module Main where import L main .. = ...L.baz... GHC in this case inlines the whole expression "...B.foo..." in `Main', but will it inline the right hand side of `B.bar' in `Main' (or even of `B.foo')? If the INLINE pragma is transitive across modules boundaries, one would hope so. It seems that GHC is not (always?) doing this inlining, which already for a very simple benchmark costs us a factor of 5 runtime! (With inlining - enforced by copying definitions manually into `Main' - the code produced by GHC is actually a little bit faster than the code for the corresponding C program). Cheers, Manuel PS: I had problems building GHCi and it seems as if my message to cvs-ghc(a)haskell.org doesn't get through somehow...

2 1

RE: Beginners profiling question
by Simon Marlow 11 Dec '00

11 Dec '00

> Your picture shows that sat uses 12% of the time, and main > uses 99% which is > fine because it inherites all time usage. But main really > only calls sat, like > so: > > main = do > ~[rnastr] <- getArgs > print (sat (str2inp rnastr (0::Int))) > > str2inp is just a small data conversion routines for sat. So where > does all the time go? Probably in "print". Yes, the Prelude isn't compiled with -auto-all (or even -auto) by default. We'll probably start doing this when the better profile viewers come on-line. Cheers, Simon

1 0

RE: Beginners profiling question
by Simon Marlow 11 Dec '00

11 Dec '00

> So I have tried profiling the first time... > > using ghc-4.08.1 with options -prof -auto-all > runtime option -px > ghcprof and daVinci work like a charm > > what I see is > > main uses 99.90 % time and space > sat for practical purposes is the only function called from main and > uses ca. 12 % time and space > > what am I doing wrong... > Prelude not compiled for profiling? I'm not sure what you're expecting to see - the profile looks reasonable to me. Why do you think it's wrong? Ah, perhaps you're worried that the percentages don't add up to 100%: that's because they're "inherited", i.e. sat's costs form part of the total costs of main, because main called sat. The daVinci browser has a button to turn off inherited stats, as I recall. BTW, we're working on a new profile viewer. Here is a screenshot showing your profile: http://research.microsoft.com/~simonmar/pview.jpg the user interface is little rough at the moment, but you can see the general idea. Cheers, Simon

2 1

RE: Beginners profiling question
by Simon Peyton-Jones 08 Dec '00

08 Dec '00

| No answer? | Is the question too stupid? not at all. just no one with time to answer today. posting your program too would be a useful thing to do. Simon

1 0

Beginners profiling question
by Dirk Evers 08 Dec '00

08 Dec '00

So I have tried profiling the first time... using ghc-4.08.1 with options -prof -auto-all runtime option -px ghcprof and daVinci work like a charm what I see is main uses 99.90 % time and space sat for practical purposes is the only function called from main and uses ca. 12 % time and space what am I doing wrong... Prelude not compiled for profiling? Thanks in advance Dirk --- +---------------------------------------------------------------------+ | Dirk Evers Office: M3-120 | | Technische Fakultaet / AG PI Tel: +49 521 106-2905 | | Universitaet Bielefeld FAX: +49 521 106-6411 | | D-33594 Bielefeld e-mail: dirk(a)TechFak.Uni-Bielefeld.DE | | Germany URL: http://www.TechFak.Uni-Bielefeld.DE/~dirk/ | |---------------------------------------------------------------------| | Die Succulenten / a cappella singing / http://www.succulenten.de | +---------------------------------------------------------------------+

1 1