[tptacek]

It feels likely that the fundamental problem facing JS programs competing with the entire solution space available to C programs --- apart from the nerd who will implement an equivalently fast JIT compiler to run the JS on just to make a point --- is that C code has much better control over the layout of data in memory. You can work around the GC issues and modern compilers work around the interpretation overhead, but a C program is going to tend to have the easiest time ensuring that its working set fits into cache.

Of course, the real problem here is that he's comparing his JS code to a random blob of C code that just happens to be part of the MySQL package. Is the MySQL client library famously performant?

[pcwalton]

C-like control over the layout of data in memory is provided by the Binary Data proposal for ECMAScript: http://wiki.ecmascript.org/doku.php?id=harmony:binary_data&#...

I think the GC issues and codegen are the most difficult, actually. When the GC bites you you rarely have any other choice than to use free lists, which are always a pain. Furthermore, JS codegen is always complicated by the fact that JS is a JIT, and so many optimizations commonplace in C compilers tend to be skipped in the name of faster compilation. (You would be amazed how many of the common JS benchmarks end up boiling down to compilation speed.)

Despite all of this, however, I'm bullish on the future of JS with respect to performance; it may lose on head-to-head competition with C, but modern JS performance is perfectly adequate even for 3D games and the like.

(Also interestingly, Emscripten works around all of these difficulties surprisingly well -- you get low-level control over memory with it; you never GC; you get LLVM's optimizations.)

[hythloday]

modern JS performance is perfectly adequate even for 3D games and the like

You can certainly write a 3d engine in JS, and it won't be laughably slow, but the idea that you're going to see any AAA games in the next 5 years written with any more JS than the usual Scaleform is extremely unlikely.

[_delirium]

I don't think there will be a wholesale replacement of AAA game engines with JS-based engines, but I do think JS-based engines will encroach more and more on AAA territory from the bottom up, as the visual-fidelity differences between AAA games and web/mobile/etc. games narrow. I know of at least one AAA-level game company that's working in-house on a WebGL-based game engine to hedge their bets, and currently debating what should be deployed on that platform. I would guess others are looking into it as well.

[SoftwareMaven]

I agree with you. If getting every bit of performance out of your hardware is important to you, C (possibly with inlined assembly) is the way to go.

I am so happy that I've never had to do that in my career.

[tptacek]

Are you being sarcastic? Because wringing performance out of a known-working piece of C code is a pretty fun problem.

[SoftwareMaven]

I'm not being sarcastic. I can see how it could be fun (in a particularly zen-coder way, in fact), except almost every performance issue I've had to deal with has shown itself in production, needing a fix yesterday.

[sliverstorm]

The difference, as best I can tell, is mixed C-assembly code is generally built for performance from the very start, so it isn't all performance bugfixes for production code.

[DeepDuh]

That being said, Fortran is being used equally often, if not more often, in HPC applications. The reason being that modern Fortran both gives you bare bone access to the memory structures and offers array slicing notation as well as good multidimensional arrays for HPC. (C multidimensional arrays usually don't offer optimal performance, leading to the pointer arithmetic notation).

It's still an ugly language though. I've yet to find a C language extension that gives you the higher level features of Fortran however - and even then it would have to be an industry standard to be supported by the wealth of HPC compilers out there - remember it's not only x86, you also have GPUs, Itanium, PPC.. Looking forward to a world where LLVM actually gives the performance people need in that field, because architecture wise this could turn out to be a silver bullet.

[alexchamberlain]

The main reason Fortran is used is that medieval professors can't be bothered to learn C. There are less assumptions about pointers in Fortran - which means it can be parallelised more easily - but you can work round that in C.

[ams6110]

Fortran is not exactly a general purpose language though, it's specifically designed for the sorts of problems that scientific and HPC tends to deal with, and it's probably rare especially nowadays to see it used anywhere else. I'm guessing there aren't any web frameworks written in Fortran (though I'm sure someone will now point one out....)

[DeepDuh]

Web development with Fortran. Shudder. (String handling is abysmal in Fortran so I wouldn't wish that to my worst enemy).

No, but my parent was talking about deep code optimizations being almost exclusively being done in C. I'd say HPC is a significant market for code optimization, so I wanted to point out that Fortran is kind of the industry standard there.

[evoxed]

If I'm trapped on a desert island with (somehow) my MacBook and a solar charger, this will definitely be the first project I take one...

[wglb]

Well, it might surprise you to know that the first serious optimizing was written in fortran. In my book, compilers trump frameworks for generality.

[wglb]

I found it fun. I had to handle the stock options feed at a very high rate and do a binomial calculation to get the implied volatility on every tick.

[vidarh]

Last time I looked at the MySQL client library, which is admittedly a few years ago, I was horrified to find it wasted a tremendous amount of time doing tiny read()'s instead of reading into larger buffers and splitting things up client side - the former causes ridiculous extra latency due to the extra context switches - , so I'd not be the least bit surprised if it is still slow.

In fact, if the tiny reads are still there in the MySQL C client, that in itself might explain the difference.

[specialist]

> C code has much better control over the layout of data in memory.

Yes. This presentation really drives that point in.

Building Memory-Efficient Java Applications: Practices and Challenges http://www.cs.virginia.edu/kim/publicity/pldi09tutorials/mem...

(There are plenty of other sources too.)

Our Java study group tackled this paper. To prepare for the discussion, I tried to put my XML document object model implementation on a diet. Super fun. Modest benefits.

> You can work around the GC issues and modern compilers work around > the interpretation overhead, but a C program is going to tend to > have the easiest time ensuring that its working set fits into cache.

As I understand it (h/t Joe Bowbeer), Doug Lea and others have been doing very cool work micro tuning data structures suitable for use on multicore systems. So it's possible. But definitely not trivial; certainly beyond my abilities.