Skip to content

Cpp tips and tricks #1383

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Cpp tips and tricks #1383

wants to merge 5 commits into from

Conversation

jxu
Copy link
Contributor

@jxu jxu commented Oct 24, 2024

Resolves #903

As always, feel free to make any comments or changes.

@jxu
Copy link
Contributor Author

jxu commented Oct 24, 2024

navigation.md and homepage needs to be updated?

@adamant-pwn
Copy link
Member

Yes, we need to update README.md and navigation.md. I'd also mention something of the following:

  • #pragma GCC optimize("Ofast,unroll-loops") allows more aggressive compiler-level optimisation;
  • #pragma GCC target("avx2") allows significant speedups when your code can be auto-vectorized, which primarily affects simple for-loops doing linear transforms (primarily, adding one vector to another, multiplied by some constant);
  • Doing % is very expensive, try to avoid when possible:
    • When adding or subtracting modints;
    • When multiplying at most two modints, consider keeping them modulo $M^2$, until you really need to get back to modulo $M$;
  • Avoid having lots of small containers, like map<int, int> to[maxn]. If you need to keep a lot of lists, consider keeping a vector of basic_string<T> or forward_list<T>, rather than a vector of vector<T> or deque<T>;
  • When iterating nested arrays, try to avoid iterating over earlier indices in the inner loops (e.g. for A[i][j], ideally, i should be in the outer loop, and j should be in the inner loop);
  • Link to Montgomery multiplication;
  • Link to Algorithms for Modern Hardware;
  • Link to some other useful blogs on the topic?

@jxu
Copy link
Contributor Author

jxu commented Oct 24, 2024

I'd also mention something of the following:

I agree with you, but I want to get the simple things down in an article first.

@mhayter
Copy link
Contributor

mhayter commented Oct 27, 2024

There's still some formatting problems: some C++ keywords are not formatted, the subpoints of the #define section need to be formatted as such.

I'm not convinced we should be pushing a lot of what's currently in the article:

Defining int as long long is super hacky and likely should not be taught imo.

The using namespace std section seems unnecessary.

The statement that C++ is, by default, iostreams doesn't really make sense as one can avoid using them.

Some of the only necessary knowledge is disabling the sync and the endl vs '\n' and flush portion.

@jxu
Copy link
Contributor Author

jxu commented Nov 4, 2024

There's still some formatting problems: some C++ keywords are not formatted, the subpoints of the #define section need to be formatted as such.

Everything has been formatted afaict. You can highlight specific places that haven't.

I'm not convinced we should be pushing a lot of what's currently in the article:

Defining int as long long is super hacky and likely should not be taught imo.

Yes it's hacky, so I included a note that it's not recommended. But you may encounter this when looking at other people's submissions.

The using namespace std section seems unnecessary.

I think it's important to point out the naming conflicts, which can be confusing.

The statement that C++ is, by default, iostreams doesn't really make sense as one can avoid using them.

You can, but my understanding is that C-style I/O is only provide compatibility with C libraries.

Some of the only necessary knowledge is disabling the sync and the endl vs '\n' and flush portion.

The explanations aren't strictly necessary, but I think it's better to explain why than just provide a template for copy-pasting.

@jxu jxu requested a review from adamant-pwn November 11, 2024 16:21
@jxu
Copy link
Contributor Author

jxu commented Jan 6, 2025

@adamant-pwn is the page good enough for a new article? There is a balance between quality control and not getting stuck forever. I think the info as it is currently is more beneficial published and then tweaked later than not having anything on it.

@adamant-pwn
Copy link
Member

I still think we should implement some of the suggestions from #1383 (comment). We certainly have to update README.md and navigation.md in any case, as is the process when adding new articles, but I also think that a lot of the other points are very low-effort to add (and can be essentially transfered from the comment), and should not be a reason to get stuck forever.

@mhayter
Copy link
Contributor

mhayter commented Mar 25, 2025

I agree with @adamant-pwn. No offense but the article seems low effort and no time was put in to improve it. Instead there was another request to "just publish it".

Formatting isn't consistent:

"cout every time you read from cin". No formatting even exists on this line at quick glance.

I'd prefer intro paragraphs on why we need faster io and other topics but I sort of feel at this point that there's potentially too much time reviewing relative to the effort of the article.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Article on common I/O optimizations
3 participants