Mercurial > hg > Members > yuuhi > slide

changeset 3:3d5fd010131d

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
test
author Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
date Wed, 09 Jul 2014 14:53:16 +0900
parents 105ba499ae40
children f23d647ae3fa
files s6/blank.html
diffstat 1 files changed, 25 insertions(+), 205 deletions(-) [+]
line wrap: on
line diff
--- a/s6/blank.html	Tue Jun 24 18:07:06 2014 +0900
+++ b/s6/blank.html	Wed Jul 09 14:53:16 2014 +0900
@@ -127,222 +127,42 @@
           と<font color="red">特別なチューニング</font>が必要となる。
           そこでCeriumを用いてその差を吸収し、自動的なチューニングを可能にする。
         </p>
-        <p>
-          しかし、GPUのみで並列計算を行った場合、Taskによっては並列度が出ない場合がある。
-          そこでチューニングの一環として、MultiCoreとGPU上での同時実行を可能にする。
-        </p>
-      </div>
-      
-      <!-- h1.hidden => use heading just for table of contents (toc) -->
-      <div class='slide'>
-        <h2>進捗</h2>
-        <dl>
-          <dt>Scalaで遊んでた</dt>
-          <dt>mallocのお勉強</dt>
-          <dd>kernel reading party(小崎さん)</dd>
-          <dd><a href="http://shelby.tv/video/youtube/0-vWT-t0UHg/the-67th-yokohama-kernel-reading-party">動画</a></dd>
-          <dd><a href="http://www.slideshare.net/kosaki55tea/glibc-malloc">資料</a></dd>
-      </div>
-      
-      <div class='slide'>
-        <h2>mallocってなんだっけ……？</h2>
-        <pre class="code">
-          void *malloc(size_t size);</pre>
-        <img src="images/malloc.png" width="500">
-        <ul>
-          <li>mallocはsizeバイト分のメモリを割り当て、ポインタを返す</li>
-          <li>返ってくるのはvoidのポインタなので、戻り値を型でキャストする必要がある</li>
-          <li>中身は初期化されていない</li>
-          <li>確保した領域はfreeを忘れずに</li>
-        </ul>
-        <pre class="code">
-          char *str = (char*)malloc(length); // 使う型でキャストする</pre>
-      </div>
-
-      <div class='slide'>
-        <h2>古典的malloc(K&R malloc)</h2>
-        <img src="images/heap.png" width="700">
-        <ul>
-          <li>使用可能なブロックを繋げたリスト構造、free list (freeされているブロックのlist?)
-          <li>listを使ってメモリを管理
-          <li>管理領域(header)分だけ多くallocateして、先頭に管理領域を付加
-          <li>first fit
-        </ul>
-        <hr>
-        <pre class="code">
-          union header {
-              struct {
-                  union header *ptr;  // 空きリストの上なら次のブロック
-                  unsigned size;      // このブロックの大きさ
-              } s;
-          };</pre>
-      </div>
-
-      <div class='slide'>
-        <h2>First Fit</h2>
-        <p>
-          リストを頭から見ていって、最初に見つけたものを使用するというすごいシンプルな方法。
-        </p>
-        <img src="images/firstfit.png" width="500">
-      </div>
-
-      <div class='slide'>
-        <h2>First Fit</h2>
-        <img src="images/firstfit2.png" width="500">
-        <p>実は、もう一個先にもっと適切なブロックがあった。こんな場合に対応できない…というか、対応しないのがfirst fit。</p>
-        <p>あまりよくない……</p>
-      </div>
-
-      <div class='slide'>
-        <h2>free</h2>
-        <pre class="code">
-          void free(void *ptr);</pre>
-        <p>
-          メモリの開放自体は、使用中のブロックをfree listに追加するだけで良い。
-          引数で受け取ったポインタ部分を開放したら良い……かに思える。
-          でもそれだけじゃダメで、開放したい領域と隣接しているブロックが空きブロックなら併合しないといけない。
-        </p>
-        <img src="images/free_merge.png" width="700">
-      </div>
-
-      <div class='slide'>
-        <h2>free</h2>
-        <img src="images/free1.png" width="700">
-        <p>
-          listから最初のポインタと、その次のポインタを取得。prev < p < nextを満たすまで走査していく
-                                                                       </p>
       </div>
 
       <div class='slide'>
-        <h2>free</h2>
-        <img src="images/free2.png" width="700">
-        <p>あった！！</p>
-        <p>
-          開放後に前後のメモリと併合する必要がある場合があるので、prevとp・pとnextが隣接してるか判定する。
-        </p>
-        <ul>
-          <li>(prev+prev-&gt size) != p なので、隣接していない </li>
-          <li>(p+p-&gt size)        = next    なので、隣接している</li>
-          <p>ブロックが隣接している場合は併合する。</p>
-      </div>
-      
-      <div class='slide'>
-        <h2>free</h2>
-        <img src="images/free_after.png" width="700">
-        <p>チェックに引っかかったところをマージする。</p>
-      </div>
-      
-      <div class='slide'>
-        <h2>古典的malloc & freeまとめ</h2>
-        <p>フラグメンテーションが頻発する。</p>
+        <h2>進捗</h2>
         <ul>
