昨日の RTR 読書会はパイプライン最適化の話だった. 改めて読むと面白い. 各種高速化チップスはさておき, パイプラインの遅い部分, ボトルネックを特定する方法が興味深かった. (ゲーム屋さんには当たり前の話だと思います.) グラフィクス・アプリケーションのパイプラインはおおよそ以下のようなものだ: CPU でデータを作り, それを GPU に送る. GPU ではまず geometry ステージ (vertex shader とか) が頂点情報を計算し, それを rasterize ステージ (pixel shader とか) がピクセルに変換, frame buffer に書き込む. データは図の左から右に流れる. この流れっぷりがパイプラインと呼ばれる所以. パイプラインの各ステージは基本的に並列して動く. だから全体の実行時間は最も遅いステージの所要時間になる. 各ステージの合計で

2007/04/27 “twitter”がブームだ。140バイト以内の短いメッセージで“現在進行形”の自分のステータスをほかのユーザーとシェアするだけのオンラインサービスだが、本国の米国はもとより、日本でも非常な人気を集めている。Alexaでアクセス数の推移を調べると、今年に入ってから本格的にブレークしている様子が分かる。4月22日にはニューヨークタイムズもtwitterと、サンフランシスコ在住の創業者2人を記事で取り上げている。 twitterのコミュニケーションツールとしての新しさ twitterに参加してみると、チャットやメール、SNSといった、既存のコミュニケーションツールのいずれとも異なる、不思議なつながり方が新鮮で楽しい。熱心にメッセージを更新するユーザーを見ていると、CUSeeMe、ICQ、mixiなどが登場したときに人々が示した熱狂に近いものを感じる。 twitterでは、

すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox とゲーム PC ゲーム Windows ゲーム 映画とテレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform Windows 365 開発者

