【问题标题】:Simplifying algorithm testing for researchers.为研究人员简化算法测试。
【发布时间】:2009-05-17 22:51:59
【问题描述】:

我在一个从事大量研究开发和完整运输代码的团队工作。

我有一半时间开发在我们的实时系统上运行的流程(介于软实时和硬实时之间,中等实时?)

另一半我为那些根本不关心代码的研究人员编写或优化流程。

目前我正在处理一个我必须分成两个不同分支的过程。

一个组有一个研究版本,一个生产版本需要偶尔与研究代码合并,以便将最新和最好的版本投入生产。

要测试这些流程,您需要设置一个半复杂的测试环境,以便在正确的时间将我们分析的数据发送到流程(实时系统)。

我正在考虑如何制作:

  1. 想法
  2. 实施
  3. 测试
  4. 转到 #1

让我的同事尽可能轻松、快速、无痛地骑自行车。

我的一个想法是在这些长期运行的进程中嵌入一种脚本语言。 因此,随着流程的运行,他们可以调整实际算法及其参数。

我立即查看了嵌入:

这些似乎都是可行的,实际上可能完全解决给定的问题。

还有什么好主意吗?

在 1-2 行更改后重新编译,重新部署到测试环境并重新启动很糟糕。

系统相当复杂,希望我解释得体面。

【问题讨论】:

  • 你的实时系统是什么样的平台?
  • Linux,具有所有 IO 的所有自定义内部库。生产系统在内部 Linux 集群上运行。

标签: c++ scripting real-time


【解决方案1】:

如果您可以通过脚本更改足够多的程序以使其有用,而无需完全重新编译,也许您应该考虑将系统分解为更小的部分。您可以有一个“服务器”来处理数据加载等,然后是执行实际处理的客户端代码。每次系统加载新数据时,它都会检查并查看客户端代码是否已重新编译,如果是,则使用它。

我认为这里有几个优点,其中最大的优点是整个系统不会那么复杂。现在您使用一种语言而不是两种语言工作。人们在头脑中从 python 或 lua 模式转移到 c++ 模式时,不太可能搞砸事情。通过在系统中嵌入一些其他语言,您也会冒着依赖它的风险。如果您使用 python 或 lua 来 tweek 程序,这些语言要么在需要部署时成为依赖项,要么您需要将事情退回到 C++。如果您选择将内容移植到 C++,则在切换期间还有另一个机会出现错误。

【讨论】:

    【解决方案2】:

    嵌入 Lua 比嵌入 Python 容易得多。

    • Lua 从一开始就是为嵌入而设计的; Python 的可嵌入性是事后嫁接的。

    • Lua 比 Python 小约 20 倍且简单。

    您不会过多地谈论构建过程,但是使用真正强大的 make 版本可以显着简化构建和测试。我使用 Andrew Hume 的 mk,但您最好花时间掌握 Glenn Fowler 的 nmake,它可以即时添加依赖项并消除对单独配置步骤的需要。我通常不推荐 nmake,因为它有些复杂,但很明显,Fowler 和他的团队已经为 很多 扩展和可移植性问题构建了 nmake 解决方案。对于您的特定情况,可能值得努力掌握它。

    【讨论】:

    • 我们目前确实使用了一个相当复杂的基于 make 的构建系统。正如您所描述的,它使用动态依赖项,这很棒。无论如何都是好建议。而且我更倾向于lua,我同意你的子弹。
    【解决方案3】:

    不确定我是否了解您的系统,但如果构建和部署过于复杂,也许您可​​以将其自动化?如果部署是完全自动的,那会解决问题吗?

    我不明白脚本语言如何解决问题?如果你改变你的算法,你仍然需要从头开始计算,不是吗?

    【讨论】:

    • 系统已设置好,因此您启动进程并等待数据。每 N 分钟周期将数据馈入系统。我曾设想我会阅读有关数据接收事件的脚本。因此,您可以在更新期间或中间进行更改,下一次更新将与您的新更改一起运行。
    • 虽然构建系统并不完美,但这并不是真正的问题。
    【解决方案4】:

    听起来你需要的是CruiseControl 或类似的东西;每次你接触基线代码时,它都会重新构建并重新运行测试。

    【讨论】:

    • 我有 buildbot 设置,用于持续集成。但结果并不是真正可测试的。这更像是科学家不得不坐下来分析结果的情况。
    • 听起来测试过程本身就是你的问题;让科学家参与似乎不是最理想的。与已知输出相比,为什么不使用已知输入构建一组测试呢?
    • 研究领域是天气,算法的开发主要是对算法的改进。虽然这是一个好主意,但为已知的良好输入和输出生成完整的案例数据可能比节省时间更多。
    • 你不能从过去的数据中捕获测试用例吗?