On Sun, Apr 23, 2017 at 11:40 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Fri, 14 Apr 2017 23:03:02 -0300 Gustavo Sverzut Barbieri > <barbi...@gmail.com> said: >> On Wed, Apr 12, 2017 at 9:14 PM, Carsten Haitzler <ras...@rasterman.com> >> wrote: >> > On Tue, 11 Apr 2017 09:41:06 -0700 Cedric BAIL <cedric.b...@free.fr> said: >> >> On Tue, Apr 11, 2017 at 2:52 AM, Carsten Haitzler <ras...@rasterman.com> >> >> wrote: >> >> > On Tue, 11 Apr 2017 18:58:58 +0930 Simon Lees <sfl...@suse.de> said: >> >> >> On 04/11/2017 04:19 PM, Carsten Haitzler (The Rasterman) wrote: >> >> >> > On Mon, 10 Apr 2017 12:01:49 -0300 Gustavo Sverzut Barbieri >> >> >> > <barbi...@gmail.com> said: >> >> >> >> On Mon, Apr 10, 2017 at 4:50 AM, Carsten Haitzler >> >> >> >> <ras...@rasterman.com> wrote: >> >> >> >>> On Sun, 9 Apr 2017 23:25:39 -0700 Cedric BAIL <cedric.b...@free.fr> >> >> >> >>> said: >> >> >> >>> >> >> >> >>>> On Sun, Apr 9, 2017 at 7:51 PM, Gustavo Sverzut Barbieri >> >> >> >>>> <barbi...@gmail.com> wrote: >> >> >> >>>>> On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees <sfl...@suse.de> >> >> >> >>>>> wrote: >> >> >> >>>>>> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote: >> >> >> >>>>>>> Which brings me to my last point: we should adopt and use for >> >> >> >>>>>>> REAL a >> >> >> >>> one possible option is to jump behind the transpiler bandwagon. >> >> >> >>> what >> >> >> >>> about writing a js -> lua transpiler? this should be not that hard >> >> >> >>> given the incredible similarity in the 2 languages. you can then >> >> >> >>> write in lua or in js. just you need a compile step for js. perhaps >> >> >> >>> we should also have a compile step for lua anyway? at least minify >> >> >> >>> it for faster parsing etc....? >> >> >> >> >> >> >> >> isn't jerryscript good enough? Seems pretty small, not sure if >> >> >> >> they're focusing on efficiency as much as ram/disk. >> >> >> > >> >> >> > jerryscript is interpreted only - no jit, so it's going to have a >> >> >> > fairly big performance hit vs something jitted. if the point is to >> >> >> > write more and more in such a language you want it to be as >> >> >> > performant as possible. it can be more performant with a jit... so >> >> >> > you'd want that. >> >> >> > >> >> >> >> >> >> I'll be controversial and say that for many Desktop UI applications and >> >> >> probably for a lot of smartphone ones as well performance really >> >> >> doesn't >> >> >> matter that much, its not like were running these things on a 386, So I >> >> >> guess sometimes less performant languages have other benefits which is >> >> >> why people use them. >> >> > >> >> > then why does android precompile java apps to native code on >> >> > installation >> >> > now as opposed to just keep interpreting? :) >> >> >> >> No clue of what this guys are doing, but I can tell you for sure, you >> >> will be fine writing EFL application in JS. For a reminder, EFL with a >> >> JS binding without any JIT run fine for doing 2D games on a MIPS at >> >> 200Mhz with no GPU. So speed is absolutely not necessary for the large >> >> majority of application with EFL as a toolkit (Not talking bob here). >> >> I think that if we are to choose a preferred binding, we should go >> >> with what bring most developers in. >> > >> > then why did google bother with v8? why did firefox do tracemonkey? if js >> > interpreted is fast enough? remember that js in a web page will be similar >> > to js + efl - the web engine is doing the heavy lifting for ui, rendering >> > and layout... >> >> there is a HUGE difference that you're ignoring: browsers shouldn't >> start to incorporate extensions that pages can rely, thus they MUST >> implement everything on their own... as I said in other emails, even >> nice JS utilities such as sane "foreach" aren't there and needs to be >> monkey patched, what to say about real useful frameworks that creates >> the navigation, widgets, etc? boostrap, react, angular, jquery cannot >> be implemented in other languages and exposed... so code starts to >> grow quite a lot. That's also true for game engines and the likes. >> >> In EFL we have much more extensive feature set and those are >> implemented in C, thus not that big problem. > > actually you can add new stuff. plugins. web browsers have had these for > years. > they are giving up now because people really didnt want to. if you have to > then > write something in c/c++ compile it and expose it you lose the point of using > js (or lua or whatever) as what you have is now not portable as-is but needs > recompilation. > > my point is that if you push js as the lang and then go "jerryscript will do" > you'll have app devs that have to do more and more in their app as their apps > get less trivial and it will become a burden and the whole "js in the web" > will > repeat history to get a faster js... which means v8. which means much bigger > basic scripting engine vs luajit.
Not really. There is an inherent cost with JIT over doing just AST or IR execution. You have to do a full compilation cycle (whatever technique you use), which is more costly than just executing a function call. Also JIT is broken and stopped everytime you do a C function call. So any callback to have great performance with JIT has to be a long running function with only a few C call at the end of it, otherwise it is slower than just walking the AST or an IR. This doesn't describe any code pattern we have in EFL application and why I say we focusing on JIT here is pretty moot for application. > we COULD give people js with a transpiler js -> lua - they write in js and it > gets compiled to lua for distribution. it should give the performance needed > with the "popularity". we could run the js natively or the developer and just > transpile when packaging the app up for distribution. I am pretty sure doing a js->lua transpiler is far from being an easy task that would lead to better performance than what you get with js engine. -- Cedric BAIL ------------------------------------------------------------------------------ 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
