次世代言語26 TypeScript Swift Go Kotlin Nim

**デフォルトの名無しさん** · 2022/06/21(火) 09:27:46.30

スレタイ（順番はRedMonk準拠）以外の言語もok

※　Rustは現世代最強言語なので除外します

前スレ

次世代言語25 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1650185555/

**デフォルトの名無しさん** · 2022/07/25(月) 16:01:59.92

>>414
これはいい質問

>>416
これはダメな回答

詳しく知りたい人はRustスレでどうぞ

**デフォルトの名無しさん** · 2022/07/25(月) 16:04:20.43

>>446
>特に酷いのは「所有権の複製」
>Rustにそんな概念も用法も無い
複製おじさんのオマエが言うなよwww

**デフォルトの名無しさん** · 2022/07/25(月) 16:06:38.58

>>432
例えばC言語でグラフを実装する時も生のポインタのみで実装されることはありません
なぜなら各ノードのメモリを解放するタイミングがわからなくなるためです
そこで主に三つの方法が取られます

一つは各ノード一覧を配列などで持っておくとともに定期的にルートから到達可能か到達フラグを用意します
そしてノード一覧の中で到達フラグが立っていないものをメモリ解放します
この方法の欠点は4つあり
(1) ノード一覧を管理する配列が別途必要となる
(2) 到達フラグが必要となる
(3) 定期的に到達可能かを調べる必要がある
(4) 使われなくなったノードがすぐには解放されない

もう一つの方法は定期的コピー方式です
ルートから到達可能な部分を定期的に別の場所にコピーします
コピーされなかった部分が到達できない使われていない部分なのでまとめて解放となります
この方法の欠点は
(1) この方法も定期的な実行が必要となる
(2) メモリ空間が2倍必要となる
(3) 使われてる全体が定期的にメモリコピーされる負荷
(4) 使われなくなったノードがすぐには解放されない

残りの方法は参照カウンタ方式です
おなじみなので略します

いずれの方法も様々な欠点があります
このグラフのノード解放問題は
ガベージコレクションを必要とするプログラミング言語にそのまま当てはまります
GCの負荷コストを理解していただけましたでしょうか？

**デフォルトの名無しさん** · 2022/07/25(月) 16:46:22.65

>>446
このように顔真っ赤になって、怒り心頭で攻撃してきます、激おこぷんぷん...マジでRustコミュニティはこういう輩の扱い考えたほうが良い....

>特に酷いのは「所有権の複製」
頭から「君はRustを叩きたい側だからだろう」という下種な勘ぐりを持って色眼鏡で相手と話し合う事はできませんし、これ以上
狂者を相手をするつもりもありませんが、デタラメ/間違いなら、より正しい言葉で説明したら良いじゃない？
なぜ1番先に書いたことを無説明で流し、Rc/Arcなんかの長文説明でグチグチ言ってるんです？
下のコメで「メモリーを限界まで使用してアクセスが高負荷な環境では確かに良い」と認めているのがあなたの目には見えませんか？

>Rcが滅多に使われないというのは事実
RcはStringにさえ使われています。あなたから薄ら頭に付いてる目から見える「事実」は隠されたライブラリの中に存在しているようですが
そこでもArcの話なんてしていません。Rcのスレッドセーフ版がArcなだけで、グダクダと口臭いArcの説明なんて誰も求めていません。

さらに参照カウントの一般的な欠点を説明しているのに、「批判するのがおかしい」と「誤差」なんてそれだから一般的なプログラマーから
ドン引きされるんですよ。

**デフォルトの名無しさん** · 2022/07/25(月) 16:51:48.53

>>450
> RcはStringにさえ使われています。

これマジ！？

**デフォルトの名無しさん** · 2022/07/25(月) 17:01:49.95

>>451
https://doc.rust-lang.org/src/alloc/string.rs.html
pub struct String {
　vec: Vec<u8>,
}
これだと言葉足らずですが、リテラルから生成するString::fromなどはこのようになります

**デフォルトの名無しさん** · 2022/07/25(月) 17:05:57.06

>>450
> RcはStringにさえ使われています。

嘘つき！
RcはStringで当然使われていないだけだなく
Rust標準ライブラリの中でも(Rc自体の
部分を除き)Rcは全く使われていない

一般的にもRcは使われることが少ない
もちろんRcを使うべき例外も一部あるがRcを使う前に構造の見直しを勧める

