同样一段代码( C++ fstream 读 / 写 9000000 个数字),在不同环境下为何差异那么大?

2016-08-11 12:55:13 +08:00
 t123yh

以下是测试代码:

#include <iostream>
#include <vector>
#include <fstream>

using namespace std;

int main(int argc, char **argv)
{
	if (argc != 2)
	{
		cout << "syntax: benchmark <option>" << endl << "option can be r or w" << endl;
		cout << "argc: " << argc << endl;
		return 1;
	}
	const int count = 9000000;
	vector<int> data(count);
	if (argv[1][0] == 'w')
	{
		ofstream fout("test.txt");
		for (int i = 0; i < count; i++)
		{
			fout << i << " ";
		}
	}
	else if (argv[1][0] == 'r')
	{
		ifstream fin("test.txt");
		for (int i = 0; i < count; i++)
		{
			fin >> data[i];
		}
	}
}

这段代码会自动生成 test.txt ,其中是 0 - 8999999 这 9000000 个数字。 注: Windows 上使用 ptime( http://www.pc-tools.net/win32/ptime/) 测试运行时间; Linux 取 time 命令返回的 real 值。 不同环境下,差异为何如此之大?特别是 Ubuntu 和 WSL ,用的 binary 都是一样的( WSL 上编译,然后复制到 Ubuntu )如何减小 Ubuntu 上运行时间?

3690 次点击
所在节点    程序员
16 条回复
exch4nge
2016-08-11 13:31:09 +08:00
没明白楼主这测试意义何在……这段代码运行时间主要跟以下几个东西有关
0. 硬件( CPU ,磁盘)
1. 编译器。 crt 实现,编译优化程度。
2. 文件系统
3. 同 OS 中的其它进程
等等……

Ubuntu 和 WSL 的 binary 一样,但貌似硬件不一样吧
t123yh
2016-08-11 14:29:58 +08:00
@exch4nge 但 WSL 和 Windows 差距不应如此之大啊,主要是如何优化
arakashic
2016-08-11 14:49:03 +08:00
LZ 你这测试方法就有问题,你测试的是程序整体的执行时间,影响因素太多了。你至少应该把不同部分的执行时间测一下,然后再分析为什么。
just4test
2016-08-11 14:54:20 +08:00
i7 和赛扬能一样吗?这不是废话。
磁盘有写入缓存,你这数据量太少不会充满写入缓存,因此所有磁盘都可以认为是 randisk 。
然后瓶颈就是内存频率 /带宽和 cpu 了。
exch4nge
2016-08-11 15:21:05 +08:00
@t123yh 我这边没有 WSL ,没法具体测。另外一个主要占用 CPU 的是 stream 的<<与>>,尤其用 MS 的 CRT 的时候,这部分转换比较耗时。

C++的 iostream 遭人唾弃是有原因的,一般都不会用于高频读写。

WSL 和 Windows 差距主要来源于编译器与 CRT 库不一样。

另外 VS2015 默认创建的 C++工程,默认启用了很多编译选项,包括很多检查,这部分也耗费了一些时间。
klausroot
2016-08-11 15:21:45 +08:00
linux 下的是 ext 文件系统, windows 下的 fat32 或 ntfs ,相比之下 ext 的更高效
t123yh
2016-08-11 16:25:37 +08:00
@klausroot WSL 也是在 NTFS 上跑的
whatot
2016-08-11 16:48:40 +08:00
archlinux g++ 6.1.1 -O2 ext4

CT480BX200SSD1 写入 0.47s ,读取 0.55s
SM951 写入 0.46s ,读取 0.55s
FrankHB
2016-08-11 17:44:29 +08:00
没 sync_with_stdio(false)纠结啥性能……是想看 cstdio (无误)实现得有多蠢么……
FrankHB
2016-08-11 17:48:49 +08:00
@FrankHB 好吧,文件流……以上作废。首先 Debug 没啥可比性就不用管了(调_ITERATOR_DEBUG_LEVEL 和_GLIBCXX_DEBUG 也不能指望半径八两)。然后……噫,这些环境的外部变量太多,还是没啥可比性啊……
FrankHB
2016-08-11 17:52:57 +08:00
比较能直接比较的 WSL 的差距,猜测是 M$自知 NTFS 太笨重所以在 WSL 实现文件系统驱动塞了些特技,调缓存之类。
嗯, Naive Windows ……
yonka
2016-08-11 18:18:24 +08:00
@FrankHB 活捉帝球
Neveroldmilk
2016-08-11 18:46:11 +08:00
VS2015 的 Debug 模式是不是开了什么性能检测的额外功能了。另外,不同 C 编译器的性能和分区类型不一样也会导致性能差异。
t123yh
2016-08-11 23:44:55 +08:00
@FrankHB 我用的 fstream ,和 cstdio 无关
t123yh
2016-08-11 23:46:39 +08:00
好了,估计是 CPU 性能问题,我在 i7 的 Ubuntu 上跑出了 0.4s 的结果
ragnaroks
2016-08-13 10:01:10 +08:00
说明 Windows 还是 Naive 啊

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/298616

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX