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

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

[前50を表示]
400:デフォルトの名無しさん
18/05/04 11:25:26.68 VQ//CMaE.net
>>393
それは抽象データ型を定義できる言語ならどれでも可能か
それともC++やRustでは不可能か
これが問題だ

401:デフォルトの名無しさん
18/05/04 14:10:07.69 51fiRXRv.net
この知ったかぶり
抽象データ型なんか関係ないだろ

402:デフォルトの名無しさん
18/05/04 15:02:25.96 ZqOHI6SP.net
>>393
ってもそれ空理空論であって、
x[i,j,k] みたいな配列のメモリレイアウトをアクセスパターンから
決めるという単純な処理ですらどの処理系にも実装の予定すらないだろう
「c/c++では有能なプログラマがちゃんと判断して書くから最適な結果が得られる可能性が高い」
という言説の方がまだ現実的

403:デフォルトの名無しさん
18/05/04 15:04:28.49 ngnuzOEt.net
>>396
単純に隙間を詰めるだけなら普通にやってるし、それだけでもメモリのアクセス効率や利用効率は改善するよ

404:デフォルトの名無しさん
18/05/04 15:05:37.17 ZqOHI6SP.net
>>397
それアクセスパターンと関係ないでしょ
話通じてないな

405:デフォルトの名無しさん
18/05/04 15:09:57.46 ZqOHI6SP.net
アクセスパターンからの最適化というのは、
巨大な配列だけどアクセスされるのはごく一部
→スパース配列を用いる
2次元で同じyについて近しいxで連続してアクセスされることが多い
→ cでいう v[y][x] というように同じy座標のものを連続して並べる
こういうこと

406:デフォルトの名無しさん
18/05/04 15:12:34.97 ZqOHI6SP.net
実装が隠蔽されていればそういう最適化の自動化が可能だという>>393に対して、
それはそうだが絵に描いた餅過ぎると否定的なことを言ったのが>>396
以上

407:デフォルトの名無しさん
18/05/04 15:24:22.35 51fiRXRv.net
ヒープの話から来てるからあくまでメモリアロケートした単位での最適化と考えるべきでしょ
話を拡大解釈して通じてないのはお前だと思う

408:デフォルトの名無しさん
18/05/04 15:40:45.66 8dzo215M.net
>>401
393をそう読むのなら話通じないな
別にお前が無違ってると主張する気は無いよ
思想と言論の自由は認めるから黙れとも言わないし

409:デフォルトの名無しさん
18/05/04 15:45:30.86 8dzo215M.net
あ、いや俺が間違ってる気がしてきた
コンパクションで並べるとかいう話か
それでもやっぱり
>>396
＞「c/c++では有能なプログラマがちゃんと判断して書くから最適な結果が得られる可能性が高い」
＞という言説の方がまだ現実的
だと思う

410:デフォルトの名無しさん
18/05/04 17:35:05.26 ngnuzOEt.net
で、有能なC++プログラマはヒープの断片化をどうやって回避するの？
一般的な回避策としてはまとめて静的に確保するわけだけど、それだとRAII的な方法論を否定してることになるよね

411:デフォルトの名無しさん
18/05/04 17:41:04.90 VQ//CMaE.net
生ポインタをprivateメンバーにすれば再配置できるんだろ

412:デフォルトの名無しさん
18/05/04 18:45:44.08 VQ//CMaE.net
そもそもRAIIを肯定するのも否定するのもC++プログラマの自由だ
この自由を尊重すれば、極めて大きな最適化の自由度はC++にもあるんじゃないか
自由を奪ったら最適化の自由度もなくなるのは当たり前だ

413:デフォルトの名無しさん
18/05/04 18:55:41.39 /D8HsFql.net
C++は何も縛らないからなんでも出来る理論本当に嫌い

414:デフォルトの名無しさん
18/05/04 19:00:50.09 ngnuzOEt.net
縛ったほうが最適化の自由度は上がる
C/C++はポインタのせいで配列アクセスの並列化がやりづらいのは有名な話だ

415:デフォルトの名無しさん
18/05/04 19:11:43.01 VQ//CMaE.net
>>407
じゃあ逆の理論はなんなの
一長一短理論
どっちもどっち理論かね

416:デフォルトの名無しさん
18/05/04 19:12:50.22 /D8HsFql.net
>>409
>>408

417:デフォルトの名無しさん
18/05/04 19:24:33.12 HyF2shia.net
GCは、あるプログラマにとっては仕事を単純にしてくれるが、別のプログラマにとっては仕事を複雑にする要因になるという特性があるんだよね

418:デフォルトの名無しさん
18/05/04 20:34:01.38 +h39vGOl.net
>>411
プログラマに、というよりは作ろうとする対象によってではないかな。

419:デフォルトの名無しさん
18/05/04 22:10:23.06 VQ//CMaE.net
「設定より規約」で複雑な設定を不要にするために規約で縛って単純にすることはある
最適化とは関係ない

420:デフォルトの名無しさん
18/05/04 22:27:54.24 U2Bct8CT.net
>>413
全然レイヤが違うぞ…はぁ

421:デフォルトの名無しさん
18/05/04 22:29:07.68 /D8HsFql.net
もういいや

422:デフォルトの名無しさん
18/05/05 00:07:46.07 3M7DBZHK.net
>>414
全然違うレイヤでしか評価されない概念だからね
型宣言を省略して単純にした言語はあまり評価されない
だからC++のように複雑な言語がずっと勝ち続ける

423:デフォルトの名無しさん
18/05/05 09:26:04.08 0zR7mPRl.net
言語レベルでは縛りを減らして、ツールもしくはプロジェクト毎の規約で矯正する方が成功してる印象。

424:デフォルトの名無しさん
18/05/05 12:36:15.72 Ptn/YTVe.net
Ruby使いはなんでもRails基準で話するから困惑させられるわ。
規約で縛るのと、設定させるのはまた別の次元の話な気がする。
規約で縛った上でさらに明示的に設定させるなんて思想もあるし、
明示的に設定すること、と言う一文すら大きく捉えたら「規約」だと思うんだが。
misra然り、規約で担保される部分も否定はしないけど、
そんなこと考えなくても言語レベルで無茶は出来ないってのは、結構有益だと思うよ。
goが他の言語だと警告で済ますものをコンパイルエラーにしてたりとか。

425:デフォルトの名無しさん
18/05/05 14:40:21.15 0zR7mPRl.net
それはわかる。
ただ「言語レベルで無茶させない」機能を実装するために「言語実装が無茶してる」
っていう本末転倒レベルのコンパイラが増えてる。