**デフォルトの名無しさん** · 2022/07/25(月) 17:28:44.47

標準ライブラリでRcが使われてないのは
オーバーヘッドを嫌ってunsafeを使った代替実装が使われてるからだぞ

**デフォルトの名無しさん** · 2022/07/25(月) 17:32:52.00

>>430
RustよりGoのほうが速いやんけｗｗｗｗ
Goしゅごいｗｗｗ

**デフォルトの名無しさん** · 2022/07/25(月) 17:35:20.01

人を嘘つき呼ばわりするキチガイを使う前に見直しを勧める
Rustは一人でやる分には良いけど、こういう奴とは絶対組みたくない、stdしか見えないアホ、ドアホォ
std::collectionsにないコレクションを使いたければ自分で実装するかgithubなどで拾ってくる必要があるのに、お前の顔見直せよ

**デフォルトの名無しさん** · 2022/07/25(月) 17:57:22.48

>>452
そのStringにもVecにもRcは使われていないね

>>454
Rust標準ライブラリでRcが使われていないのは所有者が複数存在するという特殊な状況が発生しないため

>>456
外部ライブラリにはRcを使っているものも存在するけどその少なさに驚くと思うよ
これはシングルスレッドで所有者が複数存在するという特殊な状況が滅多に発生しないため

**デフォルトの名無しさん** · 2022/07/25(月) 18:18:18.06

>>454
ライブラリ内部の実装に依存するなよ
抽象に依存しよう

**デフォルトの名無しさん** · 2022/07/25(月) 18:57:52.01

Python代替を狙いたいなら、脳死スニペットコピペで、
Excelファイルが編集できて便利ね。くらいを目指さないと無理じね？

**デフォルトの名無しさん** · 2022/07/25(月) 19:33:13.71

自分で使わないならダメじゃん？
Rc。

**デフォルトの名無しさん** · 2022/07/25(月) 19:37:10.91

だいたい、Haskell全然流行っていないじゃんか。
世界のすべてがHaskellに代わるんじゃなかったのかよ？
Rustが流行るとか言われてももう信じられんわ。
D言語だって全然流行らなかったし。

**デフォルトの名無しさん** · 2022/07/25(月) 19:48:55.75

結局一番使える凄いやつはExcel VBAだと思うね。
一番役に立つじゃん。

**デフォルトの名無しさん** · 2022/07/25(月) 19:54:28.52

>>460
RcをRust標準ライブラリや多くの外部ライブラリが使っていない理由は、Rcがダメだからではなく、
Rcが対象とするシングルスレッド環境においては、所有者が複数となることがない、もしくは、避けられることが多いため。
使わなくてよい時は使わず、どうしてもRcを使う必要がある時のみ使う、という当たり前の行動の結果。

**デフォルトの名無しさん** · 2022/07/25(月) 19:55:45.54

言い訳は要らないんだよ。

**デフォルトの名無しさん** · 2022/07/25(月) 19:56:57.83

RustよりGoのほうが速いじゃん。

**デフォルトの名無しさん** · 2022/07/25(月) 20:00:32.25

こんな遅いんだったらRustなんか使うんじゃなかったってみんな言ってるわ。

**デフォルトの名無しさん** · 2022/07/25(月) 20:06:54.34

>>466
RustはC++よりも速い結果が出ることも多い中で何を言ってるんだ？？

**デフォルトの名無しさん** · 2022/07/25(月) 20:08:53.16

>>449
延々と変なことを書いてるなとしか

**デフォルトの名無しさん** · 2022/07/25(月) 20:16:00.56

RustはHaskellの後継言語では？
口だけ番長みたいな。

**デフォルトの名無しさん** · 2022/07/25(月) 20:18:22.01

速い遅いは1bit的な100パーセントの保証ができないからね
逆に、変数の型を全く書かない、ゼロを保証するPythonのようなものは誠実な印象になる

**デフォルトの名無しさん** · 2022/07/25(月) 20:29:29.58

>>455
それ測定方法がおかしい
解いていないとはいえ、grepが一番速くて、次にwcが速くて、それらはC言語で書いたものより速くなっている
解いているシェルスクリプトですら1.83秒しかかかっておらず、Rubyの最適化版に至ってはシェルスクリプトより遅い結果となっている
最適化版のコードも一人が提供しただけであり、これでは意味がなかろう
その程度の課題でプログラミング言語間の時間比較に意味あるのか？

