次世代言語27 Nim Zig Pony Carbon Gleam (308ﾚｽ)
上下前次1-新
1(1): (ﾜｯﾁｮｲ c35f-St8y) 2022/08/05(金)09:40 ID:/hLfNpmA0(1)調 AAS
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
スレタイ（順番はRedMonk準拠）以外の言語もok
前スレ
次世代言語26 TypeScript Swift Go Kotlin Nim
2chｽﾚ:tech VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
2: (ﾃﾃﾝﾃﾝﾃﾝ MMee-Jv5Y) 2022/08/05(金)12:18 ID:X0qTPiXKM(1)調 AAS
乙
3: (ﾜｯﾁｮｲ ba7c-t4GX) 2022/08/05(金)20:57 ID:IaHwMjJC0(1)調 AAS
本スレ
4: (ﾜｯﾁｮｲ 9a4b-Xfpw) 2022/08/05(金)23:22 ID:mIb2aBTZ0(1)調 AAS
ただし Rust言語ネタは禁止します
5: (ｱｳｱｳｳｰ Sa55-9Xv3) 2022/08/06(土)15:25 ID:eSBCWCwIa(1)調 AAS
>>1
O2
6(1): (ﾜｯﾁｮｲ 895f-UFof) 2022/08/07(日)04:00 ID:40aW3DD80(1)調 AAS
久々にHaxeのプロジェクトページを訪ねてみたらサポートターゲットにHashLinkなるVMが追加されていた
Nekoの後継？
7: (ﾜｯﾁｮｲ 1907-Z5J/) 2022/08/07(日)13:37 ID:Dd35QVWO0(1)調 AAS
過疎やん
8: (ｽｯｯﾌﾟ Sd33-agxP) 2022/08/07(日)15:10 ID:G9vPq40Zd(1)調 AAS
>>6
haxeまだあったのか。
昔ちょろっと見てけっこう良さそうな印象持ったけど流行らなかったな。
nimもトランスレーター系だし、同じ将来にはならないで欲しい。
結局はバックにGAFAMがつくかどうかによるのかねぇ。
それでいうとpythonは運・タイミングが良かったのか。
9(1): (ｻｻｸｯﾃﾛ Sp5d-RXyn) 2022/08/07(日)15:41 ID:SSq6cfdBp(1)調 AAS
nimとかD言語みたいなちょっと良くした程度の言語だと流行らないんだろうなあ
RubyでいうRailsみたいな超人気フレームワークが登場すると話が変わってくるんだろうけも
10(1): (ﾜｯﾁｮｲ 1b8c-lJ3c) 2022/08/08(月)01:27 ID:mO/LiGB20(1)調 AAS
>>9
NimはもっとシームレスにPythonソースを使えればいいんだけど。
nimpyとかnimporterとかって公式になったっけ？
11(1): (ﾜｯﾁｮｲ 132c-D0FT) 2022/08/08(月)15:07 ID:XhYLtnJ40(1)調 AAS
>>10
nimpyやnimporterが公式になるってどういうこと?
標準ライブラリになることを期待してるのかもしれないが、標準ライブラリになったとしても使いやすくなるとは限らないよ。
C/C++のライブラリだったらc2nimやfutharkというツールがC/C++のコードを読んで自動的にバインディングを生成してくれるらしい。
futharkはlibclangを使ってコードをパースするらしい。
12: (ﾜｯﾁｮｲ 13a5-s6Hz) 2022/08/11(木)04:05 ID:Bpvt7Gu80(1)調 AAS
CarbonってC++のABI問題の拗れが引き金となって生まれたものなんだろうけど
わざわざ文法から作り直すことないのにな
実用的なレベルになるまで相当かかりそう
13: (ｽｯｯﾌﾟ Sd33-JIap) 2022/08/11(木)08:03 ID:6LydNS9Hd(1)調 AAS
GoogleでC++の糞の山のメンテばっかりさせられて嫌気が差したんだろ
所詮数あるホビー言語の一つに過ぎないんだから好きにさせてやれよ
14(1): (ﾃﾃﾝﾃﾝﾃﾝ MM8b-lJ3c) 2022/08/12(金)13:09 ID:0xlDyyucM(1)調 AAS
>>11
公式になって手順・ドキュメントが整備されるというということだな。
そうすればもっとpythonコードが流用しやすくなるので、性能で困っているpythonユーザーが手を出しやすくなるかと。
15(1): (ﾜｯﾁｮｲ 937c-agxP) 2022/08/12(金)15:40 ID:bDQmrk+50(1)調 AAS
nimのアンダースコアを無視する仕様は好きじゃない。
16: (ﾜｯﾁｮｲ 132c-D0FT) 2022/08/12(金)18:28 ID:D0nb2yzy0(1)調 AAS
>>14
公式になったからといってドキュメントが整備されるとも限らないし
公式にならなくてもやる気があればドキュメントを整備するＰＲを送ればいいのでは。
>>15
アンダースコアを無視するおかげで、ライブラリがfoo_barみたいな名前を使っていてもライブラリを使う側のコードがfooBarという名前で呼び出せるので命名規則に一貫性をもたらすことができる。
しかしCのライブラリがfoo_barとfooBarという異なる二つの関数を持っているとNimから使うときに違う名前を使って参照するようにbindingを書かなくてはいけなくなってしまう。
そいいうケースはあまりないけどね。
17(3): (ﾜｯﾁｮｲ 468c-Waa7) 2022/08/13(土)22:42 ID:6wAoLN5t0(1)調 AAS
Rustを見てて疑問に思うところがあるんだけど、
「コールスタック専用変数」「ヒープ用変数」といった
使い分けをする言語はあるのかしらん？
現状の言語で近いのは
C：変数はコールスタック専用。ヒープのインスタンスはポインタで管理
Rust：変数はコールスタック専用。ヒープ用変数はBox、Vec、Rcとかで模倣
ぐらいか。
コールスタックにあるインスタンスはスコープに連動するRAIIとかの便利な特性があるから、
他の言語でもコールスタック専用変数があってもいいと思うんだけど。
例えばJavaにコールスタック用変数があればfinalizeメソッドももっと使いやすくなりそう。
コールスタック用変数専用クラスとかあってもいいし。
18(1): (ｽｯｯﾌﾟ Sd62-Rl2g) 2022/08/13(土)23:29 ID:601ao6Evd(1)調 AAS
スタックとヒープの使い分けができるという意味ならGoとかC#とか
19: (ﾜｯﾁｮｲ 422c-GRcq) 2022/08/14(日)01:50 ID:H+Dty+yM0(1/6)調 AAS
>>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。
だいたいのシステムプログラミング言語ならヒープとスタックを使い分けられるんじゃないの？
20(1): (ﾜｯﾁｮｲ 422c-GRcq) 2022/08/14(日)01:50 ID:H+Dty+yM0(2/6)調 AAS
>>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。
だいたいのシステムプログラミング言語ならヒープとスタックを使い分けられるんじゃないの？
21(1): (ﾜｯﾁｮｲ 468c-8lLW) 2022/08/14(日)01:53 ID:XCwSZ99k0(1/2)調 AAS
>>18
変数のエスケープ解析して自動でヒープとスタックを使い分けるんじゃなくて、その変数をスコープからエスケープするような使い方をしたときにコンパイルエラーにするようなのを想定しています。
スタックフレーム制約付き変数ですな。
22(1): (ﾜｯﾁｮｲ 468c-8lLW) 2022/08/14(日)02:03 ID:XCwSZ99k0(2/2)調 AAS
>>20
確か、Nimもスタックフレームにインスタンスを置くことを強制できなかったかと思うけど、どうだったっけ？
23: (ﾜｯﾁｮｲ 422c-GRcq) 2022/08/14(日)02:10 ID:H+Dty+yM0(3/6)調 AAS
>>17
Nimでもスタックとヒープを使いわけられるよ。
refのついた型とクロージャの環境とstring, seqの中身はヒープに確保される。
それ以外のローカル変数はスタックに確保。
C言語のグローバル変数とstatic変数はstatic storageというスタックとは別の所に置かれるよ。
だいたいのシステムプログラミング言語ならヒープとスタックを使い分けられるんじゃないの？
24: (ﾜｯﾁｮｲ 422c-GRcq) 2022/08/14(日)02:20 ID:H+Dty+yM0(4/6)調 AAS
間違えて連続投稿してすいませんでした。
>>22
type
SomeObj = object
x: int
proc foo =
var x = SomeObj(x: 10) #スタックに確保
var y = new(SomeObj) #ヒープに確保
foo()
25(1): (ｽﾌﾟｯｯ Sd62-IWzR) 2022/08/14(日)09:07 ID:5kZWLu5Dd(1)調 AAS
ここの系列で出たことあるのか知らないし、ちょっと毛色違うんだけど設定ファイル言語でDhallってあるんだね
方向性は凄く好みなんだけど最新バージョンの規格をそのまま食えるのが現状Haskell（とPureScript?）だけらしくて君らそういうところやぞ……ってなってる
yamlやjsonに変換してから食わせることはできるらしいけどやっぱそのまま食えるのと手間と複雑さは無駄に嵩張るし、この手のDSLはどれだけ広い環境で使えるかが重要よねって
26: (ｽｯｯﾌﾟ Sd62-Rl2g) 2022/08/14(日)09:18 ID:E6D9Byfed(1)調 AAS
>>21
C#はスタック変数のエスケープは不可で、その参照を返すようなことはできない
クロージャでキャプチャされたり非同期メソッドの場合にヒープに昇格する例外はあるが、文脈から明らかであり、いわゆるエスケープ解析とは異なるものだ
更に、構造体を ref struct として定義することで上記のような昇格も不可となり、完全にスタック専用になる
27: (ﾜｯﾁｮｲ 4201-8lLW) 2022/08/14(日)10:18 ID:osAuRY7C0(1/2)調 AAS
>>25
ちょっとぐぐってみたけど俺はできると思ってる子がなんかこれあったら便利やんって言うのを色々詰め込んだイメージ
本当にでかい設定ファイルなら嬉しいのかも知れないけど大多数の設定ファイルにはオーバースペック過ぎて流行らないと思う
28: (ﾜｯﾁｮｲ adda-TI6p) 2022/08/14(日)10:55 ID:lDco67Nc0(1/2)調 AAS
オーバースペックさで言うとyamlも相当だしそれだけでは判断できないのでは
29(2): (ﾜｯﾁｮｲ 79f0-mhOm) 2022/08/14(日)19:14 ID:1Y4ysm770(1)調 AAS
スタックとかヒープとか基本的に実装依存じゃないの
言語レベルで規格として策定されてるのある？
30(1): (ﾜｯﾁｮｲ 027c-5Ix7) 2022/08/14(日)19:23 ID:TMCPzdUa0(1)調 AAS
CやC++はmallocやらnewなどでメモリ確保しない限りは全てスタックではないの？
今時のコンパイラはどうやってるのか知らんけど昔は少なくともそうだった
31: (ﾜｯﾁｮｲ 422c-GRcq) 2022/08/14(日)19:43 ID:H+Dty+yM0(5/6)調 AAS
可変長配列とか文字列型などの必要なメモリ量が実行時に決まるものや
関数やブロックのスコープと変数の寿命が対応しないもの(GCで管理されるオブジェクト)などはヒープ使うしかないでしょ。
けどローカル変数などをヒープに置くと効率悪いし。
32: (ﾜｯﾁｮｲ 4201-8lLW) 2022/08/14(日)19:55 ID:osAuRY7C0(2/2)調 AAS
>>29
ハードウェアスタックがないマシン（汎用機とか）もあるから実装依存なのは確かだけどそういうマシンでもソフトウェアでスタック作ってるので実装としてはたいして変わらん
33: (ﾜｯﾁｮｲ 422c-GRcq) 2022/08/14(日)19:58 ID:H+Dty+yM0(6/6)調 AAS
>>30
関数の外にある変数やstatic変数はstatic storageというプロセスが生まれてから死ぬまで存在し続ける領域に置かれるよ。
詳しくはdata segmentとかbssとかで検索してね。
static変数は値を保持し続けないといけないからスタックに置けないし、
関数の外にある変数は複数の関数から共有されるのでコンパイル時かリンク時にアドレスが決まってないといけないと思うのでおそらくスタックに置けない。
34(2): (ｱｳｱｳｳｰ Saa5-xzlL) 2022/08/14(日)20:34 ID:d/RE/iMKa(1)調 AAS
C++の定石としてオブジェクトはスタックに置くのが基本だよ
デストラクタを動かしたいからね
ヒープにデータを割り当てたい時は構造体やクラスでラップするのが基本
35: (ﾜｯﾁｮｲ adda-TI6p) 2022/08/14(日)20:39 ID:lDco67Nc0(2/2)調 AAS
>>29
最適化の余地残すために規格では振る舞いしか記述しないのが基本だと思う
レジスタだけ使うとかあるしね
36: (ｽﾌﾟｯｯ Sd62-IWzR) 2022/08/14(日)20:50 ID:/dHI52Jsd(1)調 AAS
可変長配列に限って言えばCは一応VLAがある
11からオプションだけど
37(1): (ﾌﾞｰｲﾓ MMb6-Rl2g) 2022/08/15(月)08:38 ID:qDRL1WTlM(1)調 AAS
>>34
スマポ使えばいいだけだからそれはない
38: (ｱｳｱｳｳｰ Saa5-xzlL) 2022/08/15(月)13:39 ID:SFJl5V0da(1)調 AAS
>>37
スマポがまさに>>34のパターン使ってるんだけど
39: (ﾜｯﾁｮｲ 027c-5Ix7) 2022/08/15(月)15:41 ID:qHbAfBQi0(1)調 AAS
スマートポインタｗって正直使う必要殆ど無いのに
全てのインスタンス生成で使うバカがいるよねｗ
40: (ﾜｯﾁｮｲ 4201-8lLW) 2022/08/15(月)16:32 ID:zxOEKBbO0(1)調 AAS
今時生ポインタでイキルバカが出てくるとはw
41: (ﾜｯﾁｮｲ e9e6-xzlL) 2022/08/16(火)18:56 ID:1oXHhIiq0(1)調 AAS
スタックに確保されるのがポインタなのかクラスや構造体の実態なのかをちゃんと理解してない人が多すぎるね
コンパイラとかコンピュータアーキテクチャの勉強すべき
そこを避けてたら絶対に使いこなせない
42(1): (ﾜｯﾁｮｲ 027c-5Ix7) 2022/08/16(火)19:04 ID:JSsOGCvC0(1)調 AAS
そもそもスタックやらヒープやらちゃんと意味が分かっている奴って
アセンブラレベルで組んだことがあるとかじゃないと
知らなくても仕方ない気がするなぁ
43: (ﾜｯﾁｮｲ 460f-U+eq) 2022/08/16(火)19:50 ID:RYKZv1s10(1)調 AAS
使いこなす必要は無くて、理解が足りなくてもやりたい事が出来れば、それで良いと思うよ。
44: (ｱｳｱｳｳｰ Saa5-xzlL) 2022/08/17(水)15:25 ID:DfCxGnRFa(1)調 AAS
理解してなくてやりたいことができるってそれはたまたま動いてるか
その機能が必要ないことをやってるだけ
壁が来た時ぶち当たって手遅れになる
最近スクリプト言語系のエンジニアがRustとかのモダン言語で苦しんでるのを見ると
何が理解できてないのか？を理解することってのはすごく大事
45: (ﾜｯﾁｮｲ 3104-GRcq) 2022/08/17(水)16:47 ID:hcUDPGl30(1)調 AAS
Compiler explorerとかでコードがどんな風に最適化されてアセンブリ言語になるか読んでみるといいかもね。
スタックに割り当てられたローカル変数はレジスタに割り当てられる場合はあるけどグローバル変数やヒープにある変数はかならずメモリ上におかれるから毎回メモリからレジスタにロードして値を計算してからメモリにストアされる。
46: (ﾜｯﾁｮｲ ed7c-n+Ky) 2022/08/17(水)17:41 ID:J/baCQNr0(1)調 AAS
最適化でキャッシュの考慮や制御までするんだから
volatileないと実際どうなるかはわからんとちゃうかな
47(1): (ﾜｯﾁｮｲ 9901-5Ix7) 2022/08/17(水)17:53 ID:cnWCAZlk0(1)調 AAS
Rustやるなら当然アセンブラが理解できないとってことだね
メモリ安心安全のためには必要なコストだよね
48: (ﾜｯﾁｮｲ 9901-U+eq) 2022/08/17(水)20:56 ID:9RiCNb2+0(1)調 AAS
プログラム書くのが本業の人なら、どうやってプログラムが動くのか知らなきゃっていうのは分かるけれど、プログラムば手段であって、コピペでも何でも良いから欲しい結果が得られるなら良いって人もいるから。
それで、Rustがそんな人に合わせる必要はないし、そんなのはPython辺りに任せて、Rustはプロフェッショナルの道具でいいんじゃないの？
49: (ﾜｯﾁｮｲ dd5f-FS65) 2022/08/17(水)21:08 ID:3noakHYk0(1)調 AAS
それでいいよ
あっちのスレの空気持ち込まないでくれ
50: (ﾜｯﾁｮｲ adda-TI6p) 2022/08/17(水)22:39 ID:SgLVBpM30(1)調 AAS
>>47
アセンブリ知ってて損することはないけど、必須な知識ではないよ
スタックやヒープの区別について分かっていればよくて、理解のための手段のひとつとしてアセンブリが提案されているだけ
他の手段で理解できるならそれで良い
Cを使いこなすのにアセンブリの知識が必須ではないのと同じ
51: (ﾜｯﾁｮｲ 79f0-mhOm) 2022/08/17(水)23:44 ID:C+o8slGL0(1)調 AAS
書いたコードがどんな機械語になってるか、確認してない層が一定数存在するって事？
周りに居たら嫌だなぁ
52(1): (ﾜｯﾁｮｲ a5a4-n+Ky) 2022/08/18(木)00:15 ID:uPozsGij0(1)調 AAS
どんなバイナリになるかイメージはするけど確認なんてしないだろ
最適化ビルドするとまるで想像通りじゃなくてびびったりはする
53: (ﾜｯﾁｮｲ 827c-Z8r5) 2022/08/18(木)00:23 ID:K1uqUAUE0(1)調 AAS
>>52
だよね。
54: (ﾜｯﾁｮｲ e9e6-xzlL) 2022/08/18(木)01:11 ID:yLDzsouG0(1/2)調 AAS
>>42
俺特殊なハードウェア用のコンパイラとか作ってたんだけど
コンパイラ作ってようやくCがちゃんと理解できたよ
マジでコンパイラ作らないとわらないと思う
55(1): (ｱｳｱｳｳｰ Saa5-oUG4) 2022/08/18(木)11:25 ID:p/limWqpa(1)調 AAS
https://www.kinokuniya.co.jp/f/dsg-01-9784797337952
ISBN 4797337958
56: (ﾜｯﾁｮｲ e9e6-xzlL) 2022/08/18(木)12:21 ID:yLDzsouG0(2/2)調 AAS
>>55
これはまあまあおすすめ
ただ32bitCPU時代に書かれた本なのでそこが微妙なのと
理論的なものがほとんどなく構文解析もJavaCC使ってるし
コード生成も毎回演算結果をスタックにpushするようなことをやってた気がする
allocaも自前で実装するし
ただCのような言語をアセンブリ言語へコンパイルするための勉強としては悪くない
57: (ｱｳｱｳｳｰ Saa5-oUG4) 2022/08/18(木)14:58 ID:qt1eMpHHa(1)調 AAS
著者はruby厨
racc使う予定だったらしい
58: (ﾜｯﾁｮｲ e936-4eON) 2022/08/18(木)21:22 ID:1X5HVpNn0(1)調 AAS
intel ISAのドキュメントがオレオレ用語多くて意味わからん
59: (ﾄﾞｺｸﾞﾛ MM4f-06yp) 2022/09/05(月)00:54 ID:cFc+MJ1wM(1)調 AAS
あげ
60(2): (ﾜｯﾁｮｲ 5f7c-eJ3+) 2022/09/05(月)01:08 ID:9iTWKe040(1)調 AAS
nimも早くnull安全にしてくれないかね。
61: (ﾜｯﾁｮｲ 0701-Jj1I) 2022/09/05(月)01:34 ID:ARttffD10(1)調 AAS
ドラゴンブックを見て一つ一つ実装していくのが良いですよ。
誤植が猛烈に多いのも練習問題のような気がしてきますよ。
62: (ﾃﾃﾝﾃﾝﾃﾝ MM8f-jyuF) 2022/09/05(月)08:15 ID:HWNfM8e/M(1)調 AAS
>>60
このあたりは偏執狂のRustの方が上手だな。
いっそのこと参照型のゼロ値は禁止すればいいのに。
63: (ﾜｯﾁｮｲ 5f4b-Iguz) 2022/09/05(月)22:33 ID:1hFtemgL0(1)調 AAS
>>60
std/options で
ひとまずOK じゃないか ?
64(2): (ﾜｯﾁｮｲ 4704-Ka/N) 2022/09/06(火)04:20 ID:6xx96XME0(1)調 AAS
Not nil annotationはversion2.xで使えるようになるらしいよ。
https://github.com/nim-lang/RFCs/issues/437
65: (ﾃﾃﾝﾃﾝﾃﾝ MMff-jyuF) 2022/09/06(火)08:29 ID:AHhd6ypaM(1)調 AAS
>>64
not nil がデフォルトになるとあるね。
66: (ﾜｯﾁｮｲ 5f4b-Iguz) 2022/09/06(火)13:26 ID:3wQQbwTr0(1)調 AAS
>>64
2.0がいつ出るかなんて全く不明
1.8.0の次は1.10.0
次は1.12.0となって。。。
恐らく5年以上先 ?
67: (ﾃﾃﾝﾃﾝﾃﾝ MM8f-jyuF) 2022/09/08(木)12:38 ID:H4D+Re2GM(1)調 AAS
スタックフレームて大抵の実行環境で使用されているのに、スタックフレームに特化した言語て無いよね。
なんでなんだろう？
68: (ﾜｯﾁｮｲ 4704-Ka/N) 2022/09/08(木)17:28 ID:cKTVDYCV0(1)調 AAS
世の中のほとんどのプログラムにはヒープメモリが必要だからでしょ。
実行時じゃないとサイズがわからないことがあるし、スタック上に動的にメモリ領域を確保できるようにするとかなり大きめにスタックを確保しなくてはならくなるだろうし。
69(2): (ﾜｯﾁｮｲ e7da-ZIhe) 2022/09/08(木)18:05 ID:U6/gufpm0(1)調 AAS
スタックフレームに特化した言語ってどういうものを想定してるの？
Forthみたいなスタック指向の言語とは違うよね
70: (ﾜｯﾁｮｲ 5fe0-InTp) 2022/09/08(木)18:22 ID:ydRaiFc90(1)調 AAS
実CPUのスタック操作なんて仕様にいれたら足枷だしね
関数のABIとは別に仮想的なローカルスタックを扱えるかんじ？
71: (ﾌﾞｰｲﾓ MM8f-W2iS) 2022/09/08(木)18:50 ID:11l7kxGRM(1)調 AAS
>>69
COBOL++でしょ
72(1): (ﾃﾃﾝﾃﾝﾃﾝ MM8f-jyuF) 2022/09/08(木)19:36 ID:gDKj2SJwM(1)調 AAS
>>69
スタックフレームならではの特性をコードに明記できる、といったイメージ。
例えばスタックにあるインスタンスしか受け付けない(参照)引数とかあれば、shared ptrとかunique ptrの参照渡しも安全に使える。
Rustがそこそこいい感じなんだけど、なんか中途半端。
73(2): (ﾌﾞｰｲﾓ MM8f-W2iS) 2022/09/08(木)21:06 ID:g68A8C0LM(1)調 AAS
>>72
Rustなら実用上はCopyで十分
74: (ﾜｯﾁｮｲ 0701-Iguz) 2022/09/08(木)22:22 ID:D8Erj63H0(1)調 AAS
>>73
rustの話は向こうのスレでお願い
75: (ﾜｯﾁｮｲ bf8c-jyuF) 2022/09/09(金)07:32 ID:v1OYGNdb0(1)調 AAS
>>73
そういうのが中途半端だと言っている。日本語も読めないのかよ。
76: (ﾜｯﾁｮｲ a95f-Yvh5) 2022/09/16(金)11:26 ID:eTFy07in0(1)調 AAS
800 デフォルトの名無しさん sage 2022/09/15(木) 23:09:10.28 ID:KFRYW2wo
次スレはこれらの言語を入れてください
Zig
https://ziglang.org/ja/
Jakt
https://github.com/SerenityOS/jakt
77: (ﾜｯﾁｮｲ a563-jxjI) 2022/09/16(金)11:34 ID:CoCetj5m0(1/3)調 AAS
Jaktは知らないな
どんな処理系かな
78: (ﾜｯﾁｮｲ a563-FZWc) 2022/09/16(金)11:58 ID:CoCetj5m0(2/3)調 AAS
パッと見の構文はRustソックリ
borrow checkerはなく、代わりにARCを使って実行時にメモリ管理しようとしてるっぽい
なんでRustやZig使わないんだろうと気になったけど、自作したSerenityOSのためのエコシステムはできるだけすべて自作したい、くらいの動機みたい
参考: https://awesomekling.github.io/Memory-safety-for-SerenityOS/
まあZig未満のドマイナー言語にとどまりそう
79: (ﾜｯﾁｮｲ a563-FZWc) 2022/09/16(金)12:01 ID:CoCetj5m0(3/3)調 AAS
書き忘れた
jaktはC++へのトランスパイラ、ってのも特徴
SerenityOSはC++で作ってたから、C++トランスパイラにすれば移行しやすかったってことだろう
80: (ｱｳｱｳｳｰ Sa5b-8eP5) 2022/09/18(日)13:44 ID:KpBP36NGa(1)調 AAS
トンズラパイラに観えた
81: (ﾜｯﾁｮｲ 1e66-JEMU) 2022/09/28(水)19:48 ID:Tun9Z/EC0(1)調 AAS
Nim追加
Language x10 x100 x200 x400 Memory Comment
--------------------------------------------------------------
Zig 0.118 1.073 2.113 4.203 3.2MB (std.HashMap, caller-hash by Context(Fnv1a_64))
Nim(clang) 0.211 1.171 2.245 4.372 4.2MB (CustomCountTable,LTO,ARC,caller-hash) New
C(gcc) 0.136 1.146 2.271 4.531 2.0MB (optimized.c,binary IO,jemalloc,O4,LTO)
C(clang/LLVM) 0.137 1.147 2.280 4.544 2.0MB (optimized.c,binary IO,jemalloc,O3,LTO)
Go 0.152 1.233 2.428 4.832 3.9MB (caller hash,better loop)
Go 0.164 1.346 2.654 5.279 3.8MB (caller hash)
Rust(LLVM) 0.154 1.425 2.838 5.674 2.6MB (optimized-customhashmap,O3,LTO,caller-hash)
以下、caller-hashではない
Go 0.085 0.366 0.693 1.319 61.9MB (parallel.go,reserve 65536/2)<--マルチスレッド
Nim(clang) 0.218 1.255 2.401 4.691 4.2MB (CustomCountTable,LTO,ARC) New
Zig 0.162 1.493 2.970 5.935 4.6MB (std.StringHashMap)
Go 0.182 1.563 3.063 6.097 3.8MB (customhash.go,reserve 65536)
Rust(LLVM) 0.214 1.725 3.396 6.715 3.5MB (optimized,fxhash,O3,LTO)
Nim(clang) 0.316 2.241 4.371 8.633 4.2MB (optimized.nim,std/CountTable,65536,LTO,ARC,FNV) New
Nim(clang) 0.332 2.387 4.652 9.152 4.2MB (optimized.nim,std/CountTable,65536,LTO,ARC) New
zig 0.10.0-dev/gcc 12.2.0/clang 15.0.0/Nim 1.6.8/go go1.19.1/rust 1.64.0
CPU Zen3@boost~4.75GHz
https://github.com/benhoyt/countwords
2chｽﾚ:tech
今回の検証では、「C」は定点観測用として固定。
Nim/CustomCountTableはinc呼び出しの引数string copyを抑制。
Nimが想像より遥かに速くて「Cと同程度」以上の結果が出た。
82: (ﾜｯﾁｮｲ 6bf0-rqSc) 2022/10/09(日)07:33 ID:alq59Sy20(1/2)調 AAS
検証 https://blog.fascode.net/2021/10/24/try_julia/
Language 10^5 10^6 Comment
----------------------------------
C++(clang) 0.032 1.029 (O3,LTO,vector,fastmod)
Nim(clang) 0.033 1.031 (O3,LTO,Seq,fastmod)
Nim(gcc) 0.041 1.339 (O4,Seq,fastmod)
C++(gcc) 0.042 1.502 (O4,vector,fastmod)
以下、fastmodではない
Odin(LLVM) 0.073 3.784 (o:speed,[dynamic]int)
Nim(clang) 0.074 3.784 (O3,LTO,Seq)
C++(clang) 0.074 3.785 (O3,vector)
Cython(clang) 0.089 3.797 (O3,libcpp.vector)
Nim(gcc) 0.083 4.410 (O4,Seq)
C++(gcc) 0.085 4.412 (O4,vector)
Zig(LLVM) 0.083 4.410 (OReleaseFast,ArrayList)
Julia(LLVM) 0.254 4.583 (JIT,O3,Int[])
Python(Numba) 0.602 5.236 (JIT,list[int])
PyPy 0.162 7.046 (JIT,list[int])
Cython(clang) 0.696 39.603 (O3,list[int])
Python 1.187 75.740 (list[int])
https://odin-lang.org/
https://github.com/lemire/fastmod
zig 0.10.0-dev/gcc 12.2.0/clang 15.0.2/Nim 1.6.8/Odin dev-2022-10-nightly/
julia 1.8.2/Python 3.10.7/PyPy 7.3.9/Cython 0.29.32/numba 0.56.2
CPU Zen3@boost~4.75GHz
83: (ﾜｯﾁｮｲ 6bf0-rqSc) 2022/10/09(日)07:34 ID:alq59Sy20(2/2)調 AAS
感想:
Juliaは確かに速いが、他との比較は最適化オプションしだい。
動的配列/リストのベンチになるかと思ったが、やってみたらgccが振るわない。
原因はmodulo計算の最適化の違い？ https://godbolt.org/z/T7bKK14fr
ZigはLLVMのmodulo最適化をトリガー出来なかったか。
OdinはLLVM AOTコンパイラとしての性能を引き出せている(今回は)
まだ言語機能の特徴をつかんでいないが、映画、ゲームグラフィックス分野で使う様な
ライブラリが最初から入っているのが売り？
Nimは殴り書きとか、書き捨てとか、簡潔に書けて、gcc/clangの速い方を選べて、
fastmodの様なC++「header only」のライブラリを手軽に利用できるのが良い。
Cythonも慣れたらNimと同じように出来るのだろうか。
84: (ﾜｯﾁｮｲ 074b-kHT+) 2022/10/09(日)11:10 ID:hHOnLIUR0(1)調 AAS
並べるときは速度の早い順で書いて下さい
85: (ﾜｯﾁｮｲ d9f0-ofdD) 2022/10/31(月)12:29 ID:RFzpfvk70(1)調 AAS
「Python 3.11」がリリース、4年で5倍の高速化を目指す「Faster Cpython」計画が始動
https://forest.watch.impress.co.jp/docs/news/1451751.html
200万ドル程度と見積もられる資金はMicrosoftが協力
参考
Faster-Cpython Microsoft
Pyjion Microsoft
Cinder Instagram/Facebook/Meta
GraalPy Oracle
Pyston Dropbox->pyston-lite
Ruby3 3倍速->rya
86: (ﾜｯﾁｮｲ 8901-HLP5) 2022/10/31(月)13:03 ID:4lYEr6WH0(1)調 AAS
Rust「…」
87(1): (ﾜｯﾁｮｲ e5f0-FFna) 2022/11/13(日)10:14 ID:lA0JSaU/0(1)調 AAS
検証??
https://i.imgur.com/EjOYpAq.png
88: (ﾜｯﾁｮｲ 234b-H0Ic) 2022/11/13(日)17:19 ID:vYboHCwy0(1)調 AAS
>>87
時間比較する時は
時間で昇順ソートした表を掲載して下さい
89: (ｱｳｱｳｳｰ Saa9-FFna) 2022/11/14(月)11:28 ID:EWF0SvAna(1)調 AAS
>Nimが想像より遥かに速くて「Cと同程度」以上の結果
Nimが速いのはトランスパイラだからな
上下前次1-新書関写板覧索設栞歴
あと 219 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s