【问题标题】:We have to use C "for performance reasons" [closed]我们必须“出于性能原因”使用 C [关闭]
【发布时间】:2010-11-16 11:02:09
【问题描述】:

在这个语言众多的时代,几乎每项任务似乎都有一门很棒的语言,我发现自己在专业上与“C 语言快”这样的口头禅作斗争,其中快是真正的意思是“足够快”。我与非常理性、思想开放的人一起工作,他们喜欢比较数字,而我所拥有的只是想法和意见。你能帮我找到摆脱主观意见进入“现实世界”的方法吗?

您能帮我找到有关是否可以将任何其他语言用于嵌入式和 (Linux) 系统编程的研究吗?我很可能会提出一个错误的假设,并且非常感谢研究向我展示这一点。能否请您链接或包含好的数字,以帮助将“这只是他/她的意见”cmet 保持在最低限度。


所以这些是我的特殊要求

  • 内存不是一个严重的限制
  • 便携性不是一个严重的问题
  • 这不是实时系统

【问题讨论】:

  • 很难找到数字来证明某些事情实际上是错误的。
  • 会谨慎对待过早的优化参数。如果处理能力有限,并且需要实时或接近实时地完成一定数量的工作,而你选择的语言比你拥有的工作需要更多的处理能力,那你就完蛋了,因为你现在必须用一种有能力的语言重新开始。更多信息weblogs.mozillazine.org/roc/archives/2005/11/…
  • 问题的语法和内容有点乱。
  • 一个写得好的 VB 程序可以胜过一个写得不好的 C 程序。不是语言快(我可以编写一个 C 编译器生成非常慢的代码),而是你使用语言的方式。
  • “过早优化是万恶之源”,但过早优化和过早悲观化之间有一条细线。后者应与前者一起避免。例如,尝试在嵌入式系统上编写光线追踪器并选择 Python,已经相当悲观。使用解释器实现这样的目标是不现实的。

标签: c linux embedded systems-programming


【解决方案1】:

根据我的经验,使用 C 进行嵌入式和系统编程不一定是性能问题 - 它通常是可移植性问题。在几乎所有平台上,尤其是在嵌入式系统平台上,C 往往是最可移植、最受支持的语言。

如果您希望在嵌入式系统中使用其他东西,通常需要弄清楚哪些选项可用,然后确定性能、内存消耗、库支持等是否适合您的情况。

【讨论】:

  • 确实如此。嵌入式软件倾向于用 C 语言编写,因为多年来一直这样做,因此嵌入式软件工程师更有可能精通 C 语言而不是任何其他语言。因此,编译器生产商将选择销售最好的语言,即 C 和可能的 C++。
  • 当然,Python 是用 C 编写的,许多解释工具也是如此。只需一点点工作,您就可以在许多平台上使用 Python。
  • 是的 - Python 可以。我什至使用过 Lua(因为它的开销很小)。内存开销和库支持可能是 pythong 之类的问题。
  • 是的 - 我完全同意这一点。在我的前任雇主那里,当然有一种文化精神偏向于 C(和汇编程序)以外的任何东西,但最重要的是,支持 C 以外的任何东西的嵌入式系统的专业级工具集非常少。你 可能找到对 C++ 的工具集支持,在极少数情况下,Java。有一些针对其他语言(例如 Erlang)的垂直堆叠的利基平台,但这些平台几乎不可能出售给管理层,尤其是对于现有系统。
  • 真实数据——如果性能是您最关心的问题,那么为什么要停在 C 语言上呢?用 C 语言编写第一遍(编译器非常好,所以这是一个很好的起点),然后手动检查程序集。许多系统都有编译器通常不支持的效率技巧。
【解决方案2】:

“Nothing but C is fast [enough]”是一种早期优化,并且由于早期优化错误的所有原因都是错误的。如果您的系统具有足够的复杂性以至于需要 C 以外的其他东西,那么系统的某些部分必须“足够快”,而某些部分的约束更轻。例如,如果用 Python 编写代码可以更快地完成项目,并且错误更少,那么您可以跟进一些 C 或汇编代码来加快时间关键部分的速度。

