Skip site navigation (1)Skip section navigation (2)
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>