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

51–60 of 68 posts

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

#51

Post by fleitz »

sausagefeet wrote: post #49
fleitz wrote: post #46

Earlier quoted context omitted.

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.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

http://flyingfrogblog.blogspot.com/2009/07/ocaml-vs-f-burrow...

You're right about OCaml generally being 1.5X slower than C but it does beat it for some problems which is impressive for all the additional features it provides. I must have been looking at the numbers wrong last time I checked.

Type inference is much different than static typing because it allows functions to be specialized at run/compile time which can result in having to write much less code.

For example, in C a map function would have to be written for every datatype (or lose the benefits of static typing by using a void*) where as in OCaml/F# you get type safety and specialized / inlined code for free.

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

#52

Post by FabricPaul »

azakai wrote: post #50
FabricPaul wrote: post #48

Earlier quoted context omitted.

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++?)

Sure - we designed Fabric to be extendable, so it can include existing c++ libraries. So we just integrated the Bullet SDK. http://fabric-engine.com/2011/11/building-extensions-on-wind... covers the extension model in detail.

Does that answer your question properly? I can get more info if needed.

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

#53

Post by azakai »

FabricPaul wrote: post #52
azakai wrote: post #50

Earlier quoted context omitted.

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++?)

Sure - we designed Fabric to be extendable, so it can include existing c++ libraries. So we just integrated the Bullet SDK. http://fabric-engine.com/2011/11/building-extensions-on-wind... covers the extension model in detail. Does that answer your question properly? I can get more info if needed.

Thanks, that does answer my question.

I asked because I work on compiling C++ into JavaScript, and I was curious if your technology included something to compile C++ into KL.

I assume integrating existing C++ libraries to Fabric Engine has no security model, then?

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

#54

Post by FabricPaul »

azakai wrote: post #53
FabricPaul wrote: post #52

Earlier quoted context omitted.

Sure - we designed Fabric to be extendable, so it can include existing c++ libraries. So we just integrated the Bullet SDK. http://fabric-engine.com/2011/11/building-extensions-on-wind... covers the extension model in detail. Does that answer your question properly? I can get more info if needed.

Thanks, that does answer my question. I asked because I work on compiling C++ into JavaScript, and I was curious if your technology included something to compile C++ into KL. I assume integrating existing C++ libraries to Fabric Engine has no security model, then?

Right - they have to be 'trusted', much like a plugin. People will have to explicitly choose to install them. Right now we bundle them all in he plugin, but that's just until we write the manager

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

#55

Post by azakai »

FabricPaul wrote: post #54
azakai wrote: post #53

Earlier quoted context omitted.

Thanks, that does answer my question. I asked because I work on compiling C++ into JavaScript, and I was curious if your technology included something to compile C++ into KL. I assume integrating existing C++ libraries to Fabric Engine has no security model, then?

Right - they have to be 'trusted', much like a plugin. People will have to explicitly choose to install them. Right now we bundle them all in he plugin, but that's just until we write the manager

Makes sense, thanks again for all the replies.

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

#56

Post by spullara »

Srirangan wrote: post #2

Extremely interesting. Since we're bench marking it with C++, is it safe to assume it performs much better than the JVM?

Yes, I ported it and though the JVM performed well, it is beaten by the optimizing C++ compiler.

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

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

#57

Post by feralchimp »

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…

This is all new to me so perhaps I'm misinterpreting it completely...but if Fabric works by analyzing program/data flow to automatically add parallelism, what's stopping it from being applied to a single-threaded C or C++ implementation and raising its performance to the level of the multithreaded-by-hand C++ implementation?

With all respect for the developers' showcase involving a bridge to Javascript, my gut sense is that the world would pay (more) money for a tool that takes single-threaded C code and makes it run like multi-threaded C code.

Also wondering how much of the underlying technology is patented, or if this is an implementation of publicly-accessible (and cheap/free licensable) academic research.

Finally, thanks to FabricPaul for very informative comments in this thread.

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

#58

Post by foobarbazetc »

FabricPaul wrote: post #29
tantalor wrote: post #28

Is Fabric Engine commercial software? If so, the authors of this post ought to disclose their interests as the owners.

Hi there - apologies. Fabric is a commercial company. Fabric Engine will be free for non-commercial use - we're currently in beta so pricing is not yet finalized. I assumed the username 'FabricPaul' was a good indication, but thanks for calling it out.

"free for non-commercial use" == commercial.

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

#59

Post by sausagefeet »

fleitz wrote: post #51
sausagefeet wrote: post #49

Earlier quoted context omitted.

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.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all... http://flyingfrogblog.blogspot.com/2009/07/ocaml-vs-f-burrow... You're right about OCaml generally being 1.5X slower than C but it does beat it for some problems which is impressive for all the additional features it provides. I must have been looking at the numbers wrong last time I checked. Type inference is much different than static typing because it…

> Type inference is much different than static typing because it allows functions to be specialized at run/compile time which can result in having to write much less code.

You are confused, type inference is purely about determining what type something is. It can determine a function is polymorphic but this has nothing to do with how the polymorphism is implemented. AFAIK Ocaml (by that I mean the INRIA Ocaml implementation) doesn't specialize polymorphic functions at all. Types are boxed and the boxes are all the same size so a single function definition is all that is needed for a polymorphic function or type. .net does do these things but, again, that has nothing to do with type inference. There is no difference between me specifying a function has type 'a -> 'b and the compiler inferring that.

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

#60

Post by FabricPaul »

feralchimp wrote: post #57
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…

This is all new to me so perhaps I'm misinterpreting it completely...but if Fabric works by analyzing program/data flow to automatically add parallelism, what's stopping it from being applied to a single-threaded C or C++ implementation and raising its performance to the level of the multithreaded-by-hand C++ implementation? With all respect for the developers' showcase involving a bridge to Javascript, my gut sense…

Hi - the parallelism is derived from the dependency graph, which provides task and data based (SIMD) parallelism. So, if you describe a bad graph, then you'll get limited concurrency. The performance you get is directly related to how well you can describe concurrency in your graph.

Dependency graphs aren't new - Intel TBB recently introduced a dependency graph model, and it's a well known approach. So if you're looking for a tool for making it easier to run concurrent C++, TBB is a great option.

Companies have tried the 'analyze code and work out how to multi-thread it' approach with limited success - it's pretty hard to do that in a dependable manner. Often you see horrible code snippets being inserted as flags etc - which very quickly gets messy and intrusive. It's a lot easier to describe the parallelism at a high level and let the engine handle it from there.

Our view is that bringing this kind of performance to dynamic languages is a big opportunity. Our reasoning: - Modern hardware requires developers to write concurrent applications - the days of one big core are long gone. This is hard. - Dynamic languages are flexible, easy to work with and fast to iterate. They're also very slow compared to native code, let alone multi-threaded code. - There are a lot of people that know dynamic languages that can't, won't or don't want to work with compiled languages.

That said - Fabric will be free for non-commercial use (students, researchers etc). We open-source everything we build on top of the core engine - all of the extensions, 3D scene graph, rendering etc.

As for patenting - we've filed around some of the client-side stuff (I can't disclose details just yet - sorry). Most of the ideas that went into Fabric are not original - it's really how we've combined them to offer something that's (hopefully) compelling. We were very lucky to come at this problem when there was a perfect convergence of technologies - particularly JavaScript, HTML5 and LLVM.

Apologies for the ramble - been a long (but gratifying) day :)

Post reply on HN