タグ付けされた質問 「computer-architecture」

コンピュータハードウェアの構成と設計に関する質問。

3
関数型プログラミングのために純粋に設計されたCPUはどう違うのでしょうか?
CPUは、人々が暗黙的または明示的に作成するソフトウェアを念頭に置いて設計されています。 命令セットアーキテクチャの設計を見ると、各命令が命令型コマンドをエンコードするという意味で、それらは非常に「命令型」であるように思えます。また、現在の命令セットアーキテクチャは、プログラマが生成するコードのタイプに部分的に基づいて進化しているようにも思えます。 関数型プログラミングスタイルで記述されたプログラムのみを実行することを知って、CPUをゼロから設計する場合、そのCPUは既存のCPUとは異なるようにどのように設計されますか?

7
プログラムはCPUレベルでどのように実行されますか?
これはよくある質問です。しかし、私は心の中で異なる角度を持っています。ここで明確にしようとします。 私が知っていることから、CPUが実行するすべての命令は機械語であり、CPUができることはすべて、ALUとそのトランジスタのおかげで何らかの算術演算を行うことです(ハードウェアレベルの場合)。 ただし、これは理解するよりも入力する方が簡単です。すべてのCPUが加算、減算などを行うのであれば、これらの算術演算で実行されるプログラム、たとえば、印刷Hello WorldというJAVAプログラムはどうでしょうか。 つまり、このプログラムは、CPUに追加するだけのものにどのように変換されるのでしょうか。 PSこの質問がこのウェブサイトに当てはまらない場合は、おpoび申し上げます。 - - -二部 - - - はい。これに迅速かつ熱意を持って答えてくれたすべての人に感謝します。質問に少し手を加えて、すべての回答にコメントしてからもう一度質問するよりも良いと思いました。 ここにあります。 まず、全員がHello Worldの例について具体的に回答しています。これは私のせいだ。私はこれをジェネリックのままにしておくべきでした。Hello worldの例では、出力デバイスと、その処理がCPUだけに限定されるわけではないことを疑問視しています。 また、多くの人がCPUが単なる追加以上のことを行うことに気付きました。私はそれに同意します。私はただそれを書いておらず、ずっとそれを想定していました。私が理解していることから、これはプロセスです: メモリから命令を読み取る(データおよびアドレスバスとプログラムカウンタースタッフを使用) CPU内のレジスタにデータを保存する ALUはもちろん、命令をデコードした後、算術演算を行うか、ifのような命令の場合はジャンプします そして、出力デバイスなどのように、必要に応じて他のリソースと通信します。これ以上のプロセスは今のところ簡単です。 CPUが命令をデコードし、算術演算を実行することを決定するステップ3で(ここでは、現在の命令をジャンプするなど、他に実行すべき演算がないと仮定しています。 )ここで私の視覚化が終了します。プログラムからの命令がCPUの単なる算術演算である方法。それはその算術演算を行い、その命令はその目的を果たします。 今回は明確にしたいと思います。 PSここでは、ALUはプログラムで行う実際の算術演算に限定されず、バイナリ形式のすべての命令を実行するなど、それらを意味する結果を得るために加算または減算することで大きな仮定を取っています得た。ここで間違っている場合は、以下の回答が私の質問に正しく答えています。

6
間隔内の2つの数値の最大XORを見つける:二次式よりも良いことはできますか?
lllrrr L ≤ I 、最大(I ⊕ J )最大(私⊕j)\max{(i\oplus j)}L ≤ I 、J ≤ Rl≤私、j≤rl\le i,\,j\le r ナイーブアルゴリズムは、考えられるすべてのペアを単純にチェックします。たとえば、ルビーでは次のようになります。 def max_xor(l, r) max = 0 (l..r).each do |i| (i..r).each do |j| if (i ^ j > max) max = i ^ j end end end max end 私感私たちはより良い次より行うことができます。この問題のためのより良いアルゴリズムはありますか?


