メニュー
ブログ更新履歴
コンテンツ更新履歴
リンク
  • Magome
  • クラウドベースのMIDIシーケンサ
    音楽制作に興味のある方を対象に、スタンドアロンでも使え、ネットならではの面白さも兼ね備えた音楽制作アプリの提供を目指しています。
twitter
  1. 技術系備忘録​/C++​/OpenSSL​/ビルド方法 (59d)
    • 2018-02-25 (日) 00:27:12 by takatsuka 差分
        • c:\openssl\openssl-1.1.0g   ←解凍したファイル一式
        • c:\openssl\x86     ←出来上がり先
  2. 技術系備忘録​/C++​/Boost​/boost.formatを使った文字列フォーマット。printf系関数を置き換え (72d)
    • 2018-02-12 (月) 01:13:17 by takatsuka 差分
      	std::wstring ws0 = String::Format( L"BNR%d RB%dDE%s", 32, 26, L"TT" );			// ws0 = L"BNR32 RB26DETT"  std::wstring も可です
  3. 技術系備忘録​/AWS​/EC2 AmazonLinuxにSWAPを設定 (103d)
    • 2018-01-11 (木) 10:03:04 by takatsuka 差分

      #prettify{{

  4. 技術系備忘録​/AWS (103d)
    • 2018-01-11 (木) 09:42:31 by takatsuka 差分

      が、AWS も日々進歩変更されてるので、すでに古い情報となってるかもしれません。そんな場合にはご指摘頂ければ幸いです。

  5. 技術系備忘録​/C++​/Boost​/インストール手順 (154d)
    • 2017-11-21 (火) 14:00:08 by takatsuka 差分
      export CPLUS_INCLUDE_PATH=$CPLUS_INCLUDE_PATH:$HOME/boost_1_60_0/include
      export LIBRARY_PATH=$LIBRARY_PATH:$HOME/boost_1_60_0/lib
  6. 技術系備忘録​/C++​/Boost (181d)
  7. 技術系備忘録​/C++​/VisualStudio (181d)
  8. 技術系備忘録​/C++​/Boost​/boost.asioコルーチン内で表コンテキストの処理を行う (181d)
    • 2017-10-25 (水) 09:59:24 by takatsuka 差分

      スタックフルコルーチンはとても便利なんですが、コルーチン内で実行するには都合が悪いコードもあるかなと思います。
      そんなとき、表コンテキスト(って言うのだろうか。通常スタックの状態のこと。)で処理をさせて結果を得るっていうことを、同期処理っぽく書くやり方を、忘れる自信があるので備忘録です。

  9. RecentDeleted (181d)
    • 2017-10-25 (水) 09:55:11 by takatsuka 差分
      • 2017-10-25 (水) 09:55:11 - 技術系備忘録​/C++​/boost.asio​/コルーチン内から表コンテキストでの処理を行う
  10. 技術系備忘録​/C++​/VisualStudio​/デバッガでstd.stringをUTF-8で表示 (189d)
    • 2017-10-17 (火) 10:14:50 by takatsuka 差分

      VisualStudio2015 の場合 anchor.png

      Page Top

      インストールされたファイルを直接編集することに抵抗があるケースもあると思いますの、そんな場合はユーザーフォルダを使う方法のほうが良いかもです。 anchor.png

  11. 会社案内 (400d)
    • 2017-03-20 (月) 21:31:38 by takatsuka 差分
      所在地〒330-0854
      埼玉県さいたま市大宮区桜木町4-900-1 桜木サンワビル2F
  12. 技術系備忘録​/C++​/templateクラスの中のtemplateクラスの書き方 (566d)
    • 2016-10-05 (水) 22:37:59 by takatsuka 差分

      というわけで、template クラスの中の template クラスの static 変数の実体や関数の中身を別に記述するとき、どうやって書くんだったっけ・・と悩んだ時のためにリファレンスコードとして残しておきます。

      以上、だいぶ以前に書いたブログの記事を引っ張ってきました。

  13. 技術系備忘録​/TypeScript​/VisualStudioでのフロントエンド開発環境 React導入 (579d)
    • 2016-09-22 (木) 20:23:03 by takatsuka 差分
      • 今時点の TypeScript2.0 はまだベータ版(RCなのかな?)ですが、そこは気にせず TypeScript 2.0.2 Beta for Visual Studio 2015 という plugin を使っています。
  14. 技術系備忘録​/TypeScript​/VisualStudioでのフロントエンド開発環境 (591d)
    • 2016-09-10 (土) 14:04:26 by takatsuka 差分

      TypeScript 1.8 では標準で結合機能があるので、webpack 等を使わなくても結合は出来るのですが、プロジェクトの全ファイルを1つにしてしまうようで、あんまり使い勝手がよくありません。それに実は、ブラウザではそのファイルをそのままでは動かせなかったりと、自分としてはイマイチだなーと思ってました。

  15. 技術系備忘録​/TypeScript (608d)
  16. 技術系備忘録​/TypeScript​/メンバ関数ポインタ (608d)
    • 2016-08-24 (水) 18:44:55 by takatsuka 差分
      		let s : string = `UserNo:${userNo} `;
      			let t = table[key].call( users[userNo], 99 );	// オブジェクト.call() で第1引数に this となるオブジェクトを指定。第2引数以降に関数の引数を指定。
      			s += `${key}は${t}。`;
  17. 技術系備忘録​/C++​/staticメンバ変数を持つクラスをヘッダファイルのみで実現 (644d)
    • 2016-07-19 (火) 17:38:42 by takatsuka 差分

      static メンバ変数を持ったクラスは、static 変数の実体を記述する為、cpp ファイル(ソースファイル)が必要になってしまいがちです。
      おそらく、普通に書くとこんな感じ↑になると思います。

  18. 技術系備忘録​/FreeNAS​/レプリケーション (692d)
    • 2016-06-01 (水) 22:30:00 by takatsuka 差分
        1. 送信先 FreeNAS にボリュームを作成しておきます。
  19. 技術系備忘録​/FreeNAS (692d)
  20. 技術系備忘録​/C++​/VisualStudio​/メモリリークの調べ方 (726d)
    • 2016-04-29 (金) 01:02:16 by takatsuka 差分

      こんな感じで出たら、{155}ってのがアロケートしたカウントなので、まずこの値を覚えておきます。

  21. 技術系備忘録​/PHP​/二分探索(binary search) (733d)
    • 2016-04-21 (木) 15:37:58 by takatsuka 差分
      • 配列内に同じ値(要素)がダブって存在していても、正しくソートされている配列であれば正常に動作します。
  22. 技術系備忘録​/NetBeans (733d)
  23. 技術系備忘録​/NetBeans​/小技 (733d)
  24. 技術系備忘録​/PHP​/準備不要のテンプレートエンジン (736d)
    • 2016-04-18 (月) 22:31:27 by takatsuka 差分
      • (↑こういうときに PHP のヒアドキュメントは色分けが正しくされなくて見にくくなってしまいますがご了承下さい)
  25. 技術系備忘録​/PHP​/CentOS7(or6)にPHP5.6をインストール (739d)
    • 2016-04-15 (金) 16:48:25 by takatsuka 差分

      php-pecl-redis php-pecl-xdebug php-opcache php-pecl-apcu とか

  26. 技術系備忘録​/PHP (740d)
  27. 技術系備忘録​/PHP​/小技 (740d)
  28. 技術系備忘録​/Bootstrap (747d)
  29. 技術系備忘録​/Bootstrap​/アコーディオン (748d)
    • 2016-04-06 (水) 22:11:16 by takatsuka 差分

      Bootstrap では collapse って名称ですが、collapse ってどんな意味だろうって調べたら、「潰れる」とか「崩壊する」とか出てきて、なるほどと思いました。
      どちらも cookie を使って、リロードしても開閉状態を保持するようにしています。

  30. 会社案内​/求人情報 (751d)
    • 2016-04-03 (日) 22:57:59 by takatsuka 差分

      それらを用いた Web サーバー等の設計開発から運用。
      さらにはゲームソフトからデスクトップアプリ、制御機器のファームウェア開発など。
      そのため、仕事を覚えるというよりは、"つぶしの効くスキル" が得られるかを優先する社風があります。

  31. 会社案内​/業務案内 (752d)
  32. 技術系備忘録​/C++​/最適化小手先テクニック​/空関数の実体はヘッダに書くべし (753d)
  33. 技術系備忘録​/C++​/最適化小手先テクニック (757d)
    • 2016-03-28 (月) 17:22:01 by takatsuka 差分

      C/C++では、同じ処理をさせるにもコードの書き方で吐き出されるマシン語コードに違いが出ます。
      ここでは自分が有効かなと思っている最適化ネタを記載してます。
      昨今のマシンスペックを持ってすれば、ちょこざいな小手先テクニックは不要と思っている方もいらっしゃると思いますし、確かに、わざわざ最適化する必要がない場合も多いと思います。
      ですが、ソフトウェアという物は、要となる数箇所を最適化するだけで動作が快適になったり、逆に、なにも考慮されずに書いたコードが(塵も積もれば山となるで)ソフトウェア全体のパフォーマンスを悪化させる要因にもなりかねません。
      昨今のコンパイラの最適化処理はかなり優秀ですし、今後さらに優秀になっていくと思われます。
      しかし、その最適化処理を有効に機能させる為のコーディングテクニックが存在することも事実です。

      最適化されたコードというのは、コードの見易さとトレードオフになるケースが多いですが、何も考慮せずに書くコードより、速度面やコストパフォーマンス、コードの読みやすさなど、全てを考慮しながらコーディング出来ることが、良いソフトウェアに繋がると考えておりますし理想だと思っています。

      開発環境として、VisualStudio6 及び VisualStudio.NET2003 をターゲットにしており、WindowsAPIを使った例もありますが、基本的な考え方は多分どんな環境にも通じるであろうと思います。

      もし掲載されている内容に間違いなどありましたら是非ご指摘ください。それ程自信がある訳ではないので、御意見、アドバイスなど頂けると大変嬉しいです。

      written by takatsuka

  34. 技術系備忘録 (757d)
    • 2016-03-28 (月) 17:21:23 by takatsuka 差分

      その当時の見解で述べている記事ばかりです。古い情報となってしまっているものも多々あると思いますが、そこも踏まえ、ご意見やご指摘など頂けると大変ありがたく思います。

  35. 技術系備忘録​/C++ (757d)
    • 2016-03-28 (月) 16:55:57 by takatsuka 差分

      #lsx(技術系備忘録/C++/,notitle)

  36. 技術系備忘録​/C++​/Boost​/boost.asioでUDPホールパンチング (760d)
    • 2016-03-25 (金) 15:30:59 by takatsuka 差分

      同じ NAT 内の端末同士は、ローカルIPで通信させるなり対策しなきゃ。(たぶん一般的なルーターでは、自分自身が開けたポートに自分自身から接続(ヘアピン)は出来なさそうなので)。とか。

  37. 技術系備忘録​/C++​/最適化小手先テクニック​/VisualStudio2005,2008,2010コンテナ速度比較 (753d)
    • 2007-01-28 (日) 12:03:17 by takatsuka 差分

      fileBenchContainer.zip

  38. 技術系備忘録​/C++​/最適化小手先テクニック​/STLとMFCのmap速度比較 (753d)
    • 2007-01-28 (日) 12:03:17 by takatsuka 差分

      fileBenchMap.zip

  39. FrontPage (4488d)
  40. 技術系備忘録​/C++​/最適化小手先テクニック​/シフト演算の乗除算に注意すべし (753d)
    • 2005-12-25 (日) 08:43:00 by takatsuka 差分

      通説ですが、"2のべき乗での乗除算は、シフト演算(ビットシフト)で処理したほうが早い"というのがあります。
      CPUが高速化されたといっても、乗除算命令はそれなりに遅い処理で、比較するまでもなくシフト演算のほうが高速です。(List1)

      • List1
        #prettify{{
        int Test(int n)
        {
        	return n << 3;		// ビットシフトを使う
        }
        }}

      8倍する掛け算なのですが、2進数の仕組みを利用し、ビットシフトすることで8倍という処理を実現しています。
      これは確かに有効な手段であり、古くからあるテクニックで、まったく問題ないと思います。

      しかし、昨今のコンパイラは、わざわざシフト演算で記述をしなくても、シフト演算を使うコードを吐き出します。(VisualC++6で確認)
      こうなると、シフト演算で記述しようと、掛け算で記述しようと、最適化の観点からはどっちでも良いということになります。

       ・
       ・
       ・

      というわけで、以上でこのネタは終わりでもよいのですが、ちょっとツッコンだ個人的見解を述べたいと思います。

      自分は、昨今の最適化コンパイラを使う場合、素直に掛け算で記述するほうが良いと思っています。
      理由は、コードの見易さと間違いの避け易さからです。

      2のべき乗という単純な場合であれば、どちらの書き方であってもコードの見易さは変わらないと思いますが、それ以外の数で処理する場合、コードの見易さと間違いやすさは劇的に変わります。

      15倍する例を見てみます。(List2)

      • List2
        #prettify{{
        int Test(int n)
        {
        	return ( n << 4 ) - n;
        }
        }}

      これは、掛け算をビット演算に分解することで、掛け算命令を使わずに処理速度を稼ぐという、昔からある小手先テクニックです。16倍から1倍を引くことで15倍を実現しています。

      この場合、最適化の面から言えば問題ないかもしれませんが、コードの見易さは大きく犠牲になってますし、15倍をビット演算に分解する過程でミスを犯すかもしれません。

      さらに、最適化の面からも、実は正解ではなさそうです。
      List2 をコンパイルした結果(アセンブラ)が List3 です。

      • List3
        #prettify{{
        int Test(int n)
        	mov  eax, DWORD PTR n
        	lea  eax, DWORD PTR [eax+eax*2]		// 3倍して
        	lea  eax, DWORD PTR [eax+eax*4]		// 5倍する
        }
        }}

      期待した結果とは明らかに違いますが、これがコンパイラの最適化の結果です。

      つまり、見辛い上に最適ではないコードを記述してしまったことになります。
      (というか、どっちの記述でも出力されるアセンブラは List3 になります。ビット演算で記述してもコンパイラ(VisualC++6)は最適化してくれました。全然違う書き方でも同じように解釈するとは優秀です。)

      以上の結果からわかるように、定数の乗除算程度は、素直にコンパイラ任せにするほうが、コードの見易さも犠牲にせず、しかも最適な結果になる訳です。

      もちろん、コンパイラが優秀であればという条件が必要になるので、不安であれば念のため調べたほうが良いと思います。

      /*
      VisualC++の最適化性能がどんなもんか色々試しましたが、定数の乗除算についてはかなり詰められているようです。
      とはいえ、CPU特性などを考慮すると、どういうアセンブラが最速なのかということは、一見しただけじゃ分かりません。
      今回の例でも、コンパイラの出力が最速なのかどうかは確認も検証もしてません。しかし必要もないかなと思います。
      */

      なお、一つ注意点があります。List4をご覧下さい。

      • List4
        #prettify{{
        int Test(int n)
        {
        	return n / 8;
        }
        }}

      一見何も問題なさそうです。コンパイラはシフト演算するアセンブラを出力してくれそうに思えます。
      しかし、この場合は期待通りにはなりません。
      それは型が int (符号付) だからです。単純にビットシフトすることは出来ないため、けっこう面倒なアセンブラが出力されます。

      どうすればよいかというと、符号付として処理する場合はどうしようもありません。
      しかし、"マイナス値の引数はあり得ない"という前提があるのであれば、List5 のように書くと、ビット演算のアセンブラを出力させることが出来ます。

      • List5
        #prettify{{
        int Test(int n)
        {
        	return (unsigned int)n / 8;
        }
        }}

      unsigned int にキャストすることで、符号無しで処理しなさいとコンパイラに教えています。
      もちろん、このキャストによるオーバーヘッドというのはありません。変数 n を符号無しとして扱えとコンパイラに教えているだけです。

      まとめとして。
      昨今の最適化コンパイラのおかげで、定数の乗除算はどのように書いても最適化されたアセンブラが吐き出されるようですので、それを期待して素直な乗除算コードを書いたほうが良いと思います。
      もちろん、最適化されないコンパイラや環境を使う場合、ビット演算でのコーディングは有効な手段だと思います。
      List2 のような往年のテクニックも十分活かせると思いますので、知っておくことは損ではないと思います。

      なお、言うまでもないかもですが、本ネタは整数演算を前提に書いています。浮動小数点演算についてはまったく当てはまりませんのでご注意下さい。

  41. 技術系備忘録​/C++​/最適化小手先テクニック​/ビットフィールドを活用すべし(メモリ節約編) (753d)
  42. 技術系備忘録​/C++​/最適化小手先テクニック​/try~throw~catchの乱用を避けるべし (753d)
    • 2005-12-25 (日) 08:43:00 by takatsuka 差分

      通説ですが、try~throw~catch は遅いです。
      便利に使える場面もありますが、パフォーマンスが気になるところでは、なるべく使わないほうがよいでしょう。

      どの程度のパフォーマンスかを実際に調べてみました。

      • List1
        #prettify{{
        class CTest
        {
        public:
        	enum{
        		TABLESIZE = 100,
        	};
        	int m_Table[TABLESIZE];
        public:
        	CTest();
        	int CaseGoto();
        	int CaseTry();
        	virtual void OnExcept(){}
        };
        CTest::CTest()
        {
        	::memset(m_Table,0,sizeof(m_Table));
        	m_Table[0] = 1;
        }
        int CTest::CaseGoto()
        {
        	int nCount = 0;
        	for(int i=0; i<1000000; i++ ){
        		for(int x=0; x<TABLESIZE; x++ ){
        			if( m_Table[x] != 0 ){
        				OnExcept();	// 最適化されないように念のため
        				goto next;	// throwと比較しやすいようにgoto使ってます
        			}
        		}
        		nCount++;
        	next:;
        	}
        	return nCount;
        }
        int CTest::CaseTry()
        {
        	int nCount = 0;
        	for(int i=0; i<1000000; i++ ){
        		try{
        			for(int x=0; x<TABLESIZE; x++ ){
        				if( m_Table[x] != 0 ){
        					OnExcept();	// 最適化されないように念のため
        					throw false;
        				}
        			}
        			nCount++;
        		}catch(...){
        		}
        	}
        	return nCount;
        }
        }}

      CTest::CaseGoto と CTest::CaseTry の処理時間をそれぞれ計測してみると、
      CTest::CaseGoto が 10ms、
      CTest::CaseTry が 7551ms、
      と、サンプルコードが特殊ではありますが、かなりの差があります。
      (Pentium3 1.2G のマシンでVC++6を使用)

      try~catch は、関数をまたいで goto 出来るうえ、ローカルクラスのデストラクタ処理なども考慮されており、使い勝手はC言語の頃からある setjmp~longjmp 以上の物なのですが、便利な分、遅いです。

      例外処理本来の意味で、深いネスト(関数)からエラー処理の為に脱出するような使い方であれば良いと思うのですが、サンプルコードのように、普通の条件分岐で記述できる箇所では使わないようにしたほうが、パフォーマンスの面では有利だと思います。

      さらに、ちょっと愚痴っぽくなりますが、
      本来 goto文 を使うべき箇所(*1)で、goto文 を避ける為に try~catch を使っているような場合も、パフォーマンスの面だけでなく考慮してほしいな思うことがあります。
      VisualC++ を使ってデバッガ上で実行すると、throw が発生する度に、出力ウインドウに"例外処理・・・"というメッセージが表示されます。
      開発業務等で外部提供のモジュールを使用するケースはよくあると思いますが、
      その外部モジュールが、通常フローにも関わらず throw 連発しているような物だったら、しかも常に処理が走り throw 連発するような物だったら、
      出力ウインドウが"例外処理・・・"で埋め尽くされてしまいます。
      自分で入れたデバッグメッセージは一瞬で流されて見れたもんじゃありません。
      どうにかならないもんでしょうか・・・って誰にも文句を言えないとこにプログラマの辛い面を感じました。

      なにはともあれ、try~catch を何も考えずに使うのは止めたほうが良いと思います。

      /*
      setjmp はメモリ上にスタック環境を保持しておき、longjmp でその状態を戻すというアクロバティックな動作をします。普通の条件分岐とは訳が違います。
      その為か setjmp~longjmp は特殊で難しく、コードの見通しも悪くなるのでなるべく使わないようにしましょうとまで言われていた関数だったのですが、
      C++では try~catch として言語仕様としてサポートされた訳です。
      そう考えると、C言語の時代でも setjmp~longjmp をもっと便利に使うべきだったのかなと思います。
      */

      /*
      本件は C++ における try~catchのパフォーマンスについて述べています。
      JAVA や C# は try~catch を使うことが大前提のような仕様になってますので遠慮なく使っていいと思います。(パフォーマンスはわかりません)
      */


      *1 goto文は使ってはいけないとか、場合によっては使うべしという意見がありますが、自分は後者です。

  43. 技術系備忘録​/C++​/最適化小手先テクニック​/”エイリアスを使わないと仮定する”の意味 (753d)
  44. 技術系備忘録​/C++​/最適化小手先テクニック​/メンバ変数の並びを考慮すべし (754d)
    • 2005-12-25 (日) 08:43:00 by takatsuka 差分

      ご指摘いただきました。ありがとうございます。(2005/4/7追記) anchor.png

      Page Top

      ご指摘いただきました。ありがとうございます。(2005/4/7追記) anchor.png

  45. 技術系備忘録​/C++​/最適化小手先テクニック​/経過時間の判断方法の穴に落ちるべからず (754d)
  46. 技術系備忘録​/C++​/最適化小手先テクニック​/メンバ変数の参照は控えめにすべし (754d)
    • 2005-12-25 (日) 08:43:00 by takatsuka 差分

      関数の中で、同じメンバ変数を何度も参照するような場合、ローカルにコピーしたほうが処理は早い場合が多いです。
      例えば List1 のようなコードがあったとします。
      private:

      	CClassA *m_pClassA;
      	void Proc();

      void CTest::Proc()

      	m_pClassA->SetNumber(1);
      	m_pClassA->SetCount(2);
      	m_pClassA->Proc();

      CTest::Proc 関数で、m_pClassAを3回参照しています。
      もし、m_pClassA の値が関数内で変わることがないのであれば、m_pClassA をローカル変数にコピーして、それを参照するようにしたのが List2 です。
      void CTest::Proc()

      	CClassA* const pClassA = m_pClassA; // ローカル変数にコピー
      	pClassA->SetNumber(1);
      	pClassA->SetCount(2);
      	pClassA->Proc();

      なぜ、わざわざローカル変数にコピーする必要があるかというと、List1 は実は以下のコード list3 と同等です。
      void CTest::Proc()

      	CClassA *pClassA;
      	pClassA = this->m_pClassA
      	pClassA->SetNumber(1);
      	pClassA = this->m_pClassA
      	pClassA->SetCount(2);
      	pClassA = this->m_pClassA
      	pClassA->Proc();

      コンパイラは、変数m_pClassAが保持するCClassAのポインタを、毎回読み直すコードを吐きます。
      そのため、プログラマがそれをさせないコードにすればムダは省けます。
      賢いコンパイラならこの程度の最適化は勝手にしてくれると考えるかもしれませんが、この場合はされません。
      コンパイラは、
      m_pClassA->SetNumber(1);
      という関数の中で、CTest::m_pClassA が変更される可能性がある為 m_pClassA をキャッシュしておくことはしません。
      その為、次に m_pClassA を参照する場合も律儀に読み直す必要があるのです。

  47. MenuBar (4903d)

トップ 印刷に適した表示   ページ新規作成 全ページ一覧 単語検索 最新ページの一覧   ヘルプ   最新ページのRSS 1.0 最新ページのRSS 2.0 最新ページのRSS Atom Powered by xpWiki