Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[cee1]

2015-10-17 3:29 GMT+08:00 Nicolas Dufresne :
> Le samedi 17 octobre 2015 à 01:20 +0800, cee1 a écrit :
>> 2015-10-16 23:46 GMT+08:00 Florian Müllner :
>> > On Fri, Oct 16, 2015 at 5:38 PM, cee1  wrote:
>> >> If yes, we may let GObject inherit from
>> >> GstMiniObject to obtain the COW feature?
>> >
>> > This would break ABI, so not something you should expect any time
>> soon.
>>
>> So what about GObject2(a bit likes playbin2 in GStreamer)? Code can
>> change to inherit from it and recompiling...
>
> That's an extremely ugly fallback solution, specially for a feature
> that no one will use.
>
> The problem here is that GObject cannot be copied generically, when
> they are, it's a custom feature. Note that reference based locking
> isn't always great. If I was to redo that, I'm opt for explicit locking
> instead. In GStreamer we have hit many of the limitation of this model.
> This can of course be introduced with an GInterface if you drop this cr
> azy idea of using ref-count to figure-out writability.
>
Is there any examples about the limitation of this reference count
based model at hand?

So can I say gstreamer use COW mainly for locking(similar to RCU), not
for the purpose of removing duplication?

For comparison, IIUIC, EFL implements a GSlice (some what)equivalent
layer[1], but provides COW-able memory objects. It will even find
memory objects which have the same content and merge them in idle,
according to the article
https://phab.enlightenment.org/phame/live/1/post/efl_memory_consumption_moo/.

BTW, I go through internal of gst_mini_object_make_writable, and
following logical seems confused:
"""
http://cgit.freedesktop.org/gstreamer/gstreamer/tree/gst/gstminiobject.c#n190

gst_mini_object_lock()
...
if (access_mode & GST_LOCK_FLAG_EXCLUSIVE) {
  /* shared ref */
  newstate += SHARE_ONE;
  access_mode &= ~GST_LOCK_FLAG_EXCLUSIVE;
}
"""

Why under an EXCLUSIVE mode, a mini object can be shared?



---
1. https://docs.enlightenment.org/stable/efl/group__Eina__Cow__Group.html


Regards,

- cee1
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[cee1]

2015-10-17 1:26 GMT+08:00 Emmanuele Bassi :
> Hi;
>
> On 16 October 2015 at 18:15, cee1  wrote:
>
>> The idea here is trying to make a thinner event loop.
>
> You keep using that word, "thin". I don't think it means what you
> think it means.
>
> You have consistently failed to bring any measurement, or any metric,
> that would allow you (or anybody else) to identify what's the current
> state of GLib, and how would we identify a "thinner" version of GLib.
>
> Saying that you want a "lightweight" version of GLib is pointless, if
> you also don't define a system of measurement that defines what
> "lightweight" even means.
>
Yeah, a profile/measurement is necessary when discuss '*thin*'. While
on the other hand, IMHO, comparing similar libraries which deploying
different approaches may inspire some ideas. Here, as an example: the
COW approach to remove duplication, a simpler event loop ...

Quite frankly, GMainLoop seems a little complicated to me, especially
compared with the event handling in GCD[1]. Hence, I'm wondering
whether I can combine an external event loop without GMainContext
involved.


>> I'm wondering is it a thinner and cleaner implementation, that
>> GTK+/GIO/etc provide hooks and let client or utility/glue library use
>> these hooks to put GTK+/GIO/etc into their event loop.
>
> The idea is to have a fd-based interface that lets you extract a
> (pollable) descriptor from GMainContext, and additional main loops can
> poll on that; see the (lengthy) discussion on:
> https://bugzilla.gnome.org/show_bug.cgi?id=699132
>
Thanks for pointing out this patch out :)

In this patch, the iteration of the event loop is
poller->funcs->iterate(), take epoller as an example, which will then:

1. Invoke g_main_loop_prepare_poll() to invoke GSource.prepare, and
notify epoller to update epoll_fd through "add_fd / modify_fd /
remove_fd" in context_update_poller().

2. Do epoll()

