はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
すみません、以前のプログラムにポカがありました 以前、以下のエントリーを書きました。 float型とdouble型を比較した場合、常にfloatが速いと思ってはダメらしい - 強火で進め http://d.hatena.ne.jp/nakamura001/20090226/1235641233 そして今回、この速度差がどこから来てるのかアセンブリレベルで検証しようと色々と前回のプログラムを見直していたところ大ポカをやらかしている事に気がつきました。 具体的には以下の様な部分です。 NSLog(@"double : time=%f\tval=%f", elapsedTime, floatTotal); こちら double での計算結果なので本来でればここで指定するのは floatTotal ではなく doubleTotal です。 このようなポカをやらかしたせいで doubleTotal
「よりパフォーマンスの高いプログラムを作成するにはアセンブラを駆使すべし」という話を聞いたことがある人も多いだろう。これは、C/C++言語で記述されたプログラムには冗長な部分があるため、ノウハウを持つプログラマがアセンブラでチューニングしたプログラムの方が高いパフォーマンスを得られる、ということであった。しかし、現在では必ずしもこのことは当てはまらなくなっている。その理由は、コンパイラの進化と、CPUおよびPCアーキテクチャの複雑化にある。 最近のコンパイラのほとんどは最適化機能と呼ばれる、ソースコードをより効率の良い形に自動変換する機能を備えている。基本的な最適化の例としては、プログラム内で実際には使われていない処理の省略や、冗長なforループの自動展開などが挙げられるが、最近ではこのほかにも高速に処理を行えるようプログラムの実行順序を入れ替えたり、頻繁に呼び出される関数を自動的にインラ
strlen()とmemchr()のSIMD版を作ってみました． 今回は最速よりもお手軽さを重視したのでアセンブリ言語ではなくintrinsic関数を使っています．そのためVisual Studio 2008, gcc 4.xの両方でコンパイルでき32-bit, 64-bit OS上で動作します． WindowsとLinuxでのみ確認していますが恐らくIntel Mac OS X上でも動作するでしょう(sample source)． ベンチマークはランダムな長さの文字列の平均長(average length)を変化させつつ取りました．数値は1byteあたりにかかった処理時間比で小さいほど速いことを表します． strlenが3種類(ANSI, BLOG, SSE2)とmemchrが2種類(ANSI, SSE2)あります．BLOGというのは今回試してみようというきっかけになったCounting
プログラムの高速化については本連載の第13回で紹介しています。プログラム中のどの部分を高速化すべきなのか，どのように効果を測定するのか，そもそも高速化が必要なのかを考察しました。今回は実際に高速化を試みます。 今回はプログラム高速化の実践編として，ある程度の大きさの具体的なプログラムを段階的に高速化しながら，実践的なテクニックを学ぶことにしましょう。 例題はマンデルブロ集合＊1の計算プログラムです（図1）。マンデルブロ集合は非常に美しい集合ですから，本当はグラフィックス表示が好ましいでしょう＊2。しかし，GUIを使うと，特定のGUIライブラリ（グラフィックス・ルーチン）に依存したコードが大量に必要です。今回のテーマは「高速化」ですから，直接関係のないGUIコードはできるだけ省くため，キャラクタ（英文字）で図形を表現することにしました。 1 require 'complex' 2 3 def
プログラムの高速化はプログラマにとって永遠の課題です。しかし，そこには知られざる暗黒面が隠れています。そもそも高速化に意味があるのかを調べなければなりません。次に，どの部分をどの程度高速化するのかが重要です。アルゴリズムの効率にも目配りが必要です。 コンピュータの処理速度は驚くべき勢いで向上しています。現在私たちが使っているパソコンは一昔前のスーパーコンピュータをしのぐ性能を備えていますし，半世紀前に登場したばかりの計算機と比較すると数十万倍の性能に相当します。 このように高速なコンピュータを持っているにもかかわらず，人間の欲望は限りがないものです。プログラムの実行速度はプログラマにとっての永遠の課題のようです。プログラムを高速化していると，「そんなに急いでどこに行く」という気になることもあります。 今回は，プログラムの高速化にまつわるさまざまな「秘密」と「限界」，そして「戦略」について解
UNIX 偏向文書 artu の中で "Measure Before Optimizing" と説く Raymond は, 同時にプロファイラの計測機構 (instrumentation) がもたらすノイズについて注意を促している. 私のプロファイラ信仰に不安が翳を落とす. gprof ノイズはさておき, そもそもプロファイラはどんな仕組みで速度を測っているんだろう. gprof のマニュアル によると, GNU 一族のプロファイラは次のように実装されている: まず "-pg" オプションつきの gcc でソースをコンパイルする. この指示を受けたコンパイラは各関数の冒頭に "mcount" という名前の関数呼出しを加える. リンクする C のランタイムも専用バージョン (gcrt0.o) に差し替わる. このランタイムは裏で profil() 関数を使いタイマを仕掛ける. そのタイマは発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
