次世代言語28 TypeScript Swift Go Kotlin Rust Nim

■ このスレッドは過去ログ倉庫に格納されています
2022/08/29(月) 11:22:16.48ID:5dAad4gs
スレタイ以外の言語もok

前スレ
次世代言語27 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1659655598/
2022/09/04(日) 02:03:59.28ID:1GJgU4m+
たぶん必要なのは
葡萄を食べるべきでない理由ではなく
食べない自由なんだな
2022/09/04(日) 08:04:17.58ID:IySRHUNr
>>200
プログラミング言語間の速度差が激しくて勝負にならないな
競プロで勝つためにはRustかC++を選ばざるを得ないのか
2022/09/04(日) 08:07:09.64ID:gz8Ny9ff
>>213
いいや
Pythonは論外だけど他の言語で十分戦える
2022/09/04(日) 08:19:18.55ID:ftO7cI3V
>>200
Rust最速レベルやん
てかC++の分布笑えるな
ギリ合格からトップクラスまでみっちり
216デフォルトの名無しさん
垢版 |
2022/09/04(日) 10:34:00.57ID:RQxkFcRF
本日のRustあげ会場はこちらですか？
2022/09/04(日) 11:16:04.09ID:ubNPliW5
貶めれば誹謗中傷かも知れんけど、ほめれば気持ち悪いだけ
こんなの消去法でほめるに決まってんだろ
218デフォルトの名無しさん
垢版 |
2022/09/04(日) 11:23:49.03ID:YUzYugU5
参加者自体はRustも多い。
C++と同じくらい居る。
時間内に提出できる人が少ないだけ。
2022/09/04(日) 11:27:19.04ID:eUUNIT4U
つまりRustは生産性が低いor利用者の能力が低いってこと？
2022/09/04(日) 11:52:32.99ID:r6qlMaZb
普通にガチ勢は昔からC++を使ってて今さら他の言語にしないというだけだろうな
221デフォルトの名無しさん
垢版 |
2022/09/04(日) 12:28:01.29ID:1n1CTU4P
CオジはCとC++比べてもやっぱCの方が早いからC++はダメとか言うのかな？
222デフォルトの名無しさん
垢版 |
2022/09/04(日) 12:29:11.61ID:RQxkFcRF
ダメな香具師が描いたダメなC++コードは本当に糞
Cのがマシ
2022/09/04(日) 12:57:20.84ID:r6qlMaZb
>>201
Pythonはよほどうまくチューニングしないとすぐ時間制限越えるんで競プロだと使い物にならないんですわ
>>200のグラフから実行時間でのランキングができそうだけどぶっちゃけ時間内に結果が出れば速かろうが遅かろうが大差無いのでPython以外なら何使ってもいい
言語よりプログラマーの能力が大事だし、それよりむしろ暇の方が大事
とにかく参加し続けてなるべく正解を出してれば上位に行ける
2022/09/04(日) 13:11:43.10ID:MfsHP/8v
pythonでアルゴリズム性能出ると思ってるのお前だけだよ。。
2022/09/04(日) 13:31:05.58ID:r6qlMaZb
お前がアルゴリズムという言葉を知らないと言うことがわかった
2022/09/04(日) 14:04:04.57ID:ubNPliW5
行列の和と積を英単語ではなく記号で書けるだけでC++と互角みたいになったのがPython

argv + 1000000 がnullを返したり計算中に例外を投げる実装が可能なだけでRustと互角になれる
227デフォルトの名無しさん
垢版 |
2022/09/04(日) 14:42:33.66ID:RQxkFcRF
何と戦ってるのか知らんがイミフな基準
2022/09/04(日) 14:46:33.79ID:Pinnb9nG
>>223
うーん、いろんな言語で競プロやってる青色だからついコメントしたくなってしまう

