記事は長いです。
0. 使用言語
前はpypy3でやっていたのですが、ロジックを組んでも定数倍でTLEするケースが出てきて、これは言語を変えようと思い、AtCoderのライブラリも使えるC++に変更しました。
環境はUbuntu上でVSCodeを使って実装してます。少し前までWindows + WSL2 + VSCodeでやってたのですが、Ubuntu上でやったほうが、なぜかコンパイル時間が1秒短かったのでUbuntuの環境に切り替えました。
1. 自分の中では思ったよりも早く到達
もう使用していないpypy3のアカウントでは、精進もあまりしてなかったので、緑から水色になるのは2年以上かかりましたが、水色から青色は1年4か月くらいでした。
ほぼ毎日新規4問ACをやり続けて1年以上経過。
青になったときの記録。
・AtCoder Problemsの結果
1/13に1問数え間違えて3問しかACになってなかったのが残念。
2. レート推移
2.1 レート1300から1400付近
ずっと精進を続けていて、過去問をだいぶ触っていたので、失敗することは少なくなりましたが、大きくレートが上がるようなパフォが取れてなかったです。そのため、このレート帯でかなりさまよい続けました。
結局、ABCDEの5完は安定していても、6完を取らないと青パフォ以上が出ないのでレートが安定しないですね。
2.2 レート1400から1600へ
直近、5月後半くらいから精進方法を変えました。
AtCoder ProblemsのRecommendationのEasyから3問解いて、Difficultから1問以上解くようにしました。Difficultは自力ACにするのは少し難しく、30分から1時間かけて解けなかったら解説みてACしてました。
これが知識量の拡張にもなり、コンテスト本番でも活きてきました。
あれ、これ前やった気がする、っていう感じで。手ごたえも結構あり、
失敗したなぁと思ってもパフォ1400出てたりと、実力が上がってきているのを感じました。本番中で青diff以上が解けるようになってきて、無事青レートに到達しました。
精進方法の変更は結構効果あったんじゃないかと思っています。
これからも、この方法で学習し、実力を伸ばそうかと思います。
3 コンテストに向けたコンディションの整え方
3.1 コンディションを整える目的
体のコンディションを整えることが重要なのは、コンテストのパフォーマンスを高くするというのもありますが
【コンディションを整えなかったために、「今日は体の調子が悪かったから、問題が解けなかった」という言い訳をして、
解けなかった問題から逃げる】ということをしないためですね。実力で解けなかったのに、体調のせいにして逃げるのを避けるために、言い訳をしないようにするために、万全な状態でコンテストに臨む。そして解けなかったら実力不足を認めて問題を解けるように理解する。これが重要かなと思っています。
3.2 コンディションの整え方
ここまでやる必要ないと思いますが、自分はコンテストがある日は以下のようなスケジュールで整えてます。
朝起きてから、16時までは精進。16時から18時くらいの間で1時間半睡眠。
19時頃から風呂に浸かって、頭から汗が出るまで温まる。20時30分頃エナドリ投入。
45分くらいからコンテストの準備(ソースコードを8問分用意)、トイレを済ませて自分のライブラリを確認。
21時からコンテスト着手。という流れです。
いろいろと模索した結果、この流れがパフォーマンスが安定したので、このやり方で一年くらいやり続けてます。
4 コードの下準備
過去問を解いていって、典型的なアルゴリズムはできるだけ、準備するようにしました。自分の考えは合っているのに、実装できずっていうパターンを出来るだけなくしたいので。ビルド時間長くなりますが、今大体8000行くらいのコードを提出してます。。。
2023/07/04時点でこのようなコードになっています。
https://atcoder.jp/contests/arc119/submissions/43232774
2023/07/15時点でこのようなコードになっています。(Maxflowのクラス間違ってました。Maxflow問題AC通しました。)
https://atcoder.jp/contests/practice2/submissions/43574330
過去問解いていくことで、自分のコードが色々と手が加えられていきますね。自分はpythonからC++へ移行したので、できるだけ書き方をpythonに近づけて実装できるようにしようと思ってました。
マクロなど準備したおかげで、自分の中では、pythonの実装速度と同等くらいまでC++で実装できるようになって
実行速度はC++のほうが段違いで速いので、pythonの上位互換になった感じになった。
pythonはホント短くコードかけるのがいいよね。あとビルドが無いので直ぐに動かせるのも強いと思う。
その点C++はデバッグするサイクルが遅い。そこはどうしようも無いかなぁ。
とりあえず、以下に自分が用意したものを簡単に記載。(不具合あったらごめんなさい)
4.1 入力マクロ
私は大体以下のマクロを使っています。この中でもGET, GETVLL、GETVVLL, GETVSTRくらいで事足りる感じです。
誰かのコードを参考にしたのですが、_overload6マクロによって、GET1, GET2, GET3, GET4, GET5, GET6のマクロを呼び分けることなくGETマクロだけで実装できるのがめちゃくちゃ便利です。
GET(X), GET(X, Y), GET(X, Y, Z)という感じで1入力、2入力、3入力受け取りができます。
#define _overload6(_1,_2,_3,_4,_5,_6,name,...) name
#define GET1(x) ll x = in_ll();
#define GET2(x, y) ll x, y; {vll _A_ = in_lls(); x = _A_[0]; y = _A_[1];}
#define GET3(x, y, z) ll x, y, z; {vll _A_ = in_lls(); x = _A_[0]; y = _A_[1]; z = _A_[2];}
#define GET4(x, y, z, a) ll x, y, z, a; {vll _A_ = in_lls(); x = _A_[0]; y = _A_[1]; z = _A_[2]; a = _A_[3];}
#define GET5(x, y, z, a, b) ll x, y, z, a, b; {vll _A_ = in_lls(); x = _A_[0]; y = _A_[1]; z = _A_[2]; a = _A_[3]; b = _A_[4];}
#define GET6(x, y, z, a, b, c) ll x, y, z, a, b, c; {vll _A_ = in_lls(); x = _A_[0]; y = _A_[1]; z = _A_[2]; a = _A_[3]; b = _A_[4]; c = _A_[5];}
#define GET(...) _overload6(__VA_ARGS__,GET6, GET5, GET4, GET3, GET2, GET1)(__VA_ARGS__)
#define GETVLL(x) vll x = in_lls();
#define GETVVLL(x, N) vvll x; rep(i, N) {GETVLL(ab); x.pb(ab);}
#define GET1D(x) ld x = in_d();
#define GET2D(x, y) ld x, y; {vd _A_ = in_ds(); x = _A_[0]; y = _A_[1];}
#define GET3D(x, y, z) ld x, y, z; {vd _A_ = in_ds(); x = _A_[0]; y = _A_[1]; z = _A_[2];}
#define GET4D(x, y, z, a) ld x, y, z, a; {vd _A_ = in_ds(); x = _A_[0]; y = _A_[1]; z = _A_[2]; a = _A_[3];}
#define GET5D(x, y, z, a, b) ld x, y, z, a, b; {vd _A_ = in_ds(); x = _A_[0]; y = _A_[1]; z = _A_[2]; a = _A_[3]; b = _A_[4];}
#define GET6D(x, y, z, a, b, c) ld x, y, z, a, b, c; {vd _A_ = in_ds(); x = _A_[0]; y = _A_[1]; z = _A_[2]; a = _A_[3]; b = _A_[4]; c = _A_[5];}
#define GETD(...) _overload6(__VA_ARGS__,GET6D, GET5D, GET4D, GET3D, GET2D, GET1D)(__VA_ARGS__)
#define GETVD(x) vd x = in_ds();
#define GETVVD(x, N) vvd x; rep(i, N) {GETVD(ab); x.pb(ab);}
#define GETSTR(x) string x = in_str();
#define GETSTRS(x) vs x; x = in_strs();
#define GETVVS(x, N) vvs x; rep(i, N) x.pb(in_strs());
#define GETVSTR(x, N) vs x; rep(i, N) x.pb(in_str());
#define GETPOINT(p) Point p; {GET2(x, y); p = Point{x, y};}
#define GETPOINTS(p, N) vector<Point> p; rep(i, N) {GET2(x, y); p.pb(Point{x, y});}
#define GETCOMPLEX(p) complex<ld> p; {GET2D(x, y); p = complex<ld>{x, y};}
#define GETCOMPLEXS(p, N) vector<complex<ld>> p; rep(i, N) {GET2D(x, y); p.pb(complex<ld>{x, y});}
4.2 出力マクロ、デバッグ
この方のdebugコードがめちゃくちゃ使いやすい。このコードを標準出力でも使うようにした。
https://blog.naskya.net/post/0002/
デバッグについては、自分の環境でビルドするときはLOCALのマクロを有効にしてビルドするだけで、
自分の環境ではデバッグコードが実行されて、内容が表示される。
提出するときもデバッグコード消さなくても、AtCoder側がLOCALマクロを有効にしていないので
debugマクロが;に置き換えられるので、デバッグコードが実行されない。なので提出するときに
デバッグコードを消す必要がないのがものすごく大きい。
#ifdef LOCAL
# define debug(...) cerr << "\033[33m(line:" << __LINE__ << ") " << endl; debug_print_func::multi_print(#__VA_ARGS__, __VA_ARGS__); cerr << "\033[m";
#else
# define debug(...) ;
#endif
4.3 多倍長整数
pythonでは標準で多倍長整数があるが、C++にはない。
そこでBoostを使って、対応しようと最初はしたけれど、あまりにも遅かった。
そのため、AtCoderの問題の範囲内ではオーバーフローがおこらない__int128を使っている。
ただ、これを使うと、今度は標準入力で受け取れないので、この記事に感謝しながら、対応している。
https://kenkoooo.hatenablog.com/entry/2016/11/30/163533
4.4 repマクロ
今は使っていないようなマクロもあるかもしれないけど、repマクロは使いやすい。
とくに_overload4のおかげで、
rep(i, N)はiが0からN未満までインクリメント
rep(i, a, N)はiがaからN未満までインクリメント
rep(i, a, N, s)はiがaからN未満までs分増やしてループ
という感じで書ける。超便利。デクリメント側はrrepマクロを用意してる。
/* REP macro */
#define _overload4(_1,_2,_3,_4,name,...) name
#define _rep(i,n) reps(i,0,n)
#define reps(i,a,n) for (ll i = (a); i < (ll)(n); ++i)
#define repsp(i,a,n,s) for (ll i = (a); i < (ll)(n); i += s)
#define rep(...) _overload4(__VA_ARGS__,repsp, reps,_rep,)(__VA_ARGS__)
あとは辞書や集合をfor文で回すときに使うコードかな。
#define repdict(key, value, dict) for (const auto& [key, value] : dict)
#define repset(x, st) for(auto x : st)
4.5 sort関連
ソートのマクロも用意している。
#define SORT(x) stable_sort(all(x))
#define RSORT(x) stable_sort(rall(x))
#define SORT_IDX(x, idx) stable_sort(all(x), [&](const vll &_a_, const vll &_b_){return _a_[idx] < _b_[idx];})
#define RSORT_IDX(x, idx) stable_sort(all(x), [&](const vll &_a_, const vll &_b_){return _a_[idx] > _b_[idx];})
4.6 multisetの要素削除
multisetはなぜかeraseを呼ぶと、multiset内に含まれている要素を全て削除してしまう。
それが嫌なので、以下のマクロを用意した。
#define ERASE(x, s) {auto itr_ = s.find((x)); if (itr_ != s.end()) s.erase(itr_); }
4.7 chmin, chmaxマクロ
DPを実装するときによく使うマクロ。結構使いやすい。
// 第一引数と第二引数を比較し、第一引数(a)をより大きい/小さい値に上書き
template <typename T> inline bool chmin(T& a, const T& b) {bool compare = a > b; if (a > b) a = b; return compare;}
template <typename T> inline bool chmax(T& a, const T& b) {bool compare = a < b; if (a < b) a = b; return compare;}
4.8 yesno関数
難しいことはしてないが、使いやすい。
inline string YESNO(bool cond) {return cond ? "YES" : "NO";}
inline string yesno(bool cond) {return cond ? "yes" : "no";}
inline string YesNo(bool cond) {return cond ? "Yes" : "No";}
4.9 型変換
数字を文字にしたり、文字列を数字に変換したりする関数。
// 型変換
#define CHARSTR(x) (""s + x)
#define STRBIN2LL(x) ((ll)std::stoull(x, nullptr, 2))
#define STRLL(x) ((ll)parse(x))
#define STRD(x) std::stod(x)
#define CHARLL(x) ((ll)std::stoll(CHARSTR(x)))
4.10 unordered_mapのキーに対して対応する型を増やす。
おそらく、unordered_mapでpair, vector, tupleをkeyにするとコンパイルエラーがでるはず。
そこで以下の記事を参考にして、unordered_mapにpair等の型をキーにしてもコンパイルエラーが出なくなる。
https://qiita.com/hamamu/items/4d081751b69aa3bb3557
4.11 AtCoderのライブラリの導入
AtCoderのライブラリをincludeすると、結構ビルドに時間がかかる。
プリコンパイル済みヘッダーとかやってみたけど、自分は効果が無かった感じ。(設定ミスしてそう)
どうもincludeするファイルが多いとそれだけビルドに時間がかかるような感じだったので
1ファイルに全て書くようにしてビルド時間を短縮した。
AtCoderのライブラリを提出コードにそのままコピーまたは自分のコードとマッチするように
書き換えて、問題を対応している。
4.12 組み合わせ列挙
C++で地味にきついのが、combination。pythonはライブラリ使えば簡単に取得できるんだけど
C++はcombinationが無いと思う。順列はあるけど。
で高速にcombinationを列挙できるコードを色々と探してたら、このURLのコードが最速だったので
今はこれを使ってる。このコードが最速じゃないかなぁ。
https://howardhinnant.github.io/combinations.html
で自分はvvll get_comb_ptn(ll N, ll R)を用意して、組み合わせ全列挙するとき、この関数を使ってる。
4.13 実装するコードを一番上にもってくる
ソースコードのフォーマットを以下のようにして、問題を解くコードを一番上に持ってきている。
このようにしてもビルド時間はあまり変わらなかったので、見やすさ重視で一番上に問題を解くコードを持ってきてる。
#ifdef INCLUDED_MAIN
auto solve() {
return _0;
}
int main() {
auto ans = solve();
print(ans);
}
#else
#define INCLUDED_MAIN
// 自作ライブラリ群
#include __FILE__
#endif
4.14 その他ライブラリ
グラフ理論や、整数問題、幾何問題、文字列処理、しゃくとりや、2次元imos、BITやseg木などのデータ構造など
水色以下で使用するものはある程度揃えてると思う。少し前に、頂点倍化二部グラフ判定や、Mo's Algorithmとか実装した。Mo's Algorithmは区間のたどり方で実行速度が大きく異なって、色々と調べたらHilbert Orderが速いらしい。
https://take44444.github.io/Algorithm-Book/range/mo/main.html
自分は実装速度が遅いので、それをカバーするためにライブラリを多く用意してるかな。
先人の方のコードを拝借して、自分の環境で動作するように少し修正して取り入れているので
先人の方々に感謝です。
4.15 ビルドオプション
これも他の人に教えてもらったんだけど、ビルドオプションマジで重要。
warningとかで不具合を先に潰せる。いいなと思うものを列挙。
4.15.1 -fsanitize=address
ここに書いてくれているけど、これがホントに優秀で、ビルド時間が多少伸びても、このオプションはつけたほうがいいと思う。範囲外アクセスしたコードの行数を特定してくれるので、すぐにどこに問題があるか分かる。
このオプション優秀すぎる。このオプションと-gをつける必要があるかも。
4.15.2 -Wshadow
手癖で大体rep(i, N) {}ってやってしまうんだけど、2重、3重ループのコードを書くと
ループ変数がかぶったりする。そのときにすぐに警告出してくれて、どこでshadowingしてるか分かるようになる。
これで実行して不具合調査する前に、ビルドするだけで実装ミスを見つけることができる。
4.15.3 最適化はオフ
自分のコードが多いためビルドだけでも数秒かかるんだけど、最適化するともっと時間かかる。
なので、最適化はオフにしてビルドを実行して、ビルド時間の短縮をしている。
実行時間は、だいたいサンプルを通すくらいなら、あまり時間かからないので、
不具合調査、修正のサイクルを早くするために最適化はオフにしている。
あと余りに速すぎると、自分の環境では2秒以内に答えが返ってくるのに、
提出したらTLEみたいな問題も起こるので、あまり最適化はしないかな。
4.15.4 -ftime-report
これはコンテスト中につけないオプション。ビルド時間を調査するために使用する。
どこに時間かかっているのかを確認して、対策を打つ。
今の自分のテンプレートのコードをビルドすると、こんな感じで時間かかってる。
コードを短くすればビルド時間を短縮できるんだけどなぁ。
Time variable usr sys wall GGC
phase setup : 0.00 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 1684 kB ( 0%)
phase parsing : 1.59 ( 30%) 0.64 ( 62%) 2.23 ( 35%) 325358 kB ( 41%)
phase lang. deferred : 0.75 ( 14%) 0.12 ( 12%) 0.88 ( 14%) 142234 kB ( 18%)
phase opt and generate : 2.89 ( 55%) 0.27 ( 26%) 3.15 ( 50%) 327341 kB ( 41%)
phase last asm : 0.07 ( 1%) 0.01 ( 1%) 0.08 ( 1%) 5549 kB ( 1%)
phase finalize : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%)
|name lookup : 0.44 ( 8%) 0.12 ( 12%) 0.55 ( 9%) 14913 kB ( 2%)
|overload resolution : 0.60 ( 11%) 0.16 ( 15%) 0.69 ( 11%) 116344 kB ( 15%)
garbage collection : 0.29 ( 5%) 0.00 ( 0%) 0.29 ( 5%) 0 kB ( 0%)
dump files : 0.09 ( 2%) 0.00 ( 0%) 0.06 ( 1%) 0 kB ( 0%)
callgraph construction : 0.17 ( 3%) 0.03 ( 3%) 0.20 ( 3%) 39815 kB ( 5%)
callgraph optimization : 0.04 ( 1%) 0.01 ( 1%) 0.01 ( 0%) 0 kB ( 0%)
ipa dead code removal : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%)
ipa inlining heuristics : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%)
ipa HSA : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%)
ipa free inline summary : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%)
cfg construction : 0.00 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 1154 kB ( 0%)
cfg cleanup : 0.05 ( 1%) 0.00 ( 0%) 0.01 ( 0%) 42 kB ( 0%)
trivially dead code : 0.06 ( 1%) 0.00 ( 0%) 0.08 ( 1%) 0 kB ( 0%)
df scan insns : 0.16 ( 3%) 0.00 ( 0%) 0.11 ( 2%) 182 kB ( 0%)
df live regs : 0.04 ( 1%) 0.01 ( 1%) 0.03 ( 0%) 0 kB ( 0%)
df reg dead/unused notes : 0.02 ( 0%) 0.01 ( 1%) 0.03 ( 0%) 4891 kB ( 1%)
register information : 0.02 ( 0%) 0.00 ( 0%) 0.05 ( 1%) 0 kB ( 0%)
alias analysis : 0.00 ( 0%) 0.00 ( 0%) 0.04 ( 1%) 1502 kB ( 0%)
rebuild jump labels : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%)
preprocessing : 0.11 ( 2%) 0.09 ( 9%) 0.23 ( 4%) 7936 kB ( 1%)
parser (global) : 0.22 ( 4%) 0.20 ( 19%) 0.46 ( 7%) 69540 kB ( 9%)
parser struct body : 0.17 ( 3%) 0.06 ( 6%) 0.27 ( 4%) 38669 kB ( 5%)
parser enumerator list : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 233 kB ( 0%)
parser function body : 0.14 ( 3%) 0.05 ( 5%) 0.23 ( 4%) 14668 kB ( 2%)
parser inl. func. body : 0.14 ( 3%) 0.02 ( 2%) 0.08 ( 1%) 8703 kB ( 1%)
parser inl. meth. body : 0.19 ( 4%) 0.04 ( 4%) 0.22 ( 3%) 32889 kB ( 4%)
template instantiation : 1.20 ( 23%) 0.27 ( 26%) 1.32 ( 21%) 232853 kB ( 29%)
constant expression evaluation : 0.01 ( 0%) 0.00 ( 0%) 0.04 ( 1%) 521 kB ( 0%)
early inlining heuristics : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%)
inline parameters : 0.00 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 3640 kB ( 0%)
integration : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 2 kB ( 0%)
tree gimplify : 0.05 ( 1%) 0.01 ( 1%) 0.04 ( 1%) 16771 kB ( 2%)
tree eh : 0.02 ( 0%) 0.00 ( 0%) 0.04 ( 1%) 3100 kB ( 0%)
tree CFG construction : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 6683 kB ( 1%)
tree CFG cleanup : 0.02 ( 0%) 0.01 ( 1%) 0.03 ( 0%) 15 kB ( 0%)
tree PHI insertion : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 963 kB ( 0%)
tree SSA rewrite : 0.00 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 4117 kB ( 1%)
tree SSA other : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 548 kB ( 0%)
tree SSA incremental : 0.02 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 4 kB ( 0%)
tree operand scan : 0.02 ( 0%) 0.02 ( 2%) 0.03 ( 0%) 13611 kB ( 2%)
tree switch lowering : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 66 kB ( 0%)
dominance computation : 0.04 ( 1%) 0.00 ( 0%) 0.04 ( 1%) 0 kB ( 0%)
out of ssa : 0.02 ( 0%) 0.01 ( 1%) 0.03 ( 0%) 429 kB ( 0%)
expand vars : 0.04 ( 1%) 0.00 ( 0%) 0.05 ( 1%) 12258 kB ( 2%)
expand : 0.24 ( 5%) 0.05 ( 5%) 0.15 ( 2%) 40631 kB ( 5%)
post expand cleanups : 0.02 ( 0%) 0.01 ( 1%) 0.06 ( 1%) 6909 kB ( 1%)
varconst : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 16 kB ( 0%)
jump : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%)
loop init : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 3207 kB ( 0%)
integrated RA : 0.45 ( 8%) 0.03 ( 3%) 0.47 ( 7%) 107415 kB ( 13%)
LRA non-specific : 0.19 ( 4%) 0.01 ( 1%) 0.29 ( 5%) 3249 kB ( 0%)
LRA virtuals elimination : 0.03 ( 1%) 0.00 ( 0%) 0.04 ( 1%) 2455 kB ( 0%)
LRA reload inheritance : 0.00 ( 0%) 0.01 ( 1%) 0.01 ( 0%) 59 kB ( 0%)
LRA create live ranges : 0.09 ( 2%) 0.02 ( 2%) 0.10 ( 2%) 646 kB ( 0%)
LRA hard reg assignment : 0.04 ( 1%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%)
reload : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%)
thread pro- & epilogue : 0.06 ( 1%) 0.00 ( 0%) 0.10 ( 2%) 7780 kB ( 1%)
machine dep reorg : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 438 kB ( 0%)
shorten branches : 0.05 ( 1%) 0.00 ( 0%) 0.09 ( 1%) 0 kB ( 0%)
reg stack : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 169 kB ( 0%)
final : 0.23 ( 4%) 0.02 ( 2%) 0.29 ( 5%) 13390 kB ( 2%)
symout : 0.16 ( 3%) 0.04 ( 4%) 0.22 ( 3%) 69758 kB ( 9%)
initialize rtl : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 12 kB ( 0%)
rest of compilation : 0.26 ( 5%) 0.01 ( 1%) 0.29 ( 5%) 27453 kB ( 3%)
unaccounted post reload : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%)
repair loop structures : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%)
TOTAL : 5.30 1.04 6.35 802179 kB
ビルドオプションはこれくらいかな。
5 今後の目標
とりあえず、青パフォを安定させる(おそらくF問題を安定してACしないといけない)
1800レートくらいを安定して推移したら黄色レートを目指したい。
まずは青レート安定かな。
緑レートから青レートまで精進して伸ばしてきたけど、
3完安定 → 早解き3完 → ギリ4完 → 4完安定 → 早解き4完 → ギリ5完 → 5完安定 → 早解き5完 → ギリ6完
っていう感じで成長してる気がする。
問題のセットや難易度によって多少ブレがあるけど、
ギリ4完あたりが緑レート、ギリ5完あたりが水レート、ギリ6完あたりが青レートって感じかなぁ。
早解きができるようになったら、次の段階(難しい問題を解説見てもいいから解いて知識量を増やす)になってる気がする。
このまま精進を継続して、精進方法を確立したい。
何か思いついたら追記するかも。