[Bug libc/207] New: ucontext is very slow.

[Bug libc/207] New: ucontext is very slow.

[a dot darovskikh at compassplus dot ru]

We use ucontext related functions in our project.
We port it from Windows, where we used to deal with
*Fiber functions. During the tests we discovered that
our task engine on linux is near 10 times slower than 
windows one.

Here are two small examples on context swapping on windows fibers
and unix ucontexts. Unix one works near 5 seconds against 0.4 on
windows one.

Is it possible to improve perfomance?

Thanks in advance. Alexander Darovsky.

-- 
           Summary: ucontext is very slow.
           Product: glibc
           Version: 2.3.3
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: a dot darovskikh at compassplus dot ru
                CC: glibc-bugs at sources dot redhat dot com
  GCC host triplet: Linux 2.6.0


http://sources.redhat.com/bugzilla/show_bug.cgi?id=207

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/207] ucontext is very slow.

[a dot darovskikh at compassplus dot ru]

------- Additional Comments From a dot darovskikh at compassplus dot ru  2004-06-07 08:47 -------
Created an attachment (id=106)
 --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=106&action=view)
A windows test case


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=207

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/207] ucontext is very slow.

[a dot darovskikh at compassplus dot ru]

------- Additional Comments From a dot darovskikh at compassplus dot ru  2004-06-07 08:48 -------
Created an attachment (id=107)
 --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=107&action=view)
A unix ucontext test case


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=207

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/207] ucontext is very slow.

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2004-06-08 14:38 -------
Hardly.
More than 50% of the time is spent in sigprocmask syscalls, which are needed
(the program can change its signal mask any time and this needs to be preserved,
caching current signal mask in userland would be a huge can of problems and
slowdowns for little gain).
The other big part of the total time is spent on saving/restoring FPU state
(again, swapcontext must do this) and that's about it.

Why aren't you using real threads instead?


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sources.redhat.com/bugzilla/show_bug.cgi?id=207

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/207] ucontext is very slow.

[a dot darovskikh at compassplus dot ru]

------- Additional Comments From a dot darovskikh at compassplus dot ru  2004-06-09 04:30 -------
Subject: Re:  ucontext is very slow.

On Tuesday 08 June 2004 20:38, jakub at redhat dot com wrote:
> ------- Additional Comments From jakub at redhat dot com  2004-06-08 14:38
> ------- Hardly.
> More than 50% of the time is spent in sigprocmask syscalls, which are
> needed (the program can change its signal mask any time and this needs to
> be preserved, caching current signal mask in userland would be a huge can
> of problems and slowdowns for little gain).
> The other big part of the total time is spent on saving/restoring FPU state
> (again, swapcontext must do this) and that's about it.
>
> Why aren't you using real threads instead?

This is because we use thousands so-called "tasks", which access on the same 
"tree". If we implement it using real threads, they will use complex 
synchronization, which will take much more time than the real work. This is 
why we need cooperative multitasking. There are some more complex reasons for 
this, so I'm afraid, we will not able to use real threads. Indeed, we do use 
it, but it's for external things, like database connections.

Is it possible to avoid sigprocmask syscalls and FPU things? We do not use it.

Maybe it's possible to take this code and remove those calls from it? Or use 
something like setjmp/longjmp? I tried last one, but timings were even worse.

Alexander Darovsky.


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=207

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/207] ucontext is very slow.

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2004-08-10 02:06 -------
The functions already do the minimal amount of work.  There are no speedups
possible.  Create your own library with specialized code which does not have to
be general if you don't like it.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WONTFIX


http://sources.redhat.com/bugzilla/show_bug.cgi?id=207

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.