随着多核技术进入嵌入式领域，很多过去简单的东西在硬件和软件方面都变得越来越复杂。但是有一个元素——通常被这一领域的知识分子认为是“多核的难点”——几乎没有被触及:如何将一个程序划分到多个核上。
基本上，很难做错。而且要做对就更难了。特别是在手动操作时，这是很长一段时间内唯一的选择。过程的自动化元素是有帮助的，我们在那个方向上看到了一些运动上一篇文章．
Vector Fabrics是这一领域的一家公司，刚刚发布了他们最新的工具公告，它反映了一些关键的变化:
- 他们改了名字。
- 技术本身也在发展。
- 他们已经离开了云．
随着功能的展开，Vector Fabrics的工具已经经历了几次迭代。最初，他们的vfAnalyst工具以一种以前从未有过的方式显示了代码中的依赖关系。他们又经历了几次迭代，直到他们的最后一个版本vfEmbedded，该版本以更基本的方式包含分区和映射选项。
Pareon填补了许多漏洞，将工具从处理最常见场景的工具改进为更无懈可击的工具。正如你所看到的，他们改变了品牌结构;他们发现驱动之前方案的潜在“本体论”变得有点勉强，所以他们彻底决裂了。
虽然关键技术与以独特方式可视化的依赖关系的识别有关，但从用户方法学的角度来看，这已被证明是次要的。最初，依赖关系是用户确定在哪里进行最有效分区的一种方法。一旦他们有了这些，他们意识到他们可以根据这些依赖关系提出不同的分区策略，而且，如果用户喜欢这样，那么他或她根本不需要显式地检查依赖关系。
因此，Pareon执行一个程序，并显示一个显示器，显示程序各部分运行所需的时间;在概念上与概要相似(尽管以不同的图形方式呈现)。然后，用户进入对长位进行分区——稍后将详细介绍。
执行该程序的原因不仅仅是为了分析速度，还为了检测某些依赖关系。一些依赖关系(他们称之为“计算”依赖关系)只涉及寄存器值，可以通过静态检查程序来确定这些值。但是其他的——通常与指针算术和指针混叠有关——不能静态处理。两个指针可能最终指向相同的内存位置，只有实际运行程序并检查内存地址才能知道这一点。所以他们对代码进行检测，然后跟踪加载和存储。如果一个变量写入一个位置，然后，过了一段时间，其他变量(甚至是同一个变量)从该位置读取数据，就会注意到依赖关系。
这些依赖关系最终可能非常复杂。所谓的“循环携带”依赖关系，即在一个循环的一次迭代中产生的值在另一个循环中被消耗(如a[i] = a[i-1] + a[i-2])可能很难跟踪(如果您试图手动计算它们，它们通常会让人头晕目眩)。
此外，该工具还可以注意和处理一些特殊的模式。例如:
- 从一开始，该工具就能够识别“流”模式，即在重复的基础上通过一些规则的地址序列进行访问。
- 还有更复杂的版本，他们称之为“窗口式”，它不仅仅是直接通过地址序列，而是在一个地址窗口内以规则方式移动的一系列访问。这方面的一个例子是图形算法，它通过检查周围3×3窗口中的像素来处理像素。该窗口内的访问将使事情看起来不像简单地遍历数组，但当操作从一个像素移动到另一个像素时，窗口也会随之移动。这种模式也被检测了一段时间。
- 循环中的归纳表达式——对i加1的代码——根据定义创建了一个循环携带的依赖关系:i的值将被设置为i加1(或其他增量)的前一个值。所以你不能算出nth迭代，直到算出n-1th迭代，它阻碍了并行化。实际上，i不是计算的一部分，它只是一个循环机制，在这里它把事情搞混了。该工具可以识别这些归纳表达式，并对它们进行不同的处理，以消除依赖关系。
- 约简包括对数组内容求和之类的操作。同样，计算的“sum = sum + a[i]”方面本质上是串行的。有可能重组事物，以允许多个子和并行计算，最后将子和相加为一个总总数。这种场景也可以由Pareon检测和处理。
在过去，还有其他各种各样的图案，它们的结构无法辨认;在这一点上，他们唯一难以处理的依赖关系是由某些复杂的递归实例产生的依赖关系。
为什么它们能够检测和处理哪些依赖关系很重要?因为这决定了工具认为您可以对代码进行分区的位置。您可以选择一个消耗大量执行时间的函数，并决定尝试对其进行分区，以使其运行得更快。机械地，右键单击并选择“Partition”，Pareon将显示一个不同分区选项及其成本的列表。它只会选择那些要么不破坏依赖关系，要么破坏它们知道可以在分区程序中同步的依赖关系的分区。它们可以处理的依赖项越多，可用的分区选项就越多。实际上，如果它找不到对函数进行分区的方法，那么您可以转到一个计划视图，在那里您将能够看到哪些依赖项妨碍了分区(以及创建依赖项的源代码)。
它们还将只提供没有死锁问题的分区选项。
每个分区选项都以一定的代价提供了一定程度的程序加速。成本与创建的线程数量和线程间同步数据的开销有关。然而，由此产生的加速是棘手的。过去展示的东西在某种程度上更理论化，甚至在早期与建筑无关。但是架构和其他方面很重要。一旦开始运行并行程序，就可能会出现内核之间的总线争用或缓存问题。
Pareon允许映射到特定的体系结构，这样就可以更准确地计算总线和缓存(以及其他)特征，从而得到的加速估计包括这些潜在的问题。他们还描述了操作系统调用延迟的特征，并与处理器供应商合作测量硅延迟，以便这些延迟都可以包含在性能评估中。
线程本身的开销不是微不足道的。事实上，如果您依赖于经典的线程创建和销毁，分区很可能会使并行程序比其连续的原始程序慢。因此，Pareon依赖于“工作线程”:在早期创建一系列线程，并将函数分配给这些线程(而不是创建新的线程)。
当空闲时，这些线程可以休眠——这意味着它们需要在分配时被唤醒和调度，这可能需要时间——或者被构造为“忙碌-等待”线程，在那里它们只是循环——这浪费了周期，但在许多深度嵌入式程序的情况下，只有一个进程在运行，没有什么可以调度来取代浪费的周期，可以容忍并节省时间。Pareon可以根据设置、定时和程序特性在两者之间进行选择。
到目前为止，我们所讨论的都是分区选项的选择，这往往是一个迭代过程:您找到一个大的时间用户并尝试对其进行分区。然后找到其他的并对它们进行划分，直到达到所需的性能(假设这是可能的)。
但这个工具只是记录你的决定;它实际上没有改变任何代码或产生输出。当你得到你想要的性能时，就像工具估计的那样，然后你需要实现它。理论上，这至少在一定程度上是可以自动化的，但程序员通常不希望有工具为他们编写代码或更改他们的代码。因此，Pareon提供了一系列“重构步骤”(以前称为“配方”)来进行代码更改。其目的是这些步骤可以一次实现一个，并且每个步骤都会生成一个可运行的程序，在执行下一步之前可以对该程序进行验证。
这些步骤将引导您完成拆分子例程、创建和使用线程以及实现用于同步非流循环携带的依赖项的信号量的过程。它们提供了简化信号量实现中比较棘手的部分的库。
可能听起来像是Pareon可以为每个人做所有事情，有很多不同的实现多核系统的方法，Pareon不支持所有的方法(至少目前)。它们的语言支持是C和c++。他们可以处理ARM和x86架构，专注于平板电脑、手机和桌面应用程序。他们对其他架构持开放态度(如果有资金的话)。它们只生成SMP实现，并且只实现数据并行(函数并行已经成为“实验室”的一个特性，将在未来正式发布)。
也就是说，正如你可以想象的那样，他们试图解决一个有很多用途的市场领域，并且C、c++、ARM和SMP在嵌入式系统中具有重要的功能也就不足为奇了(x86是免费的，因为运行Pareon的主机工具运行在基于x86的机器上)。目前最常见的AMP系统要么是像手机这样的东西，不同的核心运行不同的程序，几乎没有交互，要么是分组处理，有自己的专门的做事方式，而且已经有很多年了。像Pareon这样的工具在那里不太可能有吸引力，因为这些程序从一开始就为并行而编写。
Pareon更多地针对计算密集型算法，如图形或视频处理，加速各种编码和其他算法。在这些情况下，很多时候算法都是从连续的C程序开始的，然后必须在多核平台上实现。像这样的工具旨在使“困难的部分”变得更容易一些。
更多信息:
您是否必须手动进行程序分区?你今天是怎么做到的?