**デフォルトの名無しさん** · 2022/07/25(月) 20:30:15.46

よく分からんけれど、CPythonに代わる速くて安全で効率の良いRustPythonを作るのが良いのではないだろうか？

**デフォルトの名無しさん** · 2022/07/25(月) 20:32:58.49

RustはPHPと変わらないじゃん。
PHP速いわー。

**デフォルトの名無しさん** · 2022/07/25(月) 20:34:05.94

Haskellおっそ。
なんなんこれ。
12.81だって。

**デフォルトの名無しさん** · 2022/07/25(月) 20:38:25.47

仮にも地球を代表するプログラマが遅い速いは時の運とか言っちゃだめだと思うわ。

**デフォルトの名無しさん** · 2022/07/25(月) 20:44:28.71

>>471
これが全てとは言わないけど参考にはなるでしょ

Rustはripgrepの作者が作ってるお墨付きなんだがGoより早くないのは事実

**デフォルトの名無しさん** · 2022/07/25(月) 20:47:52.05

こんだけ凝って、こんだけ遅いって、Rustの見事な性能の表れでしょ。
そりゃ誰も使いませんわ。
こんなの使ってたら宗教ですよ。
信徒ですよ。

**デフォルトの名無しさん** · 2022/07/25(月) 20:52:51.88

はい、エビデンス出ましたー。

**デフォルトの名無しさん** · 2022/07/25(月) 20:56:02.00

>>476
ちょっとコードを見てみたけど両者でやっていることが異なるね
例えばGoのコードと異なりRustのコードはバッファ内をcopy_withinでコピーしていたりするなどGoにはないコードがあるような

**デフォルトの名無しさん** · 2022/07/25(月) 20:59:34.44

また言い訳が始まった。

**デフォルトの名無しさん** · 2022/07/25(月) 21:05:06.38

まだコードをよく見ていないが、
他のベンチマークではGoがいつも負けていて、
今回だけGoが勝っているのだから、
何か裏があると推測できる。

**デフォルトの名無しさん** · 2022/07/25(月) 21:07:28.31

トイプログラムやベンチマークではRustのほうが速いけど、こういう実用的なプログラムではGoのほうが速いってことじゃないの？

**デフォルトの名無しさん** · 2022/07/25(月) 21:08:19.44

もしデータが間違っているなら理屈と直感で判断すればいい

全ての情報源が正直者でなければ何もできないことを性善説という

**デフォルトの名無しさん** · 2022/07/25(月) 21:09:45.71

4Kb未満のデータはRustのほうが速いけど、
それ以上のデータでは、Goのほうが速いのでは？

**デフォルトの名無しさん** · 2022/07/25(月) 21:11:43.19

わし、単体テストにベンチマークも入れてるよ？

**デフォルトの名無しさん** · 2022/07/25(月) 21:19:04.59

キャッシュを上手に使えるGoと、全く考慮しないRustの違いが出てるのでは？

**デフォルトの名無しさん** · 2022/07/25(月) 21:19:28.30

>>430
まずCのコードを読んだが特にトリッキーなことをしていないので
そのままRustに書き換えればいつものC→RustのようにRustでほぼCと同じ速さが出るだろうな
一方でそこに書かれているRustのコードはCの2倍近く遅くて普通にありえない結果となってるな

**デフォルトの名無しさん** · 2022/07/25(月) 21:21:31.99

また言い訳かよ。
負けたんだよ、Rustは。

**デフォルトの名無しさん** · 2022/07/25(月) 21:23:25.12

じゃあ、Rustにprogress_displayはあるのかよ？

**デフォルトの名無しさん** · 2022/07/25(月) 21:26:07.93

progress_display無かったら要らんわ。
しかも遅いし。

**デフォルトの名無しさん** · 2022/07/25(月) 21:58:27.37

>>430
なんでこのおじさんHashMapとか使ってるの？
遅いので有名だぞ

**デフォルトの名無しさん** · 2022/07/25(月) 22:00:37.54

>>430のベンチマークの方法とか見てたんだが
1. 時間はpythonのsubprocess.runで独立した試行を5回行っている。
2. 5回のうち最速のものを記録にしている。

だから、Javaみたいに起動時に重い言語は不利なのと、同じくらいの速度だと計算機の機嫌で順位が入れ替わりそう。

**デフォルトの名無しさん** · 2022/07/25(月) 22:03:54.64

Rustは糞遅いから入れ替わらない。

