From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id A4C601BA007E for ; Wed, 10 May 2017 03:08:03 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 1EB7AB5D869 for ; Wed, 10 May 2017 03:51:51 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id 14B1018CC829 for ; Wed, 10 May 2017 03:51:50 +0900 (JST) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 981581206A6; Wed, 10 May 2017 03:51:48 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTPS id ABC2912040E for ; Wed, 10 May 2017 03:51:43 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id F18381FDEA; Tue, 9 May 2017 18:51:40 +0000 (UTC) Date: Tue, 9 May 2017 18:51:40 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20170509185140.GA17410@starla> References: <20170508030120.GB24763@starla> <94ca8f9a-7001-12d3-323d-8c5751569c51@atdot.net> <20170508063633.GA6821@starla> <4a83bbeb-b22b-61ec-a03f-657746843431@atdot.net> <20170509033806.GA27973@starla> <20170509051223.GA31857@whir> <20170509062353.GB8654@starla> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-ML-Name: ruby-core X-Mail-Count: 81078 Subject: [ruby-core:81078] Re: [ruby-cvs:65407] normal:r58236 (trunk): thread.c: comments on M:N threading [ci skip] X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" SASADA Koichi 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?