Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

fabric-engine.com

Post reply on HN
Print view View original

41–50 of 68 posts

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

#41

Post by azakai »

FabricPaul wrote: post #33
mmaunder wrote: post #32

Earlier quoted context omitted.

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 in…

> That way people will have completely portable code.

Makes sense about portability, but what is your security model? Are you using static analysis, sandboxing like NaCl, or something else?

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

#42

Post by FabricPaul »

almost wrote: post #40
FabricPaul wrote: post #23

Earlier quoted context omitted.

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

Closures break the high-performance part of things. If we could have just used JavaScript, we would have done so - KL is as close to JavaScript as we can get, and still offer native, multi-threaded performance. If we introduce inferred types, then the only difference will be 'no closures'.

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

#43

Post by spullara »

Porting the C++ code directly to Java:

macpro:ValueAtRisk sam$ time java -cp . VarMT

VaR = -43.7173372179254300

real 0m36.863s user 4m48.944s sys 0m0.978s

macpro:ValueAtRisk sam$ time ./var-mt

VaR = -43.7173372179254329

real 0m27.048s user 3m33.971s sys 0m0.145s

Pretty good showing for such a low level benchmark.

https://github.com/spullara/Benchmarks/blob/master/Server/Va...

It would be moderately interesting to see how well this benchmark would do in OpenCL or the like.

(Benchmarks ran on a 3.33 GHz, 6-core MacPro, JDK 7 Developer Preview)

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

#44

Post by FabricPaul »

azakai wrote: post #41
FabricPaul wrote: post #33

Earlier quoted context omitted.

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 in…

> That way people will have completely portable code. Makes sense about portability, but what is your security model? Are you using static analysis, sandboxing like NaCl, or something else?

It's actually a reason why we went down the 'create your own language for operators' path - we originally wrote our operators in C++, but when we shifted to the browser it was clear that wasn't going to go well :) We looked at sand-boxing, but given how long the NaCl guys took to get it working, we really didn't want to take that on as a start-up. We also wanted something that a web developer would be comfortable working with - so we looked at JS and decided we could create a variant for performance.

We don't give pointers, and we do things client-side like guarded arrays (not necessary on the server). Memory management is handled by the core. I will get our guys to put a post up that covers KL in more detail - security was a major consideration for us.

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

#45

Post by FabricPaul »

spullara wrote: post #43

Porting the C++ code directly to Java: macpro:ValueAtRisk sam$ time java -cp . VarMT VaR = -43.7173372179254300 real 0m36.863s user 4m48.944s sys 0m0.978s macpro:ValueAtRisk sam$ time ./var-mt VaR = -43.7173372179254329 real 0m27.048s user 3m33.971s sys 0m0.145s Pretty good showing for such a low level benchmark. https://github.com/spullara/Benchmarks/blob/master/Server/Va... It would be moderately interesting to see…

cool :) Thanks for doing that - we can merge in at later date and include Java results.

We expose OpenCL in Fabric as an extension, as we wanted to be able to target heterogeneous hardware architectures. We didn't use this for benchmarking as we wanted to show CPU performance first. For clarity - KL does not compile down to OpenCL, you have to write for the GPU explicitly.

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

#46

Post by fleitz »

itsnotvalid wrote: post #20
allertonm wrote: post #5

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…

That's incorrect. Objects aren't objects, in imperative languages their largely syntactic sugar for passing struct as a this pointer, and providing a vtable. They don't actually implement many of the ideas from OO theory such as sending messages to objects.

Look at a language OCaml which can consistently beat C or C++ which also frequently beats C.

Most of the reason why C is fast is because it mirrors the hardware so closely allowing people to write reasonably optimized portable assembler, C falls down on macro optimizations such as inlining function pointers that are available to higher level languages such as OCaml. Sometimes the marco and runtime optimizations are far more important than the micro optimizations.

You don't need static typing or lack of object support to write fast code. OCaml beats C providing both inferred typing and object support.

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

#47

Post by azakai »

FabricPaul wrote: post #44
azakai wrote: post #41

Earlier quoted context omitted.

> That way people will have completely portable code. Makes sense about portability, but what is your security model? Are you using static analysis, sandboxing like NaCl, or something else?

It's actually a reason why we went down the 'create your own language for operators' path - we originally wrote our operators in C++, but when we shifted to the browser it was clear that wasn't going to go well :) We looked at sand-boxing, but given how long the NaCl guys took to get it working, we really didn't want to take that on as a start-up. We also wanted something that a web developer would be comfortable wor…

Interesting, thanks. Looking forward to that post.

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

#48

Post by FabricPaul »

azakai wrote: post #47
FabricPaul wrote: post #44

Earlier quoted context omitted.

It's actually a reason why we went down the 'create your own language for operators' path - we originally wrote our operators in C++, but when we shifted to the browser it was clear that wasn't going to go well :) We looked at sand-boxing, but given how long the NaCl guys took to get it working, we really didn't want to take that on as a start-up. We also wanted something that a web developer would be comfortable wor…

Interesting, thanks. Looking forward to that post.

I linked this elsewhere on the thread, but you might find it interesting in the meantime: http://fabric-engine.com/2011/10/couldnt-you-just-use-javasc...

There are more details on KL, and the reasoning why we didn't use JavaScript

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

#49

Post by sausagefeet »

fleitz wrote: post #46
itsnotvalid wrote: post #20

Earlier quoted context omitted.

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…

That's incorrect. Objects aren't objects, in imperative languages their largely syntactic sugar for passing struct as a this pointer, and providing a vtable. They don't actually implement many of the ideas from OO theory such as sending messages to objects. Look at a language OCaml which can consistently beat C or C++ which also frequently beats C. Most of the reason why C is fast is because it mirrors the hardware s…

Have a link to benchmarks where Ocaml beats C? In my experience Ocaml is usually only about 2x slower than C, but never beating it. Also, Ocaml is statically typed. Type inference is just inferring the static types.

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

#50

Post by azakai »

FabricPaul wrote: post #48
azakai wrote: post #47

Earlier quoted context omitted.

Interesting, thanks. Looking forward to that post.

I linked this elsewhere on the thread, but you might find it interesting in the meantime: http://fabric-engine.com/2011/10/couldnt-you-just-use-javasc... There are more details on KL, and the reasoning why we didn't use JavaScript

Thanks, that was interesting.

While I have you here :) , can you please elaborate on your Bullet/Fabric demo? Specifically, how did you get the Bullet C++ code to run on the Fabric Engine? (Since that doesn't use C++?)

Post reply on HN