March 2001 - Glasgow-haskell-users

RE: Bagley shootout. Was: Lightningspeed haskell
by Simon Marlow 06 Mar '01

06 Mar '01

> Reducing the 46M reported on the shootout without changing the > program would be interesting. An easy way for improvement > would be to share characters and small integers like is done in Hugs. > This would mean the initial list of characters would be reduced from > 40M to 24M, so the total should go down from 46M to 30M. We do share characters and small integers. Cheers, Simon

2 1

PrimIO
by Simon Marlow 02 Mar '01

02 Mar '01

Quick poll: Is anyone still using the PrimIO type and combinators from GlaExts? It's high time we removed them. In fact, there's nothing in this module that isn't either deprecated or can be got from somewhere else. I think GlaExts will be deprecated in the next release. Cheers, Simon

2 1

runProcess/ createPipe
by George Russell 02 Mar '01

02 Mar '01

If Posix.runProcess really is supposed "our candidate for the high-level OS-independent primitive" (see documentation), it would help if there was a documented way of using it with pipes. The problem is that runProcess takes handles as arguments, while the obvious function, createPipe, returns two Fds. There seems to be no _documented_ way of converting an Fd to a Handle. I suggest therefore that either there be a createPipeHandle :: IO (Handle,Handle) (which would be nice, because it might avoid bothering the operating system completely, and would makes sense on non-Posix systems). Or else, the existing Posix.fdToHandle fdToHandle :: Fd -> IO Handle should be documented.

1 0

RE: Bagley shootout. Was: Lightningspeed haskell
by Simon Peyton-Jones 02 Mar '01

02 Mar '01

A String is a [Char] and a Char is a heap object. So a file represented as a string takes a massive 20 bytes/char (12 for the cons cell, 8 for the Char cell). Then it's all sucked through several functions. It's entirely possible, though, that the biggest performance hit is in the I/O itself. We'd be happy if anyone wanted to invesigate and improve. Simon | -----Original Message----- | From: John Atwood [mailto:atwoodj@cs.orst.edu] | Sent: 02 March 2001 01:12 | To: Josef Svenningsson | Cc: glasgow-haskell-users(a)haskell.org | Subject: Bagley shootout. Was: Lightningspeed haskell | | | I notice that the reverse file program, while concise, is quite slow. | The program in its entirety is: | main = interact $ unlines . reverse . lines | | Any thoughts on why its time is 5.68 seconds, vs 3.56 for tcl, 2 for | perl, 0.19 for gcc, 0.18 for ocaml; and how it might be sped | up? Is the | lack of speed all in the stdio I/O? | | Is there a way to tell which benchmarks have no haskell entry? | | John Atwood | -- | | Josef Svenningsson wrote: | > | > Hi all. | > | > Some days ago someone posted this url: | > http://www.bagley.org/~doug/shootout/ | > | > which is a page benchmarking a number of different languages and | > compilers where ghc is one of them. Some benchmarks lacked a haskell | > versions (and some still do) and so I decided to fill in | some of the gaps. | > | > One benchmark turned out to give pretty remarkable results. It's the | > producer/consumer benchmark. I suggest you all take a look | at it. The | > haskell version is six (SIX!!!) times faster than the c | version. Hey, | > what's going on here? I would really like to hear some | comments from our | > dear implementors. | > | > It should be noted that synchronisation is achieved by using | > slightly different kinds of primitives. But still... six times... | > | > I lift my hat of for the ghc-implementors. | > | > /Josef | > | > | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

3 3

RE: Concurrency in GHCi
by Simon Marlow 02 Mar '01

02 Mar '01

> The little program below is to test an idea to try to interact > using Hugs or GHCi with a running program. > > To use the program: > 1. Start the server with "addServer addChan" > 2. Write requests to addChan "writeChan addChan (Add 3 4)" > > The program seems to work OK in Hugs, but crashes out with > "ghc: no threads to run". > > Can anybody suggest a way of getting this to run properly with > GHCi? I think you wanted "forkIO (addServer addChan)", because addServer immediately attempts to read from the channel and will block if there's no data available. Oh, and you should really say "{-# NOINLINE addChan #-}" to prevent it being accidentally duplicated. Cheers, Simon