CPythonは知らんけど、pypyは実行速度速いからマラソンでもなければ困ることないよ
再帰がしんどいと言われる問題も、コドフォではよく使われてるbootstrapデコレータを使えば簡単に解決する
Rustはusizeの扱いのために余分なコードが必要になることが多かったし、クロージャ使おうとすると引数の型とかめんどいしで、最近は専らPythonを使ってる
Pythonはクロージャを短めに書けることも競プロ的には気が楽だな
229デフォルトの名無しさん
垢版 |
2022/09/04(日) 15:31:08.56ID:YUzYugU5
Rustは競プロに向いて居ないからな。
避けるのが賢明。
2022/09/04(日) 15:33:36.35ID:+XXjYupQ
複オジと
複オジにマジレスしちゃう人と
その両方を焚き付けて喜んでる人の三人でお送りしています
231デフォルトの名無しさん
垢版 |
2022/09/04(日) 16:44:07.43ID:nQgfFYZJ
Cが普通はintインデクスなのになんで、配列というかスライスをusizeにしたか何回も疑問に上がるよね....
まあインデックスループじゃなく、イテレート操作するからとか、std::ops::Index<T>でusizeだからとか
色々な回答があるけど、どうにもスッキリしない
usize以外の型（より小さい型やsigned)を使えるようにすることは将来ありうるかという開発者への質問も
ライブラリの互換性上ではすぐに実現できないみたいだし、ま、使う人の利便性・プログラマーへの負担軽減を
優先的に考えて作られた言語じゃないからだけど、let mutと書いてる時点でそうだが、せめてこれだけでも
1キーワードに出来なかったんだろうかな
それとCだとint a = 0, b = 1, c = 2;と宣言できるけど、let (mut a, mut b, mut c) = (0, 1, 2);
文末セミコロンで複数行に分けても、理解しやすいという話はどこに行った？使いやすさを求めては
イケないんだろうけど、どうもね....
2022/09/04(日) 16:46:11.53ID:/0DHyjSi
ミュータブルを極力使うなということだろ
233デフォルトの名無しさん
垢版 |
2022/09/04(日) 17:40:27.34ID:YUzYugU5
韓国で最も愛される言語と銘打てば流行るのでは？
2022/09/04(日) 17:47:06.26ID:rbLH55CO
>>231
わざと面倒臭くさせてることに意味がある
その辺りの思想は今までの言語とは違うかもしれん
235デフォルトの名無しさん
垢版 |
2022/09/04(日) 17:48:26.12ID:qbvnu5SJ
>>231
＞Cが普通はintインデクスなのに
そんなルール無いよね？
仕事で他社さん作ライブラリがuint使ってたことある。
2022/09/04(日) 18:06:41.17ID:mP7WKJy6
普通にprintln!使うと遅いんだけど教プロ上位なんだな
2022/09/04(日) 18:17:28.78ID:6TwASNhD
競プロではRustは間違いなく最速レベルだし、proconioみたいなマクロを使えば入出力もめちゃくちゃ扱いやすい
でもまあそれ以外のとこでかなり慣れがいる
2022/09/04(日) 18:21:48.03ID:oPTKOfK9
安心安全最速、Rust最高じゃん
2022/09/04(日) 19:10:58.79ID:brj4MXrP
>>231
インデックスやその長さはusize型で絶対に正しい
まずインデックスは負の数になってはいけないからunsigned型
サイズとしてはポインタなどと同じそのCPUで使われるサイズでなければならないからusizeとなる
そして実際のほとんどの様々なプログラミングにおいてインデックスはusize型で上手く動く

ところが例外が二つある
例外の一つは自分たちで決められない外部指定APIなど規定においてインデックスや長さがusize型でない場合でas usizeにより解決

例外のもう一つは一部の数値アルゴリズムでプログラミングする上で一時的もしくは最初あるいは終端で負の数になると便利なことがある
もちろんその一時的な負の数である時ははインデックスとして使われないようにプログラマーの責任でプログラミングしてインデックスとして使う時はas usize
2022/09/04(日) 19:29:23.15ID:OkswyjL5
浮動小数点数から符号無し整数へキャストする命令なくね？
最近の処理系は直接キャスト出来るようなったん？
2022/09/04(日) 19:44:58.67ID:brj4MXrP
>>231
その3-tupleはデータ型の一つでもありまとめて変数に格納できるし関数の引数や戻り値に3-tupleは使える
let foo = (1, 2, 3);

