5 ms·

Fabric Engine: JavaScript as fast as C++

• tlack 15y ago
  Anyone out there done a deep dive into this one? What's the catch?
  • udp 15y 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 15y ago
      So its like a cython for javascript?
      • FabricPaul 15y ago
        not really - Fabric is integrated with dynamic languages, we 're not interpreting JS or Python (we work with both languages). Fabric is basically a high-performance threading engine that you can call from your dynamic language - 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. A regular Python or JavaScript developer can pick it up.
        • axiak 15y ago
          I think you've just described cython. A higher-than-c level language that trivially binds to the higher target language.
        • FabricPaul 15y ago
          Replying to comment below (can't see a reply button) - please correct me if I'm wrong, but I don't see anything about Cython handling multi-threading and I don't see anything about dynamic compilation on target. I just had a flick through their documentation, so if this stuff is in there then I missed it...
          • maxerickson 15y ago
            There is a cython mechanism for compiling code on demand (pyximport), but it is only transparent to the user, it isn't especially dynamic. There are also some parallel features: http://wiki.cython.org/enhancements/prange http://wiki.cython.org/enhancements/prange
            • phtaylor 15y ago
              Multi-threaded software development is a huge challenge facing software developers. The model we have taken enables massive amounts of computation to be distributed across all available cores. 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-ParallelFrostbite-Siggraph09.pdf 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.
        • masklinn 15y ago
          > Fabric is integrated with dynamic languages, we 're not interpreting JS or Python (we work with both languages). 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.
          • FabricPaul 15y ago
            as per my other comment: "please correct me if I'm wrong, but I don't see anything about Cython handling multi-threading and I don't see anything about dynamic compilation on target. I just had a flick through their documentation, so if this stuff is in there then I missed it..."
            • phtaylor 15y ago
              When we designed Fabric, our goal was not to speed up Python, or JavaScript. Our goal was to build high performance multi-threaded applications on top or dynamic languages. 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.
    • ramy_d 15y ago
      i'm seeing this page from their site: http://documentation.fabric-engine.com/latest/FabricEngine-KLProgrammingGuide.html#introduction http://documentation.fabric-engine.com/latest/FabricEngine-K... the KL language looks statically typed at a glance. So what's the advantage exactly?
      • FabricPaul 15y ago
        we dynamically compile on target (using LLVM), and the developer doesn't have to manage things like pointers.
        • alexchamberlain 15y ago
          What's wrong with pointers? I quite enjoy working with pointers - they are a very simple concept.
          • FabricPaul 15y ago
            Using pointers adds a certain amount of complexity, and they also introduce the possibility of security problems. This was particularly important for the work we were doing on the browser plug-in. For the type of work that developers use KL for, they aren't needed.
            • d1plo1d 15y ago
              On that topic, I wasn't able to find any information on the security of Fabric or the sandboxing it uses. Short of going through the source code is there documentation on this topic? 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.
  • binarycrusader 15y 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 15y 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
      • FabricPaul 15y ago
        Yes, this is correct - it's targeted at people who are comfortable using dynamic languages like JS/Python
    • anonymoushn 15y ago
      AGPL is a bit bothersome. I'd rather be able to release my code under a non-viral license.
      • FabricPaul 15y ago
        we offer commercial licensing that allows devs to bypass the AGPL requirements. I'll update the site info soon to show the subscription pricing options.
  • FabricPaul 15y 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 http://news.ycombinator.com/item?id=3227905
• anonymoushn 15y 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.
  • FabricPaul 15y 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 15y ago
      You should do an introductory article for technical audiences yourself perhaps. Or maybe you already have one?
      • FabricPaul 15y ago
        we did a lot of documentation work for launch - the overview is a good place to start: http://documentation.fabric-engine.com/latest/FabricEngine-Overview.html http://documentation.fabric-engine.com/latest/FabricEngine-O...
  • stcredzero 15y 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 15y 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.
  • FabricPaul 15y 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...
  • FabricPaul 15y ago
    p.s. I meant to say - yes, it is misleading. We are most definitely not an automagical interpreter :)
• Amadiro 15y 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"
  • FabricPaul 15y ago
    lol :) Read this older HN thread - http://news.ycombinator.com/item?id=3227905 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/Server 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/ 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 ;)
    • FabricPaul 15y ago
      p.s. Fabric Engine 2.0 has a flux capacitor
    • Amadiro 15y ago
• kodablah 15y 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?
  • FabricPaul 15y 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 15y 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.
  • FabricPaul 15y 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' :)
    • FabricPaul 15y 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-javascript-2/ http://fabricengine.com/2011/10/couldnt-you-just-use-javascr...