次世代言語10[Rust Swift TypeScript Dart]

**デフォルトの名無しさん** · 2018/04/25(水) 07:02:27.60

スレタイ以外の言語もok

前スレ
次世代言語9[Haskell Rust Kotlin TypeScript Dart]
http://mevius.5ch.net/test/read.cgi/tech/1520298555/

**デフォルトの名無しさん** · 2018/05/12(土) 10:47:42.87

>>505
sunはコンテナーをいち早く実現してたり
zfs出したり、先進的な企業だったよな。金が稼げなかったけど。
googleは金があるから問題ない

**デフォルトの名無しさん** · 2018/05/12(土) 10:52:24.71

>>507
Blazorに期待してる

**デフォルトの名無しさん** · 2018/05/12(土) 10:55:45.44

JavaScriptからwasmへのコンパイルができるようになったら普及は速いんだろうけど、いつになるかなぁ。
そのころにはwasmのエコシステムも十分整備されてそう。

**デフォルトの名無しさん** · 2018/05/12(土) 11:01:20.26

>>507
各種apiのリファレンス実装として続いてくんじゃないかとは思ってる
正直TS→wasmは期待しちゃうよね

**デフォルトの名無しさん** · 2018/05/12(土) 11:13:10.47

rustでwasm吐くとdom操作もメモリ効率が良い感じになるのだろうか。
個人的にはgoで全部できるようになりそうで嬉しい。

meteor.jsというのがあってね。コンセプト的にすごく良かったんだけどエコシステムがいろいろ終わってた。wasmでもう一度復活するかも

**デフォルトの名無しさん** · 2018/05/12(土) 11:31:33.64

Rustでブラウザ本体を書き直す動きがJSの部分にまで広がる
ブラウザを作れない言語には速い遅いという以前の問題がある

**デフォルトの名無しさん** · 2018/05/12(土) 13:14:14.79

>>508
思い出は美化されるね。
不便なコマンド、SysV系転向、長いことジャーナリング無し、ftpのlsがユーザのロケールでパース困難、NFSの進歩の遅さ、etc
罪を数えたらキリが無いよ

**デフォルトの名無しさん** · 2018/05/12(土) 13:53:25.93

>>491
なんでも俺のせいにすなw

**デフォルトの名無しさん** · 2018/05/12(土) 14:06:23.00

よかった、透視能力なんてなかったんだ

**デフォルトの名無しさん** · 2018/05/12(土) 14:10:21.47

>>508
SUNは我田引水に失敗して凋落したのだ。
自社の高価な機器を売るためにメモリーイーターな言語を広めたり、自社の機器以外では性能が発揮できないように互換環境を禁止したり。

**デフォルトの名無しさん** · 2018/05/12(土) 14:13:17.43

Googleは現在我田引水のため色々やってるが、消費者にとっては良いことは何もない。
吉と出るか凶と出るか。
一方、MSは戦場から早々に離脱したので、不戦敗となるのか、勝ちもしないが負けもしないのか。

**デフォルトの名無しさん** · 2018/05/12(土) 17:45:08.76

>>503
dot関数自体の最適化はほぼ完璧に行われています
gcc だと 100 回繰り返してるところを1度で済ます
最適化が起きてるだけでは？
速度もちょうど100倍だし。

そうじゃないと
>i5-3550 で 0.08ms

1G回の積和を0.08msで完了ということは毎秒125Gの積和を実行したことになりますから、
演算性能は125GFlopsメモリ帯域は1000GB/sになる (←あり得ない)

**デフォルトの名無しさん** · 2018/05/12(土) 17:51:25.31

最後の計算間違ってるか
結果はあってるけど10M個の積和を0.08ms、という計算か。

**デフォルトの名無しさん** · 2018/05/12(土) 18:44:38.63

>>519
ああ、確かに。引数変わらないから１００回ループが１回に省略されてるな…

**デフォルトの名無しさん** · 2018/05/13(日) 08:36:01.91

Cはハスケルの１００倍はやかったってこと？

**デフォルトの名無しさん** · 2018/05/13(日) 11:23:16.33

GCのベンチマークって無いのかな
一番速いのはGo言語？

**デフォルトの名無しさん** · 2018/05/13(日) 11:26:00.88

Rustってcと比べて機能てんこ盛りなのに同等の速度で実行できるって何でなの？

**デフォルトの名無しさん** · 2018/05/13(日) 11:46:40.60

別に機能が多いかどうかは関係ない。
速度を出すための設定を細かくできるかどうか。
細かく設定するってことはそれだけ手間がかかるってこと。