-          <li>このmallocが主流だった時は「メモリはプログラムの最初に一気に確保するもの」だった</li>
-          <li>メモリが充分に空いている状態で、
-              必要なメモリを一気に確保するならフラグメンテーションは起きにくい</li>
-          <li>今はJava・C++のようなオブジェクト指向言語、
-              Rubyのようなスクリプト言語等、小さいmallocが頻発するものが多い</li>
-          <li>それをfirst fitでやるのはよくない</li>
-        </ul>
-        
-      </div>
-      
-      
-      <div class='slide'>
-        <h2>mallocの改良</h2>
-        <p>そもそも、一つのfree listで管理することが無理がある</p>
-        <p>サイズ16Byte用のリスト、サイズ24Byte用のリスト……というようにリストを複数作ってやる</p>
-        <table border="0">
-          <tr>
-            <th>
-              <img src="images/free_list_list.png" width="400">
-            </th>
-            <th valign="top" align="left">
-              <ul>
-                <li>mallocで要求されたsizeを8で割れば自分が使用するindexとなる</li>
-                <li>無限にリストを増やすわけにはいかないので、このリストを使うのは512バイト以下の場合のみ</li>
-                <li>512バイト以上の大きいデータの場合は、特殊な管理を行う</li>
-                <li>大きいデータと小さいデータを一緒に管理するからフラグメンテーションが進むんだ<br>
-                  →大きいデータ用の領域がもう一個欲しい<br>→そうだ、mmapを使おう</li>
-            </th>
-          </tr>
-        </table>
-      </div>
-
-
-      <div class='slide'>
-        <h2>mmapってなんだっけ……？</h2>
-        <ul>
-          <li>ファイル(fdで指定したもの)をメモリにマップする</li>
-          <li>fdで&quot;/dev/zero&quot;を指定することでmmapをメモリ確保APIとして使用</li>
-          <li>このAPIを使ってHuge Blockはmmapで直接kernelから取得する</li>
-        </ul>
-        <pre class="code">
-          void *alloc_mmap(size_t size) {
-              int fd    = open("/dev/zero", O_RDONLY);
-              void *ret = mmap(addr, length, prot, flags, fd, offset); 
-              return ret;
-          }</pre>
-        <table border="1" >
-          <tr bgcolor="dbffa3">
-            <th align="left" style="margin:10px 10px 10px;">addr</th><th align="left">mapするメモリアドレス。NULLを渡せばkernelがアドレスを選択する。</th>
-          </tr>
-
-          <tr bgcolor="palegreen">
-            <th align="left">length</th><th align="left">addrから何バイトマッピングするか。</th>
-          </tr>
-
-          <tr bgcolor="dbffa3">
-            <th align="left" >prot</th><th align="left">マッピングのメモリ保護の指定。Read Write Exec None等がある。</th>
-          </tr>
-          <tr bgcolor="palegreen">
-            <th align="left">flags</th><th align="left">マップを要求された時、共有するかコピーを渡すか。</th>
-          </tr>
-          <tr bgcolor="dbffa3">
-            <th align="left">offset</th><th align="left">ファイルの何バイト目からをメモリにマップするか。</th>
-          </tr>
-        </table>
-      </div>
-
-      <div class='slide'>
-        <h2>Huge Block</h2>
-        <p>mmapで確保するので、free listからは独立している。
-        <table>
-          <tr>
-            <th>
-              <img src="images/huge_block.png" width="500">
-            </th>
-            <th valign="top" align="left">
-              <p>
-                listを使って管理しているわけではないので、listをたどったりしなくて良い。</p>
-              <p>
-                ほしかったらmmapして、いらなくなったらmunmapすればよい。
-              </p>
-            </th>
-          </tr>
-        </table>
-        <ul>
-          <li>free list上でフラグメンテーションが起きにくくなった(当たり前)</li>
-          <li>メモリの無駄が少ない<br>
-            大きなメモリは同じサイズでもう一度mallocされる可能性は低いので、
-          使わなくなったらすぐOSに返却するのは正しい</li>
+          <li><dt>glibcの環境構築</dt>
+            <dd>実はまだgcc...</dd></li>
+          <li><dt>mallocを(ようやく)読み始めた</dt></li>
         </ul>
       </div>
 
       <div class='slide'>
-        <h2>まとめ</h2>
+        <h2>glibc 環境構築</h2>
+        <p>install</p>
+        <pre class="code">
+          $ mkdir build;cd build
+          $ ../configure --prefix=/home/hiyoko/glibc-2.19/build/bin
+          $ make <font color="red">--debug</font> -j
+          $ make install</pre>
+        <p>compile</p>
+        <pre class="code">
+          $ g++  -Wall -g -O0   -c malloc_sample.cc -o malloc_sample.o
+          $ g++  -o malloc_sample malloc_sample.o  -g <font color="red">-static</font>
+                 -I../glibc-2.19/build/bin/include -L../glibc-2.19/build/bin/lib</pre>
+      </div>
+
+      <div class='slide'>
+        <h2>次やること</h2>
         <ul>
-          <li>一見危なそうに見える処理が……</li>
-          <li>HugeBlockをmmapで管理すれば確かに手っ取り早いではあるが、何バイトからをHugeBlockとするかをちゃんと考えないとだめ</li>
-        </ul>
-        <h2>次やること？</h2>
-        <ul>
-          <li>AVLTree</li>
-          <li>2-2n allocator</li>
-          <li>mallocのソースを読む</li>
+          <li><dt>malloc読み終わる</dt></li>
+          <li><dt>2-2n allocater</dt></li>
+          <li><dt>内定者研修に向けて</dt>
+            <dd>swiftの勉強...?</dd></li>
         </ul>
       </div>
-
-
+      </div>
 
     </div> <!-- presentation -->
   </body>