Hacker News Reader

Comment by itsnotvalid | Hacker News Reader

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 used in benchmark, you may find that it resembles C code. It's exactly what they did to make it fast: types and free from indirection.

[1]: http://blog.mrale.ph/post/12396216081/the-trap-of-the-perfor...

[2]: https://github.com/fabric-engine/Benchmarks/blob/master/Serv...

View on HN

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.

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.

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.

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

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

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)

Reply on news.ycombinator.com