Strictness annotations question
Hello, One thing I discovered a while ago when fiddling about with optimisting the AVL library was that making the AVL constructors strict in left and right sub-tree fields resulted in slower code than using no strictness annotation and explicit forcing of evaluation with `seq`. I hope it isn't too presumptious of me to hazard a guess as to what might cause this :-) My guess is that it's because the AVL code contains a lot of stuff like this.. -- With strictness annotations case blah of N l e r - N l e (f r) -- l and r are left and right sub-trees or -- Without strictness annotations case blah of N l e r - let r' = f r in r' `seq` N l e r' Now if the compiler wasn't smart enough to figure out that in the first example l was already reduced (because it's from a strict field) then it would get diverted trying to reduce it again (pointlessly accessing heap record it didn't need, disrupting the cache etc), so the net result would be slower code. But in truth I understand precious little about what analyses and optimisations ghc is capable of, so this could all be complete nonsense. So is this explanation plausible? Also (persuing this a little further) it occurs to me that the if this hypothesis is correct there could be other bad effects. For example, if in an expression I have a constructor with a strict field, but the constructor is used in a non-strict context. Presumably the compiler won't generate this constructor in it's reduced form (whatever that might be for ghc :-) because this would force evaluation of the field value. So it must construct some kind of thunk instead. But there's no reason it should be so inhibited if the constructor was non-strict (or if the compiler could figure out the field value was already reduced). Thanks -- Adrian Hey ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
CVS Repository
Hi, I understand the GHC CVS repository has moved recently? It appears that the document http://www.haskell.org/ghc/docs/latest/html/building/sec-cvs.html hasn't been updated accordingly; could someone with CVS commit access please fix that? Thanks, Peter ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: CVS Repository
On 14 September 2005 11:51, Peter Simons wrote: I understand the GHC CVS repository has moved recently? It appears that the document http://www.haskell.org/ghc/docs/latest/html/building/sec-cvs.html hasn't been updated accordingly; could someone with CVS commit access please fix that? I've updated it in CVS, a new version will get uploaded with the 6.4.1 release. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unsafePerformIO and NOINLINE Pragma
Am Dienstag, 13. September 2005 16:13 schrieb David Sabel:
Hi,
Hi!
I want to analyse the laziness of a data structure. To check how many
nodes are constructed I use a global counter.
counter :: IORef Int
counter = unsafePerformIO (newIORef 0)
This counter is increased every time the constructor is called by
redefining the constructor OBDD as follows.
oBDD low var high =
seq (unsafePerformIO (modifyIORef counter (+1))) (OBDD low var high)
This works fine.
When I compile with optimisations the counter is always set to one no
matter how many nodes are constructed. I thought this would be caused by
inlining. Therefore I have added two NOINLINE pragmata.
{-# NOINLINE counter #-}
{-# NOINLINE oBDD #-}
Although the counter doesn't work. Is there another optimisation that can
cause harm? Is there something wrong with the pragmata?
Two comments:
1. There are other optimisations than inlining that can break sharing, e.g.
common subexpression elimination, full-laziness-transformation.
2. I tested the following:
{-# NOLINE counter #-}
{-# INLINE oBDD #-}
then the counter seems to work correct. In my opinion
oBDD is an abstraction and can always be inlined.
Sadly this solution doesn't work in my environment. The counter is always set
to 2 while it should be something around 15.000. I think it's not worth going
into detail of the transformations for me thus I will check the number of
nodes without optimisations and the performance with optimisations. Thanks
anyway.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: FFI: calling Haskell from C++?
Theres been a bit of traffic about calling Haskell from C++ recently, and I know that calling C++ from Haskell is a frequently asked question. (E.g. Koen Claessen was asking me about it this week.) It also seems to be somewhat platform dependent. (Esp on Windows, I think.) Would someone like to write up a description of how to successfully call out from Haskell to C++ and vice versa, using GHC? If you did, wed gladly include the result in the user manual, and save others a lot of head scratching. Maybe there are simple things we could do to GHC to make the process simpler. But what it needs is someone who knows C++ well to write a coherent story. Please! Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Neswold Sent: 13 September 2005 16:45 To: Felix Breuer Cc: glasgow-haskell-users@haskell.org Subject: Re: FFI: calling Haskell from C++? On 9/13/05, Felix Breuer [EMAIL PROTECTED] wrote: $ ghc -fffi Foo.o Foo_stub.o main.cpp main.o(.text+0x22): In function `main': main.cpp: undefined reference to `__stginit_Foo()' main.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0' collect2: ld returned 1 exit status In main.cpp, you need to define __stginit_Foo(void) like this: extern C void __stginit_Foo(void); Specifying the C linkage with prevent the compiler from looking for a name-mangled version of the function. To fix the second problem, you need to shut off exception handling (specifying the -fno-exceptions option ought to do this. I don't know how to pass compiler option via ghc, though. -- Rich AIM : rnezzy ICQ : 174908475 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI: calling Haskell from C++?
On 9/14/05, Simon Peyton-Jones [EMAIL PROTECTED] wrote: There's been a bit of traffic about calling Haskell from C++ recently, and I know that calling C++ from Haskell is a frequently asked question. Would someone like to write up a description of how to successfully call out from Haskell to C++ and vice versa, using GHC? If you did, we'd gladly include the result in the user manual, and save others a lot of head scratching. Maybe there are simple things we could do to GHC to make the process simpler. But what it needs is someone who knows C++ well to write a coherent story. Please! I'm flattered that you quoted my message, but I'm not familiar with the foreign language interface; I started looking at Haskell only a few weeks ago. I was able to fix the first problem, since the name-mangler is always a problem when mixing other languages with C++. The second error I may or may not have got right. The other solution recommended that the C++ library be linked which fixes the undefined exception handling symbols. I'm curious what would happen if Haskell called down into C++ code and then an exception was thrown... Anyways, I think your suggestion is a good one and I would be willing to answer any C++ questions that anyone has when writing such a document. -- RichAIM : rnezzyICQ : 174908475 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI: calling Haskell from C++?
On Wed, 14 Sep 2005 16:05:26 +0100 Simon Peyton-Jones [EMAIL PROTECTED] wrote: Would someone like to write up a description of how to successfully call out from Haskell to C++ and vice versa, using GHC? I could write up a summary of our experiences calling Haskell from C++, but as I have no in depth knowledge of the interna, that summary would be anything but comprehensive, so I am not sure I am the right man for the job. Right now we have to use GHC to link the entire project (including the C++ part) because we have to rely on --make to figure out which GHC libraries (i.e. which .o files in /usr/lib/ghc-6.4) we need to link against. We would like to do the linking manually (via g++). Now: * Is there a way to have GHC link only the Haskell part of the project (including libraries) and create an .o file? * Alternatively: Is there a way to have GHC return dependency information _including_ information about GHC libs? (I know about -M but that does not include info about needed libraries) Thanks, Felix ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
