qsharp
magicl
qsharp | magicl | |
---|---|---|
5 | 14 | |
340 | 226 | |
12.9% | 0.4% | |
9.8 | 5.4 | |
7 days ago | 6 months ago | |
Rust | Common Lisp | |
MIT License | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
qsharp
-
A tutorial quantum interpreter in 150 lines of Lisp
(disclaimer: I work on the team developing Q# and its tooling)
That's part of the goal of Q#. It's designed to be a language which allows you to build up from quantum gates, efficiently work with quantum concepts such as 'adjoint' and 'controlled' operations, and build that up into a higher level of abstraction. You can see an old post as to some of the reasoning when it was first developed at <https://devblogs.microsoft.com/qsharp/why-do-we-need-q/>.
Another consideration to some of the points raised here, is that even on today's state-of-the-art hardware you typically only get a couple thousand gates at best before noise overwhelms the system and the qubits 'decohere' (https://en.wikipedia.org/wiki/Quantum_decoherence). So you do often want to develop at a level where you can squeeze every last gate out of whatever program you're writing. (If you intend to run it on a quantum computer and not just simulations).
Being that the post is about quantum simulation, you can see the one our team built in Rust at https://github.com/qir-alliance/qir-runner/blob/main/sparses... . This uses 'sparse' simulation, which means any state with a probability of 0 isn't tracked, which turns out to be quite a few in a lot of algorithms. This allows you to simulate many more qubits than you can with a full state simulator (where you need to track 2^n states for n qubits). It also does some other nifty tricks where you can elide or combine gates before they are performed to get even more perf. We use it in our new Q# stack (https://github.com/microsoft/qsharp) to run program simulations in our CLI or in the browser (such as on our new https://quantum.microsoft.com site), or inside VS Code (desktop or web)).
We are looking to evolve the Q# language and improve the quantum development experience, with a focus given to a 'scalable' quantum future where gate count and noise is less of a limit, and moving development higher up in abstraction - as you outline. So if it is something you have an interest in, we're more than happy to get the input on the qsharp GitHub repo linked to above.
- Microsoft rewrote Q# compiler in Rust
-
Microsoft rewrote Q compiler in Rust
Portability, minimal size, and speed are all priorities. Building with Rust allowed us to really focus on all of these for both WebAssembly and OS binaries.
For example, if you go to the playground that we publish on every push to main (https://microsoft.github.io/qsharp/), and open the Developer Tools to see the network traffic, you'll see that our WebAssembly module is just 1.5MB (504kb over the wire) - which includes the not just the language (parser, type system, IR, etc.) but also the runtime interpreter and quantum simulator.
Similarly, for the native tools, on my MacBook (i.e. ARM64) the command line compiler ("./target/release/qsc") is 3.9MB, which is entirely standalone with no dependencies.
We do have many features to add, so I'm sure those will grow a bit, but we are focused on keeping things as small, portable, and fast as a general principal.
magicl
-
A tutorial quantum interpreter in 150 lines of Lisp
(Link didn't work for me)
https://github.com/quil-lang/magicl/blob/master/src/high-lev...
-
Why Lisp?
use MAGICL. [1] It is optionally and transparently accelerated by BLAS/LAPACK.
[1] https://github.com/quil-lang/magicl/blob/master/doc/high-lev...
-
How fast can you multiply matrices using only common lisp?
Maybe have a look at how magicl does this?
-
A software engineer's circuitous journey to calculate eigenvalues
This is essentially the first option, which is already supported by MAGICL by loading MAGICL/EXT-LAPACK [1].
[1] https://github.com/quil-lang/magicl#extensions
-
Uncle Stats Wants You
I think what the magicl team has done is brilliant - allowing multiple implementations is awesome.
-
Good Lisp libraries for math
Second up is magicl, especially useful if performance is a concern. This might not be as extensive as numcl, but it's been battle tested in the industry over the last decade or so. Because this uses generic functions, so long as you are using not-very-small arrays, performance should not be a concern for you. And even if you are, you could write your own functions that use the low-level functions that magicl's backends define. Otherwise performance can be at par with numpy.
-
Why is python numpy *so* much faster than lisp in this example?
This Dev How-To describes (I hope in enough detail) how to add these specialized routines to MAGICL.
-
CL-AUTOWRAP generated (C)BLAS wrapper in QUICKLISP
I agree... and I do don't want be the person who has not rallied. I just took a look at guicho's issue from 2019. And here, you yourself have admitted that the high level interface is less than ideal and needs more work. However, the very point that magicl is an industry standard could imply that potentially radical backward-incompatible changes can be hard. But, honestly, I want to discuss this, time permitting!
- Fast and Elegant Clojure: Idiomatic Clojure without sacrificing performance
-
Anybody using Common Lisp or clojure for data science
Common Lisp is a great language to build new tools for data science, but currently has pretty awful library support existing data science workflows. Common Lisp is sorely lacking in high-quality statistics, plotting, and sparse arrays. There’s been a long work-in-progress library to bring flexible and high-performance linear algebra to Lisp, but it needs more contributors.