C++相談室 part144

**デフォルトの名無しさん** · 2019/07/22(月) 13:18:35.52

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

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

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレここまで -----

**デフォルトの名無しさん** · 2019/08/18(日) 10:59:16.60

正常動作してんだったらそれでいいじゃん

**デフォルトの名無しさん** · 2019/08/18(日) 11:14:15.09

前半のexportが謎

**デフォルトの名無しさん** · 2019/08/18(日) 11:22:19.79

>>501
簡単に言えばMakefileに

作ってほしいファイル名: そのファイルを作るのに必要なファイル
(タブ（なぜか空白はダメ））作るためのコマンド

をズラズラ書いておけばいい
なのでその例だと

Func.o: Func.cpp
　g++ -c -g -Wall -pthread -std=c++11 ./Func.cpp -lm -lz -Wextra -o Func.o

Main.o: Main.cpp
　g++ -c -g -Wall -pthread -std=c++11 ./Main.cpp -lm -lz -Wextra -o Main.o

Main.exe: Main.o Func.m
　g++ Main.o Func.o -o main.exe -lz

って書いておいて（わかると思うがg++の前はタブな）
make Main.exe
ってやればいい
毎回Main.exeを指定するのが面倒なら
Main.exe: Main.o Func.m
　g++ Main.o Func.o -o main.exe -lz
の行を一番上に持って行けば make だけで作成できる
（makeは指定がないと最初に見つけた作りたいファイルを作ろうとする）

**デフォルトの名無しさん** · 2019/08/18(日) 11:59:20.99

>>501
以下の文献とオライリーのGNUmake読んで、あとは自分で考えるのが良い。
http://aegis.sourceforge.net/auug97.pdf
この辺り、まともに理解してる奴が本当に少ないから。
だからconstexprとかboostとかクソみたいなものをありがたがるんだろうなと思う。

**デフォルトの名無しさん** · 2019/08/18(日) 12:02:21.51

ビルドツール選びの時にC++の言語機能をたたく理由がわからない。

**デフォルトの名無しさん** · 2019/08/18(日) 12:06:43.92

>>506
ビルドと言語機能は綿密に絡み合ってるから。
c++使っててこれだけ当たり前の話を理解できないというのが理解できない。

**デフォルトの名無しさん** · 2019/08/18(日) 12:20:14.52

> ビルドと言語機能は綿密に絡み合ってるから。
具体例の１つも出せないクズ乙

**デフォルトの名無しさん** · 2019/08/18(日) 12:24:12.06

>>508
505の内容見て具体例に思えないようならもう話すことはないな。

**デフォルトの名無しさん** · 2019/08/18(日) 12:25:58.38

> タブ（なぜか空白はダメ）

こういうところがクソ

**デフォルトの名無しさん** · 2019/08/18(日) 12:32:36.07

「else」は「さもなくば」

**デフォルトの名無しさん** · 2019/08/18(日) 12:35:03.02

Makeは古い
AntかMavenかGradle使え、
いや知らんけど

**デフォルトの名無しさん** · 2019/08/18(日) 12:39:00.99

>>509
ああ、そのまま黙っていてくれ。

**デフォルトの名無しさん** · 2019/08/18(日) 12:43:59.27

>>509
はい、逃げたーw

**デフォルトの名無しさん** · 2019/08/18(日) 12:54:48.15

素のMakefileは最終的なオブジェクトファイルとヘッダファイルの依存関係を書き下すのが大変に面倒臭い
なぜなら、
　Target: Dependencies1 Dependencies2 ...
　(TAB)Command
という記述において、Commandが具体的にTargetお生成しないと事実上立ち行かないので、
インクルードファイルAがインクルードファイルB、Cをインクルードしているという状況を
　A: B C
　(TAB)echo Hello World!
などと書くわけには逝かず、あくまで
　foo.obj : foo.cc A B C
　(TAB)gcc foo.cc
式に.objなターゲットに対して関連付けねばならない
ファイルがあるだけで勝手にヘッダファイルの依存関係を解決させることは
GNU Makeの昨日とシェルコマンドを組み合わせてできた気がするが（忘れた
たかがこれだけのためになんでそんな糞面倒なことをせねばならんのじゃ、というｷﾓｽ

※ 個人の感想です

**デフォルトの名無しさん** · 2019/08/18(日) 13:00:42.47

Ruby のRake, Thor などのタスクランナーで、コンパイル出来ないのか？

Webpack, Gulp とか

**デフォルトの名無しさん** · 2019/08/18(日) 13:02:29.42

C++のモジュールシステムはいけてないよね
という話ならわかるが、
constexprとboost?
全く意味がわからねぇ

**デフォルトの名無しさん** · 2019/08/18(日) 13:07:44.93

>>515
そこは gcc -M 類の出番。まぁ面倒なのは変わらないんだろうけど。

**デフォルトの名無しさん** · 2019/08/18(日) 13:34:10.37

一応昔はコンパイル単位がすなわちモジュールとして機能していたはずだったのに、どこで間違えたんだろうな

**デフォルトの名無しさん** · 2019/08/18(日) 14:46:24.52

>>501
簡単に言えばMakefileに

作ってほしいファイル名: そのファイルを作るのに必要なファイル
(タブ（なぜか空白はダメ））作るためのコマンド

をズラズラ書いておけばいい
なのでその例だと

Func.o: Func.cpp
　g++ -c -g -Wall -pthread -std=c++11 ./Func.cpp -lm -lz -Wextra -o Func.o

Main.o: Main.cpp
　g++ -c -g -Wall -pthread -std=c++11 ./Main.cpp -lm -lz -Wextra -o Main.o

Main.exe: Main.o Func.m
　g++ Main.o Func.o -o main.exe -lz

って書いておいて make Makefile Main.exe

**520** · 2019/08/18(日) 14:48:27.09

スマン、間違えて二重投稿になっちまった

**501** · 2019/08/18(日) 14:57:48.84

>>503
CC, CXXは個別インストールしているgccがあり、以前何かのモジュールをインストールしたときに、元からある
/usr/bin/g++
に関連したライブラリパスが使われることがありこれを設定しました。
今回の単純コンパイルには不要かもしれませんが、おまじないで残していました。

>>504
ありがとうございます。
基本はコマンドを並べていけばいいんですね。
何も指定しない時には先頭のものを指定したことと同じになることも参考になりました。

>>505
このあたりもちゃんと理解できるようになりたいです。
少しづつ勉強したいと思います。

>>512
こんなのもあるんですね。
これも調べてみたいと思います。

**501** · 2019/08/18(日) 15:01:32.97

>>521
いえいえありがとうございます。
まずは単純羅列から入ってCXXFLAGS、OBJS、LIBSなどを使いこなしていこうと思います。

◆QZaw55cn4c · 2019/08/18(日) 16:31:44.67

>>512
それらが make に比して優れた点はなんでしょうか？

**デフォルトの名無しさん** · 2019/08/18(日) 17:11:35.03

>>517
横からすまんが意味はわかる
c++はコンパイル時になんでもかんでも解決しようと必死すぎ
フェーズ分けてbinutils使いこなした方が素直と思うことが多々ある

**デフォルトの名無しさん** · 2019/08/18(日) 18:18:09.60

>>525
binutilsを使う例として、具体的にはどういうことがありますか？

**デフォルトの名無しさん** · 2019/08/18(日) 18:19:29.10

なんなんだろうなこの「俺に手取り足取り教えろ」みたいな要求は。

**デフォルトの名無しさん** · 2019/08/18(日) 18:30:04.45

お前には聞いてないから気にしなくていいぞ

**520** · 2019/08/18(日) 19:26:20.54

>>525
ますます意味わからんw

**デフォルトの名無しさん** · 2019/08/18(日) 19:34:00.82

変なの居るなw

**デフォルトの名無しさん** · 2019/08/18(日) 19:35:39.45

スキル不足なのに見下してるやつに教えてやる義理はないんだよね
逃げますね

**デフォルトの名無しさん** · 2019/08/18(日) 19:40:22.27

私はneson/ninjaがおぬぬめ🌱

**デフォルトの名無しさん** · 2019/08/18(日) 22:23:44.93

>>525
国際標準になってないbinutilsなんて使ったら、環境依存でコンパイル通らなくなったりする。

**デフォルトの名無しさん** · 2019/08/19(月) 03:39:22.51

VC++2017で std::string str = "abcd";ってやると
debugモードだとビルドできてるのに
ReleaseモードだとLNK2001エラーが出てしまいます

他に何か宣言かlibがいるのでしょうか
昨日一日この点で一日悪戦苦闘していました

ちなみにプロジェクトはコンソールアプリで
リンカーのシステムは処理の都合上、Windows(/SUBSYSTEM:WINDOWS)にしてあります

**デフォルトの名無しさん** · 2019/08/19(月) 06:43:15.57

プロジェクトの構成変更したときにDebug版だけ変えたとかじゃねえの

**デフォルトの名無しさん** · 2019/08/19(月) 06:56:44.40

>>524
遅レスｽﾏﾝが、知っている単語を並べてみただけなので
全く
わかり
ません

**デフォルトの名無しさん** · 2019/08/19(月) 07:12:08.46

>ファイルがあるだけで勝手にヘッダファイルの依存関係を解決

俺はこれカスタムして使ってます
https://postd.cc/makefile-c-projects/

**デフォルトの名無しさん** · 2019/08/19(月) 09:00:35.28

>>535
いつの間にかReleaseの方ばかり設定いじるというアホなことやらかしてました。
プロジェクトを作り直してソースをコピーすることで解決しました。

**デフォルトの名無しさん** · 2019/08/19(月) 09:12:20.21

VC++2017でコンソールアプリとしてプロジェクトを立ち上げました。
しかし、コンソール（dos窓）を非表示にするべく
構成プロパティのリンカー→システム→サブシステムを
Windows(/SUBSYSTEM:WINDOWS)にしてwindows.hをincludeして
int main(void)からint WINAPI WinMain(void)に変更してビルドすると
「C2731 'WinMain':関数はオーバーロードできません」と言われました。

構成プロパティのリンカー→詳細設定→エントリポイントをmainにしてビルドしても
結果は変わらず、int main(void)に戻すと大量にエラーが発生しました。

この場合、どうすればよろしいのでしょう？

**デフォルトの名無しさん** · 2019/08/19(月) 09:16:19.09

WinMainのシグネチャが違う

**デフォルトの名無しさん** · 2019/08/19(月) 09:16:37.96

>>539
エラーメッセージにしたがって修正すればよろしいですよ。

**デフォルトの名無しさん** · 2019/08/19(月) 09:37:33.04

>>539
なぜ手でsubsystem変えようとしてんの？
VSのテンプレートそのまま使えばいいじゃん
それができないならその理由を説明すべき

**デフォルトの名無しさん** · 2019/08/19(月) 09:40:50.85

>>540-541
ありがとうございます。
以前ググって見つけたものをだまされたと思って
int WINAPI WinMain(void)から
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, char* lpCmdLine, int nCmdShow)に
変更したらReleaseモードでも上手くいきました。
でも、元が(void)なんで、引数の設定に釈然としないところありますが…

**デフォルトの名無しさん** · 2019/08/19(月) 09:43:45.91

>>542
普通にやったらどうしても大きなdos窓がしばらく現れるので
（処理の都合上system関数からのexe実行が必要だからです）
ググって調べたらそういう風にいじれと書いてあったからです。

**デフォルトの名無しさん** · 2019/08/19(月) 10:35:27.56

boostなしで128ビット複素数を使う最もシンプルな方法ってなんですか？

**デフォルトの名無しさん** · 2019/08/19(月) 13:02:54.66

complex<__int128_t>

**デフォルトの名無しさん** · 2019/08/19(月) 15:12:55.94

>>546
c++における4倍精度三角関数の呼び方が分かりません
cosq()とかsinq()のことです

**デフォルトの名無しさん** · 2019/08/19(月) 15:33:17.41

複素数関係ないじゃん…

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2019/08/19(月) 15:36:02.76

コスキュー、シンキューじゃあかんの？

コサインクアドラント、サインクアドラント

**デフォルトの名無しさん** · 2019/08/19(月) 21:07:56.83

4倍精度ライブラリでまともな速度出るものってないのでは。

**デフォルトの名無しさん** · 2019/08/19(月) 21:14:48.68

template+constexpr => これ最強！！！

**デフォルトの名無しさん** · 2019/08/19(月) 21:20:16.93

C++20でようやく使っても良いかな程度

**デフォルトの名無しさん** · 2019/08/19(月) 21:23:04.43

unifyde call syntax => 邪道。

でも、欲しいのである。
関数型食えると思うんだけどなー。

**デフォルトの名無しさん** · 2019/08/19(月) 23:23:04.65

バイトデータの比較を高速に行いたいのですが、以下①②を考えました。
連続したバイトデータを比較するのに下記以外に簡素に書ける方法はありませんか？
memcpyはコピーが発生するのでちょっと遅くなるかなと思っています。

int main(){
unsigned char byte[6] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06 };
// ①1バイトずつ比較
if( byte[2] == 0x03 && byte[3] == 0x04 && byte[4] == 0x05 && byte[5] == 0x06 ){
printf("yes\n");
}else{
printf("no\n");
}
// ②ビット演算した結果を比較
if( (byte[2] << 24 | byte[3] << 16 | byte[4] << 8 | byte[5]) == 0x03040506 ){
printf("yes\n");
}else{
printf("no\n");
}
}

