5 ms·

Actually this is probably thanks to Safari's JS engine. From the graph [1] it seems that Safari is roughly 3x faster than Chrome parsing and compiling JS code o

by M4v3R 10y ago

Actually this is probably thanks to Safari's JS engine. From the graph [1] it seems that Safari is roughly 3x faster than Chrome parsing and compiling JS code on the same Macbook Pro. [1] https://cdn-images-1.medium.com/max/2000/1*dnhO1M_zlmAhvtQY_7tZmA.jpeg https://cdn-images-1.medium.com/max/2000/1*dnhO1M_zlmAhvtQY_...

Klathmon 10y ago
Yeah, Safari has stupidly fast startup times compared to Chrome. It's one of the big things that they are working on in their engine. It's been a bit, and I'm going from memory here, so forgive me if i'm wrong, but... V8 is introducing a new "interpreter" mode to help here so that the page can start being interpreted ASAP and no JIT overhead needs to force the system to wait until it's done a first pass. And in the long run they want to pull out 2 of the JITs in their engine to simplify the process and speed up the first execution (along with reducing memory usage, and simplifying the codebase to allow for faster and easier additions and optimizations). It's a great move, but it means that things are going to get slightly worse before they get better. The "old" V8 had 3 compilers, "Fullcodegen", "crankshaft", and "turbofan" [0]. The current V8 has those 3 + Ignition [1], so it's just adding more on now. But over time they will be removing crankshaft and fullcodegen and it will leave them with a really clean and fast engine [2]. If anyone is interested, [3] is a fantastic talk on this and other plans they have for V8, and it's very accessible for those who don't know a thing about JS engines. (sorry about the links to google sheets here, it's the only place I can seem to find the infographics) [0] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6HaCIu9wpZsrzqpIVIwQSuiXQ/edit#slide=id.g1453eb7f19_0_359 https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H... [1] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6HaCIu9wpZsrzqpIVIwQSuiXQ/edit#slide=id.g1453eb7f19_5_97 https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H... [2] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6HaCIu9wpZsrzqpIVIwQSuiXQ/edit#slide=id.g1453eb7f19_0_391 https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H... [3] https://youtu.be/r5OWCtuKiAk https://youtu.be/r5OWCtuKiAk edit: Removed comment about edge, it was more assumption than anything.
- natorion 10y ago
  Great summary with a few nits! I am not aware that Edge is "stupidly fast" on startup. Safari though, is indeed currently leading the field. As you correctly outlined, V8 is indeed transitioning to a world with an interpreter+optimizing compiler only. If you are using Chrome Canary, there is a chance that you are already using the new pipeline :-). Full disclosure: I work on the V8 team.
  - Klathmon 10y ago
    I gotta be honest, I've only heard that in comments and "not so reliable" sources, so I should probably remove it while I can. As for the Ignition+TurboFan setup, are you really that far along already? Last I heard a few months ago it still sounded like it was gonna be a while before TurboFan was fast enough in most cases to be able to handle it. If so that's awesome!
    - natorion 10y ago
      It is progressing quite nicely. We still don't know yet when it is ready to graduate from Canary/Dev though. Lot's of stuff to do!
  - gsnedders 10y ago
    From those who spoke at BlinkOn about Ignition, it sounded like some of the pushback had been about Octane, but there'd been some movement against worrying about the Octane regression from a view that Crankshaft was over-fitted to Octane. How much of what's remaining is performance versus stability/correctness?
  - sedachv 10y ago
    > As you correctly outlined, V8 is indeed transitioning to a world with an interpreter+optimizing compiler only. ECL and CLISP both settled on this model. CLISP started out as a bytecode interpreter and added GNU Lightning for native code generation. ECL started out as a source-to-source compiler to C and added a bytecode interpreter; both follow C calling convention as much as possible, at first for easy interop with C code and then for easy interop for the bytecode interpreter, which avoids the C++ interop problems mentioned in the talk.
jinwood 10y ago
Its a combination of that and Apple's A10 chip being significantly faster than the top Qualcom chips at single thread: http://www.tomsguide.com/us/iphone-7-benchmark-results,news-23474.html http://www.tomsguide.com/us/iphone-7-benchmark-results,news-...
- pvg 10y ago
  The A10 doesn't come into this, it just makes it even faster. An iPhone 6 is substantially faster in the graph shown than any current Android phone.
DanHulton 10y ago
iPhones aren't simply faster at JS, they're faster at everything. Benchmarks run in the same app always come out drastically in the iPhone's favour. Granted, this isn't a strict apples-to-apples comparison, but the differences are so drastic and always in Apple's favour. That, combined with the actual, physical differences in speed of the processors on the phone itself, indicates that it's not just Safari.
- pjmlp 10y ago
  It helps that they chose an AOT model, with languages that support value types. Also that even the bitcode model is compiled at the store, instead of frying eggs on the device. Doing real-time audio applications on Android is a pain, from the presentations I have watched, even with the NDK.

