#include <stdio.h>
#include <time.h>
int main(int argc, char* argv[])
{
int i, sums;
long time1, time2;
time(&time1);
sums =0;
for(i=0; i<=0x5FFFFFFF; ++i)
{
sums +=(1+2<<1)%2*2-1;//主要是使运算复杂点
}
time(&time2);
printf("count is:%d, timespan is:%d\n", sums, time2-time1);
}
速度(秒) debug release
windows 11 0
linux 17 7
大小(byte) debug release
windows 180,278 45,056
linux 4,877 4,825
linux 下是这样编译的:
release版: cc file.c -O3
debug版: cc file.c -O0
问题
1、为什么linux下运行的程序要比windows慢这么多呢,对linux失去点信心了。
2、主代码是这句sums +=(1+2<<1)%2*2-1;windows release作了什么优化,居然能快那么多。
26 个解决方案
#1
是不是Windows编译器直接给算出来了?
你改成sums +=rand()看看。
另外这个测试可能不好反映OS性能。多开几个线程,再打开几个文件读写,或者申请很大的内存(大到接近物理内存),然后往这块内存的随机位置读写试试
关注中
有结果记得回帖告诉我啊
你改成sums +=rand()看看。
另外这个测试可能不好反映OS性能。多开几个线程,再打开几个文件读写,或者申请很大的内存(大到接近物理内存),然后往这块内存的随机位置读写试试
关注中
有结果记得回帖告诉我啊
#2
你用time来计算程序的运行时间是不准确的(实际上很不准确的),应该用times。用这个
这个函数计算出来的时间才是CPU在你的进程上花费的时间。而time不是CPU时间,它还
包括了进程等待等一系列的时间花费,如果这时在Linux上有IO操作的话,time得到的时间
会非常大。如果你的程序运行足够长的时间,Linux下会在程序结束时打印出下面的信息:
571.719u 25.130s 14:42.89 67.6% 0+0k 0+0io 15pf+0w
第一个是User Time,第二个是System Time(这两个的具体内容你可以参考times),他们
的和就是CPU真正花费的时间。第三个就是你用time计算出来的时间。第四个是一个百分比,
你可以发现这个比值就是times得到的时间/time得到的时间。
这个函数计算出来的时间才是CPU在你的进程上花费的时间。而time不是CPU时间,它还
包括了进程等待等一系列的时间花费,如果这时在Linux上有IO操作的话,time得到的时间
会非常大。如果你的程序运行足够长的时间,Linux下会在程序结束时打印出下面的信息:
571.719u 25.130s 14:42.89 67.6% 0+0k 0+0io 15pf+0w
第一个是User Time,第二个是System Time(这两个的具体内容你可以参考times),他们
的和就是CPU真正花费的时间。第三个就是你用time计算出来的时间。第四个是一个百分比,
你可以发现这个比值就是times得到的时间/time得到的时间。
#3
lqh_wh(liqh) 对。
不能用wall clock time来做比较。
不能用wall clock time来做比较。
#4
居然这么来测试
顶lqh_wh(liqh)
顶lqh_wh(liqh)
#5
windows编译器大概已经知道+=(1+2<<1)%2*2-1是个常数了。
看看gcc有什么选项没有?
看看gcc有什么选项没有?
#6
把gcc的优化开到O3试试。
#7
lqh_wh(liqh)解释正确!!!支持!
#8
这样测试是不合理的
影响经常运行有很多因素
影响经常运行有很多因素
#9
我是经过多次随机测试的,time是记录当前的系统时间,两个时间相差就是运行时间了吧,大家有什么好办法测试linux和window的速度呢?
#10
我想我误会了lz的意思。首先澄清几个问题。
1. 程序运行时间,即程序开始执行到程序退出这段时间就是程序的运行时间,这个时间可以采用lz所说的time函数得到。
2. 程序的效率,即程序在运行中占用CPU的时间(实际上是程序占用了多少个时钟周期)。这个采用我所说的times函数得到。
3. 系统的效率。这才是lz真正的目的。系统效率受硬件和OS的影响。这里就不说硬件的影响,而OS的效率是跟OS的实现有关的,如OS如何实现I/O,如何实现进程调渡等等。而LZ只通过一个小程序就觉得Linux的效率不如Windows有失偏颇。如果LZ想比较OS的效率,应该写一些大程序,涉及I/O读写,进程调度,IPC等方面来进行测试,才是比较好的方法。
1. 程序运行时间,即程序开始执行到程序退出这段时间就是程序的运行时间,这个时间可以采用lz所说的time函数得到。
2. 程序的效率,即程序在运行中占用CPU的时间(实际上是程序占用了多少个时钟周期)。这个采用我所说的times函数得到。
3. 系统的效率。这才是lz真正的目的。系统效率受硬件和OS的影响。这里就不说硬件的影响,而OS的效率是跟OS的实现有关的,如OS如何实现I/O,如何实现进程调渡等等。而LZ只通过一个小程序就觉得Linux的效率不如Windows有失偏颇。如果LZ想比较OS的效率,应该写一些大程序,涉及I/O读写,进程调度,IPC等方面来进行测试,才是比较好的方法。
#11
楼主在Windows下用什么编译器?如果不是用gcc的话,就不具备可比性,若要做比较,不妨用 -S参数先编译出汇编,然后整理后分别在Windows和Linux下编译成可执行程序,才具备可比较性,否则编译器的优化有时候会使结果偏离初衷。
另外,这个程序并不能达到比较两个操作系统效率的目的,既然要比较操作系统效率,应该至少调用和操作系统相关的函数,而不是和系统无关的东西。
另外,这个程序并不能达到比较两个操作系统效率的目的,既然要比较操作系统效率,应该至少调用和操作系统相关的函数,而不是和系统无关的东西。
#12
楼主根本就不懂怎么测试.
#13
支持楼主,结果怎样?
#14
victorchen_2000(微力) ( ) 信誉:104 2006-04-12 10:09:00 得分: 0
楼主根本就不懂怎么测试.
---------------------------
本来没什么好说的,只到看了这位老大的
你可以说说你认为的,正确的测试方法是怎么样的嘛
用不着指责别人
楼主根本就不懂怎么测试.
---------------------------
本来没什么好说的,只到看了这位老大的
你可以说说你认为的,正确的测试方法是怎么样的嘛
用不着指责别人
#15
vc的编译器确实会优化那个算式的,你可以在里面带上i进行计算,就不会被优化那么多了
#16
是在同一台机器测试吗?
下面数据在同一台机器测试.
环境: winxp sp1 VS FC4
>cl time_test.c -o time_test.exe
>time_test
count is -1610612736, timespan is: 5
[root@localhost chapter02]# gcc time_test.c -o time_test
[root@localhost chapter02]# ./time_test
count is: -1610612736, timespan is:7
[root@localhost chapter02]#
下面数据在同一台机器测试.
环境: winxp sp1 VS FC4
>cl time_test.c -o time_test.exe
>time_test
count is -1610612736, timespan is: 5
[root@localhost chapter02]# gcc time_test.c -o time_test
[root@localhost chapter02]# ./time_test
count is: -1610612736, timespan is:7
[root@localhost chapter02]#
#17
为了比赛更公平,采用 slay78(天灯石) 的意见,把 i 加入运算中.
#include <stdio.h>
#include <time.h>
int
main(int argc, char *argv[])
{
int i;
double sums;
long time1, time2;
time(&time1);
sums = 0.0;
for (i = 0; i <= 0x5FFFFFFF; i++) {
sums += (1 + 2 << 1)%2*2 - 1 + i/10000;
}
time(&time2);
printf("count is: %f, timespan is:%d\n", sums, time2-time1);
}
测试结果:
[root@localhost chapter02]# gcc time_test.c -o time_test
[root@localhost chapter02]# ./time_test
count is: 129701253350160.000000, timespan is:24
[root@localhost chapter02]#
C:\c\a>time_test1
count is 129701253350160.000000, timespan is: 57
#include <stdio.h>
#include <time.h>
int
main(int argc, char *argv[])
{
int i;
double sums;
long time1, time2;
time(&time1);
sums = 0.0;
for (i = 0; i <= 0x5FFFFFFF; i++) {
sums += (1 + 2 << 1)%2*2 - 1 + i/10000;
}
time(&time2);
printf("count is: %f, timespan is:%d\n", sums, time2-time1);
}
测试结果:
[root@localhost chapter02]# gcc time_test.c -o time_test
[root@localhost chapter02]# ./time_test
count is: 129701253350160.000000, timespan is:24
[root@localhost chapter02]#
C:\c\a>time_test1
count is 129701253350160.000000, timespan is: 57
#18
#19
争论有了结论了么?
#20
效率跟编译器也有一定关系
并且通常系统启动后第一次运行和第二次运行也不一样
并且通常系统启动后第一次运行和第二次运行也不一样
#21
写了几天java,终于看到计算机的东西了。
首先,上面的程序基本上不用什么操作系统的资源,就是基本的运算,这样的测试主要的区别会来自编译器。
sourceid()的方法用的还是不相同的编译器,同时,两者的标准库对于time的处理,系统最小定时精度等,都会带来差异。
我的感觉: i = a + b
这类运算操作系统基本没有干预。上面的测试和操作系统没有本质关系。
首先,上面的程序基本上不用什么操作系统的资源,就是基本的运算,这样的测试主要的区别会来自编译器。
sourceid()的方法用的还是不相同的编译器,同时,两者的标准库对于time的处理,系统最小定时精度等,都会带来差异。
我的感觉: i = a + b
这类运算操作系统基本没有干预。上面的测试和操作系统没有本质关系。
#22
算法,算法
#23
不要太快下结论
#24
up~受益~
#25
处处留心皆学问啊
#26
LZ的操作系统性能测试程序真幽默,很经典
#1
是不是Windows编译器直接给算出来了?
你改成sums +=rand()看看。
另外这个测试可能不好反映OS性能。多开几个线程,再打开几个文件读写,或者申请很大的内存(大到接近物理内存),然后往这块内存的随机位置读写试试
关注中
有结果记得回帖告诉我啊
你改成sums +=rand()看看。
另外这个测试可能不好反映OS性能。多开几个线程,再打开几个文件读写,或者申请很大的内存(大到接近物理内存),然后往这块内存的随机位置读写试试
关注中
有结果记得回帖告诉我啊
#2
你用time来计算程序的运行时间是不准确的(实际上很不准确的),应该用times。用这个
这个函数计算出来的时间才是CPU在你的进程上花费的时间。而time不是CPU时间,它还
包括了进程等待等一系列的时间花费,如果这时在Linux上有IO操作的话,time得到的时间
会非常大。如果你的程序运行足够长的时间,Linux下会在程序结束时打印出下面的信息:
571.719u 25.130s 14:42.89 67.6% 0+0k 0+0io 15pf+0w
第一个是User Time,第二个是System Time(这两个的具体内容你可以参考times),他们
的和就是CPU真正花费的时间。第三个就是你用time计算出来的时间。第四个是一个百分比,
你可以发现这个比值就是times得到的时间/time得到的时间。
这个函数计算出来的时间才是CPU在你的进程上花费的时间。而time不是CPU时间,它还
包括了进程等待等一系列的时间花费,如果这时在Linux上有IO操作的话,time得到的时间
会非常大。如果你的程序运行足够长的时间,Linux下会在程序结束时打印出下面的信息:
571.719u 25.130s 14:42.89 67.6% 0+0k 0+0io 15pf+0w
第一个是User Time,第二个是System Time(这两个的具体内容你可以参考times),他们
的和就是CPU真正花费的时间。第三个就是你用time计算出来的时间。第四个是一个百分比,
你可以发现这个比值就是times得到的时间/time得到的时间。
#3
lqh_wh(liqh) 对。
不能用wall clock time来做比较。
不能用wall clock time来做比较。
#4
居然这么来测试
顶lqh_wh(liqh)
顶lqh_wh(liqh)
#5
windows编译器大概已经知道+=(1+2<<1)%2*2-1是个常数了。
看看gcc有什么选项没有?
看看gcc有什么选项没有?
#6
把gcc的优化开到O3试试。
#7
lqh_wh(liqh)解释正确!!!支持!
#8
这样测试是不合理的
影响经常运行有很多因素
影响经常运行有很多因素
#9
我是经过多次随机测试的,time是记录当前的系统时间,两个时间相差就是运行时间了吧,大家有什么好办法测试linux和window的速度呢?
#10
我想我误会了lz的意思。首先澄清几个问题。
1. 程序运行时间,即程序开始执行到程序退出这段时间就是程序的运行时间,这个时间可以采用lz所说的time函数得到。
2. 程序的效率,即程序在运行中占用CPU的时间(实际上是程序占用了多少个时钟周期)。这个采用我所说的times函数得到。
3. 系统的效率。这才是lz真正的目的。系统效率受硬件和OS的影响。这里就不说硬件的影响,而OS的效率是跟OS的实现有关的,如OS如何实现I/O,如何实现进程调渡等等。而LZ只通过一个小程序就觉得Linux的效率不如Windows有失偏颇。如果LZ想比较OS的效率,应该写一些大程序,涉及I/O读写,进程调度,IPC等方面来进行测试,才是比较好的方法。
1. 程序运行时间,即程序开始执行到程序退出这段时间就是程序的运行时间,这个时间可以采用lz所说的time函数得到。
2. 程序的效率,即程序在运行中占用CPU的时间(实际上是程序占用了多少个时钟周期)。这个采用我所说的times函数得到。
3. 系统的效率。这才是lz真正的目的。系统效率受硬件和OS的影响。这里就不说硬件的影响,而OS的效率是跟OS的实现有关的,如OS如何实现I/O,如何实现进程调渡等等。而LZ只通过一个小程序就觉得Linux的效率不如Windows有失偏颇。如果LZ想比较OS的效率,应该写一些大程序,涉及I/O读写,进程调度,IPC等方面来进行测试,才是比较好的方法。
#11
楼主在Windows下用什么编译器?如果不是用gcc的话,就不具备可比性,若要做比较,不妨用 -S参数先编译出汇编,然后整理后分别在Windows和Linux下编译成可执行程序,才具备可比较性,否则编译器的优化有时候会使结果偏离初衷。
另外,这个程序并不能达到比较两个操作系统效率的目的,既然要比较操作系统效率,应该至少调用和操作系统相关的函数,而不是和系统无关的东西。
另外,这个程序并不能达到比较两个操作系统效率的目的,既然要比较操作系统效率,应该至少调用和操作系统相关的函数,而不是和系统无关的东西。
#12
楼主根本就不懂怎么测试.
#13
支持楼主,结果怎样?
#14
victorchen_2000(微力) ( ) 信誉:104 2006-04-12 10:09:00 得分: 0
楼主根本就不懂怎么测试.
---------------------------
本来没什么好说的,只到看了这位老大的
你可以说说你认为的,正确的测试方法是怎么样的嘛
用不着指责别人
楼主根本就不懂怎么测试.
---------------------------
本来没什么好说的,只到看了这位老大的
你可以说说你认为的,正确的测试方法是怎么样的嘛
用不着指责别人
#15
vc的编译器确实会优化那个算式的,你可以在里面带上i进行计算,就不会被优化那么多了
#16
是在同一台机器测试吗?
下面数据在同一台机器测试.
环境: winxp sp1 VS FC4
>cl time_test.c -o time_test.exe
>time_test
count is -1610612736, timespan is: 5
[root@localhost chapter02]# gcc time_test.c -o time_test
[root@localhost chapter02]# ./time_test
count is: -1610612736, timespan is:7
[root@localhost chapter02]#
下面数据在同一台机器测试.
环境: winxp sp1 VS FC4
>cl time_test.c -o time_test.exe
>time_test
count is -1610612736, timespan is: 5
[root@localhost chapter02]# gcc time_test.c -o time_test
[root@localhost chapter02]# ./time_test
count is: -1610612736, timespan is:7
[root@localhost chapter02]#
#17
为了比赛更公平,采用 slay78(天灯石) 的意见,把 i 加入运算中.
#include <stdio.h>
#include <time.h>
int
main(int argc, char *argv[])
{
int i;
double sums;
long time1, time2;
time(&time1);
sums = 0.0;
for (i = 0; i <= 0x5FFFFFFF; i++) {
sums += (1 + 2 << 1)%2*2 - 1 + i/10000;
}
time(&time2);
printf("count is: %f, timespan is:%d\n", sums, time2-time1);
}
测试结果:
[root@localhost chapter02]# gcc time_test.c -o time_test
[root@localhost chapter02]# ./time_test
count is: 129701253350160.000000, timespan is:24
[root@localhost chapter02]#
C:\c\a>time_test1
count is 129701253350160.000000, timespan is: 57
#include <stdio.h>
#include <time.h>
int
main(int argc, char *argv[])
{
int i;
double sums;
long time1, time2;
time(&time1);
sums = 0.0;
for (i = 0; i <= 0x5FFFFFFF; i++) {
sums += (1 + 2 << 1)%2*2 - 1 + i/10000;
}
time(&time2);
printf("count is: %f, timespan is:%d\n", sums, time2-time1);
}
测试结果:
[root@localhost chapter02]# gcc time_test.c -o time_test
[root@localhost chapter02]# ./time_test
count is: 129701253350160.000000, timespan is:24
[root@localhost chapter02]#
C:\c\a>time_test1
count is 129701253350160.000000, timespan is: 57
#18
#19
争论有了结论了么?
#20
效率跟编译器也有一定关系
并且通常系统启动后第一次运行和第二次运行也不一样
并且通常系统启动后第一次运行和第二次运行也不一样
#21
写了几天java,终于看到计算机的东西了。
首先,上面的程序基本上不用什么操作系统的资源,就是基本的运算,这样的测试主要的区别会来自编译器。
sourceid()的方法用的还是不相同的编译器,同时,两者的标准库对于time的处理,系统最小定时精度等,都会带来差异。
我的感觉: i = a + b
这类运算操作系统基本没有干预。上面的测试和操作系统没有本质关系。
首先,上面的程序基本上不用什么操作系统的资源,就是基本的运算,这样的测试主要的区别会来自编译器。
sourceid()的方法用的还是不相同的编译器,同时,两者的标准库对于time的处理,系统最小定时精度等,都会带来差异。
我的感觉: i = a + b
这类运算操作系统基本没有干预。上面的测试和操作系统没有本质关系。
#22
算法,算法
#23
不要太快下结论
#24
up~受益~
#25
处处留心皆学问啊
#26
LZ的操作系统性能测试程序真幽默,很经典