Idea: Runtime Optimization, Iterator Blocks and Compiler-generated State Machines

[AdamSobieski]

Hello. I would like to discuss some ideas towards enabling the optimization of iterator blocks and their resultant compiler-generated state machines.

public IEnumerable<int> Function1()
{
    yield return 1;
    yield return 2;
    yield return 3;
}

At first, towards enabling runtime optimizations, one might consider features which would surface in C# in a manner resembling:

public IQueryable<int> Function2()
{
    yield return 1;
    yield return 2;
    yield return 3;
}

Next, one might consider that these functions are transformed by compilers into state machines. So, techniques for runtime optimization might surface in C# in a manner resembling:

public IStateMachine<int> Function3()
{
    yield return 1;
    yield return 2;
    yield return 3;
}

When developers would utilize the state-machine-related interfaces as return types, this would signal that they desired to provide iteration while also providing inspectability for runtime optimizers.

As considered, state machines would provide read-only access to their states and transitions. IStateMachine<T> would extend IEnumerable<T> and IStateMachine. IStateMachine would have a property of type IStateMachineProvider.

Models of compiler-generated state machines might provide access to System.Linq.Expressions.Expression or Roslyn tree expression nodes representing the transformed program logic inside of the state machines. With these sorts of features, one can start to imagine exploring how to provide developers with runtime optimizations.

We could create extension methods on these interfaces, on IStateMachine and IStateMachine<T>, resembling LINQ. These extension methods would be used, in particular, when runtime optimizations were desired.

I am in particular interested in optimizations with respect to use cases like YieldProlog where iterator blocks and compiler-generated state machines are utilized extensively.

These topics are interesting to me and hopefully are of some interest to you. Has anyone else explored these topics? What do you think of these ideas?

[CyrusNajmabadi]

@AdamSobieski similar to related discussions you've brought up in the past, this seems to lack information on why this would be beneficial.

Furthermore, it doesn't really explain what the language would do here.

[AdamSobieski]

@CyrusNajmabadi, hello. I'm not sure that I'd tend to agree with that. The last time that I opened a discussion here was in February of this year and six of us, yourself included, appeared to enjoy talking about Metadata Attributes on Statements and Expressions.

This discussion topic about Runtime Optimization, Iterator Blocks and Compiler-generated State Machines could be even more interesting, more significant, and, potentially, more beneficial to the developer community.

I wanted to share these ideas as soon as they occurred and, as a result, I am still awaiting some emails about some of the technical particulars pertaining to the optimization of multiple interconnected, interrelated, interdependent compiler-generated state machines. The intended benefits would be speed- and performance-related.

The gist of the envisioned language features, what the language would do here, would be to allow developers to choose to use another return type for their iterator and generator functions. That is, IEnumerable<T> would be utilized for the existing functionalities and something new would be available from the language for the "IQueryable<T> analogue".

The envisioned return-type interface, IStateMachine<T> or IQueryableStateMachine<T>, would extend IEnumerable<T>, supporting iteration, but would also provide runtime inspectability for compiler-generated state machines from multiple modular methods, classes, or assemblies, allowing the inspection of states, transitions, and compiler-generated program logic therein.

[HaloFour]

@AdamSobieski

Have you two noticed that you just verbally slighted a third-party software project, YieldProlog, as not worth looking at, when all I said about it is that it and its users make extensive use of generator functions?

Not in the slightest. Could be an excellent project. But it's not my responsibility to research what it is in order to figure out how it makes your vague statements make any sense. That's your responsibility.

[AdamSobieski]

Could be an excellent project.

@HaloFour, thank you for taking a minute to clarify. A ticklish matter is that Jeff Thompson, creator of the YieldProlog project, is one of the people that I invited, last week, to observe and to potentially participate in this discussion thread.

[CyrusNajmabadi]

@AdamSobieski You mentioned:

I am in particular interested in optimizations

But you haven't even given a description of what issues actually exist today, and what sort of optimizations would be possible, viable, and how they would even work.

You've vaguely jsut said that there will be interfaces (like IStateMachine) without describing what those interfaces actually provide, and vaguely indicated that this will make optimizations possible, without showing a single example of that in action.

Basically, there's nothing really possible here. It's like saying: "if c# exposed an IGC interface, we could make memory management faster". There's just nothing to go off of there.

For these discussions/ideas to have traction, we need more to go off of. My recommendation is to do some exploration first, then come with some more fleshed out ideas that people can realistically consider and then sink their teeth into.

[CyrusNajmabadi]

@AdamSobieski when you have something more fleshed out, feel free to start a new discussion on that idea. Thanks.

[CyrusNajmabadi]

I am still awaiting some emails about some of the technical particulars pertaining to the optimization

As this is a suggestion to make language changes to support optimizations, but no information had been given in that, I'm going to close this out.

If you can provide better specifics in the future, that would be appreciated. Thanks!