C++相談室 part163

2022/12/30(金) 23:16:31.37

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

※前スレ
C++相談室 part162
https://mevius.5ch.net/test/read.cgi/tech/1667194175/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2023/04/18(火) 07:58:45.20

負の数、虚の数

2023/04/18(火) 09:29:12.70

符号無しループはグーグルだとコーディング規約違反だからな

2023/04/19(水) 11:20:40.34

コーディング基準はあくまで特定案件での決めごとに過ぎず
井の外で何かを批判する根拠に使っても説得力はない

2023/04/19(水) 11:50:42.02

符号ありしかない言語もあるから、それなりに一般性あるかと

2023/04/19(水) 12:06:58.70

特定案件つーてるのに他の言語？
話通じないやつだな

2023/04/19(水) 12:12:27.61

あれ？話広げたいんじゃなかったのか　こりゃ失礼

2023/04/21(金) 06:54:24.86

std::vector<T>::size()やstrlen()が符号無しで返してくるからそれらを使った汎用ライブラリ的なものを書く場合に仕方なくsize_tを使うこともあるだけでループ変数については符号有りで大して困らない希ガスだいたいOS記述言語であるところのC言語がアセンブラでは常識的に利用されるゼロフラグやキャリーフラグの概念を捨て去った設計した点をかみしめるべきや整数表現のMSBまで符号以外の意味で使わねばならないｼﾁｭｴｰｼｮﾝはﾏｼﾞ少ない多倍長演算であってさえ2のべき乗範囲に拘るのを捨てたらゼロフラグやキャリーフラグを駆使してビット幅全部使う記述と同等以上の効率にできうる

2023/04/21(金) 07:19:21.58

句読点を入れろ

2023/04/21(金) 08:49:31.32

江戸時代かよ。

2023/04/21(金) 11:52:07.81

スレチだと思うけどx86intrinsicsに詳しい人がいたらNonTemporal命令について教えてもらいたい
_mm_stream_load_si128や_mm_stream_si32はCPUキャッシュに対象範囲が無い場合はキャッシュスルーして確実にメモリを読み書きするということは分かったけど、
CPUキャッシュにある場合の挙動は一般的な命令同様にCPU内だけで完結してしまう？

2023/04/26(水) 10:00:37.79

>>891
読める・・・
読めるぞ！！

2023/04/26(水) 12:19:22.01

>>894
パフォーマンスを気にしてるなら実験、測定するべきだし
同期ならメモリバリア命令など適切な措置を取るべき

2023/04/26(水) 19:26:58.67

素人考えで悪いけどメモリへの書き込みがされずCPU内だけで終わると困ると思うけど

勝手なイメージ

書き込むアドレス内容がキャッシュに
ある
キャッシュのデータも書き換える　→　通常の動作

ない
_mm_stream_si32の場合　キャッシュへデータを読み込まない　→　速い
その他の場合　キャッシュへデータを読み込む　→　遅い

2023/04/26(水) 20:14:03.72

avx2でnon temporay　loadの方を比較したけどほぼ変わらない
サイズが小さすぎたせいかもしれないけど

2023/04/26(水) 22:05:00.98

>>896
目的はDMAとの整合性で既存の実装は勿論同期処理していたが
数日稼働させてみてTemporal命令混ぜた後にstreamストアしても今のところ不整合発生してないからもうちょい様子見てみる

2023/04/26(水) 22:12:18.77

>>898
本来のnon temporal命令の利点はその命令自体の速度ではなくキャッシュ汚染防止だね
例えば離れたアドレスにあるであろうstatic変数にアクセスするとき、その付近のデータには一定期間内に一度しかアクセスしないと分かりきっているなら、CPUの親切心による近隣メモリのキャッシュへの先読みはどうせ使われないのでむしろペナルティでしかなく不要となる

あとはmemcpyにおいてキャッシュはソース側に集中させてディスト側へは_mm_streamでキャッシュ汚染を抑えてコピーをするというテクニックもあって多分メジャーどころのコンパイラ実装は大体そうなってる
IvyBridge以降であればsimdより強化版rep movsbの方が早いケースも多くて分岐によってそっちに行くこともあるだろうけど

