Comments on: Playing with the new Haskell epoll event library

By: solrize

solrize — Fri, 22 Jan 2010 06:08:20 +0000

Btw I wonder how the timings would chance if you eliminate the sendall (just accept the connection and close the socket immediately). I know we’re in a different world when 15k connections/sec sounds slow, but a lot of the time must be in the kernel rather than in GHC concurrency.

By: solrize

solrize — Tue, 19 Jan 2010 22:29:18 +0000

Don, you asked for applications other than servers that wanted such high concurrency. One example, is a network router, e.g. a corporate firewall that handles a few thousand client connections and routes them to the internet or various VPN’s depending on the endpoints. It might even implement the VPN so it would do IPSEC or SSL (de-)encapsulation. If it is handling a lot of VOIP traffic there could be as many as 60 packets per second per client (the frame rate of Speex is about 30 msec and it is full duplex, so 2 packets per frame). Of course we could even want to use something like that in a data center instead of a big Cisco box, so the amount of traffic increases again.

Kernel mode Haskell anyone? ;-)

By: Taru Karttunen

Taru Karttunen — Tue, 19 Jan 2010 14:54:05 +0000

Tried to reproduce this but got quite different numbers:

The T-ended things are compiled with -threaded.

bs2 is you bytestring-example with the forkIO removed as the epoll does not forkIO either.

Linux nar.taruti.net 2.6.32-ARCH #1 SMP PREEMPT Thu Jan 7 22:28:29 CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz GenuineIntel GNU/Linux
The Glorious Glasgow Haskell Compilation System, version 6.12.1

str: Request rate: 11555.5 req/s (0.1 ms/req)
str: Request rate: 11437.5 req/s (0.1 ms/req)
str: Request rate: 11595.1 req/s (0.1 ms/req)
strT: Request rate: 8480.5 req/s (0.1 ms/req)
strT: Request rate: 8777.3 req/s (0.1 ms/req)
strT: Request rate: 8762.9 req/s (0.1 ms/req)
bs: Request rate: 17266.1 req/s (0.1 ms/req)
bs: Request rate: 17349.4 req/s (0.1 ms/req)
bs: Request rate: 17227.9 req/s (0.1 ms/req)
bsT: Request rate: 14416.9 req/s (0.1 ms/req)
bsT: Request rate: 13607.0 req/s (0.1 ms/req)
bsT: Request rate: 14386.1 req/s (0.1 ms/req)
epoll: Request rate: 16242.7 req/s (0.1 ms/req)
epoll: Request rate: 17910.9 req/s (0.1 ms/req)
epoll: Request rate: 16119.1 req/s (0.1 ms/req)
epollT: epollWait: interrupted (Interrupted system call) BROKEN!
bs2: Request rate: 18584.1 req/s (0.1 ms/req)
bs2: Request rate: 18580.1 req/s (0.1 ms/req)
bs2: Request rate: 18753.0 req/s (0.1 ms/req)
bs2T: Request rate: 17244.9 req/s (0.1 ms/req)
bs2T: Request rate: 16940.1 req/s (0.1 ms/req)
bs2T: Request rate: 16890.5 req/s (0.1 ms/req)

By: codexon

codexon — Mon, 18 Jan 2010 20:51:10 +0000

I’ve checked the configure logs both both machines, one where it works and one where it doesn’t. They are both about the same except the one that works is running Ubuntu 9.10 instead of 9.04.

It should probably be noted that compiling works just fine, the error happens at runtime. Does this still mean it may be a configuration problem?

By: dons00

dons00 — Mon, 18 Jan 2010 19:43:19 +0000

@bos I get just over 10k req/sec for the Python epoll version, and 15k req/sec for the Haskell one.

By: Bryan O'Sullivan

Bryan O'Sullivan — Mon, 18 Jan 2010 19:06:28 +0000

@dons00, what are the Python performance numbers like on your box?

By: Bryan O'Sullivan

Bryan O'Sullivan — Mon, 18 Jan 2010 19:06:05 +0000

@codexon, if you are having problems, you’ll have to give us some details. Please file a report with detailed info about your platform and distribution at http://github.com/tibbe/event/issues

By: dons00

dons00 — Mon, 18 Jan 2010 09:38:18 +0000

> functions available for bytestring are as numerous and useful as they are for strings?

Indeed. They provide the full list api, along with many other support libraries, such as utf8 encodings, parser combinators and so on. That’s why we use them for everything performance-oriented.

For unicode packed strings, I’d use the text library, http://hackage.haskell.org/package/text

Regarding epoll_create failing on your machine — could you take it offline, and send me the config.log from your event lib build? You’re not building the app with the -threaded flag are you? That won’t work.

By: codexon

codexon — Mon, 18 Jan 2010 09:27:06 +0000

I haven’t been able to fix the unsupported problem error. I am not very experienced in Haskell to be able to debug the problem. I want to wait until epoll is merged with GHC (which I hope is soon) before writing the server I have planned out.

> Just leave the data in bytestring form, and enjoy the performance.

I’m assuming the functions available for bytestring are as numerous and useful as they are for strings? What about unicode?

By: dons00

dons00 — Mon, 18 Jan 2010 06:37:26 +0000

@codexon

You’re on track, up until:

> So any time you need to operate on the data, it needs to be converted to and from a byte string costing 2*O(n) operations

Which isn’t true. You just operate on the data directly as a bytestring. The penalty applies only if you convert it to a [Char], which would be silly. Just leave the data in bytestring form, and enjoy the performance.

Where you able to update the benchmark examples?