- Glasgow-haskell-users

RE: how much can %alloc in profiling be trusted
by Hal Daume 10 Jul '03

10 Jul '03

Hi Simon, All, By SCC'ing the code myself, it seems that most of the allocation is coming from the SCCs dot4 and size'2 in the following: cosine :: Vector -> Vector -> Double cosine v1 v2 = case dot v1 v2 0 of n | n <= 0 -> 0 | otherwise -> n / (size v1 * size v2) where dot [] _ n = {-# SCC "dot1" #-} n dot _ [] n = {-# SCC "dot2" #-} n dot xl@((x,xv):xs) yl@((y,yv):ys) n = case x `compare` y of EQ -> {-# SCC "dot3" #-} (dot xs ys $! (xv * yv + n)) LT -> {-# SCC "dot4" #-} (dot xs yl n) GT -> {-# SCC "dot5" #-} (dot xl ys n) size l = sqrt $! size' l 0 size' [] n = {-# SCC "size'1" #-} n size' ((_,x):xs) n = {-# SCC "size'2" #-} (size' xs $! (n + x*x)) The only reason dot4 dominates rather than dot5 is that it's called about 30 times more frequently (by chance). Looking at the simpl-core from -ddump-simpl, and not knowing too much about how to read it, it vaguely looks to me light GHC has un-tail-recursified the dot function: (in definition of Main.$wdot) case GHC.Prim.<# x# y# of wild5 { GHC.Base.True -> __scc {dot4 Main} case Main.$wdot a3 wild1 ww of ww1 { __DEFAULT -> GHC.Float.D# ww1 }; Now I know the semantics of core is a bit different than Haskell, but this seems to no longer be tail recursive (it needs to rebox the Double# after the recursive call). Am I reading this correctly? - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -----Original Message----- > From: Simon Peyton-Jones > Sent: Thursday, July 10, 2003 2:38 AM > To: Hal Daume; glasgow-haskell-users(a)haskell.org > Subject: RE: how much can %alloc in profiling be trusted > > > It should be accurate. Hard to say more without > investigating your program in detail. > > Try -ddump-simpl (with your profiling flags) to see how your > function looks just before code generation. > > Simoin > > | -----Original Message----- > | From: glasgow-haskell-users-admin(a)haskell.org > [mailto:glasgow-haskell-users-admin@haskell.org] > | On Behalf Of Hal Daume > | Sent: 09 July 2003 23:17 > | To: glasgow-haskell-users(a)haskell.org > | Subject: how much can %alloc in profiling be trusted > | > | In my program, I get the following time/allocation information for a > | call to my cosine function: > | > | individual inherited > | COST CENTRE no. entries %time %alloc %time %alloc > | cosine 2721 43.1 74.3 43.1 74.3 > | > | this is a shocking amount of allocation, considering the > definition of > | the function: > | > | cosine :: Vector -> Vector -> Double > | cosine v1 v2 = > | case dot v1 v2 0 of > | n | n <= 0 -> 0 > | | otherwise -> n / (size v1 * size v2) > | where > | dot [] _ n = n > | dot _ [] n = n > | dot ((x,xv):xs) ((y,yv):ys) n = > | case x `compare` y of > | EQ -> dot xs ys $! (xv * yv + n) > | LT -> dot xs ((y,yv):ys) n > | GT -> dot ((x,xv):xs) ys n > | -- size = sqrt . sum . map (square . snd) > | size l = sqrt $! size' l 0 > | size' [] n = n > | size' ((_,x):xs) n = size' xs $! n + x*x > | > | where Vector = [(Int,Double)] is a sparse vector > representation. This > | was even higher (moderately) until I switched from the old > to the new > | definition of size listed there. > | > | You can't blame this on the fact that the two vectors are > being passed > | lazily either: they're being read strictly from a file and > even seq'd > | before being put into the list. Specifically, we have (v0 > is passed in > | to the function from top-level): > | > | ... do > | v <- readList_H h > | return (cosine v0 v, w) > | > | where readList_H is defined as: > | > | readList_H h = do > | b <- FastIO.isEOF h > | c <- FastIO.fscanfChar h > | if c /= ' ' > | then return [] > | else do > | b <- FastIO.isEOF h > | i <- FastIO.fscanfInt h > | FastIO.fscanfChar h > | v <- FastIO.fscanfFloat h > | rest <- readList_H h > | return ((force (force i,force $ floatToDouble v)) : rest) > | where force x = x `seq` x > | > | as far as i can tell, all the list allocation should be > happening here. > | (the forces were not there in the beginning -- I added them > later but it > | changed nothing.) > | > | - Hal > | > | -- > | Hal Daume III | hdaume(a)isi.edu > | "Arrest this man, he talks in maths." | www.isi.edu/~hdaume | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

GHC 6.0 on Win32: warning!
by Simon Peyton-Jones 10 Jul '03

10 Jul '03

Dear GHC users If you use GHC 6.0 on Win32, read on. Otherwise, don't bother. Some of you have already discovered that GHC 6.0 has a nasty bug: if you go ghci foo\Baz.hs and there is any error at all in Baz.hs, then GHC deletes the source file! This seems like excessive punishment for a type error. So far as I am aware, this only happens * on windows * with ghci (not ghc) * if you put back-slashes in the path There's no problem if you use forward slashes, or no slashes at all. This will be fixed in 6.0.1, which we'll put out in a couple of weeks, but meanwhile you might want to be aware of it. A bit of an egg-on-face job really. Simon

2 1

RE: how much can %alloc in profiling be trusted
by Simon Peyton-Jones 10 Jul '03

10 Jul '03

It should be accurate. Hard to say more without investigating your program in detail. Try -ddump-simpl (with your profiling flags) to see how your function looks just before code generation. Simoin | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Hal Daume | Sent: 09 July 2003 23:17 | To: glasgow-haskell-users(a)haskell.org | Subject: how much can %alloc in profiling be trusted | | In my program, I get the following time/allocation information for a | call to my cosine function: | | individual inherited | COST CENTRE no. entries %time %alloc %time %alloc | cosine 2721 43.1 74.3 43.1 74.3 | | this is a shocking amount of allocation, considering the definition of | the function: | | cosine :: Vector -> Vector -> Double | cosine v1 v2 = | case dot v1 v2 0 of | n | n <= 0 -> 0 | | otherwise -> n / (size v1 * size v2) | where | dot [] _ n = n | dot _ [] n = n | dot ((x,xv):xs) ((y,yv):ys) n = | case x `compare` y of | EQ -> dot xs ys $! (xv * yv + n) | LT -> dot xs ((y,yv):ys) n | GT -> dot ((x,xv):xs) ys n | -- size = sqrt . sum . map (square . snd) | size l = sqrt $! size' l 0 | size' [] n = n | size' ((_,x):xs) n = size' xs $! n + x*x | | where Vector = [(Int,Double)] is a sparse vector representation. This | was even higher (moderately) until I switched from the old to the new | definition of size listed there. | | You can't blame this on the fact that the two vectors are being passed | lazily either: they're being read strictly from a file and even seq'd | before being put into the list. Specifically, we have (v0 is passed in | to the function from top-level): | | ... do | v <- readList_H h | return (cosine v0 v, w) | | where readList_H is defined as: | | readList_H h = do | b <- FastIO.isEOF h | c <- FastIO.fscanfChar h | if c /= ' ' | then return [] | else do | b <- FastIO.isEOF h | i <- FastIO.fscanfInt h | FastIO.fscanfChar h | v <- FastIO.fscanfFloat h | rest <- readList_H h | return ((force (force i,force $ floatToDouble v)) : rest) | where force x = x `seq` x | | as far as i can tell, all the list allocation should be happening here. | (the forces were not there in the beginning -- I added them later but it | changed nothing.) | | - Hal | | -- | Hal Daume III | hdaume(a)isi.edu | "Arrest this man, he talks in maths." | www.isi.edu/~hdaume | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

passing a Handle to a C function
by Hal Daume 10 Jul '03

10 Jul '03

I have a C function that, for simplicity, has its definition as something like: > void myCFun(FILE *fd); I have a Handle I've opened in Haskell using openFileEx and would like to pass this to the function. I've tried a bunch of things, the most recent being: > foreign import ccall "myHFile.h myCFun" c__myCFun :: Ptr CInt -> IO () > myCFun :: Handle -> IO () > myCFun (FileHandle handleMV) = do > h__ <- readMVar handleMV > ptr <- malloc > poke ptr (toCInt $ haFD h__) > c__initVars ptr i've also tried it with just CInt -> IO (), without the ptr, but that doesn't work either. Surely someone has done this at some point...or is it even possible (please say it is)... - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

4 3

how much can %alloc in profiling be trusted
by Hal Daume 09 Jul '03

09 Jul '03

In my program, I get the following time/allocation information for a call to my cosine function: individual inherited COST CENTRE no. entries %time %alloc %time %alloc cosine 2721 43.1 74.3 43.1 74.3 this is a shocking amount of allocation, considering the definition of the function: cosine :: Vector -> Vector -> Double cosine v1 v2 = case dot v1 v2 0 of n | n <= 0 -> 0 | otherwise -> n / (size v1 * size v2) where dot [] _ n = n dot _ [] n = n dot ((x,xv):xs) ((y,yv):ys) n = case x `compare` y of EQ -> dot xs ys $! (xv * yv + n) LT -> dot xs ((y,yv):ys) n GT -> dot ((x,xv):xs) ys n -- size = sqrt . sum . map (square . snd) size l = sqrt $! size' l 0 size' [] n = n size' ((_,x):xs) n = size' xs $! n + x*x where Vector = [(Int,Double)] is a sparse vector representation. This was even higher (moderately) until I switched from the old to the new definition of size listed there. You can't blame this on the fact that the two vectors are being passed lazily either: they're being read strictly from a file and even seq'd before being put into the list. Specifically, we have (v0 is passed in to the function from top-level): ... do v <- readList_H h return (cosine v0 v, w) where readList_H is defined as: readList_H h = do b <- FastIO.isEOF h c <- FastIO.fscanfChar h if c /= ' ' then return [] else do b <- FastIO.isEOF h i <- FastIO.fscanfInt h FastIO.fscanfChar h v <- FastIO.fscanfFloat h rest <- readList_H h return ((force (force i,force $ floatToDouble v)) : rest) where force x = x `seq` x as far as i can tell, all the list allocation should be happening here. (the forces were not there in the beginning -- I added them later but it changed nothing.) - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

1 0

RE: passing a Handle to a C function
by Kevin S. Millikin 09 Jul '03

09 Jul '03

Hal, I was really hoping that someone would have a pretty answer for you by now. Just this last week, I came up with a similar problem--I need to pass a handle to some foreign code, but in my case, the foreign code can treat the handle as opaque, it just needs to be able to give it back to Haskell when needed. I haven't actually solved my problem in a nice way (though your posted code suggests a way, using the file descriptor). > foreign import ccall "myHFile.h myCFun" c__myCFun :: Ptr CInt -> IO () > myCFun :: Handle -> IO () > myCFun (FileHandle handleMV) = do > h__ <- readMVar handleMV > ptr <- malloc > poke ptr (toCInt $ haFD h__) > c__initVars ptr Do you mean c__myCFun instead of c__initVars? What is toCInt? Is it doing anything wierd? Anyway, might this work? > foreign import ccall "myHFile.h myCFun_stub" c__myCFun :: CInt -> IO () > myCFun :: Handle -> IO () > myCFun (FileHandle handleMV) = > readMVar handleMV >>= c__myCFun . toCInt . haFD To pass a CInt (no need for Ptr here) to a stub function in C, where the stub function just converts the file descriptor to a FILE * and calls yourCFun (I mean, myCFun): void myCFun_stub(int fd) { FILE *f = fdopen(fd, "w"); myCFun(f); fflush(f); } It worked for writing to a text file in a simple test, and for writing to stdout. I needed to fflush on the C side when writing to the file. ---- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture (952)829-5864 x162 http://www.atcorp.com

1 0

BENACHRICHTIGUNG ZUR MAIL ZUSTELLUNG
by Mailer-Daemon＠kirchgruppe.de 09 Jul '03

09 Jul '03

Sehr geehrter Internet Email Benutzer, dies ist eine automatisierte Benachrichtung zur Mailzustellung, da Ihre Email nicht auf die gewohnte Art und Weise zugestellt werden konnte. Es ist folgendes Problem aufgetreten: In dieser Mail wurde ein Virus mit folgender Kennung gefunden: the W32/Sobig.e@MM virus !!! Mit freundlichen Gruessen, Ihr GeNUGate Mail-Gateway. =========================================================== In English =========================================================== Dear Internet Email User, this is an automated mail delivery notification, because your email has not been delivered the usual way. Your mail was not deliverd for the following reason: This mail contained a virus with the following Virus-Id: the W32/Sobig.e@MM virus !!! Best regards, Your GeNUGate Mail Gateway ========================================================= ENVELOPE INFORMATION ========================================================= FROM = glasgow-haskell-users(a)haskell.org RCPT = Sven_Panne(a)BetaResearch.de ========================================================= HEADER INFORMATION ========================================================= Received: from smtp02do.de.uu.net (192.76.144.69) by (smtprelay) with ESMTP Wed Jul 9 17:22:10 2003. Received: from SISTEMAS15 ([200.24.7.180]) by smtp02do.de.uu.net (8.9.3p2/5.5.5) with ESMTP id RAA16287 for <Sven_Panne(a)BetaResearch.de>; Wed, 9 Jul 2003 17:22:05 +0200 (MET DST) From: glasgow-haskell-users(a)haskell.org Message-Id: <200307091522.RAA16287(a)smtp02do.de.uu.net> To: <Sven_Panne(a)BetaResearch.de> Subject: Re: Application Date: Wed, 9 Jul 2003 10:23:03 --0500 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_008BE4BE" =========================================================

1 0

scavenge_mutable_list: strange object?
by Johannes Waldmann 09 Jul '03

09 Jul '03

I sometimes get this error: > internal error: scavenge_mutable_list: strange object? 3 ( large program, running on debian linux on i368, compiled with ghc-6.0 -pgmc gcc-2.95 --make -O2 -fvia-C -funbox-strict-fields ) what can I do to a) work around this, b) help finding/fixing the reason? -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/209 --

2 1

RE: Nightly development snapshots?
by Simon Peyton-Jones 09 Jul '03

09 Jul '03

Hmm. That's odd. It'll have to wait till Simon M gets back from holiday though. Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Kirsten Chevalier | Sent: 09 July 2003 04:02 | To: glasgow-haskell-users(a)haskell.org | Subject: Nightly development snapshots? | | The most recent snapshot listed on | <http://www.haskell.org/ghc/dist/current/dist/> is dated May 26 -- will | development snapshots be made available again sometime? | | Thanks, | Kirsten | | -- | Kirsten Chevalier * krc(a)uclink.berkeley.edu * Often in error, never in doubt | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Nightly development snapshots?
by Kirsten Chevalier 09 Jul '03

09 Jul '03

The most recent snapshot listed on <http://www.haskell.org/ghc/dist/current/dist/> is dated May 26 -- will development snapshots be made available again sometime? Thanks, Kirsten -- Kirsten Chevalier * krc(a)uclink.berkeley.edu * Often in error, never in doubt

1 0