**デフォルトの名無しさん** · 2019/08/19(月) 23:35:28.83

std::int8_t A[]={0,1,2,3};
std::uint32_t* B=(std::uint32_t)A; //care align.

if(*B == 0x03020100){
//yes.
}else{
//no
}
SIMDライクな感じで比較できる気がするけど、おススメはしない。
エンディアン注意。

**デフォルトの名無しさん** · 2019/08/20(火) 00:09:06.19

クヌース-モリス-プラット法とかボイヤー-ムーア法とかやらんかい
ttps://nebuta.hatenablog.jp/entry/20110127/1296115997

**デフォルトの名無しさん** · 2019/08/20(火) 01:22:04.58

>>554
memcmp とか std::equal とか。速度はどうなるかわからないので推測じゃなくて実測でよろしく。

**デフォルトの名無しさん** · 2019/08/20(火) 01:33:17.10

データの性質によるけどテーブル使ったCRC16で比較するのは？

**デフォルトの名無しさん** · 2019/08/20(火) 01:43:07.39

>>554
ぐだぐだ考えてないでてめえで計測しろ
計測しないなら黙ってmemcmp使っとけ

**デフォルトの名無しさん** · 2019/08/20(火) 02:14:14.18

>>554
少量のメモリ上の値比較やコピーの処理時間なんて無視できる程度で考える必要もない。
大量のデータの比較を行うとしたら、その大量のデータがメモリ上に存在するために多くの場合はファイルI/Oなり通信なり演算なりしているはずで、そちらのコストの方が桁違いに大きいから単純な比較処理のコストを気にするのは無意味。
ほんとに気にする必要があるのか、まずは確認すべきだろう。つまらない高速化を考えるより、可読性の高い素直なコードを書いた方がいいよ。