letはパターンマッチ文なので分解にも使う
let (a, mut b, c) = foo;
b += 100;
println!("{a} {b} {c}')
ここでbしかmutableを必要としていないのだから個別mut指定が自然
どの言語でも同様だがmutableをできる限り少なくするのがプログラミングのコツ
2022/09/04(日) 20:00:50.97ID:wyRxABNd
>>231
Cも配列のインデックス関連は(s)size_tが基本では
strlenやmemcpyの引数や返値はsize_tだし
単にintから暗黙的にキャストできるというだけで

暗黙の数値キャストがないのは確かにめんどくさい

asでのキャストはリリースビルドだと範囲外の値になったときにエラーにならないし、
絶対成功するキャストと失敗する可能性のあるキャストが見た目からぱっと区別がつかないのもよろしくない
かといってn.try_into().unwrap()を書くのもだるい

せめてn.into()で済ませたいが16bitアーキもサポート対象だからusizeに From<u32> が実装されていない

ターゲットを32bit以上のアーキテクチャに限定するした場合はinto()使えるようにするとか、もう少し楽にできないだろうか
2022/09/04(日) 22:29:03.84ID:rWQ8XHaT
>>242
Rustは基本としては正しい一貫した方針をとっていて
型変換が必ず成功するものはinto()つまりfrom()が定義されていて
型変換が成功しない可能性のあるものはtry_into()つまりtry_from()が定義されている
したがって基本的にはどちらかを用いればよい
新たな型に対しても同じ方針で実装していくしライブラリもそうなっている
usizeについても同様だが16bit環境もあるためbool, u8, u16からのみinto()となり一貫している
唯一の例外は浮動小数点で成功が定義されないためにinto()もtry_into()もない

上述のコンパイラが型変換を常に保証する方式に対して
プログラマーが型変換を保証する方式に利便性を兼ね備えたのがasによるキャスト
これは例えばu32を自動的に上位を切り捨ててu8に入れるといったことも含めた広義の型変換も含まれる
いずれのケースもキャストはプログラマーの責任で行なうという一貫した方針がある
わざわざ『as xxx』と記述させるのはそのためで意図的に目立つようにしている
プログラムをチェック、デバッグ、メンテする時にunsafeに準じてas xxxは注視すべきポイントとなる
2022/09/04(日) 23:03:51.17ID:rWQ8XHaT
>>243の基本を踏まえた上で
例えば16bit環境でなければu32からusizeへのtry_into()は常に成功し安全にunwrap()できる
生成コードも以下のようにコストゼロ
https://godbolt.org/z/cEc5fKGjh

キャストasと同様にunwrapも注視ポイントとなるため
利便性も含めてinlineのto_usize()を用意してしまうのがよいかもしれない
bit環境依存性はそのメソッドに押し込めることで注視ポイントが散らばるのを防げる
245デフォルトの名無しさん
垢版 |
2022/09/04(日) 23:05:01.26ID:ULs4IOBU
危険のある操作は面倒にするべきなんだよ。
246デフォルトの名無しさん
垢版 |
2022/09/04(日) 23:23:22.66ID:nQgfFYZJ
>>239
それ絶対に正しいとは言えてないよね
下のほうに書いてるんだろうけど、よくある別の言語仕様だと、a[-1]が末尾を表したりできるし、数多くの言語でインデックスループだと
これもよくある相対位置やインデックス演算でa[i-1]とか書くけど、usizeをキャストしてi32にしてもう一度、スライスにアクセスするために
as usizeとか2回キャストを行う。これがどれほど醜くなるし、めんどくさくて労力を要するか
当然、メモリアドレッシングが0x00〜上に伸びていくことなんて言わなくてもわかるが、それが合理的であり、かつスライスがusizeで
支持できる理由かといえばどうだろう？少なくとも私はメンドクサイ
またもちろん、(a, b) = t がタプルのアンパッキングなどに使えるのも知ってるけど、それとまとめて変数の宣言と初期化を少ないタイプ量で
出来る話とは別だろう、上からアドバイス頂いてるようでケチをつけて申し訳ないけど、もちろん不変性はマルチスレッドでも有利だしコードの
リファクタリングなどもし易い、ファンクションの変更が良くわかる（そのくせ同じ変数名で別型再定義できたり）とか色々利点があるのは
当然分かってるけど、これもまたmutを多数宣言しなきゃならない時とは全く別の話だよ
2022/09/04(日) 23:56:45.66ID:C1tkKKn6
>>246
Rustならばusize型そのままa[i-1]と書くことが出来ますが
2回キャスト面倒とは別の言語の話ですか？

例えば前の要素との差が指定のものを見つけてインデックスを返すRustコード例
fn find_diff(a: &[i32], diff: i32) -> Option<usize> {
　for i in 1..a.len() {
　　if a[i] - a[i-1] == diff {
　　　return Some(i);
　　}
　}
　None
}
もちろん最適化によりアクセス時のインデックス境界チェックは無くなります
2022/09/05(月) 00:30:20.92ID:+iXq2ECO
まともにプログラム書いたことなさそうだね
2022/09/05(月) 00:34:33.72ID:BTzrk4g4
>>241
Rustはletとmut指定を分離することでそのようにできるから大成功だな
mut指定が分離していない言語ではそのようにすることができずいつも困っている
方法がないからimmutableで十分な変数も含めてまとめてmutableな変数宣言にせざるをえない
初めて知ったときRustはよく考えられているなあと感動した
250デフォルトの名無しさん
垢版 |
2022/09/05(月) 00:43:43.47ID:+21R+/VD
>>246
・Rustは、数値リテラルに多くの言語ある固定の型がなく、文脈によりu32とかi32とか変わる（型推測）
・下のほうで境界チェックがないのも1..a.len()としているから
当然ながら、これは胸を張って一貫性があるとは言えないがa[-1]は言語仕様ではコンパイルエラーになるが
for i in 0..a.len()とすれば境界チェックが入り実行時にpanicする
君が勘違いしてるのはa[i+b]とかはbを宣言した場合、as castが必要で、色々ごっちゃになってるYO

アンダースタンド？ｗ
251デフォルトの名無しさん
垢版 |
2022/09/05(月) 00:44:27.92ID:ARttffD1
C++は型の特性を調べて、ユーザーがconst性を利用したバージョンの実装を生み出すことができる。
しかも利用時には、型の特性によってコンパイラにどのバージョンを使うか選択させる事が出来る。
2022/09/05(月) 00:48:14.12ID:g3RfqaIY
RustもIndex<u32>とか実装はできるよ
標準のsliceに実装されてないというだけで
253デフォルトの名無しさん
垢版 |
2022/09/05(月) 00:55:53.18ID:ARttffD1
C++は、型の計算ができるんですよ。
254デフォルトの名無しさん
垢版 |
2022/09/05(月) 01:07:57.19ID:9iTWKe04
すまん、誰が聖闘士星矢で例えてくれないか？
255デフォルトの名無しさん
垢版 |
2022/09/05(月) 01:12:56.84ID:ARttffD1
>>254
くちから　たれている　みつは　２きろ　はなれていても　はなが　まがるほど　もうれつに　くさい。
2022/09/05(月) 01:19:02.56ID:JbiV7xYP
>>211
一昨日は言葉が過ぎました。開発現場、携わっている人には心無い発言でした。反省してます。
強調したかったのは、最適化って難しいよ、速そうな言語を選んでコンパイラにお任せって言う易しい世界じゃないよ、という事です。

むしろ叩きたいのは、定期的に現れる無意味なRust上げ
スレッドの流れをフォローしている人間にはネガティブキャンペーンと受け取られているコメントです。
うすうす気づいているとは思いますが、これSEO対策なんですよ。
Rustをほとんど知らない人が検索をした時に、
チラッとその一部だけを見せてエコーチェンバーにはめ込むと言う仕掛けです
同様に時々現れる、会話の流れを修正したい時に持ち出す極論、逆説的にRustを卑下する冗談
これはわざとRsutとタイポしてチラ見に現れないようにしている。
複製おじとは別人だと思うのですがどんなんですかね。皆さんの意見を訊きたいな
2022/09/05(月) 01:22:23.34ID:RaegMrzk
>>246はまともにプログラミングしたことないとまでは言えないが多くの勘違いをしてるのは確かだな
usizeを上に伸びていくと書いてあるから引き算出来ないとでも勝手に思い込んでa[i-1]ができないと勘違いしたのかもしれない
もう一件

＞ よくある別の言語仕様だと、a[-1]が末尾を表したりできるし

その件はa[-1]やマイナスのインデックスに意味を持たせたプログラミング言語の仕様ミス
もしくはお子様向け言語であるとの結論が大昔に出ている
プログラミングのミスでマイナスのインデックスとなり本来はエラーでミス発覚となるべきところか不可能となった
つまり言語仕様ミスなのかそんなこと気にしないお子様向け言語なのかどちらかということになる
ほとんどの言語はまともなのでa[-i]はエラーとなり正しくa[len-i]と書く
2022/09/05(月) 01:34:56.96ID:9oDekVHu
>>257
複製おじ？usizeの議論は微笑ましいですね。盲目的ですが熱意にあふれてます。
速度、最適化に関する盲目的思い込みがなければ無害ですな
SEO対策(>>256)に加担していなければの話ですが
259デフォルトの名無しさん
垢版 |
2022/09/05(月) 01:45:29.53ID:ARttffD1
実力のある者はC++を利用するべきでは？
2022/09/05(月) 01:57:02.85ID:b0NkdPU/
>>259
同意ですな
一方で熱意にあふれ盲目的で従順に車輪の開発をしてくれるプログラマが
無料で使えるのであれば使わない手は無いとLinus辺りは策略してそう
SEO対策(>>256)もあながち...？
2022/09/05(月) 02:02:44.86ID:7mfke0+F
欠陥言語C++を使うメリットは何？
今はこれだけ多数の安全な言語があって色々選べるのに
262デフォルトの名無しさん
垢版 |
2022/09/05(月) 02:05:41.16ID:ARttffD1
アセンブラを使う理由はレジスタにアクセスできるから。
これはとても危険。
C/C++を使う理由はメモリーにアクセスできるから。
これはとても危険。
263デフォルトの名無しさん
垢版 |
2022/09/05(月) 02:07:30.95ID:ARttffD1
大いなる力には責任が伴う。
　　2019 - アフレシアさん
264デフォルトの名無しさん
垢版 |
2022/09/05(月) 02:14:43.00ID:ARttffD1
早くコンセプトが使いたいわー。
2022/09/05(月) 02:16:22.39ID:E82kQidM
>>261 もしこの二日間程度のスレッドの流れをフォローしてもなお一つのメリットも見えないのであれば
あなたの長所は熱意だけです。周りを頼って上手に立ち振る舞ってください。

>>260 有料案件で活躍されているプログラマーを見下すものではありません

>>263 同意 正に実力の世界。去れよ無責任Kids
2022/09/05(月) 02:33:35.68ID:sgxkT6js
C++にもメリットはありゼロじゃない
ただし世界的には>>154の結論が出ている
そして今回もC++で書かれたChromiumの穴のせいで、それを使うElectronを始め多數に影響が出て、それを使うVScodeにもセキュリティ脆弱性と連鎖
C++を使い続ける限りセキュリティの穴が量産されてしまう
2022/09/05(月) 02:57:07.57ID:5U2utJMj
>>266
あなたの結論素晴らしいですね。
どうぞLinusあるいはMozillaの元へ
SEO対策(>>256)の一環ですか？

＞C++を使い続ける限りセキュリティの穴が量産されてしまう
ほんと怖いです。一刻も早くRustに書き換えて欲しいですね。もう10年経ったっけ？

ところでFirefoxのthird_party directoryを除いたsource repoでのRustの使用割合ってご存知？宿題ですよ
268デフォルトの名無しさん
垢版 |
2022/09/05(月) 03:10:33.61ID:9iTWKe04
何でもrustでやらんで、安全性第一のとことか機能が優れてるとこ(非同期やジェネリクス、健全なマクロ、パターンマッチ等)とかからでもrustを便利に使ってったらええ。
今のrustは少しずつ実用面で採用を広げて行ってる段階だろ。Linuxでの採用とかさ。
既存のcでやってることをイキなり全部rustで置き換えようとしてる人なんて居ない。
rustにその潜在能力があったもしてもマンパワーが足りない。だから大手は少しずつ小さな分野で使いだしてる、複数の大手でね。
ただrustはもっとc言語との連携が簡単だったらと思う。
2022/09/05(月) 03:31:45.52ID:hQwE/dE/
>>268
＞何でもrustでやらんで、安全性第一のとこ
完全同意 話が合いそう
安全性アピールがマーケティング上有利な暗号通貨系の動きが早かったです

＞Linuxでの採用とかさ。
早いとこ第一歩を踏み出して欲しいです。偉大な一歩となることでしょう。

＞既存のc...イキなり全部rust...
10年なんてあっという間ですね

＞複数の大手でね。
大手って何やっても凄いです
ScalaでのNetflix分岐点 未満/以上の話を思い出した

＞ただrustはもっとc言語との連携が簡単だったらと思う。
完全同意 話が合いそう

>>266 が宿題(>>267)をサボったら手伝ってあげてください
2022/09/05(月) 03:36:29.05ID:pmwagyd7
>>268
どの言語からどの言語の場合でも既存システムをそのまま言語置き換えはコストだけかかり効率がよろしくない
そのためシステム改修や新規システムを中心にRust採用となっているようだ
現在ある選択肢では人間が引き起こしうるミスをコンパイラに防止させてセキュリティ含む穴を無くしていく言語候補がRustの他にない
271デフォルトの名無しさん
垢版 |
2022/09/05(月) 06:42:39.68ID:ARttffD1
簡単に言えば、Pythonの代わりにRustを使うことはあっても、C/C++の代わりになることはない。
レジスタやメモリーを扱うのは大変危険だから。
2022/09/05(月) 07:16:47.41ID:yWe543y4
>>271
Rustはinlineアセンブラ記述をサポートしていてレジスタ操作もできることを知らないのかね
Rust叩きの人はなぜ学習せずに無知なままなのだろうか
273デフォルトの名無しさん
垢版 |
2022/09/05(月) 07:22:08.46ID:ARttffD1
>>272
じゃあ安全じゃないじゃん。
2022/09/05(月) 07:51:21.51ID:928S9Xdp
以前の言語
　・プログラムのメモリ安全性、null安全性、データ競合安全性をプログラマーの責任で保証する

Rust
　・それらの安全性を全てコンパイラが保証
　・プログラマーの責任でCと同じメモリ操作やインラインasmなどを記述できるunsafeブロックもサポート

Swift, Kotlinなど
　・null安全性をコンパイラが保証
2022/09/05(月) 08:33:46.56ID:HWNfM8e/
>>268
Rustを使うにはガッツリ勉強しないと無理だから……THE BOOK一通り勉強しないと無理だから……
276デフォルトの名無しさん
垢版 |
2022/09/05(月) 09:45:50.25ID:KpRHtzI/
>>92
上に書いたように、当然gccでやったら同じコンパイル結果にならず全く違いますね？これを同じとは言えません
rustcの結果(-C opt-level=2)が138行あるが、x86-64 gcc 12.2(-O2)は16行です。
https://godbolt.org/z/v6TxTGGbT
max_value:
test rdi, rdi
je .L4
lea rcx, [rsi+rdi*4]
xor eax, eax
.L3:
mov edx, DWORD PTR [rsi]
cmp eax, edx
cmovb eax, edx
add rsi, 4
cmp rsi, rcx
jne .L3
ret
.L4:
xor eax, eax
ret

速度の比較はやはりrust（というかllvm)のほうが、ほんのちょっぴりから2倍以内ほど遅い結果になると思います。
今はC言語といえばclangなのかもしれませんが作られているソフトウェアはまだgccのほうが圧倒的に多いです。
gccを-O3にするとrustcと同じくSIMD拡張命令が使われますが、それでも84行と138行なので違います
それほど真剣に見ていませんが、C側はlenが引数として取るのに対して、もう一方はlen()を呼び出していますが
c/clangでほぼ同じになるのはなんでなんでしょうか？
2022/09/05(月) 09:57:13.85ID:DUaqFrRV
>>276
やっぱりおまえアホだな
16行だから速いと思っている？？
行数で速さは決まらないが
その例なら16行のコードが無展開で一番遅くなる
2022/09/05(月) 10:24:45.85ID:vkD3rEEb
>>276
Cでは引数にlenを取り、Rustではlen()を使っていて、両者は全く異なるのに、なぜ、ほぼ同じ生成コードになるのかが分からないって！？
もう少しRustを勉強してからアンチ活動しましょ

