前一段时间遇到Bettina Heim（Q#论文第五作者），这个月也在组里和老板同事们一起很愉快地研读了Q#这篇论文。我来说下我的理解。
背景信息
量子计算编程语言Q#是微软量子计算机全系统层次Solid的一部分。Solid这个项目源于2014年微软发布的一个量子计算软件全家桶：LIQui|>（liquid):
Liquid主要包含：一个基于F#的编程语言，一个编译器，一个模拟器，然后是周边服务及后端。
基于F#的Liquid语言在当时出现的时候有一种惊人天人的感觉，提供了大量的高级操作来简化量子编程，如受控门与反计算的自动实现。 一个直观的例子是，大名鼎鼎的Shor大数分解算法用QCL(第一个量子编程语言）来描述大概需要100行，而Liquid仅需50行左右。
它的编译器可自动实现优化、容错翻译、量子电路打印等。尤其是最后的量子电路打印，是量子计算中经常需要，但是没有特别方便的工具来满足的需求。这种直观的东西给人的视觉冲击还是很明显的。当时这或多或少让我知道了量子编译器也可以这么玩。
它的模拟器在当时是算是第一个人们可以很轻易地得到的可靠的模拟器。很多学生学习量子计算，却没有一个好用的模拟器。Liquid的出现算是给圈内人一个非常棒的礼物。但是不得不说，微软的尿性限制了Liquid的推广：其公开发布版只能模拟不超过22个qubit，而且给出的理由是，我们认为一般的用户用不到模拟更多的qubit。
在liquid这篇论文中，他们利用F#进行描述，到编译器进行优化，最后到模拟器，模拟了Shor大数分解算法的运行，在当时是很为量子高级语言的推广烧了一把火。
但是，这个项目只是停留在了软件层面。他们想向下继续走一步，去控制真正的量子比特(qubit)，于是，想从软变硬，那就从Liquid走向solid吧！
Solid
2016年初我与QuArc（微软量子体系结构研究组，Solid项目的负责人）的Alan Geller交流的时候，他就跟我说到了Solid这个项目，其目标是从顶层算法、编程语言、到体系结构、到控制电子电路，最后到qubit的整个全系统层次。换句话说，他们想开发一个新的全家桶，提供一个量子计算机所需的全部软件、硬件控制环境。
后来，我也在不同的场合下听Alan Geller, Krysta Svore, Dave Wecker说起Solid。但是(!)，经常的情况是，他们说着说着就来了：公司现在对Solid的政策还没有定下来，我们也只能说到这。。。这不是刚掀起姑娘盖头的一角就让观众且听下回分解么！(ノ=Д=)ノ┻━┻
从前后各处打听到的消息来看，Solid这个项目的leader是Alan Geller。应用层有以Dave Wecker为代表的一波人进行的量子化学模拟等算法的开发，上层软件工具层有以Krysta Svore为首的量子编程语言及编译器开发。这个编程语言就是Q#。Q#经过编译之后，一个编译器后端会根据目标硬件输出相应的指令及其他的控制命令，然后通过QCoDeS这个统一的电子设备控制平台来操控qubit。至于在Solid框架内，从编译器到QCoDeS之间经过什么步骤，以及QCoDeS下面都有些什么，我就不是很清楚了。值得一提的是，QCoDeS是由微软Station Q牵头，与Copenhagen，Delft，以及Sydney一起联合开发的一个基于Python开源的控制平台，可以很好地控制常见的量子实验设备，以一种系统地方式控制量子计算实验并采集数据。到目前为止，QCoDeS一直在不断发展，而且在各大高校里攻城掠地，势头很好。
以上是背景。下面来说Q#。
Q#
在我的认识中，Q#可能是第一个明确定义了完整的编程模型的量子语言。
人类对量子计算机进行编程仍处于摸索阶段。从IBM的量子计算平台Quantum Experience来看，现在的量子编程类似于六七十年代的经典计算机编程，量子汇编（QASM)是主流且可以解决绝大多数问题。虽然不断有新的量子编程语言的出现，但它们始终围绕着一个点：如何抽象QASM、用一种更高效、严谨的方式来简化量子线路的描述。换句话说，它们主要关心的是在qubit上做什么事以及怎么做。
可是，我们知道，最终的量子计算机中不可能只有qubit，也会有传统的CPU，也会有GPU。它们可能在一起工作。一个自然的问题是，这些不同的计算部件之间如何进行交流？在计算的过程中，一个部件能够调用另一个部件吗？比说如CPU该如何调用量子芯片进行特定的计算？
现在一些公司已经在推混合计算或异构计算，如Rigetti基于Quil语言的Forest，一直声称自己是量子-经典混合计算平台。可是，它们在计算模型上是含混不清的（这个也包括IBM基于OpenQASM的Qiskit）：虽然经典操作（如条件分支指令）与量子操作（在qubit上的门）可以写在一起，但是怎么样在硬件上，尤其是控制体系结构上实现这种混合计算，都是没有规范定义的。这种不规范包括没有定义能够调度的资源，没有定义不同部件之间交流的方式等等。
其实如果将量子换成GPU，那么刚刚提及的问题在业界已经有了解决方案甚至是标准——OpenCL及CUDA所定下的异构并行编程模型。那么能否将这一套应用在量子计算上呢？这样既可以充分利用传统CPU的优势，又可以完成对量子芯片的控制。
可以的，于是Q#就这么做了。这也是Q#在我看来与其他所有量子编程语言在本质上不同的一点。
Q#并没有说自己是一门通用的编程语言。相反，它给自己的定义是领域专用语言(Domain Specific Language)。Q#仅用于描述在量子芯片上可能发生的操作，而对于在传统CPU上执行的操作，Q#的编程模型规定需要一门经典编程语言来描述，如C#或Python。也就是说，在实际使用过程中，Q#一定要与另外一门经典编程语言一起共同使用！Quantum Development Kit提供的Demo中，C#写的是主程序，然后它将某个特殊的很难的任务交给量子芯片来执行（量子内核，kernel)，而这个任务由Q#来描述。C#描述的部分最终会在传统CPU上执行，而Q#描述的内核，最终由量子芯片以及与之配套的控制芯片来执行。所以，简单地作一个类比，Q#就是OpenCL或CUDA中描述Kernel的语言。所以，量子计算机在Q#中的定位最终是一个量子加速器，只是异构计算体系结构中的一部分。
最后，我的一些理解与脑洞
我本人是非常喜欢Q#的，但是我也想比较下Q#的优势与不足，从而窥探一下它可能的发展。
我想Q#最大的制约因素可能源于微软的闭源政策。当我向我导师提出向Q#开放我们的指令集以实现Q#与我们的工作的对接的时候，我老板直接因为微软的闭源政策而否决了我的提议。从更为普度的角度来说，如果Q#的编译器无法开源，一般用户则无法修改Q#的某些特性来满足自己的需要，这势必会导致Q#的推广成为一个难题。在这样的背景之下，如果有另外一门新的开源语言定义了类似的编程模型，或者是已有开源语言（如普林斯顿与芝加哥合作开发的Scaffold/ScaffCC)采纳了这样一种编程模型，Q#的后续推广将受到极大的影响。
但是，不得不提微软在拓扑量子计算上的努力！在有钱就是王道的背景下，现在微软基本上已经将全球最顶尖的做拓扑量子计算的理论、实验研究组都纳入了Station Q旗下。拓扑量子计算相比于标准量子计算机而言在容错方面拥有无法比拟的优势，而容错是量子计算机发展的瓶颈之一。一直以来，拓扑量子计算最大的问题是无法实锤证明用于构建拓扑量子比特的Majorana的存在。但最近Delft的工作进一步提高了Majorana存在的可能性，这也让人很期待拓扑量子计算机实现的可能性。如果拓扑量子计算机真的可以造出来，那么相比于全球其他任何机构，凭借微软现有的资源在这个领域就是一骑绝尘，实现对IBM，Google的弯道超车更是不在话下。如果是那样，微软凭借拓扑量子计算实现像现在Windows一样在量子计算领域内的垄断优势？然后Q#一下子就成为了量子编程语言的标准？呃，我这个脑洞还是就到这里吧。。。
来源：知乎 www.zhihu.com
作者：瓜子脸帅哥
【知乎日报】千万用户的选择，做朋友圈里的新鲜事分享大牛。 点击下载
此问题还有 14 个回答，查看全部。
延伸阅读：
日立的「CMOS 退火」技术是怎样的一种技术？利用该技术的半导体计算机是否能够替代量子计算机？
如何理解「量子退火」？
没有评论:
发表评论