mirror of
https://github.com/krahets/hello-algo.git
synced 2026-07-16 00:46:06 +00:00
deploy
This commit is contained in:
krahets
File diff suppressed because it is too large
Load Diff
@@ -6,7 +6,7 @@
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width,initial-scale=1">
|
||||
|
||||
<meta name="description" content="アニメーションで図解、ワンクリック実行のデータ構造とアルゴリズムチュートリアル">
|
||||
<meta name="description" content="アニメーション図解とワンクリック実行コードで学べるデータ構造とアルゴリズムの入門書">
|
||||
|
||||
|
||||
<meta name="author" content="krahets">
|
||||
@@ -117,7 +117,7 @@
|
||||
<path
|
||||
d="M480 32c0-12.9-7.8-24.6-19.8-29.6s-25.7-2.2-34.9 6.9L381.7 53c-48 48-113.1 75-181 75H192 160 64c-35.3 0-64 28.7-64 64v96c0 35.3 28.7 64 64 64l0 128c0 17.7 14.3 32 32 32h64c17.7 0 32-14.3 32-32V352l8.7 0c67.9 0 133 27 181 75l43.6 43.6c9.2 9.2 22.9 11.9 34.9 6.9s19.8-16.6 19.8-29.6V300.4c18.6-8.8 32-32.5 32-60.4s-13.4-51.6-32-60.4V32zm-64 76.7V240 371.3C357.2 317.8 280.5 288 200.7 288H192V192h8.7c79.8 0 156.5-29.8 215.3-83.3z" />
|
||||
</svg>
|
||||
<span>日本語版審閱者を募集しています！詳細は <a href="https://github.com/krahets/hello-algo/blob/main/ja/CONTRIBUTING.md">CONTRIBUTING.md</a> を参照してください。</span>
|
||||
<span>日本語版のレビュアーを募集しています。詳しくは <a href="/ja/chapter_appendix/contribution/">こちら</a> をご覧ください。</span>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
@@ -341,7 +341,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
序
|
||||
はじめに
|
||||
|
||||
|
||||
|
||||
@@ -358,7 +358,7 @@
|
||||
<span class="md-nav__icon md-icon"></span>
|
||||
|
||||
|
||||
序
|
||||
はじめに
|
||||
|
||||
|
||||
</label>
|
||||
@@ -618,7 +618,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
1.1 アルゴリズムはどこにでもある
|
||||
1.1 アルゴリズムは至るところにある
|
||||
|
||||
|
||||
|
||||
@@ -646,7 +646,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
1.2 アルゴリズムとは何か
|
||||
1.2 アルゴリズムとは
|
||||
|
||||
|
||||
|
||||
@@ -783,7 +783,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
2.1 アルゴリズムの効率評価
|
||||
2.1 アルゴリズム効率の評価
|
||||
|
||||
|
||||
|
||||
@@ -1060,7 +1060,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
3.3 数値の符号化 *
|
||||
3.3 数値エンコーディング *
|
||||
|
||||
|
||||
|
||||
@@ -1088,7 +1088,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
3.4 文字の符号化 *
|
||||
3.4 文字エンコーディング *
|
||||
|
||||
|
||||
|
||||
@@ -1593,7 +1593,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
第 6 章 ハッシュ表
|
||||
第 6 章 ハッシュテーブル
|
||||
|
||||
|
||||
|
||||
@@ -1615,7 +1615,7 @@
|
||||
<span class="md-nav__icon md-icon"></span>
|
||||
|
||||
|
||||
第 6 章 ハッシュ表
|
||||
第 6 章 ハッシュテーブル
|
||||
|
||||
|
||||
</label>
|
||||
@@ -1637,7 +1637,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
6.1 ハッシュ表
|
||||
6.1 ハッシュテーブル
|
||||
|
||||
|
||||
|
||||
@@ -1944,7 +1944,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
7.5 AVL木 *
|
||||
7.5 AVL 木 *
|
||||
|
||||
|
||||
|
||||
@@ -2107,7 +2107,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
8.2 ヒープ構築操作
|
||||
8.2 ヒープ構築
|
||||
|
||||
|
||||
|
||||
@@ -2493,7 +2493,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
10.2 二分探索の挿入点
|
||||
10.2 二分探索の挿入位置
|
||||
|
||||
|
||||
|
||||
@@ -2549,7 +2549,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
10.4 ハッシュ最適化戦略
|
||||
10.4 ハッシュによる最適化戦略
|
||||
|
||||
|
||||
|
||||
@@ -2577,7 +2577,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
10.5 探索アルゴリズムの再認識
|
||||
10.5 探索アルゴリズム再考
|
||||
|
||||
|
||||
|
||||
@@ -3115,7 +3115,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
12.1 分割統治アルゴリズム
|
||||
12.1 分割統治法
|
||||
|
||||
|
||||
|
||||
@@ -3171,7 +3171,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
12.3 木の構築問題
|
||||
12.3 二分木の構築問題
|
||||
|
||||
|
||||
|
||||
@@ -3199,7 +3199,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
12.4 ハノイの塔問題
|
||||
12.4 ハノイの塔の問題
|
||||
|
||||
|
||||
|
||||
@@ -3392,7 +3392,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
13.3 部分集合和問題
|
||||
13.3 部分和問題
|
||||
|
||||
|
||||
|
||||
@@ -3420,7 +3420,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
13.4 Nクイーン問題
|
||||
13.4 n クイーン問題
|
||||
|
||||
|
||||
|
||||
@@ -3561,7 +3561,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
14.1 動的計画法の初歩
|
||||
14.1 動的計画法入門
|
||||
|
||||
|
||||
|
||||
@@ -3589,7 +3589,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
14.2 DP 問題の特性
|
||||
14.2 動的計画法の問題特性
|
||||
|
||||
|
||||
|
||||
@@ -3617,7 +3617,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
14.3 DP の解法の考え方
|
||||
14.3 動的計画法の問題解決の考え方
|
||||
|
||||
|
||||
|
||||
@@ -3645,7 +3645,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
14.4 0-1ナップサック問題
|
||||
14.4 0-1 ナップサック問題
|
||||
|
||||
|
||||
|
||||
@@ -3838,7 +3838,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
15.1 貪欲アルゴリズム
|
||||
15.1 貪欲法
|
||||
|
||||
|
||||
|
||||
@@ -4083,7 +4083,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
16.2 一緒に創作に参加する
|
||||
16.2 一緒に制作に参加しましょう
|
||||
|
||||
|
||||
|
||||
@@ -4277,8 +4277,8 @@
|
||||
<p><img alt="配列と連結リスト" class="cover-image" src="../assets/covers/chapter_array_and_linkedlist.jpg" /></p>
|
||||
<div class="admonition abstract">
|
||||
<p class="admonition-title">Abstract</p>
|
||||
<p>データ構造の世界は頑丈なレンガの壁に似ています。</p>
|
||||
<p>配列では、レンガがぴったりと整列し、それぞれが次のものと継ぎ目なく隣り合って、統一された形成を作っている姿を想像してください。一方、連結リストでは、これらのレンガが自由に散らばり、それらの間を優雅に編み込む蔦に抱かれています。</p>
|
||||
<p>データ構造の世界は、まるで重厚なれんがの壁のようです。</p>
|
||||
<p>配列のれんがは整然と並び、一つひとつがぴったりと接しています。連結リストのれんがはあちこちに分散し、それらをつなぐつるがれんがのすき間を自由に行き交います。</p>
|
||||
</div>
|
||||
<h2 id="_1">章の内容<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
|
||||
<ul>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -6,7 +6,7 @@
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width,initial-scale=1">
|
||||
|
||||
<meta name="description" content="アニメーションで図解、ワンクリック実行のデータ構造とアルゴリズムチュートリアル">
|
||||
<meta name="description" content="アニメーション図解とワンクリック実行コードで学べるデータ構造とアルゴリズムの入門書">
|
||||
|
||||
|
||||
<meta name="author" content="krahets">
|
||||
@@ -117,7 +117,7 @@
|
||||
<path
|
||||
d="M480 32c0-12.9-7.8-24.6-19.8-29.6s-25.7-2.2-34.9 6.9L381.7 53c-48 48-113.1 75-181 75H192 160 64c-35.3 0-64 28.7-64 64v96c0 35.3 28.7 64 64 64l0 128c0 17.7 14.3 32 32 32h64c17.7 0 32-14.3 32-32V352l8.7 0c67.9 0 133 27 181 75l43.6 43.6c9.2 9.2 22.9 11.9 34.9 6.9s19.8-16.6 19.8-29.6V300.4c18.6-8.8 32-32.5 32-60.4s-13.4-51.6-32-60.4V32zm-64 76.7V240 371.3C357.2 317.8 280.5 288 200.7 288H192V192h8.7c79.8 0 156.5-29.8 215.3-83.3z" />
|
||||
</svg>
|
||||
<span>日本語版審閱者を募集しています！詳細は <a href="https://github.com/krahets/hello-algo/blob/main/ja/CONTRIBUTING.md">CONTRIBUTING.md</a> を参照してください。</span>
|
||||
<span>日本語版のレビュアーを募集しています。詳しくは <a href="/ja/chapter_appendix/contribution/">こちら</a> をご覧ください。</span>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
@@ -341,7 +341,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
序
|
||||
はじめに
|
||||
|
||||
|
||||
|
||||
@@ -358,7 +358,7 @@
|
||||
<span class="md-nav__icon md-icon"></span>
|
||||
|
||||
|
||||
序
|
||||
はじめに
|
||||
|
||||
|
||||
</label>
|
||||
@@ -618,7 +618,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
1.1 アルゴリズムはどこにでもある
|
||||
1.1 アルゴリズムは至るところにある
|
||||
|
||||
|
||||
|
||||
@@ -646,7 +646,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
1.2 アルゴリズムとは何か
|
||||
1.2 アルゴリズムとは
|
||||
|
||||
|
||||
|
||||
@@ -783,7 +783,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
2.1 アルゴリズムの効率評価
|
||||
2.1 アルゴリズム効率の評価
|
||||
|
||||
|
||||
|
||||
@@ -1060,7 +1060,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
3.3 数値の符号化 *
|
||||
3.3 数値エンコーディング *
|
||||
|
||||
|
||||
|
||||
@@ -1088,7 +1088,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
3.4 文字の符号化 *
|
||||
3.4 文字エンコーディング *
|
||||
|
||||
|
||||
|
||||
@@ -1368,7 +1368,7 @@
|
||||
<a href="#441" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
4.4.1 コンピュータ記憶装置
|
||||
4.4.1 コンピュータの記憶装置
|
||||
|
||||
</span>
|
||||
</a>
|
||||
@@ -1674,7 +1674,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
第 6 章 ハッシュ表
|
||||
第 6 章 ハッシュテーブル
|
||||
|
||||
|
||||
|
||||
@@ -1696,7 +1696,7 @@
|
||||
<span class="md-nav__icon md-icon"></span>
|
||||
|
||||
|
||||
第 6 章 ハッシュ表
|
||||
第 6 章 ハッシュテーブル
|
||||
|
||||
|
||||
</label>
|
||||
@@ -1718,7 +1718,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
6.1 ハッシュ表
|
||||
6.1 ハッシュテーブル
|
||||
|
||||
|
||||
|
||||
@@ -2025,7 +2025,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
7.5 AVL木 *
|
||||
7.5 AVL 木 *
|
||||
|
||||
|
||||
|
||||
@@ -2188,7 +2188,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
8.2 ヒープ構築操作
|
||||
8.2 ヒープ構築
|
||||
|
||||
|
||||
|
||||
@@ -2574,7 +2574,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
10.2 二分探索の挿入点
|
||||
10.2 二分探索の挿入位置
|
||||
|
||||
|
||||
|
||||
@@ -2630,7 +2630,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
10.4 ハッシュ最適化戦略
|
||||
10.4 ハッシュによる最適化戦略
|
||||
|
||||
|
||||
|
||||
@@ -2658,7 +2658,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
10.5 探索アルゴリズムの再認識
|
||||
10.5 探索アルゴリズム再考
|
||||
|
||||
|
||||
|
||||
@@ -3196,7 +3196,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
12.1 分割統治アルゴリズム
|
||||
12.1 分割統治法
|
||||
|
||||
|
||||
|
||||
@@ -3252,7 +3252,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
12.3 木の構築問題
|
||||
12.3 二分木の構築問題
|
||||
|
||||
|
||||
|
||||
@@ -3280,7 +3280,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
12.4 ハノイの塔問題
|
||||
12.4 ハノイの塔の問題
|
||||
|
||||
|
||||
|
||||
@@ -3473,7 +3473,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
13.3 部分集合和問題
|
||||
13.3 部分和問題
|
||||
|
||||
|
||||
|
||||
@@ -3501,7 +3501,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
13.4 Nクイーン問題
|
||||
13.4 n クイーン問題
|
||||
|
||||
|
||||
|
||||
@@ -3642,7 +3642,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
14.1 動的計画法の初歩
|
||||
14.1 動的計画法入門
|
||||
|
||||
|
||||
|
||||
@@ -3670,7 +3670,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
14.2 DP 問題の特性
|
||||
14.2 動的計画法の問題特性
|
||||
|
||||
|
||||
|
||||
@@ -3698,7 +3698,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
14.3 DP の解法の考え方
|
||||
14.3 動的計画法の問題解決の考え方
|
||||
|
||||
|
||||
|
||||
@@ -3726,7 +3726,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
14.4 0-1ナップサック問題
|
||||
14.4 0-1 ナップサック問題
|
||||
|
||||
|
||||
|
||||
@@ -3919,7 +3919,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
15.1 貪欲アルゴリズム
|
||||
15.1 貪欲法
|
||||
|
||||
|
||||
|
||||
@@ -4164,7 +4164,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
16.2 一緒に創作に参加する
|
||||
16.2 一緒に制作に参加しましょう
|
||||
|
||||
|
||||
|
||||
@@ -4310,7 +4310,7 @@
|
||||
<a href="#441" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
4.4.1 コンピュータ記憶装置
|
||||
4.4.1 コンピュータの記憶装置
|
||||
|
||||
</span>
|
||||
</a>
|
||||
@@ -4377,11 +4377,11 @@
|
||||
|
||||
<!-- Page content -->
|
||||
<h1 id="44">4.4 メモリとキャッシュ *<a class="headerlink" href="#44" title="Permanent link">¶</a></h1>
|
||||
<p>この章の最初の2つのセクションでは、「連続格納」と「分散格納」をそれぞれ表現する2つの基本的なデータ構造である配列と連結リストを探究しました。</p>
|
||||
<p>実際、<strong>物理構造はプログラムがメモリとキャッシュをどの程度効率的に利用するかを大きく決定し</strong>、これがアルゴリズムの全体的なパフォーマンスに影響を与えます。</p>
|
||||
<h2 id="441">4.4.1 コンピュータ記憶装置<a class="headerlink" href="#441" title="Permanent link">¶</a></h2>
|
||||
<p>コンピュータには3種類の記憶装置があります：<u>ハードディスク</u>、<u>ランダムアクセスメモリ（RAM）</u>、および<u>キャッシュメモリ</u>です。以下の表は、コンピュータシステムにおけるそれぞれの役割とパフォーマンス特性を示しています。</p>
|
||||
<p align="center"> 表 4-2 コンピュータ記憶装置 </p>
|
||||
<p>本章の前二節では、配列と連結リストという二つの基礎的かつ重要なデータ構造を扱いました。これらはそれぞれ「連続格納」と「分散格納」という二つの物理構造を表しています。</p>
|
||||
<p>実際には、<strong>物理構造はプログラムにおけるメモリとキャッシュの利用効率を大きく左右し</strong>、ひいてはアルゴリズムプログラム全体の性能に影響します。</p>
|
||||
<h2 id="441">4.4.1 コンピュータの記憶装置<a class="headerlink" href="#441" title="Permanent link">¶</a></h2>
|
||||
<p>コンピュータには三種類の記憶装置があります。<u>ハードディスク（hard disk）</u>、<u>メモリ（random-access memory, RAM）</u>、<u>キャッシュ（cache memory）</u>です。以下の表は、これらがコンピュータシステムで担う役割と性能上の特徴を示しています。</p>
|
||||
<p align="center"> 表 4-2 コンピュータの記憶装置 </p>
|
||||
|
||||
<div class="center-table">
|
||||
<table>
|
||||
@@ -4396,80 +4396,80 @@
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>用途</td>
|
||||
<td>OS、プログラム、ファイルなどのデータの長期保存</td>
|
||||
<td>現在実行中のプログラムと処理中のデータの一時保存</td>
|
||||
<td>頻繁にアクセスされるデータと命令を保存し、CPUのメモリへのアクセス数を削減</td>
|
||||
<td>OS、プログラム、ファイルなどを長期保存</td>
|
||||
<td>実行中のプログラムや処理中のデータを一時保存</td>
|
||||
<td>頻繁にアクセスされるデータや命令を保存し、CPU のメモリアクセス回数を減らす</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>揮発性</td>
|
||||
<td>電源オフ後もデータは失われない</td>
|
||||
<td>電源オフ後にデータは失われる</td>
|
||||
<td>電源オフ後にデータは失われる</td>
|
||||
<td>電源断後もデータは失われない</td>
|
||||
<td>電源断後にデータは失われる</td>
|
||||
<td>電源断後にデータは失われる</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>容量</td>
|
||||
<td>より大きい、TBレベル</td>
|
||||
<td>より小さい、GBレベル</td>
|
||||
<td>非常に小さい、MBレベル</td>
|
||||
<td>大きい、TB 級</td>
|
||||
<td>小さい、GB 級</td>
|
||||
<td>非常に小さい、MB 級</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>速度</td>
|
||||
<td>より遅い、数百から数千MB/s</td>
|
||||
<td>より高速、数十GB/s</td>
|
||||
<td>非常に高速、数十から数百GB/s</td>
|
||||
<td>遅い、数百〜数千 MB/s</td>
|
||||
<td>速い、数十 GB/s</td>
|
||||
<td>非常に速い、数十〜数百 GB/s</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>価格（USD）</td>
|
||||
<td>より安価、数セント/GB</td>
|
||||
<td>より高価、数ドル/GB</td>
|
||||
<td>非常に高価、CPUと一緒に価格設定</td>
|
||||
<td>価格（人民元）</td>
|
||||
<td>比較的安価、数角〜数元 / GB</td>
|
||||
<td>比較的高価、数十〜数百元 / GB</td>
|
||||
<td>非常に高価、CPU と一体で価格設定される</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<p>コンピュータ記憶システムは、下図に示すようにピラミッドとして視覚化できます。ピラミッドの上部にある記憶装置ほど高速で、容量が小さく、より高価です。このマルチレベル設計は偶然ではなく、コンピュータ科学者とエンジニアによる慎重な検討の結果です。</p>
|
||||
<p>コンピュータの記憶システムは、下図のようなピラミッド構造として捉えられます。ピラミッドの頂点に近い記憶装置ほど速度は速く、容量は小さく、コストは高くなります。この多層構造は偶然ではなく、コンピュータ科学者やエンジニアによる熟慮の末の設計です。</p>
|
||||
<ul>
|
||||
<li><strong>ハードディスクをメモリに置き換えるのは困難です</strong>。第一に、メモリ内のデータは電源オフ後に失われるため、長期データ保存には適していません。第二に、メモリはハードディスクよりも大幅に高価で、消費者市場での広範囲な使用の実現可能性を制限しています。</li>
|
||||
<li><strong>キャッシュは大容量と高速のトレードオフに直面しています</strong>。L1、L2、L3キャッシュの容量が増加するにつれて、その物理サイズが大きくなり、CPUコアからの距離が増加します。これによりデータ転送時間が長くなり、アクセス遅延が高くなります。現在の技術では、マルチレベルキャッシュ構造が容量、速度、コストの間の最適なバランスを提供します。</li>
|
||||
<li><strong>ハードディスクはメモリで置き換えにくい</strong>。まず、メモリ内のデータは電源断後に失われるため、長期保存には向きません。次に、メモリのコストはハードディスクの数十倍であり、消費者市場で広く普及しにくいという問題があります。</li>
|
||||
<li><strong>キャッシュは大容量と高速性を両立しにくい</strong>。L1、L2、L3 キャッシュの容量が段階的に増えるにつれて、物理サイズは大きくなり、CPU コアとの物理的距離も遠くなります。その結果、データ転送時間が増え、要素アクセスの遅延も大きくなります。現在の技術では、多層キャッシュ構造が容量、速度、コストの最適なバランスです。</li>
|
||||
</ul>
|
||||
<p><img alt="コンピュータ記憶システム" class="animation-figure" src="../ram_and_cache.assets/storage_pyramid.png" /></p>
|
||||
<p align="center"> 図 4-9 コンピュータ記憶システム </p>
|
||||
<p><img alt="コンピュータの記憶システム" class="animation-figure" src="../ram_and_cache.assets/storage_pyramid.png" /></p>
|
||||
<p align="center"> 図 4-9 コンピュータの記憶システム </p>
|
||||
|
||||
<div class="admonition tip">
|
||||
<p class="admonition-title">Tip</p>
|
||||
<p>コンピュータの記憶階層は、速度、容量、コストの間の慎重なバランスを反映しています。このタイプのトレードオフは様々な業界で一般的であり、利益と制限の間の最適なバランスを見つけることが重要です。</p>
|
||||
<p>コンピュータの記憶階層は、速度、容量、コストの三者間にある巧妙なバランスを体現しています。実際、このようなトレードオフはあらゆる工業分野に広く存在しており、異なる利点と制約のあいだで最適な均衡点を見つけることが求められます。</p>
|
||||
</div>
|
||||
<p>全体的に、<strong>ハードディスクは大量のデータの長期保存を提供し、メモリはプログラム実行中に処理されるデータの一時保存として機能し、キャッシュは頻繁にアクセスされるデータと命令を保存して実行効率を向上させます</strong>。それらは一緒になってコンピュータシステムの効率的な動作を保証します。</p>
|
||||
<p>下図に示すように、プログラム実行中、データはハードディスクからメモリに読み込まれ、CPU計算が行われます。CPUの拡張として機能するキャッシュは、**メモリからインテリジェントにデータを先読み**し、CPUのより高速なデータアクセスを可能にします。これによりプログラム実行効率が大幅に向上し、低速なメモリへの依存が減少します。</p>
|
||||
<p><img alt="ハードディスク、メモリ、キャッシュ間のデータフロー" class="animation-figure" src="../ram_and_cache.assets/computer_storage_devices.png" /></p>
|
||||
<p align="center"> 図 4-10 ハードディスク、メモリ、キャッシュ間のデータフロー </p>
|
||||
<p>要するに、<strong>ハードディスクは大量データの長期保存に、メモリはプログラム実行中に処理しているデータの一時保存に、キャッシュは頻繁にアクセスされるデータや命令の保存に用いられ</strong>、プログラム実行効率を高めます。三者は協調して動作し、コンピュータシステムの高効率な運用を支えています。</p>
|
||||
<p>次の図に示すように、プログラム実行時にはデータがハードディスクからメモリへ読み込まれ、CPU の計算に使われます。キャッシュは CPU の一部と見なせ、<strong>メモリからデータを賢く読み込むことで</strong>、CPU に高速なデータ読み出しを提供し、プログラムの実行効率を大きく高め、低速なメモリへの依存を減らします。</p>
|
||||
<p><img alt="ハードディスク、メモリ、キャッシュ間のデータの流れ" class="animation-figure" src="../ram_and_cache.assets/computer_storage_devices.png" /></p>
|
||||
<p align="center"> 図 4-10 ハードディスク、メモリ、キャッシュ間のデータの流れ </p>
|
||||
|
||||
<h2 id="442">4.4.2 データ構造のメモリ効率<a class="headerlink" href="#442" title="Permanent link">¶</a></h2>
|
||||
<p>メモリ空間利用の観点から、配列と連結リストにはそれぞれ利点と制限があります。</p>
|
||||
<p>一方で、**メモリは限られており、複数のプログラム間で共有できない**ため、データ構造での空間使用の最適化は重要です。配列は要素が密接にパックされており、連結リストのように参照（ポインタ）のための追加メモリを必要としないため、空間効率的です。しかし、配列は連続したメモリブロックを事前に割り当てる必要があり、割り当てられた空間が実際の必要量を超える場合、無駄につながる可能性があります。配列の拡張も追加の時間と空間のオーバーヘッドを伴います。対照的に、連結リストは各ノードに対してメモリを動的に割り当て・解放し、ポインタのための追加メモリのコストでより大きな柔軟性を提供します。</p>
|
||||
<p>一方で、プログラム実行中、<strong>繰り返されるメモリの割り当てと解放はメモリの断片化を増加させ</strong>、メモリ利用効率を低下させます。配列は連続記憶方式により、メモリ断片化を引き起こす可能性が比較的低いです。対照的に、連結リストは要素を非連続の場所に保存し、頻繁な挿入と削除はメモリ断片化を悪化させる可能性があります。</p>
|
||||
<p>メモリ空間の利用という観点では、配列と連結リストにはそれぞれ利点と制約があります。</p>
|
||||
<p>一方で、<strong>メモリは有限であり、同じメモリ領域を複数のプログラムで共有することはできません</strong>。そのため、データ構造にはできるだけ効率よく空間を使うことが求められます。配列の要素は密に並んでおり、連結リストのノード間参照（ポインタ）を保持する追加領域が不要なため、空間効率は高くなります。しかし、配列は十分な連続メモリを一度に確保する必要があり、メモリ浪費を招くことがありますし、拡張時にも追加の時間と空間コストがかかります。これに対して連結リストは「ノード」単位で動的にメモリを割り当て・解放でき、より高い柔軟性を備えています。</p>
|
||||
<p>他方で、プログラムの実行中には、<strong>メモリの確保と解放を繰り返すにつれて、空きメモリの断片化はますます進み</strong>、メモリ利用効率の低下を招きます。配列は連続した格納方式を取るため、比較的メモリ断片化を起こしにくい構造です。反対に、連結リストの要素は分散して格納されるため、頻繁な挿入や削除を行うと、より断片化を招きやすくなります。</p>
|
||||
<h2 id="443">4.4.3 データ構造のキャッシュ効率<a class="headerlink" href="#443" title="Permanent link">¶</a></h2>
|
||||
<p>キャッシュはメモリよりも空間容量がはるかに小さいですが、はるかに高速で、プログラム実行速度において重要な役割を果たします。限られた容量のため、キャッシュは頻繁にアクセスされるデータのサブセットのみを保存できます。CPUがキャッシュに存在しないデータにアクセスしようとすると、<u>キャッシュミス</u>が発生し、CPUは低速なメモリから必要なデータを取得する必要があり、パフォーマンスに影響を与える可能性があります。</p>
|
||||
<p>明らかに、<strong>キャッシュミスが少ないほど、CPUのデータ読み書き効率が高く</strong>、プログラムパフォーマンスが向上します。CPUがキャッシュからデータを正常に取得する割合は<u>キャッシュヒット率</u>と呼ばれ、キャッシュ効率を測定するためによく使用される指標です。</p>
|
||||
<p>より高い効率を達成するために、キャッシュは以下のデータロードメカニズムを採用します。</p>
|
||||
<p>キャッシュは容量こそメモリよりはるかに小さいものの、速度はメモリよりずっと速く、プログラム実行速度において極めて重要な役割を果たします。キャッシュ容量には限りがあり、頻繁にアクセスされる一部のデータしか保持できません。そのため、CPU がアクセスしようとするデータがキャッシュ内に存在しない場合、<u>キャッシュミス（cache miss）</u>が発生し、CPU は低速なメモリから必要なデータを読み込まなければなりません。</p>
|
||||
<p>当然ながら、<strong>「キャッシュミス」が少ないほど、CPU のデータ読み書き効率は高くなり</strong>、プログラム性能も向上します。CPU がキャッシュからデータを正常に取得できた割合を<u>キャッシュヒット率（cache hit rate）</u>と呼び、この指標は通常、キャッシュ効率の評価に用いられます。</p>
|
||||
<p>できるだけ高い効率を実現するため、キャッシュは次のようなデータ読み込みの仕組みを採用しています。</p>
|
||||
<ul>
|
||||
<li><strong>キャッシュライン</strong>：キャッシュは個々のバイトではなく、キャッシュラインと呼ばれる単位でデータを保存・ロードして動作します。このアプローチは、一度により大きなデータブロックを転送することで効率を向上させます。</li>
|
||||
<li><strong>先読みメカニズム</strong>：プロセッサはデータアクセスパターン（例：連続または固定ストライドアクセス）を予測し、これらのパターンに基づいてデータをキャッシュに先読みして、キャッシュヒット率を向上させます。</li>
|
||||
<li><strong>空間的局所性</strong>：特定のデータがアクセスされると、近くのデータもまもなくアクセスされる可能性があります。これを活用するために、キャッシュは要求されたデータと一緒に隣接するデータをロードし、ヒット率を向上させます。</li>
|
||||
<li><strong>時間的局所性</strong>：データがアクセスされた場合、近い将来に再びアクセスされる可能性があります。キャッシュはこの原理を使用して、最近アクセスされたデータを保持してヒット率を向上させます。</li>
|
||||
<li><strong>キャッシュライン</strong>：キャッシュはデータを 1 バイト単位で保存・読み込みするのではなく、キャッシュライン単位で扱います。1 バイト単位の転送と比べて、キャッシュライン単位のほうが効率的です。</li>
|
||||
<li><strong>プリフェッチ機構</strong>：プロセッサはデータアクセスのパターン（たとえば順次アクセス、一定ステップ幅のスキップアクセスなど）を予測し、そのパターンに応じてデータをキャッシュへ読み込むことで、ヒット率を高めます。</li>
|
||||
<li><strong>空間的局所性</strong>：あるデータがアクセスされた場合、その近傍のデータも近いうちにアクセスされる可能性があります。そのため、キャッシュはあるデータを読み込む際に、その周辺のデータもあわせて読み込み、ヒット率を高めます。</li>
|
||||
<li><strong>時間的局所性</strong>：あるデータがアクセスされた場合、そのデータは近い将来に再びアクセスされる可能性が高いです。キャッシュはこの性質を利用し、最近アクセスしたデータを保持することでヒット率を高めます。</li>
|
||||
</ul>
|
||||
<p>実際、<strong>配列と連結リストは異なるキャッシュ利用効率を持ち</strong>、これは主に以下の側面に反映されます。</p>
|
||||
<p>実際には、<strong>配列と連結リストではキャッシュの利用効率が異なり</strong>、主に次の点に表れます。</p>
|
||||
<ul>
|
||||
<li><strong>占有空間</strong>：連結リスト要素は配列要素よりも多くの空間を占有するため、キャッシュに保持される有効データが少なくなります。</li>
|
||||
<li><strong>キャッシュライン</strong>：連結リストデータはメモリ全体に散在し、キャッシュは「行単位でロード」されるため、ロードされる無効データの割合が高くなります。</li>
|
||||
<li><strong>先読みメカニズム</strong>：配列のデータアクセスパターンは連結リストよりも「予測可能」で、つまりシステムがこれからロードされるデータを推測しやすいです。</li>
|
||||
<li><strong>空間的局所性</strong>：配列は連続したメモリ空間に保存されるため、ロードされているデータの近くのデータがまもなくアクセスされる可能性が高くなります。</li>
|
||||
<li><strong>使用空間</strong>：連結リストの要素は配列要素より多くの空間を占めるため、キャッシュに収まる有効データ量は少なくなります。</li>
|
||||
<li><strong>キャッシュライン</strong>：連結リストのデータはメモリの各所に分散しており、キャッシュは「ライン単位で読み込む」ため、無効データまで読み込む割合が高くなります。</li>
|
||||
<li><strong>プリフェッチ機構</strong>：配列のほうが連結リストよりもデータアクセスのパターンを「予測しやすく」、システムが次に読み込まれるデータを推測しやすくなります。</li>
|
||||
<li><strong>空間的局所性</strong>：配列はまとまったメモリ空間に格納されるため、読み込まれたデータの近くにあるデータも、まもなくアクセスされる可能性が高くなります。</li>
|
||||
</ul>
|
||||
<p>全体的に、<strong>配列はより高いキャッシュヒット率を持ち、一般的に連結リストよりも操作効率が高いです</strong>。これにより、配列に基づくデータ構造はアルゴリズム問題の解決において人気があります。</p>
|
||||
<p>**高いキャッシュ効率が配列が常に連結リストより優れているという意味ではない**ことに注意すべきです。データ構造の選択は特定のアプリケーション要件に依存すべきです。例えば、配列と連結リストの両方が「スタック」データ構造を実装できますが（次章で詳細説明）、それらは異なるシナリオに適しています。</p>
|
||||
<p>全体として、<strong>配列はより高いキャッシュヒット率を持つため、操作効率では通常、連結リストより優れています</strong>。このため、アルゴリズム問題を解く際には、配列ベースで実装されたデータ構造のほうが好まれることが多くなります。</p>
|
||||
<p>注意すべきなのは、**キャッシュ効率が高いからといって、配列があらゆる状況で連結リストより優れているとは限らない**という点です。実際にどのデータ構造を選ぶかは、具体的な要件に応じて決めるべきです。たとえば、配列と連結リストはいずれも「スタック」データ構造を実装できますが（次章で詳しく説明します）、適した場面は異なります。</p>
|
||||
<ul>
|
||||
<li>アルゴリズム問題では、より高い操作効率とランダムアクセス機能を提供するため、配列に基づくスタックを選択する傾向があります。唯一のコストは配列に対して一定量のメモリ空間を事前に割り当てる必要があることです。</li>
|
||||
<li>データ量が非常に大きく、高度に動的で、スタックの予想サイズを推定するのが困難な場合、連結リストに基づくスタックがより良い選択です。連結リストは大量のデータをメモリの異なる部分に分散でき、配列拡張の追加オーバーヘッドを回避できます。</li>
|
||||
<li>アルゴリズム問題に取り組むときは、一般に配列ベースのスタックを選ぶ傾向があります。より高い操作効率とランダムアクセス能力を備えており、その代償は配列用に一定量のメモリを事前確保することだけです。</li>
|
||||
<li>データ量が非常に大きく、動的性が高く、スタックの想定サイズを見積もりにくい場合は、連結リストベースのスタックのほうが適しています。連結リストなら大量のデータをメモリの異なる場所に分散して保存でき、配列拡張による追加コストも回避できます。</li>
|
||||
</ul>
|
||||
|
||||
<!-- Source file information -->
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width,initial-scale=1">
|
||||
|
||||
<meta name="description" content="アニメーションで図解、ワンクリック実行のデータ構造とアルゴリズムチュートリアル">
|
||||
<meta name="description" content="アニメーション図解とワンクリック実行コードで学べるデータ構造とアルゴリズムの入門書">
|
||||
|
||||
|
||||
<meta name="author" content="krahets">
|
||||
@@ -117,7 +117,7 @@
|
||||
<path
|
||||
d="M480 32c0-12.9-7.8-24.6-19.8-29.6s-25.7-2.2-34.9 6.9L381.7 53c-48 48-113.1 75-181 75H192 160 64c-35.3 0-64 28.7-64 64v96c0 35.3 28.7 64 64 64l0 128c0 17.7 14.3 32 32 32h64c17.7 0 32-14.3 32-32V352l8.7 0c67.9 0 133 27 181 75l43.6 43.6c9.2 9.2 22.9 11.9 34.9 6.9s19.8-16.6 19.8-29.6V300.4c18.6-8.8 32-32.5 32-60.4s-13.4-51.6-32-60.4V32zm-64 76.7V240 371.3C357.2 317.8 280.5 288 200.7 288H192V192h8.7c79.8 0 156.5-29.8 215.3-83.3z" />
|
||||
</svg>
|
||||
<span>日本語版審閱者を募集しています！詳細は <a href="https://github.com/krahets/hello-algo/blob/main/ja/CONTRIBUTING.md">CONTRIBUTING.md</a> を参照してください。</span>
|
||||
<span>日本語版のレビュアーを募集しています。詳しくは <a href="/ja/chapter_appendix/contribution/">こちら</a> をご覧ください。</span>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
@@ -341,7 +341,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
序
|
||||
はじめに
|
||||
|
||||
|
||||
|
||||
@@ -358,7 +358,7 @@
|
||||
<span class="md-nav__icon md-icon"></span>
|
||||
|
||||
|
||||
序
|
||||
はじめに
|
||||
|
||||
|
||||
</label>
|
||||
@@ -618,7 +618,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
1.1 アルゴリズムはどこにでもある
|
||||
1.1 アルゴリズムは至るところにある
|
||||
|
||||
|
||||
|
||||
@@ -646,7 +646,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
1.2 アルゴリズムとは何か
|
||||
1.2 アルゴリズムとは
|
||||
|
||||
|
||||
|
||||
@@ -783,7 +783,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
2.1 アルゴリズムの効率評価
|
||||
2.1 アルゴリズム効率の評価
|
||||
|
||||
|
||||
|
||||
@@ -1060,7 +1060,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
3.3 数値の符号化 *
|
||||
3.3 数値エンコーディング *
|
||||
|
||||
|
||||
|
||||
@@ -1088,7 +1088,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
3.4 文字の符号化 *
|
||||
3.4 文字エンコーディング *
|
||||
|
||||
|
||||
|
||||
@@ -1396,7 +1396,7 @@
|
||||
<a href="#1" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
1. 重要な復習
|
||||
1. 要点の振り返り
|
||||
|
||||
</span>
|
||||
</a>
|
||||
@@ -1663,7 +1663,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
第 6 章 ハッシュ表
|
||||
第 6 章 ハッシュテーブル
|
||||
|
||||
|
||||
|
||||
@@ -1685,7 +1685,7 @@
|
||||
<span class="md-nav__icon md-icon"></span>
|
||||
|
||||
|
||||
第 6 章 ハッシュ表
|
||||
第 6 章 ハッシュテーブル
|
||||
|
||||
|
||||
</label>
|
||||
@@ -1707,7 +1707,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
6.1 ハッシュ表
|
||||
6.1 ハッシュテーブル
|
||||
|
||||
|
||||
|
||||
@@ -2014,7 +2014,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
7.5 AVL木 *
|
||||
7.5 AVL 木 *
|
||||
|
||||
|
||||
|
||||
@@ -2177,7 +2177,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
8.2 ヒープ構築操作
|
||||
8.2 ヒープ構築
|
||||
|
||||
|
||||
|
||||
@@ -2563,7 +2563,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
10.2 二分探索の挿入点
|
||||
10.2 二分探索の挿入位置
|
||||
|
||||
|
||||
|
||||
@@ -2619,7 +2619,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
10.4 ハッシュ最適化戦略
|
||||
10.4 ハッシュによる最適化戦略
|
||||
|
||||
|
||||
|
||||
@@ -2647,7 +2647,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
10.5 探索アルゴリズムの再認識
|
||||
10.5 探索アルゴリズム再考
|
||||
|
||||
|
||||
|
||||
@@ -3185,7 +3185,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
12.1 分割統治アルゴリズム
|
||||
12.1 分割統治法
|
||||
|
||||
|
||||
|
||||
@@ -3241,7 +3241,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
12.3 木の構築問題
|
||||
12.3 二分木の構築問題
|
||||
|
||||
|
||||
|
||||
@@ -3269,7 +3269,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
12.4 ハノイの塔問題
|
||||
12.4 ハノイの塔の問題
|
||||
|
||||
|
||||
|
||||
@@ -3462,7 +3462,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
13.3 部分集合和問題
|
||||
13.3 部分和問題
|
||||
|
||||
|
||||
|
||||
@@ -3490,7 +3490,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
13.4 Nクイーン問題
|
||||
13.4 n クイーン問題
|
||||
|
||||
|
||||
|
||||
@@ -3631,7 +3631,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
14.1 動的計画法の初歩
|
||||
14.1 動的計画法入門
|
||||
|
||||
|
||||
|
||||
@@ -3659,7 +3659,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
14.2 DP 問題の特性
|
||||
14.2 動的計画法の問題特性
|
||||
|
||||
|
||||
|
||||
@@ -3687,7 +3687,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
14.3 DP の解法の考え方
|
||||
14.3 動的計画法の問題解決の考え方
|
||||
|
||||
|
||||
|
||||
@@ -3715,7 +3715,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
14.4 0-1ナップサック問題
|
||||
14.4 0-1 ナップサック問題
|
||||
|
||||
|
||||
|
||||
@@ -3908,7 +3908,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
15.1 貪欲アルゴリズム
|
||||
15.1 貪欲法
|
||||
|
||||
|
||||
|
||||
@@ -4153,7 +4153,7 @@
|
||||
<span class="md-ellipsis">
|
||||
|
||||
|
||||
16.2 一緒に創作に参加する
|
||||
16.2 一緒に制作に参加しましょう
|
||||
|
||||
|
||||
|
||||
@@ -4299,7 +4299,7 @@
|
||||
<a href="#1" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
1. 重要な復習
|
||||
1. 要点の振り返り
|
||||
|
||||
</span>
|
||||
</a>
|
||||
@@ -4355,60 +4355,62 @@
|
||||
|
||||
<!-- Page content -->
|
||||
<h1 id="45">4.5 まとめ<a class="headerlink" href="#45" title="Permanent link">¶</a></h1>
|
||||
<h3 id="1">1. 重要な復習<a class="headerlink" href="#1" title="Permanent link">¶</a></h3>
|
||||
<h3 id="1">1. 要点の振り返り<a class="headerlink" href="#1" title="Permanent link">¶</a></h3>
|
||||
<ul>
|
||||
<li>配列と連結リストは2つの基本的なデータ構造であり、コンピュータメモリにおける2つの格納方法を表しています：連続空間格納と非連続空間格納です。それらの特性は互いに補完し合います。</li>
|
||||
<li>配列はランダムアクセスをサポートし、使用するメモリが少ない一方で、要素の挿入と削除は非効率的で、初期化後の長さが固定されています。</li>
|
||||
<li>連結リストは参照（ポインタ）の変更によって効率的なノードの挿入と削除を実装し、長さを柔軟に調整できますが、ノードアクセス効率が低く、より多くのメモリを消費します。</li>
|
||||
<li>連結リストの一般的な種類には、単方向連結リスト、循環連結リスト、双方向連結リストがあり、それぞれに独自の応用シナリオがあります。</li>
|
||||
<li>リストは要素の順序付けられたコレクションで、追加、削除、変更をサポートし、通常は動的配列に基づいて実装され、配列の利点を保持しながら柔軟な長さ調整を可能にします。</li>
|
||||
<li>リストの出現により配列の実用性が大幅に向上しましたが、一部のメモリ空間の無駄につながる可能性があります。</li>
|
||||
<li>プログラム実行中、データは主にメモリに格納されます。配列はより高いメモリ空間効率を提供し、連結リストはメモリ使用においてより柔軟です。</li>
|
||||
<li>キャッシュは、キャッシュライン、先読み、空間的局所性、時間的局所性などのメカニズムを通じてCPUに高速データアクセスを提供し、プログラム実行効率を大幅に向上させます。</li>
|
||||
<li>より高いキャッシュヒット率により、配列は一般的に連結リストよりも効率的です。データ構造を選択する際は、特定のニーズとシナリオに基づいて適切な選択をすべきです。</li>
|
||||
<li>配列と連結リストは 2 種類の基本的なデータ構造であり、それぞれコンピュータメモリにおけるデータの 2 つの格納方式、すなわち連続領域への格納と分散領域への格納を表す。両者の特徴は相互補完的である。</li>
|
||||
<li>配列はランダムアクセスをサポートし、使用メモリも少ない。一方で、要素の挿入と削除の効率は低く、初期化後に長さを変更できない。</li>
|
||||
<li>連結リストは参照（ポインタ）を変更することでノードの挿入と削除を効率的に行え、長さも柔軟に調整できる。一方で、ノードへのアクセス効率は低く、メモリ使用量も多い。一般的な連結リストには単方向連結リスト、循環連結リスト、双方向連結リストがある。</li>
|
||||
<li>リストは、追加・削除・検索・更新をサポートする順序付き要素集合であり、通常は動的配列に基づいて実装される。配列の利点を保ちながら、長さを柔軟に調整できる。</li>
|
||||
<li>リストの登場により配列の実用性は大幅に高まったが、一部のメモリ領域が無駄になる可能性がある。</li>
|
||||
<li>プログラムの実行時、データは主にメモリに格納される。配列はより高いメモリ空間効率を提供でき、連結リストはメモリ利用の面でより柔軟である。</li>
|
||||
<li>キャッシュは、キャッシュライン、プリフェッチ機構、空間局所性と時間局所性といったデータ読み込み機構を通じて CPU に高速なデータアクセスを提供し、プログラムの実行効率を大きく向上させる。</li>
|
||||
<li>配列はキャッシュヒット率が高いため、通常は連結リストよりも高効率である。データ構造を選択する際は、具体的な要件や場面に応じて適切に選ぶべきである。</li>
|
||||
</ul>
|
||||
<h3 id="2-q-a">2. Q & A<a class="headerlink" href="#2-q-a" title="Permanent link">¶</a></h3>
|
||||
<p><strong>Q</strong>：配列をスタックに格納するかヒープに格納するかは、時間と空間効率に影響しますか？</p>
|
||||
<p>スタックとヒープの両方に格納される配列は連続したメモリ空間に格納され、データ操作効率は本質的に同じです。しかし、スタックとヒープには独自の特性があり、以下の違いが生じます。</p>
|
||||
<p><strong>Q</strong>：配列をスタックに格納する場合とヒープに格納する場合では、時間効率と空間効率に影響がありますか？</p>
|
||||
<p>スタック上とヒープ上の配列はいずれも連続したメモリ領域に格納されるため、データ操作の効率は基本的に同じである。ただし、スタックとヒープにはそれぞれ特徴があり、以下の違いが生じる。</p>
|
||||
<ol>
|
||||
<li>割り当てと解放効率：スタックはより小さなメモリブロックで、コンパイラによって自動的に割り当てられます。ヒープメモリは比較的大きく、コードで動的に割り当てることができ、断片化しやすいです。したがって、ヒープでの割り当てと解放操作は一般的にスタックよりも遅くなります。</li>
|
||||
<li>サイズ制限：スタックメモリは比較的小さく、ヒープサイズは一般的に利用可能なメモリによって制限されます。したがって、ヒープは大きな配列の格納により適しています。</li>
|
||||
<li>柔軟性：スタック上の配列のサイズはコンパイル時に決定される必要がありますが、ヒープ上の配列のサイズは実行時に動的に決定できます。</li>
|
||||
<li>確保と解放の効率：スタックは比較的小さなメモリ領域で、確保はコンパイラによって自動的に行われる。一方、ヒープメモリは相対的に大きく、コード内で動的に確保できる反面、断片化しやすい。そのため、ヒープ上での確保と解放は通常スタック上より遅い。</li>
|
||||
<li>サイズ制限：スタックメモリは比較的小さく、ヒープのサイズは一般に利用可能メモリに制限される。そのため、ヒープは大きな配列の格納により適している。</li>
|
||||
<li>柔軟性：スタック上の配列サイズはコンパイル時に確定している必要があるが、ヒープ上の配列サイズは実行時に動的に決定できる。</li>
|
||||
</ol>
|
||||
<p><strong>Q</strong>：なぜ配列は同じ型の要素を必要とし、連結リストは同じ型の要素を強調しないのですか？</p>
|
||||
<p>連結リストは参照（ポインタ）によって接続されたノードで構成され、各ノードはint、double、string、objectなど、異なる型のデータを格納できます。</p>
|
||||
<p>対照的に、配列要素は同じ型である必要があり、これにより対応する要素位置にアクセスするためのオフセットを計算できます。例えば、intとlong型の両方を含む配列で、単一要素がそれぞれ4バイトと8バイトを占有する場合、配列に2つの異なる長さの要素が含まれているため、以下の式を使用してオフセットを計算できません。</p>
|
||||
<div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a><span class="c1"># 要素メモリアドレス = 配列メモリアドレス + 要素長 * 要素インデックス</span>
|
||||
<p><strong>Q</strong>：なぜ配列では同じ型の要素が求められるのに、連結リストでは同じ型であることが強調されないのですか？</p>
|
||||
<p>連結リストはノードで構成され、ノード同士は参照（ポインタ）で接続されている。各ノードには <code>int</code>、<code>double</code>、<code>string</code>、<code>object</code> など、異なる型のデータを格納できる。</p>
|
||||
<p>これに対して、配列要素は同じ型でなければならない。そうでなければ、オフセットを計算して対応する要素位置を取得できないからである。たとえば、配列に <code>int</code> と <code>long</code> の 2 種類が同時に含まれていて、各要素がそれぞれ 4 バイトと 8 バイトを占める場合、配列内に 2 種類の「要素長」が存在するため、次の式ではオフセットを計算できない。</p>
|
||||
<div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a><span class="c1"># 要素のメモリアドレス = 配列のメモリアドレス（先頭要素のメモリアドレス） + 要素長 * 要素インデックス</span>
|
||||
</code></pre></div>
|
||||
<p><strong>Q</strong>：ノードを削除した後、<code>P.next</code>を<code>None</code>に設定する必要がありますか？</p>
|
||||
<p><code>P.next</code>を変更しなくても問題ありません。連結リストの観点から、ヘッドノードからテールノードまでの巡回で<code>P</code>に遭遇することはもうありません。これは、ノード<code>P</code>がリストから効果的に削除されたことを意味し、<code>P</code>が指す場所はもはやリストに影響しません。</p>
|
||||
<p>ガベージコレクションの観点から、Java、Python、Goなどの自動ガベージコレクションメカニズムを持つ言語では、ノード<code>P</code>が収集されるかどうかは、それを指す参照がまだあるかどうかに依存し、<code>P.next</code>の値には依存しません。CやC++などの言語では、ノードのメモリを手動で解放する必要があります。</p>
|
||||
<p><strong>Q</strong>：連結リストでは、挿入と削除操作の時間計算量は<code>O(1)</code>です。しかし、挿入や削除前の要素検索には<code>O(n)</code>時間がかかるので、なぜ時間計算量は<code>O(n)</code>ではないのですか？</p>
|
||||
<p>要素を最初に検索してから削除する場合、時間計算量は確かに<code>O(n)</code>です。しかし、連結リストの挿入と削除における<code>O(1)</code>の利点は他のアプリケーションで実現できます。例えば、連結リストを使用した両端キューの実装では、常にヘッドとテールノードを指すポインタを維持し、各挿入と削除操作を<code>O(1)</code>にします。</p>
|
||||
<p><strong>Q</strong>：「連結リストの定義と格納方法」の図で、薄青色の格納ノードは単一のメモリアドレスを占有しますか、それともノード値と半分を共有しますか？</p>
|
||||
<p>図は単なる定性的な表現であり、定量的分析は特定の状況に依存します。</p>
|
||||
<p><strong>Q</strong>：ノード <code>P</code> を削除した後、<code>P.next</code> を <code>None</code> に設定する必要はありますか？</p>
|
||||
<p><code>P.next</code> を変更しなくてもよい。この連結リストの観点では、先頭ノードから末尾ノードまでたどっても、もはや <code>P</code> に出会うことはない。つまり、ノード <code>P</code> はすでに連結リストから削除されており、この時点で <code>P</code> がどこを指していても、この連結リストには影響しない。</p>
|
||||
<p>データ構造とアルゴリズム（問題を解くとき）の観点では、切り離さなくても問題はなく、プログラムのロジックが正しいことを保証すればよい。標準ライブラリの観点では、切り離したほうがより安全で、ロジックも明確である。切り離さない場合、削除されたノードが適切に回収されなかったとすると、後続ノードのメモリ回収に影響する可能性がある。</p>
|
||||
<p><strong>Q</strong>：連結リストでの挿入と削除の時間計算量は <span class="arithmatex">\(O(1)\)</span> です。しかし、追加や削除の前には要素を探すのに <span class="arithmatex">\(O(n)\)</span> の時間が必要です。では、なぜ時間計算量は <span class="arithmatex">\(O(n)\)</span> ではないのですか？</p>
|
||||
<p>要素を先に探してから削除するのであれば、時間計算量が <span class="arithmatex">\(O(n)\)</span> であるのは確かである。しかし、連結リストの <span class="arithmatex">\(O(1)\)</span> での追加・削除という利点は、ほかの用途で生かせる。たとえば、両端キューは連結リストで実装するのに適しており、先頭ノードと末尾ノードを常に指すポインタ変数を維持すれば、各挿入・削除操作はどれも <span class="arithmatex">\(O(1)\)</span> になる。</p>
|
||||
<p><strong>Q</strong>：図「連結リストの定義と格納方式」で、薄青色のノードポインタ部分は 1 つのメモリアドレスを占めているのですか？ それともノード値と半分ずつなのでしょうか？</p>
|
||||
<p>この模式図は定性的な表現にすぎず、定量的な表現は具体的な状況に応じて分析する必要がある。</p>
|
||||
<ul>
|
||||
<li>異なる型のノード値は異なる量の空間を占有します。例えば、int、long、double、オブジェクトインスタンスです。</li>
|
||||
<li>ポインタ変数によって占有されるメモリ空間は、使用されるオペレーティングシステムとコンパイル環境に依存し、通常8バイトまたは4バイトです。</li>
|
||||
<li>ノード値が占める領域は型によって異なり、たとえば <code>int</code>、<code>long</code>、<code>double</code>、インスタンスオブジェクトなどがある。</li>
|
||||
<li>ポインタ変数が占めるメモリ空間の大きさは、使用する OS やコンパイル環境によって異なり、多くは 8 バイトまたは 4 バイトである。</li>
|
||||
</ul>
|
||||
<p><strong>Q</strong>：リストの末尾への要素追加は常に<code>O(1)</code>ですか？</p>
|
||||
<p>要素を追加することでリスト長を超える場合、リストは最初に拡張される必要があります。システムは新しいメモリブロックを要求し、元のリストのすべての要素を移動するため、この場合の時間計算量は<code>O(n)</code>になります。</p>
|
||||
<p><strong>Q</strong>：「リストの出現により配列の実用性が大幅に向上しましたが、一部のメモリ空間の無駄につながる可能性があります」という文は、容量、長さ、拡張係数などの追加変数によって占有されるメモリを指していますか？</p>
|
||||
<p>ここでの空間の無駄は主に2つの側面を指します：一方で、リストは初期長で設定されますが、常に必要とは限りません。他方で、頻繁な拡張を防ぐため、拡張は通常<span class="arithmatex">\(\times 1.5\)</span>などの係数で乗算されます。これにより多くの空きスロットが生まれ、通常は完全に埋めることができません。</p>
|
||||
<p><strong>Q</strong>：Pythonで<code>n = [1, 2, 3]</code>を初期化した後、これら3つの要素のアドレスは連続していますが、<code>m = [2, 1, 3]</code>を初期化すると、各要素の<code>id</code>は連続していないが<code>n</code>のものと同一です。これらの要素のアドレスが連続していない場合、<code>m</code>はまだ配列ですか？</p>
|
||||
<p>リスト要素を連結リストノード<code>n = [n1, n2, n3, n4, n5]</code>に置き換える場合、これら5つのノードオブジェクトも通常メモリ全体に分散しています。しかし、リストインデックスが与えられれば、<code>O(1)</code>時間でノードのメモリアドレスにアクセスでき、対応するノードにアクセスできます。これは、配列がノード自体ではなく、ノードへの参照を格納するためです。</p>
|
||||
<p>多くの言語とは異なり、Pythonでは数値もオブジェクトとしてラップされ、リストは数値自体ではなく、これらの数値への参照を格納します。したがって、2つの配列の同じ数値が同じ<code>id</code>を持ち、これらの数値のメモリアドレスは連続である必要がないことがわかります。</p>
|
||||
<p><strong>Q</strong>：C++ STLの<code>std::list</code>はすでに双方向連結リストを実装していますが、一部のアルゴリズム書籍では直接使用していないようです。何か制限がありますか？</p>
|
||||
<p>一方で、アルゴリズムを実装する際は配列を使用することを好み、必要な場合のみ連結リストを使用します。主に2つの理由があります。</p>
|
||||
<p><strong>Q</strong>：リストの末尾への要素追加は常に <span class="arithmatex">\(O(1)\)</span> ですか？</p>
|
||||
<p>要素を追加する際にリスト長を超える場合は、先にリストを拡張してから追加する必要がある。システムは新しいメモリ領域を確保し、元のリストの全要素をそこへ移動するため、このとき時間計算量は <span class="arithmatex">\(O(n)\)</span> になる。</p>
|
||||
<p><strong>Q</strong>：「リストの登場により配列の実用性は大きく向上したが、一部のメモリ空間が無駄になる可能性がある」というのは、容量、長さ、拡張倍率のような追加変数が占めるメモリのことですか？</p>
|
||||
<p>ここでいう空間の無駄には主に 2 つの意味がある。一方では、リストには初期長が設定されるが、必ずしもそれだけ必要とは限らない。もう一方では、頻繁な拡張を防ぐため、拡張時には通常ある係数、たとえば <span class="arithmatex">\(\times 1.5\)</span> を掛ける。このため、多くの空きスロットが生じ、通常それらを完全に埋めることはできない。</p>
|
||||
<p><strong>Q</strong>：Python で <code>n = [1, 2, 3]</code> を初期化した後、この 3 つの要素のアドレスは連続しています。しかし <code>m = [2, 1, 3]</code> を初期化すると、各要素の id は連続しておらず、それぞれ <code>n</code> 内の同じ値と一致していることがわかります。これらの要素のアドレスが連続していないなら、<code>m</code> も配列なのですか？</p>
|
||||
<p>仮にリスト要素を連結リストのノード <code>n = [n1, n2, n3, n4, n5]</code> に置き換えたとしても、通常この 5 つのノードオブジェクトもメモリ上の各所に分散して格納される。それでも、与えられたリストインデックスに対して、私たちは依然として <span class="arithmatex">\(O(1)\)</span> 時間でノードのメモリアドレスを取得し、対応するノードにアクセスできる。これは、配列に格納されているのがノードそのものではなく、ノードへの参照だからである。</p>
|
||||
<p>多くの言語と異なり、Python では数値もオブジェクトとしてラップされており、リストに格納されているのは数値そのものではなく、数値への参照である。そのため、2 つの配列内の同じ数値が同一の id を持つことがあり、しかもそれらの数値のメモリアドレスは連続している必要がない。</p>
|
||||
<p><strong>Q</strong>：C++ STL の <code>std::list</code> はすでに双方向連結リストを実装していますが、アルゴリズム本ではあまり直接使われないようです。何か制約があるのでしょうか？</p>
|
||||
<p>一方では、私たちは多くの場合、アルゴリズムの実装に配列を好み、必要なときにだけ連結リストを使う。その主な理由は 2 つある。</p>
|
||||
<ul>
|
||||
<li>空間オーバーヘッド：各要素に2つの追加ポインタ（前の要素用と次の要素用）が必要なため、<code>std::list</code>は通常<code>std::vector</code>よりも多くの空間を占有します。</li>
|
||||
<li>キャッシュ非友好的：データが連続して格納されていないため、<code>std::list</code>はキャッシュ利用率が低くなります。一般的に、<code>std::vector</code>の方がパフォーマンスが優れています。</li>
|
||||
<li>空間オーバーヘッド：各要素には 2 つの追加ポインタ（前の要素用と次の要素用）が必要なため、<code>std::list</code> は通常 <code>std::vector</code> より多くの空間を消費する。</li>
|
||||
<li>キャッシュ非効率：データが連続して格納されていないため、<code>std::list</code> はキャッシュの利用効率が低い。一般には、<code>std::vector</code> のほうが性能がよい。</li>
|
||||
</ul>
|
||||
<p>他方で、連結リストは主に二分木とグラフに必要です。スタックとキューは、連結リストではなく、プログラミング言語の<code>stack</code>と<code>queue</code>クラスを使用して実装されることが多いです。</p>
|
||||
<p><strong>Q</strong>：リスト<code>res = [0] * self.size()</code>を初期化すると、<code>res</code>の各要素は同じアドレスを参照しますか？</p>
|
||||
<p>いいえ。しかし、この問題は二次元配列で発生します。例えば、二次元リスト<code>res = [[0]] * self.size()</code>を初期化すると、同じリスト<code>[0]</code>を複数回参照することになります。</p>
|
||||
<p><strong>Q</strong>：ノードを削除する際、その後続ノードへの参照を断つ必要がありますか？</p>
|
||||
<p>データ構造とアルゴリズム（問題解決）の観点から、プログラムのロジックが正しい限り、リンクを断たなくても問題ありません。標準ライブラリの観点から、リンクを断つ方が安全で論理的に明確です。リンクを断たず、削除されたノードが適切にリサイクルされない場合、後続ノードのメモリのリサイクルに影響を与える可能性があります。</p>
|
||||
<p>もう一方では、連結リストを使う必要がある代表的な場面は主に二分木とグラフである。スタックやキューについては、連結リストではなく、たいてい言語が提供する <code>stack</code> と <code>queue</code> を使う。</p>
|
||||
<p><strong>Q</strong>：<code>res = [[0]] * n</code> という操作で 2 次元リストを生成した場合、それぞれの <code>[0]</code> は独立していますか？</p>
|
||||
<p>独立していない。この 2 次元リストでは、すべての <code>[0]</code> は実際には同一オブジェクトへの参照である。そのうちの 1 つを変更すると、対応するすべての要素が一緒に変化することがわかる。</p>
|
||||
<p>2 次元リスト内の各 <code>[0]</code> を独立させたい場合は、<code>res = [[0] for _ in range(n)]</code> を使って実現できる。この方式の原理は、独立した <code>[0]</code> リストオブジェクトを <span class="arithmatex">\(n\)</span> 個初期化していることにある。</p>
|
||||
<p><strong>Q</strong>：<code>res = [0] * n</code> という操作で生成されたリストでは、それぞれの整数 0 は独立していますか？</p>
|
||||
<p>このリストでは、すべての整数 0 が同一オブジェクトへの参照である。これは、Python が小さな整数（通常は -5 から 256）に対してキャッシュプール機構を採用し、オブジェクトの再利用を最大化して性能を向上させているためである。</p>
|
||||
<p>それらは同じオブジェクトを指しているが、それでもリスト内の各要素は独立して変更できる。これは、Python の整数が「イミュータブルオブジェクト」だからである。ある要素を変更するとき、実際には別のオブジェクトへの参照に切り替わるのであって、元のオブジェクトそのものを変更しているわけではない。</p>
|
||||
<p>しかし、リスト要素が「ミュータブルオブジェクト」（たとえばリスト、辞書、クラスインスタンスなど）である場合は、ある要素を変更するとそのオブジェクト自体が直接変更され、そのオブジェクトを参照しているすべての要素に同じ変化が生じる。</p>
|
||||
|
||||
<!-- Source file information -->
|
||||
|
||||
|
||||
Reference in New Issue
Block a user