Cは先頭ポインタと長さの二つの引数を別々に渡しているのに対して、
Rustはスライス1つのみ引数を渡しているけど、「スライス＝ポインタと長さのセット」だから同じ情報を渡しています
そしてlen()はその長さ部分を示すだけだからCコード側のlenと同じ

そしてスライスとしてセットとなっているlen()だからこそデタラメな不正な値が来ることはなく、
コンパイラの管轄下で信頼できる正しい長さ数値情報として扱うことができて、
その長さ未満となるループ内でインデックス境界チェックも安全に省略できるのよ
そのためLLVMによりCのプログラムと同等の生成コードが出来上がります
2022/09/05(月) 12:00:09.73ID:g3RfqaIY
>>276
rustにもgccバックエンドあるからそれで試してみてくれ
2022/09/05(月) 13:38:45.87ID:hgtSwHCO
>>276
素晴らしいです。ブラウザで見るに留まらず実際に動かしたのですね。277 278は気にする必要なし

gccの中の人も訪れる場でおこがましいですが解説してみます
gccとclang/LLVMで同じ最適化オプションO2同士でも適用されるテクニックが異なるのです。
手っ取り早く最上級で比べる場合は gcc -O4 vs clang -O3 で比べたりします。
>>73の人も書いてますがclangはgccに比べてやたらとunrollしたがります。
clangが出始めの頃に持ち上げられた事がありましたが、新入りは背伸びをしたがるものです
大きなデータセットで見栄えのする、gccに引けを取らないベンチマーク結果が欲しかったのか
そういう状況にフォーカスした味付けがしてあったのかなと邪推したくなります

