- Glasgow-haskell-users

RE: Comparsion of Execution Speeds
by Simon Marlow 13 Aug '01

13 Aug '01

> Is anyone aware of publications relating the execution speeds of ghc > compiled haskell programs to say C? > > I have once heard that the difference is about a factor of 10. The difference varies wildly depending on the program. But Doug Bagely's programming language shootout has some interesting figures: http://www.bagley.org/~doug/shootout/ cheers, Simon

1 0

Comparsion of Execution Speeds
by Stephan Reiff-Marganiec 13 Aug '01

13 Aug '01

Hi, Is anyone aware of publications relating the execution speeds of ghc compiled haskell programs to say C? I have once heard that the difference is about a factor of 10. Stephan -- ______________________________________________________________________________ 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

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