vc++ 用的是什么编译器？

就是微软的编译器啊，微软要是连个编译器都做不出来就别混了，不过VC的编译器是在VS2003以后才逐渐赶超其他编译器的，得益于从Borland挖来的一批人现在VS2008的编译器生成的执行代码速度仅次于intel C++ 11.0，而且是在Core 2以上的平台，因为这时候Intel编译器可以直接生成SSE3的执行代码！很赖的。

新版G++和BCB编译器生成的执行代码，平均比VS2008慢10%~20%，在不支持SSE3和SSE4平台的CPU上，Intel C++ 11.0和VS2008差不多，Intel C++ 10.0、9.0的版本和VS2005差不多，也是比VS2008稍慢10%左右。更早的VC6就差的远了，一般得慢30%以上（VC6编译器本身品质在当时就不算最高，而且VC6只能针对奔腾2优化），慢50%以上也是常见的。另一些不出名的就更差了

恐怕和不同项目有关吧，我用图象识别测试的，C代码，VC2008不知道，VC6比VC2005稍快，比2005年的INTEL快。

执行速度。
INTEL的版本05年前我也一直和VC做比较，从7.0开始，一直不如VC，它有一些特性可能对某些用户有帮助，比如说循环展开和SSE的支持，但高价用户会手工处理这些问题，效率比它高，循环该展开的才展开，不该展的被自动展了白白降低缓存效率。

你一定没有用优化选项，release版优化全开的情况下，VC比VS2008至少慢30%，除非你的机器是奔腾2以下的

别告诉我你是用debug版测试的结果

我问的是VC6与2008的效率比，不是intel的

各楼都说的很多了，有Visual C++6.0、Visual Stutio 2003、Visual Stutio 2005、Visual Stutio 2008，这些都是微软的产品，当然还有什么intel C++ 11.0、
C++ builder啦，以及什么DEV C++了等等！

关于intel的编译器，网上确实有不如VS2005、VS2008一说，主要是因为这种编译器不流行，通常用户获得的都是上几代的产品，比如现在绝大部分intel编译器用户用的还是9.0，新款已经11.0了，我拿11.0比VS2008，10.0比VS2005，确实效率是差不多的（不开SSE）。intel编译出来的东西大，是因为他不用msvcrt.dll，要知道，这个dll包含了大部分的C语言标准库函数，也就是说动态链接的VS2008的exe程序里面是几乎没有库函数代码的，当然很小。其实intel和VS的效率之争你高点我低点都正常，双方优化的方向不同。我感到困惑的是为什么说VC6的效率高于VS2005，在不换库和编译器（很多程序员用惯了VC6的IDE，换库和编译器继续用VC6）的情况下VC6本身对C++标准支持不好，而且只能优化到奔腾2的指令集，如果VC6的效率高与VS2005的话，微软那七年都白干了。我记得当时VC6的效率比同时代的BCB、GCC还要低

VC2008我会稍后再试，有一个还没试的原因，就是我经常看网上的评论，说2008比VC6快30%的还是第一听到，反而负面的说法听到不少。
还有一个原因是我准备移植程序到64位，再拿2008和VC6做比较已经没意义了，但我还会关注INTEL，看看64位谁快。

同样，我的源程序也是高度优化，因为C函数都无法满足我的效率要求，很多函数得用查表编码自编。
实际上，代码本身怎么样并不重要，效率低的代码所有的编译器编译效率都低，不影响编译器的表现的，你可以搜一下CSDN里不少关于VC6和VS2005、VS2008讨论的帖子，测试结果VC6慢100%都有

INTEL的代码我反汇编出来看，大的原因有两个，一是过度的循环展开，另一个是过度的16字节代码对齐，我的程序是纯C代码，没用到MS的运行DLL，其实核心都可以脱离操作系统运行。
至于和VC2005比，当时测出VC6高出1%，还小一点。优化的方法有变化，速度小的差距是可以理解的。

如果你不信的话，说明你还是没有真正研究优化选项，不要拿64位来自相矛盾，既然VC6没有64位，intel你又认为比较慢，谁和谁比快啊……VC6的垃圾多是出了名的，VC6的经典仅限于他那个时代而已。

这说明你根本不懂VS，我说过微软的所有C库函数都在msvcrt.dll里，不信的话，你编一个hello world，然后忽略msvcrt.lib，release编译，能通过的话就怪了。微软的所有C库函数都是利用API和微软本身的二进制库实现的，怎么会和操作系统没关系？

