December 2000 - Glasgow-haskell-users

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

Re: New InstallShield: no more DLLs
by Reuben Thomas 08 Dec '00

08 Dec '00

> Did you already try out a statically linked, stripped DLL on Win2K? Do > you get the same > error? Yes, I did, and I didn't get the error. (At least, not after the latest round of debugging.) > Do you have some idea what's wrong here? Only the idea I had before: that something is going wrong during DLL startup. The best suggestion I've seen is that there's a problem with trying to use the value of uninitialised pointers, and that when they lie within the application address space there's no problem, but when they lie outside, an error is raised. The only guess I have as to why this could be happening (on our side) is the hack used to allow static initialisers in DLLs. On the other hand, there is definitely a problem with the linker, which creates different executables depending on the order in which the libraries are stored on the disk. I'm not sure whether this is causing problems; indeed, the fact that the current problem occurs on some machines and not on others suggests that it is not. It is nevertheless weird, and *can* make the difference between the problem occurring or not (as it did on my machine). So it's a sufficient but not necessary cause. For the moment I'm not investigating this. I will again when I can find the enthusiasm. There's one thing that worries me about your message: are you saying that you can reproduce the problem with a statically linked DLL? I've only ever had the problem with dynamic DLLs. That's one reason that I've given up on it for the moment: it is still possible to use DLLs reliably, as far as I'm concerned. I thought that Arjan only had problems, as I did, with the dynamically linked version. If this is false, I'd better dig a bit more. -- http://sc3d.org/rrt/ | impatience, n. the urge to do nothing

1 0

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

07 Dec '00

