Can someone give me the code for fast IO in c++? Thanks very much.
# | User | Rating |
---|---|---|
1 | tourist | 4009 |
2 | jiangly | 3823 |
3 | Benq | 3738 |
4 | Radewoosh | 3633 |
5 | jqdai0815 | 3620 |
6 | orzdevinwang | 3529 |
7 | ecnerwala | 3446 |
8 | Um_nik | 3396 |
9 | ksun48 | 3390 |
10 | gamegame | 3386 |
# | User | Contrib. |
---|---|---|
1 | cry | 167 |
2 | Um_nik | 163 |
3 | maomao90 | 162 |
3 | atcoder_official | 162 |
5 | adamant | 159 |
6 | -is-this-fft- | 158 |
7 | awoo | 157 |
8 | TheScrasse | 154 |
9 | Dominater069 | 153 |
9 | nor | 153 |
Can someone give me the code for fast IO in c++? Thanks very much.
Name |
---|
printf
scanf
faster then that
Maybe faster than velocity of light?
Isn't it speed of light?
reads integers fast
I've compared reading 10^7 integers ([-10^9; 10^9]) in your way and scanf.
Your: 2.45s.
Scanf: 1.98s.
This works a bit faster than scanf:
It`s really faster than scanf, Thanks a lot.I was able to solve the problem which has not previously held a scanf
That is maybe because he was reading long long integers,it probably would have been faster if function was of int type.
Btw your code helped me on one task on SPOJ so thank you!
After reading your comment i wonder why dario-dsa got so many down-votes even though the question is totally right (like, everybody could understand what he was asking), is it because he is cyan ?, please, don't tell me that's the reason, because i saw the first guy proVIDec be like : (Oh, a "new bie", better troll him a little bit)
btw, i know this post is 3-years old
No, he surely wasn't cyan 3 years ago.
Using buffered io very fast:
Go to Codechef. Find a problem with a huge amount of input. Look at the fastest submit. Profit.
You can use fast cin/cout by writing "ios::sync_with_stdio(false);" on the top of your programm!
another approach is to read and store the entire input in a buffer before you begin processing it. Fastest functions are fread and fwrite (they are technically C functions, but should work fine in C++).
I did some benchmarks couple of days ago while trying to find the fastest method for reading integers from stdin. I used input that had 200000 lines and two integers on each line. The results were like this (MinGW 4.8, Intel 3770K):
So it's important to minimize the number of calls to standard library functions. The only type of IO that standard library does fast is transferring large chunks of data. I ended up with the last option because it's almost as fast as buffering the entire input but uses much less memory. Here's the code (it has some flaws but for contests it's good enough):
edit: this version requires manually skipping whitespace (stdinPos++), but it could easily be added to the function itself.
You might also be interested in this article I wrote a while ago; I performed some similar I/O benchmarks: http://mirror.codeforces.com/blog/entry/5217
Interesting results! A minor detail: readInt has a bug. It will not work with the min value of int, e.g. –2,147,483,648 for 4-byte ints. Since 2,147,483,647 is the maxvalue of int, x will be 2,147,483,640 + 8, which is not 2,147,483,648 (since that cannot be represented in an int) and thus -x will not become -2,147,483,648 in the result. If you instead use x -= *stdinPos — '0'; and return neg ? x : -x; it should work.
It is actually correct. 2,147,483,640 + 8 overflows and becomes -2,147,483,648. When this is multiplied by -1 it becomes -2,147,483,648 again.
It doesn't
On most machines it works just fine. I have used mod 2^32 overflow in many competitions and it hasn't failed me once.
It doesn't depend on the machine, it depends on compiler, your code and memory layout, moon phase etc.
You got lucky. You can search Codeforces for 'undefined behavior', 'integer overflow' etc. (But then again, the chances of getting both bad optimization and MIN_INT edge case are minuscule.)
I often, practically always implement, for example, the Rabin-Karp algorithm (and other rolling hash algorithms) using modulo 2^64 and long longs (even on 32-bit machines!). I simply let all the multiplications / additions overflow.
...
Never had a single issue.
Lucky? I don't think so.
Well, you may suppose that this will always work, but I suggest you to meditate on this code and its output a bit: http://ideone.com/JEITIH
What does that have to do with anything? This is clearly a compiler bug.
I know, I know, undefined behavior, this program could set the computer on fire and that would be just fine according to the C++ standard.
However, on MOST architectures, multiplying/adding two numbers about which the compiler cannot know anything (they have something to do with user input, for example), works just fine almost always, because the compiler doesn't bother "optimizing" it.
In this case, you're multiplying numbers about which the compiler knows about and it's a lot easier for the compiler to detect undefined behavior and go haywire (for example, by setting the computer on fire like in your example)
Slightly irrelevant, but since the topic was brought up: I've never seen contests that give contestant choice to perform IO using either:
Of course, this "ability to choose" has cons:
Could this idea be used (at least) for problems that have big input/output files? By that, I mean — in the description of a task don't add comment that goes like this:
"oh yeah, input's huge, don't use slow IO, like C++ cin/cout, use printf/scanf",
but provide an option to read from "input.txt" or "binary.in", and write to "output.txt" or "binary.out".
fast IO from Burunduk1
Premature optimization is the root of all evil. Strict to cin/cout or scanf/printf.
I was looking for a "real C++" fast Input solution. So I thought about std::cin.readsome() and tried to substitute it to fread(), but even if it's fine on my terminal it is not working on judging servers...