C++编译器性能比较

现在市面上,主流的C/C++编译器包括M$的CL、gcc、Intel的icl、PGI的pgcc及Codegear的bcc(原来属于Borland公司)。Windows上使用最多的自然是cl,而在更广阔的平台上,gcc则是C/C++编译器的首选。但要提到能力优化,排名就未必与它们的市场占有率一致了。

今天一时兴起,便做了一个各编译器数值性能的比较。测试的代码是一个求积分的程序,来源于intel编译器的例子程序,修改了一个头文件,以便每个编译器都能编译。

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <math.h>

// Function to be integrated
// Define and prototype it here
// | sin(x) |
#define INTEG_FUNC(x) fabs(sin(x))

// Prototype timing function
double dclock(void);

int main(void)
{
// Loop counters and number of interior points
unsigned int i, j, N;
// Stepsize, independent variable x, and accumulated sum
double step, x_i, sum;
// Timing variables for evaluation
double start, finish, duration, clock_t;
// Start integral from
double interval_begin = 0.0;
// Complete integral at
double interval_end = 2.0 * 3.141592653589793238;

// Start timing for the entire application
start = clock();

printf(" \n");
printf(" Number of | Computed Integral | \n");
printf(" Interior Points | | \n");
for (j=2;j<27;j++)
{
printf("------------------------------------- \n");

// Compute the number of (internal rectangles + 1)
N = 1 << j;

// Compute stepsize for N-1 internal rectangles
step = (interval_end - interval_begin) / N;

// Approx. 1/2 area in first rectangle: f(x0) * [step/2]
sum = INTEG_FUNC(interval_begin) * step / 2.0;

// Apply midpoint rule:
// Given length = f(x), compute the area of the
// rectangle of width step
// Sum areas of internal rectangle: f(xi + step) * step

for (i=1;i<N;i++)
{
x_i = i * step;
sum += INTEG_FUNC(x_i) * step;
}

// Approx. 1/2 area in last rectangle: f(xN) * [step/2]
sum += INTEG_FUNC(interval_end) * step / 2.0;

printf(" %10d | %14e | \n", N, sum);
}
finish = clock();
duration = (finish - start);
printf(" \n");
printf(" Application Clocks = %10e \n", duration);
printf(" \n");

return 0;
}

时间: 2024-09-17 03:14:15

C++编译器性能比较的相关文章

JVM 性能优化,第二部分:编译器

本文将是JVM 性能优化系列的第二篇文章,Java 编译器将是本文讨论的核心内容. 本文中,作者(Eva Andreasson)首先介绍了不同种类的编译器,并对客户端编译,服务器端编译器和多层编译的运行性能进行了对比.然后,在文章的最后介绍了几种常见的JVM优化方法,如死代码消除,代码嵌入以及循环体优化. Java最引以为豪的特性"平台独立性"正是源于Java编译器.软件开发人员尽其所能写出最好的java应用程序,紧接着后台运行的编译器产生高效的基于目标平台的可执行代码.不同的编译器适

Java虚拟机JVM性能优化(二):编译器_java

本文将是JVM 性能优化系列的第二篇文章(第一篇:传送门),Java 编译器将是本文讨论的核心内容. 本文中,作者(Eva Andreasson)首先介绍了不同种类的编译器,并对客户端编译,服务器端编译器和多层编译的运行性能进行了对比.然后,在文章的最后介绍了几种常见的JVM优化方法,如死代码消除,代码嵌入以及循环体优化. Java最引以为豪的特性"平台独立性"正是源于Java编译器.软件开发人员尽其所能写出最好的java应用程序,紧接着后台运行的编译器产生高效的基于目标平台的可执行代

Java SE 6性能白皮书

