東方算程譚

Oriental Code Talk ── επιστημηが与太をこく、弾幕とは無縁のシロモノ。

目次

Blog 利用状況

ニュース

著作とお薦めの品々は

著作とお薦めの品々は
東方熱帯林へ。

あわせて読みたい

わんくま

  1. 東京勉強会#2
    C++/CLI カクテル・レシピ
  2. 東京勉強会#3
    template vs. generics
  3. 大阪勉強会#6
    C++むかしばなし
  4. 東京勉強会#7
    C++むかしばなし
  5. 東京勉強会#8
    STL/CLRによるGeneric Programming
  6. TechEd 2007 @YOKOHAMA
    C++・C++/CLI・C# 適材適所
  7. 東京勉強会#14
    Making of BOF
  8. 東京勉強会#15
    状態遷移
  9. 名古屋勉強会#2
    WinUnit - お気楽お手軽UnitTest

CodeZine

  1. Cで実現する「ぷちオブジェクト指向」
  2. CUnitによるテスト駆動開発
  3. SQLiteで組み込みDB体験(2007年版)
  4. C++/CLIによるCライブラリの.NET化
  5. C# 1.1からC# 3.0まで~言語仕様の進化
  6. BoostでC++0xのライブラリ「TR1」を先取りしよう (1)
  7. BoostでC++0xのライブラリ「TR1」を先取りしよう (2)
  8. BoostでC++0xのライブラリ「TR1」を先取りしよう (3)
  9. BoostでC++0xのライブラリ「TR1」を先取りしよう (4)
  10. BoostでC++0xのライブラリ「TR1」を先取りしよう (5)
  11. C/C++に対応した、もうひとつのUnitTestFramework ─ WinUnit
  12. SQLiteで"おこづかいちょう"
  13. STL/CLRツアーガイド
  14. マージ・ソート : 巨大データのソート法
  15. ヒープソートのアルゴリズム
  16. C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す
  17. .NETでマンデルブロ集合を描く
  18. .NETでマンデルブロ集合を描く(後日談)
  19. C++/CLI : とある文字列の相互変換(コンバージョン)
  20. インテルTBBによる選択ソートの高速化
  21. インテルTBB3.0 によるパイプライン処理
  22. Visual C++ 2010に追加されたSTLアルゴリズム
  23. Visual C++ 2010に追加されたSTLコンテナ「forward_list」
  24. shared_ptrによるObserverパターンの実装
  25. .NETでマンデルブロ集合を描く(番外編) ── OpenCLで超並列コンピューティング
  26. StateパターンでCSVを読む
  27. 状態遷移表からStateパターンを自動生成する
  28. 「ソートも、サーチも、あるんだよ」~標準C++ライブラリにみるアルゴリズムの面白さ
  29. インテルTBBの同期メカニズム
  30. なぜsetを使っちゃいけないの?
  31. WPFアプリケーションで腕試し ~C++でもWPFアプリを
  32. C++11 : スレッド・ライブラリひとめぐり
  33. Google製のC++ Unit Test Framework「Google Test」を使ってみる
  34. メールでデータベースを更新するココロミ
  35. Visitorパターンで遊んでみたよ
  36. Collection 2題:「WPFにバインドできる辞書」と「重複を許す検索set」
  37. Visual C++ 2012:stateless-lambdaとSQLiteのぷち拡張
  38. 「Visual C++ Compiler November 2012 CTP」で追加された6つの新機能

@IT

  1. Vista時代のVisual C++の流儀(前編)Vista到来。既存C/C++資産の.NET化を始めよう!
  2. Vista時代のVisual C++の流儀(中編)MFCから.NETへの実践的移行計画
  3. Vista時代のVisual C++の流儀(後編) STL/CLRによるDocument/Viewアーキテクチャ
  4. C++開発者のための単体テスト入門 第1回 C++開発者の皆さん。テスト、ちゃんとしていますか?
  5. C++開発者のための単体テスト入門 第2回 C++アプリケーションの効率的なテスト手法(CppUnit編)
  6. C++開発者のための単体テスト入門 第3回 C++アプリケーションの効率的なテスト手法(NUnit編)

AWARDS


Microsoft MVP
for Visual Developer - Visual C++


Wankuma MVP
for いぢわる C++


Nyantora MVP
for こくまろ中国茶

Xbox

Links

記事カテゴリ

書庫

日記カテゴリ

わすれもので(ちょびっと)高速化

Visual C++ 2010に追加されたSTLアルゴリズム@CodeZine で忘れてたのがありました。

■ minmax_element
template<class Iterator, class Predicate>
std::pair<Iterator,Iterator>
  minmax_element(Iterator first, Iterator last, Predicate pred);

シーケンス[first,last)から、最初に見つけた最小要素 と 最後に見つけた最大要素 を指すイテレータをペアにして返します。

最小/最大要素を見つけてくれるアルゴリズムはそれぞれmin_element/max_elementがあるんだけど、minmax_elementはそいつらの合わせ技
大きなメリットはmin_element,max_elementを一度ずつ呼び出すより速いす。要素数Nに対し3/2N程度だそうで、前者の2Nに比べて25%ほどの時短となるます。

コレ使って単純選択ソートをちょびっと速くします。単純選択ソートのアルゴリズムはめっちゃ単純:
「i=0..N-1に対し、data[i]~data[N-1]中の最少要素とdata[i]を交換する」こんだけ。コード書けば:

while ( first != last ) {
  iter_swap(first, min_element(first,last));
  ++first;
}

loop回るたんびに未ソートな要素がいっこずつ減ってくんだから、minmax_elementならふたっつずつ減ってくれんでないのん?  と。

