[C++] 为什么读取stdin中的行比C ++慢得多?


Answers

出于好奇,我看了一下发生了什么,我在每次测试中都使用了dtruss/strace

C ++

./a.out < in
Saw 6512403 lines in 8 seconds.  Crunch speed: 814050

syscalls sudo dtruss -c ./a.out < in

CALL                                        COUNT
__mac_syscall                                   1
<snip>
open                                            6
pread                                           8
mprotect                                       17
mmap                                           22
stat64                                         30
read_nocancel                               25958

蟒蛇

./a.py < in
Read 6512402 lines in 1 seconds. LPS: 6512402

syscalls sudo dtruss -c ./a.py < in

CALL                                        COUNT
__mac_syscall                                   1
<snip>
open                                            5
pread                                           8
mprotect                                       17
mmap                                           21
stat64                                         29
Question

我想比较使用Python和C ++的stdin字符串输入的读取行,并且很惊讶地看到我的C ++代码比等效的Python代码慢了一个数量级。 由于我的C ++很生疏,而且我还不是专家蟒蛇,所以请告诉我,如果我做错了什么或者我误解了某些东西。

(TLDR答案:包括声明: cin.sync_with_stdio(false)或者只是使用fgets代替。

TLDR结果:一直滚动到我的问题的底部并查看表格。)

C ++代码:

#include <iostream>
#include <time.h>

using namespace std;

int main() {
    string input_line;
    long line_count = 0;
    time_t start = time(NULL);
    int sec;
    int lps;

    while (cin) {
        getline(cin, input_line);
        if (!cin.eof())
            line_count++;
    };

    sec = (int) time(NULL) - start;
    cerr << "Read " << line_count << " lines in " << sec << " seconds.";
    if (sec > 0) {
        lps = line_count / sec;
        cerr << " LPS: " << lps << endl;
    } else
        cerr << endl;
    return 0;
}

// Compiled with:
// g++ -O3 -o readline_test_cpp foo.cpp

Python等效:

#!/usr/bin/env python
import time
import sys

count = 0
start = time.time()

for line in  sys.stdin:
    count += 1

delta_sec = int(time.time() - start_time)
if delta_sec >= 0:
    lines_per_sec = int(round(count/delta_sec))
    print("Read {0} lines in {1} seconds. LPS: {2}".format(count, delta_sec,
       lines_per_sec))

这是我的结果:

$ cat test_lines | ./readline_test_cpp
Read 5570000 lines in 9 seconds. LPS: 618889

$cat test_lines | ./readline_test.py
Read 5570000 lines in 1 seconds. LPS: 5570000

编辑: 我应该注意到,我在Mac OS X v10.6.8(Snow Leopard)和Linux 2.6.32(Red Hat Linux 6.2)下都尝试了这一点。 前者是一台MacBook Pro,后者则是一台非常强大的服务器,并不是说这样太贴切。

编辑2 :( 删除此编辑,不再适用)

$ for i in {1..5}; do echo "Test run $i at `date`"; echo -n "CPP:"; cat test_lines | ./readline_test_cpp ; echo -n "Python:"; cat test_lines | ./readline_test.py ; done
Test run 1 at Mon Feb 20 21:29:28 EST 2012
CPP:   Read 5570001 lines in 9 seconds. LPS: 618889
Python:Read 5570000 lines in 1 seconds. LPS: 5570000
Test run 2 at Mon Feb 20 21:29:39 EST 2012
CPP:   Read 5570001 lines in 9 seconds. LPS: 618889
Python:Read 5570000 lines in 1 seconds. LPS: 5570000
Test run 3 at Mon Feb 20 21:29:50 EST 2012
CPP:   Read 5570001 lines in 9 seconds. LPS: 618889
Python:Read 5570000 lines in 1 seconds. LPS: 5570000
Test run 4 at Mon Feb 20 21:30:01 EST 2012
CPP:   Read 5570001 lines in 9 seconds. LPS: 618889
Python:Read 5570000 lines in 1 seconds. LPS: 5570000
Test run 5 at Mon Feb 20 21:30:11 EST 2012
CPP:   Read 5570001 lines in 10 seconds. LPS: 557000
Python:Read 5570000 lines in  1 seconds. LPS: 5570000

编辑3:

好吧,我尝试了JN的建议,试图让Python存储行读取:但它对python的速度没有任何影响。

我也尝试过JN的建议,将scanf转换为char数组,而不是将getline转换为std::string 。 答对了! 这导致Python和C ++的性能相当。 (我的输入数据是3,333,333个LPS,顺便说一句,每个都只有三个字段的短行,通常约20个字符宽,有时甚至更多)。

码:

