Also, (in response to your question from August) I'm working on mapping qubit states to RGB color space so we can build a quantum circuit visualizer with Arduino+Pi.
wrt your question, though likely you have figured it out by now, but the
.simulate() method should return the results of the Q# function or operation: https://github.com/microsoft/Quantum/blob/67f75e857c26c68168c0d404dc879abeee1682dd/samples/getting-started/intro-to-iqsharp/Notebook.ipynb#L346
No additional operations needed I think
cgranade @cgranade waves hi from the Q# development team. @crazy4pi314 has it exactly right, the
.simulate() method in Python returns a value, while the .Run() method in C# host programs returns a task that needs to be awaited on. We're in the process of clarifying this in documentation, so we really appreciate the feedback! đ
If you're interested, by the way, I put together a very quick sample of calling
.simulate() from Python: https://mybinder.org/v2/gh/cgranade/6e1d177dc33f0bb34132319672c149bf/master
Some exciting new news today from Microsoft Ignite today! https://twitter.com/QSharpCommunity/status/1191385169669873665?s=20
Azure Quantum now will let you requisition quantum hardware resources in the cloud and run the same Q# code you develop on whatever target machine you want!
Sign up for early access to this open source platform here: https://azure.microsoft.com/en-us/services/quantum/#contact
also I was going thru some of the optimizations the compiler has and I think it be interesting to implement a few more, for example DeadCode elimiation is a typical one that could be added
@eginez Cool that you've looked at the compiler code! Let me give what I hope are some helpful pointers where to find things:
The output of the compiler right now is binary json (that may change in the future) and/or a dll that contains the same as resource (that might also change). Both at the moment contain the data structures here: https://github.com/microsoft/qsharp-compiler/blob/master/src/QsCompiler/DataStructures/SyntaxTree.fs
That output can be loaded by the compiler e.g. via the CompilationLoader: https://github.com/microsoft/qsharp-compiler/blob/bd09e7c63adf0d9420399c451d2e4a2e0c6b8479/src/QsCompiler/Compiler/CompilationLoader.cs#L747.
The command line compiler (https://github.com/microsoft/qsharp-compiler/tree/master/src/QsCompiler/CommandLineTool) allows to pass arbitrary .NET Core dlls via the handle --load path/to/your/dll that are invoked at the end of the compilation process. Any class implementing IRewriteStep in that dll will be executed as part of the compilation process (at the end of it). An example that invokes the C# generation in this way can be found here: https://github.com/microsoft/qsharp-compiler/blob/master/src/QsCompiler/TestTargets/Simulation/Target/Program.cs
It would be terrific to get some additional optimizations! Sounds like you have already found the project that one of my interns (Rory Soiffer) started this summer: https://github.com/microsoft/qsharp-compiler/tree/master/src/QsCompiler/Optimizations/OptimizingTransformations. I am happy to assist with pointers and such on how to add more! :)
one follow up question what project turns the bson into architecture specific asm?
Hi @eginez,
Sorry for the delay in response. Targeting executables for particular hardware is currently work in progress. In particular, the compiler so far does in fact not have a handle to receive the information regarding what the execution target is - that should be amended shortly. There is definitively a long way to go to build a full compilation process and a prototypical runtime that will make this as universal and useful as it is intended to be. If you have more specific questions related to targeting and/or are interested in contributing a particular functionality I may be able to give you a more useful answer. :)
Sorry for the delay in response. Targeting executables for particular hardware is currently work in progress. In particular, the compiler so far does in fact not have a handle to receive the information regarding what the execution target is - that should be amended shortly. There is definitively a long way to go to build a full compilation process and a prototypical runtime that will make this as universal and useful as it is intended to be. If you have more specific questions related to targeting and/or are interested in contributing a particular functionality I may be able to give you a more useful answer. :)
Hey @/all , check out the Q# advent calendar for some project inspiration! There are also still some slots left later in the month if folks are interested in contributing.
I was reading this paper a couple of days ago (Compiling SU(4) quantum Circuits to IBM QX Architectures https://arxiv.org/pdf/1808.05661.pdf) and it inspired me to look at q# in more detail
I tried running some of the compiler unittests but I found some build problems with it, probably mac os related. I'll send a PR once I figure out what is going on with the test target
hey all I wrote a blog post on my experiences of building the q# compiler on mac os x: http://www.eginez.xyz/post/qsharp_macos/
hope you all find it interesting
@cgranade wrote an awesome post on what it's like to be a quantum developer at Microsoft! https://dev.to/cgranade/what-is-a-quantum-developer-anyway-38l
@eginez Cool post - I love it! I think I've already given the explicit disclaimer that the data structures that the compiler output may/will change in the future, so you should not rely on them. However, the API of the CompilationLoader that allows to read the output back in should be stable-ish. FYI, this might also be of interest to you: https://github.com/microsoft/qsharp-compiler/tree/master/src/QuantumSdk (early alpha version obviously, and I'm happy for feedback).
Do you know where I could read up on estimating the performance characteristic of a Q# function? Like, is using an extra O(n) pass over an array better than using a mutable? And how costly is that ancilliary qubit really? I often have different ideas for the implementation of a function and I don't know how to decide between them..
@anfelor: Thanks for your question! For estimating the quantum resource usage (e.g.: the number of qubits required, the đ-depth, etc.) of different operations, the resources estimator (https://docs.microsoft.com/quantum/machines/resources-estimator) is a great place to start. For estimating the classical performance of different Q# functions, I've found profiling with the C# profiler or using BenchmarkDotNet works pretty well at estimating how long things take to run on the simulators currently provided with the Quantum Development Kit. Beyond that, @bettinaheim may have some better advice, as she leads the compiler and runtime efforts.
We currently unfortunately do not have any custom profiling support for classical performance besides profiling the C# code. For our ML sample, @cgranade went with good old print statements (https://github.com/microsoft/Quantum/tree/master/samples/machine-learning). I can give more insights into how arrays work under the hood however. Did you have a concrete case in mind, @anfelor?
đ New Blog Monday!
Want to learn more about arrays in Q#? Check out the post @cgranade and I did this weekend while we were #flatteningthecurve
https://dev.to/crazy4pi314/an-array-of-facts-on-arrays-in-q-50m2
@cgranade That is helpful, I didn't know about that :). Do you know how the different metrics are related? Probably 'Width' should be restricted as much as possible and I can imagine that a rotation is costlier than a Pauli Gate (?)
I have a background in math and coding, but I know virtually nothing about quantum physics, let alone quantum computers
@anfelor: Happy to help! The resources estimator is really focused around counting the kinds of operations that are uniquely costly on quantum computers, esp. error-corrected quantum computers. To a good approximation, the cost of a quantum algorithm is determined by how many times the
T operation gets called. As you note, that can happen indirectly when you call rotations or other operations, as the resources estimator expands those operations into equivalent implementations based on T. You can see some of those expansions in the runtime at https://github.com/microsoft/qsharp-runtime/tree/master/src/Simulation/Simulators/QCTraceSimulator/Circuits. From that perspective, the thing to worry most about is the T depth. Under that cost model, Pauli operations are pretty much free, since you don't need to call T to implement them.
@anfelor I'm glad you're enjoying the Katas!
For the question on the extra qubit, https://github.com/tcNickolas/MiscQSharp/tree/master/DecoratingTheTree2019-Optimize talks a bit about improving performance in simulation: each extra qubit (roughly) doubles the number of numbers needed to represent the state of a system (and to update it when applying a gate), so you're not going to notice the difference between 5 and 6 qubits, but the difference between 26 and 27 is quite noticeable. It wouldn't be the case for a real device, of course, since it wouldn't update the individual amplitudes - the physics would take care of that
For the question on the extra qubit, https://github.com/tcNickolas/MiscQSharp/tree/master/DecoratingTheTree2019-Optimize talks a bit about improving performance in simulation: each extra qubit (roughly) doubles the number of numbers needed to represent the state of a system (and to update it when applying a gate), so you're not going to notice the difference between 5 and 6 qubits, but the difference between 26 and 27 is quite noticeable. It wouldn't be the case for a real device, of course, since it wouldn't update the individual amplitudes - the physics would take care of that
@tcNickolas_twitter I finally got around to reading your blog post. I am actually a bit surprised that Q# can't do that optimization automatically since it should be similar to let-floating and that is essentially a solved problem, see 3.1 in https://www.microsoft.com/en-us/research/publication/let-floating-moving-bindings-to-give-faster-programs/
@cgranade I don't understand yet what makes the T operation so costly; something about error correction? But then that should apply to rotations too? I looked at the definitions of rotations, but they all seem to reduce to Interface_R which is marked intrinsic..
Do you know of some papers/blog posts/READMEs that describe the architecture of the Simulator in more detail? I only found https://arxiv.org/abs/1604.06460 so far