ってなわけで書いてみた。ソート対象は挿入/削除がチョー速いlist<T>で。


#include <iostream>
#include <array>
#include <list>
#include <algorithm>
#include <numeric>
#include <cassert>
#include <windows.h>
using namespace std;
// フツーの単純選択ソート
DWORD min_selection_sort(list<int>& data) {
  DWORD t = GetTickCount();
  for ( auto first = data.begin(); first != data.end(); ++first ) {
    iter_swap(first,min_element(first,data.end()));
  }
  return GetTickCount() - t;
}
// ヒネクレた単純選択ソート
DWORD minmax_selection_sort(list<int>& data) {
  DWORD t = GetTickCount();
  list<int> smaller, bigger;
  while ( !data.empty() ) {
    auto mm_pair = minmax_element(data.begin(),data.end());
    smaller.splice(smaller.end(), data, mm_pair.first);
    if ( mm_pair.first != mm_pair.second ) {
      bigger.splice(bigger.begin(), data, mm_pair.second);
    }
  }
  data.splice(data.begin(),bigger);
  data.splice(data.begin(),smaller);
  return GetTickCount() - t;
}
int main() {
  const int N = 20000;
  array<int,N> src;
  iota(src.begin(),src.end(),0);
  random_shuffle(src.begin(),src.end());
  DWORD t;
  list<int> data;
  data.assign(src.begin(),src.end());
  t = min_selection_sort(data);
  assert( is_sorted(data.begin(), data.end()));
  cout << t << endl;
  data.assign(src.begin(),src.end());
  t = minmax_selection_sort(data);
  assert( is_sorted(data.begin(), data.end()));
  cout << t << endl;
}

実行結果:
1092 (min_selection)
967 (minmax_selection)

一割ちょいかー、けっこーややこしくなってっから、こんなもんかなー
もっとエレガントな実装がありそな希ガス。

投稿日時 : 2010年6月23日 21:39

コメントを追加

# re: わすれもので(ちょびっと)高速化 2010/06/25 12:54 Chiharu

359 (min_selection)
421 (minmax_selection)
Core i7 の結果ですが、minmax_selection の方が遅い結果に。環境によってこうも速度傾向が変わるものなんでしょうか。

# re: わすれもので(ちょびっと)高速化 2010/06/25 17:28 Chiharu

359 (min_selection)
421 (minmax_selection)
343 (minmax_selection2) ← ソート対象をそのまま書き換え。
同じく Core i7 の結果ですが、集合の別途作成などしなければ、多少速くなるようです。コードはうちのサイトのトップに貼ってみました。
(ブログやってないので、トラックバックとかできない...

# re: わすれもので(ちょびっと)高速化 2010/06/25 22:29 επιστημη

ありがとございますー。

ウチとこでやると
selectionとselection2にほとんど差がないのですよぅ。

# re: わすれもので(ちょびっと)高速化 2010/06/25 22:51 Chiharu

んー。やっぱりその手の速度傾向ですね。

自作のエンジンで、高速化した処理が Pentium M, Core 2 で効果がなく、Atom, Core i7 でだけ効果があるケースが多くて、結構困ります。ここ最近、アーキテクチャの相違によって、ボトルネックが変わってきてるのかも。根拠はありませんが、なんとなく、CPU 1 コアあたりに対してメモリが速くなってきているような。

# re: わすれもので(ちょびっと)高速化 2010/06/25 23:37 επιστημη

僕とこは Athlon 64 X2 4400+、
L1:64Kx2, L2:1024Kx2
Core i7だとL3:8M 持ってっからより広範囲のメモリをキャッシュ内でアクセスできっから...なの?

# re: わすれもので(ちょびっと)高速化 2010/06/26 8:35 Chiharu

私が経験しているのは、ソート処理ではなくて画像処理なんですけれど、Core 2 以前の CPU だと、画素あたりの命令数を減らしていくと、ある程度のところで速度が頭打ちになるところが、Core i7 だと結構、青天井で伸びて行きます。なのでメモリのアクセス速度が速くなってきているのかなー、と。

メモリコントローラの内蔵や、L1 と低速 L2 の間に高速 L2 用意したり、ハードウェア プリフェッチが強化されたりで、Core i7 のメモリアクセスが旧来のアーキテクチャよりは速くなっていると思うのですが、Athlon 比はどうなんでしょ。

んー。Athlon は Intel に先立ってメモリコントローラ内蔵していたはずだし、今回のプログラムに関して言えば、L2 に収まっているハズだし。

根拠がないなので、解もありませんが、そんな感じのこと考えてました。別の可能性で、x86 デコーダの改良で各命令のレイテンシが変わってきている可能性もありますけれど。…、あ。Core i7 は局所ループがあると、キャッシュされたデコード済みマイクロ コードを実行しますね。んー。今回のコードで、それにハマルものがあるのかわかりませんけれど。

…と、思わせぶりなコメントの割に、答えの出ないコメントですみません。そんなこと、考えてました、程度のことです。

# re: わすれもので(ちょびっと)高速化 2010/06/26 8:40 Chiharu

>L2 に収まっているハズだし。
あ。リストなんで、アロケータ次第で、必ずしも L2 に収まるか分からないですね。
(80kB の実体しか持たないリストが 1024kB を超える可能性なんて想像したくもないですけれど…

# wzdNJHPBRpRsO 2021/07/03 4:50 https://www.blogger.com/profile/060647091882378654

You made some respectable factors there. I regarded on the web for the issue and found most individuals will go along with together with your website.

タイトル
名前
URL
コメント