3. Invoke g_main_loop_process_poll() to run GSource.check and GSource.dispatch.

It is a big step to utilize scalable event loop implementation, while
still a little complicated...



---
1. 
https://github.com/cee1/cee1.archive/blob/master/documents/libdispatch-event.pdf

- Regards,

cee1
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[Nicolas Dufresne]

Le lundi 19 octobre 2015 à 15:57 +0800, cee1 a écrit :
> Is there any examples about the limitation of this reference count
> based model at hand?
> 
> So can I say gstreamer use COW mainly for locking(similar to RCU),
> not
> for the purpose of removing duplication?

Memory locking is a term used in certain graphics stacks. It means
gaining access to the data with specific permissions.

see, gst_mini_object_lock() and gst_mini_object_unlock(). These have
nothing to do with mutexes.

Nicolas

signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[Emmanuele Bassi]

Hi;

On 16 October 2015 at 18:15, cee1  wrote:

> The idea here is trying to make a thinner event loop.

You keep using that word, "thin". I don't think it means what you
think it means.

You have consistently failed to bring any measurement, or any metric,
that would allow you (or anybody else) to identify what's the current
state of GLib, and how would we identify a "thinner" version of GLib.

Saying that you want a "lightweight" version of GLib is pointless, if
you also don't define a system of measurement that defines what
"lightweight" even means.

> E.g. g_socket_client_connect_async calls g_task_new, which uses
> idle_source - routes to a main context and fires.

That's a pretty wrong understanding of how GTask actually works.

> The idea is from the evas - "evas is not dependent or aware of main
> loops".

Let's leave Evas out of this discussion.

> I'm wondering is it a thinner and cleaner implementation, that
> GTK+/GIO/etc provide hooks and let client or utility/glue library use
> these hooks to put GTK+/GIO/etc into their event loop.

The idea is to have a fd-based interface that lets you extract a
(pollable) descriptor from GMainContext, and additional main loops can
poll on that; see the (lengthy) discussion on:
https://bugzilla.gnome.org/show_bug.cgi?id=699132

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[cee1]

2015-10-16 23:46 GMT+08:00 Florian Müllner :
> On Fri, Oct 16, 2015 at 5:38 PM, cee1  wrote:
>> If yes, we may let GObject inherit from
>> GstMiniObject to obtain the COW feature?
>
> This would break ABI, so not something you should expect any time soon.

So what about GObject2(a bit likes playbin2 in GStreamer)? Code can
change to inherit from it and recompiling...



-- 
Regards,

- cee1
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[Emmanuele Bassi]

Hi;

On 16 October 2015 at 18:20, cee1  wrote:
> 2015-10-16 23:46 GMT+08:00 Florian Müllner :
>> On Fri, Oct 16, 2015 at 5:38 PM, cee1  wrote:
>>> If yes, we may let GObject inherit from
>>> GstMiniObject to obtain the COW feature?
>>
>> This would break ABI, so not something you should expect any time soon.
>
> So what about GObject2(a bit likes playbin2 in GStreamer)? Code can
> change to inherit from it and recompiling...

What would be the point, if everything that currently depends on
GObject still has to depend on GObject?

That's the reason why we don't break GLib's ABI: not because we don't
want, but because then *everything* that depends on GLib would need to
break API/ABI. If you introduce a new type, you won't get any benefit
unless you also port everything to it — which nullifies the benefit of
introducing a new type without breaking ABI in the first place.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[cee1]

2015-10-15 23:00 GMT+08:00 Nicolas Dufresne :
> Le jeudi 15 octobre 2015 à 22:14 +0800, cee1 a écrit :
>> >> providing APIs to make GTK+(also GIO) easily integrated to other
>> >> event
>> >> loop, then we use epoll() on Linux, kqueue() onBSD or even
>> >> libdispatch[3] - client code can use simpler event loop(e.g. no
>> >> locks,
>> >> no recursive main loop support)
>> >
>> > This is all fully supported.
>> For GStreamer, yes. But not for GIO or GTK+? I guess.
>
> It's all provided by GLib. You should document yourself better. I've
> combined glib main loop into other loops many times, I know it's fully
> supported and has been for years. GStreamer is special case, as you
> don't need a main loop, though application is easier to write with one.

