- Glasgow-haskell-users

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

RE: Sockets on Windows
by Matthew Richards 24 Feb '01

24 Feb '01

You need to wrap up the use of sockets in a "withSocketsDo", as in: > server port = withSocketsDo $ > do socket <- listenOn port > -- etc I seem to recall the documentation says you always need to use that, so I don't know why it works without on Linux :-) Hope this helps, Matthew -----Original Message----- From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org]On Behalf Of Steinitz, Dominic J Sent: Friday, February 23, 2001 11:10 AM To: glasgow-haskell-users Subject: Sockets on Windows I am was trying out sockets. These worked fine under linux. Under windows I get the following error. Does anyone know what it means and how I can fix it? I can telnet from within the cygwin window so I assume tcp/ip is running. Thanks, Dominic. administrator@DEFAULT /cygdrive/d/dom/home/socketTest $ ./server1 8000 Fail: does not exist Action: getProtocolByName Reason: no such protocol entry ---------------------------------------------------------------------------- --------------------- 21st century air travel http://www.britishairways.com

2 1

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

24 Feb '01

Hallo everybody! 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. 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? Does it depend in any way on c: mounted to /? If not why do you want this mount (in the installation instructions section 2.2.2.1)? Thanks, Andreas PS: Thanks Reuben for the new install shield and a very big thanks to all of you who have their parts in getting the profiling to run under WinNT

2 1

RE: --add-package
by Simon Marlow 23 Feb '01

23 Feb '01

> On Fri, 23 Feb 2001, Simon Marlow wrote: > > > I don't think I agree. Installation of an external package > shouldn't be > > doing --delete-package first: that should be left to the > user (or rpm > > -e, or whatever). > > rpm is a different story. I would expect 'make install' to be > idempotent. > With your scheme one has to write 'make uninstall install'. ghc --add-package behaves just like rpm --install, which seems reasonable to me. Why should it behave differently? If you want 'make install' to be idempotent (which I'm not sure is desirable anyway), then you will indeed have to ghc --delete-package first, but then I hope you're going to print a big warning and wait for the user to press any key first :) Cheers, Simon

1 0

RE: --add-package
by Simon Marlow 23 Feb '01

23 Feb '01

> In practice installation script of an external package does > --del-package before --add-package, because if it was > installed before, > --add-package would cause an error. > > Wouldn't be reasonable then to let --add-package overwrite > any existing > package of that name? There is no real safety, because the package > is explicitly deleted anyway. I don't think I agree. Installation of an external package shouldn't be doing --delete-package first: that should be left to the user (or rpm -e, or whatever). If you want to install a new package that replaces an existing one, you have to remove the existing one first. Cheers, Simon

2 1

Re: Sockets on Windows
by Reuben Thomas 23 Feb '01

23 Feb '01

> administrator@DEFAULT /cygdrive/d/dom/home/socketTest > $ ./server1 8000 > > Fail: does not exist > Action: getProtocolByName > Reason: no such protocol entry Just from looking at the manpage for getprotobyname, I surmise that the problem is that you don't have an /etc/protocols file (or equivalent) under Windows. I'm not sure what's supposed to happen (or for that matter, what's supposed to work). Look in hslibs/net/BSD.lhs; I couldn't work out what was going on in a minute; perhaps someone else knows. The other thing I couldn't work out was where getProtocolByName was being called in the first place, but presumably it's to find the protocol number of tcp. -- http://sc3d.org/rrt/ | Slow Pedestrian Crossing

1 0