1
実際のキャッシュ忘却のパフォーマンスの評価に関する研究
キャッシュを無視するアルゴリズムとデータ構造は、Frigo et alによって導入されたかなり新しいものです。中のCache-忘れアルゴリズム、1999。同じ年のプロコップの論文も初期のアイデアを紹介しています。 Frigoらによる論文。理論と、キャッシュを無視するアルゴリズムとデータ構造の可能性を示すいくつかの実験結果を提示します。キャッシュを意識しないデータ構造の多くは、静的検索ツリーに基づいています。これらのツリーを保存およびナビゲートする方法は、おそらく最も顕著なものとして、Bender et al。また、Brodal et al。Demaineが概要を説明します。 実際にキャッシュの動作を調査する実験的な作業は、少なくともLadnerらによって行われました。でプログラム計装、2002を使用してキャッシュを意識し、キャッシュ紛失静的検索木のA比較。ラドナー等。古典的なアルゴリズム、キャッシュ忘却型アルゴリズム、キャッシュ対応アルゴリズムを使用して、バイナリ検索問題を解決するアルゴリズムのキャッシュ動作をベンチマークしました。各アルゴリズムは、暗黙的および明示的なナビゲーション方法の両方でベンチマークされました。これに加えて、2003年のRønnの論文では、同じアルゴリズムを非常に詳細に分析し、Ladner et al。と同じアルゴリズムのさらに徹底したテストも実行しました。 私の質問は それ以来、実際にキャッシュを使用しないアルゴリズムのキャッシュ動作のベンチマークに関する新しい研究はありますか?特に静的検索ツリーのパフォーマンスに興味がありますが、他のキャッシュを意識しないアルゴリズムとデータ構造にも満足しています。

3
割り込み後、プロセッサはどのようにカーネルコードを検出しますか?
割り込みが発生すると、プロセッサは現在のプロセスを横取りし、カーネルコードを呼び出して割り込みを処理します。プロセッサは、カーネルに入る場所をどのようにして知るのですか? 各割り込みラインにインストールできる割り込みハンドラがあることを理解しています。しかし、プロセッサーは「ハードワイヤードロジック」のみを実行するため、割り込みハンドラー自体、またはハンドラーの前に実行されるコードのいずれかを指す定義済みの場所が存在する必要があります(1つの割り込み行に複数のハンドラーがあるため、後者)。

3
消費電力をキャプチャできる抽象的なマシンはありますか?
アルゴリズムのアルゴリズムの複雑さを報告するとき、基礎となる計算は、最新のCPUに近い抽象的なマシン(RAMなど)で実行されると想定します。このようなモデルにより、アルゴリズムの時間と空間の複雑さを報告できます。さて、GPGPUの普及により、消費電力も考慮することができるよく知られたモデルがあるかどうか疑問に思います。 GPUはかなりの量の電力を消費することがよく知られており、特定の命令は、その複雑さと洗練されたチップ上の位置に基づいて、異なるカテゴリの電力消費に分類されます。したがって、指示のエネルギーは、エネルギーの観点から、単位(または固定)のコストではありません。取るに足らない拡張は、操作コストに重みを割り当てることですが、操作/命令がエネルギーの一定でない単位、たとえば多項式量(またはさらに複雑な例:開始から経過した時間の関数)を要する強力なモデルを探していますアルゴリズムの;または、冷却システムの故障の可能性を考慮して、チップを加熱し、クロック周波数を遅くするなど) 自明ではないコストと障害を組み込むことができるようなモデルはありますか?

1
GPGPUがある場合、なぜSIMDを使用するのですか?
この質問はStack ExchangeのCSの部分でより適切に処理されると思いました。CUDAやOpenCLなどの言語を使用するGPGPUができたので、マルチメディアSIMD拡張機能(SSE / AVX / NEON)はまだ目的を果たしていますか? 最近、SSE命令を使用してソートネットワークを加速する方法についての記事を読みました。私はこれはかなりきちんとしていると思いましたが、私のcomp arch教授に言ったとき、彼は笑い、GPUで同様のコードを実行するとSIMDバージョンを破壊すると言った。SSEは非常にシンプルで、GPUはより多くの並列処理を備えた大規模で複雑なアクセラレーターであるため、これは疑いありませんが、マルチメディアSIMD拡張機能がGPUを使用するよりも便利なシナリオはたくさんありますか? GPGPUがSIMDを冗長にする場合、インテルはなぜSIMDサポートを増やすのですか?SSEは128ビットでしたが、AVXでは256ビットになり、来年は512ビットになります。GPGPUがデータ並列処理を備えたより優れた処理コードである場合、インテルはなぜこれらのSIMD拡張機能をプッシュするのですか?それらは、同等のリソース(研究と領域)をより大きなキャッシュと分岐予測子に入れることができ、それによりシリアルパフォーマンスが向上します。 GPGPUではなくSIMDを使用する理由

