Now ASM.JS is available for Node.JS Applications

Posted On
ASM.JS, an extraordinarily optimizable, low-level subset of JavaScript. Now it's available for Node applications. The latest JXcore (Github) embeds SpiderMonkey in addition to V8 JavaScript engine. As you might know V8 was able to run ASM.JS codes without much problem but there was no optimization or performance gain in place (actually it is even slower). As a result, it never made any sense to use ASM.JS code on a Node.JS application.

Since JXcore has SpiderMonkey in place (in addition to V8), now it's time to show a basic sample.

Save the JavaScript lines below into asmjs.js file

function AsmJSFibonacci() {
  "use asm";

  function fib(n) {
    n = n | 0;
    var value = 1;
    var prev = 1;
    var i = 1;
    var t = 0;
    for (;
      (i | 0) < (n | 0); i = (i + 1) | 0) {
      t = prev;
      prev = value;
      value = (value + t) | 0;
    }
    return value | 0;
  }

  function many_fib(n) {
    n = n | 0;
    var i = 1;
    var total = 0;
    var calc = 0;
    var z = 0;
    var limit = 2000;
    for (; (z | 0) < (limit | 0); z = (z + 1) | 0) {
      for (; (i | 0) < (n | 0); i = (i + 1) | 0) {
        calc = fib((i | 0)) | 0;
        total = ((total | 0) + (calc | 0)) | 0;
        total = (total - 452433) | 0;
      }
      i = 1 | 0;
    }

    return total | 0;
  }

  return many_fib;
}

var asm_fib = AsmJSFibonacci();


var nfib = function (numMax) {
  var x;
  for (var i = 0, j = 1, k = 0; k < numMax; i = j, j = x, k++) {
    x = i + j;
  }

  return x;
};

var normal_fib = function (n) {
  var total = 0;
  var calc = 0;
  for (var z = 0; z < 2000; z++) {
    for (var i = 1; i < n; i++) {
      calc = nfib(i);
      total += calc;
      total -= 452433;
    }
  }

  return total;
};

var start = process.hrtime();
var res = asm_fib(34);
start = process.hrtime(start);
console.log("ASMJS Time", start, res);

start = process.hrtime();
res = normal_fib(34);
start = process.hrtime(start);
console.log("NORMAL Time", start, res);

