リンクフリーを近日中にとりやめる予定です

すでにリンクを貼っていただいている方、ご一報頂きたくお願い申し上げます。


ごく少数ですが、リンクをお断りする場合があります



ブログ内 風景光景カテゴリー

続編記事などをご希望の方は こちらへどうぞ

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

店長を卒業することになりました

・これは告知記事のため、しばらくの間トップ固定となっています。
・このブログは閉鎖ではなく、しばらくお休みとなります。
ビータラボ株式会社は健在です。


今までご愛顧いただきありがとうございました。
心あたたかいご指導、ご鞭撻いただけたことに対し感謝の気持ちでいっぱいです。
おかげさまで、綴り続けることができました。

皆様ご存知の通り、このブログは、ビータラボ株式会社の公式サイトからの唯一のブログという位置づけでスタートし、
「ビータラボ株式会社の存在を皆さんに知って頂きたい」
という一念で進んでまいりました。

第一幕をこれにて終了とさせて頂きます。
ご理解のほど、よろしくお願い申し上げます。

いずれ、再開を検討しております。
再開の際には、ごひいきいただければ幸いです。


(1) 店長役廃止に関して
おかげさまで、大手通販サイトや店頭にて製品を取り扱っていただけるようになりました。
然るべく、販売、宣伝、それぞれ得意とする方々に一任したほうが良いという決断に至りました。
よって、今までは製品を公式サイトから直接購入できる仕組みであった点を改めると共に店長役を廃止するに至った次第であります。

公式サイトの改装は2012年秋頃より着手、改装完了は2013年 3月末を目標としておりました。
遅くなってしまった点、関係各位に深くお詫び申し上げます。

※ 一部の方々にご心配いただいた、当ブログへの誹謗中傷と今回の件は無関係です。
※ また、脅迫された件に関しては正々堂々と対処してゆく所存であります。

(2) 当サイトの今後に関して
打ち合わせの段階では、公式サイト改装後、即閉鎖という案でした。
一方、過去に掲載した、マニアック( 主にPCに関する )な話題に関して、連日アクセスいただいております。
「記事を何らかの形で残しておく方がお役に立てるであろう」という結論に至りました。


(3) 再開に関して
しばらくの間、筆者 ( 管理人 )の都合により、一旦お休みとさせていただきます。

体調が悪い中でも、無理にブログ活動をなられている方、ありがたいと思う反面、負担をかけているようで心苦しい思いもありました。
さらに、災害に遭遇した避難先から訪問コメントをいただいた際には唖然とするばかりでした。
これは筆者にとって遣る瀬ないところであります。
しばしば言われるように、ネット ( PC の利用 ) というのは中毒性があり、離れるのはなかなか難しいものです。

個々人のポリシーがあるかとは存じますが、筆者はメリハリが重要だと考えています。スパイラル ( 悪循環 ) は避けたいところであります。
疲れ、体調不良などの痛みを抱えながら進むよりも、一度スッキリとしてから物事に当たるのが賢明であると考えております。


(4) その他
筆者 ( 管理人 )の休養にともない、新しい話題はお届けできそうにありません。
掲載却下になった話題がいくつもあります。まだ下書き途中であった記事もあります。
それらの話題に関しては、何らかの形で公開できないか模索しております。
スポンサーサイト

本日も最後までご覧いただきありがとうございます。

「つまらなかった」「判り辛った」という方もご遠慮なくコメント欄へどうぞ

テーマ : 管理人からのお知らせ
ジャンル : その他

続編記事への要望はこちらへ

過去に掲載されたあの記事の続編が読みたい
などのご要望は、この記事コメント欄へ書き込んでいただきたくようお願い申し上げます。
再開の際、筆をとる目安とさせていただきます。

※ 普段の記事とは異なるため、返信できない場合もあります。
※ 似たハンドルネーム、タイトルなどが複数ある場合、ご本人様と判別できないことがあります。この記事コメント欄に限っては連絡先、URLなどを入力いただければ幸いです。

本日も最後までご覧いただきありがとうございます。

「つまらなかった」「判り辛った」という方もご遠慮なくコメント欄へどうぞ

テーマ : 管理人からのお知らせ
ジャンル : その他

[未掲載分] 「除算が遅い」の補足 (9)

