Yes? My question was "whats the benefit of an interpreter for runtime code exec, over using a compiler-as-a-service like Roslyn"

You've asked what is the benefit of using apples over oranges. The two things are unrelated.

When you use Roslyn you still need either a JIT or an interpreter to execute the output of Roslyn. You can't ask what is the benefit of using the interpreter over using Roslyn as you cannot do that. They don't fit into the same place in the system. They don't do the same job. They aren't alternatives.

It's a nonsense question.

This is a somewhat better answer :) The reason I'm asking was because the interpreter was framed as a solution to in-app code execution (e.g like Lua in many game engines) - but this type of scripting is exactly what I use Roslyn for. So if I can rephrase it: what is the benefit of interpreted scripts vs dynamic compilation of scripts in the context of , for example, app scripting? Specifically in .NET apps. Not e.g. a C++ app (there it's obvious as a replacement for e.g Lua)

> When you use Roslyn you still need either a JIT or an interpreter

Yes: Assume I'm already in a .NET appxontext so yes I have the JIT available. Does that make the interpreter less attractive as I can just load compiled code there?

I'm guessing then the benefit might be less initial overhead, but at the expense of slower execution?

This still doesn't make any sense:

> but this type of scripting is exactly what I use Roslyn for

Because you aren't using Roslyn to execute anything. You're using it to compile C# to CIL. That CIL is then executed by a different part of the system - the JIT. It's that entirely unrelated part of the system that is being talked about being replaced with an optional interpreter instead.

Roslyn goes from C# to CIL.

The JIT and interpreter execute CIL. They don't know or care that it comes from Roslyn and the fact that you use Roslyn or the command line C# compiler to generate the CIL is irrelevant.

You're being tripped up by the fact that the system has multiple levels of compilers. You're thinking about one level but this discussion is about another level.

But anyway there is actually a helpful answer to this question:

> what is the benefit of interpreted scripts vs dynamic compilation of scripts in the context of , for example, app scripting?

The interpreter will probably use less memory and run your code faster first time. You probably don't care about less memory in a game unless you are running in a very constrained system, and you probably don't care about first-time execution as either these scripts run every frame and so it's critical they're very fast, or they run once a few seconds or so in which case who cares how fast they run.

> Because you aren't using Roslyn to execute anything. You're using it to compile C# to CIL. That CIL is then executed by a different part of the system - the JIT.

Right - with Roslyn Run("somecode") means creating an assembly from the code, then loading it into the current AppContext and executing it there. If I were to run an interpreter then Run ("someCode") is interpreted. I get that.

My question was still only: would an application chose one or the other, when given both options. I get that they are completely separate ideas and Roslyn doesn't do anything an interpreter does (Roslyn and jit does) - but "compile+load" and "interpret" both offer a way to solve the Run("somecode") problem, which is why they are still somewhat related in the specific context of a .NET app with scripting

Ideally, an application doesn't have to choose, but the runtime uses some good defaults. For example, let's have a look at the HotSpot JVM: A Java method first gets executed in the interpreter, then, if it's hot enough it will compile the method with the C1 JIT, and then later uses the C2 JIT to bring the method up to full peak performance. There is also some profiling going on that is fed into the JITs to guide optimizations. The transition between the execution tiers is based on some heuristics and is kinda complex.

Do you need to care as an application? Ideally no :-) It should be transparent to the user and it's the runtime's job to do the best available thing for you. (Sure, the runtime can be tweaked for specific workloads etc.)

In Mono we aren't there yet: the interpreter is currently useful for restricted targets like iOS, where a JIT can't be used due to security concerns and AOT comes with certain limitations (that is, loading assemblies at runtime and execute them). If you want to use Mono's Interpreter to run roslyn, you can explicitly tell the runtime to do so, but it doesn't make much sense today, because it will give you less performance than the available JIT; we don't support switching the execution engine on the fly for single methods yet (it's also called tiered compilation).