Rust Part6
レス数が1000を超えています。これ以上書き込みはできません。
Chromiumのソースもそんなん(長い関数クラス名とか)だけど どういう経緯で何が起こって開発元は原因は何だとしてるのか
ちゃんと説明しろ >>953
「セキュリティに関わるのでお答えできません。知りたきゃソース見ろ」
だそうです C++はRustだった
今すぐモジラのステマ言語C++を使うのをやめろ それでもFireFoxがいい
軽さとセキュリティの誠実さ
ブックマーク回りはころころ変わってひどいけど GoogleやMicrosoftのWebブラウザは十数枚開いただけでメモリ消費がやばいことになる
Mozillaならそんなことない 実践Rustって、電子書籍版を8インチタブレット(iPad mini)でちゃんと読める大きさ?
前に出たRust本は余白カット表示してギリギリって感じだった >>959
逆だろ
火狐はタブ10個も開けばカクツキ起きるしそれからほどなくしてフリーズ
Chromeはもちろんクソクソ言われてるEdgeすらも
動作の安定面では火狐なんぞには負けん
ちなWin10 >>960
本のステップで分ける説明より、2→4→8→... と増えていく図を見たほうが分かりやすいと思った
ttps://www.cs.rutgers.edu/~venugopa/parallel_summer2012/bitonic_overview.html >>964
FireFoxで10タブ開いてみたけどなんも変わらんよ? >>966
20~30くらい同時に開くとビジーになるからビジーとフリーズの区別がついてないんだと思う。 IEやChromeで100Tabとか開いたらメモリを食いつぶしてまとも動かないよ その分今でもメモリ周りでバギーってのは笑わせますね。 Firefoxなら100タブくらい大丈夫だよ。IE、Chromiumでそんな事したら他の作業が出来なくなってしまうけど
実際に比べた上でFirefoxを使っている。開発やっていると開くページがどんどん増える Rust→IR→Cが実用出来るようになるのはいつだ
LLVMが対応していないアーキテクチャでRustを使いたいねん
それともトランスパイラを作った方が早いかなぁ 524 デフォルトの名無しさん sage 2019/07/02(火) 14:38:03.95 ID:ep8keXko
言語機能の複雑さという代償はあったが
GC無しでリージョン推論を実現したのがRust
記述性のためGCを入れつつも遅延を最小にすべく
GCの性能向上に努めたのがGO
一方vlangの公式によると
https://vlang.io/
> V manages memory at compilation time (like Rust)
https://vlang.io/compare
> - No GC
> That's why the language is so simple
・Rustのようにコンパイル時にメモリ管理される
・Goのように書けるがGC不要
・それでいてRustのような複雑さは無い
・という予定(まだ未実装)
本当にこの通り実現するなら
GoとRustの設計者達にマウント取れるレベル
526 デフォルトの名無しさん sage 2019/07/02(火) 14:59:25.78 ID:ep8keXko
ちなみに自動メモリ管理が未実装なので、以下の記事によると
hello worldやvlangコンパイラ自体もメモリリークしているとのこと
https://christine.website/blog/v-vaporware-2019-06-23
> The compiler itself also leaks memory
531 デフォルトの名無しさん 2019/07/02(火) 18:22:15.31 ID:NqAwj9wC
>>526
www
532 デフォルトの名無しさん sage 2019/07/02(火) 18:59:24.21 ID:8dHuftNb
>>526
あっ・・・(察し) >>973
rust2cトランスレータはとっくの昔にあるしとっくの昔にどれも開発止まってる
rust->llvm->c->任意のコンパイラで出来るじゃん。 >>974
生ポインタ使えるの?新しすぎるせいからしい情報が見つからんかった
>>977
今出てくるCバックエンドの話って関数レベルで使えれば御の字みたいなのばっかりに見える
プロジェクトレベルで実用に耐えるワークフローがあるなら詳細を知りたい >>608
横田さん潜伏中に生魚あたってハイタのかな?排他だけに。
なかなかRockだね!Lockだけに。 >>978
>プロジェクトレベルで実用に耐えるワークフローがあるなら詳細を知りたい
rustでは見たこと無いね。操作的意味論に基づいて命令列とグルーコードに変換するものばかり。
というかそれ以外は難しいと思う。 >>980
やっぱりそうか、残念。LLVMのバックエンドは作れる気がしないしトランスパイラの方が望みがあるけど
それでもELFのパーサとジェネレータ、変換元機械語のデコーダは最低必要だな
こういうのって処理系やエミュレータ等でしばしば使われるけど、単体のライブラリとなるとx86とかの
有名なアーキテクチャですらなかなかないんだよな Cと比べたらノウハウ少ないかもしれんけど、LLVMバックエンド作るのってそんなに面倒なの?
LLVM->Cって抽象度上げる方向だし参考になるものがもっと少ない気がする。ecmascriptenくらいじゃない? >>982
Rust to Cは自分の手に負えそうにないので他力本願です
ググって出てくる情報を見る限り最適化コンパイラを自作できるくらいの理解がないとLLVMの理解とバックエンドの開発は難しそうに感じます
各言語やアセンブラを使える程度の理解では歯が立ちそうにないです
なので機械語 to 機械語(もしくはアセンブラ to アセンブラ)の方がまだ望みがあるかなと バイナリ変換ってかなり壮大な研究テーマでは…。
どうしてもLLVMに触れたくないならLLVM-IR to アセンブリを自作するほうがまだましかな。
結局素直に勉強してLLVMバックエンド作るのが一番早いと思うけど。 >>984
LLVM IRってレジスタ数が青天井ですしstd付きとはいえHello worldですら十数本使っているようです
何処まで増えるのか判りませんがレジスタを数百本使うIRとか吐かれたら何とかなる気がしません
勉強すると言ってもどこから手を付ければいいのか判らない状態ですし最近は相対的にローレベルな
情報自体が減少しています。運良く自分が理解できる資料や教材に巡り会えない限り難しそうです オレオレ → LLVM はレジスタ何本あってもOK
LLVM → CPUネイティブ は良きに計らえ
オレらの仕事は前者
気にすんな そこまで部分の最適化って自分でやらにゃならんし
計算と制約を記述するのに適したその手前までの中間言語ってないじゃろか
Lispとかか バイナリ変換ってダブルバッファリング的な事しないと整合性とれねー気がした。 >>988
レジスタが1〜2本足りないくらいなら使用頻度の低いのからメモリに逃がす方法で何とかなりそうだけど
全然足りない場合全く別の方法が必要そうですが思いつかないです。自分にとっては高度な問題です
Rustと言うかLLVMが吐けてターゲットとの相性が良さそうなアーキテクチャを選ぶ必要があるけどこれも難問かな
IA32/AMD64はメジャーだけど建て増ししすぎでアドレッシングモードとかスーパーカオスだし無駄に命令も多い
ARM7あたりが無難だろうか。分岐処理が特徴的なようだけどRISCの割にレジスタが少なめなのも好条件か
純RISC系は命令セットが単純だけどレジスタが多くてLLVM IRと同じ問題が出てきそう キューイングしてガンガン処理して節目でプログラムカウンタを1増やす。とか理想を語る俺。 2つのvectorの同じインデックスの要素を比較したいときってどうかくのがスマートなんでしょう MISPならツールチェイン揃ってるからPS系ハードで動かないことはない コンパイラチェッカーについて簡潔にまとまっている資料とかないんだろうか
数ヶ月ぶりに触ったらすっかり記憶の彼方だわ RustってVisual Studio Codeとかでビルドしたりインテリセンスが利いたりするようにならんの このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 352日 16時間 14分 50秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。