Sorting Algorithms The animations on this page illustrate a number of different sequential and parallel sorting algorithms. The relative execution times of the animations give a very rough idea of the relative speeds of the algorithms. Each algorithm is finished when its colored lines disappear. Speed and Efficiency Analysis. Bubble Sort is a sequential algorithm, with an average case time of O(n2

1988年 1989年 1990年 1991年 1992年 1993年 1999-10-11: David Huffman 没 2000-04-14: Phil Katz 没 (享年37才) 2001-02-26: Claude Shannon 没 当時の畏友［これもずっと前の情報です。間違っていたら教えてください］ 吉崎栄泰さんは帯広協会病院の忙しいお医者さんです。 三木和彦（まむし）さんは株式会社情報管理の代表取締役をしておられます。 MASSAN（massangeana，益山健）さんについてはここをご覧ください。 ＲＯＭ男さんについてはここをご覧ください。 岡本継男さんはここでUNIX版LHAをメンテしてくださっています。 大久保謙二郎先生は どうしておられるでしょうか お元気で活躍されておられます。 奥村晴彦 Last modified: 2008-03-20 07:30:19

2006-09-11 近況 今月は貧乏なので慎しく暮らしている. 週末もひきこもりとしてオンラインの記事を読んで過ごすことに. ウェブを眺めているといいタイミングで Google の新作論文が出ていた. ありがとう, Google の中の人. これ. GFS, MapReduce, Sawzall とつづく Google インフラ N 部作の 4 章が幕をあげた. 実はデータベースも作ってるんだぜ, という話. BigTable という名前だけは以前から O'Reilly Radar などに登場していた. ようやく公式な文書があらわれた. BigTable は GFS をはじめとする Google インフラの上に作られた分散データベース. 少し変わったデータモデルと, 運用までワンセットのヘビーな実装を持つ. 実装の話もまあ面白いんだけれど, それよりデータモデルが印象的だった. 先にその

いまどきのデスクトップは色々モダンになっている. ただモダン化は API の裏側で進んでいるため, あまり興味を持たれていないらしい. 一見いろいろウォッチしていそうな知り合いと話していてわかった. 利用者視点の話題では, いまどきのデスクトップというとたとえばウィンドウが ヘナヘナ揺れるといったアイ・キャンディばかりが連想される. でもそのアイ・キャンディに至るにはきっと山ほど苦労があったはず. そのへんをちょっとねぎらってみたい. 念頭にあるのは Windows Vista, Mac OSX, XGL あたり. まず共通の階層化されたアーキテクチャを想定し, ケーススタディを交えつつその層を下から上へ順にたどっていきます. 復習: デスクトップ処理系の階層構造 そもそもデスクトップの中味はどんな構成をとっているのか. ざっと眺めておこう. 典型的なデスクトップ処理系のアーキテクチャはだ

The deep inside of Windows 〜　Windowsの深淵 Ｌｅｓｓｏｎ　2．超高速描画の謎【後編】　 '01/11/03 DirectDrawSurface + functorでの描画が基本という結論を得たので、案外盲点になっている注意点を書いてみたいと思います。 １．DirectDrawSurfaceのLockのバグ LockするRectを指定してのLockは正しくlockされない（バグ）のため、使わないようにしましょう。 ２．システムメモリ上のDirectDrawSurfaceは、Lostしない。 そのため、IsLostで検出できません。注意しましょう。 ３．システムメモリ上のDirectDrawSurfaceは、Lockしなくても読み書きできる 出来るようです。VRAMが非リニアなマシンではどうなるのかって？というと、初期のPC-9801シリーズとかですかね．．

The deep inside of Windows 〜　Windowsの深淵 Ｌｅｓｓｏｎ　１．超高速描画の謎【前編】　 '01/10/04 走り書きですんません、、時間無いのです。きちんとデータをとりなおして、書き直したいのですが、その時間も無いので、もうこのまま載せちゃいます。読みにくくってごめんなさい。 通常のゲームにおいては、描画処理が、処理全体の８０％以上を占めると言っても過言ではありません。そのわりには、Windowsで、どうやれば高速な描画ができるのか、実際に比較して示してある書籍が皆無です。私も断片的に、ｒｓｐ（スーパープログラマへの道）で書きましたが、測定値を示すには至っていなかったのです。だから、同業者のしとたちから、詳しく書け書けとうるさく催促されています＾＾； しかし、実は、いま、ここで詳しいことを書いているほど時間は無いのです。私は、某麻雀ソフトで、DIB描画の

Last Modified: 2000-11-14 (Since: 2000-11-14) Suffix array is a data structure designed for efficient searching of a large text. The data structure is simply an array containing all the pointers to the text suffixes sorted in lexicographical (alphabetical) order. Each suffix is a string starting at a certain poinsition in the text and ending at the end of the text. Searching a text can be performe

━─────────────────────────────────── アセンブラ講座（番外編） 《万能数値表現法　ＵＲＲ》 鎌田　誠 ──────────────────────────────────── IEEE 754 で規格化されている浮動小数点数の表現方法は符号と指数部と仮数 部に整然と分けられていてわかりやすく、実装も容易なのですが、指数部と仮数 部を区切る位置を固定してしまったために、大きな数を扱いたい技術者には指数 部の範囲が狭すぎ、精度を要求する技術者には仮数部のビット数が少なすぎると いう問題点があります。 しかし、かつて日本人によって IEEE 754 よりも算術的に優れている浮動小数 点数の表現方法が考案されていたことを知る人はほとんどいないでしょう。その 数値表現法は考案された当時の技術では実装が困難だったために規格化されなか ったようですが、非常に興味深い数

『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直

はじめに　ニューラルネットワークの主要なアルゴリズムであるバックプロパゲーション法を、車両のナンバープレートの自動読取りへの応用例で紹介します。完成版のアプレットを見る 対象読者　パターン認識に興味を持ち、特にニューラルネットワークを用いる方法に関心のある人。必要な環境　J2SE 5.0を使っていますが、これより古いバージョンでも、本稿のコードをコンパイルし、実行することができます。ただし、添付のコンパイル済みアプレットの実行には、J2SE Runtime Environment 5.0が必要です。また、CPUパワーが足りないと、学習に時間がかかります。 パターンには、音声、画像、図形、文字などがあります。これらが何であるかを認識することを「パターン認識」と呼び、音声認識の応用は音声入力装置に、画像認識の応用は顔や指紋の照合に使われます。文字認識は、大別して、手書き文字の認識と、印刷文字の

点列をベジェ曲線に変換する BezierGenerator.js のサンプルです。 このサンプルは Firefox, Opera くらいでしか動きませんが、BezierGenerator.js 自体に環境依存性はありません（たぶん）。

はじめに　テキストを生成するアプリケーション（メールの本文やソースコード生成など）を作る場合、プログラム中でテキストを結合する方法が一般的です。しかし、長いテキストをプログラムで編集することは思いのほか面倒ですし、内容を変更する場合には再コンパイルを行わなければなりません。　そこで本稿では、雛形（テンプレート）として用意しておいたテキストファイルをアプリケーションの実行時に読み込み、動的に値を埋め込める「NVelocity」というプロダクトについて紹介します。NVelocityを利用すると、単純な文字列の挿入だけではなく、条件分岐、繰り返し、メソッド／プロパティの戻り値の利用など柔軟なテキスト生成が可能になります。また、プログラムを変更することなくテキストを変更できるため、保守性の高いアプリケーションを構築できます。対象読者　Visual Studio（.NET）にて開発を行っている方、テ

はじめに　「データ圧縮」は、必要な情報を残したまま、データをコンパクトに保存・伝送する技術であり、テキストや画像・動画情報の圧縮など、多くの場面で使われる情報化社会において不可欠なものとなっています。データ圧縮の中身は、「モデル化」と「符号化」の2種類に大きく分けられます。前者はデータをどのように表現するかを求める部分であり、後者はその表現したものをコンピュータ上でどう保存するかという部分です。今回扱うCHCは、この後者のための代表的な技術であり、モデルが分かっているデータを最も短い符号長注1で保存する技術です。 対象読者　C++の利用者を対象としています。データ圧縮の基礎を知っていることが望ましいです。必要な環境　C++、32bit環境を想定しています。Windows XP上のVisual Studio C++ 2005、gcc 3.2.2で動作確認済みです。Huffman Codeの概