C言語なら俺に聞け 155

2020/05/10(日) 23:20:27.99

!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

※前スレ
C言語なら俺に聞け 154
https://mevius.5ch.net/test/read.cgi/tech/1578997950/

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

2020/07/15(水) 21:08:27.18

このクイズ番組の回答者が読み方喋ってる
https://youtu.be/f7WPP-5GG58

2020/07/15(水) 21:53:44.85

>>548
イエーー
が正しい

2020/07/16(木) 00:44:59.58

>>546
カルチュアコンビニエンスクラブ

2020/07/16(木) 04:02:23.42

>>550
イェェェ！！

2020/07/16(木) 09:30:43.69

>>548
イエエエ！

2020/07/16(木) 09:34:53.50

>>548
アイドルぷりぷり

2020/07/16(木) 22:21:03.87

東京が goto キャンペーンから外されて本当に良かった。

◆QZaw55cn4c (NZ 0H42-Hpaz) · 2020/07/16(木) 22:33:48.51

>>555
goto hell キャンペーン？

2020/07/16(木) 23:23:34.12

東京以外は goto を使ったCプログラムで溢れかえるんだろうなあ・・・

2020/07/16(木) 23:59:23.84

すべてのreturnは東京に帰る

2020/07/17(金) 00:08:23.19

exit((int) "TOKYO");

2020/07/17(金) 06:35:08.70

令和のgoto有害説

2020/07/17(金) 08:41:43.61

gotoとラベル

2020/07/17(金) 09:09:08.77

うまいな

2020/07/17(金) 20:54:53.28

くっ。やられた。
私の負けを認めよう。

2020/07/18(土) 12:46:51.82

奥村先生が書いてらっしゃる
「いまさらC言語」
https://scrapbox.io/imasaraC/
って、「初学者がC言語を学ぶ」という目的にはそぐいますか？
偉そうな言い方なんですけど、C言語の基礎を一通りなぞる感じには見えませんでした。
ですが、もしもC言語の基礎をこの記事で勉強できるなら、
奥村先生直筆の日本語文書ですし、ぜひ参考にさせていただきたいのです。

2020/07/18(土) 12:56:27.17

散文っぽくて体系的じゃない感じは受けた
「いまさら」であって「初めての」ではないので文字通り受け取って
既に知ってる人が改めて見直す機会には良いんじゃね

scanf
https://scrapbox.io/imasaraC/scanf()

fgets
https://scrapbox.io/imasaraC/fgets()

2020/07/18(土) 15:06:19.54

>>565
ありがとうございます。
入門書と銘打ってる文書にします。

2020/07/21(火) 00:25:21.83

すっごいポンコツPCでmacでCSV作って作ったの読み込んで計算して表示してって10回ぐらい繰り返したら同じデータ表示されるの？

2020/07/21(火) 00:30:45.40

ポンコツだとたまに計算間違うから無理じゃないかなあ

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdfa-ch6b) · 2020/07/21(火) 00:32:52.06

>>567
本当にポンコツであれば、主メモリーかHDDが壊れている可能性がある。

2020/07/21(火) 00:34:45.78

>>567
なんかこんな環境でやったらCSVのデータが更新されなくて10回全部同じ計算になってるって事が起きたから
やった人はsleepで遅らせたら変化したって言ってたからそんなことが起きる事があるのかって不思議に思ったわ

2020/07/21(火) 01:27:00.90

メモリは思ったより信用できない (ちょいちょい化ける) という話を
何かのウェブブラウザ関連の文章で読んだことがあるような
気がするんだけど思い出せない。

2020/07/21(火) 01:41:36.17

おじいちゃん

2020/07/21(火) 02:56:31.73

簡単に化けるから誤り検出符号なるものが存在している
HDDはもちろんメモリだって物理的に劣化する

2020/07/21(火) 03:18:48.82

https://ja.wikipedia.org/wiki/ECC%E3%83%A1%E3%83%A2%E3%83%AA

2020/07/21(火) 03:19:15.76

ディスクキャッシュでなかったかな。
毎度syncするようなkernelパラメータか何かを与えないと旧データを読み出すような事象が昔あったような。

2020/07/21(火) 08:19:11.51

>>571
DRAMのメモリセルに宇宙線が当たったりね
でサーバー用のメモリにはECCがついてるし
HDDはRAIDで耐障害性設計もする

2020/07/21(火) 17:26:30.39