2023/04/26(水) 22:46:41.52

>>900
それなら納得

AMDでも試したけど変わらないな

2023/04/26(水) 22:54:06.40

それとx86intrinsicsと書かれてるのはSystem.Runtime.Intrinsics.X86 名前空間で.netなんだ
コンパイラがキャッシュを気にしたIL吐いたりそこから最適化されたネイティブコードを吐くようにはできてないと思う

2023/04/30(日) 10:58:06.37

これまでなんとなくinitializer_listを使ってきたのですが
このクラスって他のクラスと異なりコンパイラによって特別な解釈をされるのでしょうか?
以下のhoge::initializer_listはstdからコピペしてpublicメンバ以外を除外したものです
hoge::initializer_listを実体化するとコンパイルエラーとなります
コンパイラは g++ (Debian 10.2.1-6) 10.2.1 20210110 です
#include <initializer_list>
#include <cstddef>
namespace hoge {
template<class _E>
class initializer_list {
private: // 割愛
public:
typedef _E value_type;
typedef const _E& reference;
typedef const _E& const_reference;
typedef size_t size_type;
typedef const _E* iterator;
typedef const _E* const_iterator;
constexpr initializer_list() noexcept;
constexpr size_type size() const noexcept;
constexpr const_iterator begin() const noexcept;
constexpr const_iterator end() const noexcept;
};
}
int main () {
std::initializer_list <int> il0 = {10, 100, 1000};
hoge::initializer_list <int> il1 = {10, 100, 1000}; // <- コンパイルエラー
return 0;
}
エラーメッセージは
error: could not convert ‘{10, 100, 1000}’from ‘<brace-enclosed initializer list>’ to ‘hoge::initializer_list<int>’

2023/04/30(日) 11:09:10.55

エラーメッセージから考えると
1. { ..., ..., ..., }はstd::initializer_listと解釈される
2. std::initializer_listをhoge::initializer_listに変換しようとしてエラー
ということだと予想しますが
上記の1がstd::initializer_listを特殊なクラスとしている言語仕様と考えれば良い?

2023/04/30(日) 11:20:07.93

>>903
constexpr initializer_list(std::initializer_list<_E> const&) noexcept { }
これを追加すると通る

コンパイラは { } で std::initializer_list を生じる、という意味で「特別な解釈」をする
似たような話で typeid() で std::type_info を生じるのと同様

2023/04/30(日) 11:20:11.94

継承も何もしてないのにhoge::で上手く行くワケないだろ

2023/04/30(日) 11:25:59.75

せめて>>985みたいにstd::initializer_listを何かしらの形で受け入れ口としてコンストラクタに実装してやらないと通らないだろ

2023/04/30(日) 11:31:13.64

一般にstd名前空間のものは全部言語仕様と一体のものとしてあらゆる特別扱いが許されてるので
ヘッダからコピペして作った自作クラスが標準と同じように振る舞ってくれない可能性は常にある

2023/04/30(日) 11:36:13.87

>>905-908
みなさん有難うございます

>>908
>一般にstd名前空間のものは全部言語仕様と一体のものとしてあらゆる特別扱いが許されてるので
これは最小限にして欲しいものですね

>>905
>似たような話で typeid() で std::type_info を生じるのと同様
なるほどー! 言われてみればこれも気持ち悪かったです
同種の気持ち悪さ

2023/04/30(日) 11:38:03.98

初期化リストは式ではない

**デフォルトの名無しさん** (JP 0H6b-zzYQ) · 2023/04/30(日) 18:30:04.58

低レベルな質問ですが、よろしくお願いします

char str[10] = {0};

char str[10] = {0,};

この二つって違うんですか？

2023/04/30(日) 18:59:49.81

>>911
下は0,0と同じ意味じゃないかな

2023/04/30(日) 19:05:00.57

どっちも10個とも0になる

2023/04/30(日) 19:21:03.63

最後のカンマの次に項目を書かなくてもエラーにならなくなった名残だな

2023/04/30(日) 19:25:11.20

