- Glasgow-haskell-users

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

RE: Lightningspeed haskell
by Jan-Willem Maessen 28 Feb '01

28 Feb '01

Josef Svenningsson <josefs(a)cs.chalmers.se> wrote: > 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. And Simon Peyton-Jones <simonpj(a)microsoft.com> replied: > I guess GHC is fast because it's implementing lightweight > threads inside a single OS thread. Absolutely. Good high-level thread support trumps anything provided by the operating system. I'd second Simon's guess that this was on Linux or some other system where pthreads map one-to-one to OS threads. Similar dramatic performance disparities have cropped up in the Java community. There are Java benchmarks which create thousands of threads; most implementations slow to a crawl when this happens, as the operating system collapses under the crushing load. Those which don't (IBM's Jalapeno, a research JVM, comes to mind) use this as a *big* bragging point. Unless you're mucking with thread priorities, mapping language-level threads one-to-one to operating-system threads is a terrible idea. -Jan-Willem Maessen Eager Haskell project jmaessen(a)mit.edu

1 0

RE: Lightningspeed haskell
by Simon Marlow 28 Feb '01

28 Feb '01

> It should be noted that synchronisation is achieved by using > slightly different kinds of primitives. But still... six times... And it's about to get faster still, because CVars can now be implemented with a single MVar instead of two. The reason is that putMVar now blocks on a full MVar rather than raising an exception. But as Simon said, the main reason is surely that GHC is using lightweight threads compared to C. BTW, was this on Linux? I'd be interested to see the results on systems that have different threading models, because Linux's threads implementation maps threads onto processes (albeit lightweight kind of process, but still a process), so the context switch overhead is going to be much higher than a threads library which sits in a single process. Cheers, Simon

2 1

RE: Lightningspeed haskell
by Simon Peyton-Jones 28 Feb '01

28 Feb '01

Cool! Thanks for doing this. I guess GHC is fast because it's implementing lightweight threads inside a single OS thread. Simon | -----Original Message----- | From: Josef Svenningsson [mailto:josefs@cs.chalmers.se] | Sent: 28 February 2001 09:47 | To: glasgow-haskell-users(a)haskell.org | Subject: Lightningspeed haskell | | | 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 |

1 0

Re: Re: Problems when mounting c: to /
by andreas.marth＠daimlerchrysler.com 27 Feb '01

27 Feb '01

Hallo! I just run "ghc -c -v Main.hs 2>&1| tee withMount.log" while c: was mounted at / and "ghc -c -v Main.hs 2>&1| tee withoutMount.log" after unmounting it. I attached both Files. because cygwin complains about a missing /tmp after mounting c: to / I have a c:\tmp directory but ghc uses c:\Temp. I think you should drop the mount c: at / because it is sure a problem you run into when installing ghc. I used a fresh WinNT (service pack 5 and inernet explorer 5 installed) installed cygwinat c:\cygwin, mounted c: to /, set PATH, SHELL, HOME, MAKE_MODE and TMPDIR, restarted cygwin, created /tmp, installed ghc-4.08.2 at c:\ghc\ghc-4.08.2, added it to PATH, restarted cygwin and went to my code directory. The rest is described above. So until the next problem, Andreas rrt1001@cam.ac.uk@cl.cam.ac.uk am 24.02.2001 13:57:17 Gesendet von: reuben.thomas(a)cl.cam.ac.uk An: Andreas Marth/FT/DCAG/DCX@WK-EMEA2 Kopie: glasgow-haskell-users(a)haskell.org Thema: Re: Problems when mounting c: to / > When installing ghc-4.08.2 (onWinNT) as described in the installation > instructions under c:, I couldn't get ghc to run. > It invoked the C-preprozessor and stoped after cleaning. I'm puzzled by this. Could you please send some sample output? Preferably running ghc -v. > When I unmount c:, it works fine. (If I install cygwin and dont mount c: to / > it works fine too.) > But now //c/ is the normal win-root. That's not a problem for me, but how about > ghc? Well, if it works, I suppose it's not a problem... > Does it depend in any way on c: mounted to /? I'm not sure. I think it used to (because of using /tmp as the temporary directory). Now it's mostly for convenience. > If not why do you want this mount (in the installation instructions section > 2.2.2.1)? I think it used to be necessary, and I kept it in the instructions partly because I find it useful to be able to refer to the drive with Unix-style paths, with the root directory being /, and partly because it worked, and the less I change the instructions, the less likely I am to break something. -- http://sc3d.org/rrt/ ¦ wit, n. educated insolence (Aristotle)

2 1

message
by www＠dcs.gla.ac.uk 26 Feb '01

26 Feb '01

[This message is sent through a WWW-Email gateway.] [The authenticity of the sender can not be validated.] [Message sent from the following machine - 62.172.105.102 ] [after accessing this URL http://www.dcs.gla.ac.uk/scripts/global/send_message?glasgow-haskell-users@…] -- Hi, If you want to instal Perl if you go to www.activestate.com then you can dowload it and it instals with no trouble (and gives you help if you do come accross any problems). As to the #! bit, not sure yet, it's the reason I came accross your query in the first place. If you've come up with an answer could you let me know. Cheers James --

1 0