Hacker News Reader

Comment by taylodl | Hacker News Reader

The paragraph beginning with "To put it another way, C is no longer close to the real machine" really drove the point home. The further C gets away from the real machine then the less useful C will become. Higher-level languages have the advantage that a compiler can more easily determine what the program is attempting to accomplish and optimize the result for a specified architecture. This will be very difficult to do for C. As a result I would expect the performance of higher-level languages to start exceeding the performance of C. I guess we're just going to have to change our conventional wisdom when that time comes.

View on HN

Well that point is complete nonsense so you should undrive it.

Just because a piece of code incurs hardware related performance issues does not mean it's "no longer close to the real machine". Cache misses? Reorder your data, or start inserting prefetch statements. Mispredicted branches? Issue a hint, or structure your code better.

Both of these are profile-guided optimizations. It's very difficult for compilers to optimize for access patterns that will only become clear in the context of execution, and often depend on your target spec machine.

But a JIT can perform such optimizations. Which doesn't help Haskell, but may help JavaScript or Lua beat C in some cases.

I'm doubtful that a JIT could realistically adapt its output based on runtime performance metrics, but if you have links I'd love to read more.

http://en.wikipedia.org/wiki/Tracing_just-in-time_compilatio...

None of the problems he cites are issues with his code, though, nor are they as much of an issue with modern processors. Unless I'm missing something, the presentation he cites are running on the Cell processor, not a modern x86 system.

RAM cache misses are pretty bad, but with the blocks that he's dealing with, he's looking at maybe 1 miss per block, and that's assuming that the processor is letting the blocks get entirely out of the 3 levels of cache to RAM.

The compliment array should stay in memory 100% of the time because it's tiny and referenced constantly, and the individual arrays shouldn't be that bad. He's not branching all that much, so unless the while and for loops are triggering after 1 or 2 characters, it's unlikely that's the issue.

The actual problem he's more likely running into is the OS rescheduling the thread to a different core, which is a gigantic hit.

Reply on news.ycombinator.com