- Glasgow-haskell-users

RE: ghc Profiler
by Simon Marlow 10 Aug '01

10 Aug '01

> Dear ghc friend or developper, > > I am using the ghc profiler to do time profiling, and sadly cannot get > the relevant detail out of the tool. > > I compile the program using ghc -auto -caf-all -prof and get an > exectuable. All that is fine and I can also use other compile options. > > When running, the document suggests that one uses > > +RTS -p -RTS, and again that works fine. Unfortunately it > only delivers > percentages of time, no raw ticks. So if a particluar CCS > took less than > 0.1 percent it will not occur. > > So, one should be able to use -P instead to obtain actual figures as > well, but the resulting .prof file is identical to the -p one. > > Bug? or is it me?? No, it's a bug. Fixed now. Cheers, Simon

1 0

ghc Profiler
by Stephan Reiff-Marganiec 10 Aug '01

10 Aug '01

Dear ghc friend or developper, I am using the ghc profiler to do time profiling, and sadly cannot get the relevant detail out of the tool. I compile the program using ghc -auto -caf-all -prof and get an exectuable. All that is fine and I can also use other compile options. When running, the document suggests that one uses +RTS -p -RTS, and again that works fine. Unfortunately it only delivers percentages of time, no raw ticks. So if a particluar CCS took less than 0.1 percent it will not occur. So, one should be able to use -P instead to obtain actual figures as well, but the resulting .prof file is identical to the -p one. Bug? or is it me?? Is there any other way of obtaining good time profiles? a quick reply would be appreciated Stephan ps: I am using ghc 5.02 (although the same problem occurs with ghc 4.08) -- ______________________________________________________________________________ Stephan Reiff-Marganiec e-mail: sreiff(a)dcs.gla.ac.uk Research Assistant / Student tel: + 44 141 339 8855 x 0048 Department of Computing Science fax: + 44 141 330 4913 University of Glasgow 8-17 Lilybank Gardens GLASGOW G12 8RZ, U.K. ______________________________________________________________________________

1 0

Socket
by Koen Claessen 09 Aug '01

09 Aug '01

Hi, I am implementing a modest webserver using GHC (as an example program). I am using the Socket library. In the Socket library, the following function is provided: accept :: Socket -> IO (Handle, HostName, PortNumber) Unfortunately, this is a blocking function, which means that the whole program blocks when it is waiting for a connection. This is not nice, since I would like to do something else in the meantime (such as serving other clients). I do not want to use the "concurrent" package (for a good reason). Ideally, I would like to integrate this with the function "hSelect" from the Select module. Has anybody had this problem before, and, if so, what could be a solution? Thanks, /Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen phone:+46-31-772 5424 mailto:koen@cs.chalmers.se ----------------------------------------------------- Chalmers University of Technology, Gothenburg, Sweden

2 2

RE: Socket
by Simon Marlow 09 Aug '01

09 Aug '01

> Koen writes: > > > accept :: Socket -> IO (Handle, HostName, PortNumber) > > > > Unfortunately, this is a blocking function, which means that > > the whole program blocks when it is waiting for a > > connection. > [..] > > Ideally, I would like to integrate this with the function > > "hSelect" from the Select module. > > man 2 accept on my Linux says: > > In order to be notified of incoming connections on a > socket, you can use select(2) or poll(2). A readable > event will be delivered when a new connection is attempted > and you may then call accept to get a socket for that con- > nection. > > So I imagine if you passed the socket as the first arg to > Select.hSelect, you'd get what you want. > SocketPrim.socketToHandle claims to do the required conversion. > > disclaimer: I haven't tried this. Strange, I haven't received the original message in this thread yet (I read it from the archives). 'accept' doesn't block the whole program, it only blocks the current thread - it's designed to be well-behaved in a multi-threaded program. If you need the select() behaviour, I recommend using multiple threads and let GHC's RTS handle the I/O multiplexing. You mentioned that you weren't using concurrency for a good reason - care to elaborate? Cheers, Simon

1 0

RE: GC options. Reply
by Simon Marlow 09 Aug '01

09 Aug '01

