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

61–68 of 68 posts

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

#61

Post by Locke1689 »

sausagefeet wrote: post #59
fleitz wrote: post #51

Earlier quoted context omitted.

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

This is correct. The most common algorithm used for type inference is Hindley-Milner (http://en.wikipedia.org/wiki/Hindley%E2%80%93Milner).

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

#62

Post by jamii »

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.

I've never seen Ocaml come even close to C in micro-benchmarks but in large applications it can win on macro-optimisations eg Deens is significantly faster than BIND with much less code (www.utdallas.edu/~hamlen/Slides/Melange.pdf)

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

#63

Post by FabricPaul »

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 language itself. Just like JavaScript borrows syntax from C, and OpenCL borrows from C.

- There are many things in Javascript we don't support.  Some things we don't currently support (eg. in-line initialization of arrays) but will probably support in the future; other things we probably won't support (eg. regular expressions as language objects) and finally there are things we will never support (ie. closures).

- There are nice features of KL that Javascript does not have, for instance arithmetic operator overloading.  These features are included because they are particularly useful for computational problems.

- KL is not JavaScript++ - It's designed for writing high-performance operator code, not to handle everything that JavaScript can do. We don't want to reinvent the wheel :)

We will work on a post to cover KL in more detail, including roadmap. You can email info at fabric-engine dot com if you have any questions you want to take offline.

Thanks, Paul

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

#64

Post by almost »

FabricPaul wrote: post #42
almost wrote: post #40

Earlier quoted context omitted.

> 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'.

That makes sense, I'm sure it is hard to optimize closures and untyped code. However, if you remove those you no longer have JavaScript so it is incorrect to say that you have made Javascript fast, you've just created a different language and made that fast. Of course if it plays nicely with Javascript that's cool, but please say that!

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

#65

Post by FabricPaul »

pjin wrote: post #21
VMG wrote: 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 ?

Fortran compilers (gcc has a Fortran 95 frontend) have long offered optimization levels beyond -O3; i.e., -O6 is a decent upper bound among popular free and commercial compilers, not just gcc/gfortran. The author probably came from a HPC background where -O6 is commonly used for compatibility among such a variety of compilers, even when writing C and C++ programs. Technically not the most portable way to build, but i…

I asked the engineer for a response: "For reference, I used -O6 because it's a historical convention (more of a joke, really) for "optimize the crap out of it". UNIX geeks have been using -O6 in this way for about 30 years."

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

#66

Post by FabricPaul »

almost wrote: post #64
FabricPaul wrote: post #42

Earlier quoted context omitted.

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'.

That makes sense, I'm sure it is hard to optimize closures and untyped code. However, if you remove those you no longer have JavaScript so it is incorrect to say that you have made Javascript fast, you've just created a different language and made that fast. Of course if it plays nicely with Javascript that's cool, but please say that!

I agree. I have made a separate post on this thread that calls this out.

Thanks -Paul

Post reply on HN