page0022
の編集
http://osecpu.osask.jp/wiki/?page0022
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
BracketName
FormattingRules
FrontPage
Fulyn
Fulyn-v2
Fulyn_Samples
Help
InterWiki
InterWikiName
InterWikiSandBox
K
KOR_PIT8254
KWVM.NET
Liva
MANA
MenuBar
OSECPU_FPGA
PG_MANA
PHP
PukiWiki
PukiWiki/1.4
PukiWiki/1.4/Manual
PukiWiki/1.4/Manual/Plugin
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/H-K
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/V-Z
RecentDeleted
SandBox
WikiEngines
WikiName
WikiWikiWeb
YukiWiki
hikalium
hikarupsp
hikarupsp_ELCHNOS
hikarupsp_ELCHNOS_IDE
hikarupsp_FrontEndCode
hikarupsp_WebCPU-VM
hikarupsp_WebCPU-VM_internal
hikarupsp_study_hh4
impressions
impressions0000
jpag0000
jpag0001
jpag0002
jpag0003
jpag0004
jpag0005
lambdalice
mandel59
members
memo0000
memo0001
memo0002
memo0003
memo0004
memo0005
memo0006
memo0007
memo0008
memo0009
memo0010
osask
osecpu4android
page0000
page0001
page0002
page0003
page0004
page0005
page0006
page0007
page0008
page0009
page0010
page0011
page0012
page0013
page0014
page0015
page0016
page0017
page0018
page0019
page0020
page0021
page0022
page0023
page0024
page0025
page0026
page0027
page0028
page0029
page0030
page0031
page0032
page0033
page0034
page0035
page0036
page0037
page0038
page0039
page0040
page0041
page0042
page0043
page0044
page0045
page0046
page0047
page0048
page0049
page0050
page0051
page0052
page0053
page0054
page0055
page0056
page0057
page0058
page0059
page0060
page0061
page0062
page0063
page0064
page0065
page0066
page0067
page0068
page0069
page0070
page0071
page0072
page0073
page0074
page0075
page0076
page0077
page0078
page0079
page0080
page0081
page0082
page0083
page0084
page0085
page0086
page0087
page0088
page0089
page0090
page0091
page0092
page0093
page0094
page0095
page0096
page0097
page0098
page0099
page0100
page0101
page0102
page0103
page0104
page0105
page0106
page0107
page0108
page0109
pagenames
populars
seccamp2013
seccamp2014
seccamp2017
ttwilb
ttwilb-asmi
yao
* 高速化のアイデア -(by [[K]], 2013.04.02) ** 基本的な考え方 -OSECPUは遅い。JITコンパイラだからインタプリタ方式よりは間違いなく速いと思うけど、それでも普通の機械語よりは遅い。 -これを気にしないということももちろんできるし、あきらめるということもできるけど、それはやっぱり僕らしくはない。OSECPUが教材用であることを含めても、やはり気になる。 -.NETではこれをunsafeという方法で克服したらしい。よくわからないけど、要するにバイトコードの中に機種依存な機械語を混ぜることにしたのだろう。・・・実は僕も似たようなものを先日まで考えていたのだけど、それはやめた。新しい方法を思いついたのでそれをここに書きたい。 -unsafe方式の残念なところは、Windows用のunsafeなコードが入っている場合に、他のOSでは動かなくなってしまうところにある。また、インターネット上のunsafeなものは実行できないらしい。 -僕は次のような代替案を考えている。 --OSECPUはunsafeみたいなフォーマットを持たず、基本的にアプリもライブラリもOSECPUのバイトコードのみで書かせる。これにより性能さえ気にしなければ、最も高いセキュリティ機能と、十分な互換性を提供できる。 --一方で、オプションのライブラリとして、高速化フレーズライブラリというものを持つ。これはある種のバイトコード列を見つけたら、JIT時にライブラリ内に登録済みの機械語のほうを使うというものである。このライブラリはスタティックリンクやダイナミックリンクをして使うような普通のライブラリではなく、翻訳キャッシュの辞書みたいなものである。 --ユーザは信用できるソースから生成した機種依存のコードのみを自分のライブラリに登録しておけばいいだろう。 --この方法なら、配布元が「これは安全だ、署名もあるぜ、信用しろ」と言ってきて、なんかうさんくさいけどこれがないと動かないからあきらめて使う、みたいなことも起きない。 ---そういうものはOSECPUの標準JITコンパイラで、低速なまま使えばいいのだから。 ** 議論 -unsafe方式でも、unsafeな部分を全てDLLとして外部に追い出した上で、そのDLLのunsafe版とsafe版の両方を提供してユーザに選ばせれば同じことはできる。しかしそのunsafe版だけど、果たしてそれは信用できるものなのか? --信用するためには最低でもオープンソースである必要があるだろうし、自分の手元でビルドしないと不安だ。 --そうでなければ、ある特別な入力が与えられるまでは完全におとなしくしていて、その合図と共に悪さを始める、なんていうコードではないとどうして確信できるだろう。 -オープンソース化してきちんと確認するためには、コードの量が膨大になってはいけない。 --ということで「オレオレな」unsafeコードをたくさん作られても困る。 -一方で、自分で作ったものはもちろん信用できるから(バグはあるかもしれないけど、少なくとも悪意はない)、審査を受けないと実行できないとかそんなのはごめんだ。警告すら出てほしくない。なぜシステムに僕の作品を危険物呼ばわりされるのだ。ソースを公開してないメーカ製のライブラリのほうがはるかに注意を要するというのに。 -フレーズ方式なら、とにかく確認が取れたものから登録していける。遅くて我慢ならないところから確認して登録すればいいだろう。さらにフレーズ方式は、既存のアプリに対しても「この部分はこうやってJITコンパイルしてくれ」と指示することが可能である。したがって他人が作ったものを部分的に解析して、高速化することもできる。 -先ほどはunsafe方式でも「DLLのunsafe版とsafe版の両方を提供すれば同じことはできる」と書いたが、果たして配布元はそんなに気の利いたことをしてくれるだろうか?という心配もある。 --開発元としてはunsafe版を使ってほしいと思っているに違いない。それこそが(自分たちの考える)本来の速さだと思っているに違いない。その気持ちは分かる。 --しかしそれを買ってきてorダウンロードして使う側としては、むしろ心配なのだ。スピードよりもまずは安全がほしい。というかそのためのOSECPUではないか。だからsafe版を必ず開発してほしい。unsafe版だけでいいや、十分だと思わないでほしい。 --フレーズ方式なら、結果的にsafe版の提供を回避することはないだろう。 -アプリのコードもおそらく80-20ルールに従うだろう。つまりコードのうちの20%程度を高速化フレーズで置き換えるだけで、機種依存で最適化されたプログラムと遜色ない(まあ20%くらいしか遅くない?)スピードが出るだろう。しかもその高速化フレーズはおそらく多くのプログラムで共通な部分が多く、その重複も考えれば、アプリの全コード量のうちの1%未満の量の確認だけで、僕の期待する安全性が得られるのではないかと想像する。 --スピードについては100%にならないわけだけど、それはセキュアなこととのトレードオフだからしょうがない。僕は1.2倍程度で済むのであれば許容してもよい。 -インターネット上のものでも、フレーズさえ一致すれば高速化される。だから定番のフレーズを使っている限りインターネット上のものでも高速だし、もしくはこのフレーズを登録すれば速くなりますって、高速コードのソースを公開してもいい。 --僕はコードを精査して入れるかどうかを判断する。 ** メモ -フレーズ方式だとラベル番号が比較の際に邪魔になるので、OSECPUの上位の命令体系では、ラベル番号が生では現れない形式のほうが好ましい。 --lbstk表記(のバイナリ版)を上位の命令体系で採用すればいいかなと思っている。 ** こめんと欄 -このページにこめんと欄はありません。このページの内容にコメントしたいときは[[impressions]]にお願いします。
タイムスタンプを変更しない
* 高速化のアイデア -(by [[K]], 2013.04.02) ** 基本的な考え方 -OSECPUは遅い。JITコンパイラだからインタプリタ方式よりは間違いなく速いと思うけど、それでも普通の機械語よりは遅い。 -これを気にしないということももちろんできるし、あきらめるということもできるけど、それはやっぱり僕らしくはない。OSECPUが教材用であることを含めても、やはり気になる。 -.NETではこれをunsafeという方法で克服したらしい。よくわからないけど、要するにバイトコードの中に機種依存な機械語を混ぜることにしたのだろう。・・・実は僕も似たようなものを先日まで考えていたのだけど、それはやめた。新しい方法を思いついたのでそれをここに書きたい。 -unsafe方式の残念なところは、Windows用のunsafeなコードが入っている場合に、他のOSでは動かなくなってしまうところにある。また、インターネット上のunsafeなものは実行できないらしい。 -僕は次のような代替案を考えている。 --OSECPUはunsafeみたいなフォーマットを持たず、基本的にアプリもライブラリもOSECPUのバイトコードのみで書かせる。これにより性能さえ気にしなければ、最も高いセキュリティ機能と、十分な互換性を提供できる。 --一方で、オプションのライブラリとして、高速化フレーズライブラリというものを持つ。これはある種のバイトコード列を見つけたら、JIT時にライブラリ内に登録済みの機械語のほうを使うというものである。このライブラリはスタティックリンクやダイナミックリンクをして使うような普通のライブラリではなく、翻訳キャッシュの辞書みたいなものである。 --ユーザは信用できるソースから生成した機種依存のコードのみを自分のライブラリに登録しておけばいいだろう。 --この方法なら、配布元が「これは安全だ、署名もあるぜ、信用しろ」と言ってきて、なんかうさんくさいけどこれがないと動かないからあきらめて使う、みたいなことも起きない。 ---そういうものはOSECPUの標準JITコンパイラで、低速なまま使えばいいのだから。 ** 議論 -unsafe方式でも、unsafeな部分を全てDLLとして外部に追い出した上で、そのDLLのunsafe版とsafe版の両方を提供してユーザに選ばせれば同じことはできる。しかしそのunsafe版だけど、果たしてそれは信用できるものなのか? --信用するためには最低でもオープンソースである必要があるだろうし、自分の手元でビルドしないと不安だ。 --そうでなければ、ある特別な入力が与えられるまでは完全におとなしくしていて、その合図と共に悪さを始める、なんていうコードではないとどうして確信できるだろう。 -オープンソース化してきちんと確認するためには、コードの量が膨大になってはいけない。 --ということで「オレオレな」unsafeコードをたくさん作られても困る。 -一方で、自分で作ったものはもちろん信用できるから(バグはあるかもしれないけど、少なくとも悪意はない)、審査を受けないと実行できないとかそんなのはごめんだ。警告すら出てほしくない。なぜシステムに僕の作品を危険物呼ばわりされるのだ。ソースを公開してないメーカ製のライブラリのほうがはるかに注意を要するというのに。 -フレーズ方式なら、とにかく確認が取れたものから登録していける。遅くて我慢ならないところから確認して登録すればいいだろう。さらにフレーズ方式は、既存のアプリに対しても「この部分はこうやってJITコンパイルしてくれ」と指示することが可能である。したがって他人が作ったものを部分的に解析して、高速化することもできる。 -先ほどはunsafe方式でも「DLLのunsafe版とsafe版の両方を提供すれば同じことはできる」と書いたが、果たして配布元はそんなに気の利いたことをしてくれるだろうか?という心配もある。 --開発元としてはunsafe版を使ってほしいと思っているに違いない。それこそが(自分たちの考える)本来の速さだと思っているに違いない。その気持ちは分かる。 --しかしそれを買ってきてorダウンロードして使う側としては、むしろ心配なのだ。スピードよりもまずは安全がほしい。というかそのためのOSECPUではないか。だからsafe版を必ず開発してほしい。unsafe版だけでいいや、十分だと思わないでほしい。 --フレーズ方式なら、結果的にsafe版の提供を回避することはないだろう。 -アプリのコードもおそらく80-20ルールに従うだろう。つまりコードのうちの20%程度を高速化フレーズで置き換えるだけで、機種依存で最適化されたプログラムと遜色ない(まあ20%くらいしか遅くない?)スピードが出るだろう。しかもその高速化フレーズはおそらく多くのプログラムで共通な部分が多く、その重複も考えれば、アプリの全コード量のうちの1%未満の量の確認だけで、僕の期待する安全性が得られるのではないかと想像する。 --スピードについては100%にならないわけだけど、それはセキュアなこととのトレードオフだからしょうがない。僕は1.2倍程度で済むのであれば許容してもよい。 -インターネット上のものでも、フレーズさえ一致すれば高速化される。だから定番のフレーズを使っている限りインターネット上のものでも高速だし、もしくはこのフレーズを登録すれば速くなりますって、高速コードのソースを公開してもいい。 --僕はコードを精査して入れるかどうかを判断する。 ** メモ -フレーズ方式だとラベル番号が比較の際に邪魔になるので、OSECPUの上位の命令体系では、ラベル番号が生では現れない形式のほうが好ましい。 --lbstk表記(のバイナリ版)を上位の命令体系で採用すればいいかなと思っている。 ** こめんと欄 -このページにこめんと欄はありません。このページの内容にコメントしたいときは[[impressions]]にお願いします。
テキスト整形のルールを表示する