1 0

Lightningspeed haskell
by Josef Svenningsson 02 Mar '01

02 Mar '01

Hi all. Some days ago someone posted this url: http://www.bagley.org/~doug/shootout/ which is a page benchmarking a number of different languages and compilers where ghc is one of them. Some benchmarks lacked a haskell versions (and some still do) and so I decided to fill in some of the gaps. One benchmark turned out to give pretty remarkable results. It's the producer/consumer benchmark. I suggest you all take a look at it. The haskell version is six (SIX!!!) times faster than the c version. Hey, what's going on here? I would really like to hear some comments from our dear implementors. It should be noted that synchronisation is achieved by using slightly different kinds of primitives. But still... six times... I lift my hat of for the ghc-implementors. /Josef

2 1

Concurrency in GHCi
by John Knottenbelt 01 Mar '01

01 Mar '01

Hi The little program below is to test an idea to try to interact using Hugs or GHCi with a running program. To use the program: 1. Start the server with "addServer addChan" 2. Write requests to addChan "writeChan addChan (Add 3 4)" The program seems to work OK in Hugs, but crashes out with "ghc: no threads to run". Can anybody suggest a way of getting this to run properly with GHCi? Thanks Johnny ---- Transcript of a Hugs session: Type :? for help ConcTest> addServer addChan addServer started ConcTest> writeChan addChan (Add 3 4) 1: addServer: 3 + 4 = 7 ---- Transcript of a GHCi session: Loading package concurrent ... linking ... done. Compiling ConcTest ... compilation IS required ConcTest> addServer addChan addServer started ghc: no threads to run: infinite loop or deadlock? bash$ ---- module ConcTest where import Concurrent import IOExts data AddMsg = Add Int Int | Quit addServer :: Chan AddMsg -> IO () addServer c = do putStrLn "addServer started" loop 1 putStrLn "addServer finished" where loop msgNum = do msg <- readChan c case msg of Add x y -> do putStrLn (show msgNum ++ ": addServer: " ++ show x ++ " + " ++ show y ++ " = " ++ show (x + y)) loop (msgNum + 1) Quit -> return () addChan :: Chan AddMsg addChan = unsafePerformIO newChan

1 0

Re: New InstallShield
by Sigbjorn Finne 01 Mar '01

01 Mar '01

Reuben Thomas rrt1001(a)cam.ac.uk writes: > > > I didn't know the windows port of GHC used mingwin, that is great news. > > Does that mean it is possible to generate stand alone applications for > > Windows ? > > Yes; it always has been! ghc-4.04 (or was it 4.03?) added support for compiling via mingw, before that all exes had to depend on cygwin.dll > > Would it be hard to configure GHC to work with the mingwin crosscompiler > > on Linux ? It would be great to have a crosscompiling GHC. > > Not a clue. I'd be delighted to hear about this. I suspect the build system > would need ironing out somewhat, but in theory > > ./configure --target=i386-unknown-mingw32 > > ought to do something sensible. Unless someone's bitten the bullet on this one recently, the mk/ setup doesn't deal with cross-compilation at all (nor does the driver); indeed I believe the configure script will even prevent you from trying. --sigbjorn

1 0

New InstallShield
by Reuben Thomas 01 Mar '01

01 Mar '01

This one corrects a problem with the fix made in the last one that stopped anything to do with stat() working (e.g. hFileSize, reading directories &c. &c.). Sorry about that. The fix is still fragile and temporary; I'm waiting for the underlying mingwin problems to be fixed, hopefully in time for the GHC 5.0 release. -- http://sc3d.org/rrt/ | humour, n. unexpected recognition

2 2