[python] 왜 C ++에서 stdin에서 행을 읽는 것이 Python보다 속도가 느립니까?

나는 몇 년 뒤에 있지만

원본 게시물의 ‘편집 4/5/6’에서 구성을 사용하고 있습니다.

$ /usr/bin/time cat big_file | program_to_benchmark

이것은 몇 가지 다른 방식으로 잘못되었습니다.

1. 실제로 cat벤치 마크가 아닌 의 실행시기를 정하고 있습니다. 표시되는 ‘user’및 ‘sys’CPU 사용량 time은 cat벤치마킹 된 프로그램이 아니라의 CPU 사용량 입니다. 더 나쁜 것은 ‘실시간’도 반드시 정확하지는 않습니다. cat로컬 OS의 파이프 라인 구현 및 구현에 따라 cat최종 거대한 버퍼 를 작성하고 리더 프로세스가 작업을 마치기 훨씬 전에 종료 될 수 있습니다.

2. 사용 cat은 불필요하며 실제로는 비생산적입니다. 움직이는 부분을 추가하고 있습니다. 충분히 오래된 시스템 (예 : 단일 CPU를 사용하고 특정 세대 컴퓨터에서는 CPU보다 I / O가 더 빠름) cat을 실행 한 경우 실행중인 사실만으로도 결과가 실제로 색상으로 표시 될 수 있습니다. 또한 입력 및 출력 버퍼링 및 기타 처리 cat가 수행 할 수있는 작업에 종속됩니다 . ( 랜들 슈왈츠 (Randal Schwartz) 였다면 ‘ 이것은 고양이의 쓸모없는 사용’ 상을 받게 될 것입니다.

더 나은 구성은 다음과 같습니다.

$ /usr/bin/time program_to_benchmark < big_file

이 성명에서 그것은이다 쉘 (사실에, 당신의 프로그램에 전달, big_file 열리고 time이미 열린 파일 기술자로 다음 서브 프로세스로 프로그램을 실행한다). 파일 읽기의 100 %는 벤치마킹하려는 프로그램의 책임입니다. 이것은 가짜 합병증없이 성능을 실제로 읽습니다.

나는 두 가지 가능성이 있지만 실제로 잘못된 ‘수정’도 언급 할 수 있다고 언급 할 것입니다 (그러나 원래 게시물에서 잘못된 것이 아니기 때문에 다르게 번호를 매 깁니다).

A. 프로그램의 타이밍 만 지정하여이를 ‘수정’할 수 있습니다.

$ cat big_file | /usr/bin/time program_to_benchmark

B. 또는 전체 파이프 라인 타이밍 :

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

# 2와 같은 이유로 잘못되었습니다 : 여전히 cat불필요하게 사용 하고 있습니다. 몇 가지 이유로 언급합니다.

• POSIX 쉘의 I / O 리디렉션 기능에 완전히 익숙하지 않은 사람들에게는 더 ‘자연적’입니다.

• 이 경우있을 수 cat 있다 필요 (예 : 읽을 수있는 파일 액세스 권한이 어떤 종류의 필요는, 당신은 벤치 마크 할 수있는 프로그램이 권한을 부여하지 않습니다 sudo cat /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테스트 중 CPU의 74 % 를 소비 했다고 주장합니다 . 실제로 1.34 / 1.83은 대략 74 %입니다. 아마도 다음과 같은 일이 있습니다.

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

남은 .49 초만 걸렸을 것입니다! 아마 아닙니다 : cat여기 read()에서 파일을 ‘디스크'(실제로는 버퍼 캐시)에서 전송 한 시스템 호출 (또는 동등한)과 파이프가 파일을 전달하기 위해 쓰는 데 대한 비용을 지불 해야했습니다 wc. 올바른 시험은 여전히 ​​그 read()전화 를해야했을 것입니다 . 파이프에 쓰기 및 파이프에서 읽기 호출 만 저장되었을 것이므로 매우 저렴해야합니다.

그래도, 난 당신의 차이를 측정 할 수있을 것이라고 예측 cat file | wc -l하고 wc -l < file그리고 눈에 띄는 (2 자리 비율) 차이를 찾을 수 있습니다. 각각의 느린 테스트는 절대 시간에 비슷한 페널티를 받았습니다. 그러나 전체 시간의 작은 부분에 해당합니다.

실제로 나는 Linux 3.13 (Ubuntu 14.04) 시스템에서 1.5 기가 바이트 가비지 파일로 몇 가지 빠른 테스트를 수행하여 이러한 결과를 얻었습니다 (물론 캐시를 프라이밍 한 후 실제로 ‘최고 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 시간 (사용자 + 시스템)을 사용했다고 주장합니다. 파이프 라인을 인식하는 셸 (bash)의 내장 ‘time’명령을 사용하고 있기 때문입니다. 그리고 파이프 라인의 개별 프로세스가 별도의 코어를 사용하여 CPU 시간을 실시간보다 빠르게 누적 할 수있는 멀티 코어 머신을 사용하고 있습니다. 를 사용하면 /usr/bin/time실시간보다 CPU 시간이 짧아 단일 파이프 라인 요소가 명령 줄에서 전달 된 시간 만 표시 할 수 있음을 보여줍니다. 또한 셸의 출력은 밀리 초를 /usr/bin/time제공 하는 반면 수백 분의 1 초만 제공합니다.

따라서 효율 수준 wc -l은이 cat283분의 409 = 1.453 이상의 실시간 45.3 % = 2.768 및 280분의 775 또는 엄청나게 1백77퍼센트 이상의 CPU를 사용했을 때 큰 차이를 만든다! 내 무작위로 그것은 당시 테스트 상자였습니다.

이러한 테스트 스타일 간에는 적어도 하나의 다른 중요한 차이점이 있으며 이것이 이점인지 결함인지 말할 수 없습니다. 이것을 스스로 결정해야합니다.

를 실행하면 cat big_file | /usr/bin/time my_program프로그램은 파이프에서 정확한 속도로 전송 된 속도로 입력 한 값 cat을 청크로 수신합니다 cat.

를 실행하면 /usr/bin/time my_program < big_file프로그램이 실제 파일에 열린 파일 디스크립터를 수신합니다. 프로그램 ( 또는 많은 경우에 작성된 언어의 I / O 라이브러리)은 일반 파일을 참조하는 파일 디스크립터가 표시 될 때 다른 조치를 취할 수 있습니다. mmap(2)명시 적 read(2)시스템 호출 을 사용하는 대신 입력 파일을 주소 공간에 맵핑하는 데 사용할 수 있습니다 . 이러한 차이는 cat바이너리 를 실행하는 적은 비용보다 벤치 마크 결과에 훨씬 큰 영향을 줄 수 있습니다 .

물론 두 프로그램간에 동일한 프로그램이 크게 다른 성능을 발휘한다면 흥미로운 벤치 마크 결과입니다. 실제로 프로그램이나 I / O 라이브러리 가를 사용 하는 것과 같이 흥미로운 일을하고 있음을 보여줍니다 mmap(). 실제로 벤치 마크를 두 가지 방법으로 실행하는 것이 좋습니다. 아마도 cat운영 비용을 “용서”하기 위해 작은 요소에 의해 결과를 할인 할 수 있습니다 cat.

답변

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

//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);

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'; });
}

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

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