1 简介 Java SE 6(Java Platform Standard Edition 6)的一个主要设计原则就是以性能缺陷为目标,通过当前最流行的一些 Java 基准测试以及与 Java 社区的紧密协作来确定对性能影响最大的增强关键领域,从而提高性能和可伸缩性. 本指南将概述 Java Standard Edition 6 中新增功能和可伸缩性改进,同时提供各种行业标准和内部开发的基准测试结果,以便演示这些性能改进的影响. 2 新增功能和性能增强 Java SE 6 引入了一些新的功能和性

JVM优化系列-第二部分-编译器

作者:Eva Andreasson    原文链接  译者:sooerr   校对:赵峰 JVM性能优化系列中,第二篇章里Java编译器是主要部分.Eva Andreasson介绍了不同类型的编译器,并且就客户端.服务器端.分层编译进行了性能对比.她也总结了JVM优化的一些概况,例如死代码的消除.代码内嵌和循环优化. Java编译器是Java著名的跨平台特性的根源.软件开发者写出了一个理想的Java应用程序,在编写高效.平稳的代码的背后,正是编译器可以保证其运行在潜在的目标平台.不同种类的编译器

.NET程序的性能要领和优化建议

前几天在老赵的博客上看到,Bill Chiles (Roslyn 编译器的Program Manager)写了一篇文章叫做<Essential Performance Facts and .NET Framework Tips>.这篇文章是一个14页的pdf,当时我是在地铁上在Lumia手机上看的,觉得很是不错,这里也建议大家直接下载阅读原文,我这里试着翻译一下,以加深自己印象,后面也有一些思考,以下是原文内容: ----------------------------------------

.NET开发中性能的基本要领及优化建议

老赵的.NET程序性能的基本要领 说起Roslyn大家肯定都已经有所耳闻了,这是下一代C#和VB.NET的编译器实现.Roslyn使用纯托管代码开发,但性能超过之前使用C++编写的原生实现.Bill Chiles是Roslyn的PM(程序经理,Program Manager),他最近写了一篇文章叫做<Essential Performance Facts and .NET Framework Tips>,其中总结了几条经验,目前是个CodePlex上的PDF文件,以后可能会发布在MSDN上.

运行时和编译时元编程—编译时元编程

原文链接    译文链接     译者:JackWang 运行时和编译时元编程 第二部分 2 编译时元编程 Groovy的编译时元编程支持编译时生成代码.这些变换(译者注:原文该专有名词是transformations,译者直译为变换,也许不准确.如果有知道准确翻译的读者恳请不吝赐教,待译者修正)叫做程序的抽象语法树(AST),在Groovy里,我们叫做AST变换.AST变换支持在编译过程中植入钩子,修改抽象语法树之后继续编译生成正常的字节码流.和运行时元编程相比,这种转换可以在类文件的修改可见

浏览器厂商开始默认支持WebAssembly格式

各浏览器厂商在WebAssembly相关的工作上已经达成了一种"共识",这使得各浏览器开始默认支持WebAssembly格式. 早在2016年11月,WebAssembly就已经进入"浏览器预览"(Browser Preview)阶段.在此阶段,主流浏览器都提供了一个具有WebAssembly开关标识的测试版本浏览器.随后的数月时间,各浏览器厂商需要在JavaScript API和二进制格式上做改进,并就此取得一致意见.近期发布的公告对WebAssembly做了界定

我所偏爱的 C 语言面向对象编程范式

我所偏爱的 C 语言面向对象编程范式 面向对象编程不是银弹.大部分场合,我对面向对象的使用非常谨慎,能不用则不用.相关的讨论就不展开了. 但是,某些场合下,采用面向对象的确是比较好的方案.比如 UI 框架,又比如 3d 渲染引擎中的场景管理.C 语言对面向对象编程并没有原生支持,但没有原生支持并不等于不适合用 C 写面向对象程序.反而,我们对具体实现方式有更多的选择. 大部分用 C 写面向对象程序的程序员受 C++ 影响颇深.企图用宏模拟出一个常见 C++ 编译器已经实现的对象模型.于我愚见,这