quilc VS criterium

Yes, they use it for their quantum compiler, at RHL Laboratories (it was maybe initiated even at Rigetti). https://github.com/quil-lang/quilc

QUILC is probably the most interesting project. It is an open-source automatic, retargetable, optimizing compiler for Quil. It can take nearly any quantum computer architecture description and compile+optimize a Quil program for that architecture.

The QVM does all manner of quantum computer simulations. It specifically simulates a Quil program, with both classical and quantum operators. The QVM has lots of different modes of operation:

You can do this with a compiler like quilc. A program like

This is a new physical implementation of a particular mathematical operation, on a specific modality of qubit. The same mathematical operation can be computed on any other quantum computer in production today; very easily so if you use a compiler like QUILC [0].

[0] https://github.com/quil-lang/quilc

For people who maybe already have a job, just want to dip their toes in, or some other life thing that prohibits them from being employed, I’ve done pro bono mentorship sessions to interested individuals, helping them contribute to open source software around this stack, like the quantum compiler. Always happy to discuss that for serious applicants.

compiler code

Yes, simulator, compiler, paper is some of it.

Speaking about Common Lisp, the only commercial-level compiler implementation that I know of is https://github.com/rigetti/quilc by /u/stylewarning et al.

(criterium does not work here yet b.t.w., but it probably will be working soon)

criterium, specifically the quick-bench function, will actually run multiple samples an provide a mean runtime (as well as other useful stats) so you can get an idea of what a jit'd warmed up performance looks like. time is great in a pinch, but you end up needing to run it multiple times to ensure optimizations are kicking and and other artifacts (like gc) aren't throwing the results.

I'm going to leave tooling out of this and run everything through a repl on the command line right from the jar. One other thing I want to do is include the incredible criterium library so we can profile. I'm deliberately including criterium separately like this because you shouldn't have a dev-time tool like criterium in an uberjar. And knowing how to easily combine other jars with your real production jar can be very helpful. I grabbed the jar from my .m2 cache.

I am just going to leave this here - https://github.com/hugoduncan/criterium

where crit is criterium. As you can see, you're spending most of your time in the seq transformation part.

It's better to benchmark with something like criterium. time is a bit inaccurate. Though, if it's really 15 seconds, I guess will not be that big of a difference

>>> One of Clojure's biggest weaknesses in practice is that breaking in to those functional structures to figure out where the time is being spent or to debug them is harder than in other languages. This is a natural trade-off of developing a terse and powerful language.

Not that hard if you use something like YourKit. There's also a quite good Clojure library https://github.com/hugoduncan/criterium .

Criterium (the benchmarking library used here) uses multiple runs to obtain tighter bounds on amortized performance, as well as techniques to amortize the effects of garbage collection and JIT compilation. See https://github.com/hugoduncan/criterium for a brief overview, as well as links to the pitfalls and statistical techniques involved in JVM benchmarking.