Fabric Engine: JavaScript as fast as C++
h-online.com
h-online.com
[x] Claims to support a multitude of languages with wildly varying semantics while still achieving some goal that seems unrealistic (or thus-far un-achieved) even for a single one
[x] Claims to achieve performance similar to C/C++/fortran/some other traditionally-considered-fast language
[x] Claims that some traditionally-considered-hard-to-do-task will now become easy
[x] Uses buzzwords like "in the cloud"
[x] Shows meaningless benchmarks without context, code or an in-depth look at the actual bottlenecks of the benchmarked code, suggesting the particular solution by far exceeds all the competitors
[ ] Extensive usage of the words "flux capacitor" or "Gigawatts"
We made our benchmark code available: (https://github.com/fabric-engine/Benchmarks/tree/master/Serv...)
If you have a standalone module for the high-performance, then of course you can bind it to different languages. We're not interpreting the dynamic language, so therefore semantic differences between languages aren't a major factor.
If you think about what we're doing, it isn't surprising that we'd hit that kind of performance - after all, we're asking the developer for a concurrency-friendly description, then taking their operator code (which is strongly typed) and compiling it on target. It's more about the dynamic compilation that LLVM enables, and the ease of access for regular developers.
It runs on instances - how do you describe that other than to say 'in the cloud'?
The benchmarks are properly presented and explained: http://fabricengine.com/technology/benchmarks/
I understand the skepticism, but we have been open with our data and the code we used for our benchmarks. We're not claiming to go faster than light here ;)
Fabric Engine has released version 1.0 of its platform for multi-threaded optimised execution of scripting languages.
I haven't looked into it, but this suggests it's not actually JavaScript (as the title implies) but rather some new language that gets the speed boost.
There are also some parallel features:
The combination of task based parallelism, and data based parallelism, orchestrated using a dependency graph, enable our scheduler to very efficiently manage the CPU(and in the GPU in the future).
This model is used in high end video game engines today to leverage multi-core CPUs effectively. We make this programming model available in Python and JavaScript.
http://s09.idav.ucdavis.edu/talks/04-JAndersson-ParallelFros...
A single call from Python/JavaScript can kick off hundreds of tasks (written in KL) to be scheduled and executed.
Neither does Cython.
> Fabric is basically a high-performance threading engine that you can call from your dynamic language
Well Cython is for writing Python modules, so it's integrated with Python only. But that's pretty much it.
> the key element is that the operator code (KL) enables the high-performance. This KL is only required for the operators, and is not as difficult or complex as C/C++ to use - it's designed purely for this task.
So's Cython. Cython compile to a native module, that native module is simply imported and used from regular Python code.
> A regular Python or JavaScript developer can pick it up.
A regular Python developer really shouldn't have any trouble picking up cython.
Fabric is for software developers who need to build high performance software, and also use dynamic languages.
V8 will continue to speed up, and may even get close to the speed of native code. But in that time, CPUs architectures will continue to gain more cores, widening the gap between multi-threaded code, and dynamic code.
the KL language looks statically typed at a glance. So what's the advantage exactly?
NACL, which is only somewhat similar in that it runs native code via the browser, went to great lengths to demonstrate how their sandboxing worked to address the FUD of running native code in the browser. I have a very similar FUD about executing Fabric LLVM code from arbitrary websites.
To clarify where I'm coming from, I am a javascript / ruby dev and although I have worked in C I do not claim to understand the inner workings of LLVM or have ever worked with it. If there is an implicit reason why building on LLVM would sandbox code written in fabric it is not implicit to me. I doubt I am alone in this and would greatly appreciate an explanation of Fabric's sandboxing.
By being pointer-less, we block a lot of potential malicious code. If you don't have access to memory, it's hard to write anything dangerous. Our bigger concern with the plug-in is around our extension system - it allows us to include existing libraries, which of course means it's opening up to C/C++. Consequently, we force explicit install of extensions - if a developer builds a custom extensions, then the end user has to install it, the same as if you were choosing to install a local application.
When Fabric is run from the command line, we are in general unconcerned with security. This is because Fabric is run like any other program on a computer where the software is deliberately installed by the user. Fabric runs as a module for Node.js or for Python, and runs with the same security credentials as Node.js and Python. Like Node.js and Python, Fabric will only do what you explicitly tell it to. Let us be clear: this is the context in which you might use Fabric for server-side work, much as one does with Node.js, Python or Ruby.
When Fabric is run as a browser plugin, security is a major concern because a Fabric application (or, more precisely, an in-broswer application that wants to use the computer the browser is running on to run code) specifies code that is compiled and executed on the machine running the browser. To prevent the usual types of exploits, the language KL in which the Fabric operator code is written is both pointer-free (like Ruby, Javascript and Python) and provides bounds checks for all array accesses, throwing an exception for any out-of-bounds accesses (like Ruby and Python). Access to third-party code, which does not adhere to the same pointer-free and bounds-checked rules, is done through our extension mechanism, and extensions, besides the default extensions provided with Fabric (that are just wrappers for common open-source libraries), must be explicitly installed by the user -- it is not possible to make the user's browser automatically "download" an extension.
Of course, you are wise to question whether you can "trust" our security model. Fortunately, if you're really in doubt, you can simply look at our code, which is open-source; we believe this already places us ahead of common browser plugins, such as Flash, to which could be posed the same questions but for which one cannot audit the code.
The Fabric Engine core and language bindings are made
available as open source under the AGPL v3 license, with
commercial licensing options available on request and
paid-for support options for developers. Version 1.0 is
available to download from the company's site.
The rationale for creating KL was that we had some specific goals, and we couldn't find an existing language that did everything we wanted - the requirement of being high-performance _and_ easy to use was critical. We also had security concerns (we started out as a browser plug-in), so it also had to be pointerless. Given that we have a fairly narrow scope (writing high-performance operator code), we decided the best path was a DSL. If we didn't have the security concern, we would have stuck with C++ - but that wouldn't have had the lower bar to entry that KL has.
My co-founder who wrote KL still thinks we were crazy to do it - 'the world does not need another language' :)