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:
http://www.pps.jussieu.fr/~kerneis/research
On Thu, Mar 25, 2010 at 10:18:39AM +0100, Gabriel Kerneis
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
> http://www.pps.jussieu.fr/%7Ekerneis/software/files/benchmar
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
> wrote:
> > You can find the results here:
> > http://hal.archives-ouvertes.fr/hal-00434374/fr/
>
> That's quite fascinating - I have yet to understand what an additi
On Wed, Mar 17, 2010 at 12:19:23PM +0100, Gabriel Kerneis
wrote:
> You can find the results here:
> http://hal.archives-ouvertes.fr/hal-00434374/fr/
That's quite fascinating - I have yet to understand what an additional
userspace accept queue (thttpd) has as an effect (i.e. how to decide when
to
On Wed, Mar 17, 2010 at 12:13:49PM +0100, Christophe Meessen
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 defined. And
> such a us
On Wed, Mar 17, 2010 at 11:15:11AM +0100, Christophe Meessen
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 well, which is why all
Christophe,
On Wed, Mar 17, 2010 at 11:25:56AM +0100, Christophe Meessen wrote:
> 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 Threa
Marc Lehmann a écrit :
Well, the event loop has much lower cpu costs overall for the same jobs.
Reading http://state-threads.sourceforge.net/docs/st.html helped to
convince me.
The event loop combined with coroutines seems indeed the optimal approach.
Though I'm still a bit unsure about one
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 compari
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
On Wed, Mar 17, 2010 at 02:04:36AM +0100, Marc Lehmann wrote:
> Apart from libcoro (extremely bare bones, unlikely to make people happy,
> think libev to get the idea :) there is also GNU libpth, and various
> so-called "green threads" implementations.
I benchmarked a number of "green threads" lib
On Tue, Mar 16, 2010 at 04:51:49PM +0100, Christophe Meessen
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'm really not
On Tue, Mar 16, 2010 at 05:32:42PM -0500, Dan White 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 provide
On Tue, Mar 16, 2010 at 03:40:46PM +0100, Christophe Meessen
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 efficiently
> impleme
On Tue, Mar 16, 2010 at 03:24:32PM +0100, Christophe Meessen
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 independently.
>
> I was consi
On 16/03/10 02:23 +0100, Marc Lehmann wrote:
On Mon, Mar 15, 2010 at 11:07:53PM +, James Mansion
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 is not necessarily so: a spinl
On Tue, Mar 16, 2010 at 9:51 AM, Christophe Meessen
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
>> threads.
>>
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
[http:
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
connection
On Tue, Mar 16, 2010 at 8:40 AM, 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 conn
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 threa
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 indepen
On Tue, Mar 16, 2010 at 12:15 AM, James Mansion
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 seeing with
>>
>
> This
On Tue, Mar 16, 2010 at 06:55:07AM +, James Mansion
wrote:
> 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* p
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, of
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 th
On Mon, Mar 15, 2010 at 11:07:53PM +, James Mansion
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 switc
On Mon, Mar 15, 2010 at 5:07 PM, James Mansion
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 think so. (re: i
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, contex
On Mon, Mar 15, 2010 at 08:48:20PM +0500, mikhail maluyk
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 query or
does disk I/O.
Of
On Mon, Mar 15, 2010 at 02:58:14PM +0100, Christophe Meessen
wrote:
>> When you can't use a more efficient process model
>> and for some reason *have* to use threads, a lader/follower pattern, or
>> multiple event loops, are usually more preferable. YMMV.
>>
> The pattern I describe is the le
On Mon, Mar 15, 2010 at 7:52 PM, 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 loop, and c
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 pro
Le 15/03/2010 13:09, Marc Lehmann a écrit :
On Mon, Mar 15, 2010 at 11:48:54AM +0100, Christophe
Meessen wrote:
It looks like libev is designed to have one thread calling the ev_loop
and executing the callbacks (assumed to be fast and never blocking).
This is a straightforward design but
On Mon, Mar 15, 2010 at 01:55:18PM +0100, Christophe Meessen
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 the event loop
once,
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 11:48:54AM +0100, Christophe Meessen
wrote:
> It looks like libev is designed to have one thread calling the ev_loop
> and executing the callbacks (assumed to be fast and never blocking).
>
> This is a straightforward design but it is not performance optimal when
> req
Hello,
I'm new to this list and just discovered the existence of libev this
morning. So forgive me if this is a FAQ.
It looks like libev is designed to have one thread calling the ev_loop
and executing the callbacks (assumed to be fast and never blocking).
If it is to be used for a server pro
38 matches
Mail list logo