> Hello! > > On Tue, Aug 07, 2001 at 10:47:50AM +0100, Simon Marlow wrote: > > > - Compacting garbage collection is enabled when the residency > > reaches a certain percentage of the maximum heap size (if there > > is one). > > Could there be the possibility to set an absolute amount of memory > to start compacting, at least for the case of no maximum heap size? Yes, there could be, but I don't want the GC tunables to get any more complicated than they already are. In this case you could just set the maximum heap size to the size of your memory+swap and then set the compaction threshold so that compaction would kick in at the desired point. Cheers, Simon

1 0

RE: shared libraries in sun solaris
by Simon Marlow 09 Aug '01

09 Aug '01

> we are writing a haskell program that does a calculation for > an intranet > application. We assume that at peak times, several thousand > users are going > to use the program at the same time. > Our problem is, that our binary file has several MBs and we > don't know how > to compile it (we are using ghc 5.01) in a way, that all > users can share ONE > binary file in memory. If every user has one file, we would > need several GBs > of memory. > At the moment we are using Microsoft Windows NT but planning > to use Sun > Solaris later. > Every hint would be a big help, Most operating systems, including Windows NT and Solaris, will share the text of a binary in memory between several invocations. Only the data section of the binary will be duplicated (and then only the pages that are actually modified). To get slightly better sharing performance you might want to statically link the binary - it'll already be statically linked against the Haskell libraries, but statically linking against the C libraries will mean that you dirty slightly fewer pages for each new instance of the running program. This is a tradeoff with shared libraries: shared libraries are good when lots of different binaries use the same library(*), but don't give you any benefit when you have many running instances of the same binary. (*) I've heard people argue that even in this case shared libraries aren't actually a win, so YMMV. Cheers, Simon

1 0

shared libraries in sun solaris
by Siemens Entwicklungsteam 09 Aug '01

09 Aug '01

Hello, we are writing a haskell program that does a calculation for an intranet application. We assume that at peak times, several thousand users are going to use the program at the same time. Our problem is, that our binary file has several MBs and we don't know how to compile it (we are using ghc 5.01) in a way, that all users can share ONE binary file in memory. If every user has one file, we would need several GBs of memory. At the moment we are using Microsoft Windows NT but planning to use Sun Solaris later. Every hint would be a big help, thank you very much, Kilian _________________________________________________________________ Downloaden Sie MSN Explorer kostenlos unter http://explorer.msn.de/intl.asp

1 0

Re: FWD: Re: GHC FFI Return Type Bug
by Fergus Henderson 09 Aug '01

09 Aug '01

Sigbjorn Finne <sof(a)galconn.com> wrote: > > "Julian Seward (Intl Vendor)" <v-julsew(a)microsoft.com> writes: > > > > | > char fooble ( ... ) > > | > { > > | > return 'z'; > > | > } > > | > > > | > on an x86, 'z' will be returned at the lowest 8 bits in %eax. What I > > | > don't know is, is the C compiler obliged to clear the upper 24 bits of > > | > %eax, or does that onus fall on the callee? The upper 24 bits of eax must be cleared in the callee. The caller can assume that they are zero. I don't know if this is documented anywhere, but that is the convention which GNU C follows (on all architectures -- the C front-end internally promotes the return type from "char" to "int"). I can point you to the exact line of code in the GNU C front-end if you really want. I think this is required by traditional K&R C code, which does things like calling such functions without declaring them. -- Fergus Henderson <fjh(a)cs.mu.oz.au> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.

1 1

--RTS
by Marcin 'Qrczak' Kowalczyk 08 Aug '01

08 Aug '01

Currently --RTS option for a program compiled with ghc means that all the following arguments are passed to the program, even if they are +RTS and -RTS. IMHO -- should act like --RTS too. Imagine a utility like Unix ls written in Haskell. If someone invokes it ls -- "$FILENAME" he means that "$FILENAME" is a filename. He shouldn't care that it's written in Haskell and be forced to write ls --RTS -- "$FILENAME" as currently. If it's not an option for the program, it's certainly not an option for its runtime. --RTS can be retained in case one really wants to invoke the program with arguments +RTS (and not -- +RTS). PS. +RTS -h has an out of date description of -M. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: GC options. Reply
by Simon Marlow 08 Aug '01

08 Aug '01

Ok, I've done the following: - disabled the maximum heap size by default. It can still be enabled with +RTS -M<size> - RTS options are taken from the GHCRTS environment variable in addition to the command line (the command line has precedence). - Compacting garbage collection is enabled when the residency reaches a certain percentage of the maximum heap size (if there is one). Cheers, Simon

2 1