今回のケースで言うと
277 278はasmを表面的に見ただけの人で
データセットサイズに寄りけりだという常識(最速を目指すものには)がすっぽり抜けてます

gcc -O2 vs gcc -O3 vs clang -O2 (vs Rust)
ttps://godbolt.org/z/6E4Ksx34Y

gcc -O2 unroll なし blanchless move(cmovb)だけ
gcc -O3 unroll x 4 ( 4 byte/roll * 4roll/loop = 16 byte/loop = 128bit SSE LOAD x 1 / loop)
clang -O2 unroll x16 ( 4 byte/roll *16roll/loop = 64 byte/loop = 128bit SSE LOAD x 4 / loop)

lenが小さい時はせっかく用意したunroll loopに入れられず
unroll x 4 --> len <= 3 else の振り分け1回
unroll x 16 --> len <= 15 else len <= 7 else len <= 3 かどうかの振り分け3回
とunrollが大きいほど手間がかかり、CPUの分岐予測と投機実行の性能に寄りけりですが、
Benchmarkで数を回せば観測される確かな差が生まれます。
2022/09/05(月) 13:42:00.23ID:KOsqPsuw
len>=16の場合はどうか

L1/L2/L3に収まっているかどうか
それぞれのcache階層間のデータ転送granularity
Hardware prefetchの効き具合 on the fly loadの上限数
surrounding code間とのcache pollution

