次世代言語27 Nim Zig Pony Carbon Gleam (308レス)
次世代言語27 Nim Zig Pony Carbon Gleam http://mevius.5ch.net/test/read.cgi/tech/1659660050/
上
下
前
次
1-
新
通常表示
512バイト分割
レス栞
253: デフォルトの名無しさん (ワッチョイ 9edd-rfcW) [sage] 2024/03/30(土) 02:29:10.46 ID:n/Lqlt000 Bun v1.1がついにWindowsネイティブ対応化を引っさげて4月1日リリース予定 日程がエイプリルフールでややザワついてるが敢えてこの日を選んでるっぽい? Bunを作るZigもv0.12.0が4月2日リリース予定になってるが こっちは既に数回無告知延期して公式すら話題にしなくなってるのでまたダメかもしれん http://mevius.5ch.net/test/read.cgi/tech/1659660050/253
254: デフォルトの名無しさん (ワッチョイ c24b-7+Gk) [sage] 2024/04/10(水) 00:48:05.23 ID:PZl/2Qvj0 どんぐりテスト http://mevius.5ch.net/test/read.cgi/tech/1659660050/254
255: デフォルトの名無しさん (ワッチョイ 6760-+hba) [sage] 2024/04/28(日) 22:41:22.44 ID:UPZ0W4Nj0 hoshu http://mevius.5ch.net/test/read.cgi/tech/1659660050/255
256: デフォルトの名無しさん (ワッチョイ a7f9-y8PE) [] 2024/04/29(月) 13:16:16.09 ID:bo2jVeD+0 で?結局どれがいいんだい http://mevius.5ch.net/test/read.cgi/tech/1659660050/256
257: デフォルトの名無しさん (ワッチョイ 2701-Ufki) [sage] 2024/04/29(月) 16:50:51.13 ID:12eKztj20 Rustが死んだからZigかCarbonかな http://mevius.5ch.net/test/read.cgi/tech/1659660050/257
258: デフォルトの名無しさん (ワッチョイ c767-NzXl) [sage] 2024/04/29(月) 22:47:28.69 ID:6wHhtPFS0 死んでるの? 俺の中では同系統のコンセプトに対抗できてる言語が一切見られないので Rust 一強な勢いなんだが。 http://mevius.5ch.net/test/read.cgi/tech/1659660050/258
259: デフォルトの名無しさん (ワッチョイ 2501-b/g4) [sage] 2024/06/08(土) 08:52:15.87 ID:SAkY8LF70 Zigのリリースサイクル早いね、もう0.13.0がリリースされた http://mevius.5ch.net/test/read.cgi/tech/1659660050/259
260: デフォルトの名無しさん (ワッチョイ a575-eRYk) [sage] 2024/07/08(月) 21:11:19.11 ID:EaEf11Cm0 待望の新言語 生成AIに疑似コードで指示すると自然言語よりも効率的にプログラムが生成できるというアイデアから生まれた、生成AI用の疑似言語「SudoLang」 https://www.publickey1.jp/blog/24/aiaisudolang.html http://mevius.5ch.net/test/read.cgi/tech/1659660050/260
261: デフォルトの名無しさん (ワッチョイ 1b16-tQMZ) [sage] 2024/07/09(火) 01:43:38.24 ID:SMbKjjog0 本末転倒だろ http://mevius.5ch.net/test/read.cgi/tech/1659660050/261
262: デフォルトの名無しさん (オイコラミネオ MM1b-qpqo) [sage] 2024/09/01(日) 15:29:07.17 ID:f0nFMo6oM RustがCより速くなるベンチマークは見たことがないです NimのORCは明示的にオブジェクトプールを使ったプログラミングが必要ですが ベンチマークがCより2倍以上速くなって、特にハードなリアルタイムシステム向け のチューニングもできるようになっているようです https://zenn.dev/dumblepy/articles/af2b2b9f8fd890 NimがCより2倍以上速くなって、しかもORCでメモリ安全も担保されているなら Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか? http://mevius.5ch.net/test/read.cgi/tech/1659660050/262
263: デフォルトの名無しさん (ワッチョイ eaad-voeu) [] 2024/09/08(日) 01:45:12.42 ID:Hh5CAE6t0 >>262 nimは一旦cに変換してコンパイルするので、cより早くなる事はないです。 ベンチマークで早くなっているのは、メモリプールを使っているからです。 (個別にヒープメモリを確保するのではなく、大きなブロックで一度に確保して 自分で割り当てを管理しているから) 私もcでメモリプールを実装した事がありますが、ヒープのメモリ確保のコスト は以外と大きくて、一括で確保するのはパフォーマンスの面で効果が大きいです。 またこのメモリプールの部分は自前でメモリ管理しているため、ORCとは関係が ないです。(参照リンク元の記事の意図は、ORCと手動管理が混在できる事を 利点としているかと思います) Rustは詳しくないのですが、おそらくこのレベルの実装は可能だと思うので、 同じように実装すれば同程度の速度向上になるかと思います。 (ただし一括メモリ確保->個別データに強制castが必要で安全性は落ちる) 参照リンク元の記事は、メモリプールのような低水準のコードでもNimは高い 可読性で書く事ができると言いたいのでは。(手動確保したメモリをdestroy定義 で自動解放できる所とか) http://mevius.5ch.net/test/read.cgi/tech/1659660050/263
264: デフォルトの名無しさん (ワッチョイ f9df-BHET) [] 2024/09/08(日) 07:43:41.27 ID:vegiTRtO0 >>262 >ベンチマークがCより2倍以上速くなって という記述は見当たらないけど > NimがCより2倍以上速くなって、しかもORCでメモリ安全も担保されているなら > Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか? 「メモリプールが速い」は本当だろう 「Cより速い」は、そもそもそんなことを書いてないのでダウト Rustは分からんけどGCが無いぶんNimよりは有利なのでは http://mevius.5ch.net/test/read.cgi/tech/1659660050/264
265: デフォルトの名無しさん (アウアウエー Sadf-D2eP) [sage] 2024/10/02(水) 13:03:50.53 ID:XbzwGALZa RustがNimより速い訳がない http://mevius.5ch.net/test/read.cgi/tech/1659660050/265
266: デフォルトの名無しさん (ワッチョイ ffad-4whB) [] 2024/10/03(木) 12:29:21.43 ID:gQlcDFcc0 nim 2.2.0 リリース 久しぶりに速度をはかるとかなり高速化されているようだ。 単純なフィボナッチ計算45桁で実測 -d:releaseコンパイルで約26%, -d:dangerで約33%高速化している。 (実際の高速化はこの一つ前のバージョン2.0.10でされている) http://mevius.5ch.net/test/read.cgi/tech/1659660050/266
267: デフォルトの名無しさん (ワッチョイ 6f9f-xlWa) [sage] 2024/10/03(木) 13:32:37.43 ID:/N1KY/IS0 実用コードでそこまでの差はないだろうけど チェックの省略やTCOが上手になったのかな Cコードで差分とってみてほしい http://mevius.5ch.net/test/read.cgi/tech/1659660050/267
268: デフォルトの名無しさん (ワッチョイ ffad-4whB) [] 2024/10/05(土) 02:05:54.37 ID:dycfQkyl0 266です。 nimから出力されたCコードの差分を取った所、違っていた箇所は以下の2点でした。 ?メイン処理に入る前のnim側の初期化処理(関数名が変わっている) ?フィボナッチ関数内のresult変数の0初期化 ※gccのコンパイルオプションも全く同じ 特に高速化に繋がる変更はなく、なぜ早くなるのか不明でしたが、色々と試して 上記?が原因と分かりました。 nimのresult変数の初期化が入る事で、gcc側のコンパイル最適化で高速化 しているようです。 試しにnim2.0.8でresult変数を0初期化した所、nim2.2.0と同じ処理速度 が出る事が確認できました。 (フィボ関数内の先頭でresult変数を0初期化し、以降の算出値をresult変数に 格納するように変更した) http://mevius.5ch.net/test/read.cgi/tech/1659660050/268
269: デフォルトの名無しさん (ワッチョイ 231f-olmx) [sage] 2024/10/05(土) 14:35:02.61 ID:tOSXTi2h0 >>266 Nimの場合はバックエンドに使うCコンパイラの最適化能力も実行速度に影響します。Nimのバージョン間の実行速度を比較するときにCコンパイラのバージョンを同じにしていますか? 面倒でなければCコンパイラの出力するアセンブリコードを読むと何故result変数を0初期化することが処理速度に影響するかわかると思います。 --passC:"-S"というコンパイラオプションをNimに渡すとnimcacheディレクトリにアセンブリコードが出力されます。 http://mevius.5ch.net/test/read.cgi/tech/1659660050/269
270: デフォルトの名無しさん (ワッチョイ caad-6k2q) [] 2024/10/06(日) 13:25:29.22 ID:yuNPVtUj0 >Nimの場合はバックエンドに使うCコンパイラの最適化能力も実行速度に影響します。Nimのバージョン間の実行速度を比較するときにCコンパイラのバージョンを同じにしていますか? 当然同じ環境です。choosenimでバージョン切り替えて確認してます。 私の疑問点は解消しましたし、gcc側の最適化内容まで追うつもりはないので、私の方の検証はこれで終了とします。 http://mevius.5ch.net/test/read.cgi/tech/1659660050/270
271: デフォルトの名無しさん (ワッチョイ 3901-c8YC) [sage] 2024/10/26(土) 14:10:58.86 ID:lE9emaTH0 Zig言語で開発したターミナルエミュレータだってさ ミッチェル・ハシモト氏の個人開発によるターミナルエミュレータ「Ghostty 1.0」、12月に正式リリース予定。オープンソースとして公開へ 2024年10月25日 https://www.publickey1.jp/blog/24/ghostty_1012.html http://mevius.5ch.net/test/read.cgi/tech/1659660050/271
272: デフォルトの名無しさん (スプープ Sdbf-hCSs) [sage] 2024/11/29(金) 13:35:59.12 ID:cbzvCkJwd Crystalとかわりと新しめな言語っぽいけど次世代言語としてはあんま価値はない感じ? http://mevius.5ch.net/test/read.cgi/tech/1659660050/272
273: デフォルトの名無しさん (ワッチョイ 9f1c-ksDR) [sage] 2024/11/29(金) 14:06:07.15 ID:kgssLEYJ0 対立煽りに荒らし尽くされて過疎ってるだけだから気にせんと何でも書いてってや http://mevius.5ch.net/test/read.cgi/tech/1659660050/273
274: デフォルトの名無しさん (ワッチョイ 7702-cdGy) [sage] 2024/11/29(金) 18:48:03.79 ID:KH+D4ATv0 やはり、実際に採用されたプロダクトが出てくる頻度で見ると、Zigが頭一つ抜けてるな http://mevius.5ch.net/test/read.cgi/tech/1659660050/274
275: デフォルトの名無しさん (ワッチョイ 6208-Dngz) [] 2024/12/03(火) 00:07:23.29 ID:SdCS4Rrb0 zigをCコンパイラもどきとして扱うのはよく見るけどzig言語の採用例ってあんまり多くなくない http://mevius.5ch.net/test/read.cgi/tech/1659660050/275
276: デフォルトの名無しさん (ワッチョイ 96b3-jW52) [sage] 2024/12/03(火) 06:50:16.97 ID:hGt3IOpB0 時雨堂もZig撤退しちゃったしなぁ http://mevius.5ch.net/test/read.cgi/tech/1659660050/276
277: デフォルトの名無しさん (ワッチョイ 4502-WFUB) [sage] 2024/12/03(火) 07:04:26.37 ID:JOdYPQk60 >>276 マジかよ それはショックだな http://mevius.5ch.net/test/read.cgi/tech/1659660050/277
278: デフォルトの名無しさん (ワッチョイ 967c-jW52) [sage] 2024/12/03(火) 07:13:55.18 ID:hGt3IOpB0 >>277 非同期の仕様が全然決まらないかららしい 本家はLLVMに変わるコンパイラバックエンドに注力してるみたいだけど そんなことより言語仕様とか標準ライブラリやったほうがいい気はする… http://mevius.5ch.net/test/read.cgi/tech/1659660050/278
279: デフォルトの名無しさん (ワッチョイ 4502-WFUB) [sage] 2024/12/03(火) 07:40:52.23 ID:JOdYPQk60 >>278 本家は今のCの適用範囲をそのままZigで置換することを目指していて 範囲外にある非同期に関心薄いのはしょうがないのでは http://mevius.5ch.net/test/read.cgi/tech/1659660050/279
280: デフォルトの名無しさん (ワッチョイ 2af5-jW52) [sage] 2024/12/03(火) 08:12:12.79 ID:13VhrJJT0 Cの適用範囲ってのが残ってるのかちょっと疑問はある Rust for Linuxの騒動でも感じたけどCにこだわりのある人はC以外に移行しないと思う 移行してもいいって人はすでにRustなりに行ってる可能性高いし 組み込み系は残ってるけど認定コンパイラ必須だからハードル高いし そもそもユーザ増えないと認定にお金出してくれる会社も現れないんだよな http://mevius.5ch.net/test/read.cgi/tech/1659660050/280
281: デフォルトの名無しさん (ワッチョイ a64d-5eKh) [] 2024/12/03(火) 21:49:17.45 ID:FXu9rGH00 zigは結局メモリ安全じゃないからね ならcでいいってなるね http://mevius.5ch.net/test/read.cgi/tech/1659660050/281
282: デフォルトの名無しさん (ワッチョイ 96b4-jW52) [sage] 2024/12/03(火) 23:16:36.04 ID:hGt3IOpB0 zigは未使用変数がエラーになるとか今風の言語っぽく厳しい部分もC好きな人には合わなさそう http://mevius.5ch.net/test/read.cgi/tech/1659660050/282
メモ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 26 レスあります
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.006s