堕天使の煉獄
2016-02
08
06:39:58
いつまでたっても
なんか、なんでこんな基本的な部分が整備されてないんだろう。というのはずっと思ってたんですけど。
実のところ、誰もコレが正解という答えを持っていないのか。それとも当たり前すぎて誰も言及しないのか。どっちなのか悩む案件。
なにげにconstexpr化できるものはみんなconstexpr付けちゃおうと直してたんですけど、算術系の標準関数とか混じってる関数なんかでconstexprが阻害されちゃうケースがおおくて。
この辺のcの標準関数てconstexprついてないんですよね。とうぜんっちゃ当然だけど。
で、その代替はというと、まだないっぽいんですよね。
constexpr利用で有名なSproutなんかにはconstexprでつかえる算術系の関数群も用意されてたりするんですが(逆に言えば、用意しないと使えないってことですよね……)
とはいえVC++ではSproutは使い物にならない(constexprの実装がまだまだ足りてないので)ので無い物ねだりですけど(最近そればっか。conceptとかoptionalとか……)
んで、とりあえず困ったのが、実数→整数に変換するときの丸め込みで、少数以下を四捨五入する処理。
以前はSSE2命令を使った方法で、これが一番速いらしい。ってことでつかってたのですが。
constexpr関数の中で呼び出すと怒られる。
もっともコンパイル時に計算するのだから、実装がどんなタコでも速度はかんけいなくなるんですけどね。コンパイル時に処理されるなら。
んでもコンパイル時処理と非constexpr処理を分けるのってどうやるのだろう。
実行時処理ならSSE2命令つかって、コンパイル時なら適当に~ってのを分ける方法とかないのかなこれ。通常はconstexpr指定して、実行時なら実行時処理で、コンパイル時ならコンパイル時処理、と同じ関数で勝手にやってくれるんですが。
コンパイル時と実行時で処理方法分けたいんだけどなぁコレ。ググっても出てこない。
普通にconstexpr付とそうじゃないの二つかいとけばいいのだろうか??
したら普通にエラー。うーん。なにか方法あるのかな。
それともこういうのは、そもそもコンパイル時用とで関数名で分けて使うものなのかな。
constexpr関数は引数も定数式でないと意味ないわけだから、一緒の関数名で横着しようというのがイカンのだろうかw
それ以前に、そもそもSSE2命令つかったのが最速ってのほんと? という疑問がわいてくる。
c標準の算術系は遅いって言うけどどのくらい?
std::nearbyintてのあるけどこれどうなの?
そこで、その辺ちょっとすっきりさせるために時間計測をやってみるテスト。
1000000回 float→int変換で
試したのは以下の5種
std::nearbyint
SSE2 _mm_cvtss_si32
std::ceil(切り上げ
std::floor(切り下げ
0.5足してキャスト static_cast<int>(f + 0.5f);
debug
nearbyint = 622 msec
SSE2 = 508 msec
ceil = 569 msec
floor = 566 msec
0.5足す = 480 msec
release
nearbyint = 190 msec
SSE2 = 83 msec
ceil = 130 msec
floor = 85 msec
0.5足す = 85 msec
うむう……
なんか普通に0.5足してキャストするだけのが優秀じゃないか。
ceil、floorは関数呼び出しのコストが余計に掛かってるだけのきもするぽ。
それでもceilは微妙に遅い感じっぽい。
何度か試してみても、確かに微妙にSSE2のが速くなってる気もするけど1000000回やって
数msecの差じゃ、誤差レベルですね……
そして後発の筈のstd::nearbyintが使い物にならんのでわ? という。
なにかコレを使うメリットとかあるのだろうか……??
ついでにdouble→intでもテスト
debug
nearbyint = 640 msec
SSE2 = 537 msec
ceil = 538 msec
floor = 534 msec
0.5足す = 508 msec
release
nearbyint = 187 msec
SSE2 = 94 msec
ceil = 138 msec
floor = 94 msec
0.5足す = 94 msec
ふむう。
大昔はfloatは遅い。doubleを使うべし。なんて時代もあったけど、最近ではやっぱfloatのがふつうに速いですね。(まあ実行環境によるんだろうけど)
ていうか、結果的には、小数部丸めは0.5足す方式一本でおkなかんじっぽい。
一応、画像のピクセル処理とか実行時限定で、特にパフォーマンスを気にするようなところ用にSSE使った別のroundSSE関数なんてのを用意しておく……てのがいいのかも。
切り上げなんかは0.999とか足してキャストとか泥臭いのでいいかもw
んー
この辺、実行速度とか信頼できる実験結果の裏打ちとかあるかんじで、こういう基本的な処理まとめたサイトとかないものかね。
いちいち自分で調べるのは車輪の再発明じゃないけど、そんな感じで無駄が多いでつ。
そして、今回もそうだったけど、後発のが高パフォーマンスだとは限らないってのも面倒なんですよね。安全性とか例外の有無だとか、いろいろな要素が絡むので、絶対的にコレ使っとけってのは難しいんでしょうけど。
うーん。
そんなかんじで遅々として作業が進まない。
実のところ、誰もコレが正解という答えを持っていないのか。それとも当たり前すぎて誰も言及しないのか。どっちなのか悩む案件。
なにげにconstexpr化できるものはみんなconstexpr付けちゃおうと直してたんですけど、算術系の標準関数とか混じってる関数なんかでconstexprが阻害されちゃうケースがおおくて。
この辺のcの標準関数てconstexprついてないんですよね。とうぜんっちゃ当然だけど。
で、その代替はというと、まだないっぽいんですよね。
constexpr利用で有名なSproutなんかにはconstexprでつかえる算術系の関数群も用意されてたりするんですが(逆に言えば、用意しないと使えないってことですよね……)
とはいえVC++ではSproutは使い物にならない(constexprの実装がまだまだ足りてないので)ので無い物ねだりですけど(最近そればっか。conceptとかoptionalとか……)
んで、とりあえず困ったのが、実数→整数に変換するときの丸め込みで、少数以下を四捨五入する処理。
以前はSSE2命令を使った方法で、これが一番速いらしい。ってことでつかってたのですが。
constexpr関数の中で呼び出すと怒られる。
もっともコンパイル時に計算するのだから、実装がどんなタコでも速度はかんけいなくなるんですけどね。コンパイル時に処理されるなら。
んでもコンパイル時処理と非constexpr処理を分けるのってどうやるのだろう。
実行時処理ならSSE2命令つかって、コンパイル時なら適当に~ってのを分ける方法とかないのかなこれ。通常はconstexpr指定して、実行時なら実行時処理で、コンパイル時ならコンパイル時処理、と同じ関数で勝手にやってくれるんですが。
コンパイル時と実行時で処理方法分けたいんだけどなぁコレ。ググっても出てこない。
普通にconstexpr付とそうじゃないの二つかいとけばいいのだろうか??
したら普通にエラー。うーん。なにか方法あるのかな。
それともこういうのは、そもそもコンパイル時用とで関数名で分けて使うものなのかな。
constexpr関数は引数も定数式でないと意味ないわけだから、一緒の関数名で横着しようというのがイカンのだろうかw
それ以前に、そもそもSSE2命令つかったのが最速ってのほんと? という疑問がわいてくる。
c標準の算術系は遅いって言うけどどのくらい?
std::nearbyintてのあるけどこれどうなの?
そこで、その辺ちょっとすっきりさせるために時間計測をやってみるテスト。
1000000回 float→int変換で
試したのは以下の5種
std::nearbyint
SSE2 _mm_cvtss_si32
std::ceil(切り上げ
std::floor(切り下げ
0.5足してキャスト static_cast<int>(f + 0.5f);
debug
nearbyint = 622 msec
SSE2 = 508 msec
ceil = 569 msec
floor = 566 msec
0.5足す = 480 msec
release
nearbyint = 190 msec
SSE2 = 83 msec
ceil = 130 msec
floor = 85 msec
0.5足す = 85 msec
うむう……
なんか普通に0.5足してキャストするだけのが優秀じゃないか。
ceil、floorは関数呼び出しのコストが余計に掛かってるだけのきもするぽ。
それでもceilは微妙に遅い感じっぽい。
何度か試してみても、確かに微妙にSSE2のが速くなってる気もするけど1000000回やって
数msecの差じゃ、誤差レベルですね……
そして後発の筈のstd::nearbyintが使い物にならんのでわ? という。
なにかコレを使うメリットとかあるのだろうか……??
ついでにdouble→intでもテスト
debug
nearbyint = 640 msec
SSE2 = 537 msec
ceil = 538 msec
floor = 534 msec
0.5足す = 508 msec
release
nearbyint = 187 msec
SSE2 = 94 msec
ceil = 138 msec
floor = 94 msec
0.5足す = 94 msec
ふむう。
大昔はfloatは遅い。doubleを使うべし。なんて時代もあったけど、最近ではやっぱfloatのがふつうに速いですね。(まあ実行環境によるんだろうけど)
ていうか、結果的には、小数部丸めは0.5足す方式一本でおkなかんじっぽい。
一応、画像のピクセル処理とか実行時限定で、特にパフォーマンスを気にするようなところ用にSSE使った別のroundSSE関数なんてのを用意しておく……てのがいいのかも。
切り上げなんかは0.999とか足してキャストとか泥臭いのでいいかもw
んー
この辺、実行速度とか信頼できる実験結果の裏打ちとかあるかんじで、こういう基本的な処理まとめたサイトとかないものかね。
いちいち自分で調べるのは車輪の再発明じゃないけど、そんな感じで無駄が多いでつ。
そして、今回もそうだったけど、後発のが高パフォーマンスだとは限らないってのも面倒なんですよね。安全性とか例外の有無だとか、いろいろな要素が絡むので、絶対的にコレ使っとけってのは難しいんでしょうけど。
うーん。
そんなかんじで遅々として作業が進まない。
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
02
03
04
05
06
■
■
三歩ぐらいさがる?
07
08
■
■
いつまでたっても
09
10
11
[建国記念の日]
12
13
14
15
16
17
18
19
■
■
ちょっぴり風邪気味
20
21
■
■
最近なんかタイトルつけるのがタルイw
22
23
24
25
■
■
ぶつり。
26
27
28
29
total:2076516 t:28 y:396
■記事タイトル■
■年度別リスト■
2024年
2024年12月(0)2024年11月(0)
2024年10月(1)
2024年09月(2)
2024年08月(1)
2024年07月(1)
2024年06月(5)
2024年05月(2)
2024年04月(1)
2024年03月(6)
2024年02月(4)
2024年01月(3)
2023年
2023年12月(3)2023年11月(1)
2023年10月(2)
2023年09月(3)
2023年08月(3)
2023年07月(3)
2023年06月(7)
2023年05月(8)
2023年04月(2)
2023年03月(1)
2023年02月(2)
2023年01月(3)
2022年
2022年12月(4)2022年11月(3)
2022年10月(1)
2022年09月(3)
2022年08月(3)
2022年07月(2)
2022年06月(1)
2022年05月(3)
2022年04月(2)
2022年03月(2)
2022年02月(1)
2022年01月(6)
2021年
2021年12月(8)2021年11月(3)
2021年10月(4)
2021年09月(6)
2021年08月(2)
2021年07月(1)
2021年06月(3)
2021年05月(2)
2021年04月(2)
2021年03月(3)
2021年02月(1)
2021年01月(4)
2020年
2020年12月(3)2020年11月(7)
2020年10月(2)
2020年09月(3)
2020年08月(1)
2020年07月(3)
2020年06月(7)
2020年05月(5)
2020年04月(8)
2020年03月(4)
2020年02月(2)
2020年01月(4)
2019年
2019年12月(1)2019年11月(1)
2019年10月(2)
2019年09月(1)
2019年08月(3)
2019年07月(2)
2019年06月(2)
2019年05月(2)
2019年04月(4)
2019年03月(1)
2019年02月(7)
2019年01月(1)
2018年
2018年12月(1)2018年11月(1)
2018年10月(5)
2018年09月(1)
2018年08月(5)
2018年07月(1)
2018年06月(1)
2018年05月(1)
2018年04月(2)
2018年03月(2)
2018年02月(1)
2018年01月(1)
2017年
2017年12月(2)2017年11月(1)
2017年10月(2)
2017年09月(5)
2017年08月(8)
2017年07月(2)
2017年06月(1)
2017年05月(1)
2017年04月(3)
2017年03月(5)
2017年02月(7)
2017年01月(8)
2016年
2016年12月(7)2016年11月(2)
2016年10月(3)
2016年09月(7)
2016年08月(8)
2016年07月(10)
2016年06月(17)
2016年05月(6)
2016年04月(8)
2016年03月(10)
2016年02月(5)
2016年01月(10)
2015年
2015年12月(7)2015年11月(7)
2015年10月(13)
2015年09月(7)
2015年08月(7)
2015年07月(5)
2015年06月(4)
2015年05月(5)
2015年04月(2)
2015年03月(4)
2015年02月(1)
2015年01月(7)
2014年
2014年12月(12)2014年11月(8)
2014年10月(4)
2014年09月(6)
2014年08月(7)
2014年07月(4)
2014年06月(2)
2014年05月(5)
2014年04月(4)
2014年03月(8)
2014年02月(4)
2014年01月(8)
2013年
2013年12月(15)2013年11月(8)
2013年10月(3)
2013年09月(3)
2013年08月(8)
2013年07月(0)
2013年06月(0)
2013年05月(0)
2013年04月(0)
2013年03月(0)
2013年02月(0)
2013年01月(0)
■レス履歴■
■ファイル抽出■
■ワード検索■
堕天使の煉獄
https://rengoku.sakura.ne.jp
管理人
織田霧さくら(oda-x)
E-mail (■を@に)
oda-x■rengoku.sakura.ne.jp