Compile-time vs run-time actions


#1

I would like to make a high-level summary about compile-time vs run-time , based on the end part of this too long thread , that I think will help other (beginner) users too,
and also ask a question.

While in Julia, due to JIT technology, the compile- vs run- time steps are not explicitly called by user, they manifest themselves in duration of first call vs subsequent calls of a function.

Let’s consider the definition of a function in Julia, and it’s call.

  1. Compile-time is all the analysis, transformations, computations, optimizations and translation till machine language code, that the function’s code is subject to, the first time that function is “called” (during a program/module execution, or during a REPL session) (hence “Just-In-Time” tech. name)
  2. Run-time (“execution” time) is the period of execution of the binary code resulting from compilation. Run-time happens after compilation in a first-time function call, or by itself in subsequent calls (during a program/module execution, or during a REPL session)

For more introductory details, see this discourse reply.

By sem-actions (semantic actions) I will mean all the semantic-level action steps (operations/function calls/assignments/definitions…) that must be taken by the computer, as expressed in a piece of source code.
Some of sem-actions in a program require/involve :

  • (reading) external inputs (like user-supplied arguments to a program; interactive user-inputs; reading a HD file, …),
  • others involve (writing) external outputs (like writing to terminal or an external file).

I guess in a word they are called “I/O operations

The question: Is the following a good rule of thumb?

Any sem-actions that do not involve/require external inputs or outputs are taken at compile-time, while those that do require them – at run-time.

I was inspired by the following:

Comment: I think that is a good ideal (or principle) that further compilation technology development will strive to achieve (if currently is not yet fully achieved)

(Let me know if should be in another posting category)


#2

No. There can be side effects.


#3

In Julia, there is no semantic distinction between compile time and run time—everything behaves as if it is done at run time. The implementation can do something at compile time if there’s no behavioral difference between doing it at compile time and doing it at run time (aside from timing).


#4

I am wondering what the purpose of this exercise is. In particular,

  1. if you have a concrete question or problem that you want to solve, it would be more useful to ask about that instead.
  2. similarly, if you want to learn more about Julia, either the semantics or the internals, it is just better to ask what you want to know, instead of proposing something and having it debated.
  3. the broad outline of various parts of Julia’s internals is documented in the devdocs. It is usually as compact as possible while keeping it meaningful, further summaries just sacrifice precision/clarity (which you complained about in the other thread).

#5

You are all right in the sense that I had not fully baked in my head the ideas before first writing them here. I’ve edited the post with important changes.

Right, I had realized that only after Ist posting ; I’ve corrected now.

Right that the only difference is in duration taken by first- vs subsequent- calls of a function.
I wanted to find out whether I can predict when the difference will be big, that’s why I asked about that “rule of thumb”.

As exemplified in a reply, a function like

function f()
...
# ANY number of assignments with complex arithmetic expressions
# but which can be modeled by a (acyclic) dependency graph
# and don't involve side-effects
...
return(last_variable) # asssume last_variable is bound to a number -type value
end

and one like

function g()
   return(100)
end

will take exactly the same amount of time of execution, at all subsequent calls of the function (in a given program or REPL session). While first call of f() may take much much longer than g().


#6

You were addressing the post in it’s Ist version; now it’s different, and I’ve corrected it in ways that answer, I think, your points.
Some questions are more general than others.
I’m not starting a debate: the users can neglect my “Comment” in the post if that’s what you thought would cause debate.
Thanks for the devdocs reference.


#7

It is important and generally recognized as such. The manual talks about this a lot, and covers some specific caveats (eg this one).

I am still not getting the point of this topic though. If you just want to emphasize the cost of compile time, you are probably preaching to the choir, also you may not need to define your own terminology to do so.


#8

I am still not getting the point of this topic though.

This post has 2 things:

A short summary that I think will benefit other beginner users. The ideas in it may be obvious to you ( from your “preaching to the choir”) but not to others.
I’ve seen other posts just with sharing ideas, also withing “usage” category.
My comment may given an idea to advanced developers too - if not, fine, again, they’ll ignore it (or tell me it’s obvious or wrong, whatever).

Second, the post does include a question.

I don’t think you want to discourage me or others from sharing ideas or asking questions.

Let other users judge, and the post will sink to the bottom of visibility if nobody appreciates it, and I’ll learn my lesson.