「除算が遅い」の補足 (8)の続き。多くのヒトにとって除算が速い遅いといった話題は興味が沸かないことだろう。



例えば、音遊びに使うアプリを作るとしよう。これは、音とび ( クリッピングが生じた音声データ ) を修正するために組んだアプリである。
もとの音データは整数値で収納されている。アプリはそれを読み出し、乗算・除算・三角関数などを通して処理して保存する。



アプリを使う側の視点で考えてみよう。演算が遅いということは待ち時間が増える。画像や音を編集するアプリを利用する際、多かれ少なかれ待ち時間が発生する。多く待たされることはストレスにつながる。数十秒で終わるのか、はたまた、一時間近く待たされるのか・・・


お知らせ
活動休止にともない、この記事を事前に予約投稿してあります。
トップ記事の固定を目的としています

※ これを下書きしたのは2012年夏の終わり頃です。
ご覧いただいている時期によっては状況が異なっている可能性があります。
下書きした頃の環境は、OS - Microsoft Windows 7、開発環境 - Visual Studio 2008 , C/C++ 言語。
Intel 80386 ( i386 ) の流れを汲む Core i7 や Pentium や Atom 等 の CPU もしくは互換品を前提としています。


予め述べておくが、
C/C++ 言語でいうところの変数の型や型変換など、基礎的な事柄の理解が曖昧なままここに辿りついたヒトもいることだろう。この先の内容を飲み込むのは辛いと思われる。ほかのプログラミング言語を用いるにしろ、そのようなヒトは除算の高速化うんぬんの前に基礎的な事柄を習得した後、再度ご覧頂ければ幸いである・・・

少しおさらい。
「除算が遅い」の補足 (6)2組分の除算を行える~~~待ち時間はほぼ一緒。と述べた。
並列に実行できる、できないに関して手順を練り直すことで、さらなる高速化を目指せる。

なぜ XMM レジスタの明示的な利用するのかについては、「除算が遅い」の補足 (3)「除算が遅い」の補足 (4)で綴ったように、
レジスタ数に余裕があるか否かで実行速度が左右されるからである。

※ 汎用レジスタは標準装備 ( もともと備わっていた )、XMM レジスタは後から追加された。

32ビット版の OS で実行するアプリを作成した際、空きレジスタの不足を補うようなコードが生成されることがあり、速度低下の要因になる。64ビット版の OS 上で32ビット版 のアプリを実行することは可能であるが、これは解消されない。
つぎに、64ビット版の OS 向けにアプリを作成した場合、32ビット版に比べ汎用レジスタ数に余裕がある。汎用レジスタで64ビット数値を直接扱える。したがって、XMM レジスタを積極的にメリットが薄いように感じてしまう。
64ビット版のアプリでは FPU を介した演算がサポートされない。西暦1993年頃に登場した Pentium から FPU ( 浮動小数点演算処理装置 ) が標準搭載されるようになった。そのほか、XMM レジスタでの演算は、FPU を介するのに比べ、同時に2組分の演算をこなせるので待ち時間を減らすことに繋がる。FPU の内部での演算精度が 80ビットである点は魅力的ではあるが・・・

しかし、前回綴ったように、SSE2 命令体系の中に整数の除算が含まれていない。
誤解が生じるといけないので、「命令が備わっていない。」と表現した方が適切だろうか。ハードウェア内部には除算を行う回路が備わっていても、それを呼び出す命令が存在しない。
もちろん、ソフトウェアレベルでの代替は可能である。しかし、「除算が遅い」の補足 (1)「除算が遅い」の補足 (3)で触れたように、ソフトウェアレベルでの代替処理に速さ求めても仕方がない。
その後、SSE4.2 に至るまで整数の除算命令は追加されなかった。では、整数の除算に関して諦めるしかないのだろうか?

前回XMM レジスタで倍精度浮動小数点値と 32 ビット整数値、もしくはその逆の変換が可能とヒントを載せた。
C/C++ 言語でいうところの型変換 ( キャスト) が判っていれば理解し易いハズ。
いま、どの型で演算しようとしているのか???等の基礎が曖昧なままアプリ作成を続けているヒトもいることだろう。昨今はプログラミングに親しみやすいようにとの計らいで、その辺を深入りせずともアプリを組めるようになってきた。とはいえ、上の段階に歩を進めようとした際に戸惑うことがないよう、基礎固めは重要・・・