**デフォルトの名無しさん** · 2018/05/13(日) 12:03:30.51

整数とポインタの見分けがつかない機械語に比べたらCも機能てんこ盛り
だがCのポインタは参照とスライスとBoxとOptionの見分けがつかない

**デフォルトの名無しさん** · 2018/05/13(日) 13:34:16.59

>>526
これ重要やな

**デフォルトの名無しさん** · 2018/05/13(日) 15:12:37.68

>>457
のCのコードみたけどぎょれつ演算にブロック化してないからキャッシュミスが
多くなって遅くなってるだけだな。
ハスケルは自動でメモリーの最適化してるからはやいだけだな。

**デフォルトの名無しさん** · 2018/05/13(日) 15:18:09.79

dot product計算するだけのマイクロベンチなんか言語比較として無意味

**デフォルトの名無しさん** · 2018/05/13(日) 15:34:14.94

>>528
へえ。ハスケル意外と有能やん

**デフォルトの名無しさん** · 2018/05/13(日) 15:50:11.19

デタラメ言ってるだけだぞw
このスレの連中はホント騙されやすいな

**デフォルトの名無しさん** · 2018/05/13(日) 16:00:43.94

1次元のリニアなメモリをシーケンシャルに読むだけなのにブロック化とか
ここは物事の真偽もわからない初学者の集まりなんだからデタラメで混乱させるなよ
検証できることはちゃんと検証してから発言しよう

**デフォルトの名無しさん** · 2018/05/13(日) 16:15:28.33

うわマジやん糞かよ死ねや

**デフォルトの名無しさん** · 2018/05/13(日) 16:24:23.38

でも検証にはコストがあるからな
お前は嘘つきだと宣戦布告して戦争か裁判をやって勝つまでが検証です

**デフォルトの名無しさん** · 2018/05/13(日) 17:28:06.32

xとy別々の配列じゃなくて
x0y0x1y1x2....のように並べるってことだよ。
そうするとメモリーアクセスが早くなる。

**デフォルトの名無しさん** · 2018/05/13(日) 18:40:55.81

>>535
コード読めよ
xとx掛けてるんだぞ

**デフォルトの名無しさん** · 2018/05/13(日) 21:55:04.60

検証もせずに適当に推測するが
>>457のHaskellの方がCより速いというのはループを1回で済ます最適化がされた結果であって、
1ループあたりの実際の速度はCの1/80の速度なのかもね

**デフォルトの名無しさん** · 2018/05/13(日) 23:16:22.73

Haskellが早いと言うかHaskellだと早く出来ることがあるって感じだろ

**デフォルトの名無しさん** · 2018/05/13(日) 23:53:00.06

そりゃそうだろ

言語によって得意な処理は違うし、プログラマの実力によっても変わる
数値計算に限定すればjuliaは手軽に書けて尚且つ実行速度も速かったりする
バカが書いたCのコードより天才が書いたHaskellのコードのほうが(多分)速い
言語の速度だけ比較してあーだこーだ言う前に
各言語に関する詳細な知識とコーディングの実力を身に着けるべし

**デフォルトの名無しさん** · 2018/05/14(月) 00:07:25.34

SEYANA

**デフォルトの名無しさん** · 2018/05/14(月) 06:12:40.31

ドット積のような簡単な計算ならCPUの処理速度が速すぎて
メモリー転送速度がボトルネックになることは明らかだしな。
ハスケルの場合、ランダムな数値をメモリーに記録することなく
オンザフライで計算したのかもしれないな。

**デフォルトの名無しさん** · 2018/05/14(月) 07:36:06.84

ドット積が律速になることってある？

**デフォルトの名無しさん** · 2018/05/14(月) 07:59:32.34

バイナリサイズも気になるけど。
と言うか、速い遅いはあんまり簡単に割り切るわけにいかんし、
推測より実測は確かだけど、その前に何を実測してるのか、
大体どれぐらいになるかをもう少し予測したほうがいいと思うんだけどな。
こういう小さい関数単位のベンチは特に。

最新の処理系は両方持ってないから俺出来ないけど、ネイティブコード比べたほうが良いのでは？
gccは(いろんな意味で)信じられない最適化かかってる事あるし。

**デフォルトの名無しさん** · 2018/05/14(月) 08:36:31.93

>>542
HPCならなくはないけど、その場合は手計算で展開して前後の計算も含めたもっと大きなドメインで最適化するわな
単独でdotだけの最適化なんて、自分の息子を気持ちよくする以上の意味はない

