|
|
About ::
TODO ::
Blog ::
RSS ::
Old blog ::
Projects ::
GIT ::
Gallery ::
Notes
Thu, 09 Nov 2006
POSIX threading model vs. Erlang threads.
I decided to check if this
benchmark of different threading models is correct.
So I've installed Erlang on my Debian Etch desktop (Intel Core Duo 3.4 Ghz (speeded up to 3.7 Ghz), 2 GB of RAM)
and tried this
Erlang application. It was compiled fine, but failed to execute.
So I've read some FAQs and initial tutorials about Erlang and ended up
removing some bits of initialization, since my version of Erlang failed
to translate string to number, so I hardcoded required number by hand into the program.
I also compiled this (1)
C++ example and this (2)
and performed a comparison.
Basically all those programs do is to create 500 threads and exchange 3000 messages
between them one-by-one.
Results are quite deplorable for POSIX threads and C++:
Erlang : 0.443 seconds
C++/POSIX NPTL threads 1 : 4.374 seconds
C++/POSIX NPTL threads 2 : 0.190 seconds
i.e. C++ application which uses POSIX NPTL threads is about 10 (!) times slower than native Erlang threads,
but if thread start/stop functions are written in assembler (if I did not forget it completely),
C++ variant becomes 2 times faster than Erlang's one, which seems to be either real magic,
or some bug.
I understand that Erlang has completely differet thread model
(i.e. it is part of it's virtual machine, but not system as a whole),
but there is major issue to think about.
Eventually I created own application, which uses NPTL POSIX threads, which
I compared to above
(this (1)).
Above numbers are the best numbers reported by time test, so I put gettimeofday()
inside main() in both C++ and my C versions and run them 13 times.
Here are averaged results:
C++/POSIX NPTL threads 1 : 5083343 usecs
C/POSIX NPTL threads : 4821212 usecs
C++/POSIX NPTL threads 1 (-fomit-frame-pointer) : 4738057 usecs
C/POSIX NPTL threads (-fomit-frame-pointer) : 4430010 usecs
Sources are available here.
Compilation options were: -pipe -Wall -O3 -lpthread -fomit-frame-pointer
This is definitely an issue to think about...
/devel/other :: Link / Comments ()
New version of the CARP module has been released.
I'm an author of the
Common Address Redundancy Protocol (CARP)
module for Linux kernel 2.6.
CARP is an improved version of the Virtual Router Redundancy Protocol (VRRP) standard.
The latest protocol to help provide high availability and network redundancy,
it was developed because router giant Cisco Systems believes that its Hot Standby Router Protocol (HSRP)
patent covers some of the same technical areas as VRRP.
Newsforge article about CARP.
Linux kernel CARP
is based on OpenBSD CARP protocol but is not compatible with it, since OpenBSD implementation
does not contain protection against repeated message sending attack.
New release includes compilation fixes for the latest kernels.
/devel/networking :: Link / Comments ()
New kevent 'take24' release.
Short changelog:
- added kevent PIPE notifications
KEVENT_REQ_LAST_CHECK flag, which allows to perform last check at dequeueing time- fixed
poll/select notifications (were broken due to tree manipulations)
- made
Documentation/kevent.txt look nice in 80-col terminal
- fix for
copy_to_user() failure report for the first kevent (Andrew Morton)
- minor function renames
/devel/kevent :: Link / Comments ()
Kevent pipe benchmark.
Using the same benchmark created by Eric Dumazet to test
epoll, which I ported to kevent, it is possible
to test unix sockets, inet sockets and pipes.
Application has additional posix thread, which writes into number
of preallocated sockets or pipes, main process reads from appropriate pairs.
Each successfull read is counted as event.
Here is pipe result with kevent_pipe kernel kevent part with
2000 pipes:
epoll (edge-triggered): 248408 events/sec
kevent (edge-triggered): 269282 events/sec
Busy reading loop: 269519 events/sec
Kevent is definitely a winner with extremely small overhead.
/devel/kevent :: Link / Comments ()
|