FabricPaul

7 ms·

31.
by FabricPaul 15y ago
I've had a few email/tweet exchanges regarding KL, so I thought it would be useful to clarify a few things: - KL is a language with a syntax that is very close to Javascript. It borrows syntax from JavaScript, but not the rules of the langu
32.
by FabricPaul 15y ago
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
33.
by FabricPaul 15y ago
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
34.
by FabricPaul 15y ago
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 an
35.
by FabricPaul 15y ago
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
36.
by FabricPaul 15y ago
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
37.
by FabricPaul 15y ago
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,
38.
by FabricPaul 15y ago
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 type
39.
by FabricPaul 15y ago
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
40.
by FabricPaul 15y ago
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
41.
by FabricPaul 15y ago
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 oth
42.
by FabricPaul 15y ago
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 cal
43.
by FabricPaul 15y ago
p.s. you can see our sample client-side apps here: http://vimeo.com/groups/fabric/videos and play with them at http://demos.fabric-engine.com You can how we've extended Fabric to include existing C++ libraries - great for custom data ty
44.
by FabricPaul 15y ago
This is our first 'proper' benchmark - we are going to work on some other problems for comparison. We're getting impressive results with semantic analysis, so we'll publish some results there soon. Fabric is most impressive when problems le
45.
by FabricPaul 15y ago
Hi there - it depends on who you're targeting. Our client-side focus is on native developers looking for high-performance in web applications e.g. medical visualization http://vimeo.com/31970502 - the benefits of web applications are grea
46.
by FabricPaul 15y ago
This is accurate - our intent is to do the same thing with Ruby and Django. We are doing additional work on the server side so that it makes more sense to work with node. We picked node as a first target because we were already using it for
47.
by FabricPaul 15y ago
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
48.
by FabricPaul 15y ago
Hi there - not yet. We are going to start the alpha release very soon though. You can play with the client-side stuff though - it's essentially the same system. If you sign up to the newsletter you will get notification when we drop the FE
49.
Nodejs+Fabric as fast as multi-threaded C++(fabric-engine.com)
102 points by FabricPaul 15y ago|66 comments