原创 LabVIEW为多核设计的实现提供强大支持

我们首先关注的是，使测量硬件配置的可视化，以及将应用发布到硬件上的多个可编程目标上将变得非常容易。我们期望能够在不同发布和不同硬件配置下方便地进行试验。如果你能够毫不费劲地采用不同的备选方案，那么你就更有可能找到最佳方案。

现在的机器都具备功能非常强大的图形处理单元，最新的操作系统正在提高用户界面体验的级别。我们也需要在LabVIEW中提供更高级别的体验。因此，我们正在将系统框图项目(system diagram project)作为一个能够与最新的制图技术一起使用的工具，同时增加我们一直对LabVIEW框图期待的所有可视化和直接处理编辑功能。新的框图不仅看起来出色，实际上也非常有用。当你向前后移动、改变视图或者进行编辑时，都很容易查看正在发生的情况，这意味着你可以更高效地进行编辑，并且在编辑过程中将获得更多乐趣。

随着电子产业朝着多核处理器的方向发展，并行编程正在不断赢得关注。多核处理器将允许你并行运行多个独立程序，从而实现更高的整体性能。每个程序的运行速度并没有提高，但是由于各个程序在同时运行，因此这种处理器可提供更高的性能。

美国国家仪器公司“LabVIEW之父”NI Fellow暨NI创始人之一Jeff Kodosky

但是，让单个应用在多核处理器中以更高速度运行却是一个完全不同、且更具挑战性的问题。需要在多核处理器上以更高速度运行的每个应用都必须被重写成多线程程序，这是业界一个比较艰巨的任务。从现在开始的5~10年内都不可能出现用于多核编程的最佳工具。这样的工具必须能够处理内核数是现在16倍的处理器。

同时，Berkeley的研究人员正在展望未来所谓的manycore处理器，这种处理器将具有上百个甚至上千个内核。他们认为目前所讨论的multicore技术不会演进成未来的manycore处理器。根据他们撰写的有关并行编程的白皮书，未来的编程模型必须更加人性化，并且应允许编程人员描述应用中潜在的并行性。他们还表示，由于真实世界的应用和硬件本身都是并行的，因此我们需要的是本身就具备并行特性的编程模型、系统软件和支持架构。

因此，为什么我们在编写计算机程序时强迫自己用一种顺序的思维呢？依我看来，最根本的问题在于我们拥有的并行世界的计算模型是错误的。Von Neumann存储程序模型就是一个令人为难的顺序计算模型，在这个模型中，程序是一系列违反全局状态的指令。你可能会争辩这种模型至今都工作出色，但随着我们转而采用多核处理器，它将成为一个极大的障碍。

鉴于许多优化的工作已使目前的处理器运行良好，因此像多级缓存、堆栈、虚拟内存和指令流水线这样的对象全都是基于顺序模型的局限性而专门设计的。多核处理器将对上述优化造成严重破坏，而不得不用传统编程语言处理它们将是一件相当可怕的事情。

我同意Berkeley研究人员的这个观点：编程模型必须更加人性化，并且应该允许编程人员很容易地描述并行性。但更进一步，我认为我们需要停止将程序视为一系列指令的观点，而应将它们视为数据流。我们知道，测试应用特别是嵌入式和响应型应用都是并行的，因为这些应用处理的全都是作为连续并行现象存在的物理信号。数据流所固有的并行特性本身非常适合我们将要解决的采集、分析和显示的问题。

利用LabVIEW，用户只需要专注于应用，根据需要的数量描绘并行活动，而我们的任务是确保你的框图中所表达的并行处理能正确地映射到你选定的任何目标，而无需考虑内核数。LabVIEW能够将并行数据流计算模型内部映射至底层顺序架构。LabVIEW的编译器和运行时引擎可管理线程和堆栈、保护共享数据、处理缓存冲突问题和一系列其它问题，以便可靠而高效地实现数据流模型。通过采用LabVIEW，你现在就可以对多核设备进行开发，而不必等几年之后出现其它工具。

多核处理器的焦点当然是并行编程，但是我认为它们并不能真正代表并行编程的最终架构。并行编程的最终架构是FPGA，当然，LabVIEW已经可以支持该架构。因此，无论你是在开发多核台式机、多核实时嵌入式处理器、最终的并行和确定性机器、FPGA还是上述所有对象，LabVIEW都能够覆盖到这些领域。如果你是工程界或者自然科学领域专家，你不必成为C++专家或VHDL高手。只要你画出你的并行数据流框图，LabVIEW就会在你所选的目标上执行该数据流框图。

作者：Jeff Kodosky

“LabVIEW之父”

NI Fellow暨NI创始人之一

美国国家仪器公司