9 ms·

Bringing ChakraCore to Linux and OS X

264 points by bevacqua 10y ago

stonewhite 10y ago
What does ChakraCore bring on to the table V8 currently doesn't? Can someone elaborate?
- Sir_Cmpwn 10y ago
  Competetion.
- azakai 10y ago
  All JS engines make different tradeoffs, so they are better at some things compared to other engines. For example, Chakra has had full asm.js optimization support for a long time now, while v8 still doesn't (but it's coming). We now have 4 high-quality JS engines that are cross-platform and open source (v8, SpiderMonkey, JavaScriptCore, and now Chakra). This is great!
- dsp1234 10y ago
  When MS announced a node.js version backed by Chakra instead of V8, some of the comments (including one from me) addressed some of the reasons that having multiple JS engines is a good thing. https://news.ycombinator.com/item?id=10932182 https://news.ycombinator.com/item?id=10932182
- brokentone 10y ago
  It's an engine -- it shouldn't bring much that is different. Having hundreds of frameworks, platforms, etc isn't great, but having at least one alternate is awesome. Minimally it allows for a larger collection of minds to deal with hard performance problems, to each take different approaches, and to potentially standardize on a solution after sufficient time to prove out solutions.
- PeCaN 10y ago
  Sometimes faster, better ES6 support (to hopefully spur V8 to complete theirs), etc. Nothing big, but a little competition is nice.
- bzbarsky 10y ago
  Off the top of my head: better performance on some workloads, better standards support in some cases, not being controlled by Google. If you happen to care about those workloads or those cases, or have a company policy to not use or minimize use of Google software (which some places do, especially ones that think they might end up competing with Google), these are pretty useful features.
- typpytyper 10y ago
  The Node.JS project has a problem in that it has never had a specification - only a defacto implementation based on an ever-changing V8 engine with whatever ECMAScript compliance that V8 had at the time. Recently Google made big changes to the V8 API that broke Node Buffer in a rather large way and the Node devs had to do handsprings to put together a less than optimal workaround to get it working with V8 ArrayBuffer. Node.JS is at the mercy of Google's V8 engine which is designed first and foremost for Chrome. ChakraCore did the impossible in that they've mimicked the V8 C++ API to make it appear to Node as V8. But this trick will only work for so long as Google continues to change its engine. It would be better for Node long term to have a JS engine independent C ABI. But the core developers of the Node project are resisting this idea as they believe Node is V8 only. I don't think that Node will ever officially merge Chakra. They just want it to go away.
xutopia 10y ago
What's the point of this exactly? Why would someone chose this over V8?
- nitinreddy88 10y ago
  Why would someone buy Benz when there is BMW. Every engine is better in some aspect and suffer in another aspect. There is already benchmark link provided, which already prooves one reason to choose over V8.
tombert 10y ago
This is interesting enough, I suppose, but I think they should have included some kind of interesting benchmark where Chakra outperformed V8 or something for Node.
- dsp1234 10y ago
  They already did that back in January when they announced a node.js integration with ChakraCore [0]. https://blogs.windows.com/msedgedev/2016/01/19/nodejs-chakracore-mainline/ https://blogs.windows.com/msedgedev/2016/01/19/nodejs-chakra...
  - uep 10y ago
    Direct link to the graph: https://winblogs.azureedge.net/win/2016/01/nodejs-benchmark-performance-1024x547.png https://winblogs.azureedge.net/win/2016/01/nodejs-benchmark-... It looks like they perform better on 50/675 tests, and worse on 500/675 tests. That is not particularly compelling. Since that was a while ago now, I really would prefer to see where improvements have been made.
- hiteshk_msft 10y ago
  Thanks for the suggestion, great idea! However, it's really early days for us still- as the blog post mentions, we are still working on implementing the JIT and concurrent GC which are quite important to awesome performance. When we complete that work, we'd definitely keep a close eye on current industry benchmarks
  - tombert 10y ago
    Heh, I didn't actually think an actual MS developer would respond to my comment. As it stands, I can appreciate what MS is doing; you guys aren't probably going to compete with or replace V8 or SpiderMonkey on Linux overnight, hence why getting a working Node port is a good first step of presumably many. Regardless, this is definitely an interesting step; it would be really trippy if I end up using an entire MS stack on my Linux desktop, but it appears that might be a legit possibility.
  - 10y ago
