Hello codeforces community I wanna learn how to use Fread Fwrite for faster I/O.
If you have any useful example, I will be thankful :D.
№ | Пользователь | Рейтинг |
---|---|---|
1 | tourist | 3993 |
2 | jiangly | 3743 |
3 | orzdevinwang | 3707 |
4 | Radewoosh | 3627 |
5 | jqdai0815 | 3620 |
6 | Benq | 3564 |
7 | Kevin114514 | 3443 |
8 | ksun48 | 3434 |
9 | Rewinding | 3397 |
10 | Um_nik | 3396 |
Страны | Города | Организации | Всё → |
№ | Пользователь | Вклад |
---|---|---|
1 | cry | 167 |
2 | Um_nik | 163 |
3 | maomao90 | 162 |
3 | atcoder_official | 162 |
5 | adamant | 159 |
6 | -is-this-fft- | 158 |
7 | awoo | 155 |
8 | TheScrasse | 154 |
9 | Dominater069 | 153 |
10 | nor | 152 |
Hello codeforces community I wanna learn how to use Fread Fwrite for faster I/O.
If you have any useful example, I will be thankful :D.
Название |
---|
Don't. Really. If a contest requires you to use anything beyond scanf/printf (with some tricks, maybe) to get AC, then the contest is wrong.
There are a few contests where you have "best answer" type questions. i.e. the better your answer is to the actual answer, the higher is your score. In these cases, one would like to have fast I/O and fast precomputation to have more time for the actual searching in the solution space.
Also, for deterministic problems, it might help to optimize our codes(mainly in codechef problems) especially if we have a code that will surely pass with enough optimizations.
But if you really need to desperately optimize constants, I/O should take negligible time. In challenge problems especially, these don't have large input data.
I've come across a single problem where you needed faster I/O than printf/scanf, in all my life. It was CEOI 2012, practice session problem 1. The problem was trivial, but the time limit was set so low that it was impossible to read the input in time. It was an organizers' failure.
my friend, I'm just trying to learn as much as I can, It is not a mistake. And if it was permissible to use them then way not. Thanks any way :)
A contest might not require that, but maybe if you don't find the intended algorithm, you might be able to squeeze an optimized suboptimal solution through.
You can just read my comment above. One does not simply squeeze through with a suboptimal solution by taking down the I/O time from scanf/printf to fread/fwrite. It'd need really, really large data (which rules out basically all challenge problems and many binary-scored ones) and a suboptimal solution that'd be very close to the time limit.
Instead of that, why not learn more useful tricks like reserve(), bitsets, clever ways to use sqrt-decomposition or try to optimize the algorithms you've memorized? Better yet, why not solve problems and only try to learn this after you've encountered a problem where optimizing I/O was really one of the best last steps to take?
Why not do all that and have a fast I/O implementation? It's not like that would be a huge cost. There's just nothing wrong about it, contrary to what you seem to suggest
ಠ_ಠ
Pile up "not a huge cost" many times, and it starts making a difference. It does matter, actually.
How much time would it take you, anyway? About as much as solving a medium difficulty (considering difficulty from the reader's point of view) problem or trying to solve it, reading the editorial and coding a working solution afterwards, maybe?
From my experience, I/O difficulties beyond scanf/cin are practically non-existent, while dumb mistakes are rather frequent (they comprise the majority of my failed solutions lately, like a typo in a constant in my solution of 418B - Cunning Gena — try to calculate the place and points difference caused by that typo). From that POV, it's better to try and eliminate an even rarely occuring small mistake.
An excellent example is CodeChef SEP13, MLCHEF. I made a small mistake that could only be seen on few large inputs — I numbered the vertices as in the input and not in pre-order numbering, once. Finding it was an incredible pain in the ass, but now, I'm watching out for the numbering I'm supposed to use. It took probably longer than learning fI/O, but damn did it pay off!
Your anecdotical evidence does not really support your point. Of course it is more rewarding in the long term to get better at algorithms and solving problems. However using getchar and coding up a custom integer parsing routine (or just copying it from somebody else, because you're not doing it for learning purposes anyway) is a matter of minutes. That's what I meant with "low cost".
Nobody disagrees with your opinion that there is a lot more important stuff to do.
I thought the OP wanted to learn how to use them, so "not for learning purposes" sounds like an oxymoron here.
Also, that's the point of view I considered — copypasting and using pre-written code in contests is the working option here, but there's no point in this question being asked then, unless the OP doesn't know how to google stuff.
Im not attending to use them in codeforces problems and contests But i solved problems on UVA and time limit was really bad, even when i used faster I/O operations like reading numbers using getchar()
Yes, and that's the problem. Even if you use fast I/O, that won't make your code fast enough to make a difference — most of the time. That's why I'm saying this is not a good idea.
Actually, one of such wrong contests was SEERC-2013, where input was from binary file and its size was about 100M of integers (square matrix 10000*10000). And yes, time limit was only 0,5 sec.
Was the memlimit 64 MB? :D
That wouldn't fit into the time limit at all, no? That's like the CEOI I mentioned — the problem setters had a moment of immense stupidity. These situations should be avoided, not prepared for.
No, memory limit was 512 MB;) I was also very surprised, but one of contestants told that fread() worked about 0,2 sec... Unfortunately, some problems in SEERC are prepared by Romanian problem setters which don't have a lot of experience...
They say that the best way to learn something is to do it. For a start you could implement reading and writing
int
s by just usinggetchar()
andputchar()
. Write it, test it, compare the speed to the standard I/O methods. Then you can step it up and replacegetchar()
/putchar()
with your own I/O buffers through the use offread()
/fwrite()
. Again test it, see how different buffer sizes behave, compare this to usinggetchar()
/putchar()
in conjunction withsetvbuf()
.i use
getchar_unlocked()
instead ofgetchar()
. do u know the difference between them?also, using
getchar_unlocked()
results in Compilation error on Codeforces, but it works correctly on my PC (Ubuntu 12.04 LTS), Codechef, and SPOJ. do u know why this is so?Yes. See "Addendum" in http://codeforces.me/blog/entry/5217.
Also, it's you, not u.
thanks. read, upvoted, and favorited! :)
yes, I have learned such operations lately and it show a huge difference in the performance of my solutions, see this link http://ideone.com/F0KFUp but with problems like 11462-Age sort on UVA, my timing still very slow.