Will jxcore support JavaScriptCore automatically on iOS ?

jxcore / jxcore

Evented IO for ChakraCore, SpiderMonkey & V8 JavaScript

Other

2.38k stars 315 forks source link

Will jxcore support JavaScriptCore automatically on iOS ? #335

Open pandamicro opened 9 years ago

pandamicro commented 9 years ago

As JIT is only supported in JavaScriptCore for iOS, all other engine will suffer a big performance gap. So I think it will be great to support JSCore on iOS.

obastemur commented 9 years ago

@pandamicro We had discussed this issue on https://github.com/jxcore/jxcore/issues/186 . It's a bit long discussion but in summary;

JavaScriptCore license is not suitable
Limited ES6 features comparing to SM,
JXcore uses Baseline compiler, and ionMonkey on iOS without CODEGEN. I believe JavaScriptCore's JIT like approach is also similar to SM's NO-CODEGEN. So SpiderMonkey's performance is very impressive.

If you can find any time and give a shot to current jxcore-ios performance please let me know. I have a plan to run standard JS engine benchmarks on ios to see the difference better.

pandamicro commented 9 years ago

OK, thanks for the clarification, have you compared the performance between jxcore using spidermonkey and ios native JavaScriptCore with JIT ? I'm really interested by the result. I will also check it out when I'm available

robertjpayne commented 9 years ago

@pandamicro JavaScriptCore doesn't run with a JIT in most cases. There are only two instances where JSC uses the JIT:

For third party apps that utilise WKWebView since WKWebView is out of process it has security permissions to execute JIT'd code
For the Safari app

It would be great to see performance differences between JavaScriptCore and SpiderMonkey w/o JIT enabled on each.

pandamicro commented 9 years ago

OK, I see, so the real useful test case is to see the performance difference between Safari (JavaScriptCore with JIT) and SpiderMonkey with baseline and ionMonkey.

robertjpayne commented 9 years ago

@pandamicro I actually think it's more worthwhile to benchmark it against JavaScriptCore w/o JIT and SpiderMonkey w/o JIT since it's more likely users will be using it that way on iOS.

The only reason to use WKWebView is if you need a full browser stack or extremely high standalone JS performance that you're not going to bridge to native much.

pandamicro commented 9 years ago

Oh, I see your point, you are right. The real comparable use case is when user use JS VM for javascript execution in their own application with JavaScriptCore or SpiderMonkey.

In this case, JavaScriptCore don't have JIT neither.

So you are right, benchmark between JavaScriptCore w/o JIT and SpiderMonkey w/o JIT is more reasonable

obastemur commented 9 years ago

@robertjpayne @pandamicro Are you referring to something like 'turn of the JIT on both engines and do the benchmark on Desktop?'

robertjpayne commented 9 years ago

@obastemur actually the opposite. I'd love to see benchmarks of SpiderMonkey w/o JIT against JavaScriptCore w/o JIT since used on iOS they both have to have the JIT compiler turned off.

obastemur commented 9 years ago

@robertjpayne I agree. However, 'JIT has to be turned off' is something I'm not 100% agree. JSC has multiple(four?) tiers and only some(last couple?) of them are not available on iOS. SM fakes code generation part but it doesn't keep the engine from further optimizations on top of baseline compiler.

IMHO JIT is virtually in action.