The idea here is trying to make a thinner event loop.

E.g. g_socket_client_connect_async calls g_task_new, which uses
idle_source - routes to a main context and fires.

Then "integrating gmainloop into other loops", does it need:
1)  Run g_main_context_iterate()? if yes, still extra locks, nested
loop(If they aren't needed in the specific scenario), still no epoll
or kqueue, etc.
2)  Retrieve fds from GSources(if attached fds), and add to external
epoll/kqueue, run prepare/check/dispatch in a proper position? This
seems a bit hard

The idea is from the evas - "evas is not dependent or aware of main
loops". I'm wondering is it a thinner and cleaner implementation, that
GTK+/GIO/etc provide hooks and let client or utility/glue library use
these hooks to put GTK+/GIO/etc into their event loop.



-- 
Regards,

- cee1
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[cee1]

2015-10-15 23:02 GMT+08:00 Christian Hergert :
> On 10/15/2015 07:19 AM, cee1 wrote:
>>> From GStreamer point of view, the main problem as it was explained to
>>> > me, is the global locks, creating contention (GStreamer is highly multi
>>> > -threaded). It's also a base type reserved for very specific use cases
>>> > (where a lot of that type need to be allocated, GstBuffer, GstEvent,
>>> > etc.). I'm not sure it make much sense generically. Specially that you
>>> > loose most of the feature of an object, properties, interface, signal,
>>> > etc.
>>
>> Such mini objects may also play a role in GTK+, I guess...
>
> Almost certainly not. Gtk uses properties and signals heavily, and is
> dominated by single threaded operations. Basically the complete opposite
> of why GstMiniObject was created.

GstMiniObject is discussed because the COW feature (aka.
gst_mini_object_make_writable). So the question is will GTK+ benefit
from the COW feature? If yes, we may let GObject inherit from
GstMiniObject to obtain the COW feature?



-- 
Regards,

- cee1
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[Florian Müllner]

On Fri, Oct 16, 2015 at 5:38 PM, cee1  wrote:
> If yes, we may let GObject inherit from
> GstMiniObject to obtain the COW feature?

This would break ABI, so not something you should expect any time soon.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[Nicolas Dufresne]

Le jeudi 15 octobre 2015 à 22:14 +0800, cee1 a écrit :
> >> providing APIs to make GTK+(also GIO) easily integrated to other
> >> event
> >> loop, then we use epoll() on Linux, kqueue() onBSD or even
> >> libdispatch[3] - client code can use simpler event loop(e.g. no
> >> locks,
> >> no recursive main loop support)
> >
> > This is all fully supported.
> For GStreamer, yes. But not for GIO or GTK+? I guess.

It's all provided by GLib. You should document yourself better. I've
combined glib main loop into other loops many times, I know it's fully
supported and has been for years. GStreamer is special case, as you
don't need a main loop, though application is easier to write with one.

Nicolas

signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[rastersoft]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all:

El 14/10/15 a las 21:16, Matthias Clasen escribió:
>
> We (taking my GStreamer hat) havent heard of any interest from the
GLib
> group for lightweight objects. Note that some library ended up also
> having these lightweight kind of object, hence may be interesting to
> eventually consolidate.
>
>
> I think it is fair to say that there is more interest in fixing
performance of GObject than there is in introducing a miniobject type.
Not sure if that qualifies as 'interest in lightweight objects' or not.

In fact, "compact classes" in vala can qualify as lightweight objects,
isn't it? They are nothing more than a struct and some functions, and to
do that, you don't need help from GObject.