**デフォルトの名無しさん** · 2018/05/14(月) 13:14:41.23

C++の定数式を使う。

**デフォルトの名無しさん** · 2018/05/14(月) 17:04:14.47

>>539
そういう話でしかないからそういう話だという指摘をしたんだろ

**デフォルトの名無しさん** · 2018/05/14(月) 18:11:35.62

SEYANA

**デフォルトの名無しさん** · 2018/05/15(火) 07:41:24.21

ハード的なことは自分はよう知らんが、純粋関数のみで書いたところは、筋の良い関数への置き換えが利いてくれる、てことなのだろう。
知る限りだと、map、fold、filter、zipみたいな基礎的な高階関数と、配列更新はupdate関数を使っとけばその辺が勝手にかかるみたい。

>>457の例は、sumはfoldで、zipWithはzipとmap。

速度ガチ勢は満足しないだろうが、宣言的にやってる割に速度を出したければ、この辺りを気をつけてれば良い印象。

逆に気をつけないと、相当遅い。LazyとStrictも気をつける必要がある。

**デフォルトの名無しさん** · 2018/05/15(火) 09:00:25.93

これはhaskellじゃなくて理系がバカなんだ
文系がhaskellを勉強しても速度のことなんて考えないだろう

**デフォルトの名無しさん** · 2018/05/15(火) 15:12:17.78

このスレは何を議論するスレなんだ

**デフォルトの名無しさん** · 2018/05/15(火) 15:24:27.98

雑段するぞ

**デフォルトの名無しさん** · 2018/05/15(火) 18:37:20.71

SOYANA

**デフォルトの名無しさん** · 2018/05/15(火) 19:24:43.54

>>550
次世代言語と言えば関数型、関数型と言えばHaskell、ホルホルホル。

**デフォルトの名無しさん** · 2018/05/15(火) 19:50:21.10

>>549
理系が馬鹿ってことは文系が頭いいってこと？そんなバカな

**デフォルトの名無しさん** · 2018/05/15(火) 20:03:43.73

先入観は可能を不可能にするって二刀流の人が言ってた

**デフォルトの名無しさん** · 2018/05/15(火) 20:20:31.80

このご時世理系文系なんて言ってるのもどうかと思うがね

**デフォルトの名無しさん** · 2018/05/15(火) 21:18:11.07

>>553
くっさ。流石にそういう返答は求めとらん。性格悪すぎか

**デフォルトの名無しさん** · 2018/05/15(火) 22:06:27.79

理系文系で語る奴にはろくなものがイないはず
ソースは川上

**デフォルトの名無しさん** · 2018/05/15(火) 22:38:41.36

そのろくでなしを討ち取るか逃げ切られるか確定してないソースにはあまり意味がない

**デフォルトの名無しさん** · 2018/05/16(水) 00:35:59.84

はてな民の悪口はやめロッテ

**デフォルトの名無しさん** · 2018/05/16(水) 04:13:18.32

>>548
加えて >>457 には left fold にしとかないと遅いよとある
理由はあまりに明白だからか触れられていないけど
ここはあまり実践に拘る人いないからわりとどうでもいいか

**デフォルトの名無しさん** · 2018/05/16(水) 06:37:06.57

コンパイル時と実行時で語る奴は速いよ
OOPと関数型で語る奴にはろくなものがいない

**デフォルトの名無しさん** · 2018/05/16(水) 06:47:58.51

LazyかStrictかってな。評価戦略も考えてかなならん。

まあ、Haskellも使いこなすには、それなりの背景知識がないとあかんという事だね。

**デフォルトの名無しさん** · 2018/05/16(水) 07:09:06.16

lazyは無限の計算を打ち切る
遅い計算をちょっと速くするだけの最適化とは次元が違う

**デフォルトの名無しさん** · 2018/05/16(水) 07:20:15.91

>>562
これは同意かな。
結局抽象論でドヤるの好きなだけなやつってのは
実測を嫌う傾向にあるから問題を引き起こす。

**デフォルトの名無しさん** · 2018/05/16(水) 07:35:27.07

>>564
初めから無限の計算をしないように書いた方が多くの場合(ずっと)速いのでないかみたいな話だろ

**デフォルトの名無しさん** · 2018/05/16(水) 07:51:39.34

そんなlazy全否定するような話題だったのか

**デフォルトの名無しさん** · 2018/05/16(水) 07:55:55.64

そういう話題だったら初めからそう言えばいいのに
現実的には後出しが便利だから後出ししてる
現実を実測しよう