char input_a[512];
char input_b[32];
char input_c[512];
while(scanf("%s %s %s\n", input_a, input_b, input_c) != EOF) {
    line_count++;
};

速度:

$ cat test_lines | ./readline_test_cpp2
Read 10000000 lines in 3 seconds. LPS: 3333333
$ cat test_lines | ./readline_test2.py
Read 10000000 lines in 3 seconds. LPS: 3333333

(是的,我跑了几次。)所以,我想我现在将使用scanf而不是getline 。 但是,如果人们认为std::string / getline这种性能是典型和合理的,我仍然很好奇。

编辑4(是:最终编辑/解决方案):

添加:

cin.sync_with_stdio(false);

在我上面的原始while循环之上立即产生比Python运行得更快的代码。

新的性能比较 (这是在我的2011年MacBook Pro上),分别使用原始代码,禁用同步的原始代码和原始Python代码,在具有20M行文本的文件上进行比较。 是的,我跑了几次,以消除磁盘缓存混淆。

$ /usr/bin/time cat test_lines_double | ./readline_test_cpp
       33.30 real         0.04 user         0.74 sys
Read 20000001 lines in 33 seconds. LPS: 606060
$ /usr/bin/time cat test_lines_double | ./readline_test_cpp1b
        3.79 real         0.01 user         0.50 sys
Read 20000000 lines in 4 seconds. LPS: 5000000
$ /usr/bin/time cat test_lines_double | ./readline_test.py
        6.88 real         0.01 user         0.38 sys
Read 20000000 lines in 6 seconds. LPS: 3333333

感谢@Vaughn Cato的回答! 任何精心制作的人们都可以做出很好的引用,人们可以指出为什么这种同步发生,它的意思,什么时候有用,什么时候可以禁用,将会被后人所高度赞赏。 :-)

编辑5 /更好的解决方案:

正如Gandalf The Gray所建议的那样, scanfscanf或非同步cin方法更快。 我还了解到scanfgets都是不安全的,并且由于潜在的缓冲区溢出而不应该被使用。 所以,我用fgets写了这个迭代,这是获得更安全的选择。 下面是我的同伴新手的相关内容:

char input_line[MAX_LINE];
char *result;

//<snip>

while((result = fgets(input_line, MAX_LINE, stdin )) != NULL)
    line_count++;
if (ferror(stdin))
    perror("Error reading stdin.");

现在,下面是在具有非常快的磁盘的快速服务器上使用更大文件(100M行;〜3.4 GB)的结果,比较Python代码,非同步cinfgets方法,以及与wc实用程序进行比较。 [ scanf版本分割错误,我不想排除故障。]:

$ /usr/bin/time cat temp_big_file | readline_test.py
0.03user 2.04system 0:28.06elapsed 7%CPU (0avgtext+0avgdata 2464maxresident)k
0inputs+0outputs (0major+182minor)pagefaults 0swaps
Read 100000000 lines in 28 seconds. LPS: 3571428

$ /usr/bin/time cat temp_big_file | readline_test_unsync_cin
0.03user 1.64system 0:08.10elapsed 20%CPU (0avgtext+0avgdata 2464maxresident)k
0inputs+0outputs (0major+182minor)pagefaults 0swaps
Read 100000000 lines in 8 seconds. LPS: 12500000

$ /usr/bin/time cat temp_big_file | readline_test_fgets
0.00user 0.93system 0:07.01elapsed 13%CPU (0avgtext+0avgdata 2448maxresident)k
0inputs+0outputs (0major+181minor)pagefaults 0swaps
Read 100000000 lines in 7 seconds. LPS: 14285714

$ /usr/bin/time cat temp_big_file | wc -l
0.01user 1.34system 0:01.83elapsed 74%CPU (0avgtext+0avgdata 2464maxresident)k
0inputs+0outputs (0major+182minor)pagefaults 0swaps
100000000


Recap (lines per second):
python:         3,571,428
cin (no sync): 12,500,000
fgets:         14,285,714
wc:            54,644,808

正如你所看到的, fgets比较好,但离wc性能还差得很远; 我很确定这是由于wc检查每个字符而没有任何内存复制的事实。 我怀疑在这一点上,代码的其他部分将成为瓶颈,所以即使可能的话,我也不认为优化到这个水平甚至是值得的(因为毕竟我实际上需要存储读取线在记忆中)。

还要注意,使用char *缓冲区和fgets与非同步cin进行字符串的小折衷是,后者可以读取任意长度的行,而前者要求将输入限制为某个有限数字。 在实践中,读取大多数基于行的输入文件可能不是问题,因为缓冲区可以设置为一个非常大的值,不会被有效输入超出。

这是教育。 感谢大家的意见和建议。

编辑6:

正如JF Sebastian在下面的评论中所建议的那样,GNU wc实用程序使用plain C read() (在safe-read.c包装内)来一次读取16k字节块并计算新行。 下面是一个基于JF代码的Python等价物(只显示替代Python for循环的相关代码片段:

BUFFER_SIZE = 16384
count = sum(chunk.count('\n') for chunk in iter(partial(sys.stdin.read, BUFFER_SIZE), ''))

这个版本的性能非常快(当然,仍然比原始的C wc工具慢):

$ /usr/bin/time cat temp_big_file | readline_test3.py
0.01user 1.16system 0:04.74elapsed 24%CPU (0avgtext+0avgdata 2448maxresident)k
0inputs+0outputs (0major+181minor)pagefaults 0swaps
Read 100000000 lines in 4.7275 seconds. LPS: 21152829

同样,对于我来说,将C ++ fgets / cin和第一个Python代码与wc -l以及另一个Python代码片段进行比较对我来说有点愚蠢,因为后两者实际上并不存储读取的行,但是只需要换行符。 不过,探索所有不同的实现并考虑性能影响是很有趣的。 再次感谢!

编辑7:微小的基准附录和回顾

为了完整起见,我认为我会用原始(同步的)C ++代码更新同一个文件夹中相同文件的读取速度。 再次,这是一个快速磁盘上的100M行文件。 这里是完整的表格:

Implementation      Lines per second
python (default)           3,571,428
cin (default/naive)          819,672
cin (no sync)             12,500,000
fgets                     14,285,714
wc (not fair comparison)  54,644,808



以下代码对于我来说比目前发布的其他代码更快:(Visual Studio 2013,64位,500 MB文件,行长度均匀地位于[0,1000))。

const int buffer_size = 500 * 1024;  // Too large/small buffer is not good.
std::vector<char> buffer(buffer_size);
int size;
while ((size = fread(buffer.data(), sizeof(char), buffer_size, stdin)) > 0) {
    line_count += count_if(buffer.begin(), buffer.begin() + size, [](char ch) { return ch == '\n'; });
}

它比我们的所有Python尝试都多出2倍。




我在这里落后了几年,但是:

在原文的“编辑4/5/6”中,您使用的是建筑物:

$ /usr/bin/time cat big_file | program_to_benchmark

这在几个不同的方面是错误的:

  1. 你实际上计算`cat`的执行时间,而不是你的基准。 `time'显示的'user'和'sys'CPU使用率是`cat`的,而不是基准程序。 更糟糕的是,“真实”时间也不一定准确。 根据你本地操作系统中`cat`和管道的实现情况,`cat`可能会写入一个最终的巨大缓冲区,并在读者程序结束之前就退出。

  2. 使用“猫”是不必要的,事实上也适得其反。 你正在添加移动部件。 如果你使用的是足够旧的系统(即只有一个CPU,并且 - 在某些代计算机中--I / O比CPU更快) - “猫”运行的事实可能会大大增加结果的颜色。 你也受到任何输入和输出缓冲以及`cat`可能做的其他处理的支配。 (如果我是兰德尔施瓦茨,这可能会让你获得'无用的猫'奖: https://en.wikipedia.org/wiki/Cat_(Unix)#UUOC_(Useless_Use_Of_Cat) ://en.wikipedia.org/wiki/Cat_(Unix https://en.wikipedia.org/wiki/Cat_(Unix)#UUOC_(Useless_Use_Of_Cat) #UUOC_(Useless_Use_Of_Cat https://en.wikipedia.org/wiki/Cat_(Unix)#UUOC_(Useless_Use_Of_Cat)

更好的构造是:

$ /usr/bin/time program_to_benchmark < big_file

在这个声明中,它是打开big_file的shell ,将它传递给你的程序(实际上是'time',然后作为一个子进程执行你的程序)作为一个已经打开的文件描述符。 文件阅读的100%严格是您试图进行基准测试的程序的责任。 这可以让您真正了解其性能,而不会产生虚假复杂情况。

我会提到两个可能的,但实际上是错误的,也可以考虑的“修复”(但我对它们的编号是不同的,因为它们不是原始文章中错误的):

答:你可以通过只计算你的程序来修复这个问题:

$ cat big_file | /usr/bin/time program_to_benchmark

B.或通过对整个管线进行计时:

$ /usr/bin/time sh -c 'cat big_file | program_to_benchmark'

由于与#2相同的原因,这些都是错误的:他们仍在不必要地使用“猫”。 我提到他们有几个原因:

  • 对于那些不熟悉POSIX shell的I / O重定向功能的人来说,它们更“自然”

  • 可能会出现需要`cat` 情况(例如:要读取的文件需要某种特权才能访问,而且您不希望将该特权授予要进行基准测试的程序:`sudo cat / dev / sda | / usr / bin / time my_compression_test --no-output`)

  • 在实践中 ,在现代化的机器上,管道中增加的“猫”可能没有真正的结果

但是我有些犹豫地说最后一件事。 如果我们检查'编辑5'中的最后一个结果 -

$ /usr/bin/time cat temp_big_file | wc -l
0.01user 1.34system 0:01.83elapsed 74%CPU ...

- 这声称在测试过程中`cat`消耗了74%的CPU; 事实上1.34 / 1.83约为74%。 也许是一连串的:

$ /usr/bin/time wc -l < temp_big_file

本来只需要剩下的49秒! 可能不是:`猫`在这里必须支付read()系统调用(或等价物),它将文件从“磁盘”(实际上是缓冲区缓存)中转移出来,以及管道写入将它们传递给`wc`。 正确的测试仍然必须执行read()调用; 只有写入管道和管道读取会被保存,而且这些应该相当便宜。

不过,我预测你可以测量`cat file |之间的差异 wc -l`和`wc -l <​​file`,并找到明显的(2位百分比)差异。 每个较慢的测试都会在绝对时间内支付类似的惩罚; 这将占其较大总时间的一小部分。

事实上,我在Linux 3.13(Ubuntu 14.04)系统上用1.5 GB的垃圾文件做了一些快速测试,获得了这些结果(当然,这些结果实际上是'3中最好的结果;在启动缓存之后):

$ time wc -l < /tmp/junk
real 0.280s user 0.156s sys 0.124s (total cpu 0.280s)
$ time cat /tmp/junk | wc -l
real 0.407s user 0.157s sys 0.618s (total cpu 0.775s)
$ time sh -c 'cat /tmp/junk | wc -l'
real 0.411s user 0.118s sys 0.660s (total cpu 0.778s)

请注意,这两个管道结果声称占用了比实时更多的CPU时间(用户+ sys)。 这是因为我正在使用shell(Bash)的内置“时间”命令,这是对管道的认识; 而且我在多核机器上,管道中的单独进程可以使用不同的核心,因此CPU时间比实时更快。 使用/ usr / bin / time我看到的CPU时间比实时更短 - 表明它只能对在其命令行上传递给它的单个管道元素计时。 另外,shell的输出会给出毫秒数,而/ usr / bin / time只能给出秒数的结果。

因此,在`wc -l`的效率水平上,`cat`会产生巨大的差异:409/283 = 1.453或45.3%的实时性,775/280 = 2.768,或者使用的CPU超过177%! 在我的随机它是在那里的时间测试盒。

我应该补充说,这些测试方式之间至少存在一个其他显着差异,我不能说这是否是一种好处或缺点; 你必须自己决定:

当你运行`cat big_file | / usr / bin / time my_program`,你的程序正在接收来自管道的输入,正好以`cat`发送的速度,并且不大于`cat`写入的区块。

当你运行`/ usr / bin / time my_program <big_file`时,你的程序会收到一个打开的文件描述符给实际的文件。 您的程序 - 或者在很多情况下,其写入语言的I / O库 - 在提供引用常规文件的文件描述符时可能会采取不同的操作。 它可以使用mmap(2)将输入文件映射到其地址空间,而不是使用显式读取(2)系统调用。 这些差异对基准测试结果的影响可能远远大于运行`cat`二进制文件的小本钱。

当然这是一个有趣的基准测试结果,如果同一个程序在两种情况下表现差异很大。 它表明,确实,程序或其I / O库正在做一些有趣的事情,比如使用mmap()。 所以在实践中,两种方式都可以运行基准。 也许可以通过一些小因素来折扣“猫”结果,以“原谅”运行“猫”本身的成本。




顺便说一下,C ++版本的行数大于Python版本的行数的原因在于,只有在尝试读取超出eof时才会设置eof标志。 所以正确的循环将是:

while (cin) {
    getline(cin, input_line);

    if (!cin.eof())
        line_count++;
};



答案的第一个元素: <iostream>很慢。 该死的很慢。 如下所示,我用scanf获得了巨大的性能提升,但仍然比Python慢​​两倍。

#include <iostream>
#include <time.h>
#include <cstdio>

using namespace std;

int main() {
    char buffer[10000];
    long line_count = 0;
    time_t start = time(NULL);
    int sec;
    int lps;

    int read = 1;
    while(read > 0) {
        read = scanf("%s", buffer);
        line_count++;
    };
    sec = (int) time(NULL) - start;
    line_count--;
    cerr << "Saw " << line_count << " lines in " << sec << " seconds." ;
    if (sec > 0) {
        lps = line_count / sec;
        cerr << "  Crunch speed: " << lps << endl;
    } 
    else
        cerr << endl;
    return 0;
}



Links