いろんな要因がありすぎて 結局やって比べるのが手っ取り早いです
gccはcache pollutionへの対策かどうか確認したことはありませんが
unrollは控えめな印象は確かです(オプションで調整できます)

この辺のトレードオフを評価するコストモデルはCPU vendorがPRを出したりしますが
タイムリーかどうかはその時々です
個人的な印象ですが-march=znver2と-march=znver3が長いこと同一だった気がしてます...

お使いのCPU次第ですが AVX(128bit -mavx) AVX2(256bit -mavx2)で試したら
更なる発見があると思います
compiler exploreで -mavx2のasmを見てみるだけでも面白いですよ

Apple Siliconの方は判りません。どなたか解説お願いします
2022/09/05(月) 14:12:00.36ID:++1d7Ak5
Java C#などのJIT勢は決まってピーク性能(大きなデータセット,warmup付きのbenchmark)を
アピールしますがピーク性能だけを見ていて十分かどうかは別途判断が必要です。

競プロ目標であれば
>>228の様にいろんな楽しみ方がありますよ
>>226で懐かしいと言ったのは途中で行列の転置をかますことで
劇的に速くなった記憶があるからです。O(数式)ビッグオー レベルで
まだsubmit出来るようなのでお試しください
2022/09/05(月) 15:11:00.05ID:kIS7nj8M
連投するのに何でいちいちID変えてるの？
2022/09/05(月) 15:42:20.01ID:ORvHoQkv
気軽にNGされると困る
2022/09/05(月) 15:43:39.27ID:4jBB7bRF
まるでRustがキチガイ用言語に見えてきた
2022/09/05(月) 16:07:08.66ID:ZY4XQhp4
ヒント：複オジはワッチョイスレに一回も来たことがない
2022/09/05(月) 16:32:50.42ID:NIbO6JQn
複オジも昔はコテハン使ってイキってたんだが
恥ずかしいレスを叩かれて匿名複オジに
今でもそのコテハンで書き込んだりもしてる