Ｃ言語を3ヶ月前から勉強し始めたものです。この間、Ｃ言語３級を受験しました。

Ｃ言語かなり難しいです。

苦労しながらＣ言語学んだ方いますか？

2020/07/21(火) 17:28:45.77

はい
なんでしょう

2020/07/21(火) 17:30:55.73

安心しました
がんばります

2020/07/21(火) 17:30:56.37

苦労せずに学んだやつなんているのか？

元々アセンブラ屋でアドレスやポインタが当たり前だった俺でさえ
それなりに脂汗かきながら憶えたぞ

2020/07/21(火) 18:13:57.71

独学で始めたからリンカの使い方とかよく分からず、C のソースを全部 include してたな。

2020/07/21(火) 19:46:32.95

>>581
nanisore. 面白い。詳しく。

2020/07/21(火) 20:00:00.53

多分分割コンパイルのやり方を知らなかった頃の話だろう

2020/07/21(火) 20:10:11.93

>>583
そそ、そういうこと。
んで複数のソースを include するだけのファイルを作って、それのことを makeファイルと言うんだと思ってた。

2020/07/21(火) 22:42:16.68

依存ファイル集める方がよほど知識が要りそう

2020/07/22(水) 15:51:53.55

このコード最適化の余地ある？-O3でやっても1900msとかかかるんだけど

#include <time.h>
#include <stdio.h>
#include <stdlib.h>

int f(int size, int *data1, int *data2) {
int r = 0;
for (int j = 0; j < 100; j++) {
for (int i = 0; i < size; i++) {
r ^= data1[i] & data2[i];
}
}
return r;
}

2020/07/22(水) 15:52:29.23

int main(int argc, char *argv[]) {
int size = 1000 * 1000 * 100;
int *data1 = (int*) malloc(size * sizeof(int));
int *data2 = (int*) malloc(size * sizeof(int));

//setup test data
srand((int) time(NULL));
for (int i = 0; i < size; i++) {
data1[i] = rand();
data2[i] = rand();
}

int sec, millisec;
struct timeb timebuffer;

//start
ftime(&timebuffer);
sec = timebuffer.time;
millisec = timebuffer.millitm;

2020/07/22(水) 15:52:35.64

// benchmark
int r = f(size, data1, data2);

// end
ftime(&timebuffer);
sec = timebuffer.time - sec;
millisec = timebuffer.millitm - millisec;
millisec += sec * 1000;

printf("%d ms \n %d", millisec, r);

free(data1);
free(data2);
}

**デフォルトの名無しさん** (JP 0H55-ZQKC) · 2020/07/22(水) 16:01:48.88

f()で0返せばいいんじゃね？

2020/07/22(水) 16:06:36.57

たしかにrが0になるが
たぶんsrand, randで値の分布が一様じゃないせいか？
Javaとの性能比較してたんだけど乱数生成法が合わせれないな

2020/07/22(水) 16:07:57.00

あ違うなsizeがでかすぎると0になっちゃうのか

2020/07/22(水) 16:11:34.79

Java(VM)とCという言語の比較をしたいのかこのソースを最適化したいのかrandの仕様を統一したいのか意味不明だわ

2020/07/22(水) 16:21:46.25

JavaとCの性能比較で「Javaは高速だCに負けてない」とか
「JITやGCが動作する時に遅くなるだけだ」とか良く言われてる。
でもこういう単純な配列処理でCの方が3倍くらい速いよな、と思って。
この処理は計測中にヒープ割当が無いからGC関係ない（Javaでオブジェクトを作成するとGCのためのオーバーヘッドがあるらしい）。
JavaでJIT効かせてから計測してもCが4倍弱速かった。
最初1900msもかかるといってたのは勘違い。Cの方が4倍弱速いから予想通りの性能だった。

Javaの性能に関する言説を見渡しても、なぜこういう処理でJavaが遅いのか説明が無い。

大量のデータを処理しつつ特定の値に収束しない良いベンチマークコードがあればいいんだが。
足す引きを交互に繰り返すか。

2020/07/22(水) 16:24:26.21

>>586
data1[i] & data2[i] の計算を100回もやることはないから
int f(int size, int *data1, int *data2) {
int *data3 = (int*) malloc(size * sizeof(int));
for (int i = 0; i < size; i++) {
data3[i] = data1[i] & data2[i];
}
int r = 0;
for (int j = 0; j < 100; j++) {
for (int i = 0; i < size; i++) {
r ^= data3[i];
}
}
free(data3);
return r;
}
ってやると多少速くなるかも
あとは分割してスレッドで並行して実行するとかかな

