Roslyn is entirely unrelated. That's the compiler to CLIR. We're talking about the runtime interpreter and compiler to native code.
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.
> 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?
> 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.
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
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).