gcc 64bit编译器不提供任何速度优势 [英] gcc 64bit compiler does not offer any speed advantage
问题描述
我必须说我没想到这一点。我刚刚在FreeBSD上做了一些措施
6.2和gcc 3.4.6并且在32位和64位模式之间没有显着差异
- 无论是编译速度还是编译速度都没有
编译结果的速度。
作为基准测试我采用了SmallEiffel编译器的引导程序（
有38个文件约100 kloc）。我得到的时间非常可靠。
可靠。 bootstraping（从最后的eiffel
编译器阶段编译c文件，然后使用它重新生成eiffel编译器
和所有工具）采取
32位：2,58（墙），2,57（用户），0,3（系统）= exe大小：
1,757,177字节
64位：2,48（墙），2,42（用户），0,5（系统）= exe大小：
2,179,326字节
这是衡量质量的标准生成的代码
仅汇编
13,9（32位）< -16,2（64位）sec -O0
33,5（32位）< -31,4（64位）sec -02
55,7（32位）< -51,9（64位）sec -03
所以新的寄存器只是没有给出额外的内存开销所消耗的任何好处。
我很惊讶gcc的代码生成部分（编译器的速度为
）也是一样的，因为这是最可怕的
弱点我的任何发展（它与eiffel
编译器的工作原理有关。 MSVC快16倍（使用预编译头）
gcc（没有预编译头）。我无法再次比较它们因为操作系统现在在不同的机器上但是预编译的标题是
在gcc上几乎无用 - 以及Eiffel生成头文件的方式
已经很完美（每个c文件只有一个标题，每个文件的每个文件都是
）。我得到的结果是-8％（gcc 4.x）高达28％（gcc 3.4.6）。
所以我一直认为问题是gcc的代码生成器，
这是有道理的，因为SPARC上的Sun Studio 11每Mhz快4倍
然后是Intel86代码（因为
的简单调用约定编译器）和tinycc比gcc快9倍。两者都没有使用
预编译的头文件。
但额外的寄存器数量似乎并没有减少
的复杂性代码生成器。我真的不明白这一点。我认为这是一个一对一的过度设计的架构，它会减慢整个gnu系列的价值。
不幸的是只有其他可用的c编译器在linux上我可以测试
几乎和gcc一样慢。似乎英特尔只关心速度
的可执行文件。
那里有一些可用的东西（不幸的是，tinycc已经满了
$ b然后是gcc。这将使我的开发变得更加容易。
啊是的，在我的iMac PPC上我也试过了，codewarrior< -gcc只是
给了一点点比小于2倍的性能。但是这个编译器不再存在
了。 OpenWatcom也没有开发，lcc-
linux32 / lcc-linux64似乎还没有。
llotharaécrit：
我必须说我没想到这一点。我刚刚在FreeBSD上做了一些措施
6.2和gcc 3.4.6并且在32位和64位模式之间没有显着差异
- 无论是编译速度还是编译速度都没有
编译结果的速度。
我不希望别的什么。出于什么原因你会认为
64位更好？
作为基准，我采用了SmallEiffel编译器的引导程序（
有38个文件，大约100 kloc）。我得到的时间非常可靠。
可靠。 bootstraping（从最后的eiffel
编译器阶段编译c文件，然后使用它重新生成eiffel编译器
和所有工具）采取
32位：2,58（墙），2,57（用户），0,3（系统）= exe大小：
1,757,177字节
64位：2,48（墙），2,42（用户），0,5（系统）= exe大小：
2,179,326字节
$ b $你在用什么机器？没有它，绝对时间是没有意义的。
这是衡量生成代码质量的指标
汇编仅
13,9（32位）< -16,2（64位）sec -O0
33,5（32位）< ; -31,4（64位）sec -02
55,7（32位）< -51,9（64位）sec -03
因此，新的寄存器只是没有给出额外的内存开销所消耗的任何好处。
是的。代码膨胀和更大的内存占用消耗了新寄存器的好处
。
我很惊讶代码生成gcc的一部分（编译器的速度为
）也是一样的，因为这对于我的任何开发来说都是最可怕的弱点（它与如何相关） eiffel
编译器工作）。
lcc-win32比gcc快20倍。我认为大多数编译器比gcc更快
，因为gcc从未关心过这个问题。该团队显然已经实现了其他目标。
MSVC比使用预编译头文件快16倍（
gcc（没有预编译头文件）。我无法再次比较它们因为操作系统现在在不同的机器上但是预编译的标题是
在gcc上几乎无用 - 以及Eiffel生成头文件的方式
已经很完美（每个c文件只有一个标题，每个文件的每个文件都是
）。我得到的结果是-8％（gcc 4.x）高达28％（gcc 3.4.6）。
所以我一直认为问题是gcc的代码生成器，
这是有道理的，因为SPARC上的Sun Studio 11每Mhz快4倍
然后是Intel86代码（因为
的简单调用约定编译器）和tinycc比gcc快9倍。两者都没有使用
预编译的头文件。
但额外的寄存器数量似乎并没有减少
的复杂性代码生成器。我真的不明白这一点。我认为这是一个全面的过度设计的架构，可以减慢整个gnu系列的速度。
确切地说。这种情况的一个症状是-O2生成
更好的代码而不是-O3 ... -O9。
此类软件的问题这是唯一让人感兴趣的是b / b
，因为
认可归于将功能xxx添加到gcc的人。并且
永远不会从从gcc中删除不需要的功能xxx的人。
这意味着外行人对他/她的宠物感兴趣/>
项目，而不是很多人一般关心这个项目。
这意味着很多功能都会添加到软件中，但从来没有
a对所有优化进行了修改，以确定它是否很糟糕
来保持它们。
gcc项目的另一个重大难点是它是一个编译器
应该在任何地方运行，这意味着很多后端，因此很多问题都是b $ b。微软有更少的问题，因为它基本上在x86上运行，而且只在一个操作系统中运行
...
不幸的是唯一的其他可用的c Linux上的编译器我可以测试
几乎和gcc一样慢。似乎英特尔只关心可执行文件的速度
。
您可以使用lcc-lin64，但它在Linux下不是免费的，你有
买它。
那里有什么可用的东西（不幸的是，tinycc已经满了
的错误，而不是维持）至少快3-5倍
然后是gcc。它会让我的开发变得更容易。
是的，使用lcc-lin64。
啊是的，在我的iMac PPC上我也尝试了它，codewarrior< -gcc只有
给出的性能略低于2倍。但是这个编译器不再存在
了。 OpenWatcom也没有开发，而且lcc-
linux32 / lcc-linux64似乎还没有。
它们可用但需要一些调整。
我不希望别的什么。出于什么原因你会认为
64位更好？
仅适用于更好的寄存器模型。对于今天的计算机加速CPU来说，ISA似乎真的不那么重要了。很高兴看到
大地址空间没有给予很高的压力。但在进行最后的比较之前，我必须检查一下Boehm-Weisser-GC的速度。
< blockquote class =post_quotes>
32位：2,58（墙），2,57（用户），0,3（系统）= exe大小：
1,757,177字节
64位：2,48（墙），2,42（用户），0,5（系统）= exe大小：
2,179,326字节
你用的是哪台机器？没有它，绝对时间是没有意义的。
无意义。
它是一个AthlonX2 4400，但没有并行执行。数字本身
是
无关紧要我只是想指出数字是多么相等
（小于1％）甚至是exe大小只增加了20％。
起初我甚至预计程序编译错误所以
i添加了一个assert（sizeof（void *）= = 8）但是没关系。
lcc-win32比gcc快20倍。我认为大多数编译器比gcc更快
，因为gcc从未关心过这个问题。该团队显然是
的确如此。我认为这是一个很大的问题。
您可以使用lcc-lin64但它在linux下不是免费的，你有
来购买它。
只要价格合理，就不会有问题。但我需要
更多
信息。我购买了Code-Warriors Linux和Kylix。两者都是
可怕的错误
我从来没有让Kylix编译一个简单的hello世界。但是我跟
弗里德里希谈了一下这个，而且看起来你的方式更好了。有没有网站，
i看了他的Q网站上的
并且找不到任何东西。
你的在GCC编译器组中，post更加热门。
我猜你错了，或者在没有任何好处的地方。
在位板国际象棋程序（需要64位整数）中，有一个很大的加速b / b
。如果你的程序没有大量使用64位整数，那么
没有理由期望大幅提速（除非你需要访问超过2 GB RAM的
，这是64位型号
闪耀的另一个地方。
无论如何，如果你想使用GCC获得更好的性能
编译器套件，为什么不在无数GCC编译器中询问
新闻组？
如果你使用所有性能选项适合你的硬件和
进行配置文件引导优化，您可以获得非常接近商业编译器的性能。
I must say i didn''t expect this. I just did some measures on FreeBSD
6.2 with gcc 3.4.6 and there is absolutely no significant difference
between 32 and 64 bit mode - neither in compilation speed, nor in
speed of the compiled result.
As a benchmark i took a bootstrap of the SmallEiffel Compiler (which
has 38 files with around 100 kloc). The times i got were very
reliable. The bootstraping (compile the c files from last eiffel
compiler stage, and then use this to regenerated the eiffel compiler
and all tools) took
32Bit: 2,58 (wall), 2,57 (user), 0,3 (system) = exe size:
1,757,177 byte
64Bit: 2,48 (wall), 2,42 (user) , 0,5 (system) = exe size:
2,179,326 byte
This is a measure of the quality of the generated code
The compilation only
13,9 (32bit) <-16,2 (64 bit) sec -O0
33,5 (32bit) <-31,4 (64 bit) sec -02
55,7 (32bit) <-51,9 (64 bit) sec -03
So the new registers are just not giving any benefits that are not
consumed by the additional memory overhead.
I''m mostly surprised that the code generation part of gcc (speed of
the compiler) is also the same, because this is the most terrible
weakness for any of my development (it has to do with how the eiffel
compiler works). MSVC is 16x faster then (using precompiled headers)
gcc (without precompiled headers). I can''t compare them again because
the OS are now on different machines but precompiled headers are
almost useless on gcc - and the way Eiffel generates the header file
is already perfect (only one header per c file, and first statement in
each file). I got results from -8% (gcc 4.x) upto 28% (gcc 3.4.6) .
So i always believed that the problem is the code generator of gcc,
which makes sense because Sun Studio 11 on SPARC is 4x faster per Mhz
then the Intel86 code (because of the easy calling conventions for the
compiler) and the tinycc is 9x faster then gcc. Both aren''t using
precompiled headers.
But the additional number of registers seems to not reduce the
complexity of the code generator. I really don''t understand this. I
guess it is the one-for-all overengineered architecture that slows
down the whole gnu collection.
Unfortunately the only other useable c compiler on linux i could test
was almost as slow as gcc. Seems that Intel does only care about speed
of the executable.
So is there something useable out there (tinycc is unfortunately full
of bugs and not anymore maintained) that is at least 3-5 times faster
then gcc. It would make my development much easier.
Ah yes, on my iMac PPC i also tried it, codewarrior <-gcc was only
giving a little bit less then 2x performance. But this compiler does
not exist anymore. OpenWatcom is also not developed and the lcc-
linux32/lcc-linux64 seem to be not yet available.
llothar a écrit :I must say i didn''t expect this. I just did some measures on FreeBSD
6.2 with gcc 3.4.6 and there is absolutely no significant difference
between 32 and 64 bit mode - neither in compilation speed, nor in
speed of the compiled result.
I would not expect anything else. For what reason you would think
64 bit is better?
As a benchmark i took a bootstrap of the SmallEiffel Compiler (which
has 38 files with around 100 kloc). The times i got were very
reliable. The bootstraping (compile the c files from last eiffel
compiler stage, and then use this to regenerated the eiffel compiler
and all tools) took
32Bit: 2,58 (wall), 2,57 (user), 0,3 (system) = exe size:
1,757,177 byte
64Bit: 2,48 (wall), 2,42 (user) , 0,5 (system) = exe size:
2,179,326 byteWhat machine were you using? Without that, absolute times are
meaningless.
This is a measure of the quality of the generated code
The compilation only
13,9 (32bit) <-16,2 (64 bit) sec -O0
33,5 (32bit) <-31,4 (64 bit) sec -02
55,7 (32bit) <-51,9 (64 bit) sec -03
So the new registers are just not giving any benefits that are not
consumed by the additional memory overhead.
Yes. Code bloat, and larger memory footprint eat away the benefits
of the new registers.
I''m mostly surprised that the code generation part of gcc (speed of
the compiler) is also the same, because this is the most terrible
weakness for any of my development (it has to do with how the eiffel
compiler works).lcc-win32 is 20 x faster than gcc. I think most compilers are faster
than gcc since gcc has never cared about this. The team has apparently
other objectives.
MSVC is 16x faster then (using precompiled headers)
gcc (without precompiled headers). I can''t compare them again because
the OS are now on different machines but precompiled headers are
almost useless on gcc - and the way Eiffel generates the header file
is already perfect (only one header per c file, and first statement in
each file). I got results from -8% (gcc 4.x) upto 28% (gcc 3.4.6) .
So i always believed that the problem is the code generator of gcc,
which makes sense because Sun Studio 11 on SPARC is 4x faster per Mhz
then the Intel86 code (because of the easy calling conventions for the
compiler) and the tinycc is 9x faster then gcc. Both aren''t using
precompiled headers.
But the additional number of registers seems to not reduce the
complexity of the code generator. I really don''t understand this. I
guess it is the one-for-all overengineered architecture that slows
down the whole gnu collection.
Exactly. One of the symptoms for this situation is that -O2 generates
BETTER code thanh -O3 ... -O9.
The problem with this type of software is that the only thing that
people are interested in is to put some more code, since the
recognition goes to "the guy that added feature xxx to gcc" and
never to the "guy that erased unneeded feature xxx from gcc".
This means that evertbody has his/her pet interest with the
project, and not a lot of people care about the project in general.
This means that many features get added to the software but never
a reviw of all the optimizations is done to see if it is wortwhile
to KEEP them.
Another big difficulty of the gcc project is that it is a compiler
that should run anywhere, what means a lot of back ends, and
therefore a lot of problems. Microsoft has less problems since it runs
essentially on x86 and then only in one operating system...
Unfortunately the only other useable c compiler on linux i could test
was almost as slow as gcc. Seems that Intel does only care about speed
of the executable.
You could use lcc-lin64 but it is NOT free under linux, you have
to buy it.
So is there something useable out there (tinycc is unfortunately full
of bugs and not anymore maintained) that is at least 3-5 times faster
then gcc. It would make my development much easier.
Yes, use lcc-lin64.
Ah yes, on my iMac PPC i also tried it, codewarrior <-gcc was only
giving a little bit less then 2x performance. But this compiler does
not exist anymore. OpenWatcom is also not developed and the lcc-
linux32/lcc-linux64 seem to be not yet available.
They are available but need some tweaking.
I would not expect anything else. For what reason you would think64 bit is better?Only for the better register model. For todays computer speed the CPU
ISA seems really not so important any more. It''s good to see that
the large address space is not giving a high penality. But i have to
check the
speed of the Boehm-Weisser-GC before i make a final comparision.
32Bit: 2,58 (wall), 2,57 (user), 0,3 (system) = exe size:
1,757,177 byte
64Bit: 2,48 (wall), 2,42 (user) , 0,5 (system) = exe size:
2,179,326 byte
What machine were you using? Without that, absolute times are
meaningless.It''s an AthlonX2 4400 but no parallel execution. The numbers itself
are
irrelevant I just wanted to point out how equal the numbers are
(less then 1%) and even the exe size is only 20% larger.
At first i even expected the program was wrongly compiled so
i added a "assert(sizeof(void*) == 8)" but it was okay.
lcc-win32 is 20 x faster than gcc. I think most compilers are faster
than gcc since gcc has never cared about this. The team has apparentlyIndeed. I see this as a huge problem.
You could use lcc-lin64 but it is NOT free under linux, you have
to buy it.Don''t have a problem as long as the price is reasonable. But i need
some more
information. I purchased Code-Warriors Linux and Kylix. Both were
terrible mistakes
and i never got Kylix compile a simple hello world. But i talked with
Friedrich about
it and it seems that you are going a better way. Is there any website,
i looked at
his Q website and couldn''t find anything.
Your post is more topical in a GCC compiler group.
I guess you are using it wrong, or in areas where there is no benefit.
In bitboard chess programs (which need 64 bit integers) there is a big
speedup. If your program does not use 64 bit integers heavily, there
is no reason to expect a big speed increase (unless you need to access
more than 2 GB of RAM, which is another place where 64 bit model
shines).
At any rate, if you want to get better performance using the GCC
compiler suite, why not ask in one of the myriad GCC compiler
newsgroups?
If you use all the performance options pertinant for your hardware and
do profile guided optimization, you can get performace pretty close to
the commercial compilers.
这篇关于gcc 64bit编译器不提供任何速度优势的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
