在听StackOverflow播客的时候,经常有人说“真正的程序员”是用C语言编写的,而C语言的速度要快得多,因为它“接近机器”。把前面的断言留到另一篇文章,C有什么特别之处,使它比其他语言更快?或者换句话说:什么能阻止其他语言编译成二进制代码,使其运行速度与C语言一样快?
当前回答
我还没有看到它,所以我要说:C往往更快,因为几乎所有其他东西都是用C写的。
Java是建立在C上的,Python是建立在C上的(或者Java,或者。net等等),Perl是等等。操作系统是用C写的,虚拟机是用C写的,编译器是用C写的,解释器是用C写的,有些东西仍然是用汇编语言写的,这往往更快。越来越多的东西是用别的东西写的,而这些东西本身就是用C写的。
您用其他语言(不是Assembly)编写的每个语句通常都在下面实现为C中的几个语句,这些语句被编译为本机机器代码。由于其他语言的存在往往是为了获得比C更高的抽象级别,因此C中所需的那些额外语句往往侧重于增加安全性、增加复杂性和提供错误处理。这些通常都是好事,但它们是有代价的,那就是速度和规模。
就我个人而言,我已经用几十种语言写过了,涵盖了大部分可用的范围,我个人也一直在寻找你暗示的魔法:
我怎样才能鱼与熊掌兼得呢?我如何在我最喜欢的语言中玩高级抽象,然后为了速度而降至C语言的细节?
经过几年的研究,我的答案是Python(在C上)。你可能想看看它。顺便说一下,您也可以从Python下拉到Assembly(从一个特殊的库中获得一些小小的帮助)。
另一方面,任何语言都可能编写出糟糕的代码。因此,C(或汇编)代码不会自动更快。同样,一些优化技巧可以使部分高级语言代码的性能水平接近原始c语言的性能水平。但是,对于大多数应用程序来说,程序的大部分时间都在等待人员或硬件,因此两者之间的差异实际上并不重要。
享受。
其他回答
c语言并没有什么特别之处,这也是它速度快的原因之一。
新语言支持垃圾收集、动态类型和其他功能,使程序员更容易编写程序。
问题在于,会有额外的处理开销,这会降低应用程序的性能。C语言没有这些,这意味着没有开销,但这意味着程序员需要能够分配内存并释放它们以防止内存泄漏,并且必须处理变量的静态类型。
也就是说,许多语言和平台,如Java(其Java虚拟机)和。net(其公共语言运行时),多年来通过即时编译(从字节码生成本机机器代码以实现更高性能)等技术改进了性能。
如果你花了一个月的时间用C语言构建的程序只需要0.05秒,而我花了一天的时间用Java写同样的程序,只需要0.10秒,那么C语言真的更快吗?
但是回答你的问题,编写良好的C代码通常会比其他语言编写的代码运行得更快,因为编写良好的C代码的一部分包括在接近机器的级别上进行手动优化。
尽管编译器确实非常聪明,但它们还不能创造性地提出与手工按摩算法竞争的代码(假设“手”属于一个优秀的C程序员)。
编辑:
很多评论都是这样的:“我用C语言编写,我不考虑优化。”
举个具体的例子:
在Delphi中我可以这样写:
function RemoveAllAFromB(a, b: string): string;
var
before, after :string;
begin
Result := b;
if 0 < Pos(a,b) then begin
before := Copy(b,1,Pos(a,b)-Length(a));
after := Copy(b,Pos(a,b)+Length(a),Length(b));
Result := before + after;
Result := RemoveAllAFromB(a,Result); //recursive
end;
end;
用C语言写:
char *s1, *s2, *result; /* original strings and the result string */
int len1, len2; /* lengths of the strings */
for (i = 0; i < len1; i++) {
for (j = 0; j < len2; j++) {
if (s1[i] == s2[j]) {
break;
}
}
if (j == len2) { /* s1[i] is not found in s2 */
*result = s1[i];
result++; /* assuming your result array is long enough */
}
}
但是C版本中有多少优化呢?我们在实现方面做了很多我在Delphi版本中没有考虑到的决定。字符串是如何实现的?在特尔斐我看不出来。在C语言中,我已经决定它将是一个指向ASCII整数数组的指针,我们称之为字符。在C语言中,我们每次测试一个字符的存在性。在Delphi中,我使用Pos。
这只是一个小例子。在一个大型程序中,C程序员必须对每几行代码做出这类低级决策。它加起来就是一个手工制作、手工优化的可执行文件。
不要轻信别人的话,看看在代码的任何性能关键部分,C语言和你选择的语言的反汇编。我认为你可以在Visual Studio运行时的反汇编窗口中看到已分解的. net。如果Java使用windbg有点棘手,应该是可能的,尽管如果你用。net来做,许多问题将是相同的。
如果没有必要的话,我不喜欢用C来编写,但我认为,这些回答中吹捧除C之外其他语言的速度的许多主张可以放在一边,只需用C和您选择的高级语言分解相同的例程,特别是如果涉及大量数据(这在性能关键型应用程序中很常见)。Fortran在其专业领域可能是个例外,不知道。它比C高吗?
第一次比较JITed代码和本地代码时,我解决了。net代码是否能与C代码运行得相当的所有问题。额外的抽象层次和所有的安全检查都带来了巨大的成本。同样的成本可能也适用于Java,但不要相信我的话,在性能至关重要的地方尝试一下。(有没有人足够了解JITed Java来在内存中找到一个编译过的过程?这当然是可能的)
c++的平均速度更快(就像它最初一样,主要是C的超集,尽管有一些不同)。然而,对于特定的基准测试,通常有另一种更快的语言。
https://benchmarksgame-team.pages.debian.net/benchmarksgame/
fannjuch-redux是Scala中最快的
n-body和fasta在Ada中更快。
频谱范数在Fortran中是最快的。
反补、mandelbrot和pidigits在ATS中最快。
regex-dna是JavaScript中最快的。
chameneau -redux最快的是Java 7。
Haskell的螺纹环速度最快。
其余的基准测试在C或c++中是最快的。
我认为没有人提到这样一个事实,即在C编译器上投入的精力比任何其他编译器都要多,也许Java是例外。
由于前面提到的许多原因,C是非常可优化的——几乎比任何其他语言都要多。因此,如果在其他语言编译器上投入同样的精力,C可能仍然会名列前茅。
I think there is at least one candidate language that with effort could be optimized better than C and thus we could see implementations that produce faster binaries. I'm thinking of digital mars D because the creator took care to build a language that could potentially be better optimized than C. There may be other languages that have this possibility. However I cannot imagine that any language will have compilers more than just a few percent faster than the best C compilers. I would love to be wrong.
我认为真正的“唾手可得的果实”将是那些被设计为易于人类优化的语言。一个熟练的程序员可以让任何语言运行得更快——但有时你不得不做一些荒谬的事情或使用不自然的结构来实现这一点。尽管这总是需要付出努力,但一种好的语言应该产生相对快速的代码,而不必纠结于程序究竟是如何编写的。
It's also important (at least to me) that the worst case code tends to be fast. There are numerous "proofs" on the web that Java is as fast or faster than C, but that is based on cherry picking examples. I'm not big fan of C, but I know that ANYTHING I write in C is going to run well. With Java it will "probably" run within 15% of the speed, usually within 25% but in some cases it can be far worse. Any cases where it's just as fast or within a couple of percent are usually due to most of the time being spent in the library code which is heavily optimized C anyway.