There are more and more references in the Node.js community to "CrankShaftScript" (and "CrankShaftJS") on Twitter, GitHub, and Facebook group discussions. I thought Node.js was written in C++ and JavaScript, so what is CrankShaftScript referring to in performance regression bugs like this one:
https://github.com/nodejs/CTC/issues/146#issue-237435588
CrankShaftScript is the name given by the community to JS idioms (such as certain types of loops) that run faster(est?) on V8's CrankShaft engine.
CrankShaft is being replaced by an engine named TurboFan. Lots of JS code written by devs over the years has been written specifically to run fast on CrankShaft (e.g. written in "CrankShaftScript") using the known idioms that run fast on CrankShaft - this is no longer necessarily the case because the V8 engine is now different and the code that ran fastest on CrankShaft is not necessarily guaranteed to run fastest on TurboFan.
In case my answer is too verbose, here's a great comment on the NodeJS Benchmarks thread that may detail it better:
...I noticed that some parts of Node core are sort-of written in
CrankshaftScript, i.e. carefully tuned towards stuff that works
extremely well in Crankshaft.
CrankShaftScript is a community-adopted term used for non-idiomatic and/or non-standard compliant JavaScript that will only execute and/or perform well in the specific versions of the v8 JavaScript runtime that employ the CrankShaft JIT compiler. Specific examples include: loops written in a difficult-to-maintain fashion to work around JIT optimization deficiencies in v8, and use of v8-specific built-in functions/globals.
This term was originally coined to describe some root performance issues in node-chakracore and spidernode, which are Node.js distributions that employ the ChakraCore and SpiderMonkey runtimes instead of v8.
It is now being used as shorthand to explain why the Node.js 8.1 release series, which updated to a newer version of v8, has several performance regressions in micro- and macro-benchmarks due to v8's CrankShaft JIT being superseded by TurboFan (sometimes referred to as "TF"). As in these issues:
https://github.com/nodejs/node/issues/11851#issuecomment-287253082
https://github.com/nodejs/CTC/issues/146#issuecomment-310229393
https://twitter.com/matteocollina/status/870580613266501632
For these reasons, the Node.js community is actively working on excising instances of CrankShaftScript in Node.js core code, as well as in common npm packages. This should help alternative Node.js distributions like node-chakracore perform better and ease the risk of future upgrades to the JavaScript runtime in Node.js.
CrankShaft is the compilation infrastructure for V8, Node.js' Javascript runtime (details).
It's now being replaced by TurboFan.
Related
In Node, does it make sense to port some logic to wasm for json manipulation operations in order for the algorithm to be quicker?
tl;dr Don't use WASM for JSON manipulation.
Setting up the WASM tooling is no small thing, and will likely require more ongoing troubleshooting and maintenance than lighter-weight solutions.
Wasm generally comes into its own when you need to do truly compute-intensive stuff like customized signal (image/video/audio) processing for your browser users or natively inside server-size Javascript environments.
If your purpose in doing this is avoiding overhead in JSON processing, you might consider looking for fast JSON packages on npm. fast-json-stable-stringify is an example.
You should also keep this in mind: V8 -- the open-source Javascript engine in nodejs, deno, and chromium -- is under active development by a large and highly competent team at Google. That engine includes the JSON. functions. Performance improvements show up in every release, and they're highly motivated to keep making things faster. JSON handling is one of those areas. If you roll your own, your code won't get any faster with the next release of V8/nodejs. If you use the stuff in V8, it might.
Take a look at this dev summit presentation, for example. Maybe you can outsmart the V8 team. If so you should join them.
So, if you want to learn WASM, do something that will add interesting new capabilities to your personal toolbox.
Unlikely. The V8 engine has a pretty good JIT compiler. If it is a hot path and properly written, it will become machine code anyway.
Deno uses v8 to execute javascript but considering the fact that it directly runs typescript, I'm wondering if there is a performance penalty because of it or not.
It seems it compiles the code only for the first time. So is it possible to compile as a deployment step and avoid the startup overhead related to compilation?
Is there any other aspect in performance comparison between node.js and Deno?
Deno keeps track of some key performance metrics here: https://deno.land/benchmarks
As far as pre-compilation, it's on the roadmap and tracked in this issue: https://github.com/denoland/deno/issues/986
(an answer to the 2nd paragraph)
Deno stores the compiled assets in DENO_DIR. You can check it with the command "deno info". If you deploy the entire DENO_DIR as well as your source code, you can avoid the TypeScript compilation at the startup time.
You can also change the location of DENO_DIR by setting the DENO_DIR environmental variable.
DENO_DIR=/path/to/your_deno_dir deno run entrypoint.ts
Deno performance was and still better than Nodejs in excellent way since it's was using both JavaScript and TypeScript in it's code.
Deno as a secure TypeScript runtime built on V8, the Google runtime engine for JavaScript, is a good hope for back-end devs in future as It was built with Rust which I think is better than C++ which gave a life to Nodejs (Deno’s core was written in Rust, Node’s in C++).
I've not yet started to use deno fully but It's undoubtedly sure that it will be the best alternative to Nodejs as it includes almost everything Nodejs has with additional modern features needed in new dev world.
I'm trying to make it's tutorial on my site #Donnekt
Google's open sourced V8 engine is mature, performant JIT compiler.
Implemented primarily in C++, acting as JS centric execution runtime.
It has an isolation implementation (V8: Isolates), providing isolation granularity within a single process.
Leading to two part question.
(Generic)
Can this capability be broadly used for isolation across server-side web application engines (e.g. nginx, apache) and programming languages?
(And more specific ->)
What I've grasped of V8 - is that it's designed for JS scripting lang (even though, it compiles directly to machine code).
Wanting to use a programming language for source code - say Haskell, C++/C - then tends to still have JS interface in between.
Would there be a much direct way to generate machine code, while still using V8: Isolates?
V8 is a JavaScript (and WebAssembly, in recent versions) engine and as such cannot be used to compile or execute any other languages.
If you have C++ code, you'll need to use a C++ compiler to generate executable machine code for it. Haskell code needs a Haskell compiler.
Depending on your requirements, WebAssembly might be interesting to you: it is a portable compilation target for languages like C++ that is more suitable for this purpose than JavaScript.
This should answer both your "more specific" and the "generic" question.
Note that there isn't really any magic in V8's Isolates that one might want to use for other purposes; the term mostly describes the ability to have several separate instances of V8 in the same process. That's rather easy to pull off if you start your own project from scratch (no matter what its purpose is), you just have to maintain a bit of coding discipline; for an existing codebase it requires refactoring of all global state (static variables etc).
Also, note that the world has learned this year that from a security point of view, there really is no such thing as in-process isolation. If you have strong security requirements, then at the very least you'll have to run separate processes for different security domains. (To be clear, V8's Isolates do not provide protection from side-channel attacks.)
My understanding of the technology is that it is compiled on the fly into assembly. On the speed spectrum it is slower than Java but faster than Ruby and Python. On the client side an interpreter makes sense but on the server side my first thought is that compilation prior to running, or at least having the option to do so, is an optimal architecture. If the JavaScript was pre compiled in this way would it run faster than Java? Or is it something to do with weakly typed languages which means that JavaScript will always be slower than Java?
Some of Node.js is C++ and is pre-compiled. My understanding though is that there was an effort to keep as much of it in Javascript as possible, but where performance was poor then C++ was used.
Node.js would not be possible without the V8 JavaScript Engine, which is what compiles the javascript. This engine is well-known for being extremely fast. It was built for the Chrome browser, but the performance pays off in Node.js too.
Regarding performance of Node.js, as a web server it is at least on a par with the other leading web servers like Apache+PHP. So performance is not an issue in the common use case. That said, there are faster technologies. Erlang based servers are known for being faster under concurrent loads (interestingly, Erlang is also a dynamically typed language).
For pure number crunching cpu/gpu intensive tasks, Node.js is not a good choice, unless you temper it with Fabric Engine, in which case it can be on a par with C++.
There are a couple of projects that are currently exploring speed issues with JavaScript:
Dart - http://www.dartlang.org/support/faq.html. (Its not just about speed but that is part of it).
Node Native - https://github.com/d5/node.native/
As stated in the title, I would like to know if it's safe to develop a website using one of the actuals "omg" platforms that are Node.js and Ringo.js at their actual version.
Also, I would like to know if they support cookies/sessions and how do they deals with multi-fields post (fieldname[] in PHP).
Thank you
--Edit--
Thanks for all the links guys.
What can you tell me about Ringojs ?
Since I haven't figured which platform to start playing with. I must admit that the fact it can use Java seamlessly really impress me. The only available XSLT 2.0 library is in Java. I could use it as a templating system.
Is there anyone who had the chance to play with Ringojs?
From my experience using both, Ringo is more stable and "safer" for production use but you can comfortably deploy both. In addition to the ability to wrap existing Java libraries that you mention, you also get the benefit of being able to run it in an existing webapp container which manages the lifecycle of the application for you and ensures its availability.
That being said, it doesn't have to be an either or decision. By using my common-node package and assuming you don't use any Java libraries, it's perfectly feasible to maintain a project that runs on both without any changes to the code.
I've also included benchmarks that test the performance of Node.js vs. RingoJS the results of which you can find in the common-node/README.md. To summarize: RingoJS has slightly lower throughput than Node.js, but much lower variance in response times while using six times the RAM with default Java settings. The latter can be tweaked and brought down to as little as twice the memory usage of Node with e.g. my ringo-sunserver but at the expense of decreased performance.
Node.js is stable, so yes it's safe to use. Node.js is capable of handling cookies, sessions, and multiple fields but are not as easy to manage. Web frameworks solve this problem.
I recommend Express.js, it's an open-source web framework for Node.js which handles all of this and more.
You can download it here:
https://github.com/visionmedia/express
I hope this helped!
Examples of some of the bigger sites running Node.js
https://www.learnboost.com/
http://ge.tt/
https://gomockingbird.com/
https://secured.milewise.com/
http://voxer.com/
https://www.yammer.com/
http://cloud9ide.com/
http://beta.etherpad.org/
http://loggly.com/
http://wordsquared.com/
Yes. It is. https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node and https://github.com/joyent/node/wiki/modules
cookies/sessions/forms etc http://expressjs.com/ makes it easier
Ringojs is a framework developed by Hannes Wallnöver and uses rhino as it's scripting framework. There are webframeworks, templating-engines, orm-packages and many many more things already available. Have a look at the tutorial featuring a good subset of packages you may use for a simple web-application. It's not too long and straightforward.
Even thought some of those packages used within the tutorial (e.g. ringo-sqlstore]) are marked as 0.8 and come with the hint "consider this being beta" they are already very stable and bugs - if you find one - get fixed or commented on very fast.
And the power of uncountable java-libraries out there is at your fingertips - so if you already have java-knowledge this knowledge isn't wasted. Rhino - the scripting-engine - even enables you to implement interfaces and extend classes. It is possible a little more advanced but i've done it and i know of packages taking advantage of such features (like ringo-ftpserver which is a wrapper around Apache FtpServer written in java)
Another pro for me is - because ringojs is based on java - it works fairly well with multithreading with ringo/worker for example.