Fabric Engine: JavaScript as fast as C++

http://www.h-online.com/open/news/item/Fabric-Engine-brings-JavaScript-to-C-level-1497983.html

by jk4930 • 14 years ago

77 45 14 years ago

tlack• 14 years ago

Anyone out there done a deep dive into this one? What's the catch?

udp• 14 years ago

> The engine works by allowing developers to use special interfaces and a high-performance scripting language called KL for performance critical parts of the code

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.

cglace• 14 years ago

So its like a cython for javascript?

ramy_d• 14 years ago

i'm seeing this page from their site: http://documentation.fabric-engine.com/latest/FabricEngine-K...

the KL language looks statically typed at a glance. So what's the advantage exactly?

binarycrusader• 14 years ago

This seems like a non-starter to me:

  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.

Personally, I'd say "screw it", and use V8.

jiaaro• 14 years ago

you can use it on the server with nodejs - it's like a c extension, but I guess it's supposed to be easier than writing a c extension

anonymoushn2• 14 years ago

AGPL is a bit bothersome. I'd rather be able to release my code under a non-viral license.

FabricPaul21• 14 years ago

for reference, we posted our beta benchmark stuff here and people had a good look at us: http://news.ycombinator.com/item?id=3227905

anonymoushn2• 14 years ago

This isn't JavaScript being as fast as C++, it's writing critical sections in a low-level language being as good as writing the whole app in a low-level language.

FabricPaul21• 14 years ago

agreed - I was pulled up on this here last year when we published our benchmarks :) The other thing to remember is the low-level language we use sets a lower bar to entry than say C - the benefit of designing for a specific set of goals (ease of use, performance and security). That said, if you're familiar with C or JavaScript, then KL will be very familiar.

codedivine• 14 years ago

You should do an introductory article for technical audiences yourself perhaps. Or maybe you already have one?

stcredzero• 14 years ago

If this is well designed, I see this as very useful. If the barrier is lower than callouts to a C library or using cython, and if it's designed in a way to make it easier to write correct critical section code, then this encourages the "right" way to program. (Where right is any area of development where building quickly in a high level language, then optimizing later is one of the better ways to go.)

pdehaan• 14 years ago

   Fabric Engine has released version 1.0 of its platform for multi-threaded optimised execution of scripting languages.

Kind of cool, if somewhat misleading. The way that's written seems to imply it speeds up the scripting language itself, but reading further it seems to just be a lower level language that's easy to use from within those scripting languages. Using an FFI to speed things up is nothing new, but making it easier is always nice.

FabricPaul21• 14 years ago

The 'new' part relates to using LLVM to do the compilation on target - this actually makes a big difference in workflow, and is also much more familiar to people used to developing with dynamic languages. It also opens up some cool possibilities around scaling of computation...

FabricPaul21• 14 years ago

p.s. I meant to say - yes, it is misleading. We are most definitely not an automagical interpreter :)

Amadiro3• 14 years ago

Reality check:

[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"

FabricPaul21• 14 years ago

lol :) Read this older HN thread - http://news.ycombinator.com/item?id=3227905 - a few people took our code and tried to make it faster in C/C++ and Java.

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 ;)

FabricPaul21• 14 years ago

p.s. Fabric Engine 2.0 has a flux capacitor

Amadiro3• 14 years ago

I'm mainly referring to the article here, which is rather ambiguous and mis-stated in its wording, as well as the submission title, which is entirely missing the point of what Fabric does. I don't doubt that you have more in-depth information on your site, or that, for that matter, using Fabric from your scripting-language of choice can actually speed up your code (considering things like Cython have existed for a while.)

kodablah• 14 years ago

I understand the need for AGPL so this can be monetized, but I really wish there was a price on the commercial licensing page instead of just requiring me to contact y'all. Why do I have to "request licensing information", why can't it be made publicly visible?

FabricPaul21• 14 years ago

You're right - it should be publicly visible. We're working on it - it will be updated and public in the next week. We'll be offering subscription pricing - so initially it will be a monthly that allows you to run x number of instances.

cromwellian• 14 years ago

Interesting, but why the KL DSL? It seems you could have either used something like OpenCL, or, went with a language like Go, Dart, of haxe.

FabricPaul21• 14 years ago

OpenCL/CUDA are GPGPU programming languages - that's something we're getting to soon :) We previously exposed OpenCL as an extension, but took it out because it's a nightmare to support. We're looking at it again at the moment - it's pretty challenging to write GPU code, so it's hard to see how much benefit developers will get from it until we can target nicely from KL. One for the longer term :)

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' :)

FabricPaul21• 14 years ago

we wrote this piece last year - it's focused more on why JS isn't enough, but there's some useful info about KL in there. http://fabricengine.com/2011/10/couldnt-you-just-use-javascr...

Fabric Engine: JavaScript as fast as C++

Related Stories