5
将来の量子コンピューターは、2進数、3進数、または4進数の数値システムを使用しますか?
現在のコンピュータはビットを使用しているため、2進数システムを使用しています。しかし、将来の量子コンピュータは単純なビットの代わりにキュービットを使用すると聞いています。 「qubit」という言葉には「bi」という言葉があるので、私は最初に、これは量子コンピュータがバイナリ(base 2)を使用することを意味すると考えました。 しかし、その後、キュービットには3つの可能な状態があると聞きました。0、1、または0と1の重ね合わせです。そのため、これは3値(ベース3)を使用することを意味しているに違いないと考えました。 しかし、1キュビットで2ビットと同じだけの情報を保持できることがわかりました。だから、おそらくこれは彼らが第四級(ベース4)を使うことを意味していると思いました。 それでは、将来の量子コンピュータが使用する数値システムは、2進数、3進数、または4進数ですか?

2
CPUアーキテクチャは手続き型ランタイムに偏っていますか?
Rustのような同時実行時のパフォーマンスを向上させるためにCPUに変更を加えることはできますか?たとえば、同時実行に役立つ分岐予測の実装またはキャッシュサイズに変更はありますか? 現在のCPU設計は、Cのような手続き型ランタイムに対してより最適化されるかもしれないという印象を持っています。 例示のために、手続き予測コードを分析する研究論文に描かれた一般化に基づいて、分岐予測が実装されました。並行性の抽象化により、既存の分岐予測アルゴリズムに悪影響を与える重要なワーキングセットがランタイムに追加されるのではないかと思っています。たとえば、forループでの予測は1つのことですが、ブランチのターゲットが常にメモリの新しい部分(グラフィック、テキストなど)である場合、常にキャッシュミスであり、ブランチはありません。それの歴史-どちらもまだ触れていないからです。 これはおそらく馬鹿げた質問です。なぜなら、コンテンツは常にRAMにあるかもしれませんが、使用されるよりも小さい桁に分岐するからです(キャッシュに読み込まれたら)。手続き型ランタイムのキャッシュおよび分岐予測子に保存されているコンテキストの観察可能な時間境界である必要があります。これは、より並列化された環境で抽象化境界として明示されます。だから私は疑問に思う...これらの境界は観察されましたか?これを分析した研究論文はありますか? CPUアーキテクチャは、同時実行コードよりも手続き型コードに偏っていますか?または、最新のCPUは汎用性が高く、高度な同時実行言語が問題になりませんか?

2
コンピューターは実際にキャリールックアヘッド加算器を使用していますか?
大学のCSコースには、Kogge-Stone、Lander-Fischerなどのキャリールックアヘッドアダーに関する多くの詳細があります。それらは「業界で一般的」と表現されています。ただし、実際には具体的にどこでも使用されているという最近の証拠はありません(おそらくマンチェスターのキャリーチェーンを除いて)。Google検索では、ジャーナルと学術研究のページのみが返されます。せいぜい、架空の実装が与えられます。 私の質問は、キャリールックアヘッド加算器が使用される特定の場所/実装はありますか?または、それらは現実の世界とは無関係ですか?

5
OS設計で消費電力を削減できるのはなぜですか?
私は、AndroidやiOSのようなOSがバッテリー寿命を改善するために何らかの形で最適化されていることを読みました。 私の理解では、私はあなたが必要な操作の数を減らすことによって、アプリケーションをスピードアップすることができると思いますので、CPUは、一定時間内に操作が一定数を実行していることですが、CPUがまだ行いますので、Xに操業をyの時、それはいけません力に影響? また、プロセスがより多くのRAMを使用する場合、それはより多くの電力を消費しますか?

2
どの種類の分岐予測がより重要ですか?
分岐予測には2つの異なるタイプの状態があることがわかりました。 スーパースカラー実行では、分岐予測が非常に重要であり、フェッチ遅延ではなく実行遅延が主です。 命令パイプラインでは、命令は実際には後で実行されないため、フェッチがさらに問題になります。 これらのうちどれが非常に重要ですか(これらのどれが現在CPUで本当に重要であるかなど)?両方が同等に重要である場合、または2番目の方がより重要である場合、2つの命令パイプライン(おそらく長さの半分)がないのはなぜですか?次に、ブランチに応じて、それらの1つを選択してから、再び人口を開始しますはじめに?

