Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JIT: So you want to be faster than an interpreter on modern CPUs

pinaraf.info

Post reply on HN
Print view View original

41–50 of 66 posts

Re: JIT: So you want to be faster than an interpreter on modern CPUs

#41

Post by true_religion »

tgv wrote: post #29
pjc50 wrote: post #27

Earlier quoted context omitted.

You can't precompile your web page's Javascript for iOS, even if you're willing to have it signed and notarized and submitted for policy review.

Apart from the fact that its JS engine is really fast, Safari accepts WebAssembly. What else would you precompile it to?

Originally, iOS Safari handled WASM but only with JIT disabled.

However the EU decreed that it must allow for fair competition, leading to it claiming that it will enable JIT for authorized developers: https://developer.apple.com/support/alternative-browser-engi...

But I'm not sure that they have done so...

Mozilla: https://github.com/mozilla/platform-tilt/issues/3

Chrome: https://issues.chromium.org/issues/42203058

Re: JIT: So you want to be faster than an interpreter on modern CPUs

#42

Post by duped »

bencyoung wrote: post #25
duped wrote: post #10

Earlier quoted context omitted.

What advantage does JIT compilation have over Swift or Obj-C?

JIT compilation can be faster for compiled languages too, as it allows data driven inlining and devirtualization, as well as "effective constant" propogation and runtime architecture feature detection

Is there a production JIT for a compiled language that is actually faster? I understand the theory, I don't think the practice backs it up.

Re: JIT: So you want to be faster than an interpreter on modern CPUs

#43

Post by duped »

saagarjha wrote: post #12
duped wrote: post #10

Earlier quoted context omitted.

What advantage does JIT compilation have over Swift or Obj-C?

It speeds up interpreted languages.

I get that, but what interpreted language do you want to write iOS apps in when there's Swift and Obj-C right there, with bespoke support and tooling from Apple?

And if you care about performance, why aren't you writing that code in native to begin with?

Re: JIT: So you want to be faster than an interpreter on modern CPUs

#44

Post by fragmede »

duped wrote: post #42
bencyoung wrote: post #25

Earlier quoted context omitted.

JIT compilation can be faster for compiled languages too, as it allows data driven inlining and devirtualization, as well as "effective constant" propogation and runtime architecture feature detection

Is there a production JIT for a compiled language that is actually faster? I understand the theory, I don't think the practice backs it up.

Depends, what do you consider Java?

Re: JIT: So you want to be faster than an interpreter on modern CPUs

#45

Post by varjag »

fragmede wrote: post #44
duped wrote: post #42

Earlier quoted context omitted.

Is there a production JIT for a compiled language that is actually faster? I understand the theory, I don't think the practice backs it up.

Depends, what do you consider Java?

Java is certainly not the fastest language out there.

Re: JIT: So you want to be faster than an interpreter on modern CPUs

#46

Post by Arnavion »

Wowfunhappy wrote: post #33
Arnavion wrote: post #11

Earlier quoted context omitted.

Speculative execution does not require out-of-order execution. When you predict a branch, you're speculatively executing the predicted branch. Whether you're doing it in the same order as instruction order or out of order is independent of that.

If you're executing instructions in order, wouldn't you already know the result of the branch by the time you reach its code?

The fetch stage of the pipeline will have needed to predict the branch N cycles before the execute stage of the pipeline actually gets around to evaluating it, in order to continue fetching the post-branch instructions. Without branch prediction the fetch stage would need to stall until that happens, which decreases throughput. The point of branch prediction and the subsequent speculative execution is to optimistically avoid that stall.

Re: JIT: So you want to be faster than an interpreter on modern CPUs

#48

Post by Rohansi »

cmeacham98 wrote: post #40
j16sdiz wrote: post #36

Earlier quoted context omitted.

Yes.

Source? Is there any non-Apple app that has this entitlement?

If your app happens to be a browser that's only usable in the EU then:

https://developer.apple.com/documentation/browserenginekit/p...

Re: JIT: So you want to be faster than an interpreter on modern CPUs

#49

Post by Rohansi »

varjag wrote: post #30
bencyoung wrote: post #25

Earlier quoted context omitted.

JIT compilation can be faster for compiled languages too, as it allows data driven inlining and devirtualization, as well as "effective constant" propogation and runtime architecture feature detection

It can be but it never is.

But is that because of JIT compilation or other decisions for how the language should work (dynamic typing, GC, etc.)?
Post reply on HN