bevacqua 10y ago
To everyone thinking we already have V8 - competition is necessary for the ecosystem not to go stale. For it to thrive, we need competition. Just look at JavaScript. Dozens of libraries that do the same thing, a vibrant ecosystem as a result.
- Klathmon 10y ago
  For example, in V8 a try/catch statement triggers the whole function to be deoptimized [1] Chakra and SpiderMonkey fully optimize these functions even with a try/catch statement (according to 2 devs last time I talked about this [2]). Without alternate engines, people start to think that implementation details in one engine apply to javascript as a whole. Just look around at most javascript "performance tips". Most of them talk about how you should avoid try/catch in performant code, even though it's only one engine that doesn't optimize it, and they have talked about how they want to fix it, but just haven't [3]. And that's just one example, there are hundreds of examples of bugs, performance tricks, and even differences in spec interpretation that can cause issues and can inadvertently become a "standard" without multiple competing engines. [1] More accurately, the function will never be optimized in the first place if it contains a try/catch at all since Crankshaft doesn't support try/catch. [2] https://news.ycombinator.com/item?id=10896729 https://news.ycombinator.com/item?id=10896729 [3] IIRC they haven't devoted time to optimizing it because the architecture of V8 doesn't work well with something like try/catch, but also because it's fairly simple to work around, and most people already do. So you kind of get a catch 22 where V8 won't spend time to fix it because it's not worth it, and it won't be worth it because V8 doesn't support it.
  - erichocean 10y ago
    > So you kind of get a catch 22 where V8 won't spend time to fix it because it's not worth it, and it won't be worth it because V8 doesn't support it. That's an easy fix though: introduce one or more performance tests that stress try/catch (i.e. don't employ the workaround). Obviously Google won't be doing it, but there's nothing to stop Microsoft or Mozilla for lobbying for it.
    - 10y ago
kogir 10y ago
I've not tried recent versions of node but have had to port things like Brendan Gregg's flamegraph tools from node to other languages because node would die with even pedestrian memory use (well under 4GB). Does anyone know if ChakraCore has better memory management? Could be a big win for longer running applications or those that simply need a larger working set.
aravindet 10y ago
This is good news for a healthy Node.js ecosystem, but I can't see what’s in it for Microsoft. V8-based Node.js works fine on Windows and Azure, so they don’t need this to attract Node.js developers and the npm ecosystem to their platform. Are there any theories about how this (presumably substantial) investment makes business sense for MS?
- vegabook 10y ago
  It's less about an explicit positive for MS than a necessary rearguard against a trend negative in the form of the encroachment of Linux. If they don't do (things like) this, they'll be shut out of the server-side ecosystem altogether. MS needs to hedge its bets and ensure that if Linux achieves total domination, they still have a very good technical offering on that platform that does not rely on their arch enemy. So put as much stuff onto Linux as possible, then sell services/support etc IBM-style. And of course they also hope to bring in dev resources for free!
- pjmlp 10y ago
  Oracle is also making JavaScript having first class support on the JVM since Java 8. JavaScript has just reach the same status as many other languages in having the freedom of multiple implementations.
- madmax96 10y ago
  Easy: embrace, extend, and extinguish. If Microsoft behaves as they have done in the past, this is what will happen: 1. Make Node run on top of Chakra [x] 2. Give Chakra non-standard features and sell communities on them while pointing out to dissenters that the extensions are open source [] 3. Gradually allow open source work on the product to die and commercialize it [] Microsoft has lost a lot of people's trust. My grandfather used to tell me that trust is hard to earn and easy to lose. Once trust is lost, it's even tougher to earn back. It's going to take some convincing on their end if they want developers to trust them. It doesn't __matter__ if they appear to act more ethically than their competitors, that's not how trust works, and it won't convince a lot of people that have watched Microsoft for a while that they've suddenly changed their ways. EDIT: funny this is being downvoted considering eee was an actual strategy Microsoft has historically employed according to the US Justice Department. This isn't even conspiracy theory stuff -- this is real life. Those who don't study history are doomed to repeat it.
