【问题标题】:How can one create a data flow graph (DFG/SDFG) for any application from its source code如何从源代码为任何应用程序创建数据流图 (DFG/SDFG)
【发布时间】:2017-05-19 07:50:57
【问题描述】:

我进行了大量研究,以弄清楚如何从源代码为应用程序创建 DFG。某些应用程序(如 MP3 解码器、JPEG 压缩和 H.263 解码器)可在线获得 DFG。

我无法弄清楚如何从源代码为 HEVC 等应用程序创建 DFG?是否有任何工具可以立即为此类复杂的应用程序生成数据流图,还是必须手动完成?

请就此事给我建议。

编辑: 我将 Doxygen 用于 HEVC,我可以看到不同的功能是如何相互作用的。然而,每个函数都有很多入口和出口点,一段时间后 Doxygen 的输出变得太混乱而无法理解。

我也看过 StreamIt:http://camlunity.ru/swap/Library/Conflux/Stream%20Programming/streamit-cc_stream_graph_programming_language.pdf

它看起来很方便,但它为更简单的应用程序(如 MP3 解码器)生成的图表太复杂了。 为了生成连贯的 DFG,我是否必须重新编写整个源代码?

【问题讨论】:

  • 请澄清:当您说“任何应用程序”时,您的意思是“any 编程语言中的any 应用程序”吗?还是“*针对某种特定编程语言的任何应用程序”?
  • @IraBaxter 非常感谢您的回复。我的意思是任何编程语言的任何应用程序。
  • @IraBaxter 我对 HEVC 等大型复杂应用程序特别好奇。
  • HEVC 是用 C 编码的? C++?
  • @IraBaxter 它是用 C++ 编码的。 [bitbucket.org/multicoreware/x265/wiki/Coding]

标签: algorithm data-structures parallel-processing open-source dataflow


【解决方案1】:

您想从任意语言中提取数据流图。你暗示你想要一种方法来做到这一点。这手动不实用...你需要一个工具。

这样的工具很难构建。

为此,对于每种语言,您必须能够:

  • 以您在实践中找到的形式定义工具的语言(不仅仅是语言参考手册版本)。与标准相比,狂野的 C++ 有很多有趣的方式。
  • 用在现场找到的语言解析程序,可能是一个文件,可能是数万个文件;有些程序并不小。
  • 构建表示语言元素及其相互关系的结构(这通常作为抽象语法树完成)
  • 确定每个文字的实际值是多少; "a\xbc" 具有非常不同的值,具体取决于语言是否认为它是带有转义序列的 ascii 或 unicode 文本
  • 查找代码中的所有标识符,并根据语言范围规则为每个标识符确定与其关联的定义/类型信息
  • 确定数据源(文字值、来自外部世界的输入、表达式的结果)并跟踪这些数据值在程序的其他部分中跨各种控制流构造的位置
  • 大概会绘制一些结果数据流的图片。

这些任务本身都很困难,因为语言往往很复杂。大多数可以做到这一点的语言工具(主要是编译器)只为该语言的一种方言做到这一点。

要针对一种以上的语言/方言执行此操作,您需要一个可以针对每种语言配置所有详细信息的工具,并且您必须针对所有感兴趣的语言进行配置。 [实际上,您不能“全部完成”;现在有数千种计算机语言在使用]。

即使将自己限制在“日常”的通用编程语言中,这也是一项巨大的工作量;一种主流语言可能需要几年时间才能做好这一切。你自己不会成功。

我的公司构建了一个单一的、统一的工具,旨在能够做到这一点:DMS Software Reengineering Toolkit。简单的“秘密”是要意识到the machinery needed to accomplish the above tasks 在不同语言之间实际上非常相似,并且可以通过相对适度(这并不意味着“小”)的努力设计为针对特定语言进行配置。

经过20 年线性工程与博士级工程师团队,我们有parsers (even this is hard)surprising variety of languages,完整的data flow analyzers 与您谈论的类型@ 987654326@、C、COBOL 和几乎 Java 8。

我不知道有任何其他统一工具离您的理想如此遥远。在您决定我对此一无所知之前,请检查我的简历。 (Rascal/MPL 有一些野心,但在这一点上只是一个研究工具;他们根本不使用 C 或 C++)我们只是完成了一部分,还有许多语言和规模的战斗要打。

[DMS 的目标不是数据流分析;这只是一块垫脚石。就是做自动化的代码转换,需要数据流分析才能安全正确的做】。

当然,您可能只是希望为每种语言找到一个单独的工具。如果您确实可以获得一整套此类工具,您将无法从来自不同作者的不同工具中获得一致的质量或一致的数据流图样式/粒度。

【讨论】:

  • 好的,点赞。我不想写一个与这个竞争的答案......但真正的答案是,在大多数情况下,OP 想要看到的数据流并不存在于实际实现的数据流中。源中通常会有大块对应的东西,但它们之间的数据流动会很复杂,而且是有状态的。
  • 大概。那篇论文的概念(可能还有类似的“任务图调度器”论文)是一个非常聪明的工程师找出理想的任务图,然后强制应用程序结构匹配它;然后调度员会声称各种奇妙的调度来最小化执行时间。失败的地方在于您有不想破坏的工作代码(例如,HVEC);现在你必须发明这样一个理想可调度的任务图,你可以弯曲 HVEC 来处理。您首先发现 HVEC 是一个复杂的野兽......
  • ... 并且仅仅大致了解它如何传递数据和序列活动将会很困难;为此,您确实想要自动提取。然后你可以决定 real 图的哪些部分是有用的,哪些部分是笨拙的,以及你想如何手动修改代码以制作可行/可调度的任务图。这比听起来要难得多。对于复杂的应用程序,人们几乎无法做到这一点。现在的想法是获取真正提取的图,并安排 that;但它不是 15 个任务节点,而是数千个更细粒度的节点。没有简单的答案。
  • 人们主要通过手动推理数据流来做到这一点。在并行计算世界中,经常需要工具来帮助做到这一点。大多数情况下没有人回答这些请求;手工建造需要太多的机器。我们通过共享基础设施解决此类问题的方法是试图改变构建此类工具的经济性。 (数据流抽象 AFAIK 只是将许多数据流从一个程序区域到另一个程序区域捆绑到一个程序区域中;这实质上产生了对计算的控制流排序约束)。
  • 从经典数据流计算的介绍开始:ece.cmu.edu/~ece740/f13/lib/exe/… 想法很好,但你不能这样构建真正的程序;算子粒度太小,同步开销太大,会压垮实际的计算工作。秘密是聚合/抽象起来;获取个微小的数据流算子并将它们组合成一个顺序计算;现在开销是按组而不是按操作员支付的......
猜你喜欢
  • 1970-01-01
  • 2011-05-21
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多