2020/07/22(水) 16:26:57.20

これで収束しないし毎回ランダムな結果になる。

long f(int size, int *data1, int *data2) {
long r = 0;
for (int j = 0; j < 100; j++) {
for (int i = 0; i < size; i++) {
r += data1[i] - data2[i];//ここ変えた
}
}
return r;
}

**デフォルトの名無しさん** (JP 0H55-ZQKC) · 2020/07/22(水) 16:34:17.16

なんだ、^ の意味わかってなかったのか。
ていうか、コードの最適化を求めるなら、
そのコードの目的のほうが先に存在するはずじゃないのか？
コロコロ変えてさあ最適化しろとかおかしいだろ。

2020/07/22(水) 16:39:25.22

0になってたのは^じゃなくて&が原因だろ

**デフォルトの名無しさん** (JP 0H55-ZQKC) · 2020/07/22(水) 16:42:01.87

^ だよ
最後のやつで + を ^ にしたらどうなる？

2020/07/22(水) 16:44:20.78

あr=0でr^=使ってたからか
演算子の意味じゃなくてr=0で始めてる事との整合性に気付いてなかった
r = rand();
r ^= data1[i] ^ data2[i]
これなら収束しないはず

**デフォルトの名無しさん** (JP 0H55-ZQKC) · 2020/07/22(水) 16:46:16.22

それ、最初の rand の値が返るだけだから。

2020/07/22(水) 16:56:43.54

もしかして残念なベンチ

**デフォルトの名無しさん** (JP 0H55-ZQKC) · 2020/07/22(水) 17:05:53.92

目的の明確でないベンチマーク作っても無駄だよね。
何を調べたいの？

2020/07/22(水) 17:19:08.68

> この処理は計測中にヒープ割当が無い
って書いてあるけどガッツリ malloc してるし本当に何がしたいのか良く分からない

2020/07/22(水) 17:34:24.16

全ての値を偶数回^すれば答えは0になって当然

2020/07/22(水) 17:58:11.98

>>600
なんで代入されないんだ？

>>602
>>593
>こういう単純な配列処理でCの方が3倍くらい速い

>>603
「計測中に」はstartとendの間にという意味。

2020/07/22(水) 17:59:58.58

>>586
大いに改善の余地あり
0になることを仮定せずに真面目に計算するとして

データがメモリがキャッシュに入るとすると
計算の依存関係ありまくりだから
ほぼレイテンシ待ちになる

ループ4周を展開して
rを4個に分けるだけで速くなりそう

SIMD命令が使えるなら
非常に効果がある形なので
使えるなら使う
この場合も演算の依存関係は減らすこと

データがキャッシュに収まらないなら
メモリ速度で決まるからあまり関係ない

2020/07/22(水) 18:03:43.69

代入されないんじゃなくて偶数回^すると元に戻るのか

2020/07/22(水) 18:04:59.81

>>605
> なんで代入されないんだ？

代入はされているが、100が偶数だから >>604 の言うように0に戻ってるだけ。

2020/07/22(水) 18:09:25.81

二重ループにして外側が偶数回だからか。
「同じ乱数列を偶数回XOR走らせたら元に戻る」と。
>>600や>>604が言ってるのはそういうことか

勉強になった

2020/07/22(水) 18:12:28.77

あーじゃあr=0で始めてたことは関係無くて、
単に二重ループの外側が偶数回だと無意味だと。
r=0で始めてもXORならちゃんとビット列変わってたけどXORの性質から元に戻ってたと。
コンパイラがそれ知ってたら最適化して処理消しちゃうから良くないな。
XORのその性質を知らなかった

2020/07/22(水) 18:26:49.94

より正しく述べておこう
・1回でも101回でも同じ結果なのでXOR版では二重ループの外側が無意味
・data1, data2がどんな数列でもXORの性質は同様にある

ID:lGyqioywHとID:YNla03BQMはこれを言ってたんだな

2020/07/22(水) 18:26:50.13

より正しく述べておこう
・1回でも101回でも同じ結果なのでXOR版では二重ループの外側が無意味
・data1, data2がどんな数列でもXORの性質は同様にある

ID:lGyqioywHとID:YNla03BQMはこれを言ってたんだな

2020/07/22(水) 19:03:36.52

