August 2001 - Glasgow-haskell-users

RE: --RTS
by Simon Marlow 13 Aug '01

13 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. Done. Simon

1 0

RE: Socket
by Simon Marlow 13 Aug '01

13 Aug '01

> Keith writes: > > | 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. > > Yes, this works. Thanks. > > (BTW, The documentation of "SocketPrim.socketToHandle" > reports the wrong type ("IOMode" argument is missing). > Forwarded to glasgow-haskell-bugs.) Fixed; thanks. Simon

1 0

RE: Memory usage under -O2
by Simon Marlow 13 Aug '01

13 Aug '01

> Heap usage after compiling my program with -O is vastly > different (at least 10x more) than without -O. Why? How > can I prevent this? (other than, of course, not using -O) One possible cause of this is the full-laziness (or almost-full-laziness) transformation that GHC performs when -O is on. If you're up to reading core, then -ddump-simpl or -dverbose-core2core might help you figure out what's going on, after you've narrowed down the culprit with heap profiling. Unfortunately we don't have a way to turn off full-laziness at the moment, aside from patching the compiler. The optimisation pass ordering is specified in main/DriverState.hs, in the function 'buildCoreToDo'. Cheers, Simon

1 0

Memory usage under -O2
by Ken T Takusagawa 10 Aug '01

10 Aug '01

Heap usage after compiling my program with -O is vastly different (at least 10x more) than without -O. Why? How can I prevent this? (other than, of course, not using -O) --ken

1 0

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