トップ «前の日記(2008-07-30) 最新 次の日記(2008-08-01)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|

ToDo:


2008-07-31

_ unnecessary mutex

これが面白いと教えてもらったので ざっと見たらおもしろかった。

http://www.springerlink.com/content/q841550258302383/

なんか一般的なライブラリをスレッドセーフにすると シングルスレッドなアプリだったりすると mutex のロックが無駄になるけど、 それをなんとか、みたいな話。

全スレッドが一個ならロックしねーとかもアリだけど 結局 Java とかみたいに必ずスレッド作るような ややこしいシステムで意味ないのでダメ。

結局、

  • mutex を作ったスレッド T はロックせずにクリティカルセクションに入る、
  • T じゃないスレッド T' は、 mutex に1対1対応してる supervisor mutex で他のスレッドを停止させた後に
  • T がクリティカルセクションにいないかどうかを根性で確認する(すごく遅い)
    • 根性は3種類くらい紹介されてた。
    • T の PC 見てほげほげ * 2
    • T の mutex.acquire() でフラグいじっとく (これは T を遅くしちゃう)

でこれだとロック起きまくるとすごく遅いので、 何回か遅いパスに来たら普通のロックにするとか。

あとは pthread_self みたいなのを常に レジスタに置いとくように処理系いじるとかなんとか。

(22:22)

_ 戦線

土曜に病院行って ステロイド1週間塗って後は他の薬でなんとかしろという指示を 受けつつ、かゆみが減る飲み薬をもらったので 塗ったり飲んだりしている。

あとあやしげな水ももらいました。 酸化水らしい。 普通の水を電気分解して酸性の方だけ取り出したとかなんとか。 ペットボトル一本100円。 アルカリイオン水涙目。

結果として

  • 炎症ほぼ完全にひいた
  • 飲み薬の有効期間にかゆくなることはない
  • 飲み薬の副作用で、常に異様に眠く、睡眠時間も異様に長い

って感じで、まぁとにかくねむい。

(22:29)

_ LLVM

がなんとなくアレだと思ってしまうのは、 とりあえず LLVM に翻訳しとけば 色んなアーキテクチャで JIT できてある程度速くなる、ってのが、 なんでも JS に翻訳しとけば色んなアーキテクチャで、 tamarin の JIT である程度速くなる、 って言ってるのと同じくらい他人任せな感じがするんだよな、とかいう。 てか IronMonkey とか実現したらまさに第二 LLVM みたいな 感じだよなぁ。

まぁ既存のランタイムとの親和性みたいなのを考えると、 matz Ruby とかみたいにランタイムが C だと LLVM の方がやりやすそうだなぁとか思うけど まぁなんにせよ本気で速くしたいんなら ランタイムのかなりの部分はその言語自身で書くなり、 C=>LLVM のパスで作っといたりしといた方がいいんだろうなぁ。

(22:40)

本日のツッコミ(全5件) [ツッコミを入れる]
_ kosaki (2008-08-01 02:56)

ふむ。LinuxでもCPUが壊れたときにそのCPUをOSから切り離す処理なんかは、いつ壊れるかなんか予想できるかボケーの理論によってそんな感じの実装だねぇ
FIFOポリシーの優先度MAXスレッドをCPU個数分だけ作って、うは、絶対俺以外うごいてねーぜーって状態にしてからウダウダと実行したりとか。
stop_machine_run() でぐぐってちょ。
もうじきはいる、自己コード書き換えフレームワークも同じ仕組み。びっくりなことにモジュールアンロードごときでも同じ事をしているので油断すると簡単にデッドロックする。
結論としてはImmediate Valueかわいいよ.

_ kosaki (2008-08-01 02:58)

話は変わるが、ottawaでMathieuが関数をnopにするよりもブランチにあたえる定数値を書き換えたほうが速いといっていたのはちょっとビックリ。
彼曰く呼びもしない関数のためにスタックフレームつくってD-cache参照ふやすなんてバカ。

_ shinh (2008-08-01 08:41)

あ、上に「他のスレッドを停止させた後に」とか書いてありますけど、「クリティカルセクションに入ろうとしてる他のスレッドが停止することを保証させた後に」なのでかなり状況違うかと…

あと branch に与える定数書き換えって、

f:
  ...
  ret

call f



f:
  ...
  ret

call next
next:

にしちゃうって話かと最初思ったのですけど、そうではないですよね(スタック調整できん)。

_ kosaki (2008-08-01 17:08)

いやいや、カーネルモジュール抜くときは全スレッドがそのカーネルモジュールの関数を実行していない事をPCレジスタチェックして調べるので同じじゃないかな。

_ shinh (2008-08-02 00:30)

ああ、となると、全スレッド調べる vs 1スレッドだけ調べるって違いですかねえ。

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2008年
7月
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 29 30 31
1.Jbnhkota(2010-03-29 15:51) 2.shinh(2008-08-02 00:30) 3.kosaki(2008-08-01 17:08)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h