Read-write strategy in Competitive programming and practice

Tram Ho

Of course, now I remember some big misunderstandings in the CP community for a long time by teachers and a piece of divine code – read and write fast. It’s about all C++ read and write in general. Now let’s take it apart and see where everyone went wrong and why it’s been considered right all this time.

Misunderstanding #1: C I/O is faster than C++

In the past, my teacher said that C’s I/O is faster than C++ because cin uses a template , it’s necessary, if it’s a template, it’s also been optimized since it was translated, when it runs up, it won’t affect anything else. And I realized, there are countless articles also claiming that C I/O is faster than C++. So is that true? Run test to find out.

Input: 1e7 int ~ 56.7MB

Code:

WSL2:
C scanf: 515ms
C++ input stream: 414ms
Windows:
C scanf: 4479ms
C++ input stream: 1001ms

It doesn’t look like what people say. This is easy to understand, scanf has to parse the input twice (2 inputs), once for the input format, once for the actual data, while cin only parses the real data. But then why do people still see the opposite on test scores? This will be clear later, but mentally it can be seen that scanf cannot be faster than cin, especially with more complicated formats.

Misunderstanding #2: Divine Fast IO is the fastest way to read/write

NO, stop now, it’s the slowest possible way rather than if you don’t understand the nature of the problem. When Fast IO was invented I don’t know, but the spirit of it is to read word by word and analyze directly the value I’m interested in, removing unused features in both scanf and cin, thereby increasing read and write speed. But is it not, let’s try it.

Input: still the same

Code:

WSL2:
Das “Fast IO”: 163ms
C scanf: 519ms
C++ input stream: 403ms
Windows:
Das “Fast IO”: 1201ms
C scanf: 4409ms
C++ input stream: 956ms

Now things are starting to get weird, on WSL2, Fast IO gives good performance, superior to the built-in functions of C or C++, but on Windows it loses to C++ cin. Why, why me? Before answering that question, let’s run this code on both Windows and WSL2:

And the result is:

WSL2Windows
8192512

BUFSIZ is a macro that defines the default buffer size for the IO buffer. So what is buffer and why use buffer? Looking at the basic computer model in the textbook, we have internal memory, external memory, CPU. And why do we need internal memory? Because external memory is very slow, we can’t use data directly from it, we need to get it stuffed into internal memory first and then use it later. Buffer means the same thing, instead of reading every word on a solid drive (or even a hard disk) it will produce extremely slow speeds because the hard drive’s mechanism is that it reads an entire muscle, and each The first time it asks it to read, it has to look for that area – this is extremely slow compared to the actual reading time, now with buffer, we will read a large amount of data into the buffer first and then process it later, like This will reduce the time it takes to find data on the disk. If the buffer is very small, Fast IO cannot be fast, it will have to find data on the disk continuously, which is extremely expensive, but if there is an excess buffer, Fast IO is extremely fast because it eliminates the overhead of remaining 2 methods. Note: If you check the ifstream buffer size with ios::rdbuf::in_avail, by default WSL2 will read the full file and Windows uses 4096 bytes, which also explains why scanf is faster than cin in the test (most likely the program grader translation sets BUFSIZ higher than the default size of ios::rdbuf).

In fact, when taking the exam, you either don’t need to read directly from the disk (readings from stdin/stdout will load before the input into RAM), or they let the buffer size be large enough so Fast IO gives the most terrible speed. . However, when you enter the actual battle, reading every word is lame.

So to summarize, how to properly understand about reading and writing: reading faster, reading faster, doing less miscellaneous things will also read faster.

Bonus code Fast IO when buffered 64MB 🐧:

WSL2:
Das “Fast IO”: 160ms
Better “Fast IO”: 85ms
Windows:
Das “Fast IO”: 1258ms
Better “Fast IO”: 313ms

Share the news now

Source : Viblo