ErgoBo(dotnet の開発チームの主要メンバー)が実測したら閏年じゃないならyear%4!=0で終わるから速いとリプライしていた。非閏年が来るのは75%強だとするとこちらを遅くするのは期待値としてどうなのかという視点も要りそう。
z3でマジックナンバー探させるの現代の黒魔術感あって面白いな。人間が理解できない最適化コードが標準ライブラリに増えていく未来
さすがにこれだけ単純だとテーブルルックアップより速いかな
だが68000ならどうかな? (詭弁のガイドラインにもあるごく稀な反例) → 従来アルゴリズムでは%25が遅いが25=5*5であることを利用してDIV命令を使わない最適化ができて72～170clock 。今回のものは32bit乗算が遅くて228clock固定
うるう年判定界隈に革命が起こる🤔
高速なう（帰省の道中）
MC6800だと乗算が遅いので…
あとからみるとこういう謎技術にしかみえない高速化の話って好き。
102500年問題
“すべての入力に対して正確な結果を返す、というのを諦めて範囲を狭めることで、うるう年判定をより高速化できるのではないか……実際、PythonやC#では西暦9999年までしかサポートされていない”
↓早期リターンについては記事にあるけど、あとで追記されたのかな？
3命令のCPU処理で済む高速なうるう年判定アルゴリズム - Faith and Brave - C++で遊ぼう
ErgoBo(dotnet の開発チームの主要メンバー)が実測したら閏年じゃないならyear%4!=0で終わるから速いとリプライしていた。非閏年が来るのは75%強だとするとこちらを遅くするのは期待値としてどうなのかという視点も要りそう。
z3でマジックナンバー探させるの現代の黒魔術感あって面白いな。人間が理解できない最適化コードが標準ライブラリに増えていく未来
さすがにこれだけ単純だとテーブルルックアップより速いかな
だが68000ならどうかな? (詭弁のガイドラインにもあるごく稀な反例) → 従来アルゴリズムでは%25が遅いが25=5*5であることを利用してDIV命令を使わない最適化ができて72～170clock 。今回のものは32bit乗算が遅くて228clock固定
うるう年判定界隈に革命が起こる🤔
高速なう（帰省の道中）
MC6800だと乗算が遅いので…
あとからみるとこういう謎技術にしかみえない高速化の話って好き。
102500年問題
“すべての入力に対して正確な結果を返す、というのを諦めて範囲を狭めることで、うるう年判定をより高速化できるのではないか……実際、PythonやC#では西暦9999年までしかサポートされていない”
↓早期リターンについては記事にあるけど、あとで追記されたのかな？