24/09/01 15:29:07.17 f0nFMo6oM.net
RustがCより速くなるベンチマークは見たことがないです
NimのORCは明示的にオブジェクトプールを使ったプログラミングが必要ですが
ベンチマークがCより２倍以上速くなって、特にハードなリアルタイムシステム向け
のチューニングもできるようになっているようです
URLﾘﾝｸ(zenn.dev)
NimがCより２倍以上速くなって、しかもORCでメモリ安全も担保されているなら
Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか？
263:デフォルトの名無しさん
24/09/08 01:45:12.42 Hh5CAE6t0.net
>>262
nimは一旦ｃに変換してコンパイルするので、ｃより早くなる事はないです。
ベンチマークで早くなっているのは、メモリプールを使っているからです。
(個別にヒープメモリを確保するのではなく、大きなブロックで一度に確保して
自分で割り当てを管理しているから）
私もｃでメモリプールを実装した事がありますが、ヒープのメモリ確保のコスト
は以外と大きくて、一括で確保するのはパフォーマンスの面で効果が大きいです。
またこのメモリプールの部分は自前でメモリ管理しているため、ＯＲＣとは関係が
ないです。（参照リンク元の記事の意図は、ＯＲＣと手動管理が混在できる事を
利点としているかと思います）
Ｒｕｓｔは詳しくないのですが、おそらくこのレベルの実装は可能だと思うので、
同じように実装すれば同程度の速度向上になるかと思います。
（ただし一括メモリ確保->個別データに強制castが必要で安全性は落ちる）
参照リンク元の記事は、メモリプールのような低水準のコードでもＮｉｍは高い
可読性で書く事ができると言いたいのでは。（手動確保したメモリをdestroy定義
で自動解放できる所とか）
264:デフォルトの名無しさん
24/09/08 07:43:41.27 vegiTRtO0.net
>>262
>ベンチマークがCより２倍以上速くなって
という記述は見当たらないけど
> NimがCより２倍以上速くなって、しかもORCでメモリ安全も担保されているなら
> Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか？
「メモリプールが速い」は本当だろう
「Cより速い」は、そもそもそんなことを書いてないのでダウト
Rustは分からんけどGCが無いぶんNimよりは有利なのでは
265:デフォルトの名無しさん
24/10/02 13:03:50.53 XbzwGALZa.net
RustがNimより速い訳がない
266:デフォルトの名無しさん (ﾜｯﾁｮｲ ffad-4whB)
24/10/03 12:29:21.43 gQlcDFcc0.net
nim 2.2.0 リリース
久しぶりに速度をはかるとかなり高速化されているようだ。
単純なフィボナッチ計算４５桁で実測
-d:releaseコンパイルで約26%, -d:dangerで約33%高速化している。
(実際の高速化はこの一つ前のバージョン2.0.10でされている）
267:デフォルトの名無しさん
24/10/03 13:32:37.43 /N1KY/IS0.net
実用コードでそこまでの差はないだろうけど
チェックの省略やTCOが上手になったのかな
Cコードで差分とってみてほしい
268:デフォルトの名無しさん
24/10/05 02:05:54.37 dycfQkyl0.net
266です。
nimから出力されたCコードの差分を取った所、違っていた箇所は以下の２点でした。
①メイン処理に入る前のnim側の初期化処理（関数名が変わっている）
②フィボナッチ関数内のresult変数の０初期化
※gccのコンパイルオプションも全く同じ
特に高速化に繋がる変更はなく、なぜ早くなるのか不明でしたが、色々と試して
上記②が原因と分かりました。
nimのresult変数の初期化が入る事で、ｇｃｃ側のコンパイル最適化で高速化
しているようです。
試しにnim2.0.8でresult変数を０初期化した所、nim2.2.0と同じ処理速度
が出る事が確認できました。
(フィボ関数内の先頭でresult変数を０初期化し、以降の算出値をresult変数に
格納するように変更した）
269:デフォルトの名無しさん
24/10/05 14:35:02.61 tOSXTi2h0.net
>>266
Nimの場合はバックエンドに使うCコンパイラの最適化能力も実行速度に影響します。Nimのバージョン間の実行速度を比較するときにCコンパイラのバージョンを同じにしていますか?
面倒でなければCコンパイラの出力するアセンブリコードを読むと何故result変数を0初期化することが処理速度に影響するかわかると思います。
--passC:"-S"というコンパイラオプションをNimに渡すとnimcacheディレクトリにアセンブリコードが出力されます。
270:デフォルトの名無しさん
24/10/06 13:25:29.22 yuNPVtUj0.net
>Nimの場合はバックエンドに使うCコンパイラの最適化能力も実行速度に影響します。Nimのバージョン間の実行速度を比較するときにCコンパイラのバージョンを同じにしていますか?
当然同じ環境です。choosenimでバージョン切り替えて確認してます。
私の疑問点は解消しましたし、gcc側の最適化内容まで追うつもりはないので、私の方の検証はこれで終了とします。
271:デフォルトの名無しさん
24/10/26 14:10:58.86 lE9emaTH0.net
Zig言語で開発したターミナルエミュレータだってさ
ミッチェル・ハシモト氏の個人開発によるターミナルエミュレータ「Ghostty 1.0」、12月に正式リリース予定。オープンソースとして公開へ
2024年10月25日
URLﾘﾝｸ(www.publickey1.jp)
272:デフォルトの名無しさん
24/11/29 13:35:59.12 cbzvCkJwd.net
Crystalとかわりと新しめな言語っぽいけど次世代言語としてはあんま価値はない感じ？
273:デフォルトの名無しさん
24/11/29 14:06:07.15 kgssLEYJ0.net
対立煽りに荒らし尽くされて過疎ってるだけだから気にせんと何でも書いてってや
274:デフォルトの名無しさん (ﾜｯﾁｮｲ 7702-cdGy)
24/11/29 18:48:03.79 KH+D4ATv0.net
やはり、実際に採用されたプロダクトが出てくる頻度で見ると、Zigが頭一つ抜けてるな
275:デフォルトの名無しさん
24/12/03 00:07:23.29 SdCS4Rrb0.net
zigをCコンパイラもどきとして扱うのはよく見るけどzig言語の採用例ってあんまり多くなくない
276:デフォルトの名無しさん
24/12/03 06:50:16.97 hGt3IOpB0.net
時雨堂もZig撤退しちゃったしなぁ
277:デフォルトの名無しさん
24/12/03 07:04:26.37 JOdYPQk60.net
>>276
マジかよ
それはショックだな
278:デフォルトの名無しさん
24/12/03 07:13:55.18 hGt3IOpB0.net
>>277
非同期の仕様が全然決まらないかららしい
本家はLLVMに変わるコンパイラバックエンドに注力してるみたいだけど
そんなことより言語仕様とか標準ライブラリやったほうがいい気はする…
279:デフォルトの名無しさん
24/12/03 07:40:52.23 JOdYPQk60.net
>>278
本家は今のCの適用範囲をそのままZigで置換することを目指していて
範囲外にある非同期に関心薄いのはしょうがないのでは
280:デフォルトの名無しさん
24/12/03 08:12:12.79 13VhrJJT0.net
Cの適用範囲ってのが残ってるのかちょっと疑問はある
Rust for Linuxの騒動でも感じたけどCにこだわりのある人はC以外に移行しないと思う
移行してもいいって人はすでにRustなりに行ってる可能性高いし
組み込み系は残ってるけど認定コンパイラ必須だからハードル高いし
そもそもユーザ増えないと認定にお金出してくれる会社も現れないんだよな
281:デフォルトの名無しさん
24/12/03 21:49:17.45 FXu9rGH00.net
zigは結局メモリ安全じゃないからね
ならcでいいってなるね
282:デフォルトの名無しさん (ﾜｯﾁｮｲ 96b4-jW52)
24/12/03 23:16:36.04 hGt3IOpB0.net
zigは未使用変数がエラーになるとか今風の言語っぽく厳しい部分もC好きな人には合わなさそう
283:デフォルトの名無しさん
24/12/24 09:41:20.41 Q1P/mCXL0.net
待望の新言語
WebAssemblyに特化した言語「MoonBit」のコンパイラがGitHubで公開
URLﾘﾝｸ(www.publickey1.jp)
284:デフォルトの名無しさん (ﾜｯﾁｮｲ 61f0-nFNZ)
24/12/27 17:23:49.87 G1CfTzeH0.net
記述言語OCamlじゃん‥
285:デフォルトの名無しさん
24/12/27 17:30:07.17 ETOuh+5m0.net
Haxeを想起させる
286:デフォルトの名無しさん
24/12/28 18:36:13.79 6/sbywh9p.net
今更言語特有の変な記号とか覚えたく、ない
287:デフォルトの名無しさん
24/12/28 18:41:10.43 TMKvqX8o0.net
そもそもWebAssemblyをテキスト形式に書きゃいい
わざわざ別言語を挟む必要なし
288:デフォルトの名無しさん
24/12/28 20:01:23.85 BjukJolw0.net
ocamlが癌だよなあ
llvmにすりゃよかったのに
今時コンパイラをセルフホスト出来てないのは厳しい
289:デフォルトの名無しさん
24/12/29 00:15:57.27 iFrxiC4m0.net
テキスト形式ってWATのことかな？
Component Modelの実装もWATで全部記述するってことだろうけど、つよつよな人だー。
290:デフォルトの名無しさん
24/12/29 10:54:43.90 xYvb8s8e0.net
>>289
現状Wasmを使いたくなるケースがJS系より高速な数値計算くらいなんだからテキスト形式で十分
ブラウザゲームのような特殊な用途ではない限り、現行では未だ課題の多いWasmが従来のJS系+Htmlを食らうことはない
Wasmでstdの規格が制定されてWasmファイル容量の大幅削減が実現してからが本番
291:デフォルトの名無しさん
24/12/29 11:34:20.33 +BdQ0YDt0.net
URLﾘﾝｸ(x.com)
一応llvmで書き直す構想はあるみたいだ
292:デフォルトの名無しさん
24/12/29 14:55:32.92 uE2S0Bjb0.net
今時のコンパイラならrust+llvmが鉄板なんじゃないの？
ライブラリも豊富になってきたし
293:デフォルトの名無しさん
24/12/29 14:58:20.96 uE2S0Bjb0.net
>>289
Lispかける人なら余裕だと思うよ
知らんけど
294:デフォルトの名無しさん
25/01/03 03:33:14.60 REb2C/h00.net
Perlの$%@は良かった
295:デフォルトの名無しさん (ｱｳｱｳｴｰ Sa23-Y8TR)
25/01/05 10:08:03.18 8kdOFrcZa.net
そう思える人はRubyも好きなはず
296:デフォルトの名無しさん
25/01/19 19:22:00.79 zgJXkwkZ0.net
Zigは0.14.0がリリースできず2月に先延ばしされました
今回issue残件が脅威の1000件超えのままだけど来月までに選別していつも通り大半を持ち越し
目玉の増分ビルドは正式リリースに届かないっぽいかな
他も根本から書き直しってのが多くて新機能は何が正式に入るのか謎だ
297:デフォルトの名無しさん
25/01/20 07:55:51.51 /rx6KXgc0.net
>>296
増分ビルドはnightlyでマージ済み
298:デフォルトの名無しさん (ﾜｯﾁｮｲ 0b2a-7Nk8)
25/03/06 15:04:34.42 Y61FoeXm0.net
zig-0.14.0出たよ！恒例の延期はあったけどね
増分ビルドはテスト不足でデフォルトだと無効になっちゃってるようだ
> this feature is not ready to be enabled by default,
> it can be opted into via the -fincremental flag passed to zig build.
使ってみたいなら -fincremental オプションで明示的にオプトインしてねってことなので
有効化したらメッチャ高速になった…！ええやん！
299:デフォルトの名無しさん (ﾜｯﾁｮｲ 3102-TLa3)
25/03/06 19:12:13.02 l4jw4h0Z0.net
Zig 1.0はいつ出るの？
300:デフォルトの名無しさん
25/03/06 19:46:33.97 38v8ReeR0.net
最後の大物、コルーチンをサポートしてzig 1.0かなぁって予想。
301:デフォルトの名無しさん
25/03/24 18:22:12.85 mpEtAgOm0.net
>>229
きりのいいとろこで2030年ごろじゃね？
302:デフォルトの名無しさん
25/03/24 22:03:16.05 +P7EWERr0.net
MoonBitでLLVMを再構築するとのこと
> We will rebuild a better LLVM in MoonBit starting this year,
> modern compiler toolchain in a modern language and it will be deveoped in OSS
303:デフォルトの名無しさん
25/03/25 13:53:04.66 z+9Q790S0.net
>>302
は？別にそこはいいじゃん
304:デフォルトの名無しさん
25/05/20 08:58:30.48 wvxe5xAp0.net
待望の新言語
魔法陣のようなプログラミング言語「Mystical」
URLﾘﾝｸ(gigazine.net)
305:デフォルトの名無しさん
25/05/21 05:37:24.48 tVhMy6rt0.net
元はforthかな
306:デフォルトの名無しさん
25/07/13 21:25:38.68 ttim25hJ0.net
待望の新言語
jank programming language
URLﾘﾝｸ(jank-lang.org)
307:デフォルトの名無しさん
25/07/14 13:40:56.77 qata7TEE0.net
lisp方言が増える感じなのかな？
clojureは、結構javaのクラスライブラリ呼んでなんとかしてる感じしたので、その点どうなるのかね。
308:デフォルトの名無しさん
25/07/17 12:44:48.46 TY8Q4fcO0.net
Unison 言語から、「次」の言語を考察したい
URLﾘﾝｸ(zenn.dev)
309:デフォルトの名無しさん
25/11/20 09:14:17.78 QY1RnXH90.net
SUSE、Zig言語でSSHの再実装にチャレンジ
URLﾘﾝｸ(gihyo.jp)
ZigはCに近いパフォーマンスを出しながらも無駄なオーバーヘッドが少なく、ガベージコレクタをもたずにメモリ管理を手動で行うことから、SSHのような長時間稼働するサービスを効率良く動かせると見られている。
310:デフォルトの名無しさん
25/11/20 16:30:37.91 ncYlBBwT0.net
>>309
なんでよりによってSSHをメモリ安全でない言語で？
311:デフォルトの名無しさん
25/11/20 17:09:22.39 E1SPcZchM.net
いわゆるハッカソンでしょ