SASADA Koichi <ko1 / atdot.net> wrote:
> On 2017/05/09 15:23, Eric Wong wrote:
> > OK.  I also started to work on making GVL switch nd remaining native
> > mutex/condvars faster on Linux by using futex.  However, it is only
> > faster with multi-core, single core performance is a little slower.
> > 
> > 	https://80x24.org/spew/20170509062022.4413-1-e / 80x24.org/raw
> > 	(I still use my Pentium-M laptop from 2005 :)
> 
> Let us clear the your plan.
> 
> Maybe we have several tasks.
> 
> (1) lightweight fiber switching by pointer-exchange
>     (w/o copying context).

Out of all tasks here, I am least familiar with this (1).
This will be learning experience for me.

> (2) auto-fiber swiching
>    (2-1) implement with epoll/kqueue/select
>    (2-2) design APIs to use it

I think I will start on the select implementation first for
portability, but model our internal API around epoll(*).
I will probably implement epoll support last, since I am
most familiar with it.

(*) with current GVL, I expect our kqueue+kevent implementation
    will be faster than epoll in most cases (the API requires
    fewer syscalls).  select might be fastest with few FDs.

> (3) Implement GVL with futex (in your comment)

Maybe last.  Linux-only, single (but most important)
platform; and the single CPU regression needs to be fixed.

> (4) Re-implement Queue (some days ago you wrote)

I already had some work-in-progress patches I can cleanup and
send out to redmine for review later (also ConditionVariable).
Last I remember, there was a small performance regression for
small Queue/Condvar waiter lists due to better locality on embed
structs.  However, I think avoiding O(n) rb_ary_delete behavior
is more important for busy queues.

> (please add your plan if you have others)

I might break out thread.c and io.c into smaller files
(select/epoll/kqueue/timer_thread/copy_stream/...)
to make code organization easier.

> Do you have a schedule? (priority?)

I don't know how long (1) will take, (4) is almost done.
(2) maybe 1-3 weeks.  (3) not sure how long it will take
to fix single CPU performance.

Also, I will try not to break platforms I don't use.  As you
know I only use Free Software, so I would appreciate if you or
platform maintainers can help fix portability bugs on non-Free
systems.

Do you have any deadlines or priorities?

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>