**デフォルトの名無しさん** · 2018/05/16(水) 08:00:59.77

いや後出しも何も>>457のブログにlazy遅いよねとか書いてあってそれについて話してるわけだし…

**デフォルトの名無しさん** · 2018/05/16(水) 08:02:16.32

と俺は思ってたんだが違うのか？

**デフォルトの名無しさん** · 2018/05/16(水) 08:23:21.13

あってるよ。

**デフォルトの名無しさん** · 2018/05/16(水) 08:30:32.29

もう少し真剣に考えてもいいんじゃないか？
誰も最適化が完璧に行われてる、の追試しないの？
ghcの最適化結果のバイナリをgdbで眺めるだけでも全然違うと思うが。

俺がやるとおま環でオラつくなとか言われるの目に見えてるから静観してるけどさ。

**デフォルトの名無しさん** · 2018/05/16(水) 09:41:30.81

お前の静観ってうるさいのなｗ

**デフォルトの名無しさん** · 2018/05/16(水) 09:50:51.21

例がクソすぎて正直興味わかない

**デフォルトの名無しさん** · 2018/05/16(水) 09:51:48.57

>>573
やめたれｗ

**デフォルトの名無しさん** · 2018/05/16(水) 10:11:53.73

これ正味のところコンパイラのバックエンドの性能比較にしかなってないし、
その差も最適化オプションの違いと想像できる範囲だもの

**デフォルトの名無しさん** · 2018/05/16(水) 15:45:52.24

うーん、だったら異なる言語の速度比較に説得力を持たせるためには、どんなルールを定めればいいの？

**デフォルトの名無しさん** · 2018/05/16(水) 16:15:52.78

お題を設定して、そのお題を解く実行速度でも競えば

**デフォルトの名無しさん** · 2018/05/16(水) 17:11:19.52

これは反対意見が多いと思うんだけど任意の問題について各々の言語で素直な(読み書きしやすい/一般的な)書き方で解いた際の速度比較が一番だと思ってる
コンパイルオプションレベルでの最適化はアリだと思うけどソースでの最適化なんてほんとにそれするの？っていうのあるし

**デフォルトの名無しさん** · 2018/05/16(水) 17:35:38.66

問題の難度が低すぎるから早押しクイズになってしまう
正解者が1名いるかいないかの難問なら速度はどうでもいいだろ

**デフォルトの名無しさん** · 2018/05/16(水) 17:54:36.37

>>579
いや、そもそもソースを1つに限定しようとするのがダメだと思う
読みやすい(一般的な)コードと最適化を前提としたコードの両方を用意する
そうすれば両方のケースで比較できるようになる
あと、その任意の問題とやらも複数ケース用意する必要があるだろうな…
面倒臭いけどそれがベストだと思う

**デフォルトの名無しさん** · 2018/05/16(水) 18:10:24.62

>バカが書いたCのコードより天才が書いたHaskellのコードのほうが(多分)速い

一方ロシアは天才が書いたCのコードを用意した

**デフォルトの名無しさん** · 2018/05/16(水) 18:51:37.22

>>580
ある種の難問を解きやすいのが関数型言語のウリのはずだし、それはそれで一つの結果じゃない？

**デフォルトの名無しさん** · 2018/05/16(水) 19:03:04.49

それはそれとして
個人的に>>457の確認をしてみたいのだけど、
どんな main 書けばいいのか誰か教えてくれないか？

ghc -O2 で下記のようなコードをコンパイルすると
一切メモリ使わずレジスタだけで0.1ずつ増加させた数を積和していくからテストにならないし、
10M個の積和を100回実行するところも1回に省略される気しかしない…

https://ideone.com/gjFBNp

module Main (main) where
import Prelude hiding (sum, length, zipWith, map)
import System.Environment (getArgs)
import Data.Vector.Unboxed

test :: Data.Vector.Unboxed.Vector Double -> Double
test v = sum $ zipWith (*) v v

