アカウント名:
パスワード:
なんで、コンパイルなんでしょう？
バイナリー配布出来ない理由は
・バイナリー配布しちゃダメってっていうフリーソースを含んでいる？・動作環境に依存する？・？
環境に応じた最適化って言っても、所詮CPUだったらせいぜい数十種類だと思うんだけど、一体何をやってるのかな？
そんなに組み合わせが多くて爆発的に増えちゃうようなものなのかな？
あくまで中間コードのアセンブリが正で、ネイティブコンパイルしたバイナリは副。つまり、中間コード＋ネイティブコードで配布するか、中間コードから各自でネイティブコードを生成してもらうかを選択しなくてはいけない。
想像してみよう。将来新しいCPUが発表されるたびに過去のパッチに新アーキを追加するなんて可能か。オフライン用パッチのダウンロードに数十個のアーキテクチャがずらっと並ぶ光景とか。
事前にバイナリ用意する必要は無いでしょ
世の中に同じCPU積んだマシンはごまんとあるんだから最適化に必要なパラメータだけ今流行りのクラウドへ投げてクロスコンパイルさせた端からキャッシュさせとけばよろしい
それこそマイクロソフトご自慢の Azure の威力を見せつける良い機会だろうに末端のPC毎に1時間以上占有して何も作業できませんとか時代に逆行もいいところ
むしろこれは Azure の威力を見せつけるための伏線か何かじゃないかと勘ぐってしまう
「トラフィックで死ぬので勘弁してください by 企業内LAN管理者」「JITコンパイラ側のFixとかだと数百KBのFixが数十MBのFixに化ける」「アーキ毎にKB変えて提供するとFixの管理がヤバイ。かといって全部一個にまとめると本末転倒」
とか、軽く考えるだけで問題山積みですわな。有る程度は解決できるとはいえ、元々Fixの提供単位がCPUアーキごとになってないからトラブル多すぎ。っていうか、それを避ける為のJITであり.NETなのに、そんなことしたら意味が無い。
「アーキ毎にKB変えて提供するとFixの管理がヤバイ。かといって全部一個にまとめると本末転倒」
いや、まぁ、.NET Framework の更新も WSUS とかで見てると、x86/x64/IA-64 がそれぞれ出てくるんですけどね。
結局それぞれの環境ごとの最適化もプリコンパイルしておく事となるので結局コンパイル (+ セキュリティーチェック等) の時間がかかる訳ですけど。
x64 環境だと x86 向けバイナリもあるのでさらに時間が増えますね。
x86/x64/IA-64が分離しているのは、OSそのものが別物として提供されているからです。
そういう話ではなく、各系列ごとの世代差などに対する最適化の問題です。x86の場合、有効な命令セットだけで分類しても10世代を軽く超えていて、命令セットが同じでも分岐予測の構造やL1/L2キャッシュサイズでのバリエーションも存在します。JITする場合はそれらの微妙だけれど確実に影響する要素に対しても最適化が可能です。
今の.NETのJITコンパイラがどの程度までこれらを考慮しているかはわかりませんが、既に実装済みだったと思いますよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
なんで、コンパイルなの？ (スコア:0)
なんで、コンパイルなんでしょう？
バイナリー配布出来ない理由は
・バイナリー配布しちゃダメってっていうフリーソースを含んでいる？
・動作環境に依存する？
・？
Re: (スコア:0)
Re: (スコア:0)
環境に応じた最適化って言っても、所詮CPUだったらせいぜい数十種類だと思うんだけど、
一体何をやってるのかな？
そんなに組み合わせが多くて爆発的に増えちゃうようなものなのかな？
Re: (スコア:0)
あくまで中間コードのアセンブリが正で、ネイティブコンパイルしたバイナリは副。
つまり、中間コード＋ネイティブコードで配布するか、中間コードから各自でネイティブコードを生成してもらうかを選択しなくてはいけない。
想像してみよう。
将来新しいCPUが発表されるたびに過去のパッチに新アーキを追加するなんて可能か。
オフライン用パッチのダウンロードに数十個のアーキテクチャがずらっと並ぶ光景とか。
非エコ＆時代錯誤過ぎる (スコア:3, 興味深い)
事前にバイナリ用意する必要は無いでしょ
世の中に同じCPU積んだマシンはごまんとあるんだから
最適化に必要なパラメータだけ今流行りのクラウドへ投げて
クロスコンパイルさせた端からキャッシュさせとけばよろしい
それこそマイクロソフトご自慢の Azure の威力を見せつける良い機会だろうに
末端のPC毎に1時間以上占有して何も作業できませんとか時代に逆行もいいところ
むしろこれは Azure の威力を見せつけるための伏線か何かじゃないかと勘ぐってしまう
uxi
Re: (スコア:1, すばらしい洞察)
「トラフィックで死ぬので勘弁してください by 企業内LAN管理者」
「JITコンパイラ側のFixとかだと数百KBのFixが数十MBのFixに化ける」
「アーキ毎にKB変えて提供するとFixの管理がヤバイ。かといって全部一個にまとめると本末転倒」
とか、軽く考えるだけで問題山積みですわな。
有る程度は解決できるとはいえ、元々Fixの提供単位がCPUアーキごとになってないからトラブル多すぎ。
っていうか、それを避ける為のJITであり.NETなのに、そんなことしたら意味が無い。
Re:非エコ＆時代錯誤過ぎる (スコア:1)
いや、まぁ、.NET Framework の更新も WSUS とかで見てると、x86/x64/IA-64 がそれぞれ出てくるんですけどね。
結局それぞれの環境ごとの最適化もプリコンパイルしておく事となるので結局コンパイル (+ セキュリティーチェック等) の時間がかかる訳ですけど。
x64 環境だと x86 向けバイナリもあるのでさらに時間が増えますね。
Re: (スコア:0)
x86/x64/IA-64が分離しているのは、OSそのものが別物として提供されているからです。
そういう話ではなく、各系列ごとの世代差などに対する最適化の問題です。
x86の場合、有効な命令セットだけで分類しても10世代を軽く超えていて、命令セットが同じでも分岐予測の構造やL1/L2キャッシュサイズでのバリエーションも存在します。
JITする場合はそれらの微妙だけれど確実に影響する要素に対しても最適化が可能です。
今の.NETのJITコンパイラがどの程度までこれらを考慮しているかはわかりませんが、既に実装済みだったと思いますよ。