Date: Wed, 23 Apr 2014 06:05:31 -0700 From: Neil Schroeder <gigneil@gmail.com> To: Ivan Klymenko <fidaj@ukr.net> Cc: "ports@freebsd.org" <ports@freebsd.org>, Baptiste Daroussin <bapt@freebsd.org>, "x11@freebsd.org" <x11@freebsd.org> Subject: Re: [CFT] x11-servers/xorg-server with initial (GCD) Grand Central Dispatch support Message-ID: <CAK9pY-xJ4BDVhJNNcvbx6-pHNvDhXOxGex8G16sDWtWfmY8%2B0A@mail.gmail.com> In-Reply-To: <20140423152625.5bb692b9@nonamehost.local> References: <20140420200534.72226779@nonamehost.local> <20140423065824.GE63561@ivaldir.etoilebsd.net> <20140423152625.5bb692b9@nonamehost.local>
next in thread | previous in thread | raw e-mail | index | archive | help
You'd be surprised where you can apply a dispatch - anywhere there is an iterator, a thread forked, or a read from/to file, network, or io you can - for almost no cost - just wrap that call in a block (my brain wants to call it an nsoperation queue ) and dispatch it. Basically anything you don't expect to come back right away, you can benefit from dispatching it. Also a single queue can be read or write from multiple threads without locking - it just works. So if you have a bunch of calls to basically anything that isn't directly in ram right then, you could benefit from dispatching. This is ESPECIALLY beneficial for user io and ui updates - like a button click. You should immediately dispatch the action from that button click so you can move on to updating the UI. Gives the perception of hugely Improved performance and frees up the main thread for doing what the main thread does - basically starts the program and refreshes the UI. I'll see about patching 1.15 - this does beg one question however - X is a major piece of infrastructure and is single threaded after 30 years. If such benefits are huge, why has nobody at least threaded it yet? Keep in mind that most functionality has been moved out of X and into libraries and the kernel - if X actually has to render something, it's an exception these days... Everyone speaks EGL or OpenGL to the display rendering manager directly... So I wonder, how much actual benefit does this have? I'm truly asking from a metrics perspective. What percentage of total cycles spent does this impact vs what is being handled in the Display driver, window manager, etc? On Wednesday, April 23, 2014, Ivan Klymenko <fidaj@ukr.net> wrote: > =D0=92 Wed, 23 Apr 2014 08:58:24 +0200 > Baptiste Daroussin <bapt@FreeBSD.org> =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > > > Thank you for those patches, imho that is something we really do > > need. > > I would just have a couple of side notes: > > Wouldn't it be possible to use callbacks in the dispatch call rather > > than blocks? > > If I understand you correctly... > Unfortunately not for all areas of the code it is possible ... > I, in fact, only parallelize loops for "for" operator. > The remaining sections of code where this is possible, I have not > looked. > If translate to the use of GCD more significantly - then need to > rewrite a lot of code. > > > that will make the patch work on FreeBSD 8, 9, 10 and > > head with clang AND gcc, which will greatly improves the chances to > > see those patch well tested and used enough to finally be > > incorporated in the ports. > > > > I started doing what I know how and what I can :) > If there is help, examples and comments from others - I'm just glad :) > > > regards, > > Bapt > > _______________________________________________ > freebsd-x11@freebsd.org <javascript:;> mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org<jav= ascript:;> > "
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK9pY-xJ4BDVhJNNcvbx6-pHNvDhXOxGex8G16sDWtWfmY8%2B0A>