图象部分可以用SSE的部分我是用SSE汇编得。关键的地方我都反汇编编译代码看，觉得基本上我的程序里改汇编能提高10%的地方已经没有了，所以提高30%是不可能发生在我的项目上的，更不可能100%，但我的确有提高10%的奢望。
关于速度比较讨论我在GOOGLE搜了好多，VC2008以前的言论，大都认为2005和VC互有胜负。

不争论了
#include <stdio.h>int main()
{
printf("hello,world!");
return 0；
}
忽略微软运行库后就是这样，如果连这都叫“其实核心都可以脱离操作系统运行”，我真无语了，第一个（缓冲区检查）和第三个错误（crt入口）可以通过设置来去掉，但是连printf都得微软运行库的支持，我真不懂你是怎么编出来“脱离操作系统运行”的程序的1>a.obj : error LNK2001: 无法解析的外部符号 @__security_check_cookie@4
1>a.obj : error LNK2001: 无法解析的外部符号 __imp__printf
1>LINK : error LNK2001: 无法解析的外部符号 _mainCRTStartup

这说明你不懂C啦，
我的核心程序连内存分配函数都没，外部程序调用的时候给个内指针，memcpy到之类的到是有，都是INTRINSIC，不调用DLL。
我已经在裸机无操作系统的情况下测试过了，我的做法是，自己写个启动扇区，把我写的WINDOWS DLL读入内存，跟据PE头重定位。

用printf说话很无聊，你还可以用TextOut之类的WINDOWS API来说话呢。那些东西不是算法核心，我也不测那些东西的速度。当然我程序测试时候有大量的WINDOWS SPI和C外部函数，但运行的时候就不需要了。几秒钟的高强度计算，一个开关量输出解决问题。

原来还是使用换库换dll之类得来实现的，VC6本身也只是个IDE而已，如果你把库、dll都换了，那效率真不好说了。我只问你，装好VC6，什么都别动，release编译出来的程序难道会比vs2005快？你就是我常说的那一种VC6用惯了，不习惯新的IDE，换库加强VC6的，你的水平是不错，如果你把这些水平用在优化VS2008上，应该更有前途

就因为你说“其实核心都可以脱离操作系统运行”，我才用通用的printf的，如果你用API，那就请收回你说的话吧

关于PRINTF，我在裸机上写了个简单的API，直接向显存写字符串，恐怕没几个人会需要PRINTF的复杂参数格式。

你还是没明白的话，我说我程序的核心可以脱离操作系统运行，也就是几秒钟就调用操作系统和任何其它DLL，我测的就是这部分速度，如果中间调用了MSVCRT dll,你掺和在一起测，有意义吗？
和你说话太累。

测速度的时候一定要排除外部DLL的干扰，如果过程中VC编译的用了DLL，INTEL全INTRINSIC，这么比较就没意义了。

在全用API丝毫不涉及的情况下，也许VC6的效率确实没有与VS2008 30%的差距，因为绝大部分代码都是操作系统的东西（我强调这一点，还请你收回刚才的话），VC6本身的东西很少，这种情况下不同版本的操作系统dll的影响都比编译器要大，如果你为此就断言VC6的效率高于VS2005的话，是没有说服力的，可能感觉VC6效率高的也就是你这种“高手”吧，我并不怀疑你做的测试，但对于大部分人来说没有参考价值，因为100个用VS的人恐怕只有1个不用微软库的。

在某些极特殊情况下，可以写出比更高效的JAVA程序，这其实就类似于你的情况，我们不能就此说JAVA比C++更高效吧。你的这些做法比较适合于写嵌入式系统的程序和驱动程序，确实嵌入式系统很少用VS2005、2008开发。

哈哈，我没让你收回你的话就很客气了，我哪句话说错了？
测试把调用DLL和操作系统掺和在一起，都是外部干扰，测试结果意义何再？你不如去单独测试WINDOWS和DLL把。
当然对于多数应用来说，不会出现我这种应用，但测试比须要我这么测，如果你写3D游行，那就不合适拿来测编译器了，时间大都用来来调用DIRECTX了。或者说你些数据库、操作界面之类的程序，性能也取决于数据引擎的操作系统，和编译器关系不大。那种编造的来搜索1亿个字符串的应用测试也没什么意义，你用文字处理的时候CPU基本就在等候，这种东西不要性能。

我不是专门做嵌入，但是移栽性是我经常考虑的，GCC编译的性能让我担心，所以如果能让WINDOWS上最强的编译成果脱离WINDOWS是最好的了。
至于JAVA我不说了，如果你想去测试JAVA和C的运行库，比较某个库函数哪个快你可以去做，我没兴趣。

