Home | Blog | Software | Reviews and Features | Forum | Help | Donate | About us
topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • December 11, 2016, 12:10:29 AM
  • Proudly celebrating 10 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: its a myth, a MYTH I say!  (Read 2180 times)

housetier

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • default avatar
  • Posts: 1,321
    • View Profile
    • Donate to Member
its a myth, a MYTH I say!
« on: July 18, 2006, 10:53:15 AM »
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

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,029
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: its a myth, a MYTH I say!
« Reply #1 on: July 18, 2006, 11:35:10 AM »
Not a bad little article, but nothing majorly new either. And not 100% correct...

Quote
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.
- carpe noctem

housetier

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • default avatar
  • Posts: 1,321
    • View Profile
    • Donate to Member
Re: its a myth, a MYTH I say!
« Reply #2 on: July 18, 2006, 12:19:44 PM »
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.

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

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,029
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: its a myth, a MYTH I say!
« Reply #3 on: July 18, 2006, 12:46:44 PM »
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.

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.

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