>>911
最後のカンマに文法上の機能はなく、単に余計なカンマを許容するだけ。
どちらも 0 がひとつ与えられる初期化子であるという扱いになる。
コードジェネレータで生成するときに余計なカンマを許容したほうが便利だからそうなってる。

初期化子の数が配列の大きさに足りない場合は >>913 の解説の通り 0 が補われるので10個の要素全部がゼロになる。
なので全部をゼロにしたいときは char str[10] = {}; というように書いてもよい。
(新しい規格では改定されているが) C では波括弧の中に 1 個以上の値を必要としたので
それに合わせて必ずひとつは 0 を書くというスタイルで書く人もいる。

**デフォルトの名無しさん** (JP 0H6b-zzYQ) · 2023/04/30(日) 19:26:34.51

丁寧な解説ありがとうございました。
どちらとも10個ともに０になるんですね

2023/05/01(月) 10:47:39.75

STLにある、k番目の要素を見つけるnth_element()は計算量がO(n）だそうですが、
これの中身が何をやっているかの日本語の（できるだけむずかしくない）解説ってどこかに
ありますかね?

2023/05/01(月) 11:27:54.04

選択アルゴリズムとかクイックセレクトでググれ

2023/05/01(月) 12:10:58.53

GPT-4の説明が分かりやすかった
std::nth_elementの説明として正しいかは分からんが
うまく動きそうではある
GPT-4に知らないことを聞くのはかなり危険だなぁ...

**青木康善** (ｱｳｱｳｳｰ Sa1b-zK5j) · 2023/05/03(水) 13:17:48.41

Javaより断然速いんでしょプラプラは。

2023/05/03(水) 13:57:16.79

チンチンプラプラ

2023/05/04(木) 05:42:07.54

>>920
C++で書きさえすれば速いとかは幻想
高速化のためのアイディアを考え甲斐があるのがC++

2023/05/04(木) 07:42:34.11

状況によってはJavaのほうが速いこともあるね

2023/05/05(金) 11:15:11.08

サブルーチン単位で見たらJavaやC#の方が早いこともあるけどそれはC++側のコードが糞なときだからな
マネージド言語はループ回すにしても強制的に一々長さチェック入ったりするので本気出したC++にはいずれにせよ敵わない

2023/05/05(金) 11:37:06.46

昔、JavaでもC++同等性能出せます(ただしメモリ使用量は10倍)
みたいなネット記事を見たのを思い出したわ

2023/05/05(金) 11:57:14.32

そんなの実際はほぼないだろ
ありうるとしたらC++のコードは最適化がかからないでC#は最適化掛かってsimd使ってましたとかじゃないのか？

2023/05/05(金) 12:23:29.18

メモリの管理やチェックもしてくれた上で条件によっては C++ を超えることもあるってくらいなら充分以上に速くはあるけどな。

2023/05/05(金) 12:44:08.47

>>926
C#の場合はコードジェネレーターが発達してきてるからC++はprintfで動的フォーマット、C#はprintfをジェネレーターで静的展開みたいなパターンで後者の方が早いという事があり得る
jsonのパースやシリアライズとか特に

2023/05/05(金) 13:09:57.48

そこら辺は自作すればどうとでもなる

2023/05/05(金) 14:28:48.55

x86ターゲットでビルドしたC/C++プログラムをARMでx86エミュレーション実行すると遅い
Java/.NETは中間コードだからランタイムさえARM版になっていれば性能が出せるね

2023/05/05(金) 15:39:52.77

それはエミュレータの性能では?

2023/05/05(金) 15:46:51.10

C/C++はコンパイル時に命令が決まるから中間コードよりビルド済バイナリの長期運用では不利になるよね
ソースコードからリビルドできる環境があれば問題ないんだけどさ

2023/05/05(金) 15:52:51.36

ARMをリビルト出来ない環境とは？

2023/05/05(金) 15:55:40.50

環境なんて開発者それぞれでしょ
Macbook使ってるけどx86エミュレーションで動いてるアプリがいくつかあるんだよ
開発者さんがまだM1/M2を持ってなくてARMビルドがリリースできてないんだと思う（もしくは飽きて開発放棄してるのか）

2023/05/05(金) 16:00:19.83

とにかく既存バイナリを異なるCPUアーキテクチャで動かす状況が現実にあるわけ
Macに限らずWindowsでもね
そのような状況では.NETアプリは軽快にどうさするのにC/C++アプリは遅いということになる

2023/05/05(金) 16:10:23.07

めちやくちゃだな
C++の開発環境にハンデ付けたらそうなるわ

2023/05/05(金) 16:16:39.25

Javaや.NETの中間コードにしてCPU命令セットに依存させないアプローチはポータビリティだけでなくランタイムごとの最適化を可能にするメリットがあるの
これC/C++では無理でしょ

2023/05/05(金) 16:22:19.51

ランタイムが対応していない環境ではC++の勝ちだな

2023/05/05(金) 16:47:17.33

C++のスレで「ネイティブなバイナリはエミュレータ上で遅い」って主張して何の意味があるのか？
場違いなこと言ってないか少し考えような

2023/05/05(金) 17:09:02.02

>>935
Apple文化ではCPUが変更されるが、Windows/Intel文化ではデスクトップでは
変更されたことが無い。PC/AT互換機はずっとx86系。

2023/05/05(金) 17:10:06.81

「C++は速い」って盲目的に信じてるキッズの目を覚ます意味がある

2023/05/05(金) 17:10:53.16

ターゲットを限定できる組み込み系開発ならともかく
一般消費者向けのアプリではC/C++が最速とは限らないという話だよ

2023/05/05(金) 17:15:38.26

仮想化やエミュレーションを何重にも重ねて実行するのが当たり前の現代的コンピューティングでは
「ネイティブで速い」なんて限定的な状況での一つの特長にすぎないんだよね

2023/05/05(金) 17:20:08.41

>>940
マイクロソフトは異なるCPUアーキテクチャに挑戦し続けてきたよ
そもそもNTのマイクロカーネルアプローチは様々なCPUアーキテクチャに対応するためのものだった
Alpha、PowerPC、IA-64で動作するWindowsが過去には存在した
既存のx86バイナリを動かせなかったことから失敗してしまったけどね
今はARM Windowsに挑戦中
これはMac同様にx86エミュレーションで既存バイナリを動かせるようにしてる

アプリ開発者としてターゲット環境を1つに限定すると不利になっていく思うよ

2023/05/05(金) 17:27:05.17

>>942
C言語はUnixをマルチターゲットで実現するするために作られた言語である件について：

プログラム作成にいくら手間がかかっても良いという話なら
#ifdef / #else　/ #endifの山でマルチターゲットに配慮しつつ高級アセンブラ的に使用したときのC言語が
中間言語実行または中間言語からのJITで巻けるシチュがわからん
説明できるんならkwsk、

2023/05/05(金) 17:31:37.61

そうではなくてプログラム作成の手間も込みの話なら
特定の応用においてErlangがC言語に勝った話は有名な話
https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_uri&item_id=12&file_id=1&file_no=1

やが、C言語で書かれたオープンなErlanｇのVMでそのパフォーマンスをたたき出した場合、
何の言語が勝ったことになるんじゃ……

2023/05/05(金) 17:33:05.29

>>945
それは既に説明したよ
C/C++が想定したターゲットに対して最適なバイナリを出力できるのは事実
でも既存バイナリの長期運用では最適な速度を出せない状況に遭遇することがあるんだ
実際にM1/M2 MacやARM Windowsでそういう状況が生まれてる

2023/05/05(金) 17:38:21.35

>>947
>C/C++が想定したターゲットに対して最適なバイナリを出力できるのは事実
>でも既存バイナリの長期運用では最適な速度を出せない状況に遭遇することがあるんだ
話が矛盾している
既存のVM（これも既存バイナリのうち）がなんで常に最適な速度を出せることになるんdai？

2023/05/05(金) 17:43:37.99

>>948
個々のアプリをリビルドせずにVMだけリビルドすれば済むからエコシステムを維持しやすいの
たしかM1 Macが出てから半年も経たずにARM版JavaVMが登場したと思う
JavaアプリはIntel MacでもM1 Macでも同等の性能が出る
ネイティブアプリは各開発者がARMビルドをリリースするのを待たなければならなかった（まだIntel版しか存在しないアプリも多い）

2023/05/05(金) 17:53:15.49

>>949
>個々のアプリをリビルドせずにVMだけリビルドすれば済むからエコシステムを維持しやすいの
>たしかM1 Macが出てから半年も経たずにARM版JavaVMが登場したと思う
>JavaアプリはIntel MacでもM1 Macでも同等の性能が出る
>ネイティブアプリは各開発者がARMビルドをリリースするのを待たなければならなかった（まだIntel版しか存在しないアプリも多い）
そのネイティブアプリとは一体……
およびそんな特定のケースを言語の優劣の一般論として展開してよい根拠とは一体……
および>>946はどうなるんじゃ……

さらに言うと、VMの改修による新規プラットフォームのトータルサポートが、特定の応用で#ifdef/#else/#endifを何個か追加して
ソースからビルドするより常に早いとする根拠は一体……

2023/05/05(金) 18:01:52.41

ごめんね
話が噛み合わないようだからこれで最後にする

一般論として言語の優劣を語ってるつもりはないです
ソースコードからのリビルドよりVMが速いとは言ってないです
開発者の事情でリビルドされない既存バイナリで性能が出ない状況が実際にあると言ってるだけです

2023/05/05(金) 18:11:56.10

さっきも書いたけど常にc++の最適化が他の仕組みに勝つとは限らないから
他の言語でsimd化されてc++でsimd化されない場合もあるだろうと

2023/05/05(金) 18:18:32.71

データベースでは長期運用でデータ数が変わるから、
統計情報を参考にして、使われるアルゴリズムも変わる

特に、IBM では全自動のみ。
自分で、使うアルゴリズムを指定できない

2023/05/05(金) 18:19:38.90

C++はメモリーのフラグメンテーションを解消できないからJavaより遅いというエンジニアの意見は有名だと思う

2023/05/05(金) 20:13:04.57

データベースでは独自のガベージコレクションくらい実装している

2023/05/05(金) 21:20:11.75

Java仮想マシンとARM向けx64仮想マシンの比較ですか

2023/05/06(土) 03:05:01.42

>>954
フラグメンテーションで遅くなるのは、キャッシュの影響だけ。
ソートだけはキャッシュが乱れまくるので、特殊。
それ以外は、ほとんどの場合は、遅くならない。

2023/05/06(土) 03:08:16.87

キャッシュの乱れによる速度低下を防ぎたいなら:
・ソートは本当に必要な場合だけ行なう。
・ソートする場合でも、要素数が少なければ特に問題ない。
　すべてがキャッシュに載ってしまえば、キャッシュミスが起きないから。
・そもそも物理シミュレーターではソートは必要ないことが多い。
　なぜなら自然の物理法則はソートの概念を用いていないから。
・レイトレーシングなども物理法則に基くので、基本的にソートを
　余り使わないでよいアルゴリズムを作ることが出来る。

2023/05/06(土) 03:48:50.75

>開発者の事情でリビルドされない既存バイナリで性能が出ない状況が実際にあると言ってるだけです
そういう話ならそういう話で、
>既存バイナリの長期運用では最適な速度を出せない状況に遭遇することがあるんだ(>>947
と言ったときに、何と何の比較なのか（何なら「最適な」速度なのか）というレギュレーションを先に示して……

ソースコードからリビルドするだけで元より速くなるケースが本当にあるなら、そういうケースの提示をすっとばして
Javaや.NETの中間コードにしてCPU命令セットに依存させないアプローチの話なんてしないで……

一般的な速度比較ではなくて、他の言語でsimd化されてc++でsimd化されない場合の速度比較ならその話だけして……

アスペにill-definedなﾋﾞﾐｮｰなネタ振りをしないで……

2023/05/06(土) 03:54:48.32

いや俺3行以上は読まないから

2023/05/06(土) 03:55:54.11

補足、

>既存バイナリの長期運用では最適な速度を出せない状況に遭遇することがあるんだ(>>947
と言ったときに、最適な速度をたたき出すﾌﾞﾂが発言者の脳内にしか無いのだとしたら
そんなの単なるお気持ちの表明やんけ……

自分は最初から正しい論理展開をしていたみたいな顔するのはやめて……

2023/05/06(土) 03:57:28.42

あと2行削れば読んでやるよ

2023/05/06(土) 07:33:39.33

それも度が過ぎとるな

2023/05/06(土) 08:23:03.54

>>961
はじめから「中間コード」と「ビルド済バイナリの長期運用」って書いてあるぞ？

2023/05/06(土) 08:31:13.11

俺は産業用システムのフロントエンドUIをC#で組むことが多いんだが、とあるデバイスの制御APIがネイティブDLL（.NETアセンブリではない）で提供されていたんだ
そのデバイスメーカーはなぜか32ビット版のDLLしか提供してくれなかった
それでC#プログラムも32ビット版.NETランタイムで動かさなきゃならなくなった

C++が速いとかどうでもいいけどさ、せめて64ビットビルドできるようになってから言ってくれないかな？

2023/05/06(土) 09:34:57.34

C++が速いとか関係なく、そのデバイスメーカーに言え

2023/05/06(土) 09:50:15.65

64ビット版.NETランタイムから32ビットDLL使う方法あるでしょ
NeeViewがそういうことしてる

2023/05/06(土) 10:15:28.65

最近のc++プログラマってプロセス間通信も知らないの？

2023/05/06(土) 11:51:45.90

NeeViewもSusieプラグイン用の32bitプロセス起動してプロセス間通信してるだけやで

2023/05/06(土) 12:09:15.03

もうC++の話しじゃねーじゃん

2023/05/06(土) 14:00:34.30

比較と称して対立煽りすればスレの勢いが伸びる
ただし意味のある議論はほぼ発生しない

技術板にアイデンティティを勝手に感じている技術力ゼロの雑魚だけがこういう話を振り、乗っかる

2023/05/06(土) 16:35:41.29

ない環境の仕事が長くなってさわりしか覚えてないな

2023/05/07(日) 12:16:32.15

>>964
>はじめから「中間コード」と「ビルド済バイナリの長期運用」って書いてあるぞ？
同じアプリの＊実在する＊中間コード版と
＊実在する＊長期運用されたビルド済バイナリとで比較しているのかっていうか、
その根拠こそ求められる
>>964はふいんきに飲まれて詐欺に遭いやすいタイプなのではないか……

2023/05/07(日) 13:31:09.45

同じアプリである必要あるか？

2023/05/07(日) 18:18:18.80

>同じアプリである必要あるか？
ある
「中間コード」と「ビルド済バイナリの長期運用」の速度を比較しようとしているのだから、
それらの違い以外は同じに保たねば正しい比較にならない

2023/05/07(日) 18:20:17.74

0xの頃のように混とんとしてきたが、あの頃の熱さはないな

2023/05/07(日) 18:21:16.14

C++20で飯の三杯くらいは食えると思うが

2023/05/08(月) 12:43:08.47

昔Windows上でJavaがエラー吐いたとき
VCのエラーを出力してたから
裏ではC++使ってるんだろ
つまりJavaもC++のパワー借りてんだから
C++のほうが速いって話にならない？

2023/05/08(月) 13:06:18.19

>>978
ならない。

2023/05/08(月) 18:41:34.65

C++はエンジン、Javaはターボという関係では？

2023/05/08(月) 20:29:15.27

JavaってAVXとかNEONとか使えるの？

2023/05/08(月) 21:28:12.53

JavaでもAVX等の拡張命令は使われるみたいよ
https://www.slideshare.net/nttdata-tech/java-maximize-cpu-2019-nttdata-suenaga

2023/05/09(火) 01:01:11.52

命令を記述出来るかってこと
AVXやNEONはコンパイラじゃ性能出ない

2023/05/09(火) 01:14:10.24

あー自分で書きたいのか
Javaの場合はJEP417 Vector APIでAVX命令を扱えるよ

2023/05/09(火) 07:03:13.01

つstd::valarray