On Wed, Apr 12, 2017 at 5: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...
Because web engine are different from what efl provide. In the hypothetical case we wrote all application with v8, I would bet you wouldn't even get JIT on for any code in E, terminology, express or rage. The reason is that our code is mostly some short runned callback. Do you see anywhere in our code a long running loop ? JIT only kick in if you have a hot path. Callbacks every now and then won't turn it on at all. > my point is ... it is NOT good enough. not in the general case. not when > performance directly relates to battery life. if you go "well today's cpu's > can > run that ok" sure.. but then your battery life lowers by 5%. 10%, 20%... ? See my point above. I am not even sure that a shoot'em up using EFL would actually trigger a JIT in an useful manner. > there is a solution that gets us both speed and simplicity - luajit. lua isn't > an unknown language. it would be possible to write a js -> lua transpiler and > thus get the best of all worlds using luajit as an execution engine. This is optimizing for the wrong thing in my opinion. We care here more about getting 10x more developers writing EFL application than winning some small amount of performance on less than 5% of the application that nobody is going to write in the first place. The goal is to make EFL easier to use for as many developers as possible. Performance is something the toolkit provide and that developers shouldn't have to worry about. If something is slow, improving EFL should be the answer. -- 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