かようにベンチマークっていうのは難しいんだ。
CPUの比較をするだけでもいろんな提案があって
SPECとかはなんとか信頼されているが、
言語間の性能比較とか素人が適当にでっち上げても、
そのプログラムが悪いだけじゃねってなるのがオチ。

2020/07/22(水) 21:28:34.34

最終的に 0 になるだろけど、この計算は愚直に行われるんでしょ。
答えが 0 にしかならないことと C と Java の速度差がそうなることとはまた別の話だよね。

って、コードの最適化の話だったんだっけ？

2020/07/22(水) 22:22:42.43

Cがこの処理でJavaより3～4倍速い事は確認できた。
0に収束する事とそれは無関係。

以下、一応書くけど完全にスレ違い。

このような単純な配列処理でCとJavaの速度差がなぜ生じるか？はまだ分かってない。
・HotSpotは配列の境界チェックを除去できる
・一般論としてJavaが遅くなる原因としてJITやGCが挙げられるがこの単純なプログラムではそれらの影響はない

予想
・1命令で処理できるサイズが違っている？約4倍の速度差はベクトル演算の差で説明できそう。
だとしたらなぜJavaのJITはそれをやらないか？
・CPUキャッシュの問題？Javaの場合CPUキャッシュが別の何かで埋まってしまっている可能性

2020/07/22(水) 22:30:57.82

自分のブログでやって

2020/07/22(水) 23:08:24.67

そもそもjavaがc/c++並に速いとか、かなり嘘や誤魔化し入っているから
速度差3-4倍で済むなら十分健闘している

javaのコードを移植して、無駄にmalloc freeしまくったりする糞コードならもっと迫れるだろうけど

2020/07/23(木) 02:25:27.91

>>615
そもそもJITが吐くバイナリを逆アセンブルして比較しなきゃしょうがないんでね？
そのようなことが可能かは知らないけど、処理中にデバッガで無理矢理止めればわかりそうな気はする

2020/07/23(木) 04:09:18.13

最初の>>586の問いがベンチマークを意図してるとは思われてなかったから{return 0;}で良いんじゃね？ってなったんでは

2020/07/23(木) 11:21:03.05

javaの配列は特別な宣言無しに別スレッドでこっそり書き換えてもちゃんと反映されるわけだから、単純処理であっても最適化にも限界があるだろうな。
Cの場合は、他で書き換えられるかもと指定しておかなければ他所のことなんておかまいなしに処理できるから、その点だけでも有利だよね。
>>586 のコードのなら、i のループに入る前に data[j] を変数に取り置いて i のループ内で使用するようにすれば、java の方では高速化されるんじゃね。
C ならそれをコンパイラがやってくれてそう。

2020/07/23(木) 11:24:21.68

逆にCの側で配列を volatile にしておけば Java との速度差は小さくなるかもね。

2020/07/23(木) 11:26:24.50

data[j]なんかないけど

2020/07/23(木) 11:46:46.14

じゃあjava.util.concurrent.atomic以下にある配列クラスは全部廃止だな

2020/07/23(木) 12:46:54.76

ベクトル演算の未適用が原因だとほぼ特定できた。

2020/07/23(木) 13:17:22.41

>>587
巨大サイズメモリで簡単な演算だから
ほとんどがメモリアクセス時間だろ

2020/07/23(木) 13:19:58.21

簡単な処理のために巨大メモリをスキャンするのは超無駄

2020/07/23(木) 13:51:39.59

C版
size
1000*1000 * 1 20ms
1000*1000 * 10 191ms
1000*1000 * 100 1893ms
線形な変化だからCPUキャッシュに載り切るかで性能が分かれるという事が生じてない。
たぶんCPUキャッシュは「繰り返し使うデータ」じゃないと有意義じゃない。
この処理だとCPUキャッシュ上のデータを排除可能になるまでの時間がボトルネックで、
つまり「CPU上のデータを処理しきって次の要素を受け付けれるようになるまでの時間」が支配的なはずで
そこがベクトル演算で高速化してる。

Java版も線形に変化した。

で、Javaのコードでr += data1[i] + data2[i]のところでdata1のみにしたら２倍速になったからベクトル演算未適用が原因でほぼ間違いない。
その行で+か-か^か&かは結論に影響しない。

2020/07/23(木) 13:55:19.10

>>622
ほんとだw
data1 か data2 かは置いといてもどっちも i を添字とするループか。
マトリクス状に組み合わせてるんだと錯覚してたすまん