この記事は Core i7 や Pentium や Atom 等 の Intel 80386 ( i386 ) の流れを汲む CPU を前提にしている。
一般的な PC の CPU は自動車でいうところのエンジンに該当する。西暦1993年頃に登場した Pentium から FPU が標準搭載され浮動小数点数 ( 実数 )を直接扱えるようになった。それまでは 別売りの FPU を追加するか、FPU を介しないソフトウェアによる代替で処理するようなアプリを組む必要があった。
もっと遡れば、CPU が直接扱えるのは 整数に限られていた時期もある。諸説あるが、電子計算が行われるようになったのは西暦1946年頃と言われている。現在用いられている単精度や倍精度浮動小数点数演算の標準化が行われたのは西暦1985年ごろ・・・

整数しか扱えない不便さは想像し難いだろうか。
例えば、本体価格10円、そこに5%の税金が乗るとしよう。人間の頭では一個10.5円と考えることができる。
いちばん小さい通貨の単位が1円であるならば、切り捨てて10円、切り上げて11円。前者では売る側が0.5円を負担、後者なら買う側が多く支払うことになる。どこか不公平。
もちろん、毎回2個一組での売買に定め、値段は21円に設定するなどの策も考えられるのだが・・・



XMM レジスタを用いて整数から倍精度浮動小数点値に変換する、または、その逆の命令 (倍精度浮動小数点値から整数に変換する ) を知りたい場合、
・IA-32 インテル アーキテクチャ ソフトウェア・デベロッパーズ・マニュアル
・インテル エクステンデッド・メモリ64 テクノロジ・ソフトウェア・デベロッパーズ・ガイド等の書物が役立つ。もちろん無料。それら資料の入手に関しては過去記事車輪の再発明 (8)をご覧あれ。

「変換」は「convert」「conversion」「transformation」。IA-32 インテル アーキテクチャ ソフトウェア・デベロッパーズ・マニュアルは4巻。そのうち、中巻A:命令セット・リファレンスA-M。おそらく、「conv~~」「cvt~~」の項を眺めると何か見つかる。



CPU が直接解釈できるような機械語コードやCVT○○○といった擬似コードを覚えるのは苦労する。
C/C++ 言語でアプリを作成するなら組み込み関数を利用する。開発環境が Visual Studio だとすれば、「_mm_cvtepi32_pd」 と 「_mm_cvtpd_epi32」 の組み込み関数を用いることが可能。前者が整数から倍精度浮動小数への変換、後者はその逆。

「_mm_ ○△□」といった関数名を覚えるのが面倒!?!?!?
それに関しては「除算が遅い」の補足 (6)で触れたように「_mm_ ○△□ _pd」といった組み込み関数は「○△□」の部分が掛け算なら 「MUL」 、 割り算なら「DIV」と理解できる。同様に、数値を変換したい際に用いる組み込み関数の名は
「_mm_cvt」、「変換もと変数の型」、アンダースコア ( 下線 )、「変換される変数の型」の順に並んでいると理解できるハズ。

例えば、「_mm_cvtsd_si32」という組み込み関数であれば、倍精度浮動小数点値を符号付き 32 ビット整数値に変換するのに用いる。ほかにも、よく見ると



「CVTPD2DQ」のほかに「CVTTPD2DQ」という命令が載っている。違いは「CVT」と「CVTT」。
組み込み関数の方も「_mm_cvtpd_」「_mm_cvttpd_」といった具合でなんだか紛らわしい。見た目の違いは「cvt」「cvtt」。
「t」が付く付かないで変換される値が変わってしまうので注意が必要。
「_mm_cvt」の方は現在設定されている丸めモードに従って変換、「_mm_cvtt」のように「t」が2つ付く方は切り捨てて変換となる。

丸めモードは「直近値への丸め」、「切り上げ」、「切り捨て」、「ゼロ方向への丸め」があり、プログラマーが任意に指定できる。既定の丸めモード、つまり何も指定しなかった場合は、一番近い値に丸められる。
アプリを作って実行した際、演算結果が期待と大きく違ってしまうヒトはこの辺の事柄が飲み込めていないのかも。

丸めモードを指定するのはそれほど難しくない。Windows 用のアプリをC/C++ 言語 で作成するとして、FPU を介した演算ならば、_control87、_controlfp などのランタイム関数を呼び出すことで丸め動作を変更できる。