duaneb 10y ago
Does this indicate a desire to bring Edge to macOS/Linux? Finally some more browser competition!
- hellojs 10y ago
  [disclosure - I work for MSFT] It's only ChakraCore that is going cross-platform at the moment, and existing platform support matrix for Microsoft Edge remains unchanged now. That said, we'd welcome input from developers and users who want to see Edge on the platform of their choice. Limin edit - typo
  - dhritzkiv 10y ago
    One reason for Edge on other platforms: not having to spin up a Windows virtual machine or boot up a PC for cross-browser testing.
    - Ezhik 10y ago
      If the hypothetical Linux/OSX Edge lives up to Windows' one's battery life promises, it would be great as an actual primary browser.
      - Sylos 10y ago
        > Windows' one's battery life promises As in promises that Microsoft has made or as in what Windows Edge actually delivers? Because so far, from what I've heard, there seems to be a pretty big discrepancy between those two, but I haven't seen any actual benchmarks, so could also just be nonsense...
    - pyre 10y ago
      It's possible for there to be platform-specific bugs / quirks even in the same engine.
      - dimal 10y ago
        True, but if you could do day to day testing without a VM, even running automated tests against it, that would be a huge timesaver. Then you fire up the VM once a week (or some reasonable interval) to confirm it's 100%. There are platform specific bugs, but most issues I see now with Chrome or Firefox are specific to the browser, not the platform.
purohitpavan 10y ago
Super
purohitpavan 10y ago
Super
zwetan 10y ago
Having different engine is good, even "non-obvious" ones If you look at the sources of TypeScript you can see it supports: Node.js, Windows Script Host and ChakraHost (see [1]) I made a little experiment to support another engine: the ActionScript Virtual Machine (AVM2) which not only support ActionScript 3.0 but also JavaScript (see [2]) Personally it's not that I don't like Node.js, but I do like the idea to take the JS sources of some command-line tool and bundle them in one independent executable to then distribute it as a deb package or Mac OS X pkg etc. without having to first install node.js/npm [1]: https://github.com/Microsoft/TypeScript/blob/master/src/compiler/sys.ts https://github.com/Microsoft/TypeScript/blob/master/src/comp... [2]: https://discuss.as3lang.org/t/the-case-when-you-dont-want-node-js/307 https://discuss.as3lang.org/t/the-case-when-you-dont-want-no...
- skratlo 10y ago
  It's all about resource efficiency. If you do that (bundle), you're not resource efficient (memory), but the resulting solution is easy to use (no dealing with dependency conflicts where A depends on X-v1 and B on X-v2, and you need A and B running in the same system). How important is resource efficiency, and what it even means today vs. yesterday varies wildly.
  - zwetan 10y ago
    I experienced different results. One of the main problem with JS engines is that they load external code on demand, even with something like JSDB (see [1] based on SpiderMonkey engine) where you can bundle all of your JS inside a zip that you then bundle/merge with the runtime, the JS files still have to be extracted from the zip and loaded "as file" from memory. In the case of the AVM2, wether the files are AS3 or JS they are first compiled to bytecode (like Java) and that's what you bundle with the runtime, the bytecode still have to be loaded but it is "one big file", so wether your sources are many 100s of JS files it does not matter. That matter a lot for the resource efficiency, and it influence a lot the memory footprint (~10MB for AVM2, ~50MB for a Node.js, see [2]), eg. the more files you load the more memory you gonna use. For the dependencies conflict yep it make things easier too, not only for the versioning of libraries as you describe but also for the versioning of the runtime itself, eg. runtime v2 could be installed system wide but your self-contained exe could use an older runtime v1. [1]: http://www.jsdb.org http://www.jsdb.org [2]: https://github.com/eclipse/kura/wiki/Footprint https://github.com/eclipse/kura/wiki/Footprint

