# | User | Rating |
---|---|---|
1 | tourist | 3985 |
2 | jiangly | 3814 |
3 | jqdai0815 | 3682 |
4 | Benq | 3529 |
5 | orzdevinwang | 3526 |
6 | ksun48 | 3517 |
7 | Radewoosh | 3410 |
8 | hos.lyric | 3399 |
9 | ecnerwala | 3392 |
9 | Um_nik | 3392 |
# | User | Contrib. |
---|---|---|
1 | cry | 169 |
2 | maomao90 | 162 |
2 | Um_nik | 162 |
4 | atcoder_official | 161 |
5 | djm03178 | 158 |
6 | -is-this-fft- | 157 |
7 | adamant | 155 |
8 | Dominater069 | 154 |
8 | awoo | 154 |
10 | luogu_official | 150 |
Name |
---|
Your pragmas are the culprit. Remove them and you'll get AC. Submission: https://codeforces.net/contest/1580/submission/138986509
Lambda functions are not to blame here.
lol. I thought having those pragmas cant really hurt. So extended question, why is having pragmas with these lambda functions so slow?
I've narrowed the problem to
-ffinite-math-only -msse3
used together (disabling either one produces AC). Couldn't figure the rest yet. Don't understand why this matters to a program that doesn't use floating point numbers either.UPD: The two options together prevent GCC from inlining the
get
lambda for some reason.Here's the shortest reproducible example so far: https://godbolt.org/z/17b1951hY. The interesting part is that the
#include <cstdio>
line is required for this bug.It gets worse. https://godbolt.org/z/vhxfxKPjq
See, if I remove the definition of
fn
it inlines the lambda correctly, but if I add any (even empty) function, then it stops working. But only if this function is defined beforesolve
. Don't ask.If anyone's interested, I reported the (unconfirmed yet) bug here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103696
This is now fixed on trunk: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103696#c6
Thanks for helping the community at large by reporting bugs like this!
I'm not so sure why, but
Ofast
is worse thanO3
in quite a few situations, so I avoid using it. As you mentioned in your comment, removing-ffinite-math-only
works (still don't know why), and it is turned on by default if you useOfast
, but not inO3
.Why a function was inlined in one context and why it wasn't in another context is a question that usually requires insight on the the choice of compiler optimizations in various contexts, which is a very complicated matter overall. In general, if you stick to
O3
and target few architectures, your code should not face such weird issues.I'm not sure about your particular scenario but in general lambda functions are a zero cost abstraction.
In fact, due to their narrower scope, the compiler can make stronger assumptions about their use, leading to better optimizations.