XMM レジスタを介した演算では _mm_setcsr 関数で同様の指定が可能である。
念のため書いておくが、_mm_setcsr 関数を用いて丸めモードを自由に変更できるとはいえ、演算ループが終了したら変更前に戻すのが無難である。



_mm_getcsr 関数を用いることで制御レジスタの内容を読み出せる。読み出した値をどこかに保持しておき、演算の繰り返しが終わり次第、制御レジスタの内容を元の値に戻すのが良いだろう・・・



実数で演算し結果を整数に変換する場合、実行速度を左右する項目があります。・・・ちなみに、この話の旨は XMM レジスタの活用であって、FPU の活用ではありません・・・
開発環境が Visual Studio 、32ビット版のアプリを作成する、演算は FPU を介するとしよう。整数に変換する際、何も指定しないと _ftol や _ftol2 といったヘルパー関数を呼び出して処理する。先に述べた通り、ソフトウェアによる代替処理は速くない。
もちろん、FPU が直接変換して値を返すことも可能である。重複するが、FPU が標準搭載されるようになったのは Pentium の登場からである。初期の Pentium において演算回路に欠陥を抱えたモノが出回った。ハードウェアレベルでの間違いを正すためにヘルパー関数を呼び出す。

逆にいえば、FPU による 直接変換ならば速度低下を避けられそうだ。標準仕様による _ftol や _ftol2 といったヘルパー関数を呼び出すのが遅い原因だとすれば、呼び出さないように指定すれば改善されるかも。
Visual Studio で/QIfistオプションを指定することで浮動小数点型から整数型への変換が必要なときのヘルパー関数 _ftol を呼び出さなくなる。つまり、FPU による 直接変換を行うようなアプリが生成される。たいていの場合、遅い部分が改善される。

Visual Studio で何らかのオプションを指定したい場合、プロジェクトの「プロパティページ」 ダイアログ ボックスを開く。ところが、/QIfistオプションを指定する項目は見つからない。



プロジェクトの [プロパティ ページ] ダイアログ ボックスを開き、左ペインの[C/C++] をクリック。続いて、[コマンド ライン] プロパティ ページをクリック。



[追加のオプション] の入力欄に「/QIfist」と入力。

※ 初期の Pentium プロセッサーでなくとも演算結果が期待通りにならないリスクもあります。よって、このオプションを使うかどうかは慎重に・・・

あ、忘れるところでした。_ftol や _ftol2 でエラーになる件。
コンパイラとリンカーの相性が悪いとアプリ作成時にエラー。原因はコンパイラとリンカーのバージョンが合っていないこと。浮動小数点型から整数型への変換で _ftol2 関数 が使われるようになったのは西暦 2003 年頃リリースされた Visual Studio .net や同 2003 から。それ以前の Visual Studio 6.0 等では _ftol 関数 を用いたアプリとなる。
大雑把に言えば、Windows XP を念頭に置いた開発環境とそれ以前の Windows 98 や NT 4.0 を対象とした開発環境といったところ。実は、Microsoft Visual Studio 6.0 と Visual C++ Toolkit 2003 を組み合わせることが可能であった。この組み合わせにおいて、コンパイラが _ftol2 を指示してしまうが、リンカは古い方を探しに行ってしまい、結局エラーとなる。

ソースファイルの先頭の方に
extern "C" long _ftol2( double dblSource ) {return _ftol( dblSource );}
・・・といったオマジナイを加えることで解消できたような・・・

開発環境を整えておくことでこのようなトラブルは防げる。Visual Studio の新バージョンが登場すると導入したくなる。新バージョンを導入する際、ついつい古いバージョンも残しておきたくなる。新旧共存させたい気持ちもわからなくはない。新しいモノに不具合はツキモノ。とはいえ、古いモノでは機能が足りない感が否めない。さらに、複数の PC に分けるのも手間がかかる。
一台の PC で済ませたいならば、VMWare 等の仮想環境を検討すると良い・・・



さてさて、XMM レジスタを活かした除算の高速化に話を戻しましょう。
冒頭に載せたようなアプリを組みたいとします。想いつく流れをおおまかに示すと
・整数値のデータを読み出す
・整数から倍精度浮動小数点値へ変換
・浮動小数で演算
・演算結果を整数に変換
・結果をメモリにストア ( 格納 )する・・・

