-
nana4gonta
- 20379
- 3
- 11
- 1
-
- いいね！1
Hideyuki Tanaka
@tanakh
shootout見てる感じでは、C++よりやっぱ数倍遅くて、Goと同じぐらいかちょっと遅いかぐらいな(´･_･`)Javaよりは遅いっぽい。
2014-10-01 01:03:31
Hideyuki Tanaka
@tanakh
あとメモリとかクロージャーとかに部分的に線形型のようなものをサポートしてて、並行処理にらんでるっぽいのがちょっと気になる(´･_･`)
2014-10-01 01:10:55
Hideyuki Tanaka
@tanakh
広く使われているｘｘな言語を改良すると考えるんじゃない。それは確実に失敗する。逆に考えるんだ。既に存在する、イケてるけどいまいち受け入れられていない言語を、現代人好みにアレンジして、提供する。それがRustなんだ。
2014-10-01 03:48:52
Hideyuki Tanaka
@tanakh
cargo, gitレポジトリ奥田家な感じなので、中央レポジトリのあるパッケージマネージャ見たいに、ライブラリのリスト眺めてほぇぇ、とか言うのができなくて、残念。
2014-10-01 00:44:33
Hideyuki Tanaka
@tanakh
crates.io/faq.html We plan to support git repositories as a source of packages forever とかいってて、foreverとかいうぐらいgitは恒久的なインフラになったんだなあと思いました
2014-10-01 00:46:16
Hideyuki Tanaka
@tanakh
malloc/freeのオーバーヘッドとフラグメンテーションを考慮すればGCのほうがスループット高い場合も多いし、問題になるのはリアルタイム性では…(´･_･`)
2014-10-01 01:13:07
Hideyuki Tanaka
@tanakh
ガベコレがあることによってmalloc/freeのオーバーヘッドが消滅するので、単純にオーバーヘッドじゃないんだよなあ
2014-10-01 01:15:07
Hideyuki Tanaka
@tanakh
任意のサイズの移動不可能なメモリ確保・解法を効率的に行えるはずがないんだよなあ…。世の中のmalloc実装どこまで行ってもつらい気がする。
2014-10-01 01:16:08
Hideyuki Tanaka
@tanakh
malloc/freeは任意のサイズの確保解放クエリが任意の順で行えなければならないので、本質的にワーストケースでのオーバーヘッドとフラグメンテーションが防げないと思っていたんだけど、よく考えたらC++の上ではより制限された形にはできるのかもしれない…けど現実はそうでもないしなあ
2014-10-01 01:21:34
Hideyuki Tanaka
@tanakh
よくわかんないけどgccのmallocとgoogleが出してるmallocはいまいちなんかフラグメンテーションには効果がなくて死にそうなときに、モジラのmalloc実装が助けになった思い出(´･_･`)
2014-10-01 01:23:41
Hideyuki Tanaka
@tanakh
Firefoxなんてmallocで苦しんでるアプリケーションの最たるものだろうから、やっぱ頑張ってるんだなあと思った。
2014-10-01 01:24:12
Hideyuki Tanaka
@tanakh
tcmallocのほうがトップスピードでそうだけど、jemallocのほうがフラグメントには強いイメージなんだけど、数年前の知識すなあ…
2014-10-01 01:25:53
Hideyuki Tanaka
@tanakh
tcmallocのほうがトップスピードでそうだけど、jemallocのほうがフラグメントには強いイメージなんだけど、数年前の知識すなあ…
2014-10-01 01:25:53