No.1
前スレ
次世代言語26 TypeScript Swift Go Kotlin Nim
https:
前スレ
次世代言語26 TypeScript Swift Go Kotlin Nim
https:
100: 次世代言語27 Nim Zig Pony Carbon Gleam (315)
レス数: 52
概要: スレタイ（順番はRedMonk準拠）以外の言語もok 前スレ 次世代言語26 TypeScript Swift Go Kotlin Nim https://mevius.5ch.net/test/read.cgi/tech/1655771266/
前スレ
次世代言語26 TypeScript Swift Go Kotlin Nim
https:
No.265
No.266
久しぶりに速度をはかるとかなり高速化されているようだ。
単純なフィボナッチ計算４５桁で実測
-d:releaseコンパイルで約26%, -d:dangerで約33%高速化している。
(実際の高速化はこの一つ前のバージョン2.0.10でされている）
No.267
チェックの省略やTCOが上手になったのかな
Cコードで差分とってみてほしい
No.268
nimから出力されたCコードの差分を取った所、違っていた箇所は以下の２点でした。
①メイン処理に入る前のnim側の初期化処理（関数名が変わっている）
②フィボナッチ関数内のresult変数の０初期化
※gccのコンパイルオプションも全く同じ
特に高速化に繋がる変更はなく、なぜ早くなるのか不明でしたが、色々と試して
上記②が原因と分かりました。
nimのresult変数の初期化が入る事で、ｇｃｃ側のコンパイル最適化で高速化
しているようです。
試しにnim2.0.8でresult変数を０初期化した所、nim2.2.0と同じ処理速度
が出る事が確認できました。
(フィボ関数内の先頭でresult変数を０初期化し、以降の算出値をresult変数に
格納するように変更した）
No.269
Nimの場合はバックエンドに使うCコンパイラの最適化能力も実行速度に影響します。Nimのバージョン間の実行速度を比較するときにCコンパイラのバージョンを同じにしていますか?
面倒でなければCコンパイラの出力するアセンブリコードを読むと何故result変数を0初期化することが処理速度に影響するかわかると思います。
--passC:"-S"というコンパイラオプションをNimに渡すとnimcacheディレクトリにアセンブリコードが出力されます。
No.270
当然同じ環境です。choosenimでバージョン切り替えて確認してます。
私の疑問点は解消しましたし、gcc側の最適化内容まで追うつもりはないので、私の方の検証はこれで終了とします。
No.271
ミッチェル・ハシモト氏の個人開発によるターミナルエミュレータ「Ghostty 1.0」、12月に正式リリース予定。オープンソースとして公開へ
2024年10月25日
https:
No.272
No.273
No.274
No.275
No.276
No.277
マジかよ
それはショックだな
No.278
非同期の仕様が全然決まらないかららしい
本家はLLVMに変わるコンパイラバックエンドに注力してるみたいだけど
そんなことより言語仕様とか標準ライブラリやったほうがいい気はする…
No.279
本家は今のCの適用範囲をそのままZigで置換することを目指していて
範囲外にある非同期に関心薄いのはしょうがないのでは
No.280
Rust for Linuxの騒動でも感じたけどCにこだわりのある人はC以外に移行しないと思う
移行してもいいって人はすでにRustなりに行ってる可能性高いし
組み込み系は残ってるけど認定コンパイラ必須だからハードル高いし
そもそもユーザ増えないと認定にお金出してくれる会社も現れないんだよな
No.281
ならcでいいってなるね
No.282
No.283
WebAssemblyに特化した言語「MoonBit」のコンパイラがGitHubで公開
https:
No.284
No.285
No.286
No.287
わざわざ別言語を挟む必要なし
No.288
llvmにすりゃよかったのに
今時コンパイラをセルフホスト出来てないのは厳しい
No.289
Component Modelの実装もWATで全部記述するってことだろうけど、つよつよな人だー。
No.290
現状Wasmを使いたくなるケースがJS系より高速な数値計算くらいなんだからテキスト形式で十分
ブラウザゲームのような特殊な用途ではない限り、現行では未だ課題の多いWasmが従来のJS系+Htmlを食らうことはない
Wasmでstdの規格が制定されてWasmファイル容量の大幅削減が実現してからが本番
No.291
一応llvmで書き直す構想はあるみたいだ
No.292
ライブラリも豊富になってきたし
No.293
Lispかける人なら余裕だと思うよ
知らんけど
No.294
No.295
No.296
今回issue残件が脅威の1000件超えのままだけど来月までに選別していつも通り大半を持ち越し
目玉の増分ビルドは正式リリースに届かないっぽいかな
他も根本から書き直しってのが多くて新機能は何が正式に入るのか謎だ
No.297
増分ビルドはnightlyでマージ済み
No.298
増分ビルドはテスト不足でデフォルトだと無効になっちゃってるようだ
> this feature is not ready to be enabled by default,
> it can be opted into via the -fincremental flag passed to zig build.
使ってみたいなら -fincremental オプションで明示的にオプトインしてねってことなので
有効化したらメッチャ高速になった…！ええやん！
No.299
No.300
No.301
きりのいいとろこで2030年ごろじゃね？
No.302
> 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
No.303
は？別にそこはいいじゃん
No.304
魔法陣のようなプログラミング言語「Mystical」
https:
No.305
No.306
jank programming language
https:
No.307
clojureは、結構javaのクラスライブラリ呼んでなんとかしてる感じしたので、その点どうなるのかね。
No.308
https:
No.309
https:
ZigはCに近いパフォーマンスを出しながらも無駄なオーバーヘッドが少なく、ガベージコレクタをもたずにメモリ管理を手動で行うことから、SSHのような長時間稼働するサービスを効率良く動かせると見られている。
No.310
なんでよりによってSSHをメモリ安全でない言語で？
No.311
No.312
愚かな人間の都合など完全無視、LLMのための高効率プログラミング言語「Sui」（粋）
AIが正確に、安く実行できることを最優先
https:
No.313