・・・といった具合でしょうか。

長くなりましたので今回はこの辺で・・・

本日も最後までご覧いただきありがとうございます。

「つまらなかった」「判り辛った」という方もご遠慮なくコメント欄へどうぞ

テーマ : プログラミング
ジャンル : コンピュータ

[再掲載] はじめてのミキサー

しばらく、小難しい話題が続いたので緩いお話を・・・



元ネタは2012年 8月24日分、わかっちゃいるけど見つからないのおまけ部分。2013年末ころ、とある方からもう一度見たいと連絡がありました。



たびたびこのブログに登場した猫のトラ。
初めて見るミキサーに興味津々・・・


お知らせ
活動休止にともない、この記事を事前に予約投稿してあります。
トップ記事の固定を目的としています




「今なら店長が見てニャいぜぇ。」



スイッチ入れて



グライコもセットして



エフェクトもいっぱい盛っちゃおう。



ヘッドフォンつけて



ミックス開始!



「『スクラッチする猫』には負けニャいぜぇ。」

本日も最後までご覧いただきありがとうございます。

「つまらなかった」「判り辛った」という方もご遠慮なくコメント欄へどうぞ

テーマ : 楽器・音楽をエンジョイ♪
ジャンル : 趣味・実用

[未掲載分] 「除算が遅い」の補足 (8)

「除算が遅い」の補足 (6)「除算が遅い」の補足 (7)で、実数 ( 浮動小数点数 ) の除算でさらなる速度向上を目指すについて触れた。



今回は、整数の除算について・・・


お知らせ
活動休止にともない、この記事を事前に予約投稿してあります。
トップ記事の固定を目的としています




A = B ÷ C という式において、C ( 除数、割るほうの数 ) が定まっている場合、「除算が遅い」の補足 (2)で、述べたように
・整数の除算ならば、「乗算とシフト」に置き換えると良い。

除数 が定まっていないとして話を進めよう。「除算が遅い」の補足 (6)で、浮動小数点数の演算を多数繰り返す場合、
・追加された XMM レジスタを活かし同時に複数の演算を行うことや、
・並列に実行できるように練り直すことで、さらなる速度向上を期待できると述べた。昨今のCPUであれば、依存関係が無い命令が続く場合、同時に実行できる。

ということは、整数の除算についても、それと同様の手法が使える???

SSE2 命令に対応した CPU であれば、XMM レジスタで整数の演算も可能である。
複数の倍精度浮動小数点数を扱うには、__m128dといった変数の型を用いた。複数の整数を扱う際に用いる変数の型は__m128i



128ビットの XMMレジスタで32ビット幅の整数値を4組、



もしくは、64ビット幅の整数値を2組同時に扱える。ほかにも、16組の8ビット整数や8つの16ビット整数といった組み合わせも可能である。

実は、加算、減算、乗算の命令は用意されている。しかし、XMM レジスタで整数の除算を行う命令が無い。

C/C++ 言語で XMM レジスタを明示的に使う場合、浮動小数点数の演算では_mm_ ○△□ _pdなどの組み込み関数を用いる。乗算や除算は_mm_mul_pd_mm_div_pd
整数の加算、減算、乗算はそれぞれ、_mm_add_epi32 や _mm_add_epi64、_mm_sub_epi32 や _mm_sub_epi64 、_mm_mul_epu32 の組み込み関数が用意されている。しかし、除算に直結するような _mm_div_epu32 や _mm_div_epu64 が用意されていない・・・
たしか、ここはリザーブ扱いになっていたハズなので SSE2 が登場したての頃将来的に実装する予定だったのかもしれません。その後、SSE3 から SSE4.2に至るまで整数の除算命令は追加されませんでした。XMM レジスタを用いた整数の除算命令が備わることを望む声も少なくなかったハズ・・・

・・・ということで、整数の除算部分を自前で組む???

昨今流通している CPU では当然のようにハードウェアレベルで除算が可能。汎用レジスタで除算する仕組みが備わっている。
これを書いている時点でPC 用として普及している CPU は Core i7 シリーズ。Core i7 は 1980年代後半に普及した Intel 80386 ( i386 ) の流れを汲んでいる。i386 は 32ビット版 の CPU として登場した。遡ると、8086 や 80286 などの16ビット版のプロセッサをもとに32ビット版への拡張が施された。



