> We didn't beat GNU's yes, and there probably is no way. Even with the function overheads and additional bounds checks of GNU's yes, the limit isn't the processor, it's how fast memory is. With DDR3-1600, it should be 11.97 GiB/s (12.8 GB/s), where is the missing 1.5? Can we get it back with assembly?
> Even with the function overheads and additional bounds checks of GNU's yes, the limit isn't the processor, it's how fast memory is. With DDR3-1600, it should be 11.97 GiB/s (12.8 GB/s),
yes! (スコア:0)
yesコマンドなんて最初は「何だこれ？」と思ったけど
最近はPC起動するたびに使ってる気がする
何かと手間が省けるんだよね
地味ｲーーにものぐさができる
Re: (スコア:0)
初期のUNIXのシンプルさ、柔軟さを今に伝える貴重なプログラム。
...なのだが、GNU 版のソースとかを見るとロブ・パイクがUNIXは腐臭を放っていると発言したのも最もだと思わせる。
Re: (スコア:0)
でも例えばprintfを改良してどうにかなる問題じゃないからな。ループで問答する時のバッファをどうするかって話なんだから、まさにアルゴリズムの優劣が結果にダイレクトに反映されてるわけだ。
Re:yes! (スコア:2)
アルゴリズムとは言い難い感じ。
一行ずつチマチマ投げるよりも、ページ境界に合うのを期待した大きい領域に何行も詰め込んで投げる方が早いよねっていう。
Re: (スコア:0)
> 一行ずつチマチマ投げるよりも、ページ境界に合うのを期待した大きい領域に何行も詰め込んで投げる方が早いよねっていう。
なんで後者の方が早いんですか？
Re: (スコア:0)
境界またがったら2ページ分の操作が要るとか
というか、パディング分の領域が無駄になるとか
再構成の時間がかかるとか
いろいろ
Re:yes! (スコア:3, 参考になる)
一番の理由はシステムコールのオーバヘッドですよ
一行ずつチマチマ投げるとその都度システムコールが発行されます
これが結構重たい処理になります．システムコールが発行されると，その都度，ユーザ空間とカーネル空間の切り替え，
CPUのレジスタの保存と復帰，メモリキャッシュのフラッシュが必要になります
またCPUのパイプラインもストールします．
ですからこの手の高速化では
システムコールの発行回数を最低限に抑える工夫が必須となります
その工夫の一つが，大きなバッファを用意して，複数回のシステムコールを，一つにまとめる方法です
Re:yes! (スコア:2)
printf(3)はシステムコールじゃないってのは余計な突込み？
stdioライブラリ中のバッファ処理より高速なんだろう
♯改行くるとwrite(2)してるとか
ページサイズかける文字数分の境界整列したバッファを用意しといて
埋めた後グルグル回すとか
#writeに渡した後の中身って保全されてると期待しちゃいかんのじゃなかったかな
Re: (スコア:0)
まさにアルゴリズムだと思うのだが…
単純というだけでアルゴリズムに変わりはないでしょ。
Re:yes! (スコア:1)
自分の理解ではこういうのはI/Oの効率化で、アルゴリズムというよりストラテジ
アルゴリズムはもっとロジック寄りの処理を指すと思ってる
うじゃうじゃ
Re: (スコア:0)
ストラテジーよりはタクティクスかな…
Re: (スコア:0)
「アルゴリズム上の工夫とは言いがたい」と言いたいのでは
Re: (スコア:0)
unixのというよりオープンソースの話だろう。いやプロプラでも見えないだけで実はくだらないところで最適化を頑張っているのかもしれないが。
Re: (スコア:0)
> We didn't beat GNU's yes, and there probably is no way. Even with the function overheads and additional bounds checks of GNU's yes, the limit isn't the processor, it's how fast memory is. With DDR3-1600, it should be 11.97 GiB/s (12.8 GB/s), where is the missing 1.5? Can we get it back with assembly?
yyyyyyyを毎回メインメモリから読み出していると考えているようだが、3次キャッシュには乗ってんじゃねーの？
L3のバンド幅は俺は知らんが、とりあえずこいつの認識は間違ってるかもしれんぞ
Re: (スコア:0)
つか、yesのwriteでユーザー空間からyyyyyyを読んでシステム空間のパイプのバッファに書く、pvはパイプのバッファからyyyyyを読む、で都合3回メモリアクセスするよな
Re: (スコア:0)
ほらみろ、やっぱりunix界隈は糞じゃないか
Re: (スコア:0)
おっと、pvは/dev/nullにリダイレクトしてるのか
じゃあpvはreadでシステム空間(パイプ)から読んでpvのユーザー空間に書くところまではやるのかな
そうするとyyyyyyあたり4回の読み書きか
なんにせよメインメモリのバンド幅は関係ないし、ページサイズがどうのというのも見当はずれじゃねの
Re: (スコア:0)
キャッシュに載せないまたは明示的にキャッシュに載るよう明示的に記述しない限りキャッシュに載るかどうかは運によるのでは。
まあ「yes」くらいなら現代的なプロセッサの場合キャッシュに載ると思うが。
Re: (スコア:0)
> Even with the function overheads and additional bounds checks of GNU's yes, the limit isn't the processor, it's how fast memory is. With DDR3-1600, it should be 11.97 GiB/s (12.8 GB/s),
この分析が的外れだといっているのに、またuni糞がわいてきた
Re: (スコア:0)
> 都合3回メモリアクセス
> 4回の読み書き
readもwriteもブロッキングI/Oモードでシステムコールできる。さらに対象はパイプ。
なのでreadでブロック中にwriteした場合、バッファに書かず直接コピーも出来る。
その場合、メモリアクセスとしては2回。可能な条件は限られるしそう実装されてるかは知らない。
でもFreeBSDのパイプのコードでそんな感じの処理を見たような気がするしLinuxにもありそう。
Re: (スコア:0)
標準ライブラリ使えば1行で終わることを、最適化と称して10行以上もかけて
書いたあげく、最近の（といってもこの20年近く?）のPC用CPUでは却って
遅くなるようなことをやっている同僚には消えてもらいたい。