264 points by bevacqua 10y ago

stonewhite 10y ago

What does ChakraCore bring on to the table V8 currently doesn't? Can someone elaborate?

Sir_Cmpwn 10y ago
Competetion.
azakai 10y ago
All JS engines make different tradeoffs, so they are better at some things compared to other engines. For example, Chakra has had full asm.js optimization support for a long time now, while v8 still doesn't (but it's coming). We now have 4 high-quality JS engines that are cross-platform and open source (v8, SpiderMonkey, JavaScriptCore, and now Chakra). This is great!
dsp1234 10y ago
When MS announced a node.js version backed by Chakra instead of V8, some of the comments (including one from me) addressed some of the reasons that having multiple JS engines is a good thing. https://news.ycombinator.com/item?id=10932182 https://news.ycombinator.com/item?id=10932182
brokentone 10y ago
It's an engine -- it shouldn't bring much that is different. Having hundreds of frameworks, platforms, etc isn't great, but having at least one alternate is awesome. Minimally it allows for a larger collection of minds to deal with hard performance problems, to each take different approaches, and to potentially standardize on a solution after sufficient time to prove out solutions.
PeCaN 10y ago
Sometimes faster, better ES6 support (to hopefully spur V8 to complete theirs), etc. Nothing big, but a little competition is nice.
bzbarsky 10y ago
Off the top of my head: better performance on some workloads, better standards support in some cases, not being controlled by Google. If you happen to care about those workloads or those cases, or have a company policy to not use or minimize use of Google software (which some places do, especially ones that think they might end up competing with Google), these are pretty useful features.
typpytyper 10y ago
The Node.JS project has a problem in that it has never had a specification - only a defacto implementation based on an ever-changing V8 engine with whatever ECMAScript compliance that V8 had at the time. Recently Google made big changes to the V8 API that broke Node Buffer in a rather large way and the Node devs had to do handsprings to put together a less than optimal workaround to get it working with V8 ArrayBuffer. Node.JS is at the mercy of Google's V8 engine which is designed first and foremost for Chrome. ChakraCore did the impossible in that they've mimicked the V8 C++ API to make it appear to Node as V8. But this trick will only work for so long as Google continues to change its engine. It would be better for Node long term to have a JS engine independent C ABI. But the core developers of the Node project are resisting this idea as they believe Node is V8 only. I don't think that Node will ever officially merge Chakra. They just want it to go away.

xutopia 10y ago

What's the point of this exactly? Why would someone chose this over V8?

nitinreddy88 10y ago
Why would someone buy Benz when there is BMW. Every engine is better in some aspect and suffer in another aspect. There is already benchmark link provided, which already prooves one reason to choose over V8.

tombert 10y ago

This is interesting enough, I suppose, but I think they should have included some kind of interesting benchmark where Chakra outperformed V8 or something for Node.

dsp1234 10y ago
They already did that back in January when they announced a node.js integration with ChakraCore [0]. https://blogs.windows.com/msedgedev/2016/01/19/nodejs-chakracore-mainline/ https://blogs.windows.com/msedgedev/2016/01/19/nodejs-chakra...
- uep 10y ago
  Direct link to the graph: https://winblogs.azureedge.net/win/2016/01/nodejs-benchmark-performance-1024x547.png https://winblogs.azureedge.net/win/2016/01/nodejs-benchmark-... It looks like they perform better on 50/675 tests, and worse on 500/675 tests. That is not particularly compelling. Since that was a while ago now, I really would prefer to see where improvements have been made.
hiteshk_msft 10y ago
Thanks for the suggestion, great idea! However, it's really early days for us still- as the blog post mentions, we are still working on implementing the JIT and concurrent GC which are quite important to awesome performance. When we complete that work, we'd definitely keep a close eye on current industry benchmarks
- tombert 10y ago
  Heh, I didn't actually think an actual MS developer would respond to my comment. As it stands, I can appreciate what MS is doing; you guys aren't probably going to compete with or replace V8 or SpiderMonkey on Linux overnight, hence why getting a working Node port is a good first step of presumably many. Regardless, this is definitely an interesting step; it would be really trippy if I end up using an entire MS stack on my Linux desktop, but it appears that might be a legit possibility.