Manuel OK, I've improved the eta expander so it does a better job of the code you found. Try now. On the HEAD. Which should compile OK now, incidentally. How's your parallel Haskell stuff coming? Simon | -----Original Message----- | From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au] | Sent: 02 November 2000 13:54 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users(a)haskell.org | Subject: RE: Fun with GHC's optimiser | | | Simon Peyton-Jones <simonpj(a)microsoft.com> wrote, | | > I can never resist messages like these, even when I'm meant | > to be doing other things. | | That's good to know ;-) | | > It's very helpful when people offer | > fairly precise performance-bug reports. Thanks! | | Thanks for the prompt reply! To SimonM, too. | | > | I am wondering whether there is a particular reason why the | > | optimiser doesn't pull the | > | | > | (1) a = NO_CCS PArray! [wild1 mba#]; | > | > This one is a definite bug. It turns out that the head of the | > before-ghci-branch doesn't have this bug, so I'm disinclined | > to investigate it further. | | No problem, I can always build a new ghc from CVS. | | > | (2) case w of wild3 { | > | I# e# -> | > | | > | As for (2), the loop would be nice and straight if that | > | unboxing where outside of the loop - as it is, we break the | > | pipeline once per iteration it seems | > | > This one is a bit harder. Basically we want to make a wrapper | > for a recursive function if it's sure to evaluate its free | variables. | > | > In fact the 'liberate-case' pass (which isn't switched on in 4.08) | > is meant to do just this. It's in simplCore/LiberateCase.lhs, | > and it's not very complicated. I've just tried it and it | doesn't seem | > to have the desired effect, but I'm sure that's for a boring reason. | > If anyone would like to fix it, go ahead! | | Ok - something for a rainy weekend, I guess... | | > Incidentally, you'll find that -ddump-simpl gives you a dump that | > is pretty close to STG and usually much more readable. Most | > performance bugs show up there. -dverbose-simpl gives you more | > clues about what is happening where. | | Good to know. I just wasn't sure whether I wouldn't miss | out on some optimisations. | | > | Also if somebody is looking at the attached source, I was | > | wondering why, when I use the commented out code in | > | `newPArray', I get a lot worse code (the STG code is in a | > | comment at the end of the file). In particular, the lambda | > | abstraction is not inlined, whereas `fill' gets inlined into | > | the code of which the dump is above. Is it because the | > | compiler has a lot harder time with explicit recursion than | > | with fold/build? If so, the right RULES magic should allow | > | me to do the same for my own recursively defined | > | combinators, shouldn't it? | > | > I couldn't figure out exactly what you meant. The only commented | > out code is STG code. Maybe send a module with the actual | > source you are bothered about. | | Appended the version of the module where the code is | activated (it was commented out with --) - you'll find the | problematic code by searching for (**) in the code. It | generates | | $w$snewPArray | = \ ww :: Int# w :: Int -> | case newIntArray# @ RealWorld ww realWorld# | of wild { (# s2#, mba# #) -> | case $wsimpleGen | ww | (\ i :: Int -> | case i of wild1 { I# i# -> | case w of wild2 { I# e# -> | __coerce (ST RealWorld ()) | (\ s# :: (State# RealWorld) -> | case writeIntArray# @ RealWorld mba# i# e# s# | of s2#1 { __DEFAULT -> | (# s2#1, () #) | }) | } | }) | s2# | of wild1 { (# new_s, r #) -> | let { | a :: Int | a = $wI# ww | } in (# a, (__coerce ByteArray# mba#) #) | } | } | | One thing that is not nice is in the lambda abstraction | based to $wsimpleGen. There is one lambda, then two | unboxing operations and another lambda for the state | variables s#. These two nested lambda's become in STG | | stg_c1Op = | NO_CCS[] \r[i] | case i of wild1 { | I# i# -> | case w of wild2 { | I# e# -> | let { | stg_c1Sv = | NO_CCS[] \r[s#] | case | writeIntArray# [mba# i# e# s#] of s2#1 { | DEFAULT -> | (#,#) [s2#1 ()] | }; | } in stg_c1Sv; | }; | }; | | So, stg_c1Sv is allocated and immediately entered. I would | have hoped that the two lambda abstractions are merged into | something like this: | | (\ i :: Int s# :: (State# RealWorld) -> | case i of wild1 { I# i# -> | case w of wild2 { I# e# -> | case writeIntArray# @ RealWorld mba# i# e# s# | of s2#1 { __DEFAULT -> (# s2#1, () #) | }) | } | }) | | Maybe it is the __coerce, which prevents this from | happening? | | Also, I am wondering why in the case of the | | foldr (fill mpa e) (return $ unsafeFreezeMPArray mpa) [0..n-1]) | | the function `fill' gets inlined into the foldr loop, but in | the above, the lambda abstraction gets not inlined into | $wsimpleGen. Maybe it is because $wsimpleGen itself gets | not inlined... | | Cheers, | Manuel |

2 1

Anyone using SocketPrim.getSocketName?
by Volker Stolz 07 Dec '00

07 Dec '00

Is anyone using SocketPrimt.getSocketName? I try to get the IP of a listening socket (on my side), but I always get 0. It could be either my fault, SocketPrims fault (the source is prefilling the buffer with 0!), or the conversion-functions fault: > sAddr <- SocketPrim.getSocketName (s#socket) > local <- case sAddr of > (SocketPrim.SockAddrInet port host) -> do > return (show (wordToWord32 host)) > _ -> net#getHostName -- XXX output a warning > print local "host" is of type Word, so I need a way of getting it into a string. host should be 4x8 bit and thus Word32 is the right thing to use? -- \usepackage[latin1]{inputenc}! Volker Stolz * stolz(a)i2.informatik.rwth-aachen.de * PGP + S/MIME

1 1

Re: New InstallShield: no more DLLs
by Christian Lescher 07 Dec '00

07 Dec '00

> I've put up a new InstallShield for GHC 4.08.1 (Windows edition). This no > longer contains DLLs and import libraries for the libraries, so you have to > use the compiler with -static. Hmm ... That's really a fundamental change in GHC's Windows edition. > I intend to stick to this scheme in future releases (probably replacing > -static with -dynamic Good idea! :-) I also regard statically linking as more common than dynamically linking, so I welcome your idea to make statically linking the default. > ), as GHC derives few benefits from DLLized libraries, > and a lot of disadvantages. Also, there is at present an unresolved and > deep-seated bug (possibly not even in GHC) that prevents some very simple > DLLized programs from working. When may Win users expect this bug to be fixed? (A difficult question, I know.) Although I regard statically linking as much more important than the DLLized alternative, dynamically linking is (was?) an important feature of GHC for Win - f.e. to safe space when distributing a bunch of EXEs / DLLs build with GHC. > Users of DLLs need not despair: one important (and, to the best of my > knowledge, fully working) version of DLL building remains: you can still > build static DLLs, that is, DLLs in which all the code has been compiled > statically, so that all the necessary library code is linked into the DLL. > Hence, you can still build DLLs to be called from other languages, or to be > wrapped up as COM components, or whatever. Exposing Haskell functions to other languages in DLLs is a very, very important feature of GHC's Win edition! Please go on supporting it as you do!! > Finally, one nice side effect is that the size of the distribution is nearly > halved: it now weighs in at a little over 12Mb. Cheers, Christian

2 3

Or-patterns
by George Russell 06 Dec '00

06 Dec '00

Why not steal a good idea from Standard ML/New Jersey now and again? This has "Or-patterns" which allow you to match against a disjunction of patterns, EG fun sleepIn (Date.Sat | Date.Sun) = true | sleepIn _ = false Where you have variables in the patterns, you bind only the variables which appear in all the patterns, and you unify the types accordingly. Of course you can do without this feature, but I feel it shouldn't be too hard to implement and for me at least it would be occasionally useful.

2 1

RE: Or-patterns
by Simon Peyton-Jones 06 Dec '00

06 Dec '00

Sensible suggestion No technical problem, just one more thing to do. If anyone feels inclined to implement it I'll gladly incorporate the fruits of their labours in the GHC code base. Simon | -----Original Message----- | From: George Russell [mailto:ger@Informatik.Uni-Bremen.DE] | Sent: 04 December 2000 16:18 | To: glasgow-haskell-users(a)haskell.org | Subject: Or-patterns | | | Why not steal a good idea from Standard ML/New Jersey now and | again? This has | "Or-patterns" which allow you to match against a disjunction | of patterns, | EG | | fun sleepIn (Date.Sat | Date.Sun) = true | | sleepIn _ = false | | Where you have variables in the patterns, you bind only the | variables which appear | in all the patterns, and you unify the types accordingly. | | Of course you can do without this feature, but I feel it | shouldn't be too hard | to implement and for me at least it would be occasionally useful. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

The Set type
by George Russell 04 Dec '00

04 Dec '00

A minor quibble I know, but every time I use sets I want to add/subtract single elements to/from them. There is no function provided for doing this, so instead you have to do union/delete with a singleton set constructed from the element. I appreciate the zeal of the designer of this module to construct the smallest possible interface (I wish the same person had designed the standard Prelude) but I think this zeal is overdone. You do often need to operate with single elements. After all, if you wanted real hair-shirt minimalism you should get rid of "elementOf" (replace it by \el set -> isEmptySet (intersect set (singletonSet el)), but no-one would seriously suggest that - I hope.

1 0