Improvement of Nodejs CPU intensive tasks using webAssembly - node.js

I am just reading a bit, trying to understand new concepts. Hence my question.
If I understand correctly the concept of webAssembly is to simply load a code base from another language (C++, C...) and run it inside the Javascript run time.
So, If I follow correctly, I could write some intensive calculation (e.g. Image manipulation) using C++. Compile the code for webAssembly and simply use it inside Nodejs?
Is there a code play environment where I could examine the principles in more depth?

Yes, there are many things which could be ported to WebAssembly for a performance improvement. Something that is CPU intensive but with minimal interactivity is ideal, and image manipulation could well be a good candidate for using WASM. There's no guarantee of course that it would be worth the development time compared to writing it natively in JS.
Just today I've discovered two online test environments (from the same team):
https://wasdk.github.io/WasmFiddle/
https://webassembly.studio/

Related

Is it possible to execute hand-coded bytecode scripts in the V8 engine?

I am in the early stages of a project that aims to estimate the power consumption of Javascript apps. Similar work has been done with Android apps through Java bytecode profiling, and I am hoping to apply a similar methodology using the bytecode generated by Ignition in the V8 engine. However, understandably, there seem to be more tools and resources available for granular analysis of Java bytecode.
My question is whether or not it is possible in V8 to have the engine run hand-coded bytecode scripts for testing purposes, rather than those generated through the compilation process from actual JS source.
The reason for doing this would the development of energy cost functions at the bytecode instruction level. To accomplish this, I'm hoping to run the same instruction (or set of instructions) repeatedly in a loop on a machine connected to speciliazed hardware to measure power draw. These measurements would then be used to inform an estimate of the total power consumption of a program by analysing the composition of the bytecode generated by V8.
(V8 developer here.)
No, this is not possible.
Bytecode is an internal implementation detail. It intentionally doesn't have an external interface (you can't get it out of V8, and can't feed it back in), and is not standardized or documented -- in fact, it could change any day.
Also, bytecode typically isn't executed very much, because "hot" functions get tiered up (by an evolving set of compilers). So while you could create an artificial lab setting where you stress-test bytecode execution, that would be so far removed from reality that I doubt the results would be very useful. In particular, they would definitely not allow you to make any meaningful statements about actual power consumption of a JavaScript program.
The only way to measure power consumption of a JavaScript program is to run the program in question and measure power consumption while doing so. Due to JavaScript's dynamic/flexible nature, there are no static rules as simple as "every + operation takes X microjoules, every obj.prop load takes Y microjoules". The reality will be "it depends". To give two obvious examples, adding two strings has a different cost from adding two integers (in terms of both time and power). A monomorphic load is much cheaper than a megamorphic load, loading a simple property has a different cost from having to walk the prototype chain and call a getter; optimization may be able to avoid the load entirely or it might not, depending on various kinds of surrounding circumstances.

Elixir and Haskell interoperability

As a platform for handling concurrent problems, Elixir/OTP seems to be the best suited solution.
When writing an application with a web interface, consider the case in which I want to reason about, and decouple, the application logic using another functional language - namely haskell (due to benefits like its advanced detection of errors at compile time, static typing, etc). I would then handle concurrency using GenServers, and attach a web interface using Phoenix.Channels.
Is this setup even possible using NIFs? Also, would true concurrency be maintained? I'm not sure that I'm following the correct line of reasoning here, but would a new haskell process be able to be spawned in line with GenServer demands, and would the two be able communicate efficiently?
This setup is certainly possible using NIFs and GHC's FFI with a small amount of boilerplate written in C. But NIFs are best used for short synchronous computations with no side effects and I get the feeling that that isn't what these operations are.
You'd probably be better off with C Nodes for the Haskell parts of the application. Most of the documentation you'll find for that will be for Erlang and not Elixir, but given Elixir's easy interop with Erlang, it should be pretty straight forward (someone's even written an example). Most of the hard work will be to do with writing a Haskell "C Node", for which a cursory glance at hackage and github turns up nothing.