- 10y ago

bevacqua 10y ago

To everyone thinking we already have V8 - competition is necessary for the ecosystem not to go stale. For it to thrive, we need competition. Just look at JavaScript. Dozens of libraries that do the same thing, a vibrant ecosystem as a result.

Klathmon 10y ago
For example, in V8 a try/catch statement triggers the whole function to be deoptimized [1] Chakra and SpiderMonkey fully optimize these functions even with a try/catch statement (according to 2 devs last time I talked about this [2]). Without alternate engines, people start to think that implementation details in one engine apply to javascript as a whole. Just look around at most javascript "performance tips". Most of them talk about how you should avoid try/catch in performant code, even though it's only one engine that doesn't optimize it, and they have talked about how they want to fix it, but just haven't [3]. And that's just one example, there are hundreds of examples of bugs, performance tricks, and even differences in spec interpretation that can cause issues and can inadvertently become a "standard" without multiple competing engines. [1] More accurately, the function will never be optimized in the first place if it contains a try/catch at all since Crankshaft doesn't support try/catch. [2] https://news.ycombinator.com/item?id=10896729 https://news.ycombinator.com/item?id=10896729 [3] IIRC they haven't devoted time to optimizing it because the architecture of V8 doesn't work well with something like try/catch, but also because it's fairly simple to work around, and most people already do. So you kind of get a catch 22 where V8 won't spend time to fix it because it's not worth it, and it won't be worth it because V8 doesn't support it.
- erichocean 10y ago
  > So you kind of get a catch 22 where V8 won't spend time to fix it because it's not worth it, and it won't be worth it because V8 doesn't support it. That's an easy fix though: introduce one or more performance tests that stress try/catch (i.e. don't employ the workaround). Obviously Google won't be doing it, but there's nothing to stop Microsoft or Mozilla for lobbying for it.
  - 10y ago

kogir 10y ago

I've not tried recent versions of node but have had to port things like Brendan Gregg's flamegraph tools from node to other languages because node would die with even pedestrian memory use (well under 4GB). Does anyone know if ChakraCore has better memory management? Could be a big win for longer running applications or those that simply need a larger working set.

aravindet 10y ago

This is good news for a healthy Node.js ecosystem, but I can't see what’s in it for Microsoft. V8-based Node.js works fine on Windows and Azure, so they don’t need this to attract Node.js developers and the npm ecosystem to their platform. Are there any theories about how this (presumably substantial) investment makes business sense for MS?

vegabook 10y ago
It's less about an explicit positive for MS than a necessary rearguard against a trend negative in the form of the encroachment of Linux. If they don't do (things like) this, they'll be shut out of the server-side ecosystem altogether. MS needs to hedge its bets and ensure that if Linux achieves total domination, they still have a very good technical offering on that platform that does not rely on their arch enemy. So put as much stuff onto Linux as possible, then sell services/support etc IBM-style. And of course they also hope to bring in dev resources for free!
pjmlp 10y ago
Oracle is also making JavaScript having first class support on the JVM since Java 8. JavaScript has just reach the same status as many other languages in having the freedom of multiple implementations.
madmax96 10y ago
Easy: embrace, extend, and extinguish. If Microsoft behaves as they have done in the past, this is what will happen: 1. Make Node run on top of Chakra [x] 2. Give Chakra non-standard features and sell communities on them while pointing out to dissenters that the extensions are open source [] 3. Gradually allow open source work on the product to die and commercialize it [] Microsoft has lost a lot of people's trust. My grandfather used to tell me that trust is hard to earn and easy to lose. Once trust is lost, it's even tougher to earn back. It's going to take some convincing on their end if they want developers to trust them. It doesn't __matter__ if they appear to act more ethically than their competitors, that's not how trust works, and it won't convince a lot of people that have watched Microsoft for a while that they've suddenly changed their ways. EDIT: funny this is being downvoted considering eee was an actual strategy Microsoft has historically employed according to the US Justice Department. This isn't even conspiracy theory stuff -- this is real life. Those who don't study history are doomed to repeat it.