- -- 
Nos leemos
 RASTER(Linux user #228804)
ras...@rastersoft.com  http://www.rastersoft.com

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWH8flAAoJED690wQnnlF1OqIP/2G58FHCVz9d++lSHbvAPsKW
KwqDcjb9LfBzwGlXfHewl+mIYSkjqbgZkdIPJhNlEFdnoX98I2ljiBaTRyZ4iKs1
PTjPEnU/5Y+4ZJjkvAlE7QKRWDuy0U5Cs93kyefmhL/SmsfAdBHmRZj8i6rXxpw2
8qIYb/eunbBZuX4U6X1G9BFyBCe4mz+6/7r90dpEilvhzbH77Dr88aeRlLHIjOjT
67fWrY3kjV2fgeDkDIVrkJwNxTqH0D7jHCPk+Wf1tywjKqgoG+CHYNX3cibrnbnN
UPhIENtlHEPqaia7LT/+J9pfenIKAlsmtqT35iXjFyxwIR6t5VMcudsRwL2Mf2WC
MJNmGsAxaZrrLMBRX/ECFwcqQRciEDpjDg07m1hkRrRLz8gevM7Zz6Z8QpqkSFjE
EhTE4x3h9EskfVLSoqAQgVsQERKGqmIEDEAjHReayDRXpqsuiApIfhPKedMy/C7d
7Zw8yR/a7EVKZJEkEtkuoQOrZJ2KtYuss9kzh0bZqhGrYsF+oeuB4GBr3b411/Oq
/Wz5F1uwbYv2WNA5A8VEWuP5QUwnwHWWCxF6HkU1FARiZFmLZQIK1uZZqn7HkpmR
/swRM4QqcGlyYyvj1jpIBbOA8IeI8wmmxQmL4SqPx2rKcK7muMIA4r7riWKqok+D
SnxruXYMTk0/Gc2gXk8G
=NBHw
-END PGP SIGNATURE-

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[cee1]

2015-10-14 23:40 GMT+08:00 Nicolas Dufresne :
> Le lundi 12 octobre 2015 à 23:24 +0800, cee1 a écrit :
>
> GLib is already broken up into a whide amount of shared library. Even
> though, shared library tend to create a small size overhead.
> Considering this is a supporting library, it's probably not ideal to
> try and disable random features. What we endup doing here, is using
> static build, so whatever you don't use can later be stripped. It's
> more work in regard to the LGPL.
Then, I'm imaging a procedure of "static building" subset of glib
symbols into a library, and clients link to it...

>> providing APIs to make GTK+(also GIO) easily integrated to other
>> event
>> loop, then we use epoll() on Linux, kqueue() onBSD or even
>> libdispatch[3] - client code can use simpler event loop(e.g. no
>> locks,
>> no recursive main loop support)
>
> This is all fully supported.
For GStreamer, yes. But not for GIO or GTK+? I guess.



-- 
Regards,

- cee1
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[cee1]

2015-10-15 3:44 GMT+08:00 Nicolas Dufresne :
> Le mercredi 14 octobre 2015 à 15:16 -0400, Matthias Clasen a écrit :
>> I think it is fair to say that there is more interest in fixing
>> performance of GObject than there is in introducing a miniobject
>> type. Not sure if that qualifies as 'interest in lightweight objects'
>> or not.
>
> From GStreamer point of view, the main problem as it was explained to
> me, is the global locks, creating contention (GStreamer is highly multi
> -threaded). It's also a base type reserved for very specific use cases
> (where a lot of that type need to be allocated, GstBuffer, GstEvent,
> etc.). I'm not sure it make much sense generically. Specially that you
> loose most of the feature of an object, properties, interface, signal,
> etc.
>
Such mini objects may also play a role in GTK+, I guess...



-- 
Regards,

- cee1
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[cee1]

2015-10-15 3:16 GMT+08:00 Matthias Clasen :
> On Wed, Oct 14, 2015 at 11:40 AM, Nicolas Dufresne
>  wrote:
>>
>> Le lundi 12 octobre 2015 à 23:24 +0800, cee1 a écrit :
>>
>> >
>> > 2. I notice EFL use some "COW" logic[1], but we already have a much
>> > clean implementation in GStreamer, that's
>> > gst_mini_object_make_writable[2]. Then we may merge GstMiniObject
>> > back
>> > to glib?
>>
>> We (taking my GStreamer hat) havent heard of any interest from the GLib
>> group for lightweight objects. Note that some library ended up also
>> having these lightweight kind of object, hence may be interesting to
>> eventually consolidate.
>
>
> I think it is fair to say that there is more interest in fixing performance
> of GObject than there is in introducing a miniobject type. Not sure if that
> qualifies as 'interest in lightweight objects' or not.
>
I dimly remember there was a branch for GObject performance tuning?



-- 
Regards,

- cee1
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[Christian Hergert]

On 10/15/2015 07:19 AM, cee1 wrote:
>> From GStreamer point of view, the main problem as it was explained to
>> > me, is the global locks, creating contention (GStreamer is highly multi
>> > -threaded). It's also a base type reserved for very specific use cases
>> > (where a lot of that type need to be allocated, GstBuffer, GstEvent,
>> > etc.). I'm not sure it make much sense generically. Specially that you
>> > loose most of the feature of an object, properties, interface, signal,
>> > etc.
>
> Such mini objects may also play a role in GTK+, I guess...

Almost certainly not. Gtk uses properties and signals heavily, and is
dominated by single threaded operations. Basically the complete opposite
of why GstMiniObject was created.

-- Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[Nicolas Dufresne]

Le lundi 12 octobre 2015 à 23:24 +0800, cee1 a écrit :
> Hi all,
> 
> I'm thinking and interested in the idea of running Glib/GTK+ based
> applications on tiny devices, e.g. wearable devices.
> 
> I notice Tizen employs EFL because it is lightweight and fast. But
> when went through the code, it seems terrible and in a mess.
> 
> Glib is clean and elegant, and with the incoming GSK, GTK+ will be
> polished. I'm thinking how to make Glib/GTK+ thinner ( to make memory
> footprint comparable with EFL's , though I haven't found any 'GTK+ vs
> EFL' benchmark yet...)
> 
> And here are some rough thoughts:
> 1. Make Glib/GTK+ more modular for building, e.g. a configuration
> system similar to linux kernel's. Autoconf do support select in/out
> optional modules, but will be too many configure args with a huge
> options.

GLib is already broken up into a whide amount of shared library. Even
though, shared library tend to create a small size overhead.
Considering this is a supporting library, it's probably not ideal to
try and disable random features. What we endup doing here, is using
static build, so whatever you don't use can later be stripped. It's
more work in regard to the LGPL.

> 
> 2. I notice EFL use some "COW" logic[1], but we already have a much
> clean implementation in GStreamer, that's
> gst_mini_object_make_writable[2]. Then we may merge GstMiniObject
> back
> to glib?

We (taking my GStreamer hat) havent heard of any interest from the GLib
group for lightweight objects. Note that some library ended up also
having these lightweight kind of object, hence may be interesting to
eventually consolidate.

> 
> 3. Remove extra layers. E.g. the malloc implementations in nowadays
> are very powerfull(e.g. jemalloc), hence GSlice can be retired(which
> otherwise introduces an extra cache layer).Also I'm thinking
> about

I do believe disabling GSLice is already possible.

> providing APIs to make GTK+(also GIO) easily integrated to other
> event
> loop, then we use epoll() on Linux, kqueue() onBSD or even
> libdispatch[3] - client code can use simpler event loop(e.g. no
> locks,
> no recursive main loop support)

This is all fully supported.

Nicolas


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[Matthias Clasen]

On Wed, Oct 14, 2015 at 11:40 AM, Nicolas Dufresne <
nicolas.dufre...@collabora.com> wrote:

> Le lundi 12 octobre 2015 à 23:24 +0800, cee1 a écrit :
>
> >
> > 2. I notice EFL use some "COW" logic[1], but we already have a much
> > clean implementation in GStreamer, that's
> > gst_mini_object_make_writable[2]. Then we may merge GstMiniObject
> > back
> > to glib?
>
> We (taking my GStreamer hat) havent heard of any interest from the GLib
> group for lightweight objects. Note that some library ended up also
> having these lightweight kind of object, hence may be interesting to
> eventually consolidate.
>

I think it is fair to say that there is more interest in fixing performance
of GObject than there is in introducing a miniobject type. Not sure if that
qualifies as 'interest in lightweight objects' or not.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list