VisualOcaml wanted to write a deminer (rather than using Ocaml's graphics library)

In Ocaml, is there easier ways to write a graphics-based toy programs like deminer (like the one that comes with Windows 95)? I find the only way is to start by scratch using Ocaml's graphics library. There must be better ways around?
There are bindings to the SDL library, that provides more features than Graphics.
There are actually several of them, and I'm not exactly sure which is best:
SdlCaml is a part of the [GLcaml] project
the OcamlSDL library
I think SdlCaml is more bare metal (probably partly automatically generated), and OCamlSDL is an older (but still occasionally updated) library with a larger user base.
Note however that Graphics is simple to use for a start, and you can still move to something more sophisticated later. If you run into speed-of-rendering issues, you have to use double buffering, as explained in the manual.

Other language (frameworks) where the event loop is exposed as a language construct?

At http://nodejs.org/#about it says the following:
"Node is similar in design to and
influenced by systems like Ruby's
Event Machine or Python's Twisted.
Node takes the event model a bit
further—it presents the event loop as
a language construct instead of as a
library."
Are there other frameworks or languages that likewise expose the event loop?
Tcl has had this capability all along (last 2 decades). See http://www.tcl.tk/about/netserver.html
This is not to say Tcl does -- or should do -- everything Javascript and/or node.js does. But it is a valid answer to the question as to what "other frameworks or languages ... likewise expose the event loop?"
To be honest, I don't think there is something that's comparable to Node.js at the moment.
Why? Well basically because of the fact that JavaScript was single threaded from the start off, this made the language evolve in what it is today, a language that's perfectly fit for asynchronous programming, like you do it in Node.js.
Functions being first class objects, as well as having closures is a must if you want a Node like experience. For example you could just as well wrap plain C around the event lib and use that. But how much fun would that be? Even with twisted, you don't get even near the Node.js experience.
Second point is that Node.js has - except for the sync functions of the fs modules - no blocking functions, so while you can certainly do this style of programming in Python, you never know for sure if that library call isn't going to block your whole program. And kill the throughput of your server.
Also Node is fast, like in REALLY fast. V8 is definitely way ahead of Python and Ruby, yes you can write C-Extensions for both, but you can just as well do that for Node.js. Another plus point of using V8, Google is investing a ton of time/money into that Engine, another up to 2x improvement is already on the way with Crankshaft.
Node.js has more plus points, it's a complete framework (while Twisted is mainly async networking) and it's JavaScript.
The latter one may sound stupid, but the ability to re-use code and not having to do context switching , as well as being able to use mature frameworks for DOM manipulation (well, that is as soon as jsom gets into a more stable state) is another killer feature.
If you haven't done yet, I recommend you watch a couple of the talks listed on our Tag Wiki.
Especially the YUI one shows what possibilities await us in the near future.
So to sum it all up:
Although there are quite some frameworks out there that have an event loop, just having the loop itself won't give you the same experience as Node.js, so you should not expect a comparable experience when doing stuff in C or Java for example.
For the java platform I guess you could compare netty to node.js

Node.js for lua?

I've been playing around with node.js (nodejs) for the past few day and it is fantastic. As far as I can tell, lua doesn't have a similar integration of libev and libio which let's one avoid almost any blocking calls and interact with the network and the filesystem in an asynchronous manner.
I'm slowly porting my java implementation to nodejs, but I'm shocked that luajit is much faster than v8 JavaScript AND uses far less memory!
I imagine writing my server in such an environment (very fast and responsive, very low memory usage, very expressive) will improve my project immensly.
Being new to lua, I'm just not sure if such a thing exists. I'll appreciate any pointers.
Thanks
A recent corresponding project is Luvit "(Lua + libUV + jIT = pure awesomesauce)".
From the announcement:
this is basically luajit2 + libuv (the event loop library behind
nodejs). It compiles as a single executable just like nodejs and can
run .lua files. What makes it different from the stock luajit
distribution is it has several built-in modules added and some
slightly different semantics.
Notice that we're not running as a CGI script to apache or anything
like that. The lua script is the http server. You get your
callback called every time an http request is made to the server.
Looks like the following is exactly what I was looking for:
LuaNode https://github.com/ignacio/LuaNode
See lualibevent and lua-ev and also Lua Gem #27
You might also have a look at luv:
https://github.com/richardhundt/luv
from the lua mailing list:
How does luv relate to Luvit - LuaJIT + libuv (Node.js:s/JavaScript/Lua/)?
It doesn't really. Luvit borrows heavily from node.js's architecture
(reactor callbacks, etc.), links statically against luajit, provides
it's own module system and executable. Luv is just a Lua module which
binds to libuv. The key difference is that Luv is more like an m-n
threading engine combining coroutines and OS threads while using the
libuv event loop under the hood.
So other than the fact that they both bind to libuv, they don't have
much in common.
You might want to take a look at Luvit or a gander at the Lua Github site. I think it takes the approach of implementing Node.js functionality right inside Lua. You write Lua code on the client side and on the server side. Here is a description of Luvit approach to doing Node.js functionality in Lua.
if i understood the question right, take a look at http://openresty.com/
luvit aims to be to Lua exactly what Node.js is to Javascript. Definitely a promising project.
You can get node.js style non-blocking IO with lua-handlers.
It even has an async. HTTP Client, which makes it really easy to start parallel HTTP requests. See the test_http_client.lua file as a example of the HTTP client interface.
You should also check out Lapis. It's a very lightweight and fast framework for OpenResty: http://leafo.net/lapis/
I've really been enjoying it and predict it will have a bright future!
As you would expect with anything built to leverage OpenResty, it's benchmarks are insanely good: https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=query
The author of Lapis also wrote a CoffeeScript-like language for Lua called MoonScript which is quite nice:
http://moonscript.org/

Resources