为什么在 C ++ 中从 stdin 读取行比 Python 慢得多?

我想比较使用 Python 和 C ++ 从 stdin 读取的字符串输入的行数,并震惊地看到我的 C ++ 代码运行速度比等效的 Python 代码慢一个数量级。由于我的 C ++ 生锈,而且我还不是专家 Pythonista,因此请告诉我我做错了什么还是误解了。


(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,后者是非常强大的服务器,并不是说这太相关了。

$ 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

微小的基准附录和总结

为了完整起见,我认为我将使用原始(已同步)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

答案

缺省情况下, cin与 stdio 同步,这使它避免了任何输入缓冲。如果将其添加到主目录的顶部,应该会看到更好的性能:

std::ios_base::sync_with_stdio(false);

通常,当缓冲输入流时,而不是一次读取一个字符,而是以更大的块读取该流。这减少了系统调用的数量,这些调用通常比较昂贵。但是,由于基于FILE*stdioiostreams通常具有单独的实现,因此也具有单独的缓冲区,因此,如果将两者一起使用,可能会导致问题。例如:

int myvalue1;
cin >> myvalue1;
int myvalue2;
scanf("%d",&myvalue2);

如果cin读取的输入多于实际需要的输入,则第二个整数值将不适用于scanf函数,该函数具有自己的独立缓冲区。这将导致意外的结果。

为避免这种情况,默认情况下,流与stdio同步。实现此目的的一种常用方法是让cin使用stdio函数一次读取一个字符。不幸的是,这带来了很多开销。对于少量输入来说,这不是一个大问题,但是当您读取数百万行时,性能损失将是巨大的。

幸运的是,库设计人员决定,如果您知道自己在做什么,则还应该能够禁用此功能以提高性能,因此他们提供了sync_with_stdio方法。

出于好奇,我了解了实际情况,并且在每次测试中都使用了dtruss / strace

C ++

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

系统调用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

系统调用sudo dtruss -c ./a.py < in

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

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

在原始帖子的 “编辑 4/5/6” 中,您正在使用以下结构:

$ /usr/bin/time cat big_file | program_to_benchmark

这有两种不同的错误方式:

  1. 您实际上是在计时执行 cat 的时间,而不是基准测试的时间。 “时间”显示的 “用户” 和 “系统” CPU 使用情况是 “猫” 的使用情况,而不是基准测试程序。更糟糕的是,“实时” 时间也不一定准确。根据 cat 的实现以及本地操作系统中管道的实现,cat 可能会写入最终的巨型缓冲区,并在阅读器进程完成其工作之前很长时间退出。

  2. 使用 cat 是不必要的,实际上会适得其反;您正在添加活动部件。如果您使用的是足够老的系统(例如,具有单个 CPU,并且 - 在某些代代计算机中 - I / O 比 CPU 更快),那么 `cat'正在运行这一事实就可能使结果显色。您还必须遵守输入和输出缓冲以及其他处理方法 “cat” 可能做的任何事情。 (如果我是 Randal Schwartz,这可能会为您赢得“猫的无用使用”奖。

更好的构造是:

$ /usr/bin/time program_to_benchmark < big_file

在此语句中, 外壳程序将打开 big_file,并将其作为已打开的文件描述符传递给您的程序(实际上是传递给 “time”,然后将其作为子进程执行)。所读取文件的 100%严格是您要进行基准测试的程序的责任。这使您可以真正了解其性能,而不会产生虚假的并发症。

我会提到两个可能但实际上是错误的 “修复程序”,这些也可以考虑(但我对它们进行了 “不同” 的编号,因为这些并不是原始帖子中出现的错误):

答:您可以通过仅定时执行程序来 “修复” 此问题:

$ cat big_file | /usr/bin/time program_to_benchmark

B. 或通过计时整个管道:

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

由于与#2 相同的原因,它们是错误的:它们仍在不必要地使用 `cat`。我提到它们的原因有几个:

  • 对于对 POSIX shell 的 I / O 重定向功能不完全满意的人来说,它们更 “自然”

  • 可能存在 ` 需要 cat` 情况下(例如:要读取的文件需要某种特权来访问,并且不希望授予该特权的程序进行基准测试:`sudo 的猫 / dev / sda 上 | / usr / bin / time my_compression_test --no-output`)

  • 在实践中 ,在现代机器上,管道中添加的 “cat” 可能没有实际意义

但是我有些犹豫地说那最后一件事。如果我们检查 “Edit 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

只会花剩下的 0.49 秒!可能不是:cat 必须支付 read()系统调用(或等效调用),该调用从 “磁盘”(实际上是缓冲区高速缓存)传输了文件,并且通过管道写入将文件传递给 wc。正确的测试仍然必须执行这些 read()调用;只有写到管道和读到管道调用将被保存,并且这些调用应该非常便宜。

不过,我预计您将能够测量 `cat file | wc -l` 和 `wc -l

实际上,我在 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 时间(user + sys)比实时更多。这是因为我正在使用 shell(Bash)的内置 “time” 命令,该命令可以识别管道。我在多核计算机上,流水线中的各个进程可以使用各个核,因此,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 在许多情况下,该语言是使用其编写的语言的 I / O 库)在提供引用常规文件的文件描述符时可能会采取不同的操作。它可以使用 mmap(2)将输入文件映射到其地址空间,而不是使用显式的 read(2)系统调用。这些差异可能对您的基准测试结果产生的影响远大于运行 “cat” 二进制文件的少量费用。

