Add a default simulator option to the EntryPoint attribute

[Strilanc]

Some quantum methods have to run under the Toffoli simulator. E.g. running a 1000 qubit adder under the quantum simulator is a recipe for freezing your computer as it tries to allocate the universe. It would be convenient if the entry point attribute was able to indicate the default simulator to use, to avoid that particular gotcha.

Describe the solution you'd like

    @EntryPointWithDefaultSimulator("ToffoliSimulator")
    operation ExampleRequiringToffoliSimulator() : Unit {
        ...
    }

[bamarsha]

There's a DefaultSimulator property that you can put in your .csproj file:

<PropertyGroup>
  <DefaultSimulator>ToffoliSimulator</DefaultSimulator>
</PropertyGroup>

This would apply to the whole Q# project, but projects can only have one entry point, so it should be equivalent. Would this work for you, or do you still prefer to have it on the EntryPoint attribute instead?

[bettinaheim]

I think this should be covered by the project property as @samarsha mentions. I'll assign it to myself until we get confirmation.

[Strilanc]

I would explicitly prefer it to be in the code in this case, same as for tests. It's pretty rare to include your project file in example code blocks on the internet.

On Wed, Nov 25, 2020, 8:59 PM Sarah Marshall notifications@github.com wrote:

There's a DefaultSimulator property https://github.com/microsoft/qsharp-compiler/blob/f21165084cd2a85924febe9f268435c76bec15cb/src/QuantumSdk/README.md#defined-project-properties that you can put in your .csproj file:

ToffoliSimulator

This would apply to the whole Q# project, but projects can only have one entry point, so it should be equivalent. Would this work for you, or do you still prefer to have it on the EntryPoint attribute instead?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/microsoft/qsharp-runtime/issues/451#issuecomment-734013862, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAATQRJ2TBUV7XA2EMFOBDLSRWR6NANCNFSM4UC72RKA .

[bamarsha]

Another thing to consider is that there has been some discussion about possibly making Toffoli a separate execution target with its own target packages, where certain gates would not be supported at compile time instead of being runtime errors like they are now. That would work better if Toffoli was set in the project config instead of at the entry point, although it might be possible to support both...

@swernli @bettinaheim Do you have any thoughts about this?

[swernli]

I do think we want to work towards the Toffoli simulator being it's own execution target, and in that world having it be on the EntryPoint attribute would be confusing since that is not sufficient to cause that simulator to be selected (you'd need to specify it as the execution target in the csproj as well, so that the right target packages are chosen). However, once it's an execution target that implies that it will have a processor capability associated with it, which could serve as our inspiration for another way to achieve @Strilanc 's suggestion. Is there any way that the existing processor capability attributes could be used to not just identify but restrict the code to a particular target/capability? Or would it be appropriate to add a new attribute that forces exact match instead of minimum capability?

It seems to me there are two goals here: have something close to the code that advertises to a reader where it is intended to run, and have something that mechanically forces a choice of how it actually executes once compiled. While a comment in the code might be enough to achieve the former, the latter really does imply some kind of attribute, I just don't think EntryPoint fits with our longer term goals, so ideally we can find an intermediate solution that we won't have to undo once we make progress with our simulator evolution.

[bamarsha]

However, once it's an execution target that implies that it will have a processor capability associated with it, which could serve as our inspiration for another way to achieve @Strilanc 's suggestion. Is there any way that the existing processor capability attributes could be used to not just identify but restrict the code to a particular target/capability?

From the issue description, it sounds like the issue is not necessarily wanting to get compile-time diagnostics, but as a convenient way to make sure code samples shared online will run on the Toffoli simulator if they're designed for that (because the full state simulator is much slower). If Toffoli simulator was a separate target, that would need package dependencies in the project file, right?

[swernli]

Yes, we would need the project settings for it to work, so I was imagining something that can be put in the code that says it requires that target and fail if it's compiled against a different target with an error that explains the missing project setting. But I can see how that falls short of the near term goal of just defaulting to the specific simulator. Maybe providing a default simulator parameter for EntryPoint isn't so bad; when/if Toffoli moves to be a specific target, the only selectable default simulators left would be QuantumSimulator and ResourcesEstimator, but there could still be value in marking a large circuit as being for estimation only.