ISUCON7本戦で惜敗してきた

ISUCON7予選、ISUCON5本戦、ISUCON4本戦をやろうとしたのですが、結局ISUCON5本戦はうまく動かずでした。コードを見ると、もうaptで配布されていないgradle2.8をバージョン指定で入れていたので、2.8の部分を削ってビルドが通るようにしたり、PHPのいくつかのライブラリのがおかしかったので直したりしてみたのですが、ちゃんと動いているかよくわからない状態でした。二年も前のアプリケーションだとよくあることかもしれませんが、ISUCONは動かすところからだ！と言われると・・・って感じなので、なんとかしたさがあります。だけど今の環境でも動くようにするということは、スコアに影響があったり、二年前より楽になるor辛くなることがあるので、本番と全く同じ状態ではなくなってしまうところが、難しいところですね・・・。割り切りが必要そうです。

ISUCON7予選とISUCON4本戦は楽しんでやれました。もう三年も前のISUCON4本戦が普通に動いたことは、本当にすごいことだと思います。

やったこと

今回はあまり仕事できなかった感じですね。

チームではいつものごとくDB担当でしたけど、テーブルは綺麗なもんで、いじるところとか特になかったです。slow queryになるまで行けなかったです。

強いて言えばトランザクションのところが遅いと言えば遅かったですけど、かなり触りづらい感じになっていた上、AppのCPU使用率が高すぎて、ボトルネックになっていました。

不変値であると判明したm_itemをinitialize時にメモリに読み込む処理をサクッと書いたあとは調査、遅いところを直していこうって感じでした。

書いている間にふぉのさんは使うかもしれないRedis入れたりとかの環境の整備、あーちゃんはデプロイの自動化とかやってました。

golangでやってたので、pprofで調査したところ、多倍長演算がとんでもなく時間食っていることが判明しました。

この時の話し合いで、僕は多倍長演算をなんとかする、あーちゃんは構成を分散させてroom名で使うマシンを切り替える、ふぉのさんはそのサポートって感じで仕事を分けました。

結論から言うと、多倍長演算を最後までなんとかできなくて、あまり点数を伸ばすことができませんでした。

addingの方はかけ算をサボることができて、まず左から60bitくらいを残すように右にシフトさせたあとかけ算して、右にシフトさせた分を左にシフトし直すことで、誤差範囲内でかなりの計算量を減らすことができたのですが、Priceの方はこれやっちゃダメで、どう頑張っても誤差範囲内に収めることができませんでした。書いてる時はわからなかったのですが、これは当たり前で、買えるかどうかの判定を厳密な値を用いて判定しているからでした。大して多くもないパターン数だったので、計算結果をキャッシュすればよかったっぽいんですけど、引数が64bit変数だったんでキャッシュは無理って判断してました。少し競技プログラミングを齧ってる身としては、今から思えばなんで無理って思い込んだんだろうってなってます。

あーちゃんの方の分散はある程度うまくいき、ジャッジケースセットによっては一つのマシンに偏ったり、うまく分散したりと、微妙な挙動をしてました。

結局やれたのはここまでで、あとはガチャ回していい結果を引こうとしたのですが、うまくひけず、最高点の17000点くらいまでできずに12000点くらいでフィニッシュしました。競技終了後に運営側で一回回して、その点数と競技時間内最後に提出された点数の高い方が取られるので、ちょっといいガチャが引けたっぽくて15000点くらいの結果になりました。

再起動試験は2回くらいしかやってなかったので、少し不安だったのですが、ちゃんとFailせずに終わりました。