**デフォルトの名無しさん** · 2022/07/25(月) 22:06:10.72

Juliaって愛される言語5位とかに入っていたけど、あんまり流行る気配ないよね
PythonからJulia主体にならんか

**デフォルトの名無しさん** · 2022/07/25(月) 22:06:51.57

あとRustのCっぽいバージョンは何に対してas fastなんだろう

**デフォルトの名無しさん** · 2022/07/25(月) 22:08:02.42

ちょっと検索してみたんだがGoは並行処理が得意らしいぞ。
俺の12900HX16コア24スレッドが有効に使えるのでは？
もしかして。

**デフォルトの名無しさん** · 2022/07/25(月) 22:08:47.70

Cっぽくないバージョンに対してだろね。

**デフォルトの名無しさん** · 2022/07/25(月) 22:19:58.19

HashMapを高速なハッシュに変えたらRustの勝ち
解散

**デフォルトの名無しさん** · 2022/07/25(月) 22:31:12.16

>>498
Simpleは標準ライブラリ以外使わない縛りをしてて遅いHashMap使ってる。
Optimizeではfxhash使ってるのでまだ解散しないで。

**デフォルトの名無しさん** · 2022/07/25(月) 22:51:30.63

俺の環境だとRustの方が少しだけ速かったな
バージョンアップで多少改善されたのかも。誤差程度だけど

**デフォルトの名無しさん** · 2022/07/25(月) 22:53:16.38

>>499
(衝突攻撃安全性に優れるが遅い)Rust標準ライブラリのHashMapよりも
今回は(Rustコンパイラ等でも使われている)速いfxhashを使った方が良いとのアドバイスがあっただけで
実際に使っているコードはHashMapのままになってるような

**デフォルトの名無しさん** · 2022/07/25(月) 23:18:27.95

>>501
optimizedのmain.rsは

use fxhash::{FxHashMap as HashMap};

となってるんだけど
これはfxhashを使って高速化してるわけではない？
それともベンチマークに反映してないのか？

**デフォルトの名無しさん** · 2022/07/26(火) 00:27:41.06

>>472
つ Nim

**デフォルトの名無しさん** · 2022/07/26(火) 00:30:04.25