8086 には登場時から除算機能が備わっている。つまり、汎用レジスタによる整数の除算が可能である。8086 の説明で「~~~ 8080のアーキテクチャを16ビットに拡張し、乗除算などの命令を強化したCPU ~~~」などの記載を見かける。
「アーキテクチャうんぬん」との表記に戸惑うヒトがいるかもしれない。要はIntel 8080 という 8ビット版 CPU の「基本設計概念」を受け継ぎ 16ビット版 CPU として登場したといったところ。
細かく言うと、Intel 8080 の後継、拡張版としては Intel 8085 や Z80 などの 8ビット版 CPU が存在した。Z80 は Intel 8080 の開発に携わった者たちが独立起業して開発されたモノだが、当時は 8080よりもZ80を搭載した PC も多く流通していた・・・

ここで肝心なのは CPU の進化うんぬんよりも、「乗除算などの命令を強化した」の部分。かつては除算命令が備わっていなかったことを指している。その頃の機器は、データの読み書き、加算、減算とシフトが出来る程度だった。誤解が無いように加えておけば「除算命令が備わっていない」「除算できない」ではない。
自前で組むか、既存のライブラリに頼るかプログラマの力量次第だが、除算命令が備わっていなくてもソフトウェアレベルで何とかすることができた。

そもそも、昨今の CPU で除算命令をどのように処理しているのだろうか。
大雑把に言えば、ひたすら引き算を繰り返す。乗算 ( 掛け算 ) はたくさんの足し算に置き換えられることが判ればこの辺は易く理解できるハズ。

古くからの手法として、引き放し法や引き戻し法が有名である。また、0 と 1 で表される2進数の除算に最適なFast recursive divisionが発表されている。この元を書いたのは西暦2012年。Fast recursive division が発表されたのは西暦1998年頃であり、それから10年以上経つが、ハードウェアレベルで備るにはまだ時間が掛かるかも。

ひとことに引き算を繰り返すと書いただけでは想像しずらいかもしれません。
例えば1234÷5を計算するとしよう。予め答えを書いておくと246。
ひたすら引き算を繰り返すといっても、1234から5を引いて1229、まだ5より大きいから5を引いて1224~~~といった手順は非効率。
私たちが子供の頃習うのは、最上位の1は5より小さいので引けない。上から2桁の12から5を2回引いて、余りが234。次に2から5は引けないので23から・・・といった具合である。
被除数 ( 割られるほうの数 ) に対して除数 ( 割るほうの数 ) をそれぞれの位に合わせながら解いてゆくハズ。

2進数を理解すればシフト、減算、比較命令で除算処理を実現できそう。その前に、2進数とは何ぞやという状態でここを訪れたヒトは遅くない除算をご参照あれ・・・
1234を 2進数 ( 0 と 1 の組み合わせ ) で表すと0100 1101 0010 。同様に5を2進数で表すと 0101。

最初に被除数と除数を比べます。小さければ 0、等しいなら1の答えをもって終了。そうでない場合は位をそろえながら引き算を繰り返します。

まず、位を合わせます。


最上位の何ビット目が1であるかを探し、除数をシフトして位を合わせます。使うのはビットスキャンとシフト命令。



引けるか否かを比べ、可能なら減算。ここでは 0100 から 0101 を引けないので位を下げるため1ビット右シフト。使うのは比較と分岐、シフト命令。



さてさて、今度は引けそうです。減算命令の出番。引いた結果が大きければ、さらに1ビット右シフトして~~~といった感じで引けなくなるまで繰り返します。

答えは2進数で 1111 0110。 不慣れなヒトにとって 0 と1 の組み合わせで0110 等の表記は見辛いことでしょう。理解するには、一番右を1として、2番目のビットが1なら2,3番目のビットが1なら4,4番目のビットが1なら8 を足してゆくことで変換し易くなります。例えば、2進数の 0110を10進数に変換する場合 4+2。
一度4ビット分ずつの16進数に直すと判り易いかもしれません。1111 は 8*1 + 4*1 + 2*1 + 1*1 となり 16進数で F , 10進数で15、同様に 0110 は 8*0 + 4*1 + 2*1 + 1*0 となり
16進数で 6、つまり 2進数で1111 0110 は16進数で F6となります。これは 15*16 + 6 となり、答えは10進数で246。

