Talk:Ahead-of-time compilation

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Compilation of dynamically typed languages has been done since the 60s[edit]

That's hardly difficult or new. There are several meters literature about that. — Preceding unsigned comment added by Joswig (talkcontribs) 12:11, 21 February 2011 (UTC)[reply]

So what...[edit]

So what is the difference between an AOT compiler and a conventional compiler that generates executable code? MarkMLl (talk) 12:01, 9 August 2008 (UTC)[reply]

I was wondering the same thing. They seem to be the same thing, but then why does this article exist if we already have one on compilers? — FatalError 06:21, 19 December 2008 (UTC)[reply]
Apparently, an AOT compiler is used in cases where the "conventional" compiler doesn't produce native object or executable code. The output of the "conventional" compiler is given to the AOT compiler, which generates native object or executable code.
This article is currently a stub, and I have concerns about its potential for growth. Perhaps it should be incorporated into the compiler article, with a re-direct page. SlowJog (talk) 17:36, 29 April 2009 (UTC)[reply]
I found out the difference between traditional compilers and AOT compilers: with traditional compilers, the developer has to compile the source code himself; however, AOT compilers compile it when it is first run. In other words, the source code remains as text until the program is run for the first time, when it is then compiled into native code (or possibly bytecode) and executed. (The article lead doesn't make this clear, so I'm thinking it should be reworded.) I think merging this into the compiler article would be about as useless as merging the just-in-time compilation article. Static compilation and AOT compilation are two completely different things.
However, I share your concern about its growth, as there are very few compilers/virtual machines that use this technique. Personally, I think the term is notable enough, we just haven't found the sources to prove it. A quick Google search reveals plenty of information on the topic; we just have to add it to the article, with sources. — FatalError 01:05, 30 April 2009 (UTC)[reply]
The translation process you are describing sounds like JSP compilation, but I haven't heard AOT used in connection with that process. (If I may get in a trivial jibe about your wording, source code is text before, and remains text after the program is compiled, or run for the first time. Compilation leaves the source code files alone, but produces new files.)
Before I came to this article, my understanding of "Ahead of Time" compiler had been that it was a retronym for the traditional compiler. The retronym was created after the term "Just in time" compiler was created. SlowJog (talk) 14:43, 30 April 2009 (UTC)[reply]
I saw the term described by a virtual machine developer (can't remember which VM though). It's basically just-in-time compilation, except the big difference is it compiles all the necessary code to machine code immediately before execution, not during. AOT compilers may or may not dumb an executable to the disk; it may just store the native code in memory (like a JIT compiler). I don't know the process that JSP uses, but I'd imagine this is it. — FatalError 19:01, 30 April 2009 (UTC)[reply]
And about the term being a retronym, obviously I don't think that's the case, although I'd agree that it probably came up as an alternative to JIT. — FatalError 19:02, 30 April 2009 (UTC)[reply]
Yes. After seeing this article, I changed my mind about it being a retronym. SlowJog (talk) 19:16, 30 April 2009 (UTC)[reply]

Better explanation needed[edit]

I think that this article should better explain the differences between a compiler, an AOT compiler, a JIT compiler and an interpreter. From what I understood, an AOT compiler sits between a traditional compiler and a JIT compiler, but I can't write this into the article as I'm not a computer scientist, only a technician. We need the explanation of an expert in programming theories. --79.11.245.89 (talk) 17:24, 16 October 2014 (UTC)[reply]

Hello! Hm, I'd say that the article isn't bad at all, and the things you're asking about are pretty much already there. In a few words, here are the differences:
  • a traditional compiler creates a system-dependent executable file that's later executed, which contains native code
  • a JIT compiler converts high-level code into native code and executes the native code, all that during the execution
  • an AOT compiler converts high-level code into native code and executes the native code, but before the execution
  • an interpreter pretty much runs the high-level code on top of some kind of a virtual machine, without converting it to native code
AOT compilation cannot perform some of the runtime optimizations that JIT compilation is capable of, as AOT compilation doesn't "interfere" with the conversion into native code while the code is executed. On the other hand, AOT compilation involves less overhead during execution; native executables created by AOT compilation can also be stored for later reuse (an example of such behavior is the Android Runtime).
Hope it sheds some light. However, all that's pretty much already in the article, just not in such a concise form. :) — Dsimic (talk | contribs) 18:05, 16 October 2014 (UTC)[reply]
Oh, and thank you for your edit on the Android Runtime article! I've missed that somehow. :) — Dsimic (talk | contribs) 18:07, 16 October 2014 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Ahead-of-time compilation. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 22:01, 5 October 2016 (UTC)[reply]

Platform specific?[edit]

As I understand this article, it suggests that the compiled code is platform-specific machine code. What I don't see here, though, is any discussion of the downside of this in terms of portability. I assume there must be many disadvantages here, or else Java would never have been a "thing", but it seems like the article could do a better job of spelling this out. Maybe this is easy to manage nowadays, but if so, the article should probably say that.

My two cents. 75.139.254.117 (talk) 03:44, 18 November 2016 (UTC)[reply]

Another clarification request[edit]

Would it be fair to call the "AOT compiler" a bytecode interpreter? The distinction I am making is whether the machine code ever exists in a persistent executable form (machine code), or whether the persistent executable form is bytecode, and the machine code is generated at runtime, but before "execution". It seems like care is needed for the term "execution" and "compilation" in this article to clarify sequences of events, and timings.

Maybe the best option would be having a sections "compilation time" and "execution time" to sort out these details crisply. 75.139.254.117 (talk) 03:56, 18 November 2016 (UTC)[reply]