its a myth, a MYTH I say!

[housetier]

whuu? Say what now?

Well I don't say it, but this article does.


Bah, I have read so many of these language comparisons already; shoutout.alioth.debian.org anyone?

True, there aren't any benchmarks. But at the same time it is also not a rant, it just explains where certain myths come from (thereby demystifying them). And who here says shootout.a.d.o. was in any way sound? It has lots of statistics but it doesn't prove a thing.


Yaddayaddayadda, so it's not polemy; why should I read it?

The article does not use complicated terms or foul language. I found it very easy to comprehend.

Read it and next time someone makes a claim about certain "features" of certain programming languages, consider how much truth lies in that article. But don't get caught up in a programming language flame war!

Happy Hacking!

[f0dder]

Not a bad little article, but nothing majorly new either. And not 100% correct...

Due to the way C works, it’s impossible for the compiler to inline a function defined in another source file. Both source files are compiled to binary object files independently, and these are linked.

Which is wrong, considering Link-Time Code Generation (visual C++ 2003 or later). Intel's C++ compiler has had it for a while too, called something else though. Works pretty well. Idea is simple, .obj files no longer have machine code but rather the intermediate "p-code" the compiler is generating anyway, and optimizing is deferred until the link stage.

[housetier]

Idea is simple, .obj files no longer have machine code but rather the intermediate "p-code" the compiler is generating anyway, and optimizing is deferred until the link stage.

-f0dder (July 18, 2006, 11:35 AM)

Which to me sounds as if it's not too far away from just-in-time compilation. I think in the future we will have more abstract machines which optimize themselves all the time; total virtualization so to say. I will have to pick up the proper technical terms so I can better explain what I mean.

The trend seems to be to generate the machine code as late as possible in the uhm "runtime/lifetime cycle" of The Code.

[f0dder]

Idea is simple, .obj files no longer have machine code but rather the intermediate "p-code" the compiler is generating anyway, and optimizing is deferred until the link stage.

-f0dder (July 18, 2006, 11:35 AM)

Which to me sounds as if it's not too far away from just-in-time compilation. I think in the future we will have more abstract machines which optimize themselves all the time; total virtualization so to say. I will have to pick up the proper technical terms so I can better explain what I mean.

The trend seems to be to generate the machine code as late as possible in the uhm "runtime/lifetime cycle" of The Code.

-housetier (July 18, 2006, 12:19 PM)

Perhaps - we're not there yet, though. Suns JVM has abysmal performance (MS JVM beat it by far), and while dotNET is pretty okay, it's still easy to beat with native code (code speed as well as memory use) - it looks like it's hard to beat dotNET for development time in a bunch of situations, though.

There's a lot of interesting techniques that can be applied with JIT optimization, some of which is hard to do with normal code optimization. For instance, taking note of branch prediction misses and rearranging the code to minimize this. However, the profiling overhead needed for doing this is not free - and it can be done with profile-guided "static" code generation as well (Iirc supported in vc6, vc2005, intel compilers).

Then there's more or less specialized pieces of code, where (on x86 anyway) a decent programmer can beat compilers by pretty large amounts. Compilers still don't have extremely good intrinsics support for new instruction sets (SSE/2/3, MMX) - besides those intrinsics makes code less portable, so it's safer and more portable to write an external assembly module. Even for code using the plain old instruction set, it's still possible to beat compilers - but of course this rarely makes sense (hence "specialized pieces of code").

As long as we stay on x86 (which will probably be pretty much forever, after AMD introduced x86-64 and since Apple moved to intel hardware, curse them both) I don't see JIT'ing replace normal code generation... unless there's enough SHEEP who blindly swallow VISTA.