即使事实证明整个代码必须用 C 或汇编语言编写才能满足性能要求,使用 Python 等语言进行原型设计也能带来真正的好处。您可以使用您的工作 Python 原型并逐渐用 C 代码替换部分,直到达到必要的性能。

因此,请使用能够让您最正确、最快速地完成开发工作的工具,然后使用真实数据来确定您需要优化的地方。有时,C 可能是最合适的入门工具,但肯定并非总是如此,即使在嵌入式系统中也是如此。

【讨论】:

  • 更好的是,用英文(文本)、流程图、数据结构图等做原型,然后编写一次应用程序。用任何语言制作原型都知道它不能满足您的要求是一个非常糟糕的主意。就个人而言,我发现 C/C++ 很好地融合在一起并利用了相同的技能集,而 Java、Python 等会产生很多学习干扰,因为它们的不同之处足以让 C 语言在你回到它时会惩罚你。 “练习过轮胎跑的足球运动员会擅长轮胎跑”。
  • " 在 Python 中将使项目更快地完成" 它的运行速度也会慢 100 倍,并且很可能会变得如此耗费资源,以至于它使程序在大多数运行时应用程序上运行时出现故障和延迟。如果你完全关心性能,Python 是一个禁忌,即使这样,如果你不将它用于生产代码,它也是一个不错的选择,如果你想将 python 用于生产代码,至少包含一个 C 框架。 ...
  • “你可以使用你的工作 Python 原型,并逐渐用 C 代码替换部分,直到你达到必要的性能。”使用混合语言格式通常会使代码更难调试而不是更容易。如果我要求我的大多数同事维护 C 代码,而 Python 代码片段会在意想不到的地方弹出......
  • “C 语言有时可能是最合适的入门工具,但肯定并非总是如此,即使在嵌入式系统中也是如此。”在嵌入式系统中,有 4 种语言可以满足性能要求,其中两种是相当新的,即 C、C++、Rust 和 Go lang。这当然忽略了汇编、机器语言、Fortran 和 Lisp 等古老语言。
【解决方案3】:

在嵌入式系统中使用 C 有一些很好的理由,其中“性能”只是次要因素之一。嵌入式非常接近硬件,您需要手动内存寻址才能与硬件通信。所有 API 和 SDK 大部分都可用于 C。

只有少数平台可以为 Java 或 Mono 运行 VM,部分原因是性能影响,但也因为实施成本高昂。