迷惑だよな
2022/09/05(月) 18:31:27.51ID:i8gFMMFV
やっぱりワッチョイにしようぜ。
289デフォルトの名無しさん
垢版 |
2022/09/05(月) 19:04:14.83ID:iWQD5HeB
Haskellの時もそうだったけど、世界でアカン空気が流れ始めると、日本で流行らせようと宣伝し始めるのは何でだろな？
2022/09/05(月) 19:05:51.22ID:JwYYQerB
日本のIT技術を遅らせたい勢力が存在するのかも
291デフォルトの名無しさん
垢版 |
2022/09/05(月) 19:06:21.16ID:iWQD5HeB
RoRの時みたいに、世界で流行るときは、日本ではアカン言うてアンチが増えるんだよね。
2022/09/05(月) 19:08:02.01ID:XsUbtHe1
>>290
この件と関係あるかは知らんけどその勢力がいることだけは確か
293デフォルトの名無しさん
垢版 |
2022/09/05(月) 19:11:19.28ID:iWQD5HeB
このスレで紹介されるRustの良いところって、「定数の索引で配列アクセスする場合は、最適化されて境界チェックが消える、安心安全」だけでしょ？
定数の索引で配列アクセスなんて、一生に一度書くか書かないかくらいなんだから、そんな機能在っても嬉しくないわ。
294デフォルトの名無しさん
垢版 |
2022/09/05(月) 19:12:38.64ID:iWQD5HeB
その点Javaは、実行時最適化でRustの5倍速い。
知らんけど。
2022/09/05(月) 19:23:11.04ID:g3RfqaIY
>>289
Rustだめな理由知りたいからあかんとされてるブログ記事なりニュースなりフォーラムなり教えて
296デフォルトの名無しさん
垢版 |
2022/09/05(月) 19:28:42.10ID:iWQD5HeB
https://chrisdone.com/posts/rust/
こんなのはどう？

TwitterやRedditは辛辣な意見が多いよね。
クリップしてないけど。
2022/09/05(月) 19:51:44.37ID:wWfHpXgm
>>296
他にこういうのもあるの？
見てみたい
2022/09/05(月) 19:55:18.42ID:x/Xug50w
非同期関連がごちゃごちゃしてて面倒くさいってのはあるよな
ゼロランタイムコストが売りだから仕方がないんだろうが

その点Goはランタイムに強力な並行並列処理が組み込まれてるから、基本的な文法から標準ライブラリ、サードパーティライブラリで全て共通のgoroutine、channel、selectを使えて非常に扱いやすい
DockerやKubernetesとかクラウド関連で流行ってるのはこの並行並列処理が言語、ランタイムレベルでサポートされてるのが最大の要因だな
Nodeも非同期処理を言語レベルでサポートしてるからこれだけWeb系で流行ってる
その点Rustは弱い

