スピードコーディングがショートコーディング！？

今年の１月頃にやっていた、SPOJのPRICですが……
　
SPOJ - PRIC
http://www.spoj.pl/ranks/PRIC/
　
はい、まだやっていました。
　
スコアがなかなか９ケタの大台に乗りません。
あと0.02秒なんですが、この微妙な差が縮まりません。
削れる部分は、すべて削ったつもりです。
上位２人は明らかに根本的にアルゴリズムが違うはずです。
というか、４位の人も、私より圧倒的に優れたアルゴリズムを使っているに違いない！！
５位の人は辛うじて私と同じアルゴリズムな気がする。
　
16秒台だった頃から、何一つ基本アルゴリズムを変えずに、8.35秒まで削った私です。
（あれから導入したのは、モンゴメリ、逆数べき剰余ぐらいかな。逆数べき剰余は僕の造語だけど）
　
（16秒台の頃の基本アルゴリズムは、26418法→試し割→Solovay-Strassenテスト）
　
さて、ここまで削って、残り0.02秒が削れなくて、とうとう最後の手段を思いついてしまいました。
それは、２分岐５回→３２分岐１回に変換しようという案で、アセンブリコードが一気に膨れ上がります。
膨れ上がる割に、高速化の恩恵はそんなに大きくなさそうなのですが……あるいは逆に遅くなる可能性さえありますが、0.02秒さえ削れれば良いという考えに至りました。
それを削って、塗り残したタイルに終止符を打とう、と。
　
現在、試作コードのアセンブリ部分が2400バイト程度、パッチ部分が1400バイト程度、残りのC++部分が1500バイト程度、ですっけ。
合わせて5300バイトですか？　で、送信可能なバイト数が4096バイト。
　
……あれ、いつからショートコーディングになったんですか？（笑）