>>476
そうだね何でもgrep使えば一番早いと思うよ(棒
あ、wcの併用も可だと思う

**デフォルトの名無しさん** · 2022/07/26(火) 00:33:32.10

Rustがこんなに遅いとは知らんかった。

**デフォルトの名無しさん** · 2022/07/26(火) 01:36:48.26

いつものやつ貼っておくか
https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html
ChapelとJuliaすごいじゃん

**デフォルトの名無しさん** · 2022/07/26(火) 05:00:13.51

ワードカウントの結果だけで性能評価してしまうプログラマがいるんですか！？

**デフォルトの名無しさん** · 2022/07/26(火) 08:14:27.14

>>503
少し試したことあるけれど、別物だったよ。
イメージとしては、PyPyあたり。

**デフォルトの名無しさん** · 2022/07/26(火) 08:27:06.16

Rustのコードがおかしいと言うなら、改善したコード出せばいいんじゃない？
ワードカウントじゃ言語の性能はわからないとか言うんだったら、Rust有利なベンチマーク作ればいいんじゃない？

Rust簡単とか言っているやつなら余裕だろ。

**デフォルトの名無しさん** · 2022/07/26(火) 08:44:40.79

批判されていることは「性能が悪い」というより「コストの割には性能が微妙」というニュアンスなので
コードを一行も書かないことがコスト最小なんだよ
コストの話をするとコードを書く奴がいなくなる

**デフォルトの名無しさん** · 2022/07/26(火) 10:02:50.90

高級機能があってランタイム最強！っていう厨二病的なモチベーションだからほっとけばいいんだよ。
そのうち気づくし、気づかなくても知ったこっちゃない。

**デフォルトの名無しさん** · 2022/07/26(火) 10:11:09.19

>>510
その意味で重要なのはRustの非最適化版がGoより遅く、Java、C#と大差ないという事実の方だな
RAIIは遅い

**デフォルトの名無しさん** · 2022/07/26(火) 10:29:35.69

Rust遅すぎじゃね？

https://res.cloudinary.com/practicaldev/image/fetch/s--n3XlUkmN--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cqj6u280qmdwq7fgnw5h.png

**デフォルトの名無しさん** · 2022/07/26(火) 10:43:17.89

RAIIだけの問題ならGoは使わない方がよさそう
C++だけで書いてexitとabortを比較とかすればいいのでは

**デフォルトの名無しさん** · 2022/07/26(火) 11:52:47.41

RAIIはメモリ解放タイミングが決定的なのがスッとするんよ
ガベコレの場合に開放を保留しておいて
プログラムの終了がすぐだから個別の開放はしないってときは
そりゃかえってガベコレ方式のほうがメモリ関係の全体コスト少なくてもおかしくない

**デフォルトの名無しさん** · 2022/07/26(火) 12:04:42.36

CPUバウンドでも対してGoと変わらないことがあるんだから
IOバウンドの用途でRustを使うメリットなんて皆無
メモリ効率ガーGCガーとかクソどうでもいい

OS開発とか組み込みとかなら重要なんだろうけど

**デフォルトの名無しさん** · 2022/07/26(火) 12:08:48.07

>>516
組み込みはC/C++の独壇場なのだから、ここにRustが入ればより良い製品が増えるだろ

**デフォルトの名無しさん** · 2022/07/26(火) 12:14:19.45

CPUバウンドだったとしても実装に使ったアルゴリズムで劣ってればそりゃRustやCでも余裕で負けるだろう

**デフォルトの名無しさん** · 2022/07/26(火) 12:18:31.42

そもそも非最適化版でベンチマーク比較する意味ねーだろ、デバッグ中や開発中でもねーのに。

**デフォルトの名無しさん** · 2022/07/26(火) 12:21:17.66

>>519
そういう意味の非最適化じゃねーから

**デフォルトの名無しさん** · 2022/07/26(火) 12:56:48.38

>>519
Rustの "Zero Overhead Abstruction" を活用した結果遅くなったということだ

**デフォルトの名無しさん** · 2022/07/26(火) 16:33:28.70

プロファイルとって分析した上で遅い原因について語ってるの？ただの憶測？

**デフォルトの名無しさん** · 2022/07/26(火) 16:41:00.17

昔あったc++よりc#の方が速いケースがあるみたいなどうでもいい内容に思えるけど

**デフォルトの名無しさん** · 2022/07/26(火) 16:51:02.98

>>523
dotnetの方がCPUに対して最適化された命令セットにできるってのはまああり得るっちゃあり得るよね

**デフォルトの名無しさん** · 2022/07/26(火) 16:57:23.19

命令セット？
C++のコンパイラがクソい命令セットを使うことがあり得る、って話？
そりゃ処理系によってはそうだろうけど

**デフォルトの名無しさん** · 2022/07/26(火) 17:06:31.29

NTTグループで7月から3万人が原則テレワークに、遠方からの飛行機出社もOK

NTTグループは、従業員の勤務形態を原則としてテレワークとする新制度を
2022年7月1日から導入する。まず持ち株会社のNTTやNTT東日本、NTT西日本、
NTTドコモ、NTTデータなどの主要会社から導入する。当初は約3万人を対象とする。
テレワークを原則とする部署は各社で決める。
まずは人事や総務といった間接部門や企画、システム開発などテレワークに
向く部署が対象となる見込みだ。新制度では、従業員の居住地の制限もなくす。
従来は「通勤時間が2時間程度」という制限があったが、国内のどこにでも
居住して勤務できるようになる。出社が必要な場合は、出張扱いとして航空機を
利用した出社も認める。日付をまたぐ場合は、宿泊費も会社が負担する。

**デフォルトの名無しさん** · 2022/07/26(火) 18:18:56.01

>>525
AMDとIntelの違いや世代でも違うし、同じ命令でも特性が違ったりするんじゃね？

**デフォルトの名無しさん** · 2022/07/26(火) 18:26:22.14

仮にそれが原因だったとして
その実験データって再現性とかあるんですか

**デフォルトの名無しさん** · 2022/07/26(火) 18:54:20.86

twiterでMSX3と言うのが流れてきた
このハードで勝負だ！とはならんなあｗ

**デフォルトの名無しさん** · 2022/07/26(火) 19:09:11.50

countwordsを試してみたけど
optimizedで速い順にC > Rust > Go > Nim
(比率 1 : 1.69 : 2.03 : 3.42)

simpleは Nim > Go > C > Rust
(比率 1 : 1.09 : 1.22 : 1.38)

simpleでRustが遅いのはUTF-8チェックとhash関数の遅さと考えれば納得できる範囲かな
ZigやC++はコンパイルエラーになったから除いた

**デフォルトの名無しさん** · 2022/07/26(火) 19:15:29.79

Nimは毎回インストールするけどwindowsが警告が出すんだよな

防疫して一部のファイル消したりしていじわるしてくる

**デフォルトの名無しさん** · 2022/07/26(火) 20:25:55.51

意地悪というよりイジメじゃん。
慰謝料、億とれるよ。

**デフォルトの名無しさん** · 2022/07/26(火) 20:39:29.27

RustはC/C++にダブルスコアで負けてるじゃん。

**デフォルトの名無しさん** · 2022/07/26(火) 20:45:27.29

イジメはイジメられるほうに原因がある
いじめられる側が悪い

**デフォルトの名無しさん** · 2022/07/26(火) 21:21:03.08

cは単語ごとに細切れで確保
item.key = strdup(word); // simple.c
char* word_copy = malloc(word_len); // optimized.c
するんじゃなくてこっちもwordコピー用の領域をおっきく取っておいて
そっちをちまちま端から使っていってみたいけど

**デフォルトの名無しさん** · 2022/07/26(火) 21:48:16.70

プログラミングでは原因と結果というより命令と実行という方がわかりやすい
命令する側が生殺与奪の権を握っている事実が

**デフォルトの名無しさん** · 2022/07/26(火) 22:00:26.74

とりあえずこんなもん
Language | Simple | Optimized | Notes
------------- | ------ | --------- | -----
`grep` | 0.15 | 0.15 | `grep` baseline; optimized sets `LC_ALL=C`
`wc -w` | 1.20 | 0.99 | `wc` baseline; optimized sets `LC_ALL=C`
C | 3.34 | 0.93 |
Go | 3.38 | 1.30 |
Rust | 3.69 | 1.40 | by Andrew Gallant
Rust-fixhm | 3.25 | | by Andrew Gallant
Rust-buf | | 1.31 | by Andrew Gallant
Rust-unsafe | | 1.18 | by Andrew Gallant
Rust-customhm | | 0.98 | by Andrew Gallant
Python | 12.15 | 5.27 |

Rustは懸念点が多いのでいくつかやった。
-fixhmがハッシュマップを速いものに切り替えたやつ、-bufが標準出力にバッファが噛んでなかったのを直したやつ、-unsafeと-customhmが同梱されてたより高速なやつ。
こうしてみるとRustは標準ライブラリが生っぽかったりセキュリティのために性能を犠牲にしたりとちぐはぐな感じがあるな。

**デフォルトの名無しさん** · 2022/07/26(火) 23:12:57.71

>>531
Nim言語はマルウェアを作る人達に使われているらしい。
アンチウィルスソフトは単純なパターンマッチングで動いているから、
悪いことしないNimのコードでもマルウェアだと誤検出されてしまうらしい。

**デフォルトの名無しさん** · 2022/07/27(水) 00:56:57.97

>>537
これgrepが一番速いけどagとかripgrepだとどうなるの？

**デフォルトの名無しさん** · 2022/07/27(水) 01:28:29.17

Cで書かれたgrepより、Goで書かれたptのほうが早いし高機能だよ

**デフォルトの名無しさん** · 2022/07/27(水) 01:34:47.64

まあぶっちゃけ他の言語でもgrepと同じように
trieみたいな文字列処理用のアルゴリズム使えば速度はだいぶ変わると思うけどね
なんで泥臭い処理を書いてるのか
そりゃgrepが1番早いだろと

**デフォルトの名無しさん** · 2022/07/27(水) 02:00:24.66

言語の速度を比較するというのならアルゴリズムは揃えるべき
でないと何が何やらわからない

**デフォルトの名無しさん** · 2022/07/27(水) 02:42:12.43

grepは`grep foobar`を実行してファイルをなめてるだけだぞ

**デフォルトの名無しさん** · 2022/07/27(水) 04:04:05.75

RustコンパイラはC++で書かれている。

**デフォルトの名無しさん** · 2022/07/27(水) 04:20:50.92

NimコンパイラはNimで書かれている。
けどgccだけからNimコンパイラをビルドできるようにするためにNimのコンパイラのソースコードをC言語に変換したもの(csources_v1)がある。

**デフォルトの名無しさん** · 2022/07/27(水) 06:50:28.42

>>543
だからgrepのアルゴリズムのことだよ