**デフォルトの名無しさん** · 2019/08/20(火) 13:11:19.02

高速化って言ったら、やっぱりよく使う変数をレジスタに割り当てることが大事だよな
メンバ変数は毎回メモリとやり取りするので遅くなるから
ループ外で自動変数に読み込んでから使うとビックリするぐらい速くなったよ

**デフォルトの名無しさん** · 2019/08/20(火) 13:24:48.11

（いつの時代の話だろう？）

**デフォルトの名無しさん** · 2019/08/20(火) 13:45:22.85

(コンパイラを作っているのだろう)

**520** · 2019/08/20(火) 13:57:22.86

（日記はチラウラに）

**デフォルトの名無しさん** · 2019/08/20(火) 14:07:45.10

(>>562-564
こいつらの自信はどっから来てるんだろう)

**デフォルトの名無しさん** · 2019/08/20(火) 14:18:58.77

（むしろ自信なんてどこから出てきたんだ…）

**デフォルトの名無しさん** · 2019/08/20(火) 14:29:19.64

よくあるような、
if ( (c >= 'A' && code <='Z') || (c >= 'a' && code <='z') ||
　　c == '_' ) {
　・・・
}
の部分を、条件jmp文が少しでも少なくなるようにと思って、
予め作成しておいたテーブル(配列)を使って、
if ( eiji_or_underscore[c] != 0 ) {
　・・・
}
として実測してみたところ、何度計測しても後者の方が遅くなった。
アセンブリコードを見てみても、前者だと5つの条件jmp命令、後者だと1つの条件jmp命令と、
後者の方が命令数が少なくっていた。しかし、前者だと、レジスタとcmp命令を使っていたが、
後者だとグローバル変数の配列を読み出しに行っていた。

