アカウント名:
パスワード:
RとかPythonみたいなスクリプト言語でありもののパッケージ使ってコード書いてるとRyzen1950Xよりi7-6950Xの方が早かったりするんですよね。あんまり高度なプログラミングができない人でもRyzenの性能活かす方法の講習会とかやってくれたら有償でも参加したいんですが、日本AMDにはそういうマーケティング能力無いだろうなぁ。時間あればAOCC使って既存パッケージ置き換えるとか勉強してみたいけど、そこに回せる時間が無く・・・https://developer.amd.com/amd-aocc/ [amd.com]
Rは言語であると同時にソフトウェアでもある。多分この人はRで解析用のコードを書いているんじゃないかな。だからソフトウェア利用者で間違っていないのかもしれない。
#自分もRを6個起動してシミュレーション走らせてみたんだけど、Ryzen1600x、2600xとも多コアのメリットを生かせなかった。3コア利用時のコアごとの計算速度を1とすると6コア利用時のコアごとの速度は0.6か0.7くらい。このレベルだと4コアPC2台使ってもあまり変わらなくてがっかり。
複数プロセスで計算させるとメモリ律速になってしまい、メモリチャネル数+1くらいまでしか伸びなかった記憶があります。Rはどうしてもメモリアクセスが激しくなるので、仕方ないのです。なので、コア数が少ない廉価版待ち。
2700Xとか使っとけば
エンドユーザーとは言ってないからいいんじゃねーの。っていうか、ユーザーという概念は相対的だからね。君の違和感は僕には違和感ｗ
メーカーに対する語としてのユーザーだからおかしくないだら
違和感を持つ方がおかしいので認識を直した方がいい。ここスラドだよ。
今はxargsよりGNU Parallelを使ったほうが簡単ですよPerl製なのでそこそこオーバーヘッドはありますが…
シェルスクリプト並列化なんてできるんですね！言語操作系でかなり有益なはずなので今度試してみます！
面倒だったら単にバックグラウンドで複数動かして全部終わるまで待つとか
アスクは買い替えさせたい側だからやらないんじゃないのかな？性能生かされると買い替えサイクル長くなるので。
Rは知らないけどPythonはGILがあるからマルチスレッドは弱いんじゃなかったっけ？マルチスレッド性能と活かせないとRyzenでは不利になるんじゃないかなあ
そこでGO言語ですよっと(※スクリプト言語ではない)
残念だけど、コンパイルしているくせにJavaとどっこいどっこいの速度 [debian.net]しか出ない低速言語の出番はないんだよなあ。
JavaはHotspotの恩恵が結構でかいよ半分コンパイル言語と思ってもいいぐらい
そもそもJavaはコンパイルするよね。JavaScriptと混同してるのか、バイトコードとネイティブコードの話を混同しているのかは分かんないけど、真っ当に理解できてないことだけは間違いない。
なに言ってんだこいつ
GOが低速だと、世の大半の言語が低速じゃね？
pythonならmultiprocessing使えば速くなるよ。もの凄く使いにくいけど。
単純な並列化くらいなら何とかやれるんですけど、並列化した上で1950より6850が早かったんですよね。
そう？Pool.mapに落とし込める処理なら結構簡単だけど。
multiprocessingのwindows版はforkが使えない為か、無理やり実装してしてあって動作がおかしい。使える状況に制限があって、理解するのにだいぶ時間がかかった。それとプロセスを起こすからもの凄く重くて、うまくデータを用意しないと速くならない。
そういうケースがあるとすれば、Intelチップ用にビルドされた出来合いのバイナリーを使ってるんでしょ。RにしろPythonにしろ、コアの計算モジュールはC/C++で書かれてるんだから。
そういう場合にまずすべきことは、適切なバイナリを使うこと（または適切な設定でビルドすること）であって、C++を書き始めることではないだろう。
なので時間あればAOCC使ってビルドしなおし、って言う技術を身につけたいんですが、それを勉強する時間が・・・
こういうのこそJuliaじゃね?メモリはバカ食いするけど
普通にプロセスいっぱい走らせるんじゃだめなん
データを完全に分断して個別に処理できる場合は複数台で並列とかさせますけど、たいていの仕事は一部分だけ並列化できて、並列化したものを合成する必要があります。データxが2000個ある時、f(x)を計算するのは2000個並列処理できる(f(x)の計算自体も並列化できる)けど、Σf(x)を計算してΔ=f(x)-f^0(x)を計算してを何度も繰り返したりするのはスクリプト言語だとロスが大きいのです。
OSがどのくらい調停してくれるかだよねプロセスつーかアプリケーションで多コア活用するならIOと演算のバランスを考えて組むけどバラっバラの各アプリケーションが並走してたら最悪コアに振り分けられた35プロセスがIO待ちみたいな事態が起きたりするっしょ
OSの問題じゃなくて増えたのはコア数だけなんからIOの性能が上がるわけじゃないって当たり前の話だと思うけど
その当たり前の話があるからこのCPUは一般人には意味がないよねって話だと思うけど
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
HEDTユーザ皆C++書けるの？ (スコア:1)
RとかPythonみたいなスクリプト言語でありもののパッケージ使ってコード書いてるとRyzen1950Xよりi7-6950Xの方が早かったりするんですよね。
あんまり高度なプログラミングができない人でもRyzenの性能活かす方法の講習会とかやってくれたら有償でも参加したいんですが、日本AMDにはそういうマーケティング能力無いだろうなぁ。
時間あればAOCC使って既存パッケージ置き換えるとか勉強してみたいけど、そこに回せる時間が無く・・・
https://developer.amd.com/amd-aocc/ [amd.com]
Re:HEDTユーザ皆C++書けるの？ (スコア:2)
文脈からは「ユーザ = ソフトウェア開発者」ととらえられるが
一般的にPCの「ユーザ」と書けば、普通はソフトウェア開発者ではなく、ソフトウェア利用者の方を指すだろう。
Re: (スコア:0)
Rは言語であると同時にソフトウェアでもある。多分この人はRで解析用のコードを書いているんじゃないかな。
だからソフトウェア利用者で間違っていないのかもしれない。
#自分もRを6個起動してシミュレーション走らせてみたんだけど、Ryzen1600x、2600xとも多コアのメリットを生かせなかった。3コア利用時のコアごとの計算速度を1とすると6コア利用時のコアごとの速度は0.6か0.7くらい。このレベルだと4コアPC2台使ってもあまり変わらなくてがっかり。
Re: (スコア:0)
複数プロセスで計算させるとメモリ律速になってしまい、メモリチャネル数+1くらいまでしか伸びなかった記憶があります。Rはどうしてもメモリアクセスが激しくなるので、仕方ないのです。
なので、コア数が少ない廉価版待ち。
Re: (スコア:0)
2700Xとか使っとけば
Re: (スコア:0)
エンドユーザーとは言ってないからいいんじゃねーの。
っていうか、ユーザーという概念は相対的だからね。君の違和感は僕には違和感ｗ
Re: (スコア:0)
メーカーに対する語としての
ユーザーだからおかしくないだら
Re: (スコア:0)
違和感を持つ方がおかしいので認識を直した方がいい。
ここスラドだよ。
Re:HEDTユーザ皆C++書けるの？ (スコア:1)
RでもPythonでもないけれど、シェルスクリプトでxargsに-Pオプションを使うと幸せになれますよ。
自分は、自炊(いまさらですが)でスキャンした画像をImage magickのconvertコマンドでjpegファイルに変換するときに12threadsの恩恵に浴しました。
こんなTipsでもRyzenの普及には役立つような気がするので、
＞あんまり高度なプログラミングができない人でもRyzenの性能活かす方法の講習会とかやってくれたら有償でも参加したい
には、大賛成です。日本AMDは頑張ってほしいなぁ。
#３年ぶりにsrad.jpに書き込んでみました。
Re:HEDTユーザ皆C++書けるの？ (スコア:2)
今はxargsよりGNU Parallelを使ったほうが簡単ですよ
Perl製なのでそこそこオーバーヘッドはありますが…
Re:HEDTユーザ皆C++書けるの？ (スコア:1)
シェルスクリプト並列化なんてできるんですね！
言語操作系でかなり有益なはずなので今度試してみます！
Re: (スコア:0)
面倒だったら単にバックグラウンドで複数動かして全部終わるまで待つとか
Re: (スコア:0)
アスクは買い替えさせたい側だからやらないんじゃないのかな？
性能生かされると買い替えサイクル長くなるので。
Re: (スコア:0)
Rは知らないけどPythonはGILがあるからマルチスレッドは弱いんじゃなかったっけ？
マルチスレッド性能と活かせないとRyzenでは不利になるんじゃないかなあ
Re: (スコア:0)
そこでGO言語ですよっと(※スクリプト言語ではない)
Re: (スコア:0)
残念だけど、コンパイルしているくせにJavaとどっこいどっこいの速度 [debian.net]しか出ない低速言語の出番はないんだよなあ。
Re: (スコア:0)
JavaはHotspotの恩恵が結構でかいよ
半分コンパイル言語と思ってもいいぐらい
Re:HEDTユーザ皆C++書けるの？ (スコア:2)
そもそもJavaはコンパイルするよね。
JavaScriptと混同してるのか、バイトコードとネイティブコードの話を混同しているのかは分かんないけど、真っ当に理解できてないことだけは間違いない。
Re: (スコア:0)
Re: (スコア:0)
なに言ってんだこいつ
Re: (スコア:0)
GOが低速だと、世の大半の言語が低速じゃね？
Re: (スコア:0)
pythonならmultiprocessing使えば速くなるよ。
もの凄く使いにくいけど。
Re:HEDTユーザ皆C++書けるの？ (スコア:1)
単純な並列化くらいなら何とかやれるんですけど、並列化した上で1950より6850が早かったんですよね。
Re: (スコア:0)
そう？
Pool.mapに落とし込める処理なら結構簡単だけど。
Re: (スコア:0)
multiprocessingのwindows版はforkが使えない為か、無理やり実装してしてあって動作がおかしい。
使える状況に制限があって、理解するのにだいぶ時間がかかった。
それとプロセスを起こすからもの凄く重くて、うまくデータを用意しないと速くならない。
Re: (スコア:0)
そういうケースがあるとすれば、Intelチップ用にビルドされた出来合いのバイナリーを使ってるんでしょ。
RにしろPythonにしろ、コアの計算モジュールはC/C++で書かれてるんだから。
そういう場合にまずすべきことは、適切なバイナリを使うこと（または適切な設定でビルドすること）であって、C++を書き始めることではないだろう。
Re:HEDTユーザ皆C++書けるの？ (スコア:1)
なので時間あればAOCC使ってビルドしなおし、って言う技術を身につけたいんですが、それを勉強する時間が・・・
Re: (スコア:0)
こういうのこそJuliaじゃね?
メモリはバカ食いするけど
Re: (スコア:0)
普通にプロセスいっぱい走らせるんじゃだめなん
Re:HEDTユーザ皆C++書けるの？ (スコア:1)
データを完全に分断して個別に処理できる場合は複数台で並列とかさせますけど、たいていの仕事は一部分だけ並列化できて、並列化したものを合成する必要があります。
データxが2000個ある時、f(x)を計算するのは2000個並列処理できる(f(x)の計算自体も並列化できる)けど、Σf(x)を計算してΔ=f(x)-f^0(x)を計算してを何度も繰り返したりするのはスクリプト言語だとロスが大きいのです。
Re: (スコア:0)
OSがどのくらい調停してくれるかだよね
プロセスつーかアプリケーションで多コア活用するならIOと演算のバランスを考えて組むけど
バラっバラの各アプリケーションが並走してたら最悪コアに振り分けられた35プロセスがIO待ちみたいな事態が起きたりするっしょ
Re: (スコア:0)
OSの問題じゃなくて増えたのはコア数だけなんからIOの性能が上がるわけじゃないって当たり前の話だと思うけど
Re: (スコア:0)
その当たり前の話があるからこのCPUは一般人には意味がないよねって話だと思うけど