Live data from Hacker News

Nodejs+Fabric as fast as multi-threaded C++

fabric-engine.com

31–40 of 68 posts

Re: Nodejs+Fabric as fast as multi-threaded C++

#31

Not that it diminishes the interestingness of this post (quite the opposite), but it's worth noting that this is not achieved using plain-vanilla JavaScript. From the product page: "The high-performance parts of the application are written using a performance-specific extension to JavaScript, called KL (Kernel Language). This language is similar in scope and syntax to JavaScript, but has some key differences that opt…

Right... this would be a lot more interesting if they picked existing open source implementations and ran them unmodified. It's not like people can drop their unmodified software into this and make it scream like what V8 did to plain JavaScript performance.

There's a good reason for that - JavaScript is not a high-performance language. We wouldn't have had to author KL otherwise :) The high-performance parts of the application use a strongly-typed, procedural variant of JS (KL). There's no other way to deal with it.

It came up a lot in validation, so we wrote this: http://fabric-engine.com/2011/10/couldnt-you-just-use-javasc...

I hope that's helpful

Re: Nodejs+Fabric as fast as multi-threaded C++

#32

Earlier quoted context omitted.

Right... this would be a lot more interesting if they picked existing open source implementations and ran them unmodified. It's not like people can drop their unmodified software into this and make it scream like what V8 did to plain JavaScript performance.

There's a good reason for that - JavaScript is not a high-performance language. We wouldn't have had to author KL otherwise :) The high-performance parts of the application use a strongly-typed, procedural variant of JS (KL). There's no other way to deal with it. It came up a lot in validation, so we wrote this: http://fabric-engine.com/2011/10/couldnt-you-just-use-javasc... I hope that's helpful

Is KL open source? In other words, if I modify my JS apps to include KL, am I locked in to you as a vendor? Thanks, interesting post.

Re: Nodejs+Fabric as fast as multi-threaded C++

#33

Earlier quoted context omitted.

There's a good reason for that - JavaScript is not a high-performance language. We wouldn't have had to author KL otherwise :) The high-performance parts of the application use a strongly-typed, procedural variant of JS (KL). There's no other way to deal with it. It came up a lot in validation, so we wrote this: http://fabric-engine.com/2011/10/couldnt-you-just-use-javasc... I hope that's helpful

Is KL open source? In other words, if I modify my JS apps to include KL, am I locked in to you as a vendor? Thanks, interesting post.

Hi there - the engine itself is closed source, everything we build on top of it is open-sourced. So if someone built a competing engine that used KL (not sure why they would!), then you would be free to take your code wherever you liked.

If we move to type inference in the future, then the KL code will be JavaScript. Right now we declare types, but in the future we'd like to just throw a compiler error if we can't infer. That way people will have completely portable code.

Re: Nodejs+Fabric as fast as multi-threaded C++

#35

While this is interesting, not all CPUs are created equal. I can run the var-mt.cpp example on POWER hardware in: real 0m25.680s My point being, that node.js doesn't work on this box, nor does Fabric. So when developing specialized algorithms you sometimes might want to run them in specialized environments.

Right - we would have to build a version of the engine to run on that hardware. Once that's done though, the applications would run. i.e. we prototyped on ARM earlier this year, and our unit tests worked.

That said - if you're building for specialized environments, you're probably going to want to hand-optimize code rather than rely on LLVM to do it. LLVM does a pretty good job though :)

Re: Nodejs+Fabric as fast as multi-threaded C++

#36
post #17
post #14

Could probably squeeze a bit more out of the C++ version by targeting the specific architecture of the CPU to make use of SSE. Also, what floating point type is KL using? float or double? - and is double necessary? - converting the C++ code to use floats would probably provide a fair speedup on the divides and due to squeezing more data into cache lines...

Could probably squeeze a bit more out of the C++ version by targeting the specific architecture of the CPU to make use of SSE. Not only that, from browsing the code, the critical loop is likely matrix multiplication. If that's the case, any kind of engine who is smart about SSE, cache lines, etc is going to be able to outperform simple C/C++ code. Of course there's excellent matrix maths libraries for C/C++ that coul…

More than half of the running time seems to be taken up by the generation of normally-distributed random numbers. Sort of makes sense, I suppose, since that bit has a loop and a `sqrt' and a `log' in it.

The repeated calls to `exp' seem to take up some time too.

As for the matrix multiplication, that only happens on startup, so it's surely irrelevant. The bit that runs a lot just does matrix*vector. It is rather hard to make that cache-incoherent, as it just walks forwards through all inputs and outputs. In any event I would think that the program's entire working set will fit in L1.

I was merely fiddling with this out of interest, so I didn't spend ages SSE2ifying it. The VC++ x64 compiler doesn't do inline assembly language anyway. But if you halve the number of multiply-adds `multMatVec' does, under the assumption that this would make it twice as fast, and that twice as fast would be what an SSE2 implementation would be like, it makes no noticeable difference.

(I was fiddling with the single-threaded version, using Visual Studio 2010, compiling for x64.)

Re: Nodejs+Fabric as fast as multi-threaded C++

#38

Not that it diminishes the interestingness of this post (quite the opposite), but it's worth noting that this is not achieved using plain-vanilla JavaScript. From the product page: "The high-performance parts of the application are written using a performance-specific extension to JavaScript, called KL (Kernel Language). This language is similar in scope and syntax to JavaScript, but has some key differences that opt…

It is something that JavaScript can never solve: Objects are objects, there has to be some constructs to make them work so it would never be as fast as C code. The other blog post that appeared on HN this week sums it out [1]. For those who didn't read that post, basically, if you want the performance of C, you have to make those data as static and inflexible, i.e. use types and avoid indirection. Looking at the KL u…

Lua is imilar to JavaScript in that respect, and LuaJIT2 has effectively solved this problem for Lua. Code that's perfectly dynamic is almost on par with C, with variables switching type from int to double to string as needed. With essentially no restrictions on what you use.

JavaScript is more braindamaged in its dynamicness, so it's harder to write something like LuaJIT2 for JavaScript -- but it's not impossible.

Re: Nodejs+Fabric as fast as multi-threaded C++

#39
post #4

The C++ versions were compiled using gcc version 4.4.5 using the compiler flags “-O6 – lpthread”. Isn't -O6 the same as -O3 ?

Yes it was a very WTF moment for me as well. The "C++" code is pretty much straight C, with references being the only C++ feature being used.

It might look like C, but the last time I looked to the C++ standard that is also valid C++ code.

Re: Nodejs+Fabric as fast as multi-threaded C++

#40

Not that it diminishes the interestingness of this post (quite the opposite), but it's worth noting that this is not achieved using plain-vanilla JavaScript. From the product page: "The high-performance parts of the application are written using a performance-specific extension to JavaScript, called KL (Kernel Language). This language is similar in scope and syntax to JavaScript, but has some key differences that opt…

Hi there - yes, it's partly about marketing message. When we did early validation, people were concerned about a 'custom language' - the reality is that the majority of the application is written in JS - the performance parts are in KL. KL itself is almost identical to JS, but right now you have to declare types. In the future we may switch to inferred types, at which point code will be indistinguishable from JS. Jus…

> Just don't use closures :)

So very much not Javascript then

Post reply on HN