2018-01-13 7:37 GMT+01:00 Carsten Haitzler <ras...@rasterman.com>: > On Fri, 12 Jan 2018 19:48:15 +0000 Mike Blumenkrantz > <michael.blumenkra...@gmail.com> said: > > > First, thanks for taking the time to provide numbers and details to > support > > your feedback. I realize that it may seem like a burden to you, but it's > > hard for us developers to engage in a debate against vague handwaving in > > the absence of any real data. I've replied to your points inlined for > > better readability, and I hope that this will address most of the > feedback > > that you've given towards the current direction of development. > > > > On Fri, Jan 12, 2018 at 9:45 AM Carsten Haitzler <ras...@rasterman.com> > > wrote: > > > > > On Fri, 12 Jan 2018 13:48:46 +0000 Stephen Houston < > smhousto...@gmail.com> > > > said: > > > > > > > Nobody said anything about GL. > > > > > > you want gadgets to be separate external processes (one per gadget) > and i > > > covered that. > > > > > > *IF* you want gl the cost goes up even more. if you don't use gl then > you > > > have a > > > problem of having to render on cpu and transfer that data to gpu > accessible > > > memory (or make the gpu have to read slower memory when doing > rendering as > > > a > > > source buffer). it's generally far better to keep it all in gpu video > > > memory > > > rather than do this, if it's possible to do. thus it'd probably be > good to > > > have > > > gadgets render with the gpu. > > > > > > but i covered both cases. all the numbers below do split gl vs non-gl. > the > > > end > > > is the same. still a LARGE amount of overhead for a process. > > > > > > > Both of these cases are solved by rendering the buffers (both gl and > > software) directly in the outer compositor; see > > https://phab.enlightenment.org/T6592 on the gadgets workboard for this > task > > which is already nearing completion. > > that doesn't change anything. some work somewhere has to either copy the > data > to video memory every change OR the the gpu will likely have to composite > and > thus access data over a bus (eg over pci bus). if it's an embedded system > all > memory is equal, but subsurface are going to unlikely help because you'll > not > have enough hw layers to assign to a host of gadgets. there will generally > maybe be 2-5 ... maybe on a good day 8 or 10 layers, and these are far > better > used for application windows (e.g. separating desktop, active/focused > window or > window being moved/dragged, etc. etc.). it's still a gadget rendering to a > buffer THEN that buffer having to be copied again ... always. at all times. > > > > > On Fri, Jan 12, 2018, 6:02 AM Carsten Haitzler <ras...@rasterman.com > > > > > wrote: > > > > > > > > > On Thu, 11 Jan 2018 17:13:22 +0000 Mike Blumenkrantz > > > > > <michael.blumenkra...@gmail.com> said: > > > > > > > > > > > Thanks for your valuable input! We'll take it into > consideration. If > > > you > > > > > > have feedback for the developer team in the future, please be > sure to > > > > > > include technical data to support your comments so that we can > > > evaluate > > > > > it > > > > > > fairly. > > > > > > > > > > why is it that when i read the above it's just dripping in > sarcasm. i > > > > > smell it > > > > > dripping between every line. the snideness just oozes from it. > > > > > > > > > > now i wasted a good 30 mins redoing numbers below that i already > pretty > > > > > much > > > > > summarized with "don't use lots of processes" as i've spent years > > > looking > > > > > at > > > > > this data, but obviously my history, experience etc. mean little to > > > you. > > > > > this is > > > > > stuff you should have done before choosing this path. you obviously > > > didn't > > > > > given > > > > > "please provide technical data" above that you seemingly don't > have. > > > > > > > > > > if you have a gadget as a window then that window must have a > buffer > > > and > > > > > that > > > > > buffer consumes memory where otherwise no buffer would exist. did > that > > > even > > > > > need to be justified? just do the math. a 40x40@32bpp gadget will > > > consume > > > > > at least ~6k of ram and if gl rendering is involved that'd be 12 or > > > 18k or > > > > > so. > > > > > maybe more. that's a start. > > > > > > > See above comments regarding proxy rendering which would avoid > duplication > > of buffers. > > i was not talking about duplication of buffers. the buffer is used > directly. > what i'm saying is that there is an enforced 100% of the time intermediate > buffer to contain all of the gadget. this is in addition to the source > image > data (as malloced memory or as textures) e.g. an image of a battery that is > then drawn to a backbuffer/shm buffer/whatever... this backbuffer is the > extra > buffer. you'll be swapping around 2 or 3 of these all the time. that's the > extra required buffer. > > > > > > > > > > > now let me add up the dirty pages just from loaded .so files (dirty > > > pages > > > > > are > > > > > private per-process pages) for just a single efl process like > > > > > enlightenment_askpass that has the same linking as a gadget: that's > > > about > > > > > 1800kb of dirty pages PER PROCESS that is overhead. (1872kb to be > > > exact). > > > > > pmap > > > > > -x. use it. it's a rough tool but does the job for this topic. > > > > Quicklaunch solves this; https://phab.enlightenment.org/T6395 on the > > gadgets workboard. To address your criticism of quicklaunch in your other > > reply, it's a functional technology which can be leveraged for this > > purpose. Whether it is a "royal pain" for you personally is not > technically > > relevant since you are not actively contributing to the gadget project. > > quicklaunch has lots of issues with fd's as it has to keep some but not > others. > quicklaunch has broken things and then in order to fix it it has steadily > been > made less and less efficient sharing less and less with the parent process > (i.e. less being allocated/created before). it totally doesn't work with > eina > debug or threads too. any threads created prior to fork are lost and have > to > be rec-created. this leads to more and more code handling this corner case > that > is fragile. > > > > > > now if you want accelerated rendering with gl... that'd need a gl > > > context > > > > > and > > > > > gl dependencies loaded. dirty pages loaded from .so's goes up to > > > 4764kb ... > > > > > > > > > > now heap memory usage when using gl goes up too. gl contexts and > so on > > > > > (heap > > > > > meaning via malloc etc.) and this goes up from 4.9m to 8.8m just to > > > have > > > > > acceleration. this will multiple by the number of processes. > > > > > > > While I agree that you have a great point regarding GL memory usage here, > > there's no purpose in using hardware acceleration for the vast majority > of > > gadgets. The render size is very small and the content seldom changes, so > > software rendering would be a clear win over using hardware. > > i actually disagree here. given growing dpi's and larger gadgets like ibar > style things have far more pixels to render... even worse, ibar isn't > doable as > an external process gadget because it relies on getting client window > objects to > display in the popup. these are only doable in x11 if you implement a mini > compositor/redirector of your own to get the pixmaps and so on, and in > wayland > are totally inaccessible, so portability-wise this fails here. pager is > another > example. but ok. let's say that you have a choice. internal module for > these > things and external process for others, the larger the gadget the more > likely > you want to use hardware rendering. this also applies to saving memory. if > 5 > gadgets all have an "arrow up" icon that comes fro the same theme, they > will > all load and decode their own private copy of it in memory, then if e is > using > that too it will have it in a texture too. > > > > > > now there is also the overhead that every process loading an edj > file > > > has > > > > > to > > > > > have its own malloced data structures for that edj file. if you > look at > > > > > detailed massif data you'll find that edje + efreet + fontconfig > > > > > + openssl will malloc privately per process just to load the theme, > > > shared > > > > > efreet cache files and cached fontconfig data etc. a total of about > > > 1639kb. > > > > > > > > > > let me do the math for you: > > > > > > > > > > 1639 + 1872 (if software) = 3511kb per process overhead just for > what i > > > > > mentioned. it's more with each process's own stack and other things > > > also > > > > > loaded. but let's call it 3.5m. > > > > > > > > > > now if we want gl acceleration that goes up by ANOTHER 3.9 + 2.8m = > > > 6.7m. > > > > > so > > > > > 10m per process overhead if you want to use acceleration to render > and > > > not > > > > > the > > > > > cpu. at least as a new stand-alone process. > > > > > > > > > > for a more coarse measurement, just do the simple one: run free; > run > > > > > enlightenment_askpass, then free again (with system otherwise > stable): > > > > > > > > > > without gl mem usage goes up by 10848k. with gl it goes up by > 21772k. > > > this > > > > > is > > > > > nvidia drivers btw here. > > > > > > > > > > there's also all the added overhead now of having to launch all the > > > > > processes > > > > > that are gadgets and process launching is not cheap. it's slow and > > > costly - > > > > > especially all the post-process work like loading edj files, > > > decompressing > > > > > the > > > > > same data multiple times etc. etc. ... > > > > This is interesting, thanks for sharing the numbers here on memory usage > of > > edje files. These files can be cached in the compositor process and > shared > > using quicklaunch to avoid opening them multiple times, and this should > > mitigate any increased memory usage across multiple instances of gadgets. > > actually loading edje files require evas. evas creates threads. threads > don't > survive over forks. thus loading edje files in a parent then forking and > expecting it all to work ... is not going to. how many more threads to you > have > to fix up to be able to "restart after being terminated with no notice"? > the > fork may terminate them and any thread handles or variables indicating a > thread > is alive (the thread handle for example and it was never joined) will be > incorrect. shutting down all possible threads first before a fork, then > starting them all up again is an unsustainable amount of work. > > > > > > > > > > > are you telling me you didn't do any design evaluation or numbers > > > before > > > > > deciding on a path and you need me to do this for you? i have done > > > these > > > > > kinds > > > > > of numbers again and again over the years and they consistently > show > > > the > > > > > same > > > > > thing: > > > > > > > > > > 1. every process costs. especially if it's complex with lots of > > > libraries > > > > > and > > > > > data sets. it's 100's of kb just for the simplest basic libc using > > > process > > > > > stretching into multiple mb for those using larger toolkits. and > that's > > > > > just for > > > > > common shared data that isn't specific to that process. > > > > > 2. opengl adds a mountain of overhead on top per process. > > > > > > > > > > most of these are very hard to get rid of and designing something > that > > > > > actively > > > > > works against "the way things are" is a very poor way of doing > things. > > > > > especially to everything enlightenment is about, like being > efficient. > > > > I've been charitable and allowed for the highest level of technical > > competency when evaluating your proposals from this thread to others who > > have privately come to me with questions about them. I've similarly been > > very civil with my initial reply, even if you chose not to read it as > such. > > I would appreciate it if, when you come to provide your feedback, you > could > > extend the same courtesies to the developers who have already spent > > considerable time and resources implementing this. > > your mails do not read as being civil. they read as being hugely sarcastic > and > precisely the opposite. > > cedric thinks quicklaunch is a viable solution. i actually wrote it. i have > come around to the position that it is not for many technical reasons. > complexity with sharing fd's (or not), problems in sharing memory (shm > segments don't get COW'd but a fork kills assumptions on them - e.g. that > your mapping of that segment is seen by only you and not also a copy of > you). > it has major problems with threads which we are increasingly using more and > more of, etc. etc. ... if we have to write efl with the assumption that > "at any > point someone might fork AND continue to execute without immediately > exec()ing > away", any locks held that a thread would have unlocked will remain > deadlocked now forever as an example. we're going to have an endless chain > of > fork bugs here. that means every thread, every fd, every mem segment and > any > libs we rely on that also use these might be a problem. be it libpulse and > any > fd's it has (like sockets connected to pulse server), x11 connection > sockets > (this is a major pain) wayland client socket connections, and then perhaps > pipes or other things libs like gstreamer might have internally, not to > mention > any currently running threads that can't sensibly survive a fork... having > to > clean them all up, a quicklaunch system just is not sane. it's beating a > dead > horse. and this comes from the guy who wrote it and thought it a good idea > at > the time. > > i'd also have appreciated at least a high level heads up "we're going this > way" > discussion from you or anyone involved beforehand. when you do something > quietly in a back room, then decide to launch it as "the new way to do x" > then > you need to expect someone is going to probably disagree with it. and i > do. i > have my reasons. and i know quicklaunch is going to end in a bucket of > tears. i > have shed those tears myself and have now gotten over it. i've spent enough > time fixing it and finally reducing it to do as little as possible in the > parent to avoid issues. it is currently broken and it'll remain so pretty > much > forever. > > > > > > > On Thu, Jan 11, 2018 at 3:41 AM Carsten Haitzler < > > > ras...@rasterman.com> > > > > > > wrote: > > > > > > > > > > > > > On Wed, 10 Jan 2018 20:38:27 +0000 Stephen Houston < > > > > > smhousto...@gmail.com> > > > > > > > said: > > > > > > > > > > > > > > i'm going to put my take on this: i think this is bad. it > flies in > > > the > > > > > > > face of > > > > > > > everything e was built to do. to be efficient. having a > process per > > > > > gadget > > > > > > > is > > > > > > > horribly inefficient. this is precisely what helps bloat out > gnome > > > and > > > > > kde > > > > > > > memory footprints and what has kept e lean. > > > > > > > > > > > > > > while avoiding e crashing due to a bad gadget is a good thing, > the > > > > > > > following is > > > > > > > just a bad way to do it. > > > > > > > > > > > > > > 2 other alternatives: > > > > > > > > > > > > > > 1. have a SINGLE "gadget process" to hold all gadgets and load > > > modules > > > > > into > > > > > > > this process, so we don't have 20 processes, but instead have > just > > > e + > > > > > > > gadget > > > > > > > process. > > > > > > > > > > > This is an interesting proposal, and there's nothing in the current > > infrastructure model which would prevent implementing a monolithic gadget > > process. Whether doing so is a good idea is outside the scope of this > > thread--originally created to inform about documentation of the existing > > sandbox gadget infrastructure. > > well it's a discussion to have. i proposed better solutions because if > things > go the way of "we now have 10 or 20 gadget processes" and all the costs > that > come with it (as i said - quicklaunch i dont think will cut it), then this > would be a far better compromise IMHO. you get stability of the core wm > and if > an issue happens, at worst a dozen or whatever gadgets flicker off/on and > reset > (as opposed to a single one). the main wm will keep marching on and user > will > be largely unaffected. the current design i see(as i read it) with an > environment variable seems directly designed for a single gadget per > process. > > > > > > > > 2. remote ui. gadgets could be written in any language that > can do > > > > > stdio. > > > > > > > they > > > > > > > echo/printf commands to e to create objects and change their > state, > > > > > and e > > > > > > > "echos" back on stdin events and things the gadget should know. > > > your > > > > > gadget > > > > > > > could be a stripped down super-lean basic libc executable. > python. > > > > > shell > > > > > > > script. anything that can do stdio. while this still has 1 > process > > > per > > > > > > > gadget - > > > > > > > it's for the back-end only and this should make then far leaner > > > than > > > > > with a > > > > > > > full ui. > > > > > > > > > > > > > > > i actually wanted to spend time on #2 but am busy with efl > atrm. #2 > > > > > would > > > > > > > be > > > > > > > great because it'd massively lower the work needed to quickly > make > > > a > > > > > > > gadget of > > > > > > > your own. write it in python or shell quickly and dirtily and > life > > > > > would be > > > > > > > easy. > > > > > > > There's also nothing in the current infrastructure model which would > > prevent this, and there is similarly nothing preventing you from adding > > extensions to gadget sandboxing to provide these facilities if you so > > decided. Such a proposal is, however, also outside the scope of this > thread > > and the existing sandbox gadget infrastructure. > > well where was the original design discussion for this? i never remember > seeing > it. > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > I would like to point everyone to a new wiki page we have > that > > > > > details > > > > > > > > developing gadgets for Enlightenment using the sandbox > method. > > > > > > > > > > > > > > > > https://www.enlightenment.org/develop/e/sandbox_gadgets > > > > > > > > > > > > > > > > Feel free to use the guide to create cool new gadgets for E > and > > > make > > > > > sure > > > > > > > > you contribute back feedback about the guide so we can > improve > > > it as > > > > > > > needed. > > > > > > > > > > > > > > > > Thanks! > > > > > > > > Stephen (okra) > > > > > > > > > > > > > > > > > > > > > > > To address further comments that you've made in other replies: > > > > > and in what cases does this actually matter? if you want to sandbox > every > > > module/gadget then i think that is going far too far. my take is that a > > > module/gadget is a trusted tool that is integrated with your desktop. > > thus the > > > above doesn't count. and if you really do want to isolate then using > > something > > > like elua and a private lua state per gadget would work best as then it > > doesn't > > > mean we have to duplicate the entire process N times, only a fairly > > minimal lua > > > state (in comparison to the rest behind it). > > > > I can appreciate how much you value the longstanding Enlightenment > > development model of using modules, but requiring that every gadget be a > > module significantly raises the barrier to entry for both new developers > > and existing developers who want to contribute new gadgets. External > > modules effectively require users to accept an EULA in order to > > activate--sandboxed gadgets do not. There is still nothing preventing > > anyone from using modules to develop gadgets in the way that you've > > suggested. > > i never said "keep things as they are". the linux kernel also complains > about > being tainted with modules too. same idea. we ask users to once-off > approve a > "tainted module". that's not exactly problematic. but i did NOT say keep > things > as they are which is what you imply. something like elua and lua modules > would > easily be something that i don't think would warrant that (for example). > > > > will be incredibly rare to want to do this (sandbox your gadgets). as i > > > mentioned above. for cases where security is an issue they should > probably > > > split into a very simple back-end that is very locked down and a > > front-end to > > > talk to it and authenticate etc. the back-end maybe at most would > reauest > > an > > > auth itself (e.g. may execute enlightenment_askpass or have a ui of its > > own > > > though this makes it more complex, or have a passwd asking tool of its > > own it > > > directly runs etc. etc.). > > > > Certainly this is a viewpoint that some people may have, but I think it's > > important to look at the sandboxing infrastructure from another > > perspective: the purpose of this, beyond providing increased security and > > stability, is to make it significantly easier for people to contribute to > > the Enlightenment desktop. Writing a module and using a specific gadget > API > > is more difficult than writing a simple EFL-based application. Forcing > > developers to only use C, or requiring that there be language-specific > > infrastructure/bindings for the Enlightenment APIs is similarly more > > difficult than letting developers use whatever language they want. > > what i proposes with stdin/out actually would allow far more languages to > be > used than what you are doing with this process-per-gadget system. far, far > far > more. also development would be simpler as there is no library or toolkit > to > link to or import or sdk etc. beyond echo/printf/read/scanf. either way > it's > theoretical as it doesn't exist. > > but "one process per gadget" is going to end up with a huge bloat (see > about > quciklaunch - even without quicklaunch you drop any sharing of resources > for > widgets/images/whatever loaded later). a "gadget holder" process might be a > decent compromise, but then gadgets are modules again. the e module > interface > was not designed FOR gadgets. it was designed to be super generic for > anything. > thus it's a lot of work to do a gadget on top. gadget specific modules with > specific api's for just that could be simpler. a gadget holder per language > (one for c/c++ and lua via elua, one for python, etc.) that "sourced" its > gadgets as bits of script and kept them merged would ultimately work out > as a > compromise that might work. at least cost is only per language and not per > gadget. >
I totally agree with Raster here, a single process for each gadget will be a MAJOR performance issue. I'm thinking (of course) at gadgets written in python. For what I know quick-launch will works (if it will work at all) only for gadgets written in C, right? If I'm not wrong (and sorry if I am) then all the gadgets not written in C will not get any of the optimizations that quick-launch can provide. A really simple python-efl app/gadget comes at the cost of a full python interpreter spawned, 4 evas threads and some subprocess spawned (efl_net_proxy_helper, efreetd, etc). If you multiply this by 10/20 gadgets... well, you know simple math... :) The correct solution, as raster said and as I have already implemented years ago (see edgar) is a single E module for each language that load scripts and execute them in a single interpreter instance. So a single interpreter for all python gadgets. Edgar gadgets, as they are written specifically for python, are also a lot simpler to write as edgar can manage lots of gadgets complexity for you and make the gadget code as pythonic as possible. For example this is the full code for a gadget that just load an edje file (the simplest edgar gadget): https://git.enlightenment.org/enlightenment/modules/edgar.git/tree/GADGETS/ruler/__init__.py (please note that I already rised this 2 times in IRC, but my perplexity has been totally ignored, or at least that was my impression) > > > ------------------------------------------------------------ > ------------------ > > 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 > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > Carsten Haitzler - ras...@rasterman.com > > > ------------------------------------------------------------ > ------------------ > 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 > ------------------------------------------------------------------------------ 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