2
「No mode bit」のData General MV / 8000の利点
私は、Data Generalのチームが新しいマシン(コードネームは「Eagle」、後にMV / 8000と名付けました)を設計するTracy Kidderの「The Soul of a New Machine」を読んでいます。これは、以前のアーキテクチャ(16ビットEclipse)の32ビット拡張です。進化しているテーマの1つは、モードビットを備えたマシンを作成したくないことと、これに成功したことです。 ただし、これが技術的にどのように達成されるかは省略し、モードビットのないマシンを作成することがそれほど魅力的だった理由についても触れていません。この本は技術書ではないため、詳細が多少歪んでいる可能性があります。ただし、この本を読んでいると、「モードビット」ソリューションが当時は一般的であり(したがって実現可能である)、見た目上の理由からエンジニアには魅力がないと見なされていたように感じます。この本はまた、モードビットなしでデザインを作成することは非常に困難な作業のように思われ、この特定のチームによって何らかの形で克服されました。 私はそれがどのように達成されたかについてのこの説明を見つけました: http://people.cs.clemson.edu/~mark/330/kidder/no_mode_bit.txt 基本的には、以前使用されていなかったオペコード空間の部分を新しい命令に使用することのようです。私はそれが「それだけ」だったことに少しがっかりしたことを認めなければなりません。また、これでも未解決の質問がいくつか残っていると思います。 まず、16ビットプロセスは32ビットアドレス空間にどのように存在しましたか。それは、32ビット拡張を「モードビットなしで」作成する際の重要な課題だと思うからです。一方、命令セットの拡張は比較的一般的な作業です。どのようにして起こったのかについての説明がないので、16ビットコードがいつものように単にメモリにアクセスすると想定することができます。おそらく、あるタイプのメモリの仮想化/バンクビュー(新しいCPUレジスタが最初のアドレスの場所を制御する)を見るかもしれません。そんな感じ。しかし、それ以上のものがあるかどうかはわかりません。その場合、一種の「モードビット」ソリューションであると主張することができます。16ビットモードのプロセスは、CPUに追加された特別な機能により、他のプロセスと並行して実行できます。 次に、モードビットのないマシンを作成することがなぜそれほど魅力的だったのでしょうか。この本で宣伝されている利点の多くは、顧客が古いソフトウェアを実行したいと思ったことです。ただし、モードビットを使用する目的は下位互換性を維持することなので、これはモードビットに反するようには見えません。AMDがx86を64ビットに拡張したとき、少なくとも「モードビット」という言葉に対する私の理解によれば、AMDが行ったことは正確にモードビットを追加することでした。CPUを64ビットモードにする特別なビット。また、プロセスを64ビットモードの「サブモード」で実行させるもう1つのビット(32ビットアプリケーションとの互換性を有効にするため)。サブモードの本質は、CPUが命令ストリームを古い32ビット命令として解釈するが、行われた32ビットメモリアクセスは新しいページテーブル形式(64ビット対応オペレーティングシステムによるセットアップ)を使用して解決され、最終的には完全な物理アドレス空間にマッピングされます。また、32ビットのコードは64ビットのコードに取って代わられます。Data Generalソリューションと同様に、これにより、32ビットプログラムを64ビットプログラムの下で実行することもできました(DGの場合は、16ビットと32ビット)。したがって、顧客の観点から見ると、まったく違いがないように見えます。したがって、唯一の利点は実装にあり、設計を簡素化することでしたが、この本はそれが問題であるように聞こえません。モードビットはその時点でも一般的であると思われるためです(そして、それ以降のアーキテクチャでもx64ケースが示すようにそれを採用しました)。 私が見逃したものがあると私は確信しているので、誰かがこの「モードビットなし」の設計の技術的な詳細と長所についてもっと議論できたら素晴らしいでしょう。

1
ハイパースレッディングを使用するとパフォーマンスが低下する理由
ハイパースレッディングがパフォーマンスの低下につながることを、このようなさまざまな場所で読んだことがあります。 ハイパースレッディングがパフォーマンスの低下を引き起こす理由と方法を理解できません。 なぜハイパースレッディングによってOSが空きリソースを利用できるようになっても、パフォーマンスが低下するのはなぜですか。 ベンチマークはハイパースレッディングを原因として示していますが、誰かがこの理由を説明できます。 ありがとう

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.