23/08/27 17:22:00.42 P6KX7G/o.net
>>359
Nim言語が高速なのはC言語コードを吐き出した時に
再帰処理をgotoループに置き換えている可能性があります
その場合C言語のオプションをいくら変更してもあまり意味はない
です
確認はコマンドライン引数に --nimcache:.cache を加えて
コンパイルして.cacheフォルダ内のC言語ファイルを確認すれば
わかるはず
nim c --nimcache:.cache -d:release ...
-d:relsese の部分は -d:danger で 置き換え可能で
dangerのほうが高速です
詳細はここ
URLﾘﾝｸ(nim-lang.org)
コンパイル型言語のベンチを取る時は再帰処理コードは
避けた方が良いと思います
361:デフォルトの名無しさん
23/08/27 17:25:13.06 P6KX7G/o.net
>>360 追記
末尾再帰になっている可能性もありかな
362:デフォルトの名無しさん
23/08/27 22:36:37.59 M561FwxM.net
Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。
gccは再帰関数をループに置き換えているかもしれないからその確認をしたかったら-S -masm=intelを付けてアセンブリコードを出力させて読んでみよう。
363:デフォルトの名無しさん
23/08/28 06:30:35.88 eKgmQu1D.net
>>360
変換キャッシュの見方、ありがとうございます
>再帰処理をgotoループに置き換えている可能性があります
確認したところ、置き換わっていませんでした
>コンパイル型言語のベンチを取る時は再帰処理コードは
>避けた方が良いと思います
↑ここ詳しくお願いします
>再帰処理をgotoループに置き換えている
↑こうなっていませんでしたが、これ前提での話だったのですか?
再帰fibonacciは個別の言語コンパイラ(更にバージョン)の
最適化ベンチマークには持って来いに見えますので
364:デフォルトの名無しさん
23/08/28 06:40:36.37 eKgmQu1D.net
>>362
>Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。
その通りでした
確かめたところ二つの再帰関数コールがそのまま残っていて、
その他はNimのトランスパイル過程でのノイズがあるだけです
gccがノイズを消すために最適化を頑張った結果、Cより速くなったのですかね
365:デフォルトの名無しさん
23/08/28 06:47:48.48 eKgmQu1D.net
何気にNim + gcc HEADにしてみたら、更に速かったです
Nim 2.0.0 + gcc 12.2.0 -O2 (44はコマンドライン引数)
URLﾘﾝｸ(wandbox.org)
>Time= 0.250s Result=701408733
これ↑がこう↓
Nim 2.0.0 + gcc HEAD 14.0.0 -O2 (44はコマンドライン引数)
URLﾘﾝｸ(wandbox.org)
>Time= 0.197s Result=701408733
参考値再掲(>>357)
C/gcc -O2 (44はソース直書き)
URLﾘﾝｸ(wandbox.org)
> Time: 0.89583 seconds
C/clang -O2 (44はソース直書き)
URLﾘﾝｸ(wandbox.org)
>Time=1.58712s Result=701408733
gccの最適化が凄すぎて意味わからないですが、ありがたく享受する事にします
366:デフォルトの名無しさん
23/09/06 06:10:42.54 8VjD58re.net
レバテックωωω
Rust in
Nim out
ωωωωωω
367:デフォルトの名無しさん
23/11/15 08:06:37.71 6Kiw7POr.net
>>353
F#が、 F# Dataってライブラリで、コンパイル時に
ファイルの読み取りは、やってたけれど、あまり見かけないね。
368:デフォルトの名無しさん
23/11/28 09:23:46.10 XbNpNPYt.net
happyxってdjungoの上位互換なれねーかな
URLﾘﾝｸ(hapticx.github.io)
369:デフォルトの名無しさん
23/12/06 09:31:30.20 oM0gjrfW.net
>>367
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴 バージョン1.5.1
URLﾘﾝｸ(nim-lang.github.io)
第二プログラミング言語として Rust はオススメしません Nim をやるのです
URLﾘﾝｸ(wolfbash.hateblo.jp)
Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
370:デフォルトの名無しさん
23/12/06 20:32:47.84 7Cu2FhSW.net
Nim って python を強調し過ぎてるのはミスリードだと思うな
python と相性が良いってのは事実だけど Nim の特徴のほんの一部でしかない
371:デフォルトの名無しさん
23/12/08 21:38:37.62 xBCOoZoU.net
>>370
Python使える人が多いからNimを広めるためにNim言語はpythonと同じだという人は多い。
文法がpythonに近いだけで中身は静的型言語だからpythonよりC++とかRustに近いと思う。
pythonしか知らない人がNimのオーバーロードとかGenericsとかobjectとref objectの違いとかちゃんと理解して使えるのかどうか心配になる。
372:デフォルトの名無しさん
23/12/10 11:41:19.18 1MxEINjf.net
「文法がpythonに近い」が事実じゃないんだよな
観た目が似てるだけであって文法が似てる訳じゃない
全然別物
373:デフォルトの名無しさん
23/12/10 17:02:37.56 S5Hrhavn.net
そういう意味では構文で結構損してそう
オフサイドルールが気に入らない人にとってはそもそも検討に値しないし
Python好きな人ならそこは気にならないだろうけど、別に移行しやすくもない
374:デフォルトの名無しさん
23/12/11 04:52:12.28 E9pPgJ3z.net
>>373
でも静的型言語でオフサイドルールの言語はNimとcrystal以外あまりないのでは。
オフサイドルールが好きで型システムがちゃんとしていて高速に動くプログラムを書きたい人にはぴったり。
375:デフォルトの名無しさん
23/12/11 06:10:19.79 dU0p99Eo.net
型で安全性を静的に担保したいと考える人が、同時にインデントで意味が変わってしまうオフサイドを好むってのはちぐはぐさを感じる
376:デフォルトの名無しさん
23/12/11 06:46:36.74 Oijs0Efp.net
HaskellとデフォルトF#もオフサイドルールありですね。どうせインデントするんだしって使ってやれってくらいの感じなのかね？
あとは、インデントに意味はないけれど、goが標準のフォーマッタでインデント入れてくるね。
377:デフォルトの名無しさん
23/12/11 06:54:57.74 n3cFiyWX.net
Python登場当時だと{}前後のどこで改行するか論争みたいなのがあったりして確かに括弧書くのが面倒な空気はあったんだよな
それがGo/Rustの世代だと言語標準のフォーマッタが勝手にやってくれるってなって
めんどくさくないっていうオフサイドのメリットはなくなってしまった
そうすると自動フォーマットしづらいとかコピペしづらいとかデメリットばかり目立つことになってしまう
378:デフォルトの名無しさん
23/12/12 04:50:08.02 X9wYEqIf.net
ブロック毎に'{}'や行末に';'があるとソースコードが少し汚く見えるし
無いとすっきりして読みやすいと思うけどね。
379:デフォルトの名無しさん
23/12/12 05:58:22.17 6YpoyKxr.net
そんなの単なる慣れ
380:デフォルトの名無しさん
23/12/12 08:04:30.17 BxX9TTWN.net
まぁ人によるんじゃない
自分は{}がある方がブロックの識別性が良くて読みやすい
オフサイドは特にネストしたブロックの戻りが何段戻ったか見づらいんだよな
381:デフォルトの名無しさん
23/12/12 08:08:33.42 BYtUbVYs.net
カッコありなら、lisp系が好き。
悩む事が減る。
382:デフォルトの名無しさん
23/12/12 13:00:45.46 GxOznL1S.net
>>378
セミコロンはオフサイドルールじゃなくてもRuby/Go/Kotlin/Swiftのように無しできるから関係ないよね
それにセミコロンをタイプするのは面倒だとは思うが慣れると読む時のノイズにはならない
自然言語の文章で句点やピリオド+改行がノイズにならないのと同じこと
383:デフォルトの名無しさん
23/12/12 19:48:14.86 X9wYEqIf.net
CやC++を10年以上使っていたけど';'や'{}'が無いほうがすっくりして読みやすいと思うから慣れでどうにかなるものでは無いと思う。
こういうのは個人差があるのかもしれないが
384:デフォルトの名無しさん
23/12/12 19:54:02.65 X9wYEqIf.net
URLﾘﾝｸ(github.com)
このVimのプラグインを使うと同じインデント間のカーソル移動、異なるインデント間のカーソル移動が簡単にできるからお勧めです。
385:デフォルトの名無しさん
23/12/12 22:53:30.64 wCEkJKJx.net
>>383
CやC++やっててそんなこと言うやつ初めて聞いたぞ
本当に日々コード書いてる？
386:デフォルトの名無しさん
23/12/12 23:44:06.92 CyOM3fCk.net
そりゃ仕事で使える言語でオフサイドルールなのってPythonくらいだし
ほんとはオフサイドがいいけどC/C++の仕事してるって人くらいいるでしょ
387:デフォルトの名無しさん
23/12/13 00:18:56.36 YitMt0Fm.net
>>386
{}や;がノイズになるかどうかと
オフサイドがいいかどうかの話は別だよ
388:デフォルトの名無しさん
23/12/13 04:42:50.35 /pcasGi0.net
>>385
今はC/C++殆ど書いてないけど以前はほぼ毎日使ってたよ。
{}や;に慣れてもやっぱり余計な文字が少ない方がすっきりして読みやすいと思うのだが、そういう人は少数派なんかな?
389:デフォルトの名無しさん
23/12/13 05:36:33.39 R3z2LBuJ.net
主観で読みやすいかどうか力説しても結論でるわけない
オフサイドは誤ってインデントずれても気付かないままになってしまうのが問題
390:デフォルトの名無しさん
23/12/13 06:48:31.89 RhfHz66O.net
>>388
まぁ実際オフサイド採用の新規言語ってあまり出てこないし
少数派なんじゃないかな
391:デフォルトの名無しさん
23/12/13 07:21:31.19 vQeZuGNk.net
f#みたいに、使う側が選択できれば、解決なんじゃない？
392:デフォルトの名無しさん
23/12/13 07:35:42.19 q/L8o2wk.net
やれやれお前らCOBOLを知らんのか
393:デフォルトの名無しさん
23/12/13 11:38:44.64 rzHxkjlX.net
>>388
どちらの方がすっきりして読みやすいかと
{}や;が思考ノイズになるかどうかは別だよ
前者はそれなりにいる
後者はツチノコレベルで稀有
394:デフォルトの名無しさん
23/12/14 19:26:43.32 xAMEKx/6.net
エディタの色設定で{};を薄い色にすればいいだけやん
395:デフォルトの名無しさん
23/12/15 03:05:56.17 /ClHmJDY.net
{}がノイズになるようなら:や=はもちろんのことblock:なんて発狂ものだろうからNimは無理やろな
396:デフォルトの名無しさん
23/12/15 05:55:25.21 12rLPAnL.net
思考ノイズって
エロい事連想してるって意味だよな？
397:デフォルトの名無しさん
23/12/15 06:50:06.26 4QMbv0z8.net
Nimってオフサイドルール以外の所は目立った欠点の無い言語なんかな。
それに実際にオフサイドルールでコードを書いていて困ったことないし。
インデントがずれても困るという人はインデントの幅をスペース4個とか広めにすればいいのでは
398:デフォルトの名無しさん
23/12/15 17:55:10.13 BxRUp1+8.net
オフサイドルールは欠点だらけ
Pythonを例にすると
- カットペーストは命がけ
- ネット等で共有しにくい
- テキストエディタやIDEの支援が激弱
- dedentは手動タイピング必須
- 改行のために追加の()や\が結局必要
- インデントだけでは可読性が低いから余計な:が必要
- 空行の数まで厳密に意識する必要もある
- lambdaのone expression縛りのように言語の成長を阻害しやすい
- “explicit is better than implicit”と言いながらブロックはimplicit
399:デフォルトの名無しさん
23/12/15 18:18:19.69 b3hxnew5.net
次は、良い点を挙げてみて！
400:デフォルトの名無しさん
23/12/15 18:24:50.43 pkr2dCwK.net
>>399
プログラミング初心者を釣れる
以上
401:デフォルトの名無しさん
23/12/15 20:46:34.27 4QMbv0z8.net
Vim使ってるけどコピペは問題無くできるしインデントの深さもブロックごと'>'で調整できる。
vim-indentwiseでブロック毎カーソル移動可能。
スペース一個分だけでインデントするとかしない限りブロックの開始、終わりは前後の行のインデントの位置の違いでわかる。
vim-indentwiseでカーソル移動すればブロックの範囲も簡単にわかる。
以前はC/C++を書いてたけど{}や;が無くて読みづらいとか書きづらいとか思ったことは無いよ。
Nim書いていて改行のために追加の()や\が必要になることはほぼ無い
空行の数を厳密に意識する必要もない。
Nimを実際に書いたことあるの?
402:デフォルトの名無しさん
23/12/15 21:02:40.08 4QMbv0z8.net
URLﾘﾝｸ(wandbox.org)
NimのAnonymous proceduresでは複数行書けるし
こうしてコードを共有できてる。
403:デフォルトの名無しさん
23/12/15 22:17:03.24 kBMLRaUx.net
>>402
でもアロー関数にすると()を追加するなどしないと1行しか書けなくなる
これもオフサイドルールのせい
しかもこんな明らかなバグでも修正しようともしない
言語の成長を阻害するとはこういうこと
404:デフォルトの名無しさん
23/12/15 22:29:33.41 kBMLRaUx.net
>>401
論点理解せずにvim使いなら誰でも知ってる基本を必死に解説されても困るわ
>以前はC/C++を書いてたけど{}や;が無くて読みづらいとか書きづらいとか思ったことは無いよ。
{}や;が無くて読みづらいとか書きづらいとか誰もそんなこと言ってないだろ？
勝手に脳内変換するなや
ついでに言うとセミコロン無い方が書きやすいのは当たり前のこと
だから新しい言語の多くがセミコロンレスを採用してる(オフサイドは採用しないけど)
405:デフォルトの名無しさん
23/12/15 23:45:28.85 4QMbv0z8.net
>>403
アロー関数ってNimのsugarモジュールにある`=>`マクロのこと?
あくまでこの=>は二項演算子だから両辺は式になっていないといけない。
オフサイドルールに関係無く二項演算子の両辺に文を直接書けず式を置かないといけないのは殆どのプログラミング言語で同じじゃない?
複数文を書きたければanonymous procedureで書けばよいし。
オフサイドルールじゃない言語で無名関数に複数文を書くときは必ず{}で囲む必要があるし。
どうしてこれが言語の成長を阻害していることになるの?
明らかなバグなのに修正しようとしないって言うけどGithubのNimのリポジトリにそういうissueある?
無名関数を書くときはdo notationというのもあるよ。
URLﾘﾝｸ(nim-lang.org)
406:デフォルトの名無しさん
23/12/16 08:47:38.44 yzC0WAGQ.net
「vimを使えばいい」とか「無名関数を使えばいい」などと列挙されても
他の言語はそんな特別なケアなしに使えるわけでな…
このあたりがいまいち広まらない原因なんじゃない？
407:デフォルトの名無しさん
23/12/16 08:53:10.18 mPzLcjX0.net
以前インデントの代わりに{}を使える機能があったようだ。
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(forum.nim-lang.org)
けれども殆ど使われなかったのと、{}があるとgrammarとparserが発展するのが難しくなるので削除されたらしい。
URLﾘﾝｸ(forum.nim-lang.org)
408:デフォルトの名無しさん
23/12/16 09:38:42.94 mPzLcjX0.net
>>406
現代では高機能なテキストエディタやIDEが使えるから
それを使うことを前提にプログラミング言語をデザインしたらいいんじゃね?
って話は聞いたことがある。
sugarの`=>`マクロはNim言語のanonymous procedureを特定の条件下で簡単に書けるよう作られたもので完全にanonymous procedureを置き換えられるものでない。
sugarモジュール自体がシンタックスシュガーのようなものを提供するマクロなどを集めたものだし。
制限とか気にせずにanonymous procedureを書きたかったら=>を使わずに書くしかない。
409:デフォルトの名無しさん
23/12/16 09:56:43.39 yzC0WAGQ.net
>>408
そのへんがまさに省略記法の悪い点が出てる感じするな
省略するってことはソースコードの情報量は減っていて、それはタダではない
「OOのときにはXXを使う」みたいな規則がたくさん発生するというコストがあるんだよね
これはセミコロンレスもそうで、時々変なエッジケースが発生したりする
410:デフォルトの名無しさん
23/12/16 16:45:38.17 kvk3r8Lt.net
オフサイドルールと違ってセミコロンレス(optional semicolon)は多くの言語で妥当なトレードオフ
オフサイドルールが妥当なトレードオフとして成立してるのはHaskell系の言語くらい
411:デフォルトの名無しさん
23/12/16 20:00:00.36 USjLXMUH.net
なんかどうでもいいことをいつまでも
うじうじと
気に入らないなら使わなきゃいいだけ
気に入ったら使えばいいだけ
412:デフォルトの名無しさん
23/12/17 07:10:31.29 clYlz397.net
>>411
気に入っていても：
ある日突然：
気に入らなくなる事ってあるよね？
気に入らなくても：
ちょっとしたきっかけで：
すごく気に入ってしまうことも
あるよね？
そういう時はどうすればいいの？
413:デフォルトの名無しさん
23/12/17 12:19:34.98 WUPd6f5k.net
>>412
> すごく気に入ってしまうことも
> あるよね？
Error: invalid indentation
414:デフォルトの名無しさん
23/12/17 18:41:59.56 F9NekDqG.net
Nimはよく考えずに機能追加して既にC++並みに複雑化してる
目新しさだけで飛びつくと後悔するぞ
415:デフォルトの名無しさん
23/12/18 02:13:02.65 DdCrjTir.net
そうなの？ じゃあもうC++でいいじゃん
416:デフォルトの名無しさん
23/12/18 08:55:26.31 DG+uqCiP.net
例えば最近実装している変更についてもちゃんとここに理由とか書いてあるよ。
URLﾘﾝｸ(github.com)
このあたりをよく読めばちゃんと考えて機能を実装していることがわかるよ。
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
Discord/Nimのinternalチャンネルをときどき読んでるけど
開発者は論文読んだり他のプログラミング言語の機能を調査しているようだよ。
URLﾘﾝｸ(en.cppreference.com)
と
URLﾘﾝｸ(nim-lang.org)
を読み比べてみればわかると思うけどC++のほうがはるかに複雑だよ。
417:デフォルトの名無しさん
23/12/18 20:40:29.88 DG+uqCiP.net
Nim言語がどのような考えで設計されたか知りたい人はNimのblogを読むといいよ。
URLﾘﾝｸ(nim-lang.org)
URLﾘﾝｸ(nim-lang.org)
418:デフォルトの名無しさん
23/12/18 20:49:37.54 CbnA3O4k.net
Nimの現状を知りたい人はこれを読むといい
URLﾘﾝｸ(forum.nim-lang.org)
419:デフォルトの名無しさん
23/12/19 00:16:35.74 mrSFrPG8.net
議論をよく読めば何やらちゃんと考えて実装しているらしいのはC++も同じなんだよなあ
420:デフォルトの名無しさん
23/12/19 08:00:58.06 w9OEXcqM.net
>>419
単純に >>414 への反論なだけじゃない？
421:デフォルトの名無しさん
23/12/20 12:37:14.01 Cvw2c2UZ.net
バグ修正版のNim 2.0.2と1.6.18がリリースされました。
URLﾘﾝｸ(nim-lang.org)
422:デフォルトの名無しさん
23/12/23 09:16:16.92 VfEmk1mn.net
寂しいスポンサーページだな😢
URLﾘﾝｸ(nim-lang.org)
こりゃnimが普及しないのも当然か
rustとは大違い
URLﾘﾝｸ(foundation.rust-lang.org)
423:デフォルトの名無しさん
23/12/23 10:35:51.40 M8dtHAyN.net
でもRustは誰も使ってないじゃん
424:デフォルトの名無しさん
23/12/23 11:58:51.47 BXldyzev.net
Rust言語はトヨタ自動車が採用してると
どこかで読んだ
425:デフォルトの名無しさん
23/12/23 13:41:38.19 fLdoaHTJ.net
>>423
誰も使ってないは草
426:デフォルトの名無しさん
23/12/23 13:46:35.58 6J3b/0Sr.net
Nimと書き間違えたんだと思うが
427:デフォルトの名無しさん
23/12/23 18:13:17.30 A6gu1Hml.net
Nimを使っている組織のリスト
URLﾘﾝｸ(github.com)
428:デフォルトの名無しさん
23/12/27 19:41:58.29 g/RhhP+m.net
プログラムをビルドするためにC++だったらCMake、Rustだったらcargo.tomlにTOMLを使う。
Nimだったらconfig.nimsも.nimbleファイルもNim言語で書ける。
一つの言語でコンパイル言語としてもスクリプト言語としても使えて便利。
Nimはマクロやconstなどをコンパイル時に実行するためにVM使ってるんだけど、そのVMを使ってNimをスクリプト言語のように実行できるらしい。
429:デフォルトの名無しさん
23/12/27 19:50:00.04 J2C6aYvl.net
rustも複雑なことをしようと思ったらbuild.rsに書けるけど、それはそうとして依存関係をプログラム言語で書きたいかと言われると
430:デフォルトの名無しさん
23/12/27 20:16:43.40 E4kPlntL.net
あれもこれもできて便利！みたいなのはぱっと見良さそうでも
大規模・多人数・長期開発になると負債になりがちではある
431:デフォルトの名無しさん
23/12/27 20:24:29.72 qErwbOrg.net
happyxが起爆剤にならないかなぁ、、🙏
432:デフォルトの名無しさん
23/12/27 23:05:07.37 LUGQIuRd.net
zigなら全部zigで書ける（便乗）
433:デフォルトの名無しさん
23/12/27 23:27:30.38 7WiLoZ1Z.net
一体なにがエレガントなんだろうなこの言語って
434:デフォルトの名無しさん
23/12/27 23:34:47.36 qmMlPacq.net
まあアイコンはエレガントなんじゃない？王冠だし
435:デフォルトの名無しさん
23/12/27 23:51:57.04 Ra91RrOg.net
procとmethodとfuncを使い分けつつ{.global.}や{.async.}なとの{.pragma.}とmacroでぐちゃぐちゃにかき混ぜられるのが超エレガントw
他の言語では類を見ない
436:デフォルトの名無しさん
23/12/28 22:46:05.11 u+MANgUc.net
エレガントすぎてついていけないわ
437:デフォルトの名無しさん
23/12/28 23:18:44.60 u+MANgUc.net
エレガントすぎてついていけないわ
438:デフォルトの名無しさん
24/02/20 19:40:26.76 iQdtjO/s.net
新年の記念 保守
439:デフォルトの名無しさん
24/06/17 22:36:28.67 y0rZbngO.net
URLﾘﾝｸ(nim-lang.org)
Nim version 2.0.6がリリースされました。
440:デフォルトの名無しさん
24/10/04 21:03:40.29 jm0g8/rX.net
URLﾘﾝｸ(github.com)
から派生させた、Atkin Sieveベンチマーク
計算本体だけの計測に改め、更に桁を増やし、途中計算がオーバーフローしないように関係変数はすべて64bit
UPPER_BOUND: 500_000_000
Zig 1912ms
g++ 1916ms
Nim 1920ms gcc
Nim 1969ms clang
clang++ 2151ms
Rust 2411ms overflow-checks = false
Rust 2430ms overflow-checks = true
Zigが速かったので他は色々と変更した
Zigの変更は最小限なので再現検証をする場合は各自のZig計測値を基準にしてください
441:デフォルトの名無しさん
24/10/04 21:11:00.73 jm0g8/rX.net
特にデータ構造で
Nim seq[bool]
Rust Vec<bool>
は遅いので直ぐに取り換えてください
C++のvector<bool>は最適化がされていますが、最終的に別のものにしました
442:デフォルトの名無しさん
24/10/04 21:12:20.19 jm0g8/rX.net
>>440は取り換えた後の計測値です