Hi,
On Thu, Mar 25, 2010 at 10:18:39AM +0100, Gabriel Kerneis wrote:
I'll try to set up a dedicated web page to provide the scripts I used
and the method (someone requested it off-list) but won't have to time to
do so before two weeks.
Here it is:
Marc,
On Wed, Mar 17, 2010 at 01:37:07PM +0100, Marc Lehmann wrote:
On Wed, Mar 17, 2010 at 12:19:23PM +0100, Gabriel Kerneis
kern...@pps.jussieu.fr wrote:
You can find the results here:
http://hal.archives-ouvertes.fr/hal-00434374/fr/
That's quite fascinating - I have yet to understand
On Thu, Mar 25, 2010 at 10:18:39AM +0100, Gabriel Kerneis
kern...@pps.jussieu.fr wrote:
Temporal graphs were indeed fascinating for thttpd. Compare for
instance:
http://www.pps.jussieu.fr/%7Ekerneis/software/files/benchmark/graphs/thttpd-time-1000.png
Hello,
This libcoro library is very interesting. Is libcoro used in libev ?
I'll also have a look at state-thread
[http://state-threads.sourceforge.net/].
I'm also very impressed by the feasibility of the callback use you
described. This is very powerful. I must reread the document, I missed
Gabriel Kerneis a écrit :
I benchmarked a number of green threads libraries and found State
Threads to be far more efficient than Pth. OTOH, Pth focuses on
portability, and I have not idea how State Threads behaves on anything
but a Linux box. YMMV.
Did you include libcoro in your
On Wed, Mar 17, 2010 at 11:15:11AM +0100, Christophe Meessen
christo...@meessen.net wrote:
This libcoro library is very interesting. Is libcoro used in libev ?
Oh my, beware, of course not :)
But libev is of course designed with coroutines (which I use to mean
cooperative threads) in mind as
On Wed, Mar 17, 2010 at 12:13:49PM +0100, Christophe Meessen
christo...@meessen.net wrote:
My project is a CORBA like application with the difference that the
encoding is designed for stream oriented processing. It is thus a
middleware and the task to be performed is in general user
Brandon Black wrote:
However, the thread model as typically used scales poorly across
multiple CPUs as compared to distinct processes, especially as one
scales up from simple SMP to the ccNUMA style we're seeing with
This is just not true.
large-core-count Opteron and Xeon -based machines
Marc Lehmann wrote:
The precise problem they were designed to solve is slow context switching
times due to reloading of cpu registers.
You have to reload the registers when you context switch between threads
*or* processes. Its
the VM and security context switch that hurt.
With threads,
On Tue, Mar 16, 2010 at 12:15 AM, James Mansion
ja...@mansionfamily.plus.com wrote:
Brandon Black wrote:
However, the thread model as typically used scales poorly across
multiple CPUs as compared to distinct processes, especially as one
scales up from simple SMP to the ccNUMA style we're
Hello,
sorry to have woken the thread troll. It sounds like a very passionate
discussion topic.
My rationale is to favor code simplicity and clarity at the cost of some
potential performance penalty. This led me to the leader/follower
pattern with worker threads handling each request
Regarding the threads vs. processes discussion I see a use case which
hasn't been discussed yet.
Consider the C10K application with many cold links and a context (i.e.
authentication, data structures, ...) associated to each connection.
With threads we can easily set up a pool of worker
On 16 Mar 2010, at 4:40 PM, Christophe Meessen wrote:
Regarding the threads vs. processes discussion I see a use case
which hasn't been discussed yet.
Consider the C10K application with many cold links and a context
(i.e. authentication, data structures, ...) associated to each
Brandon Black a écrit :
The thing we all seem to agree on is that eventloops
beat threads within one process, but the thing we disagree on is
whether it's better to have the top-level processes be processes or
threads.
I'm really not so sure about the former. The ICE system developers
On Tue, Mar 16, 2010 at 9:51 AM, Christophe Meessen
christo...@meessen.net wrote:
Brandon Black a écrit :
The thing we all seem to agree on is that eventloops
beat threads within one process, but the thing we disagree on is
whether it's better to have the top-level processes be processes or
On 16/03/10 02:23 +0100, Marc Lehmann wrote:
On Mon, Mar 15, 2010 at 11:07:53PM +, James Mansion
ja...@mansionfamily.plus.com wrote:
Yes, threads were not meant for these kinds of workloads, and their
overheads are enourmous even on systems that are very fast (such as
GNU/Linux).
That
On Tue, Mar 16, 2010 at 03:24:32PM +0100, Christophe Meessen
christo...@meessen.net wrote:
My rationale is to favor code simplicity and clarity at the cost of some
potential performance penalty. This led me to the leader/follower
pattern with worker threads handling each request
On Tue, Mar 16, 2010 at 03:40:46PM +0100, Christophe Meessen
christo...@meessen.net wrote:
With threads we can easily set up a pool of worker threads that easily
and efficiently pick up the context associated to the connection
becoming active. I don't see how an equivalent model can be
On Tue, Mar 16, 2010 at 05:32:42PM -0500, Dan White dwh...@olp.net wrote:
userspace thread switching is 10-100 times faster than kernel thread
switching on my GNU/Linux box - and processes don't need to communicate
with themselves via slow main memory (they can use cache).
Marc,
Can you
On Tue, Mar 16, 2010 at 04:51:49PM +0100, Christophe Meessen
christo...@meessen.net wrote:
The thing we all seem to agree on is that eventloops
beat threads within one process, but the thing we disagree on is
whether it's better to have the top-level processes be processes or
threads.
I finally found out how to implement the desired multi thread model by
using the existing API. One needs to use the ev_loop( ONE_SHOT) call.
The following code skeleton shows how I would do it.
worker_thread_function(...)
{
while( !done )
{
// waiting to call ev_loop
On Mon, Mar 15, 2010 at 01:55:18PM +0100, Christophe Meessen
christo...@meessen.net wrote:
I finally found out how to implement the desired multi thread model by
using the existing API. One needs to use the ev_loop( ONE_SHOT) call.
I don't think one-shot will do what you want, one-shot runs
I have something similar, therefore how I did it.
All polling is done by libev in the main-loop, a single main loop.
If a connection is established and processing the data needs some time,
I remove the watchers from the loop, and creates a task from the data to
process and the function to
On Mon, Mar 15, 2010 at 7:52 PM, com...@gmx.ch com...@gmx.ch wrote:
I have something similar, therefore how I did it.
All polling is done by libev in the main-loop, a single main loop.
If a connection is established and processing the data needs some time, I
remove the watchers from the
On Mon, Mar 15, 2010 at 08:48:20PM +0500, mikhail maluyk
mikhail.mal...@gmail.com wrote:
How do you know beforehand that processing data will take some time?
It depends on the problem domain - in many cases you do know whether a
task will take some time, for example, when it runs a database
Marc Lehmann wrote:
Keep in mind thatthe primary use for threads is improve context switching
times in single processor situations - event loops are usually far faster at
context switches.
No, I don't think so. (re: improve context switching times in single
processor
situations). Yes,
On Mon, Mar 15, 2010 at 5:07 PM, James Mansion
ja...@mansionfamily.plus.com wrote:
Marc Lehmann wrote:
Keep in mind thatthe primary use for threads is improve context switching
times in single processor situations - event loops are usually far faster
at
context switches.
No, I don't
On Mon, Mar 15, 2010 at 11:07:53PM +, James Mansion
ja...@mansionfamily.plus.com wrote:
Keep in mind thatthe primary use for threads is improve context switching
times in single processor situations - event loops are usually far faster at
context switches.
No, I don't think so. (re:
28 matches
Mail list logo
