Re: [E-devel] Ecore - Efl.Loop + Task + Thread + App + Appthread + Exe
On Mon, 05 Mar 2018 17:25:09 -0500 Cedric Bail said:
> On March 5, 2018 6:00 AM, Gustavo Sverzut Barbieri wrote:
>
>
>
> > Well, I already mentioned this to you in irc, but replying here just
> > to make my point:
> >
> > I think the design is upside down, trying to make life easier at some
> > point resulted in messy at the other side.
> >
> > okay, call it a task, work for both process and threads, the hope is
> > to facilitate "switch from threads to process, and vice versa", but
> > we're getting the worst part of each it seems.
> >
> > ie: most thread usage is about sending shared memory back and forth,
> > after all the benefit of threads is just that: shared memory. What we
> > got? argv + int, useless for real life threads.
> >
> > solution? "stdio" for threads... you can send/receive I/O, done with
> > pipes, like it would be for processes.
> >
> > I really, really don't like that design. To me threads should be
> > exposed as such, with pointer argument and result... if you wish to
> > make it easier, you could "box" it someway, like eina_value... or just
> > let the traditional "void *pointer". But that's fundamental, say for
> > Python bindings to use threads, you want to send PyObject pointer to
> > the thread, that object will contain the information to callback the
> > user (the user's Python-callable). And for most usages as well, like
> > sending file info to be opened/decoded, etc.
>
> I do second you completely Gustavo. I have been raising my discontent with
> this design for a long time now and fully agree with your point here.
>
> > thread I/O, while useful in some cases, I don't see why they should
> > always exist. They should be optional, and as such they should be
> > created explicitly.
>
> Agreed.
>
> > Last but not least, I'd expose the stack just like in the OS, to not
> > make confusion:
> >
> > - Application ("the binary") -> Processes -> Threads -> main loop
> >
> > you can present "getters" that make it easier to access (ie: main loop
> > "get" application, in addition to "get parent" which would return the
> > thread).
> >
> > But mixing stuff "in the hope to make it easier" it not, it's just
> > making things more complicated... ALSO note that the developer that
> > would use this kind of API is "not the average developer", these don't
> > mess with such low level primitives. The developer that is likely to
> > use these primitives will say "what the fuck is this? I'm used to
> > processes and threads, these guys just messed it up".
> >
> > I'm in favor of interfaces for things that are the same, so if the
> > methods in process and threads share the same concept, behavior and
> > parameters, make them an interface... when switching from process x
> > threads one doesn't need to "sed" everything. However, definitely
> > constructors are NOT the same concept, behavior or parameters, thus
> > not part of the interface.
>
> I would add that this thread model doesn't satisfy any of the use case we
> ourself have. For example :
>
> - Ector: use thread to offload CPU and memory heavy task to another thread.
> The simple change to BFL has slowed us down. Now, if we do have to
> serialize/unserialize everything ? I have already my bet on the result.
ector using eo was and is a mistake. it's a performance sensitve part of
rendering and going through eo to do everything is bad/wrong.
the alternative is even slower eo with more locking on a global table or no
locking which is what we originally had and then we had mysterious random
crashes instead. hooray!
don't use eo for ector. simple. it's inappropriate.
> - Evas async renderer: same case as Ector. Nobody might remember, but at the
> beginning it was really slower, because of the memory copy that was done and
> it had to be removed. If we were to use this new infrastructure, it would
> lead to be back to a slower solution.
eh? it was barely noticeable. and i've been very clear that thew i/o using using
a pipe as an IMPLEMENTATION DETAIL. it could use shared buffers. but they still
require a copy into the shared buffer in userspace then out again. something
like thread queue when it doesn't do copies has thread queue about 1.6x the
speed for high volume messages in and out. i've done the benchmarks. arm
seems to have a hiccup that shouldn't be the case and is maybe. i shall bring
numbers to my aid:
https://phab.enlightenment.org/P170
https://phab.enlightenment.org/P168
a pipe is 60% slower than a zero-copy thread queue (x86) on arm 8x slower and
as kernel devs told me "that shouldn't be the case" so it's a bug it seems. the
io interface can't work with zero copy because that requires allocating your
buffers ON the thread queue to avoid a copy and not passing them in like the io
iface does. so you'd add a copy into the thread queue anyway... which i would
suspect would nuke even more of delta between them. it's barely worth talking
about in terms of performance especially for low volume. for high volume
Re: [E-devel] Ecore - Efl.Loop + Task + Thread + App + Appthread + Exe
On Tue, 6 Mar 2018 10:37:10 -0300 Gustavo Sverzut Barbieri said: > On Tue, Mar 6, 2018 at 5:40 AM, Carsten Haitzler wrote: > > On Mon, 5 Mar 2018 11:00:27 -0300 Gustavo Sverzut Barbieri > > said: > > > >> On Sat, Mar 3, 2018 at 2:02 AM, Carsten Haitzler > >> wrote: > >> > I just pushed: > >> > > >> > eb0b826776b60e0d97218242a5c285d146fb6f3b > >> > > >> > https://git.enlightenment.org/core/efl.git/commit/?id=1bdd9e4dd15fc27da43b50fd29bfb1b0b30ef6bd > >> > > >> > I wrote up a high level design document and description here for an idea > >> > of how it works: > >> > > >> > https://phab.enlightenment.org/w/efl-loops-threads/ > >> > > >> > I'm busy filling that document out a bit, but the core essentials are > >> > there. > >> > > >> > There are some details like loop having an exit eina value vs task > >> > having a simple int exit code (i'm sticking to this because it is what > >> > processes do, it's simple and its universally supported between > >> > processes, unlike an eina value). yes - it simplifies threads to only > >> > having int exit codes, but the simplicity of the design is what I'm > >> > going for. threads like executeables have full bytestream I/O for more > >> > complex data interchange. So there probably needs to be a bit of > >> > adjusting here and there to remove duplication. The Arguments event > >> > delivers arguments in an array, but the task object also stores > >> > arguments too permanently. Do we need to double-up the information? So a > >> > few small things like this. > >> > > >> > I've given this design a lot of thought and what I have here I think is > >> > clean and neat, tidy and fairly simple. It actually does work. I have > >> > tested it of course. But please have a look and let me know what you > >> > think. Are there some major defects in the design and idea? I know we > >> > can expand this in future with more controls (I have no pause/resume > >> > controls in the task interface but there should be. For processes use > >> > SIGSTOP/CONT and for threads a co-operative request on the control > >> > line). The internals could be better. I use pipes and this eats up a lot > >> > of FD's for the threads where I could use socketpairs instead. I have a > >> > separate control pipe in/out from I/O in/out where i could multiplex on > >> > the same socketpair. Currently we run out of FD's (after about 240 > >> > threads running at once because they eat up 8 FD's per thread. The > >> > Efl.Io code across the classes is a lot of copy & paste... And I don't > >> > have anything to change priority of a thread once it has run (no eina > >> > API for this - needs to be added). > >> > > >> > I'm not that happy though with Efl.Io and the sheer amount of code > >> > needed to deal with it. Even as a user of the API. > >> > > >> > Anyway - comments, thoughts, etc. etc. ? > >> > >> Well, I already mentioned this to you in irc, but replying here just > >> to make my point: > >> > >> I think the design is upside down, trying to make life easier at some > >> point resulted in messy at the other side. > > > > how? where? how is it messy? > > > >> okay, call it a task, work for both process and threads, the hope is > >> to facilitate "switch from threads to process, and vice versa", but > >> we're getting the worst part of each it seems. > >> > >> ie: most thread usage is about sending shared memory back and forth, > >> after all the benefit of threads is just that: shared memory. What we > >> got? argv + int, useless for real life threads. > > > > i did this because not only does this work between processes it can work for > > js and lua. lua can't share objects between threads. the best youcan do is a > > luastate per thread and that pretty much means treating threads as another > > process. the model of at the base terating threads like processes is more > > widely applicable than "pass share objects" because several > > languages/runtimes just can't do it at all. > > ok, for these cases, like for JS/WebWorkers the solution is to start a > new thread passing the "script to run in that thread", in the case of > JS/WebWorkers, there are message passing. > > That said, to fully implement something like that you better use a > pointer (ie: string + mutex + queue), not a serialized value. Not a > stdio-like as it was done. stdio is a binary stream. it can be used for strings raw, or for sending ptrs to data... it's a base transport layer. nothing more. protocols can be implemented on top. > >> solution? "stdio" for threads... you can send/receive I/O, done with > >> pipes, like it would be for processes. > > > > it's the same thing ecore_thread does but only one way (from thread to main > > loop) and only in a limited (only main loop can spawn threads". > > > > so this is a far more expanded model with data going the other way too. > > > >> I really, really don't like that design. To me threads should be > >> exposed as such, with pointer argument and result... if you wish to > >> make i
Re: [E-devel] Ecore - Efl.Loop + Task + Thread + App + Appthread + Exe
On Tue, Mar 6, 2018 at 5:40 AM, Carsten Haitzler wrote: > On Mon, 5 Mar 2018 11:00:27 -0300 Gustavo Sverzut Barbieri > > said: > >> On Sat, Mar 3, 2018 at 2:02 AM, Carsten Haitzler >> wrote: >> > I just pushed: >> > >> > eb0b826776b60e0d97218242a5c285d146fb6f3b >> > >> > https://git.enlightenment.org/core/efl.git/commit/?id=1bdd9e4dd15fc27da43b50fd29bfb1b0b30ef6bd >> > >> > I wrote up a high level design document and description here for an idea of >> > how it works: >> > >> > https://phab.enlightenment.org/w/efl-loops-threads/ >> > >> > I'm busy filling that document out a bit, but the core essentials are >> > there. >> > >> > There are some details like loop having an exit eina value vs task having a >> > simple int exit code (i'm sticking to this because it is what processes do, >> > it's simple and its universally supported between processes, unlike an eina >> > value). yes - it simplifies threads to only having int exit codes, but the >> > simplicity of the design is what I'm going for. threads like executeables >> > have full bytestream I/O for more complex data interchange. So there >> > probably needs to be a bit of adjusting here and there to remove >> > duplication. The Arguments event delivers arguments in an array, but the >> > task object also stores arguments too permanently. Do we need to double-up >> > the information? So a few small things like this. >> > >> > I've given this design a lot of thought and what I have here I think is >> > clean and neat, tidy and fairly simple. It actually does work. I have >> > tested it of course. But please have a look and let me know what you think. >> > Are there some major defects in the design and idea? I know we can expand >> > this in future with more controls (I have no pause/resume controls in the >> > task interface but there should be. For processes use SIGSTOP/CONT and for >> > threads a co-operative request on the control line). The internals could be >> > better. I use pipes and this eats up a lot of FD's for the threads where I >> > could use socketpairs instead. I have a separate control pipe in/out from >> > I/O in/out where i could multiplex on the same socketpair. Currently we run >> > out of FD's (after about 240 threads running at once because they eat up 8 >> > FD's per thread. The Efl.Io code across the classes is a lot of copy & >> > paste... And I don't have anything to change priority of a thread once it >> > has run (no eina API for this - needs to be added). >> > >> > I'm not that happy though with Efl.Io and the sheer amount of code needed >> > to >> > deal with it. Even as a user of the API. >> > >> > Anyway - comments, thoughts, etc. etc. ? >> >> Well, I already mentioned this to you in irc, but replying here just >> to make my point: >> >> I think the design is upside down, trying to make life easier at some >> point resulted in messy at the other side. > > how? where? how is it messy? > >> okay, call it a task, work for both process and threads, the hope is >> to facilitate "switch from threads to process, and vice versa", but >> we're getting the worst part of each it seems. >> >> ie: most thread usage is about sending shared memory back and forth, >> after all the benefit of threads is just that: shared memory. What we >> got? argv + int, useless for real life threads. > > i did this because not only does this work between processes it can work for > js and lua. lua can't share objects between threads. the best youcan do is a > luastate per thread and that pretty much means treating threads as another > process. the model of at the base terating threads like processes is more > widely applicable than "pass share objects" because several languages/runtimes > just can't do it at all. ok, for these cases, like for JS/WebWorkers the solution is to start a new thread passing the "script to run in that thread", in the case of JS/WebWorkers, there are message passing. That said, to fully implement something like that you better use a pointer (ie: string + mutex + queue), not a serialized value. Not a stdio-like as it was done. >> solution? "stdio" for threads... you can send/receive I/O, done with >> pipes, like it would be for processes. > > it's the same thing ecore_thread does but only one way (from thread to main > loop) and only in a limited (only main loop can spawn threads". > > so this is a far more expanded model with data going the other way too. > >> I really, really don't like that design. To me threads should be >> exposed as such, with pointer argument and result... if you wish to >> make it easier, you could "box" it someway, like eina_value... or just > > i did the above because it's going to universally work with things like lua > etc.. there needs to be some kind of hook to create a new luastate in the > thread before executing, but then it'd work as-is. no, see above... you need *MORE*, unless you opt to serialize stuff as argv -- which is bad -- or block the thread reading from "stdin" to receive s
Re: [E-devel] Ecore - Efl.Loop + Task + Thread + App + Appthread + Exe
On Mon, 5 Mar 2018 11:00:27 -0300 Gustavo Sverzut Barbieri said: > On Sat, Mar 3, 2018 at 2:02 AM, Carsten Haitzler wrote: > > I just pushed: > > > > eb0b826776b60e0d97218242a5c285d146fb6f3b > > > > https://git.enlightenment.org/core/efl.git/commit/?id=1bdd9e4dd15fc27da43b50fd29bfb1b0b30ef6bd > > > > I wrote up a high level design document and description here for an idea of > > how it works: > > > > https://phab.enlightenment.org/w/efl-loops-threads/ > > > > I'm busy filling that document out a bit, but the core essentials are there. > > > > There are some details like loop having an exit eina value vs task having a > > simple int exit code (i'm sticking to this because it is what processes do, > > it's simple and its universally supported between processes, unlike an eina > > value). yes - it simplifies threads to only having int exit codes, but the > > simplicity of the design is what I'm going for. threads like executeables > > have full bytestream I/O for more complex data interchange. So there > > probably needs to be a bit of adjusting here and there to remove > > duplication. The Arguments event delivers arguments in an array, but the > > task object also stores arguments too permanently. Do we need to double-up > > the information? So a few small things like this. > > > > I've given this design a lot of thought and what I have here I think is > > clean and neat, tidy and fairly simple. It actually does work. I have > > tested it of course. But please have a look and let me know what you think. > > Are there some major defects in the design and idea? I know we can expand > > this in future with more controls (I have no pause/resume controls in the > > task interface but there should be. For processes use SIGSTOP/CONT and for > > threads a co-operative request on the control line). The internals could be > > better. I use pipes and this eats up a lot of FD's for the threads where I > > could use socketpairs instead. I have a separate control pipe in/out from > > I/O in/out where i could multiplex on the same socketpair. Currently we run > > out of FD's (after about 240 threads running at once because they eat up 8 > > FD's per thread. The Efl.Io code across the classes is a lot of copy & > > paste... And I don't have anything to change priority of a thread once it > > has run (no eina API for this - needs to be added). > > > > I'm not that happy though with Efl.Io and the sheer amount of code needed to > > deal with it. Even as a user of the API. > > > > Anyway - comments, thoughts, etc. etc. ? > > Well, I already mentioned this to you in irc, but replying here just > to make my point: > > I think the design is upside down, trying to make life easier at some > point resulted in messy at the other side. how? where? how is it messy? > okay, call it a task, work for both process and threads, the hope is > to facilitate "switch from threads to process, and vice versa", but > we're getting the worst part of each it seems. > > ie: most thread usage is about sending shared memory back and forth, > after all the benefit of threads is just that: shared memory. What we > got? argv + int, useless for real life threads. i did this because not only does this work between processes it can work for js and lua. lua can't share objects between threads. the best youcan do is a luastate per thread and that pretty much means treating threads as another process. the model of at the base terating threads like processes is more widely applicable than "pass share objects" because several languages/runtimes just can't do it at all. > solution? "stdio" for threads... you can send/receive I/O, done with > pipes, like it would be for processes. it's the same thing ecore_thread does but only one way (from thread to main loop) and only in a limited (only main loop can spawn threads". so this is a far more expanded model with data going the other way too. > I really, really don't like that design. To me threads should be > exposed as such, with pointer argument and result... if you wish to > make it easier, you could "box" it someway, like eina_value... or just i did the above because it's going to universally work with things like lua etc.. there needs to be some kind of hook to create a new luastate in the thread before executing, but then it'd work as-is. > let the traditional "void *pointer". But that's fundamental, say for > Python bindings to use threads, you want to send PyObject pointer to > the thread, that object will contain the information to callback the > user (the user's Python-callable). And for most usages as well, like > sending file info to be opened/decoded, etc. i can easily add a "set a void ptr on the thread" and make it gettable from the appthread. it wont work with lua though. it can't work with exe's. it's kind of not that useful for python etc. because it's just a void ptr. > thread I/O, while useful in some cases, I don't see why they should > always exist. They should be optional, and
Re: [E-devel] Ecore - Efl.Loop + Task + Thread + App + Appthread + Exe
On March 5, 2018 6:00 AM, Gustavo Sverzut Barbieri wrote:
> Well, I already mentioned this to you in irc, but replying here just
> to make my point:
>
> I think the design is upside down, trying to make life easier at some
> point resulted in messy at the other side.
>
> okay, call it a task, work for both process and threads, the hope is
> to facilitate "switch from threads to process, and vice versa", but
> we're getting the worst part of each it seems.
>
> ie: most thread usage is about sending shared memory back and forth,
> after all the benefit of threads is just that: shared memory. What we
> got? argv + int, useless for real life threads.
>
> solution? "stdio" for threads... you can send/receive I/O, done with
> pipes, like it would be for processes.
>
> I really, really don't like that design. To me threads should be
> exposed as such, with pointer argument and result... if you wish to
> make it easier, you could "box" it someway, like eina_value... or just
> let the traditional "void *pointer". But that's fundamental, say for
> Python bindings to use threads, you want to send PyObject pointer to
> the thread, that object will contain the information to callback the
> user (the user's Python-callable). And for most usages as well, like
> sending file info to be opened/decoded, etc.
I do second you completely Gustavo. I have been raising my discontent with this
design for a long time now and fully agree with your point here.
> thread I/O, while useful in some cases, I don't see why they should
> always exist. They should be optional, and as such they should be
> created explicitly.
Agreed.
> Last but not least, I'd expose the stack just like in the OS, to not
> make confusion:
>
> - Application ("the binary") -> Processes -> Threads -> main loop
>
> you can present "getters" that make it easier to access (ie: main loop
> "get" application, in addition to "get parent" which would return the
> thread).
>
> But mixing stuff "in the hope to make it easier" it not, it's just
> making things more complicated... ALSO note that the developer that
> would use this kind of API is "not the average developer", these don't
> mess with such low level primitives. The developer that is likely to
> use these primitives will say "what the fuck is this? I'm used to
> processes and threads, these guys just messed it up".
>
> I'm in favor of interfaces for things that are the same, so if the
> methods in process and threads share the same concept, behavior and
> parameters, make them an interface... when switching from process x
> threads one doesn't need to "sed" everything. However, definitely
> constructors are NOT the same concept, behavior or parameters, thus
> not part of the interface.
I would add that this thread model doesn't satisfy any of the use case we
ourself have. For example :
- Ector: use thread to offload CPU and memory heavy task to another thread. The
simple change to BFL has slowed us down. Now, if we do have to
serialize/unserialize everything ? I have already my bet on the result.
- Evas async renderer: same case as Ector. Nobody might remember, but at the
beginning it was really slower, because of the memory copy that was done and it
had to be removed. If we were to use this new infrastructure, it would lead to
be back to a slower solution.
- Eio: we offload the io and the content generation from another thread. Even
unecessary function call do significantly slow us down while listing a
directory. That is why we are grouping things in array to avoid this function
call. I do not expect things to get better with the above proposal.
- Efl_Net: the design of the interfaces allow for moving an object to another
loop, but because we can't transfert a socket to another loop, we can't use
that. It means that we can not do any load balancing from the main loop. We can
use Efl.Io to redirect traffic to another thread, but it will always require a
wake up and work in the main loop.
If it doesn't solve our own problem, I am not convinced it will be solving
anyone problem.
Cedric
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore - Efl.Loop + Task + Thread + App + Appthread + Exe
On Sat, Mar 3, 2018 at 2:02 AM, Carsten Haitzler wrote:
> I just pushed:
>
> eb0b826776b60e0d97218242a5c285d146fb6f3b
>
> https://git.enlightenment.org/core/efl.git/commit/?id=1bdd9e4dd15fc27da43b50fd29bfb1b0b30ef6bd
>
> I wrote up a high level design document and description here for an idea of
> how
> it works:
>
> https://phab.enlightenment.org/w/efl-loops-threads/
>
> I'm busy filling that document out a bit, but the core essentials are there.
>
> There are some details like loop having an exit eina value vs task having a
> simple int exit code (i'm sticking to this because it is what processes do,
> it's simple and its universally supported between processes, unlike an eina
> value). yes - it simplifies threads to only having int exit codes, but the
> simplicity of the design is what I'm going for. threads like executeables have
> full bytestream I/O for more complex data interchange. So there probably needs
> to be a bit of adjusting here and there to remove duplication. The Arguments
> event delivers arguments in an array, but the task object also stores
> arguments
> too permanently. Do we need to double-up the information? So a few small
> things
> like this.
>
> I've given this design a lot of thought and what I have here I think is clean
> and neat, tidy and fairly simple. It actually does work. I have tested it of
> course. But please have a look and let me know what you think. Are there some
> major defects in the design and idea? I know we can expand this in future with
> more controls (I have no pause/resume controls in the task interface but there
> should be. For processes use SIGSTOP/CONT and for threads a co-operative
> request on the control line). The internals could be better. I use pipes and
> this eats up a lot of FD's for the threads where I could use socketpairs
> instead. I have a separate control pipe in/out from I/O in/out where i could
> multiplex on the same socketpair. Currently we run out of FD's (after
> about 240 threads running at once because they eat up 8 FD's per thread. The
> Efl.Io code across the classes is a lot of copy & paste... And I don't have
> anything to change priority of a thread once it has run (no eina API for this
> -
> needs to be added).
>
> I'm not that happy though with Efl.Io and the sheer amount of code needed to
> deal with it. Even as a user of the API.
>
> Anyway - comments, thoughts, etc. etc. ?
Well, I already mentioned this to you in irc, but replying here just
to make my point:
I think the design is upside down, trying to make life easier at some
point resulted in messy at the other side.
okay, call it a task, work for both process and threads, the hope is
to facilitate "switch from threads to process, and vice versa", but
we're getting the worst part of each it seems.
ie: most thread usage is about sending shared memory back and forth,
after all the benefit of threads is just that: shared memory. What we
got? argv + int, useless for real life threads.
solution? "stdio" for threads... you can send/receive I/O, done with
pipes, like it would be for processes.
I really, really don't like that design. To me threads should be
exposed as such, with pointer argument and result... if you wish to
make it easier, you could "box" it someway, like eina_value... or just
let the traditional "void *pointer". But that's fundamental, say for
Python bindings to use threads, you want to send PyObject pointer to
the thread, that object will contain the information to callback the
user (the user's Python-callable). And for most usages as well, like
sending file info to be opened/decoded, etc.
thread I/O, while useful in some cases, I don't see why they should
always exist. They should be optional, and as such they should be
created explicitly.
Last but not least, I'd expose the stack just like in the OS, to not
make confusion:
- Application ("the binary") -> Processes -> Threads -> main loop
you can present "getters" that make it easier to access (ie: main loop
"get" application, in addition to "get parent" which would return the
thread).
But mixing stuff "in the hope to make it easier" it not, it's just
making things more complicated... ALSO note that the developer that
would use this kind of API is "not the average developer", these don't
mess with such low level primitives. The developer that is likely to
use these primitives will say "what the fuck is this? I'm used to
processes and threads, these guys just messed it up".
I'm in favor of interfaces for things that are the same, so if the
methods in process and threads share the same concept, behavior and
parameters, make them an interface... when switching from process x
threads one doesn't need to "sed" everything. However, definitely
constructors are NOT the same concept, behavior or parameters, thus
not part of the interface.
--
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890
-
