Optimera körning av stora program med Resource Estimator

I den här artikeln får du lära dig hur du optimerar körningstiden när du kör stora Q# program med Azure Quantum Resource Estimator.

Information om hur du kör Resource Estimator finns i Olika sätt att köra Resource Estimator.

Förutsättningar

Om du vill använda Python i VS Code behöver du också följande:

  • Installera den senaste versionen av Python- och Jupyter-tilläggen för VS Code.

  • Det senaste Azure Quantum-paketet qsharp .

    python -m pip install --upgrade qsharp 
    

Hantera stora Q# program

När du skickar ett resursuppskattningsjobb till Resursberäknaren utvärderas kvantprogrammet helt för att extrahera resursuppskattningarna. Om du vill beräkna resurserna för en Q# åtgärd som anropas många gånger, till exempel i en loop med många iterationer, kan körningen av resursuppskattningsjobbet ta lång tid. Ett sätt att minska långa körningstider är att köra åtgärden en gång, beräkna och cachelagrat kostnaderna och använda data vid efterföljande anrop. Den här tekniken kallas manuell cachelagring.

Manuell cachelagring

Resource Estimator target stöder två Q# funktioner för att utföra manuell cachelagring: BeginEstimateCaching(name: String, variant: Int): Bool och EndEstimateCaching(): Unit. BeginEstimateCaching funktionen tar som indata ett name som är det unika namnet på kodfragmentet som du vill cachelagra kostnader för och ett heltal variant som skiljer olika kostnadsvarianter åt för samma fragment.

Kommentar

De två specialåtgärderna BeginEstimateCaching och EndEstimateCaching är inbyggda åtgärder för resursberäknaren. De stöds inte av annan körning targets.

Anta till exempel att du har en Q# åtgärd med namnet ExpensiveOperation som anropas många gånger i en iteration. Du kan använda cachelagring för att minska uppskattningstiden:

operation ExpensiveOperation(c: Int, b : Bool): Unit {
    if BeginEstimateCaching("MyNamespace.ExpensiveOperation", SingleVariant()) {
        // Code block to be cached
        EndEstimateCaching();
    }
}

När ExpensiveOperation används upprepade gånger BeginEstimateCaching anropas varje gång. När BeginEstimateCaching anropas för första gången returneras true och börjar ackumulering av kostnadsdata. Detta gör att koden fortsätter med körningen av det dyra kodfragmentet. När EndEstimateCaching anropas lagras kostnadsdata för framtida användning och införlivas i den totala kostnaden för programmet.

När ExpensiveOperation anropas andra gången (och därefter) hittar Resource Estimator de lagrade (cachelagrade) kostnadsdata, införlivar dem i den totala kostnaden för programmet och returnerar false. Detta gör att dyrt kodfragment hoppas över och därför kör Resource Estimator programmet snabbare. EndEstimateCaching ska placeras i slutet av villkoret och regioner som omges BeginEstimateCaching-EndEstimateCaching av kan kapslas.

SingleVariant() anger att kostnadsdata som samlas in vid den första körningen kan återanvändas i alla efterföljande körningar av kodfragmentet. Detta kanske inte alltid är fallet. Om koden till exempel har olika kostnader för udda och jämna värden för en variabel "c" kan du ange ett variant värde:

operation ExpensiveOperation(c: Int, b : Bool): Unit {
    if BeginEstimateCaching("MyNamespace.ExpensiveOperation", c % 2) {
        // Some code
        EndEstimateCaching();
    }
}

I det här fallet är cachen annorlunda för udda och jämna värden för c. Med andra ord återanvänds data som samlas in för jämna värden c för endast för jämna värden för c, och detsamma gäller för udda värden för c.

Kommentar

Om du stöter på problem när du arbetar med Resursberäknaren kan du gå till sidan Felsökning eller kontakta AzureQuantumInfo@microsoft.com.