by M4v3R 10y ago

Klathmon 10y ago

Yeah, Safari has stupidly fast startup times compared to Chrome. It's one of the big things that they are working on in their engine. It's been a bit, and I'm going from memory here, so forgive me if i'm wrong, but... V8 is introducing a new "interpreter" mode to help here so that the page can start being interpreted ASAP and no JIT overhead needs to force the system to wait until it's done a first pass. And in the long run they want to pull out 2 of the JITs in their engine to simplify the process and speed up the first execution (along with reducing memory usage, and simplifying the codebase to allow for faster and easier additions and optimizations). It's a great move, but it means that things are going to get slightly worse before they get better. The "old" V8 had 3 compilers, "Fullcodegen", "crankshaft", and "turbofan" [0]. The current V8 has those 3 + Ignition [1], so it's just adding more on now. But over time they will be removing crankshaft and fullcodegen and it will leave them with a really clean and fast engine [2]. If anyone is interested, [3] is a fantastic talk on this and other plans they have for V8, and it's very accessible for those who don't know a thing about JS engines. (sorry about the links to google sheets here, it's the only place I can seem to find the infographics) [0] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6HaCIu9wpZsrzqpIVIwQSuiXQ/edit#slide=id.g1453eb7f19_0_359 https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H... [1] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6HaCIu9wpZsrzqpIVIwQSuiXQ/edit#slide=id.g1453eb7f19_5_97 https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H... [2] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6HaCIu9wpZsrzqpIVIwQSuiXQ/edit#slide=id.g1453eb7f19_0_391 https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H... [3] https://youtu.be/r5OWCtuKiAk https://youtu.be/r5OWCtuKiAk edit: Removed comment about edge, it was more assumption than anything.

natorion 10y ago
Great summary with a few nits! I am not aware that Edge is "stupidly fast" on startup. Safari though, is indeed currently leading the field. As you correctly outlined, V8 is indeed transitioning to a world with an interpreter+optimizing compiler only. If you are using Chrome Canary, there is a chance that you are already using the new pipeline :-). Full disclosure: I work on the V8 team.
- Klathmon 10y ago
  I gotta be honest, I've only heard that in comments and "not so reliable" sources, so I should probably remove it while I can. As for the Ignition+TurboFan setup, are you really that far along already? Last I heard a few months ago it still sounded like it was gonna be a while before TurboFan was fast enough in most cases to be able to handle it. If so that's awesome!
  - natorion 10y ago
    It is progressing quite nicely. We still don't know yet when it is ready to graduate from Canary/Dev though. Lot's of stuff to do!
- gsnedders 10y ago
  From those who spoke at BlinkOn about Ignition, it sounded like some of the pushback had been about Octane, but there'd been some movement against worrying about the Octane regression from a view that Crankshaft was over-fitted to Octane. How much of what's remaining is performance versus stability/correctness?
- sedachv 10y ago
  > As you correctly outlined, V8 is indeed transitioning to a world with an interpreter+optimizing compiler only. ECL and CLISP both settled on this model. CLISP started out as a bytecode interpreter and added GNU Lightning for native code generation. ECL started out as a source-to-source compiler to C and added a bytecode interpreter; both follow C calling convention as much as possible, at first for easy interop with C code and then for easy interop for the bytecode interpreter, which avoids the C++ interop problems mentioned in the talk.

jinwood 10y ago

Its a combination of that and Apple's A10 chip being significantly faster than the top Qualcom chips at single thread: http://www.tomsguide.com/us/iphone-7-benchmark-results,news-23474.html http://www.tomsguide.com/us/iphone-7-benchmark-results,news-...

pvg 10y ago
The A10 doesn't come into this, it just makes it even faster. An iPhone 6 is substantially faster in the graph shown than any current Android phone.

DanHulton 10y ago

iPhones aren't simply faster at JS, they're faster at everything. Benchmarks run in the same app always come out drastically in the iPhone's favour. Granted, this isn't a strict apples-to-apples comparison, but the differences are so drastic and always in Apple's favour. That, combined with the actual, physical differences in speed of the processors on the phone itself, indicates that it's not just Safari.

pjmlp 10y ago
It helps that they chose an AOT model, with languages that support value types. Also that even the bitcode model is compiled at the store, instead of frying eggs on the device. Doing real-time audio applications on Android is a pain, from the presentations I have watched, even with the NDK.