「CPUにDRAMダイまで統合される時代に突入か」記事へのコメント

IOが解決するとメモリがネックになるしね

[Anonymous Coward]

昔、ある目的のために機能を限定したwebサーバを作ったんですよ。
それで、データのほとんどはキャッシュにひっかかるような構造にしたんですよ。
そんで、プロファイラとってみたら memcpy が一番時間数かかっていたりしたからなー。

IOを減らすとかだったらキャッシュすればいいんだろうけど、memcpy が一番遅いって言われたらもうどうすることもできないという。
これ以上は無理、、って思ったもんです。

Re:IOが解決するとメモリがネックになるしね

[Anonymous Coward]

検索してみたらgcc内蔵のmemcpyより三倍速い [hatena.ne.jp]とかって記事が

Re:memcpy()は汎用だから遅いですよ

[kmra (33703)]

memcpy()は汎用だから遅いですよ
転送元・転送先のバイトアライン関係ないし
転送サイズが大きいのか短いのかもわからないし

そういうのを最初に判定するmemcpy()もありますが、そういうのは判定の分のオーバーヘッドが転送サイズが小さい時に出てきてしまいます。

memcpy()をもう少し細分化したものを作ったらよいのかもしれません
速度がいるときはみんなその場でガシガシ作ってしまってるようです

Re:

[Anonymous Coward]

いちおう転送元と転送先が重複している可能性があるとき用にmemmoveが存在しますが、VC9ではmemcpyもmemmoveと同じ実装になってしまったようですね。汎用関数で無意味に速度を追求しても仕方ないという考えなのかもしれません。

Re:memcpy()は汎用だから遅いですよ

[Tsann (15931)]

確認しましたが、VC9のmemcpy()とmemmove()は別実装でしたよ。
ただしコンパイラはこの実装を使わずインライン展開できますので、その際にはオーバーラップしているか、アラインメントなど推測可能なら省略してしまうのでしょう。