この辺の仕組みが判ってくれば、256ビット幅や512ビット幅の数値といった汎用レジスタのビット幅を超えるような数値の演算コードが書けるようになるかもしれません。
とはいえ、ソフトウェアレベルでの代替処理はハードウェアレベルで備わっているのに比べ高速さを求めるような場面では不利。かつて、「除算が遅い」の補足 (1)でソフトウェアレベルでの除算を代行するので遅くなる件を取り上げました。
32ビット版の OS において、途中結果が汎用レジスタの幅に収まらない ( 64ビット幅の整数など ) 場合は、割り算命令に相当する関数を呼出す ( ソフトウェアレベルでの代替 ) ので遅くなる。
同じ計算式のまま64ビット版の OS 上で64ビット版向けアプリとしてビルドすれば、整数の除算部は汎用レジスタを用いた命令に翻訳される、つまり、ハードウェアレベルでの処理が選択される。実行速度を低下させる原因を取り除ける。
32ビット整数値はおおよそプラスマイナス21億、64ビット幅の整数はさらにその42億倍。実際のところ、一般的な PC で必要とされる整数の範囲として不足はない。それでも足りないような高度な演算が必要なのであれば、ソフトウェアレベルでの高速化についてあれこれ調べ巡るよりも、高度な演算に特化した機材を調達することを考えた方が良いだろう・・・

さてさて、SSE4.2に至るまで整数の除算命令が追加されなかった、というよりも見送られてしまった謎が解けそうだ。
Pentium 4 でも 西暦2004年頃リリースされた、通称 Prescott と呼ばれる第三世代より SSE3 の命令が実行可能になった。それと同時に、64ビット環境への対応が施され、つまり、64ビット版のOS やアプリを実行できる仕組みが追加された。
64ビット環境が普及すればハードウェアレベルでの演算に切り替わることにより遅い部分が解消できる。64ビット版で汎用レジスタで扱える。そのほかにもXMM レジスタで 整数の除算命令を行えるような改良・追加も可能だったと推測できる。しかし、その分回路は複雑になり、さらに多くの電力を消費するような構造になる。



当時、Pentium 4 シリーズで消費電力の高さ、言い換えれば、燃費の悪さが問題視されていた。発表されたモデルのうち燃費の悪さ等が重り、出荷されなかったモデルもある。この辺を振り返ってみれば、追加できそうな機能のうちいくつかが省かれてしまったのもいたしかたない。

ではでは、32ビット環境において整数の除算を高速化しようと考えないほうが良い!?!?!?
いえいえ。少し発想を転換すれば道が見つかるかも。ヒントを挙げるとすれば、XMM レジスタで倍精度度浮動小数点値と 32 ビット整数値、もしくはその逆の変換が可能な点・・・

長くなりましたので今回はこの辺で・・・

本日も最後までご覧いただきありがとうございます。

「つまらなかった」「判り辛った」という方もご遠慮なくコメント欄へどうぞ

テーマ : プログラミング
ジャンル : コンピュータ

検索サイトからお越しの方へ
検索サイトからお越しの方は、ブラウザのアドレス欄vitalaboloveおよび、fc2.comが含まれているかご確認ください。
含まれていない場合、偽サイトを閲覧なされている可能性があります。

偽サイトは、当ブログの文字部分や画像部分が有害サイトへのバナーと置き換わっているようです。
プロフィール

Author:Vitalabolove
ご訪問ありがとうございます。
店長を任されておりますVitalaboloveです。

コメントはお気軽に。
今のところリンクフリーですが、あと数日でとりやめます。

画像データ、文言の引用は事前連絡くださるようお願い申し上げます。事前連絡の際は、左下、メールフォームを経由をご利用ください。

最新記事
カレンダー
01 | 2017/02 | 03
- - - 1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 - - - -
カテゴリ
ランキング
いつも応援いただきありがとうございました。ただいま休養中につきランキングへ参加していません・・・

フリーエリア
内緒話などはおきてがみをご利用ください。
月別アーカイブ
メールフォーム
掲載された記事について、ご不明な点はここからお問い合わせください

名前:
メール:
件名:
本文:

最新コメント
最新トラックバック
スパムと思われるトラックバックは削除しました
QRコード
QR
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。