对了，搞清楚JAVA的运行库用哪个C编译器编译的倒是可以成为趣闻

谁说测试就得这么测的，你认为你现在的程序能体现优势的有几处？怕绝大部分时间都花在系统dll上了吧，真正能体现编译器优势的，是不调用任何系统api，算法占用99%以上时间的程序，比如你所说的没有意义的字符串搜索，数学计算、图形计算等，如果你没把握VC6在这些方面取胜，那就闭嘴吧！

其实代码都已经优化过
特别是用了内联汇编的
对各编译器的比较没什么意义无论vc、vs动态、静态编译的PE都要调用windows api

早期编译器区别还是很大的，从VC6开始我觉得接近极限了，基本上除非用SSE汇编，很难超出编译器，无法并行的时候用X86汇编没什么意义。
虽然说WINDOWS程序里面必然有WINDOWS API，但是假如跟据PE头信息找出一个DLL函数入口进去，可以不经经过任何WINDOWS API。你可以自己试验，写个简单DLL调用，反汇编一看就明白了。
当然写种程序复杂以后需要一点技巧，你当然不能用malloc, 但你可以用_alloca, 这就不依赖系统了，而且非常好用。

有趣，可以讨论下去
我的意思是代码优化过，编译器能再优化的空间就少了
如
a=b*4;在等价条件下,编译器可以优化成a=b<<2;
除法优化成乘法
现在你已经将代码写成a=b<<2，那就体现不出各个编译器对a=b*4;的优化结果再说整段代码都用内联汇编来写，编译器都不优化
况且新版的编译器支持更高效的CPU指令
这样的比较体现不出各编译器的特点什么无法并行？？
什么什么归根到底也都是和汇编等价的机器码而已PE不调用Windows API，我不知道这是什么技术
无导入表倒是有，只不过是用隐藏方式调用API而已
但加载这个PE本身，就已经执行了一些Windows API
除非你自己写裸机的PE Loader，有这必要？没听说过C编写的什么什么（不知其术语）可以直接运行在裸机上，
引导是用汇编写的吧
TC编译的程序，都要靠DOS来加载运行哩小弟学识浅，请指正

vc++是集成开发环境，eclipse如果好好配置也可以在windows下开发mfc 程序，所以vc++是IDE
cl.exe是编译器

jackyjkchen 只想说你真恶心

不想无谓争论了，我已经都已经验证甚至工程中实用的东西还有人怀疑，我没有做科普教育的义务。有兴趣的可以反汇编看RELEASE代码.
补充一点就是最近为64位优化正在用VC 2008(9.0),顺便在32位测试了一下，在我的图像识别项目，32位图像处理VC6比VC9快8%，特征比较是VC9比VC6快1%，综合比较VC6胜。

没错，我自己用BIOS调用写的PE LOADER, 几百行汇编代码而已，省下200个硬盘+200 正版WINDOWS价值十几万人民币，没必要？
CSDN里大款太多，整天泡在论坛里的人应该不是一般的富。为几万块钱我可是什么歪路都愿意走。

哈哈今天从头到尾仔细看了一遍争吵的2位大牛，经验都很丰富。呵呵，我发现2位的争吵焦点都不是同一个东西。jackyjkchen 兄，说的是应用平台的，更偏向 windows 平台的应用的，不同编译器针对代码的编译优化问题。而 Guilty 兄说的是算法层次上的，至少不是在说和 OS平台有关联的东西。我发现 Guilty 兄更偏底层开发，你那一段
“没错，我自己用BIOS调用写的PE LOADER, 几百行汇编代码而已，省下200个硬盘+200 正版WINDOWS价值十几万人民币，没必要？
CSDN里大款太多，整天泡在论坛里的人应该不是一般的富。为几万块钱我可是什么歪路都愿意走。”
让我很有兴趣，敢问 Guilty 的工种和行业？？？？和上面那一段话的实现方法从何入手！！！？？？

我只想说，LZ好可怜，被完全无视了……
我就这么告诉LZ吧，VC用的编译器就叫做VC编译器……VC既是整个c++开发工具环境，也可以用来指代VC编译器，懂不……

gcc的效率就挺高的，可惜不是Windows下的编译器。MSVC要是开源的话效率可能还能再上来。

不过说回来，GCC毕竟不是G++，C肯定要比C++快的

调试易

vc++ 用的是什么编译器？

解决方案 »