And Run!
(you can run it with 'nodejs' or 'jxcore' using V8 engine though. But you should build 'jxcore' with 'spidermonkey' from the sources in order to see how it behaves with a proper ASM.JS support.

jxcore-spidermonkey build:
ASMJS Time [ 0, 1213238 ] 122000
NORMAL Time [ 0, 1909488 ] 122000

jxcore-v8 build:
ASMJS Time [ 0, 7572855 ] 122000
NORMAL Time [ 0, 2347491 ] 122000

Looks like ASM.JS & SpiderMonkey is the winner for the above sample. This is not a performance comparison indeed. There are already many performance comparisons available on ASM.JS performance.

You may want to ask 'what the heck is "require.withAsmJS" ? SpiderMonkey requires "compileAndGo" option enabled for an ASM.JS script. This is not a case for a normal Node.JS JavaScript since "compile" and "go" are two separate steps. For this reason, JXcore has a new addition to "require" interface for JavaScript files with ASM.JS Luke Wagner from SpiderMonkey told me this is no longer an issue. JXcore is updated accordingly. Simple 'require' works now. (sample code is also updated)
[Read more]

JXcore, What's going on?

Posted On
About 10 months ago, we forked Node.JS and started building JXcore. Many people wondered what in the world we were doing by forking Node.JS. We have a big vision and a unique view of how programmers will develop applications in the future. We started by breaking that vision into many pieces that are closely tied. Node.JS is the central pieces of that vision. In this article, I will try to explain some of those pieces that we have completed and some others we are currently working on.

Soon, JXcore will be open sourced under the same license as Node.JS. It's been almost 10 months since we first started patching Node.JS in order to support multithreaded logical instances under the same process. During this time, we changed a very large part of the project sources in order to implement several key features. As a result we re-structured some key parts of Node.JS right from the beginning.

I'm going to come back to re-structuring part later but let me first explain the differences between Node.JS and JXcore. Node.JS, as defined from the main repository, is an asynchronous (evented) IO framework on top of V8 JavaScript engine. JXcore is a fork of Node.JS with additional features including support for multiple JavaScript instances for Node apps (using different threads under the same process). Soon (very soon) JXcore will offer an alternative JavaScript engine other than V8. So you can either use V8 (versions) or the other engine(s).

Since Node.JS is built on top of V8, it is no surprise that it inherits some habits like multiple processes instead multiple threads for managing separate logical parts. I have to admit, although V8 operates multiple JavaScript instances / threads properly, I was surprised by the number of developers against the idea of multiple threads when we came up with the first beta months ago. I believe the initial reaction was mostly because of a misunderstanding (or misleading) on the way we described our multi-threading support. What we implemented was a capability to allow multiple separated logic instances benefiting from multiple cores, not making JavaScript work multi-threaded.

Another challenge facing Node.JS developers is the hosting situation. We believe the difficulty of hosting Node.JS applications is a major problem that needs to be addressed. I have years of .NET experience and in my opinion Node.JS is a powerful platform that you can develop enterprise level applications in a shorter time than ASP.NET. On the other hand, hosting an ASP.NET application requires less technical background and it is much smoother to manage. There are many hosting alternatives compared to hosting a Node.JS application and I'm not even comparing the cost of hosting Node versus ASP.NET. This has to change! Indeed, ASP.NET is around for almost a decade but there are technical reasons for the problems instead being around for a longer period of time.

Last month, we released a free Parallel Plesk Node.JS extension hoping to make Node.JS hosting options available to a larger audience and make it cost effective. The extension is getting better with the updates thanks to Plesk team and its users. Hopefully, small companies and the individual Node.JS developers will find these hosting options useful for their web applications.

In order to develop the Plesk extension, we implemented some key features to make it easier to host a Node.JS application (Multithreading, monitoring, system wide application configuration as you can limit CPU, memory etc) similar to hosting a PHP or ASP.NET application. Coming weeks, we will have an alternative approach to host Node.JS applications easier, and cost effective than ever.

NPM (Node Package Manager) hosts thousands of modules developed by individuals and companies to add additional features to Node. Indeed, NPM is one of coolest package managers. The growth rates of NPM modules is a clear proof. But there are problems not exactly caused by NPM rather how Node.JS have been evolving. There are many Node.JS applications still using version 0.6 and 0.8. Having different versions of V8 makes it almost impossible to develop and compile native Node modules once and for all. It is clear that some module developers may not follow the latest Node versions and keep their modules compatible. As most of the community knows, NPM now includes many outdated packages which would otherwise be very useful. Since we are going to open source JXcore with multiple JavaScript engine option, re-structuring the native module development was inevitable. 

Node.JS has it's own way of dealing with incompatible modules. If a native modules uses 'nan', it has a better chance to survive over multiple releases unless the module doesn't use some critical (non-standard) stuff from the JavaScript engine. And unfortunately, 'nan' may not handle multiple JavaScript engines or pre-compiled binaries per platform. Implementing 'nan' was a very clever hack. But it is still a hack. As the user base of Node.JS grows, a more proper solution must be implemented. In JXcore, we are in the process of completing an interface which will work with multiple JavaScript engines and still be compatible to multiple JavaScript instances per process.

Hopefully, the concept of multiple JavaScript engines will convince more enterprises transition to using Node. One of the key advantages of supporting multiple JavaScript engines is being able to deploy Node applications on mobile platforms. But we are thinking even further. We believe JavaScript will be the best choice for the Internet of Things as we already see some practical usages. We hope to make HTML, CSS, and JavaScript native citizens for all platforms.

As Node applications are deployed on mobile and embedded devices, programmers are faced with the challenge of protecting their JavaScript source code. One option is to "uglify" your source code and hope that nobody will try to extract your code. For many companies this is not even an option. That's one of the reasons why we implemented JXcore packaging feature which protects your source code and instantly creates a package that works on every platform. 

And mobile IDEs. Based on JXcore mobile, Node.JS will be a unique platform with its own IDEs working on mobile devices.  We want to make Node.JS application development easier from development to hosting for every level of developers.

Parts of what I described here is already available. Others will be released over the course of next few months. But this is only part of our overall vision. Stayed tuned for more...
[Read more]

How to measure the CPU usage of a Node.JS / JXcore Application

Posted On
JXcore has a non-documented utility class with several handy methods / features. We didn't published a documentation for the utility members yet, since they are mostly used internally and not designed for general use cases.

Knowing that not much option available for cross platform node.js process CPU tracking, I wanted to share a small sample that may help developers looking for it. If you don't have it yet, visit jxcore.com/downloads to download latest JXcore and run the below sample for CPU usage tracking;

// console color support. 
console.log = jxcore.utils.console.log;

// get CPU usage every 1000ms 
jxcore.utils.getCPU(function (percent, timer) {
    console.log("%d%% CPU Percent Used in last %d ms", percent, 
                        timer , "green");
}, 1000);

Beware that getCPU method only supports a single listener instance at a time. In order to clear the previous listener;

jxcore.utils.getCPU(); 

To read the CPU usage for only once, use above line of code inside the callback function.

There are many alternatives for colored console output though. If you still insist using the one from jxcore.utils, feel free to check ANSI COLOR node module for a color reference. The only difference is that jxcore.utils.console.log works similar to console.log hence it supports multiple parameters..
[Read more]

Monitoring Node.JS applications using JXcore

Posted On
One of the most common concerns with Node.JS based server apps is to keep the process running as long as the hosting server is up an running. Since the whole node.js application is based on a single process, you may need to make sure that process is alive even after the unexpected crashes etc.

Simply download JXcore from http://jxcore.com/downloads/  and locate the 'jx' binary into the system path or where the node binary is located. Assuming the application needs monitoring has a main JavaScript file named 'app.js'

first of all start monitor service:
$ jx monitor start

register the application into monitoring service and run:
$ jx monitor run app.js

That's it! You can kill your application's process from 'terminal' or 'console' etc. in order to see what will happen. As soon as the process is closed, JXcore monitoring service will be restarting it.

If your application requires some command line parameters (i.e param1)
$ jx monitor run app.js param1

In order to stop monitoring service (also stops spawned processes)
$ jx monitor stop
[Read more]