Re: How MD are .hi files?
On Wed, May 14, 2008 at 11:35:36AM +0100, Simon Marlow wrote: > >for an unregisterised ghc-6.8.2 (or newer), are the .hi files > >dependent (except for the 32 vs. 64 bit word size)? I had a quick > >look at the stuff in compiler/iface, but the only MD part I found > >was that 32/64 bit difference. > > The word size is probably the only dependency, but there are many reasons > that you can't just take the .hc/.hi files generated by an unregisterised > build on one machine and expect them to work on another machine. I really don't expect this. I just decided to be lazy and provide not only .hc files but also .hi files[1] for the OpenBSD port, and then I thought: "does this make sense at all? Can it even be of use for porting GHC to other archs on OpenBSD, or for the NetBSD folks working on GHC?" Ciao, Kili [1] Of course, the correct solution would not need the .hi files, but just use the stage1 bootstrapped from .hc files to start rebuilding the libraries. But that would require even more hacking on the Makefiles, and I've already an insane amount of hacks sitting around. -- It compiles -- let's ship it! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Performance: Faster to define a function writing out all arguments?
Hi. Simon Peyton-Jones wrote: | I've definitely run into the odd other case where point-freeing | a bit of code messes with the complexity. That should not happen -- except for the state-hack. Which is this: Consider f1 :: Char -> IO () f1 = \c. let i = ord c in \s. print i s Here s::State World. Is this equivalent to f2 = \c.\s. print (ord c) s The latter is very much more efficient than 'f1', because it doesn't build an intermediate lambda. This matters a lot in I/O-intensive programs. But if 'f' is called thus: forever (f 'w') then (ord 'w') is computed once for each call of f2, but is shared among all calls to f1. And that can make a big difference too. Thanks for the explanation. State World here really means the IO and ST monad, not the State monad, right? Compiling with -fno-state-hack actually does actually lead to both versions (the point-free and explicit) being equally fast (14.4s instead of 15.2s resp. 14.0s). Though I am not sure why. Running in profiled mode makes all difference vanish. I tested this on an Intel(R) Pentium(R) 4 CPU 3.00GHz and got the reported speed difference there. Using instead an AMD Athlon(tm) 64 Processor 3800+ I got no difference even without using -fno-state-hack. I have no idea whether this is playing a role in the example you are discussing -- my guess is not, and there may be another performance bug lurking. So eliciting a small demo would be great. I am sorry, I completely failed to do that. The parser builds up a data structure from several data types using memoization. Any significant simplification of the code base reduced the performance gap until it quickly disappeared. Alexander ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: laziness, memoization and inlining
Simon, Don, You're right. -fno-state-hack fixed it. I've opened a trac ticket. Program and test data are there. http://hackage.haskell.org/trac/ghc/ticket/2284 Scott On Wed, May 14, 2008 at 1:48 AM, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: > Scott > > | I'm experiencing some undesirable performance behavior, I suspect from > | inlining things that shouldn't be, defeating my memoization attempts. > > This is bad, very bad. I think Don is right. I believe the following is > happening. In your main program you have > > do let mesh = memoMesh rawMesh > display :: IO () >display = draw mesh >> stuff >setDisplayCallback display >glutMainLoop > > So the effect is that 'display' is performed many times, by glutMainLoop. > > Now 'display' is seen by GHC thus: >display = \s -> draw mesh s >> stuff > > The "\s" says "given the state of the world, s, I'll draw the mesh on it". > The "state hack" makes GHC think that a "\s" will only ever be called once > (which is utterly false in this case), so it can inline mesh=memoMesh > rawMesh. Result disaster. > > > I bet you'll be fine if you compile your main module with -fno-state-hack. > > But I should fix this, somehow. It's coming up too often to justify the > hack. Can you make a Trac bug report, and include your message and this one? > > Thanks for reporting it. > > Simon > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How do I check the optimisation level of the built-in splitAt? Is something other than -O2 giving me my speed increase?
Hello Glasgow-Haskell Users, It was suggested to me in this thread in Haskell-Cafe http://www.haskell.org/pipermail/haskell-cafe/2008-May/042797.html which was a subsidiary of a previous thread http://www.haskell.org/pipermail/haskell-cafe/2008-April/042155.html that there might be some reason other than the -O2 optimisation level I applied to my version of splitAt that was making my program run about 30% faster than when I used the built-in splitAt. Can somebody tell me how to check what the -O level is for the built-in splitAt? Or alternatively tell me what the optimisation level is for the libraries. (Sorry I'm not sure of the right terminology for these built-in / library / Prelude things.) Richard. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How MD are .hi files?
Matthias Kilian wrote: Hi, for an unregisterised ghc-6.8.2 (or newer), are the .hi files dependent (except for the 32 vs. 64 bit word size)? I had a quick look at the stuff in compiler/iface, but the only MD part I found was that 32/64 bit difference. The word size is probably the only dependency, but there are many reasons that you can't just take the .hc/.hi files generated by an unregisterised build on one machine and expect them to work on another machine. First, you have to watch out for conditional compilation in the original Haskell source file. For example, if the .hs file contains something like #ifdef mingw32_HOST_OS, then the .hc and .hi files will both be Windows-only. There are certainly many instances of this in the libraries right now. Another problem is the configuration information that gets into the build via the autoconf scripts. Things like the size of C types in Foreign.C.Types, or the errno values in Foreign.C.Error might be different on the target machine. I hope I've managed to understand your question correctly... if not please ask again! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: small and compact ghc distribution
Bulat Ziganshin-2 wrote: > > 1. you can use winhugs - it's more user-friendly. and need only ~10mb > in stripped installation > That's what I'm using for now, but I need GHC's compilation capability. Bulat Ziganshin-2 wrote: > > 2. you can try to delete all the unneeded libs from ghc distro. in > particular, all those *_p* files are just profiling versions - you > don't need them > OK, I'll try. Bulat Ziganshin-2 wrote: > > 3. i think that ghc should work without gcc at all > Yes, but to scan and delete which files are belong to GHC and which are belong to GCC is quite difficult. That's why I ask for a pre-made (or pre-cleaned) one. -- View this message in context: http://www.nabble.com/small-and-compact-ghc-distribution-tp17223701p17225910.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: laziness, memoization and inlining
Scott
| I'm experiencing some undesirable performance behavior, I suspect from
| inlining things that shouldn't be, defeating my memoization attempts.
This is bad, very bad. I think Don is right. I believe the following is
happening. In your main program you have
do let mesh = memoMesh rawMesh
display :: IO ()
display = draw mesh >> stuff
setDisplayCallback display
glutMainLoop
So the effect is that 'display' is performed many times, by glutMainLoop.
Now 'display' is seen by GHC thus:
display = \s -> draw mesh s >> stuff
The "\s" says "given the state of the world, s, I'll draw the mesh on it". The
"state hack" makes GHC think that a "\s" will only ever be called once (which
is utterly false in this case), so it can inline mesh=memoMesh rawMesh. Result
disaster.
I bet you'll be fine if you compile your main module with -fno-state-hack.
But I should fix this, somehow. It's coming up too often to justify the hack.
Can you make a Trac bug report, and include your message and this one?
Thanks for reporting it.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Scott Dillard
| Sent: 14 May 2008 00:13
| To: glasgow-haskell-users@haskell.org
| Subject: laziness, memoization and inlining
|
| Hi Everybody,
|
| I'm experiencing some undesirable performance behavior, I suspect from
| inlining things that shouldn't be, defeating my memoization attempts.
| I've been experimenting with purely functional 3D modeling code, so a
| mesh is (initially) something like
|
| > type Mesh = Map (Int,Int) (Int,Int)
|
| that is, a function from from an edge to the next edge around the
| face, where an edge is a pair of Ints (the vertices.)
|
| This nice and pure and everything, but its slow to read from. So I
| have another immutable pointer-based representation
|
| > data Edge = Edge { edgeOrg :: Int , edgeSym :: Edge , edgeNext :: Edge }
|
| which is something like a half-edge, for those familiar with such
| things. Its basically a big net made of circular lists that are tied
| together. I do the knot tying stuff to create this thing,
|
| > memoMesh :: Map (Int,Int) (Int,Int) -> Edge Int
| > memoMesh nexts = head $ Map.elems ties
| > where
| > ties = Map.mapWithKey (\ij _ -> make ij) nexts
| > lookup ij = trace "hello" $ fromJust $ Map.lookup ij ties
| > make ij@(i,j) = Edge i (lookup (j,i)) (lookup . fromJust $ Map.lookup
ij nexts)
|
| The program first loads the model file and creates the Edge-based mesh
| using the memoMesh function. The result is then captured in the
| closure for the rendering callback in GLUT. When I compile with -O0 I
| see the "hello" traces only during the first drawing. Subsequent
| redraws are fast and output no traces. When I compile with -O1 or -O2,
| the traces get output on every redraw, and its very slow. I suspect
| all of the calls which create the mesh are inlined into the rendering
| callback, effectively rebuilding the mesh on every draw.
|
| I've tried littering NOINLINE pragmas all around, to no avail.
|
| The main function is something like
|
| > main = do
| > initGlut ...
| > rawMesh <- loadMeshFile ...
| > let
| > mesh = memoMesh rawMesh
| > otherstuff = ...
| > display =
| > draw mesh >> amongOtherThings
| > displayCallback $= display
| > glutMainLoop
|
| Can someone help me understand what's going on here? Is there a nice
| solution to this, hopefully a single strategic pragma or something?
|
| Scott
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: small and compact ghc distribution
Hello leledumbo, Wednesday, May 14, 2008, 11:31:41 AM, you wrote: > I'm a college student and I just want to learn functional programming with > Haskell. No need to access libraries other than GHC rtl (or whatever you > call it). > I already have gcc on my machine, does GHC still need its own? > Will there be any small and compact GHC distribution (if someone wants to > make it, I'd be very grateful)? 1. you can use winhugs - it's more user-friendly. and need only ~10mb in stripped installation 2. you can try to delete all the unneeded libs from ghc distro. in particular, all those *_p* files are just profiling versions - you don't need them 3. i think that ghc should work without gcc at all -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
small and compact ghc distribution
Currently, GHC distribution is VERY BIG (about 410 MB). 2 Things that I noticed which contributed most of this problem are: libraries (about 220 MB) and GCC and friends compiler (including perl, ar, as, ld, etc). I'm a college student and I just want to learn functional programming with Haskell. No need to access libraries other than GHC rtl (or whatever you call it). I already have gcc on my machine, does GHC still need its own? Will there be any small and compact GHC distribution (if someone wants to make it, I'd be very grateful)? -- View this message in context: http://www.nabble.com/small-and-compact-ghc-distribution-tp17223701p17223701.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
