次世代言語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(月) 08:59:06.96

>>429
キチガイではなく一般論を話しているのみ。Nodeが流行った理由知らないのか

単語をカウントするプログラムのベンチマークをした記事

Goがシンプル版、最適化版両方Rustより速いようだけどRust玄人さんはこれどう解釈するの？
メモリ効率がいいから速いんじゃねーの？
https://benhoyt.com/writings/count-words/

Goがライターが書いていて、Rustはripgrepの作者が作ってるみたいだけどｗ

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

>>408
量産て全部同じやつだぞ
Rustスレでは誰も相手にしなくなった自演魔

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

>>421
グラフとかどうやって実装すんの？
配列とインデックス？

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

>>430
非最適化版はC++も遅いことを考えるとRAIIの性質として遅いんじゃないか？
細切れにメモリの解放が入るからな

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

>>418
普通にデータなどを格納するコレクションを作るときに直接使用する、例えばVecとか
上のほうで書いてある「Rcが滅多に使われない」は大変な間違い。
多くのプログラムは間接的にほぼ間違いなく多く使用している、もちろん全く使用しないプログラムもあるがそちらのほうが例外。
当然、参照カウントはセマンティックムーブのある言語で所有権の複製時にはカウントアップされる
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=39acf5e2c625c2e5ccd8f9cca466f64c
スキル学習で分かりにくいのは、この種の言語の一般的な用語である「（ただ単に）参照」とは所有権の複製ではないという事
対して「可変参照」をとる場合、mutableな借用とされ参照カウントが0/1以外にもカウントアップされる。よって参照カウントが
実行時にボトルネックになる可能性があるという話は正しく、無意味に「コストゼロ、コストを必要としない」などを連呼する事は
とても近寄りがたい雰囲気を醸し出す

普通は中身を見るだけではなく格納している値を処理するので、可変参照を使うので、参照カウントがコストが無いなんていう
ふざけた説明は論外。この種の宗教的な勧誘は「コストゼロ、コストを必要としない」などを連呼する狂信性を発病する

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

>>434
「所有権の複製」とか言っちゃうと
君もその狂信者こと複製おじさんと同じになっちゃうよw

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

>>428-429
基本的なことを全くわかってないでなんでも独自解釈で間違った判断してると思うわ

なんでも狂っていたりそう簡単にぶっ壊れたりするもんじゃないから、
自分の予測と違った結果になったら基本的な用語とか使いかたを勉強し直さないと先に進めないと思う

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

>>435
Rustはプログラマーへ負担を大変に強制する言語でありながら、問題解決している分野はとても狭い....
メモリーを限界まで使用してアクセスが高負荷な環境では確かに良いかもしれないが
Pythonなどの自動学習ライブラリ(多くはC/C++で書かれる)やNodeやTypescript/JSなどが主流であるフロントエンドには非常に使いづらい。
またスマートフォンのアプリ開発も出来なくは無いが両陣営からあまり重視されていない、最近では大企業も使用をしているが
Googleなどは多くはまだメニーコアを素直に活用できるGoを使用する（社内の標準言語）
ここまで否定的なことを、ハッキリ言える狂信者は居ないとおもう

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

C/C++は危険だよ問題という
狭い問題のために過大なコストを消費するのは
Rust以前の時代からあった非合理的行動なんだよな

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

新興勢力の宣伝の常套手段の一つ
既存の勢力を貶めること
個人的には好きではないしむしろ忌み嫌うやり方

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

>>430
Nimが良いな。

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

Nim++
Nim#

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

>>437
Rustはれっきとした機械学習のライブラリや言語処理系を*作るため*の言語だよ
Rustは機械語を吐くコンパイラやトランスパイラのようなものに向いてるし
それってフロントエンドが今必死になって取り組んでる分野ではないの？
簡単に書けて省メモリかつ速い言語なんてないよ
夢見すぎ

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

>>441
Nimが十分抽象表現できてるからNim++は意味ねーだろ

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

>>437
Pythonの自動学習ライブラリはフロントエンドではない
さらに多くがC++で書かれている自動学習ライブラリに対してRustが非常に使いづらいと主張するなら根拠を書くべき
C++が多いのは長年の時間の差だけであり現在はPythonからRustを呼び出すこともできるようになったので今後は色々と出て来るだろう

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

自動学習？

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

>>434
デタラメな説明はよろしくないな
君はRustを叩きたい側だからだろうが根本的な理解ができていない
特に酷いのは「所有権の複製」
Rustにそんな概念も用法も無い

Rcが滅多に使われないというのは事実
様々なRustのライブラリ(クレート)を見てもRcの出現は非常に少なくArcよりも圧倒的に少ない
Arcが多い理由はマルチスレッドでデータを共有するためで別々の所有者だから
Rcはシングルスレッド用だから別々の所有者を必要とすることが非常に少ない
まれにRcを必要とすることもあるが本当に必要なのかをまずは疑うべき

さらにRc/Arcでカウントアップ／ダウンは滅多に起きない事象であるため負荷を批判するのもおかしい
例えばマルチスレッド間のデータ共有でArcを使うとしてもスレッド生成で＋１されスレッド終了で－１されるのみだからスレッド生成に対して誤差である
このように新たな所有主体が現れること自体の負荷と比べて数値を＋１することは誤差

**デフォルトの名無しさん** · 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と言うのが流れてきた
このハードで勝負だ！とはならんなあｗ