ライブラリによってAはサポートしてるけどBはしてないとかあって色々面倒くさい
299デフォルトの名無しさん
垢版 |
2022/09/05(月) 20:01:50.03ID:iWQD5HeB
基本的にRustは知られていないんだよね。
日本以外では。
とっくにオワコンだから。
2022/09/05(月) 20:04:19.99ID:g3RfqaIY
>>296
割とソフトな意見でオワコンとまでは言ってないような
そもそも言語におけるオワコンって何？
301デフォルトの名無しさん
垢版 |
2022/09/05(月) 20:10:04.95ID:iWQD5HeB
Rustなんか構ってる暇あったら、PHPやれよって話。
302デフォルトの名無しさん
垢版 |
2022/09/05(月) 20:13:42.10ID:9iTWKe04
>>301
他部署の人たちのPHPのバージョンアップ追従に毎回ドタバタしてるの見ると関わりたくないなぁと思う。
もちろんそれだけのお金と時間くれたらいいけど、PHPの単価ってそれほどでも無いよね？
2022/09/05(月) 20:20:47.93ID:kVCZ1c6R
>>293
君は相変わらずデタラメばかり言ってるなあ
定数の索引で配列アクセスしているコードは出てきていない
その件で出ているRustの関数の引数は全てスライスであり配列ではない
つまり始点ポインタも長さも未知のものが引数としてやってくる
さらに定数の索引とはa[5]などの例を指しそんな例も出ていない

正しくは
未知の始点ポインタと未知の長さが引数として与えられてその中を変数の索引が動くコード例であり
RustとCは同等の生成コードとなることが確認された

>>294
Cと同等の速さのRustより何倍も速いプログラミング言語は存在しない
2022/09/05(月) 20:25:02.75ID:5VtMLQd9
>>300
最後まで読むと結局仕事では使ってるみたいだし
どちらかというと不満がある人でも使うくらいには広まってきている、というべきな気はする
オワコンっていうには他言語に移行したみたいな事例が必要なのでは
2022/09/05(月) 20:36:11.44ID:e+uJj/tK
>>289
そもそもHaskellとRustに何の関係があると思った？
異なる言語って普通ならどうしようもなく分断されていて全く無関係な筈じゃないのかね

分断を回避する秘訣でもあるのか
2022/09/05(月) 20:50:10.83ID:Xf3ARiO4
>>296
読んだけど少し偏った思想の人なだけだった
「いずれRustでガベージコレクターが人気になると予想する」とか今後も極一部の用途以外では使われないだろう
「XXXをRustで書き換えたら速くなったというのはRustのせいじゃない」は安全かつ速くなった利点を理解していない
「良いメンテされたコードを書いてるメンテナーは非同期を採用することに抵抗がある」は用途に応じて使い分ける人が正常なので抵抗なんてない
Rustを批判する人はちょっとおかしな人が多いと感じる
2022/09/05(月) 21:07:54.27ID:bQN+7pEG
>>293
さすがにそのツッコミはRustゴリ押しの自作自演級に低レベルだぞ
2022/09/05(月) 21:25:09.81ID:qPl0Yk8b
Haskellてあかんやつだったの？
2022/09/05(月) 21:39:30.67ID:wI2HBmBd
>>305
Haskellはガベージを撒き散らしながら計算を進めるからRustとはその点で真逆な存在かな
強いて言えばHaskellの型クラスとRustのtraitが基本思想の一部で似てる程度
そのRustとHaskellを叩いてる人はどうせ何も理解していないでしょう
2022/09/05(月) 21:58:07.88ID:59/nx/yB
例えばRustでhttpクライアント使いたかったからhyperやらreqwestやらsurfやらサードパーティのライブラリを使うことになると思う
別にこれでもいいが他人のコードを読む上で共通のコードが出てくるってのはかなりアドバンテージがある

それに対してGoが標準ライブラリで用意されてるから通常サードパーティのライブラリは使わない
コネクションプーリングも勝手にやってくれる上にhttp2対応も完璧
テストもhttptestパッケージで簡単に作れる
サーバー作る時も標準ライブラリを学んでおけばサードパーティライブラリの習得は容易

RDB扱う時もGoは標準ライブラリレベルでインターフェースを共通化したりコネクションプーリングをサポートしてる

ということで標準ライブラリが強力ってのは実用的なソフトを複数人で作っていく上で非常に重要
2022/09/05(月) 22:16:25.49ID:LJb2ynoL
>>310
hyperとreqwest/surfはレイヤーが異なり比較する対象でないからそこで例として持ち出すのは適切ではないね
あと標準ライブラリの範囲や意味するところは言語によって異なるのだからあまり意味のない議論だと思う
その思想だとあらゆるものが標準ライブラリにあり他のライブラリを一切使わない言語が最上となってしまう
それぞれにメリットとデメリットがあります
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況