><https://twitter.com/orange_in_spacehttps://pawoo.net/@orange_in_space
ていうか、0だったら0のままで0以外だったら全bit立てるって命令があったらいろいろ高速化に便利だと思うんだけど、そういうのある環境って無いのかな?><;
こういうレアケース(?)に限って言うと、回路が十分に高速であれば、現代のPC向けCPUでもコネクションマシンのアーキテクチャのコプロセッサ(というかなんと言うか)をくっつけて高速化に利用できるのかも?><;(柔軟なロジック回路をプログラミングで作れるような環境(超頻繁に書き換えまくれる版超小規模PLDのような感じ)だし><)・・・そんなことするよりもクロックちょっとあげる方が手っ取り早いわかる><;
これのほかにifを全く使わない条件分岐無しバージョンも書いたけどむしろ大幅に遅くなった><;書いてて「これがデジタル回路だったら、小さい規模の回路で一瞬で結果が出るのに!><;」って思った><;
二分探索版を無駄な計算無くして並列実行されやすい気がするように(?)リファクタリングしたら、最適化コンパイルしても線形探索版とどっこいどっこい(測るたびに勝ったり負けたりする程度)まで速くなった><
二分探索のコード、if使ってる部分がどう考えてネックになりそうだから、そこを論理演算使うように書き換えたらまた追い越せるのかな?><;
命名が微妙におかしいのは実験コードだからで許してほしい><;
線形探索版のリファクタリング前後のコードはこんな感じ><
ていうか最適化コンパイルでは↑速いwhile使ってきれいに書いた線形探索二分探索forを使った無駄がある線形探索↓遅いなので、最適化で追い越したのはきれいに書いた版だけってことかも><
ちなみに、無駄にforで処理してたのをwhile使うようにきれいに書き換えたのは、最適化コンパイルをしてもちゃんと高速化されてる><(そういう無駄な書き方してる部分のリファクタリングはちゃんとやった方がいいよだよね><)
ちゃんとオチがついた><;
"早すぎる最適化は諸悪の根源である。" ドナルド・クヌース
(オレンジ意訳「変に手動でコードを最適化すると、未来のCPUやコンパイラの最適化を邪魔して逆に遅くなったりするよ!」)・・・・これそのまんまじゃん><
!!!!!><最適化コンパイルすると線形探索の方が速くなる!!!!!!!><;
線形探索版の方を無駄を減らしてwhile使うようにリファクタリングしたら、処理時間5パーセント~10パーセント程度削減できたけど、それでも二分探索版よりも遅い><
線形探索版、while使うようにして無駄を減らしたら速くなる・・・?><;
実験に使ったコード><下の方が8割の時間で処理が終わるって、ほんと不思議><;「がんばっても無駄でした!><;」ってオチになると思って書いたのに><;
https://mstdn.nere9.help/@orange_in_space/110088685897843278こんななんかむしろ処理が増えてそうなコードでも、百万回試行で処理時間見比べるのを何度も繰り返してみたら、だいたい8割くらいの時間で終わるっぽい><不思議><
実験したらこれ速い!!!!><;どうして!?><;
二分探索(?)版書けた><;
0b00010001、左シフトして0b00100010..みたいなマスクを使って結果を右シフトしてorしてって4回やって1bitにまとめれば二分探索できる?><;どう考えても処理増えそう><;
4bitに区切った各桁を全部で4回andしてどうにかするような手で高速化されるのかな?><;
思考の /dev/null