On Tue, Apr 11, 2017 at 1:41 PM, Cedric BAIL <cedric.b...@free.fr> wrote: > 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.
this is true, as said Python in Maemo/Nokia770 did nice as well, no GL and no JIT whatsoever. Also, working with JS JIT in WebKit you can identify the thresholds to optimize loops are rather conservative: https://trac.webkit.org/wiki/JavaScriptCore JavaScriptCore consists of the following building blocks: lexer, parser, start-up interpreter (LLInt), baseline JIT, a low-latency optimizing JIT (DFG), and a high-throughput optimizing JIT (FTL). Baseline JIT kicks in for functions that are invoked at least 6 times, or take a loop at least 100 times (or some combination - like 3 invocations with 50 loop iterations total). DFG JIT kicks in for functions that are invoked at least 60 times, or that took a loop at least 1000 times FTL JIT kicks in for functions that are invoked thousands of times, or loop tens of thousands of times Since most applications only have business logic if the framework helps them to do the hard business, then you'd not suffer from performance hit. -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ 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