duaneb 10y ago

Does this indicate a desire to bring Edge to macOS/Linux? Finally some more browser competition!

hellojs 10y ago
[disclosure - I work for MSFT] It's only ChakraCore that is going cross-platform at the moment, and existing platform support matrix for Microsoft Edge remains unchanged now. That said, we'd welcome input from developers and users who want to see Edge on the platform of their choice. Limin edit - typo
- dhritzkiv 10y ago
  One reason for Edge on other platforms: not having to spin up a Windows virtual machine or boot up a PC for cross-browser testing.
  - Ezhik 10y ago
    If the hypothetical Linux/OSX Edge lives up to Windows' one's battery life promises, it would be great as an actual primary browser.
    - Sylos 10y ago
      > Windows' one's battery life promises As in promises that Microsoft has made or as in what Windows Edge actually delivers? Because so far, from what I've heard, there seems to be a pretty big discrepancy between those two, but I haven't seen any actual benchmarks, so could also just be nonsense...
  - pyre 10y ago
    It's possible for there to be platform-specific bugs / quirks even in the same engine.
    - dimal 10y ago
      True, but if you could do day to day testing without a VM, even running automated tests against it, that would be a huge timesaver. Then you fire up the VM once a week (or some reasonable interval) to confirm it's 100%. There are platform specific bugs, but most issues I see now with Chrome or Firefox are specific to the browser, not the platform.

purohitpavan 10y ago

Super

purohitpavan 10y ago

Super

zwetan 10y ago

Having different engine is good, even "non-obvious" ones If you look at the sources of TypeScript you can see it supports: Node.js, Windows Script Host and ChakraHost (see [1]) I made a little experiment to support another engine: the ActionScript Virtual Machine (AVM2) which not only support ActionScript 3.0 but also JavaScript (see [2]) Personally it's not that I don't like Node.js, but I do like the idea to take the JS sources of some command-line tool and bundle them in one independent executable to then distribute it as a deb package or Mac OS X pkg etc. without having to first install node.js/npm [1]: https://github.com/Microsoft/TypeScript/blob/master/src/compiler/sys.ts https://github.com/Microsoft/TypeScript/blob/master/src/comp... [2]: https://discuss.as3lang.org/t/the-case-when-you-dont-want-node-js/307 https://discuss.as3lang.org/t/the-case-when-you-dont-want-no...

skratlo 10y ago
It's all about resource efficiency. If you do that (bundle), you're not resource efficient (memory), but the resulting solution is easy to use (no dealing with dependency conflicts where A depends on X-v1 and B on X-v2, and you need A and B running in the same system). How important is resource efficiency, and what it even means today vs. yesterday varies wildly.
- zwetan 10y ago
  I experienced different results. One of the main problem with JS engines is that they load external code on demand, even with something like JSDB (see [1] based on SpiderMonkey engine) where you can bundle all of your JS inside a zip that you then bundle/merge with the runtime, the JS files still have to be extracted from the zip and loaded "as file" from memory. In the case of the AVM2, wether the files are AS3 or JS they are first compiled to bytecode (like Java) and that's what you bundle with the runtime, the bytecode still have to be loaded but it is "one big file", so wether your sources are many 100s of JS files it does not matter. That matter a lot for the resource efficiency, and it influence a lot the memory footprint (~10MB for AVM2, ~50MB for a Node.js, see [2]), eg. the more files you load the more memory you gonna use. For the dependencies conflict yep it make things easier too, not only for the versioning of libraries as you describe but also for the versioning of the runtime itself, eg. runtime v2 could be installed system wide but your self-contained exe could use an older runtime v1. [1]: http://www.jsdb.org http://www.jsdb.org [2]: https://github.com/eclipse/kura/wiki/Footprint https://github.com/eclipse/kura/wiki/Footprint