【讨论】:

    【解决方案4】:

    除了性能之外,还有另一个考虑因素:您很可能会处理设计用于 C 或 C++ 的低级 API

    如果您不能使用某些 SDK,您只会给自己带来麻烦,而不是通过使用更高级别的语言进行开发来节省时间。至少,你最终会重做一堆函数声明和常量定义。

    【讨论】:

      【解决方案5】:

      对于 C:

      • C 通常是处理器编译器支持的唯一语言。
      • 大多数库和示例代码也是 C 语言中的概率。
      • 大多数嵌入式开发人员都有多年的 C 经验,但在其他方面的经验却很少。
      • 允许直接硬件接口和手动内存管理。
      • 易于与汇编语言集成。

      C 将存在很多年。在嵌入式开发中,它是一种垄断,扼杀了任何改变的尝试。需要像 Java 或 Lua 这样的 VM 的语言永远不会成为嵌入式环境的主流。如果编译语言提供了优于 C 的引人注目的新功能,它可能会有机会。

      【讨论】:

      • eLua 在嵌入式设备领域的应用相当广泛。
      • 数据库具有 ACID 属性,FAT 已被故障安全 ext4、HFS+ 和 NTFS 取代,同样 C 必须逐步淘汰。也许不完全,就像 FAT 总是在附近,但不是在敏感的地方。用 C 语言编写会推迟进度。
      • @OCTAGRAM:为什么投反对票? ext4 是用 C 编写的。用 C 编写从您的示例中似乎带来了进步。是的,C 并不是所有地方的正确答案,但对于嵌入式和 OS 环境,它是一个很好的匹配。
      • C 必须首先与 Ada、Modula-2、Pascal 进行比较。您提到 Java 和 Lua,这是一个稻草人谬误,非常危险。 Wrt 编译器可用性,Ada 和 SPARK 可用于 AVR、MIPS 和 ARM,涵盖大多数嵌入式需求。进步是ext4本身,但它的实现语言是悲剧。
      【解决方案6】:

      网络上有多种不同语言之间的基准测试。其中大多数您会在顶部找到 C 或 C++ 实现,因为它们可以让您更好地控制以真正优化事物。

      例如:The Computer Language Benchmarks Game

      【讨论】:

        【解决方案7】:

        很难反对 C(或其他过程语言,如 Pascal、Modula-2、Ada)和嵌入式汇编。这些语言有着悠久的成功历史。通常,您希望消除未知风险。在我看来,尝试使用 C 或汇编以外的任何东西都是未知数。话虽如此,在混合模型中使用 C、Python、Lua 或 JavaScript 作为脚本语言的方案之一并没有错。

        您想要的是能够在必要时快速轻松地转到 C 语言。

        如果您说服团队采用他们未经证实的东西,那么该项目就是您的 cookie。如果它崩溃了,很可能会被视为你的错。

        【讨论】:

          【解决方案8】:

          This article(作者:Michael Barr)讨论了 C、C++、汇编程序和其他语言在嵌入式系统中的使用,并附有一张图表,显示了每种语言的相对用法。

          这是另一篇文章,标题恰如其分,Poor reasons for rejecting C++

          【讨论】:

            【解决方案9】:

            Ada 是一种高级编程语言,专为嵌入式系统和关键任务系统而设计。

            它是一种快速安全的语言,在任何地方都内置了数据检查功能。飞机上的自动驾驶仪就是这样编程的。

            this link,您可以比较 Ada 和 C。

            【讨论】:

            • 我过去使用过 ADA,现在很想使用它,但我找不到可以生成代码以在我的 2K ROM/256 字节 RAM 环境中运行的版本。
            【解决方案10】:

            在某些情况下,您需要实时性能,尤其是在嵌入式系统中。你也有严重的内存限制。像 C 这样的语言可以让您更好地控制执行时间和执行空间。

            因此,根据您的工作,C 很可能“更好”或更合适。

            查看以下文章

            【讨论】:

            • www.pythononachip.org 是一个在没有操作系统、没有 MMU 和只有 8 KB RAM 的微控制器上运行 PyMite VM 的项目。
            【解决方案11】:

            C 无处不在,几乎可用于任何架构,通常从处理器可用的第一天开始。 C++ 紧随其后。如果您的系统可以支持 C++ 并且您具有必要的专业知识,请优先使用它而不是 C - 它就是 C 的全部,甚至更多,所以没有什么理由不使用它。

            C++ 是一种更大的语言,支持的结构和技术可能会消耗资源或在嵌入式系统中以不可接受的方式运行,但这不是不使用该语言的理由,而是如何适当地使用它。

            Java 和 C#(在 Micro.Net 或 WinCE 上)可能是非实时的可行替代方案。

            【讨论】:

              【解决方案12】:

              您可能想查看D 编程语言。它可以使用一些性能调整,因为 Python 在某些领域可以胜过它。由于没有列出清单,因此我无法真正向您指出基准比较,但正如 Peter Olsson 所指出的那样,Benchmarks & Language Implementations 拥有 D Digital Mars。

              您可能还想看看这些可爱的问题:

              【讨论】:

                【解决方案13】:

                我并不是真正的系统/嵌入式程序员,但在我看来,嵌入式程序通常需要确定性性能 - 这立即排除了许多垃圾收集语言,因为它们通常不是确定性的.然而,确定性垃圾收集方面的工作已经开展(例如,Java 的 Metronome:http://www.ibm.com/developerworks/java/library/j-rtj4/index.html

                问题是约束之一 - 语言/运行时是否满足确定性、内存使用等要求。

                【讨论】:

                • 删除 GC 并不能解决问题,malloc/free 是不确定的。 D 编程语言允许您禁用 GC,因此它不会在关键代码期间运行。
                • 低端嵌入式处理器的软件往往不使用 malloc/free,但它很可能使用由外部事件触发的中断,这是不可预测的,因此是非确定性的 - 无论语言如何用过。
                • 通常,malloc/free 在确定性系统中是不允许的(或者它们被重写)。 @Steve:您可以创建确定性中断处理,为您提供时间限制。
                【解决方案14】:

                C 确实是您的最佳选择。

                编写可移植的 C 代码和深入了解特定编译器的 ghee whiz 功能或语言的极端情况(所有这些都应该避免)是不同的。但是跨编译器和编译器版本的可移植性。能够开发或维护代码的员工数量。编译器将更轻松地使用它,并生成更好、更清洁、更可靠的代码。

                C 不会去任何地方,所有新语言都旨在修复所有先前语言中的缺陷。 C,尽管这些新语言试图修复的所有缺陷,仍然很强大。

                【讨论】:

                  【解决方案15】:

                  这里有几篇比较 C# 和 C++ 的文章:

                  http://systematicgaming.wordpress.com/2009/01/03/performance-c-vs-c/

                  http://journal.stuffwithstuff.com/2009/01/03/debunking-c-vs-c-performance/

                  不完全符合您的要求,因为它不关注嵌入式 C 编程。但这仍然很有趣。第一个演示了 C++ 的性能以及将“不安全”代码用于处理器密集型任务的好处。第二个在某种程度上揭穿了第一个,并表明如果您编写的 C# 代码稍有不同,那么性能几乎相同。

                  所以我会说,在许多情况下,C 或 C++ 在性能方面可以成为明显的赢家。但很多时候,利润是微乎其微的。是否使用 C 完全是另一个话题。在我看来,这真的应该取决于手头的任务。但在嵌入式系统中,您通常没有太多选择。

                  【讨论】:

                  • 或者您可以说“表明如果您编写的 C# 代码稍有不同,那么性能仍然会变慢”。不像以前那么慢,但仍然更慢。现在,在我的 3xcore、4GB 台式电脑上,这可能并不意味着我会注意到差异……但在 10Mhz 嵌入式 CPU 和 64Mb RAM 上,差异可能非常显着。
                  • 实际上,如果您阅读第二篇文章,他无法确定哪个更快完成这项特定任务(它们非常接近)。但我同意——C# 的开销要大得多,而且在低功耗嵌入式系统中不会那么令人印象深刻。
                  【解决方案16】:

                  有几个人提到了 Lua。我认识的使用过嵌入式系统的人都说 Lua 很有用,但它本身并不是它自己的语言,而更像是一个可以嵌入到 C 中的库。它的目标是在嵌入式系统中使用,通常你会想要从 C 调用 Lua 代码。但是纯 C 使得维护更简单(虽然不一定更容易),因为每个人都知道。

                  【讨论】:

                    【解决方案17】:

                    根据嵌入式平台,如果内存限制是一个问题,您很可能需要使用非垃圾收集的编程语言。

                    在这方面,C 可能是团队中最知名的,并且可用库和工具得到最广泛的支持。

                    【讨论】:

                      【解决方案18】:

                      事实是 - 并非总是如此。

                      似乎 .NET 运行时(但可以以任何其他运行时为例)强加了几 MB 的运行时开销。如果这就是你所拥有的(在 RAM 中),那么你就不走运了。 JavaME 似乎更紧凑,但它仍然完全取决于您可以使用的资源。

                      【讨论】:

                      • dotNet Compact 框架是 JavaME 的移动版。
                      【解决方案19】:

                      即使在桌面系统上,C 编译器也快得多,因为与 C++ 相比,语言功能很少,所以我想在嵌入式系统上差异不小。这意味着更快的迭代时间,尽管 OTOH 您没有 C++ 的便利(例如集合),从长远来看可能会减慢您的速度。

                      【讨论】:

                        猜你喜欢
                        • 1970-01-01
                        • 2015-01-20
                        • 2019-11-19
                        • 2012-03-23
                        • 2021-11-13
                        • 2011-08-16
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        相关资源
                        最近更新 更多