main :: IO ()
main = do
(n':_) <- getArgs
let n = read n' :: Int
let v1 = enumFromStepN 0.0 0.1 n
print n
print $ test v1

**デフォルトの名無しさん** · 2018/05/16(水) 19:11:48.70

いやごめん
Haskell スレで聞いてみます

**デフォルトの名無しさん** · 2018/05/16(水) 19:50:33.80

せっかくだから一応貼っておくと ghc -O2 は上記の sum zipWith をここまで最適化した

_c8Gb:
testq %r14,%r14 // 全て終わったら
jle _c8Gh // ループ終了
_c8Gi:
movsd %xmm1,%xmm0 // m0 <= m1
mulsd %xmm1,%xmm0 // m0 <= m1*m0
addsd %xmm0,%xmm2 // m2 <= m2+m0
addsd _n8GK(%rip),%xmm1 // m1 <= m1+0.1
decq %r14 // 回数カウンタ減らす
jmp _c8Gb // ループ

遅延評価と fusion すごいw

**デフォルトの名無しさん** · 2018/05/16(水) 19:58:05.30

ソースコードより短いのは流石に草

**デフォルトの名無しさん** · 2018/05/16(水) 21:37:36.10

これO(1)じゃなくてO(n)だけど速いのか？
聞くは一時の恥、聞かぬは一生の恥

**デフォルトの名無しさん** · 2018/05/16(水) 21:40:07.47

O(1)になるまで最適化って、それ1/6公式使わないと無理じゃね？

**デフォルトの名無しさん** · 2018/05/16(水) 21:43:37.16

つまり、鳥人間コンテストのような謎のルールで縛られてまともな飛行機作れない状態か

**デフォルトの名無しさん** · 2018/05/16(水) 21:50:17.17

1/6公式使うまで最適化してくれるようなコンパイラあんの？あったら見て見たいんだけど

**デフォルトの名無しさん** · 2018/05/16(水) 22:22:29.79

visualc の出したコードではループ回数が10の倍数だということを織り込んで
10回分ずつ loop unrolling して端数回を処理するコードは略されてた。

そこまでわかってるならもう全部計算しといて略せよという気がした。

**デフォルトの名無しさん** · 2018/05/16(水) 22:57:07.69

1/6公式使うのは違う計算をして微妙に違う値になるから最適化というより簡略化だな

**デフォルトの名無しさん** · 2018/05/16(水) 23:22:07.02

先に除算を分岐処理しないとオーバーフロー条件変わっちゃうからなぁ

**デフォルトの名無しさん** · 2018/05/16(水) 23:44:41.84

まあ最適化してるってことでコンパイル時に全て計算してしまえば
ランタイム速度はいつだってO(1)だよ。

**デフォルトの名無しさん** · 2018/05/17(木) 00:08:51.80

悪質な反則と正しいハックの違いを
理系の学問では説明できない

**デフォルトの名無しさん** · 2018/05/17(木) 01:23:03.74

コンパイル時に計算可能なのは>>457で
>>584は実行時の引数使ってるから計算しとくのは無理だな
いつだってO(1)に最適化できる、未来を予測する神のコンパイラがあれば別だけど。

積和しないで公式使うのがよろしくないってのは、
数学や算数の計算と違って丸め誤差のあるコンピュータ言語での
浮動小数点数演算は誤差に関する統一的な挙動、
通常 IEEE 754 に準拠した挙動が期待されるわけで、
式を変形したり変えたりすると丸め誤差の出方が違って結果の値が変わっちゃうから。

もちろん規格を守らなくて良いというオプションはあっても良いわけどけど。

…誰か何か他の話題を

**デフォルトの名無しさん** · 2018/05/17(木) 17:09:11.06

自分で考えろカス

**デフォルトの名無しさん** · 2018/05/22(火) 10:01:58.35

お前が考えろゴミ

**デフォルトの名無しさん** · 2018/05/22(火) 17:54:26.91

ほなワイが集めたるで～

**デフォルトの名無しさん** · 2018/05/22(火) 21:27:22.64

つまりRust最強

**デフォルトの名無しさん** · 2018/05/22(火) 21:57:35.93

何がどういう理屈で「つまり」なんだってばよ(；￣Д￣）？

**デフォルトの名無しさん** · 2018/05/22(火) 22:03:03.16

Rustは最近impl traitが実装されて使いやすくなった

**デフォルトの名無しさん** · 2018/05/22(火) 22:41:37.50

impl trait は確かに嬉しかった
これでやっとトレイトオブジェクト使わずにイテレータが返せるようになった

**デフォルトの名無しさん** · 2018/05/22(火) 22:50:22.39

rust わかりやすいくらいダメな方向に行ってるな。。

**デフォルトの名無しさん** · 2018/05/22(火) 23:12:28.14

Juliaは？
けっこう化けそうな希ガス

**デフォルトの名無しさん** · 2018/05/22(火) 23:20:40.27

何が理由で「ダメの方向」って言ってるのか分からない
C++の後継としてはRustは限りなく理想に近い言語だと思うが…