426:デフォルトの名無しさん
18/05/05 14:54:28.61 fkw9D7UX.net
何かを実装しやすくする為の機能、とバグを減らすための安全装置としての機能、と分類した時に後者が気に入らんて訳だな。
古いタイプのハカー思想的にはそうだろうね。
まあでも人間にコード書かせてる内は後者を充実させて行くしか無いでしょう。

427:デフォルトの名無しさん
18/05/05 17:40:15.09 wfyrkg3u.net
バグを減らすための機能はコードを書きやすくするための機能でもあって欲しい。Fortranはその辺のバランス感覚が地味に良い

428:デフォルトの名無しさん
18/05/05 18:31:47.37 sJdk0i7H.net
[][][] [[[ ] X_[[[ [] ][ [] ][][[[]

429:デフォルトの名無しさん
18/05/05 22:21:49.30 g4wn0nIy.net
このスレ的にDart 2はどうなの？

430:デフォルトの名無しさん
18/05/05 22:28:11.15 J0iT62yj.net
>>423
哀れな水子霊
供養してあげよう

431:デフォルトの名無しさん
18/05/06 11:13:25.80 UdK4FK7I.net
>>420
半分だけはその通り。
ただセキュリティーについても結局は効率や速度を要求されるからって話なんだよ。
安全のためにって効率を落とすようなルールを作っておいて
ノルマは下げないみたいな現場ではセキュリティーホールつくようなハックが流行るってこと。
ルールを厳しくして逆に流出なんてパターンは結局これ。

432:デフォルトの名無しさん
18/05/06 11:29:16.72 EZJKrplU.net
悪事の限りを尽くしてきたサイコパスが
効率悪化だけは許さない真面目キャラになるのなんでだろう

433:デフォルトの名無しさん
18/05/06 12:54:13.10 BpvGgdyJ.net
安全性重視と言えば聞こえはいいが
やってることはWarningをErrorにしてるだけだからな

434:デフォルトの名無しさん
18/05/06 13:00:40.56 5SuvHbqD.net
>>427
明確にエラーなら、それを前提にした最適化ができる

435:デフォルトの名無しさん
18/05/06 13:12:21.81 4/stHYd4.net
まあ正直Worningでいいとは思う

436:デフォルトの名無しさん
18/05/06 13:18:55.75 +3dRclkW.net
>>425
unsafeなりなんなりあるかと。
効率や速度というのは、安定動作している事が確実に出来てからやっとテーブルに上げることができる話題であって、
それで落ちる効率なんてのは最初からサボってた証拠とみなす方が多いかと思うよ。
ルールを厳しくして結局流出ってのは、また別の尺度かと。
流出したとしても、それは理由もはっきりさせられるし、なによりソフトウエアの瑕疵ではなくて運用の問題の話になってくる。

437:デフォルトの名無しさん
18/05/06 14:32:39.98 7acvvhvM.net
セキュリティーについての効率化云々とか、半可通だなあとしか言えんわ…

438:デフォルトの名無しさん
18/05/06 15:54:07.22 cxBuJYdg.net
レイヤの上書きし続けるのやめろ

439:デフォルトの名無しさん
18/05/06 15:58:41.42 +3dRclkW.net
いくらコンパイラが怒らないからと言え、セキュリティーホールを突くようなハックとやらをしてたら流石にコードレビューではねるんじゃね？
どういうコードかイマイチ想像がついてないけど。
インラインアセンブラが禁止されてるからハンドアセンブルしたコードか入ってるconst char[]を無理矢理呼び出すとかかな。
単純にそのプロジェクトで使ってる静的解析が誤認するようにコードを書く事を、静的解析のセキュリティーホールと勘違いしてるのか、
それとも、バッファオーバーランしないようにするにあたって、根本的に長さを指定できる関数を使わずに付け焼き刃でバッファにクソ長い配列使うみたいなコードなのか(でもこれは静的解析で怒られそう)
一体何が、コーディングの上でセキュリティーホールを突くようなハックなんだろう？
ピアレビューがあれば瞬殺されて終わりな気もするし。

440:デフォルトの名無しさん
18/05/06 16:29:24.39 3zhAqmJH.net
>>421
Fortranって現役なんか？聞いたことないが

441:デフォルトの名無しさん
18/05/06 16:32:16.64 YMV7ENjt.net
>>434
現役だよ

442:デフォルトの名無しさん
18/05/06 16:36:08.57 T0X5noxd.net
スパコンでは現役。計算物理屋とかFORTRANしか書けないおっさんも居るしね。
まあ数値計算系のコード書いてる連中なんてgitも知らなかったりするレベルで
超絶的に遅れてるから意見なんて無視していいよ

443:デフォルトの名無しさん
18/05/06 16:41:56.05 4/stHYd4.net
>>434
現役かと言われたら、現状数値解析以外では老害しか使っとらん感じで口ごもっちゃうけど、そんな状況に反して最新の言語仕様は結構いい。そして老害はFortranの良い仕様は使っとらん
ある意味逆に次世代言語感あると思う

444:デフォルトの名無しさん
18/05/06 17:13:53.77 +3dRclkW.net
ベンダーがきっちり面倒見てるのも大きいわな。Fortranは。
老害と呼ばれるコードが生き残れるのも、新しいものがサポートされていくのも。

445:デフォルトの名無しさん
18/05/06 18:05:19.44 4/stHYd4.net
まあ新しいもののサポートは遅いがな

446:デフォルトの名無しさん
18/05/06 18:53:07.67 UdK4FK7I.net
まあ運用の問題と言えばそうだけどね。
実際どこぞのrustコードなんて結局unsafe丸がこみコードになってるって話だよ。
レビュアーがまともならってのもその通りだが
P○zyさんとことか有名どこでもそんなもんですよ。

447:デフォルトの名無しさん
18/05/06 19:31:39.25 9CUhRDV/.net
}]] [[《_["[[]]" 〈[]》》 [][][]0,1》》〈〉 [] } } "B,V,0%%%,*1BVLO,SASA1`}}//%\\0,1\"VL"\

448:デフォルトの名無しさん
18/05/07 12:03:19.49 Go6Qgpic.net
>>440
そのP○zyさんのコードはどこで見れるの？

449:デフォルトの名無しさん
18/05/07 17:37:45.62 aRQ7vpNn.net
Fortran現役ってすげーな。
なんか便利な構文あるの？
スペースがなくても構文が認識するって凄いね。何というか分野によって現役だったりするし、web系とか組み込み系とか分野毎に次世代を考えたほうが良いのかも

450:デフォルトの名無しさん
18/05/07 18:29:43.67 Si7Pqr9d.net
数値計算の新しいアルゴリズムってあるの？

動画の圧縮とかだったらどんどん新しくなってるけど

451:デフォルトの名無しさん
18/05/07 18:42:27.46 4LWU/9Ql.net
アルゴリズムというよりは非プログラマが数学物理をプログラムに落とし込みやすいって所じゃないか？
統計メインの生物系なんかはもうRやPythonに移ってるけど

452:デフォルトの名無しさん
18/05/07 21:30:21.40 u0xzmUnv.net
>>443
まあ、分野についての言及は必要だろうね。

453:デフォルトの名無しさん
18/05/07 22:27:02.76 9toRjaak.net
よし、じゃあワシがwebの代表として次世代言語はrustであることをここに宣言しよう

454:デフォルトの名無しさん
18/05/07 23:32:28.33 b+1hN3YL.net
今phpのlaravelしててミドルウェアとかバリデーションとかルーターとかマイグレーションとか
それ自体はフレームワークの機能なんだけど言語仕様としても使えそうなのがチラホラあるけど
こういうの言語に使われることないんかな？

455:デフォルトの名無しさん
18/05/07 23:45:44.05 eqjeSWEf.net
>442
はいよ
URLﾘﾝｸ(tan)

456:akh.jp/posts/2016-12-20-rust-pezy-sc.html

457:デフォルトの名無しさん
18/05/08 00:32:28.71 kgnxB5OH.net
一元論が無理なら八百万って極端すぎる
二刀流くらいがちょうどいい

458:デフォルトの名無しさん
18/05/08 07:49:53.07 BTpaOhWg.net
C++の置き換え言語としてRustには期待している。ただ構文がなんかうっとうしいなあ。
ruby風のラムダは気に入ってるが。

459:デフォルトの名無しさん
18/05/08 08:43:30.21 lO+5Uui0.net
>>445
Numpy相当のベクトル記述が出来るたった一つのコンパイル言語。それがFortran

460:デフォルトの名無しさん
18/05/08 10:01:01.47 JvzvEXdE.net
>>452
確かにあれは書きやすいし速い
GPGPUでの(それをラップしたライブラリでの)行列演算に対するアドバンテージって何かあるのか？
分岐がモリモリ入ってくる場合くらいしか思いつかないが

461:デフォルトの名無しさん
18/05/08 13:34:11.30 k5VrHriK.net
>>453
なんのことを指しているんだ？

462:デフォルトの名無しさん
18/05/08 17:08:07.13 I+Jt0Kav.net
>>452
現実のFortranプログラミングは大量に宣言したスカラー配列を添字でゴリゴリ回すだけだけどな
行列やベクトルの演算のセマンティクスなんか一切残らん

463:デフォルトの名無しさん
18/05/09 01:16:05.28 PEulJP5b.net
haskellの方がCより速いってさ
URLﾘﾝｸ(superstrings.io)

464:デフォルトの名無しさん
18/05/09 02:14:38.03 0YDcqAhS.net
>>456
URLﾘﾝｸ(superstrings.io)

465:デフォルトの名無しさん
18/05/09 02:26:18.12 bn/AH8fd.net
なんですぐばれるウソをつくのだろう？

466:デフォルトの名無しさん
18/05/09 02:35:21.53 hrOQbIqv.net
>>457
すばらしいね。
Cのコードに
__attribute__((optimize("unroll-loops")))
付けると100倍早いけどw
あと、手元の環境で gcc は何故か -O だけunroll付けたのと同様に早くて　-O2 以上は遅かった。
バグと言うべきなのかな。

467:デフォルトの名無しさん
18/05/09 03:11:33.85 0bpmHxx0.net
>>453
コンパイラのやる気さえあれば、ライブラリでは不可能な最適化なんていくらでもでできるだろ
実際にやってるかはしらん

468:デフォルトの名無しさん
18/05/09 07:10:29.94 UxragvBK.net
乱数生成が遅いってどこかで見たような、Haskell

469:デフォルトの名無しさん
18/05/09 07:59:31.19 2PdkdhLd.net
>>461
それって言語の問題ではなくコンパイラの実装の問題？
それとも言語仕様として計算量の大きい生成アルゴリズムが規定されてたりするんだっけ？

470:デフォルトの名無しさん
18/05/09 08:01:55.30 2PdkdhLd.net
あ、ごめん。ライブラリの乱数生成の関数を呼んだらということかと思ったけど、自分で乱数生成の処理を書いたらということかな。

471:デフォルトの名無しさん
18/05/09 08:15:55.42 UxragvBK.net
>>463
ごめん、そこまで詳しくないので、誰か補足を。記憶だと前者だったかな。

472:デフォルトの名無しさん
18/05/09 08:17:13.45 yFt+gB3J.net
URLﾘﾝｸ(qiita.com)
この辺の話？

473:デフォルトの名無しさん
18/05/09 09:54:11.86 X/W01mab.net
>>458
せっかくコンパイラ作ったんだからみたいな貧乏性だな
一方、富豪的プログラマはインタプリタを使う

474:デフォルトの名無しさん
18/05/09 21:36:31.89 AJJ2h/PO.net
なんか知らんが定期的にCより速いって話が出てくるな。
高級かつランタイム速度が落ちないってなんかおかしいとか思わないもんなのかな。

475:デフォルトの名無しさん
18/05/09 22:20:41.60 dqSR3cl1.net
さ、最適化をダイナミックに出来るから……

476:デフォルトの名無しさん
18/05/09 23:00:53.08 hrOQbIqv.net
理想を追求

477:する精神は忘れなくて良いやろ

478:デフォルトの名無しさん
18/05/10 02:12:17.66 FhKx4uhS.net
高級品だと遅くなるならC++がCより速くなることはないんだろうなあ
フムフム

479:デフォルトの名無しさん
18/05/10 08:10:24.35 WcF1ShgP.net
実際、もしもコードを書く人がコンパイラを書いた人よりも賢いならばCの方が早速いｗｗ

480:デフォルトの名無しさん
18/05/10 09:54:42.57 +xjpfXr5.net
コンパイラの最適化能力的には今でもFortranが頭ひとつ抜けてるんだっけ

481:デフォルトの名無しさん
18/05/10 10:07:40.42 sqBEyANZ.net
async awaitの存在のお陰でTypeScriptが使いやすさで一歩先言ってる感あるな。
VasualStudioでもサポートしてるんだよね。mac版試してみたい

482:デフォルトの名無しさん
18/05/10 15:49:44.61 TSTj28YJ.net
>>472
どうせバックエンド同じなので、C言語でもpragmaとattribute駆使すればFortranと同じになるはず

483:デフォルトの名無しさん
18/05/10 16:11:32.31 gErYAeAK.net
>>474
しんどー

484:デフォルトの名無しさん
18/05/10 16:20:28.17 VgJxGkPJ.net
rebuildfmで聞いたがswiftは機械学習との親和性を高める方向でラトナーは頑張ってるみたいね。

485:デフォルトの名無しさん
18/05/11 00:25:42.85 ew48BEmx.net
にむにむ

486:デフォルトの名無しさん
18/05/11 11:38:41.21 Bitu5gZ+.net
フォートランはスタックフレームを使わないから早いらしい

487:デフォルトの名無しさん
18/05/11 19:21:18.09 BkhZdaXW.net
>>467
昔々 Java の方が C++ より速いなんて話もあった。
JIT で速くなるとか。
しかしC++だったとしてもややこしい機能を使わずC言語風に作って最適化掛かったらお終いのような気がしてならない。

488:デフォルトの名無しさん
18/05/11 20:24:29.02 ew48BEmx.net
Cはポインタが自由すぎて最適化難しいとはよく聞く

489:デフォルトの名無しさん
18/05/11 21:16:38.36 mlwOVON7.net
Javaの場合はいくら局所的に速くなっても、JITそのものにかかる時間だったり
あるいは膨大なロード時間を計測に含めてしまうと台無しだからなあ
もちろん速いとアピールしたいベンチマークではその辺が含まれないようにするし
遅いとアピールしたい場合は

490:デフォルトの名無しさん
18/05/11 21:22:37.76 RZoOPILo.net
どっちかというとマルチコアを活かした最適化って人間が頑張るしかないんじゃないかな。
だからgoでgoroutineとか、
関数型言語推しになるんでわ

491:デフォルトの名無しさん
18/05/11 21:41:43.97 rzT1F5bb.net
>>481
javaに限らずインタプリタ系も起動時間含めて time で測ってドヤってる　Qiita の記事とか消滅して欲しい

492:デフォルトの名無しさん
18/05/11 21:43:50.20 bSh0JSQF.net
>>480
ポインタをintやchar*に変換する自由を利用してFFIのようなものを作れるよ
自由にCを呼び出すことで他言語が速くなる

493:デフォルトの名無しさん
18/05/11 22:13:19.06 ew48BEmx.net
>>484
なぜその内容で>>480に安価つけるし

494:デフォルトの名無しさん
18/05/11 23:06:50.43 bSh0JSQF.net
>>485
内容に問題はないので、わからないなら自分で考えるか質問を変えてみてはどうかな

495:デフォルトの名無しさん
18/05/11 23:15:21.11 mlwOVON7.net
>>484の意図(自由過ぎるポインタにはメリットもあるよ)もわかるし
>>485の反応(最適化の話題から逸れてるだろ)もわかるんだけど
正直>>486はぞっとするほど怖い。なんだろうこの不気味な感じは

496:デフォルトの名無しさん
18/05/11 23:16:13.67 ew48BEmx.net
なんやこいつ。
まあええわこのスレには会話通じんやつがおるみたいやし時間の無駄やわ。深く考えんとこ

497:デフォルトの名無しさん
18/05/11 23:19:46.30 KxM4SNOx.net
>>487
>>484からその意図を読み取れるのはすげー行間把握力だと思うわ
>>486が怖いのは同意

498:デフォルトの名無しさん
18/05/11 23:20:50.68 bSh0JSQF.net
「不気味罪という罪はない」とか言われたらゾッとするかもしれないが
そういうことを平気で言う奴は今の世の中にはいっぱいいるな

499:デフォルトの名無しさん
18/05/11 23:24:44.89 ew48BEmx.net
この感じどうせまた例のADHDやろ。つついてもうたことを後悔してるわ

500:デフォルトの名無しさん
18/05/11 23:25:19.88 cXvpx1C3.net
>>480

501:デフォルトの名無しさん
18/05/11 23:30:08.91 cXvpx1C3.net
>>480 はコンパイラの最適化を受けての発言でいわゆるaliasの問題の
ことを言っていると思われる
で >>484 はコンパイラ関係ないFFIを持ち出してしったかをかます
で >>485 がもっともなツッコミ
で >>486 で上から目線で地面見てドやる
→キモイ
まとめてみました

502:デフォルトの名無しさん
18/05/12 00:31:38.38 5NKz3ewG.net
C / C++ はとりあえず OpenMP 相当のものを標準化して実装して欲しいわ
他の言語よりクライアント側で使うこと多いから１つ１つの処理もスケールさせたい

503:デフォルトの名無しさん
18/05/12 00:39:55.31 ioGXghPg.net
アルゴリズム変える以外に速くする方法なんてのは
結局倉庫番を上手く解くって話にしかならんわ。

504:デフォルトの名無しさん
18/05/12 00:48:56.95 R/twbybb.net
？？
それアルゴリズムでは？

505:デフォルトの名無しさん
18/05/12 00:52:27.47 F3K2afGN.net
あーもうめちゃくちゃだよ

506:デフォルトの名無しさん
18/05/12 01:03:23.63 +7qwtmL0.net
なんかgoogle ioでwasmからdom操作できるようになるって話があったらしい。

507:デフォルトの名無しさん
18/05/12 01:04:46.62 iFoVhrV3.net
地獄の始まりじゃないでしょうね（震え）

508:デフォルトの名無しさん
18/05/12 01:13:51.18 8RYDCDzW.net
みんなアルゴリズムよりむしろデータ構造を変えたがる
CのポインタもJSのdomもデータ構造だろう
でもデータ構造を変えるのは速くするのが目的とは言ってないかも

509:デフォルトの名無しさん
18/05/12 01:38:25.14 5NKz3ewG.net
>>457
>On Xeon Thinkpad P50 with Ubuntu, compiled with gcc -O3 this runs about 15.3 ms ― more than 20% slower than haskell!
あんまり関係ないが
3年前のレッツノートRZ4の最下位モデル、
Core M-5Y10 ベースクロック0.8GHz で
Visual Srudio 2017 でコンパイルしたバイナリも
ちょうど 15.3ms だわ
2コア4スレッドのcpuなので openmp で 4並列にしたら5.7ms

510:デフォルトの名無しさん
18/05/12 08:55:56.45 ioGXghPg.net
>>496
いやメモリやレジスタにデータやコードを載せるタイミングの話なんだが。
「アルゴリズム」はもう少しソフトなレイヤーを指したつもり。

511:デフォルトの名無しさん
18/05/12 10:24:39.71 LrYQoKex.net
>>501
最適化上手く行けば0.2ｍｓぐらいになると思うで
i5-3550 で 0.08ms

512:デフォルトの名無しさん
18/05/12 10:28:01.57 LrYQoKex.net
>>498
reactが早くなるってか。
ようやく90年代のクラサバに追いつくなw

513:デフォルトの名無しさん
18/05/12 10:32:35.98 TkoJoFTb.net
GoogleはSUNと同じ愚を犯してるように見える。

514:デフォルトの名無しさん
18/05/12 10:34:13.54 NuxM0Gnx.net
wasmのDOM実装は最初からロードマップに入ってる

515:デフォルトの名無しさん
18/05/12 10:46:00.14 +7qwtmL0.net
jsの出番が減るのか最近の仕様は好きなんだけどな。typescriptが直接wasm吐くようになってほしい

516:デフォルトの名無しさん
18/05/12 10:47:42.87 +7qwtmL0.net
>>505
sunはコンテナーをいち早く実現してたり
zfs出したり、先進的な企業だったよな。金が稼げなか

517:ったけど。 googleは金があるから問題ない

518:デフォルトの名無しさん
18/05/12 10:52:24.71 15xgRckc.net
>>507
Blazorに期待してる

519:デフォルトの名無しさん
18/05/12 10:55:45.44 Wuy9HJPF.net
JavaScriptからwasmへのコンパイルができるようになったら普及は速いんだろうけど、いつになるかなぁ。
そのころにはwasmのエコシステムも十分整備されてそう。

520:デフォルトの名無しさん
18/05/12 11:01:20.26 NuxM0Gnx.net
>>507
各種apiのリファレンス実装として続いてくんじゃないかとは思ってる
正直TS→wasmは期待しちゃうよね

521:デフォルトの名無しさん
18/05/12 11:13:10.47 +7qwtmL0.net
rustでwasm吐くとdom操作もメモリ効率が良い感じになるのだろうか。
個人的にはgoで全部できるようになりそうで嬉しい。
meteor.jsというのがあってね。コンセプト的にすごく良かったんだけどエコシステムがいろいろ終わってた。wasmでもう一度復活するかも

522:デフォルトの名無しさん
18/05/12 11:31:33.64 Gv6T+VfX.net
Rustでブラウザ本体を書き直す動きがJSの部分にまで広がる
ブラウザを作れない言語には速い遅いという以前の問題がある

523:デフォルトの名無しさん
18/05/12 13:14:14.79 LrYQoKex.net
>>508
思い出は美化されるね。
不便なコマンド、SysV系転向、長いことジャーナリング無し、ftpのlsがユーザのロケールでパース困難、NFSの進歩の遅さ、etc
罪を数えたらキリが無いよ

524:デフォルトの名無しさん
18/05/12 13:53:25.93 Douv0h4u.net
>>491
なんでも俺のせいにすなw

525:デフォルトの名無しさん
18/05/12 14:06:23.00 Gv6T+VfX.net
よかった、透視能力なんてなかったんだ

526:デフォルトの名無しさん
18/05/12 14:10:21.47 TkoJoFTb.net
>>508
SUNは我田引水に失敗して凋落したのだ。
自社の高価な機器を売るためにメモリーイーターな言語を広めたり、自社の機器以外では性能が発揮できないように互換環境を禁止したり。

527:デフォルトの名無しさん
18/05/12 14:13:17.43 TkoJoFTb.net
Googleは現在我田引水のため色々やってるが、消費者にとっては良いことは何もない。
吉と出るか凶と出るか。
一方、MSは戦場から早々に離脱したので、不戦敗となるのか、勝ちもしないが負けもしないのか。

528:デフォルトの名無しさん
18/05/12 17:45:08.76 5NKz3ewG.net
>>503
dot関数自体の最適化はほぼ完璧に行われています
gcc だと 100 回繰り返してるところを1度で済ます
最適化が起きてるだけでは？
速度もちょうど100倍だし。
そうじゃないと
>i5-3550 で 0.08ms
1G回の積和を0.08msで完了ということは毎秒125Gの積和を実行したことになりますから、
演算性能は125GFlopsメモリ帯域は1000GB/sになる (←あり得ない)

529:デフォルトの名無しさん
18/05/12 17:51:25.31 5NKz3ewG.net
最後の計算間違ってるか
結果はあってるけど10M個の積和を0.08ms、という計算か。

530:デフォルトの名無しさん
18/05/12 18:44:38.63 LrYQoKex.net
>>519
ああ、確かに。引数変わらないから１００回ループが１回に省略されてるな…

531:デフォルトの名無しさん
18/05/13 08:36:01.91 JK3lyAGE.net
Cはハスケルの１００倍はやかったってこと？

532:デフォルトの名無しさん
18/05/13 11:23:16.33 LKCtUx3M.net
GCのベンチマークって無いのかな
一番速いのはGo言語？

533:デフォルトの名無しさん
18/05/13 11:26:00.88 X0FozZBp.net
Rustってcと比べて機能てんこ盛りなのに同等の速度で実行できるって何でなの？

534:デフォルトの名無しさん
18/05/13 11:46:40.60 JUfYpDRX.net
別に機能が多いかどうかは関係ない。
速度を出すための設定を細かくできるかどうか。
細かく設定するってことはそれだけ手間がかかるってこと。

535:デフォルトの名無しさん
18/05/13 12:03:30.51 1GQ1TBB+.net
整数とポインタの見分けがつかない

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

537:デフォルトの名無しさん
18/05/13 13:34:16.59 NXXuYZ+p.net
>>526
これ重要やな

538:デフォルトの名無しさん
18/05/13 15:12:37.68 JK3lyAGE.net
>>457
のCのコードみたけどぎょれつ演算にブロック化してないからキャッシュミスが
多くなって遅くなってるだけだな。
ハスケルは自動でメモリーの最適化してるからはやいだけだな。

539:デフォルトの名無しさん
18/05/13 15:18:09.79 Xeb1zMif.net
dot product計算するだけのマイクロベンチなんか言語比較として無意味

540:デフォルトの名無しさん
18/05/13 15:34:14.94 NXXuYZ+p.net
>>528
へえ。ハスケル意外と有能やん

541:デフォルトの名無しさん
18/05/13 15:50:11.19 bgY0d3zI.net
デタラメ言ってるだけだぞw
このスレの連中はホント騙されやすいな

542:デフォルトの名無しさん
18/05/13 16:00:43.94 bgY0d3zI.net
1次元のリニアなメモリをシーケンシャルに読むだけなのにブロック化とか
ここは物事の真偽もわからない初学者の集まりなんだからデタラメで混乱させるなよ
検証できることはちゃんと検証してから発言しよう

543:デフォルトの名無しさん
18/05/13 16:15:28.33 NXXuYZ+p.net
うわマジやん糞かよ死ねや

544:デフォルトの名無しさん
18/05/13 16:24:23.38 1GQ1TBB+.net
でも検証にはコストがあるからな
お前は嘘つきだと宣戦布告して戦争か裁判をやって勝つまでが検証です

545:デフォルトの名無しさん
18/05/13 17:28:06.32 JK3lyAGE.net
xとy別々の配列じゃなくて
x0y0x1y1x2....のように並べるってことだよ。
そうするとメモリーアクセスが早くなる。

546:デフォルトの名無しさん
18/05/13 18:40:55.81 bgY0d3zI.net
>>535
コード読めよ
xとx掛けてるんだぞ

547:デフォルトの名無しさん
18/05/13 21:55:04.60 MDWbrDHx.net
検証もせずに適当に推測するが
>>457のHaskellの方がCより速いというのはループを1回で済ます最適化がされた結果であって、
1ループあたりの実際の速度はCの1/80の速度なのかもね

548:デフォルトの名無しさん
18/05/13 23:16:22.73 aRNPCfaw.net
Haskellが早いと言うかHaskellだと早く出来ることがあるって感じだろ

549:デフォルトの名無しさん
18/05/13 23:53:00.06 eikXWKbu.net
そりゃそうだろ
言語によって得意な処理は違うし、プログラマの実力によっても変わる
数値計算に限定すればjuliaは手軽に書けて尚且つ実行速度も速かったりする
バカが書いたCのコードより天才が書いたHaskellのコードのほうが(多分)速い
言語の速度だけ比較してあーだこーだ言う前に
各言語に関する詳細な知識とコーディングの実力を身に着けるべし

550:デフォルトの名無しさん
18/05/14 00:07:25.34 NNbrsR8u.net
SEYANA

551:デフォルトの名無しさん
18/05/14 06:12:40.31 Hm1IiEDM.net
ドット積のような簡単な計算ならCPUの処理速度が速すぎて
メモリー転送速度がボトルネックになることは明らかだしな。
ハスケルの場合、ランダムな数値をメモリーに記録することなく
オンザフライで計算したのかもしれないな。

552:デフォルトの名無しさん
18/05/14 07:36:06.84 P8BYP3+b.net
ドット積が律速になることってある？

553:デフォルトの名無しさん
18/05/14 07:59:32.34 WfY57EXm.net
バイナリサイズも気になるけど。
と言うか、速い遅いはあんまり簡単に割り切るわけにいかんし、
推測より実測は確かだけど、その前に何を実測してるのか、
大体どれぐらいになるかをもう少し予測したほうがいいと思うんだけどな。
こういう小さい関数単位のベンチは特に。
最新の処理系は両方持ってないから俺出来ないけど、ネイティブコード比べたほうが良いのでは？
gccは(いろんな意味で)信じられない最適化かかってる事あるし。

554:デフォルトの名無しさん
18/05/14 08:36:31.93 zbYXMED5.net
>>542
HPCならなくはないけど、その場合は手計算で展開して前後の計算も含めたもっと大きなドメインで最適化するわな
単独でdotだけの最適化なんて、自分の息子を気持ちよくする以上の意味はない

555:デフォルトの名無しさん
18/05/14 13:14:41.23 0aBfdvZZ.net
C++の定数式を使う。

556:デフォルトの名無しさん
18/05/14 17:04:14.47 ar4V5qZH.net
>>539
そういう話でしかないからそういう話だという指摘をしたんだろ

557:デフォルトの名無しさん
18/05/14 18:11:35.62 kUkLIG4O.net
SEYANA

558:デフォルトの名無しさん
18/05/15 07:41:24.21 cBszxXz8.net
ハード的なことは自分はよう知らんが、純粋関数のみで書いたところは、筋の良い関数への置き換えが利いてくれる、てことなのだろう。
知る限りだと、map、fold、filter、zipみたいな基礎的な高階関数と、配列更新はupdate関数を使っとけばその辺が勝手にかかるみたい。
>>457の例は、sumはfoldで、zipWithはzipとmap。
速度ガチ勢は満足しないだろうが、宣言的にやってる割に速度を出したければ、この辺りを気をつけてれば良い印象。
逆に気をつけないと、相当遅い。LazyとStrictも気をつける必要がある。

559:デフォルトの名無しさん
18/05/15 09:00:25.93 ykJK+It6.net
これはhaskellじゃなくて理系がバカなんだ
文系がhaskellを勉強しても速度のことなんて考えないだろう

560:デフォルトの名無しさん
18/05/15 15:12:17.78 +IcyTYky.net
このスレは何を議論するスレなんだ

561:デフォルトの名無しさん
18/05/15 15:24:27.98 RQo6Vb+e.net
雑段するぞ

562:デフォルトの名無しさん
18/05/15 18:37:20.71 3hgL0M2i.net
SOYANA

563:デフォルトの名無しさん
18/05/15 19:24:43.54 0x8zM7pd.net
>>550
次世代言語と言えば関数型、関数型と言えばHaskell、ホルホルホル。

564:デフォルトの名無しさん
18/05/15 19:50:21.10 dt28ByE7.net
>>549
理系が馬鹿ってことは文系が頭いいってこと？そんなバカな

565:デフォルトの名無しさん
18/05/15 20:03:43.73 TjuX/LAp.net
先入観は可能を不可能にするって二刀流の人が言ってた

566:デフォルトの名無しさん
18/05/15 20:20:31.80 maavPO86.net
このご時世理系文系なんて言ってるのもどうかと思うがね

567:デフォルトの名無しさん
18/05/15 21:18:11.07 +IcyTYky.net
>>553
くっさ。流石にそういう返答は求めとらん。性格悪すぎか

568:デフォルトの名無しさん
18/05/15 22:06:27.79 cAjQsfjh.net
理系文系で語る奴にはろくなものがイないはず
ソースは川上

569:デフォルトの名無しさん
18/05/15 22:38:41.36 TjuX/LAp.net
そのろくでなしを討ち取るか逃げ切られるか確定してないソースにはあまり意味がない

570:デフォルトの名無しさん
18/05/16 00:35:59.84 y71KiaeG.net
はてな民の悪口はやめロッテ

571:デフォルトの名無しさん
18/05/16 04:13:18.32 /r6FU1qw.net
>>548
加えて >>457 には left fold にしとかないと遅いよとある
理由はあまりに明白だからか触れられていないけど
ここはあまり実践に拘る人いないからわりとどうでもいいか

572:デフォルトの名無しさん
18/05/16 06:37:06.57 wZFh8fJh.net
コンパイル時と実行時で語る奴は速いよ
OOPと関数型で語る奴にはろくなものがいない

573:デフォルトの名無しさん
18/05/16 06:47:58.51 OmXLSXyH.net
LazyかStrictかってな。評価戦略も考えてかなならん。
まあ、Haskellも使いこなすには、それなりの背景知識がないとあかんという事だね。

574:デフォルトの名無しさん
18/05/16 07:09:06.16 wZFh8fJh.net
lazyは無限の計算を打ち切る
遅い計算をちょっと速くするだけの最適化とは次元が違う

575:デフォルトの名無しさん
18/05/16 07:20:15.91 mOBIQo/B.net
>>562
これは同意かな。
結局抽象論でドヤるの好きなだけなやつってのは
実測を嫌う傾向にあるから問題を引き起こす。

576:デフォルトの名無しさん
18/05/16 07:35:27.07 /r6FU1qw.net
>>564
初めから無限の計算をしないように書いた方が多くの場合(ずっと)速いのでないかみたいな話だろ

577:デフォルトの名無しさん
18/05/16 07:51:39.34 R9tYk9Qj.net
そんなlazy全否定するような話題だったのか

578:デフォルトの名無しさん
18/05/16 07:55:55.64 wZFh8fJh.net
そういう話題だったら初めからそう言えばいいのに
現実的には後出しが便利だから後出ししてる
現実を実測しよう

579:デフォルトの名無しさん
18/05/16 08:00:59.77 9/p4w1/n.net
いや後出しも何も>>457のブログにlazy遅いよねとか書いてあってそれについて話してるわけだし…

580:デフォルトの名無しさん
18/05/16 08:02:16.32 9/p4w1/n.net
と俺は思ってたんだが違うのか？

581:デフォルトの名無しさん
18/05/16 08:23:21.13 OmXLSXyH.net
あってるよ。

582:デフォルトの名無しさん
18/05/16 08:30:32.29 SZWziQ/v.net
もう少し真剣に考えてもいいんじゃないか？
誰も最適化が完璧に行われてる、の追試しないの？
ghcの最適化結果のバイナリをgdbで眺めるだけでも全然違うと思うが。
俺がやるとおま環でオラつくなとか言われるの目に見えてるから静観してるけどさ。

583:デフォルトの名無しさん
18/05/16 09:41:30.81 L2yt4rd4.net
お前の静観ってうるさいのなｗ

584:デフォルトの名無しさん
18/05/16 09:50:51.21 +AvdAm/t.net
例がクソすぎて正直興味わかない

585:デフォルトの名無しさん
18/05/16 09:51:48.57 ub+CyxOt.net
>>573
やめたれｗ

586:デフォルトの名無しさん
18/05/16 10:11:53.73 +AvdAm/t.net
これ正味のところコンパイラのバックエンドの性能比較にしかなってないし、
その差も最適化オプションの違いと想像できる範囲だもの

587:デフォルトの名無しさん
18/05/16 15:45:52.24 f5OfgQEL.net
うーん、だったら異なる言語の速度比較に説得力を持たせるためには、どんなルールを定めればいいの？

588:デフォルトの名無しさん
18/05/16 16:15:52.78 w3xM0aVb.net
お題を設定して、そのお題を解く実行速度でも競えば

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

590:デフォルトの名無しさん
18/05/16 17:35:38.66 JOa7NyYz.net
問題の難度が低すぎるから早押しクイズになってしまう
正解者が1名いるかいないかの難問なら速度はどうでもいいだろ

591:デフォルトの名無しさん
18/05/16 17:54:36.37 bvYagxcd.net
>>579
いや、そもそもソースを1つに限定しようとするのがダメだと思う
読みやすい(一般的な)コードと最適化を前提としたコードの両方を用意する
そうすれば両方のケースで比較できるようになる
あと、その任意の問題とやらも複数ケース用意する必要があるだろうな…
面倒臭いけどそれがベストだと思う

592:デフォルトの名無しさん
18/05/16 18:10:24.62 JOa7NyYz.net
>バカが書いたCのコードより天才が書いたHaskellのコードのほうが(多分)速い
一方ロシアは天才が書いたCのコードを用意した

593:デフォルトの名無しさん
18/05/16 18:51:37.22 w3xM0aVb.net
>>580
ある種の難問を解きやすいのが関数型言語のウリのはずだし、それはそれで一つの結果じゃない？

594:デフォルトの名無しさん
18/05/16 19:03:04.49 mn6BTyTm.net
それはそれとして
個人的に>>457の確認をしてみたいのだけど、
どんな main 書けばいいのか誰か教えてくれないか？
ghc -O2 で下記のようなコードをコンパイルすると
一切メモリ使わずレジスタだけで0.1ずつ増加させた数を積和していくからテストにならないし、
10M個の積和を100回実行するところも1回に省略される気しかしない…
URLﾘﾝｸ(ideone.com)
module Main (main) where
import Prelude hiding (sum, length, zipWith, map)
import System.Environment (getArgs)
import

595: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

596:デフォルトの名無しさん
18/05/16 19:11:48.70 mn6BTyTm.net
いやごめん
Haskell スレで聞いてみます

597:デフォルトの名無しさん
18/05/16 19:50:33.80 mn6BTyTm.net
せっかくだから一応貼っておくと 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

598:デフォルトの名無しさん
18/05/16 19:58:05.30 ub+CyxOt.net
ソースコードより短いのは流石に草

599:デフォルトの名無しさん
18/05/16 21:37:36.10 JOa7NyYz.net
これO(1)じゃなくてO(n)だけど速いのか？
聞くは一時の恥、聞かぬは一生の恥

600:デフォルトの名無しさん
18/05/16 21:40:07.47 ub+CyxOt.net
O(1)になるまで最適化って、それ1/6公式使わないと無理じゃね？

601:デフォルトの名無しさん
18/05/16 21:43:37.16 JOa7NyYz.net
つまり、鳥人間コンテストのような謎のルールで縛られてまともな飛行機作れない状態か

602:デフォルトの名無しさん
18/05/16 21:50:17.17 ub+CyxOt.net
1/6公式使うまで最適化してくれるようなコンパイラあんの？あったら見て見たいんだけど

603:デフォルトの名無しさん
18/05/16 22:22:29.79 /X1sH6Jm.net
visualc の出したコードではループ回数が10の倍数だということを織り込んで
10回分ずつ loop unrolling して端数回を処理するコードは略されてた。
そこまでわかってるならもう全部計算しといて略せよという気がした。

604:デフォルトの名無しさん
18/05/16 22:57:07.69 /X1sH6Jm.net
1/6公式使うのは違う計算をして微妙に違う値になるから最適化というより簡略化だな

605:デフォルトの名無しさん
18/05/16 23:22:07.02 kpFCptG2.net
先に除算を分岐処理しないとオーバーフロー条件変わっちゃうからなぁ

606:デフォルトの名無しさん
18/05/16 23:44:41.84 mOBIQo/B.net
まあ最適化してるってことでコンパイル時に全て計算してしまえば
ランタイム速度はいつだってO(1)だよ。

607:デフォルトの名無しさん
18/05/17 00:08:51.80 44AbGMy1.net
悪質な反則と正しいハックの違いを
理系の学問では説明できない

608:デフォルトの名無しさん
18/05/17 01:23:03.74 GvGg8gY/.net
コンパイル時に計算可能なのは>>457で
>>584は実行時の引数使ってるから計算しとくのは無理だな
いつだってO(1)に最適化できる、未来を予測する神のコンパイラがあれば別だけど。
積和しないで公式使うのがよろしくないってのは、
数学や算数の計算と違って丸め誤差のあるコンピュータ言語での
浮動小数点数演算は誤差に関する統一的な挙動、
通常 IEEE 754 に準拠した挙動が期待されるわけで、
式を変形したり変えたりすると丸め誤差の出方が違って結果の値が変わっちゃうから。
もちろん規格を守らなくて良いというオプションはあっても良いわけどけど。
…誰か何か他の話題を

609:デフォルトの名無しさん
18/05/17 17:09:11.06 UKx8yrTb.net
自分で考えろカス

610:デフォルトの名無しさん
18/05/22 10:01:58.35 C41sjEPZ.net
お前が考えろゴミ

611:デフォルトの名無しさん
18/05/22 17:54:26.91 IYYsp57a.net
ほなワイが集めたるで～

612:デフォルトの名無しさん
18/05/22 21:27:22.64 XSJVgfVv.net
つまりRust最強

613:デフォルトの名無しさん
18/05/22 21:57:35.93 eYNszKh+.net
何がどういう理屈で「つまり」なんだってばよ(；￣Д￣）？

614:デフォルトの名無しさん
18/05/22 22:03:03.16 +QrWxPmY.net
Rustは最近impl traitが実装されて使いやすくなった

615:デフォルトの名無しさん
18/05/22 22:41:37.50 eYNszKh+.net
impl trait は確かに嬉しかった
これでやっとトレイトオブジェクト使わずにイテレータが返せるようになった

616:デフォルトの名無しさん
18/05/22 22:50:22.39 BI9R8Qza.net
rust わかりやすいくらいダメな方向に行ってるな。。

617:デフォルトの名無しさん
18/05/22 23:12:28.14 auQt52bO.net
Juliaは？
けっこう化けそうな希ガス

618:デフォルトの名無しさん
18/05/22 23:20:40.27 eYNszKh+.net
何が理由で「ダメの方向」って言ってるのか分からない
C++の後継としてはRustは限りなく理想に近い言語だと思うが…

619:デフォルトの名無しさん
18/05/22 23:23:35.78 eL1QxRDx.net
>>606
去年も全く同じこと言ってたよなお前

620:デフォルトの名無しさん
18/05/22 23:28:27.19 m7LLEOxE.net
JuliaはPythonを殺せない気がする。ボトルネック以外速くてもあんまり意味ないし

621:デフォルトの名無しさん
18/05/22 23:38:51.33 rpUF29sL.net
py 3.6で標準で型付けできるようになったし
av女優の名前借りたゲス言語なんてオワコンでしょ

622:デフォルトの名無しさん
18/05/22 23:41:37.77 CTd7FMth.net
型システムだけはJuliaの方が好き。っていうかクラス嫌い

623:デフォルトの名無しさん
18/05/23 00:06:43.07 QWeWgJFJ.net
結局Dartなんだよなあ

624:デフォルトの名無しさん
18/05/23 00:10:03.78 NeMRQIGN.net
数値計算の話をwebで流すのやめろ！

625:デフォルトの名無しさん
18/05/23 00:24:34.00 lm4BwuCE.net
Juliaいらね
数値計算に使う分には記述性はFortranと大差ない

626:デフォルトの名無しさん
18/05/23 00:30:13.83 8U/w+cdS.net
Julia使ってるとコンパイル不要のスクリプト系の強みをjitのプリコンパイルの時間で失ってる気がするんだけど分かる人いない？

627:デフォルトの名無しさん
18/05/23 00:30:32.27 NeMRQIGN.net
>>614
パ……パイプとより柔軟な内包表記があるから……
グラフも出せるし……

628:デフォルトの名無しさん
18/05/23 00:32:43.88 xLXjXRd/.net
>>614
第一級関数がFortranにはないじゃん？

629:デフォルトの名無しさん
18/05/23 01:02:46.26 mwVk/jhM.net
Rustはクラス嫌いなだけでなく第一級関数も嫌う方向に行った

630:デフォルトの名無しさん
18/05/23 01:25:54.25 LjfntoLm.net
内包表記とかいうそびえ立つ糞
あのガイジ文法が読みやすいってpython作った低学歴はメクラのガイジなのか？

631:デフォルトの名無しさん
18/05/23 01:28:00.60 01TEDvfp.net
使わなきゃいい

632:デフォルトの名無しさん
18/05/23 01:48:18.92 NeMRQIGN.net
内包表記読みにくいって方が理解できん

633:デフォルトの名無しさん
18/05/23 01:52:39.56 prSTZoE+.net
包皮
放屁
やっぱ読みにくいわ

634:デフォルトの名無しさん
18/05/23 01:55:25.46 prSTZoE+.net
ピリオド.でpropertyをつないでいく何たら記法ってやつ
Rubyのゴルフ好きがよく使うが
あれこそ読みにくい

635:デフォルトの名無しさん
18/05/23 01:55:41.96 lm4BwuCE.net
>>615
Juliaは数時間～数日単位の時間のかかる処理に使うもの
全く問題にならないオーバーヘッド

636:デフォルトの名無しさん
18/05/23 02:34:11.07 V0Z2NuNB.net
>>618
なに言ってるんだ？
Rustは普通に第一級関数使えるんだが…
いろんなクレートがクロージャ使いまくってるんだが…
あとクラスを嫌ったのはむしろ正解だろ？
データと操作を一緒にするのは失敗で関連付けるのが正解
つまり、クラスは失敗でRustのimplかGoのレシーバが正解

637:デフォルトの名無しさん
18/05/23 04:36:59.97 L+y822nJ.net
Haskellの移植だっけか？あっちは分かりやすい。

638:デフォルトの名無しさん
18/05/23 04:38:52.45 L+y822nJ.net
Pythonic wwなリスト内包表記
もう少しうまくパクればいいのに。

639:デフォルトの名無しさん
18/05/23 06:54:23.85 eQfPSYhe.net
確かに for がネストしてたり if else がネストしてんのに内包表記するのは馬鹿だなと思うわ。
素直に for 文書いて append しろやと。

次ページ