2020/07/23(木) 14:11:44.83

>>623
値が volatile なことと操作が atomic なことは別の話だよ。
自分が書き換えない同じ領域を複数参照するとき、それを他の誰も書き換えないならその参照は一度目の値と同じになる前提で最適化できるけど、他の誰かがいつの間にか書き換えることがあるならそういう最適化はできなくなる。
そういう領域であることを明示するのが volatile。
atomic は同じ領域を誰かが書き換える前提なので基本的にその領域は volatile だけど、それに加えて値を参照して手を加えて書き戻すなどの一連の手続きの途中で他の誰かにいじられないことを保証すること。
それを CPUレベルの命令で行うかソフトウェア的なロックで行うかで色分けされてるだけ。

2020/07/23(木) 14:28:36.26

>>627
CPUは何？

2020/07/23(木) 14:33:33.27

メモリアクセスの影響がないなら

iとjのループを入れ換える
ループアンロール
rを偶数奇数で分ける
SIMD

などが有効

2020/07/23(木) 14:36:26.08

>>627
同じメモリに100回アクセスしてるんだから
メモリサイズが小さければキャッシュが効くはず

2020/07/23(木) 14:42:55.39

>>632
確かにそうだ。
でも1000 * 100も試してみたが2msで線形だった。

2020/07/23(木) 14:44:16.58

CPUは何？

2020/07/23(木) 16:21:21.26

>>629
別スレッドからの値の書き換えについて話をしていたよね？
だったらvolatileは何も保証してくれないよ

2020/07/23(木) 16:39:16.32

>>635
保証ってなんの話？

2020/07/23(木) 20:41:12.28

>>629
分かってると思うけど誤解なきよう勝手に補足するけどvolatileの最適化抑制はreadだけではなくてwriteに対してもな。
ドライバ書いてる人には常識レベルだけど。

2020/07/24(金) 03:10:38.82

volatile ってスレッドに限らず値が知らない内に変化する可能性のある何かの入力でも使うよね。
例えばマイクから拾った音を A/D 変換した値がメモリマップドI/Oで特定のアドレスのメモリ読む方法で読める場合。
CPUが予想不能な形で値がコロコロ変わるので volatile にせざるを得ない。(volatile って揮発性とか不安定って意味だし、言葉の意味そのままだ)。
これは読む側だけど書いて何かを出力する場合も、書いた値を読めないような作りになっている場合もある。
1を書いたのに直後に読むと0だったりなんていう事はあり得る。要するに一々覚えていない。または覚えていても読み出しに対応していない。
そんなハードウェアが接続されていたらそうなる。

2020/07/24(金) 04:44:18.69

そりゃ、外部装置と連動しているから、値がいつ変わるか分からない

外部装置が読み書きしたら、合図として、0.1ms 後に、値を反転させたりとか、
色んな事をするから、予測できない

2020/07/24(金) 09:33:19.23

volatileは変数(I/Oアドレス)に対するアクセス行為は保障するけど値そのものに対しては何の意味もない
そもそも外部要因で変化する値に対して干渉するのは不可能

2020/07/24(金) 10:20:02.92

どこから干渉するとか出てきたんだ…
知ってる知識を開陳したくてしょうがないんだろうなw

2020/07/24(金) 15:22:34.69

volatileな変数を読むのは怖いよね
ワード単位ならいいけど、構造体読むときはチェックサム欲しくなるよね

2020/07/24(金) 18:25:04.01

別に怖くはないだろ。
他所と排他するなりしかるべきタイミングでアクセスすればいいだけなんだから。
排他や同期が必要な領域にそれをせずにアクセスするならただのアホってだけで、volatile がどうとかいう話じゃない。

2020/07/24(金) 20:10:16.16

LL/SC命令が結構使える

2020/07/25(土) 04:21:09.10

>>642
それはatomicとかクリティカルセクションの話であって
volatileで何とかしようという発想がそもそも間違いだ

2020/07/26(日) 03:07:46.88

「書きこんだものの読み込んでないからコードから消しちまえ」
「読み込んでるけど、代入以降値がかわる気配がないから、読み込みを止めて固定値にしちまえ」
これを抑制するだけ
書き込や読み込みを記述通り生き残らせる

2020/07/26(日) 08:34:28.91

W=>R : R省略
R1=>R2 : R2省略
W1=>W2 : W1省略

2020/07/26(日) 10:41:35.23

volatile覚えて嬉しいのはわかるけど…