当然,如果同一程序在两种情况下的执行情况显着不同,这将是一个有趣的基准测试结果。它表明确实,该程序或其 I / O 库正在做一些有趣的事情,例如使用 mmap()。因此,在实践中最好同时使用两种基准。也许将 cat 的结果折价一些,以 “原谅” cat 本身的运行成本。

我在 Mac 上使用 g ++ 在计算机上重现了原始结果。

while循环之前将以下语句添加到 C ++ 版本,使其与Python版本内联:

std::ios_base::sync_with_stdio(false);
char buffer[1048576];
std::cin.rdbuf()->pubsetbuf(buffer, sizeof(buffer));

sync_with_stdio 将速度提高到 2 秒,并且设置更大的缓冲区将其降低到 1 秒。

如果您不关心文件加载时间或正在加载小型文本文件,则getline ,流运算符scanf可以很方便。但是,如果性能是您所关心的,那么您实际上应该只是将整个文件缓冲到内存中(假设它将适合)。

这是一个例子:

//open file in binary mode
std::fstream file( filename, std::ios::in|::std::ios::binary );
if( !file ) return NULL;

//read the size...
file.seekg(0, std::ios::end);
size_t length = (size_t)file.tellg();
file.seekg(0, std::ios::beg);

//read into memory buffer, then close it.
char *filebuf = new char[length+1];
file.read(filebuf, length);
filebuf[length] = '\0'; //make it null-terminated
file.close();

如果需要,可以将流包装在该缓冲区周围,以便更方便地进行访问,如下所示:

std::istrstream header(&filebuf[0], length);

另外,如果您控制文件,请考虑使用平面二进制数据格式而不是文本。读写更加可靠,因为您不必处理所有空白。它也更小且解析速度更快。

对于我来说,以下代码比到目前为止发布的其他代码快:(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 倍。

顺便说一句,C ++ 版本的行数比 Python 版本的行数大 1 个原因是,仅当尝试读取超出 eof 的值时,才会设置 eof 标志。因此正确的循环将是:

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

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

在您的第二个示例(带有 scanf())的情况下,这样做仍然较慢的原因可能是因为 scanf(“%s”)解析了字符串并查找了任何空格字符(空格,制表符,换行符)。

同样,是的,CPython 进行了一些缓存以避免硬盘读取。

答案的第一要素: <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;
}

好吧,我看到在您的第二个解决方案中,您从cin切换到scanf ,这是我要提出的第一个建议(cin 是 sloooooooooooow)。现在,如果您从scanf切换到fgets ,您将看到性能的另一个提升: fgets是用于字符串输入的最快的 C ++ 函数。

顺便说一句,不知道同步的事情,很好。但是您仍然应该尝试fgets