最近のCPUは非常に複雑で高度な「分岐予測」をしていて、配列は読み出してみないと
値が分からないので、「予測」ができず、分岐予測の「予測間違い」がおきるが、
レジスタをcmpで比較する場合には予測が出来るためだろうか。

しかし、昔より最適化する際にどっちが高速になるかの予想が難しくなってしまってる。

**デフォルトの名無しさん** · 2019/08/20(火) 14:39:39.94

>>567
誤：if ( (c >= 'A' && code <='Z') || (c >= 'a' && code <='z') ||
正：if ( (c >= 'A' && c <='Z') || (c >= 'a' && c <='z') ||

**デフォルトの名無しさん** · 2019/08/20(火) 14:40:33.96

分岐予測はデータの内容関係ないやろ

**デフォルトの名無しさん** · 2019/08/20(火) 14:48:01.70

最近の環境では「実測」の信頼性確保も、また難しいです。
なぜかある時には何度測定しても遅いのに、あらためて別の時に
測ると速く出る事があったりします。

**デフォルトの名無しさん** · 2019/08/20(火) 14:48:40.12

単にテーブル参照はメモリーから読み出すから遅いだけだろ

**デフォルトの名無しさん** · 2019/08/20(火) 14:49:27.63

俺が書いた通り、単にメモリへのアクセスが遅いんだよ

**デフォルトの名無しさん** · 2019/08/20(火) 15:08:33.40

理論上は、メモリがキャッシュに乗っている限り、メモリの読み書きとレジスタ
への読み書きの速度は同一です。

ただし、メモリとメモリは add, sub, mov 命令で2つのオペランドに同時指定は
出来ないのに対し、レジスタは出来るので、確率的にレジスタの方が必要な
命令数が少なくて済むので高速になる場合があります。
あとキャッシュに乗って無い場合はメモリは遅くなります。

**デフォルトの名無しさん** · 2019/08/20(火) 15:22:22.32

>>571
アホか>>567読み直せ

**デフォルトの名無しさん** · 2019/08/20(火) 15:23:45.52

あ、すまん俺の方が間違えてた・・
まさかとは思うけど最適化してないとか無いよね

**デフォルトの名無しさん** · 2019/08/20(火) 15:29:52.16

>>575
最適化はどちらも同じオプションでしてますし、出力されたアセンブリ・コード
も見て、テーブルを使った方が命令数の少ないコードになっていることも
確認してます。条件jmp命令も少なくなっています。

**デフォルトの名無しさん** · 2019/08/20(火) 15:30:02.90

あと前者のコードは与えたcの値がA-Zだと分岐の回数2回で済むからじゃないかね

**デフォルトの名無しさん** · 2019/08/20(火) 15:36:01.76

>>577
実はその影響もあると思っているのですが、それだけだと前者の場合には、
命令数から言えば1～2クロックほど速くなる場合がある程度です。
しかし、実測してみると、後者のやり方の方がもっと遅くなっている
ようなんです。

面倒ですが、マクロスイッチでコードを切り替えられるようにして
短時間の内に二つを切り替えて速度比較してみようかと思っているところです。

**デフォルトの名無しさん** · 2019/08/20(火) 15:51:20.21

最近のCPUは温度によってクロック数が変動する可能性もあるそうですね。

**デフォルトの名無しさん** · 2019/08/20(火) 16:13:18.12

テーブルがキャッシュに乗ってなかったり、
>>561と同じでテーブルがグローバル変数だと書き換えを懸念して最適化ぎ抑制されてんじゃないかな

**デフォルトの名無しさん** · 2019/08/20(火) 16:16:16.40

レンジエラーになりそうで怖い。っていう横やり。

**デフォルトの名無しさん** · 2019/08/20(火) 16:23:55.23

マクロスイッチ切り替え方式にして、ほぼ同時に両方を測定してみたら、
テーブル方式の方が速くなっていました。

**デフォルトの名無しさん** · 2019/08/20(火) 16:32:21.29

キャッシュ汚染とかの話になったの？

**デフォルトの名無しさん** · 2019/08/20(火) 17:25:38.94

>>580
アセンブリコードを見る限り、特に問題なく、人間が単純に書いた場合
と似たようなコードになっています。

ただし、一点、テーブルの c 番目の要素を参照する際、バイト整数の c
をゼロ拡張して32BIT 整数にする必要があるのですが、自分の使ってるVC++
だと、movzx 命令を使わずに、xor eax,eax; mov al,cl のように2命令
を使ってしまっている点が、人間が最適化するより遅いコードになってしまって
います。

**554** · 2019/08/20(火) 18:34:23.13

コメントありがとうございます。

>>555
エンディアンを気にしないといけないのは後々分かりづらくなりそうですね。。

memcmpというのがあったんですね。
連続バイト比較ができてシンプルで良さそうです。
これを使ってみます。

**デフォルトの名無しさん** · 2019/08/20(火) 19:55:32.24

volatile命令の他にキャッシュ命令とか無いのかよ
ルックアップテーブルをキャッシュに載せときゃ爆速じゃん
もっと言えばテーブルを石に焼いた時一番早い

**デフォルトの名無しさん** · 2019/08/20(火) 22:55:27.89

>>569
>分岐予測はデータの内容関係ないやろ
分　岐　予　測　は　デ　ー　タ　の　内　容　（統計的偏り）　に　関　係　あ　る

>>567
最近のCPUは黒魔術で製造されているからミクロな最適化を下手に人が手を加えるより
単純なアルゴリズムにした方が速いことが多くなた
印象

**デフォルトの名無しさん** · 2019/08/20(火) 23:22:44.05

>>587
お前はアレか
>>567の言う「配列は読み出してみないと値がわからないので、予測が出来ず」
が正しいと？

**デフォルトの名無しさん** · 2019/08/21(水) 01:15:10.83

多分メモリが読めてない状態でも分岐予測して投機的実行はするんじゃないかな
近代的なCPUは

**デフォルトの名無しさん** · 2019/08/21(水) 05:42:53.52

>>567の前半部のコード
>if ( (c >= 'A' && code <='Z') || (c >= 'a' && code <='z') ||
>　　c == '_' ) {
>　・・・
>}
はCPUレベルの分岐予測＋投機的実行では入力データによっては速度向上し難いケースがある
　AaZz_AaZz_AaZz_....
という入力を考えたらﾜｶﾙ（cといして1文字入力される度に||か&&を打ち切る分岐箇所がちがーう
分岐予測キャッシュというのは分岐命令1個につき1状態か2状態記憶がせいぜい（しかもLRU式に記憶が消える
のでこのような場合は投機的実行結果が捨てられ続けかねない

>>598
ハイ論破

>>589
分岐予測と投機的実行が効力を発揮するのは多重ループで内側の分岐条件が大部分の時間変わらないというケース

**デフォルトの名無しさん** · 2019/08/21(水) 05:59:08.65

ちゅか&&や||の条件式に関数呼び出しが含まれない単純なケースにおいては、
OoOと分岐予測を備えた今日日のCPUでは途中で打ち切るより全部評価してしまった砲が速い可能性がおおきい
このとき問題になるのは副作用のある式が問題であり、
副作用がある++や--があると、やっぱ言語規格どおり||や&&は条件成立で打ち切らないとソースコードに書かれた気体動作と
オブジェクトコードの動作が別物になってしまうので諸悪の根源
C言語を引きずった仕様のままでは時代について逝けてない

Rustで++や--を式の中で使えないのは故無きことでは無いんじゃ…

**デフォルトの名無しさん** · 2019/08/21(水) 06:00:45.09

ｽﾏﾝGoと混同した
Rustに++や--は無い

**デフォルトの名無しさん** · 2019/08/21(水) 06:13:21.67

もうRustはいいから

**デフォルトの名無しさん** · 2019/08/21(水) 07:20:20.39

>>590
> （しかもLRU式に記憶が消える
知ったか乙
せめて
https://ja.m.wikipedia.org/wiki/分岐予測
くらいは読んでこい

> のでこのような場合は投機的実行結果が捨てられ続けかねない
そりゃ頑張って作れば最悪の状況は作れるよw
だから何？って話だが

**デフォルトの名無しさん** · 2019/08/21(水) 10:08:42.06

>>590
そういう安価ミスはちゃんと訂正しろよ
あと反論になってない
語弊はあったろうけど配列だから分岐予測が効かないなんて話はないだろうと言いたかっただけだ

**デフォルトの名無しさん** · 2019/08/21(水) 20:40:17.99

>>586
1バイトの即値データとの比較の方が速いに決まってんだろ。
命令デコードする段階で比較対象のデータとってこれるんだから

**デフォルトの名無しさん** · 2019/08/21(水) 22:54:56.30

>>594
リンク先のどこにLRUでは無いと書いてあるんじゃ…
分岐予測キャッシュがあふれたときはLRUが基本
これは2次キャッシュを儲けても関係ない（それぞれの中で溢れたらLRU
むしろハードウェア実装の制限でLRUより性能の落ちるしくみを使うこともある
が（nウェイセットアソシアティブの「アソシアティブ」部分は一部アドレス線の固定解釈による簡素化

>>595
分岐予測が性能を発揮しない例が有る以上ハイ論破の訂正の必要は認められぬ

**デフォルトの名無しさん** · 2019/08/21(水) 23:02:56.86

もし分岐予測制度を上げるためのキャッシュエントリのn状態化とキャッシュが溢れた場合の話を
混同しているんだとしたらきわめておめでたい話だといえる

あるアドレスの分岐命令に対応するキャッシュエントリがどの状態に居たとしても、
そんあことはお構いなしに溢れたときはどれかのエントリが消される.。
このとき他の制約が無ければ理想解はLRUという話

**デフォルトの名無しさん** · 2019/08/21(水) 23:16:22.08

ていうか
>1状態か2状態記憶がせいぜい（しかもLRU式に記憶が消える (>>590
とまで書いたのだからキャッシュエントリのn状態化は機知の前提で話していることぐらいは読み取って
ﾎｽｲ
（雑駁なリンク先を示すよりはむしろ「1状態って何だよ2状態だろパーカｗｗｗｗｗｗｗ」ぐらいの反応であれば>>594は知性を疑われずに済んだ

**デフォルトの名無しさん** · 2019/08/21(水) 23:18:51.67

ただのこじつけじゃねーか
てかそんだけ御託並べて質問者へのアドバイスはゼロかw

(というかこいつの論調どっかで見たな・・・)

**デフォルトの名無しさん** · 2019/08/22(木) 00:05:50.83

>>597-599
分岐予測はキャッシュじゃねーぞw
反論するなら分岐予測にLRUアルゴリズムを使ってる奴はCPU挙げてみな