OpenClとそのためのツール。レビューとインプレッション - ページ 6 12345678910111213...29 新しいコメント Sceptic Philozoff 2012.01.30 22:05 #51 1カ月前にミシェイクが 叫んでいたのは、そういうことだったのだろう。 OpenCLの用途は、重厚なテストか、非常に集中的な並列計算をその場で行うことだと考えています。 今のところ必要ありませんが（重い計算はすべてインダクタのinit()で行っています）、触れておく価値はあると思います。 Алексей Тарабанов 2012.01.30 22:14 #52 Alexey、私も同じ問題を抱えています。何かをinitにドラッグして、次にリアルタイムにドラッグしようとするのです :) 私の脳は手続き型言語になっている。OOPが望ましいが、ネイティブでない。 削除済み 2012.01.31 04:22 #53 MetaDriver: mql5.comを見ないマニアックなB4ファンのために :OpenCL: MQL5での実装の内部テスト ありがとうございます、個人的には見てなかったです。ただ、そう単純な話ではない。 OpenCL 1.0はダブルフロートで問題なく動作しますし、すべてのメーカーがサポートする「パブリックオプション」です。 http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/ 「オプションの倍精度浮動小数点と半浮動小数点 OpenCL 1.0では、オプションの拡張機能として倍精度および半浮動小数点のサポートが追加されました。倍精度 データ型は，IEEE-754 の倍精度記憶形式を確認する必要がある。 倍精度を 使用したいアプリケーションは、カーネルコードで倍精度データ型を宣言する前に、#pragma OPENCL EXTENSION cl_khr_fp64 : enable 指令を含める必要があります。これにより、組み込みのベクトルおよびスカラーデータ型のリストが拡張され、次のようになります......」とある。 Strategy Testerでは動作しますが、OpenCL 1.0 Expert Advisorでは動作 しません。Rinatが言うように、「そこにはダブルフロートがない」からではなく、すでに述べたように、OpenCL 1.0にはセーフスレッドがなく、MT4-5にはスレッドがないためです。 OpenCL（とCUDA）は全般的に分かりにくいです。何がしたいんだ？結局、鉄とラジオの技術者たちは、番組の概念を変えることを目指したのだ。鉄のような考え方をしているのです。 プログラム（MT、DLL、Expert Advisor）は、 OpenCLコネクタを実行するプラットフォーム（AMD、Nvidia、Intel）を選択しなければなりません（複数の異なるプラットフォームがある可能性があります）。OpenCLのプラットフォーム自動選択機能はまだない。Rinatは「最強を自動選択する」と話していますが、どうなんでしょう。ここに示した例では、プラットフォームの選択も、デバイス（GPU、CPU）の選択もありません。 さらに、複数のGPUやGPU+CPUでのタスクを自動的に並列化するOpenCLの規格はまだ存在しません。AMDのドライバ/SDKのいくつかのバージョンでは、このような自動プロビジョニングを導入していましたが、いくつかの問題があり、当分の間、AMDはこの機能をオフにしています。 結論：MT4-5でOpenCLプログラムを開発し有効にするには、手作業が 必要であり、自動的または「オプションで再コンパイル」によって動作するわけではありません。そのため、実運用では多くの失速を招くことになります。そして、重要なことは、残念ながら、それはユダヤ人指向のプログラムであり、それは間違っているのだと、私は自分に言い聞かせることです。CUDAやOpenCLの並列プログラムのデバッグは、鉄の革命家が想定していたよりもはるかに困難であることが判明したのです。Nvidiaは、2011年秋のCUDAカンファレンスをキャンセルしました。ドライバの問題と、デバッグの遅延に関する多くの苦情が原因です。そこで、最新のToolkitにさらに1000もの新機能 を追加したわけだが、最も単純なプログラムが実行もしない、あるいは割り込みで実行されるとしたら、どうすればいいのだろう。結局、OpenCLやCUDAの内部機構については、記述ツールの半分も触れていないのです。 ドライバやソフトウェアの互換性によりハングアップしたビデオカードのGPU速度（単位：GigaFLOPS）はゼロです。 OpenCL：MQL5での内部実装テスト Andrey Dik 2012.01.31 05:24 #54 AlexEro: ありがとうございます！個人的には見ていないのですが。ただ、そう単純な話ではない。 .... 第5回フォーラムにお返事ください。 Sceptic Philozoff 2012.01.31 13:30 #55 tara: 手続き的な言葉に脳みそが回った。OOPが望ましいが、ネイティブでない。 そんなことはどうでもいいんです。5で手続き的に書けばいいんです。 joo：そして 、この事実に落胆しているのが、アクトゥン！です。-MQL4がDLLを呼び出すと、MQL5が同じDLLを呼び出すよりも速く動作 するのですが・・・。 これが憂慮すべきことなのです。 MQL5でOMPのネイティブサポートを開発することもできたはずです。コーダーにとっては簡単かつ安価で、DLLを書く必要もないでしょう。 しかし、この不完全な鉄のプログラミング言語のミツバチの群れは...。というのは、まだ実感がわきません。そうですね、場合によっては100倍の加速は素晴らしいことですが、プログラミング文化という点では一歩後退していますね。 Igor Chemodanov 2012.01.31 13:46 #56 ... OpenCL（とCUDA）には、一般的に多くの混乱があります。何がしたいんだ？何しろ、鉄とラジオの技術者が、番組の概念を変えることを目指したのだから。鉄のような考え方をしているのです。 プログラム、つまりMTやエキスパートDLLやEAは、 OpenCLコネクタが動作するプラットフォーム（AMD、Nvidia、Intel）を選択しなければなりません（コンピュータに複数の異なるプラットフォームがある可能性があります）。OpenCLのプラットフォーム自動選択機能はまだない。Rinatは「最強を自動選択する」と話していますが、どうなんでしょう。ここに示した例では、プラットフォームの選択も、デバイス（GPU、CPU）の選択もありません。 さらに、複数の GPU や GPU+CPU にまたがる OpenCL タスクを自動的に並列化する標準的な方法はまだ存在しません。言ってみれば、AMDはドライバ/SDKの一部のバージョンで、こうした自動並列化を実装していたのだが、問題があって、AMDは今のところこれをオフにしている。 結論：MT4-5でOpenCLプログラムを開発し有効にするには、手作業が 必要であり、自動的または「オプションで再コンパイル」によって動作するわけではありません。そのため、実運用では多くの失速を招くことになります。そして、重要なことは、残念ながら、それはユダヤ人指向のプログラムであり、それは間違っているのだと、私は自分に言い聞かせることです。CUDAやOpenCLの並列プログラムのデバッグは、鉄の革命家が想定していたよりもはるかに困難であることが判明したのです。Nvidiaは、2011年秋のCUDAカンファレンスをキャンセルしました。ドライバの問題と、デバッグの遅延に関する多くの苦情が原因です。そこで、最新のToolkitにさらに1000もの新機能 を追加したわけだが、最も単純なプログラムが実行もしない、あるいは割り込みで実行されるとしたら、どうすればいいのだろう。結局、OpenCLやCUDAの内部機構については、記述ツールの半分も触れていないのです。 ドライバやソフトウェアの互換性によるハンギングビデオカードのGPU速度（単位：GigaFLOPS）はゼロに等しくなります。 "そうだ、それでいいんだ、そうだろう "と。しかし、コインにはもう一つの側面がある」（『白人の捕虜』C）。メタクオーターは、いよいよ「時代についていく」ですね。そして、あなたの質問（正解）は彼らの問題ではなく、ハード、ウッド、OSの開発者の問題なのです。 Mykola Demko 2012.01.31 14:56 #57 Mathemat: そんなことはどうでもいいんです。5でもプロシージャルスタイルで書くことができます。 しかし、これは憂慮すべきことです。 MQL5でOMPのネイティブサポートを開発することもできたはずです。dllを書く必要がなく、簡単できれいです。 しかし、この不完全なハードウェアプログラミング言語のミツバチの群れは......。...あまり盛り上がらないような気がします。確かに、場合によっては100倍の加速は素晴らしいことですが、プログラミング文化という点では一歩後退しているのです。 また、MQL4がMQL5よりも高速に動作する事実にも出会いました。多くの場合、プログラマーによって最適化された数学的演算に現れている。 しかし、私はこれが主な問題ではないと思います。OpenCL MQを使うことで、彼らは主要なプログラミングパスと並行して走る道を選んだのです。おそらくこれまでは一歩後退する必要がありましたが、コンピュータ技術の将来の発展では、逐次処理と並列処理のどちらが使われるかはすでにコード次第となる統合スケーラブルシステムが見られるでしょう。 だから、道路はかなり正しい。現在では、並列計算を必要とする アルゴリズムはあまり多くありませんが、それはむしろ、数学的思考が並列計算を実現する装置を持っていなかったため、そのようなアルゴリズムを作る必要がなかったからです。 アレクセイ、ひとつ考えてみてほしいんだけど、数学の発見はすべて200〜300年前になされたもので、この100年間は、数学的思考はただあるものに磨きをかけてきただけなんだ。並列計算の需要が生まれたのは、NSの発見があったからに他ならない。次の100年は、大幅に並列化されたアルゴリズムが登場するでしょう。そして、そのうちの1つをあなたが発明することができるのです。 Vladimir Gomonov 2012.01.31 15:09 #58 Urain: mql4がMQL5より速いという事実も見たことがあります。これは、プログラマーによって最適化された行列演算でよく見られます。 しかし、私はこれが主な問題ではないと思います。OpenCLに参入することで、MQは主要なプログラミングの道と並行する道を歩んできました。おそらくこれまでは一歩後退する必要がありましたが、コンピュータ技術の将来の発展では、逐次処理と並列処理のどちらが使われるかはすでにコード次第となる統合スケーラブルシステムが見られるでしょう。 だから、道路はかなり正しい。現在では、並列計算の実装を必要とする アルゴリズムはあまり多くありませんが、それはむしろ、数学的思考が並列計算の実装のための装置を持たず、そのようなアルゴリズムを作る必要がなかったからです。 アレクセイ、ひとつだけ考えてほしいんだけど、数学の発見はすべて200〜300年前になされたもので、この100年の数学的思考は、あるものを磨いてきただけなんだ。並列計算の需要が形成されたのは、NSの発見があったからに他ならない。次の100年は、大幅に並列化されたアルゴリズムが登場するでしょう。そして、そのうちの1つをあなたが発明することができるのです。 いや、やはりかなり絶望的な状態ではないでしょうか。:) こんにちは。 Andrey Dik 2012.01.31 15:23 #59 MQは、GPU計算のサポート導入という（彼らにとっての）痛手をものともせず、よくやってくれました。その痛みは、まず、根本的に新しい技術（any）を導入すると、プラットフォーム全体の信頼性や耐障害性がまず低下することと関係している。しかし、将来は並列コンピューティングに なること、遅かれ早かれこの方向で何かをしなければならないことを、彼らは完全に理解しています（最初の一歩はすでに踏み出されました - クラウド）。 PSニコライ さん、こんにちは。どうしていなくなったんですか？- LINEしてください。 Sceptic Philozoff 2012.01.31 16:02 #60 Urain: アレクセイ、ひとつだけ考えてほしいんだけど、数学の発見はすべて200〜300年前になされたもので、この100年の数学的思考は、そこにあるものを磨いてきただけなんだ。そして、NSの発見だけが、並列計算の要求を形成しているのです。 ないため、事実とは異なります。数学の質的発展が途切れることはない。 また、並列計算が必要なのはNSだけでなく、もっと平凡な作業、例えばビデオのコーディングやレンダリングもある。 しかし、MQ運動の全体的なベクトルが明るいことは確かです。 12345678910111213...29 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
1カ月前にミシェイクが 叫んでいたのは、そういうことだったのだろう。
OpenCLの用途は、重厚なテストか、非常に集中的な並列計算をその場で行うことだと考えています。
今のところ必要ありませんが（重い計算はすべてインダクタのinit()で行っています）、触れておく価値はあると思います。
Alexey、私も同じ問題を抱えています。何かをinitにドラッグして、次にリアルタイムにドラッグしようとするのです :)
私の脳は手続き型言語になっている。OOPが望ましいが、ネイティブでない。
mql5.comを見ないマニアックなB4ファンのために :OpenCL: MQL5での実装の内部テスト
ありがとうございます、個人的には見てなかったです。ただ、そう単純な話ではない。
OpenCL 1.0はダブルフロートで問題なく動作しますし、すべてのメーカーがサポートする「パブリックオプション」です。
http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/
「オプションの倍精度浮動小数点と半浮動小数点
OpenCL 1.0では、オプションの拡張機能として倍精度および半浮動小数点のサポートが追加されました。倍精度 データ型は，IEEE-754 の倍精度記憶形式を確認する必要がある。
倍精度を 使用したいアプリケーションは、カーネルコードで倍精度データ型を宣言する前に、#pragma OPENCL EXTENSION cl_khr_fp64 : enable 指令を含める必要があります。これにより、組み込みのベクトルおよびスカラーデータ型のリストが拡張され、次のようになります......」とある。
Strategy Testerでは動作しますが、OpenCL 1.0 Expert Advisorでは動作 しません。Rinatが言うように、「そこにはダブルフロートがない」からではなく、すでに述べたように、OpenCL 1.0にはセーフスレッドがなく、MT4-5にはスレッドがないためです。
OpenCL（とCUDA）は全般的に分かりにくいです。何がしたいんだ？結局、鉄とラジオの技術者たちは、番組の概念を変えることを目指したのだ。鉄のような考え方をしているのです。
プログラム（MT、DLL、Expert Advisor）は、 OpenCLコネクタを実行するプラットフォーム（AMD、Nvidia、Intel）を選択しなければなりません（複数の異なるプラットフォームがある可能性があります）。OpenCLのプラットフォーム自動選択機能はまだない。Rinatは「最強を自動選択する」と話していますが、どうなんでしょう。ここに示した例では、プラットフォームの選択も、デバイス（GPU、CPU）の選択もありません。
さらに、複数のGPUやGPU+CPUでのタスクを自動的に並列化するOpenCLの規格はまだ存在しません。AMDのドライバ/SDKのいくつかのバージョンでは、このような自動プロビジョニングを導入していましたが、いくつかの問題があり、当分の間、AMDはこの機能をオフにしています。
結論：MT4-5でOpenCLプログラムを開発し有効にするには、手作業が 必要であり、自動的または「オプションで再コンパイル」によって動作するわけではありません。そのため、実運用では多くの失速を招くことになります。そして、重要なことは、残念ながら、それはユダヤ人指向のプログラムであり、それは間違っているのだと、私は自分に言い聞かせることです。CUDAやOpenCLの並列プログラムのデバッグは、鉄の革命家が想定していたよりもはるかに困難であることが判明したのです。Nvidiaは、2011年秋のCUDAカンファレンスをキャンセルしました。ドライバの問題と、デバッグの遅延に関する多くの苦情が原因です。そこで、最新のToolkitにさらに1000もの新機能 を追加したわけだが、最も単純なプログラムが実行もしない、あるいは割り込みで実行されるとしたら、どうすればいいのだろう。結局、OpenCLやCUDAの内部機構については、記述ツールの半分も触れていないのです。
ドライバやソフトウェアの互換性によりハングアップしたビデオカードのGPU速度（単位：GigaFLOPS）はゼロです。
ありがとうございます！個人的には見ていないのですが。ただ、そう単純な話ではない。
....そんなことはどうでもいいんです。5で手続き的に書けばいいんです。
joo：そして 、この事実に落胆しているのが、アクトゥン！です。-MQL4がDLLを呼び出すと、MQL5が同じDLLを呼び出すよりも速く動作 するのですが・・・。
これが憂慮すべきことなのです。
MQL5でOMPのネイティブサポートを開発することもできたはずです。コーダーにとっては簡単かつ安価で、DLLを書く必要もないでしょう。
しかし、この不完全な鉄のプログラミング言語のミツバチの群れは...。というのは、まだ実感がわきません。そうですね、場合によっては100倍の加速は素晴らしいことですが、プログラミング文化という点では一歩後退していますね。
OpenCL（とCUDA）には、一般的に多くの混乱があります。何がしたいんだ？何しろ、鉄とラジオの技術者が、番組の概念を変えることを目指したのだから。鉄のような考え方をしているのです。
プログラム、つまりMTやエキスパートDLLやEAは、 OpenCLコネクタが動作するプラットフォーム（AMD、Nvidia、Intel）を選択しなければなりません（コンピュータに複数の異なるプラットフォームがある可能性があります）。OpenCLのプラットフォーム自動選択機能はまだない。Rinatは「最強を自動選択する」と話していますが、どうなんでしょう。ここに示した例では、プラットフォームの選択も、デバイス（GPU、CPU）の選択もありません。
さらに、複数の GPU や GPU+CPU にまたがる OpenCL タスクを自動的に並列化する標準的な方法はまだ存在しません。言ってみれば、AMDはドライバ/SDKの一部のバージョンで、こうした自動並列化を実装していたのだが、問題があって、AMDは今のところこれをオフにしている。
結論：MT4-5でOpenCLプログラムを開発し有効にするには、手作業が 必要であり、自動的または「オプションで再コンパイル」によって動作するわけではありません。そのため、実運用では多くの失速を招くことになります。そして、重要なことは、残念ながら、それはユダヤ人指向のプログラムであり、それは間違っているのだと、私は自分に言い聞かせることです。CUDAやOpenCLの並列プログラムのデバッグは、鉄の革命家が想定していたよりもはるかに困難であることが判明したのです。Nvidiaは、2011年秋のCUDAカンファレンスをキャンセルしました。ドライバの問題と、デバッグの遅延に関する多くの苦情が原因です。そこで、最新のToolkitにさらに1000もの新機能 を追加したわけだが、最も単純なプログラムが実行もしない、あるいは割り込みで実行されるとしたら、どうすればいいのだろう。結局、OpenCLやCUDAの内部機構については、記述ツールの半分も触れていないのです。
ドライバやソフトウェアの互換性によるハンギングビデオカードのGPU速度（単位：GigaFLOPS）はゼロに等しくなります。
そんなことはどうでもいいんです。5でもプロシージャルスタイルで書くことができます。
しかし、これは憂慮すべきことです。
MQL5でOMPのネイティブサポートを開発することもできたはずです。dllを書く必要がなく、簡単できれいです。
しかし、この不完全なハードウェアプログラミング言語のミツバチの群れは......。...あまり盛り上がらないような気がします。確かに、場合によっては100倍の加速は素晴らしいことですが、プログラミング文化という点では一歩後退しているのです。
また、MQL4がMQL5よりも高速に動作する事実にも出会いました。多くの場合、プログラマーによって最適化された数学的演算に現れている。
しかし、私はこれが主な問題ではないと思います。OpenCL MQを使うことで、彼らは主要なプログラミングパスと並行して走る道を選んだのです。おそらくこれまでは一歩後退する必要がありましたが、コンピュータ技術の将来の発展では、逐次処理と並列処理のどちらが使われるかはすでにコード次第となる統合スケーラブルシステムが見られるでしょう。
だから、道路はかなり正しい。現在では、並列計算を必要とする アルゴリズムはあまり多くありませんが、それはむしろ、数学的思考が並列計算を実現する装置を持っていなかったため、そのようなアルゴリズムを作る必要がなかったからです。
アレクセイ、ひとつ考えてみてほしいんだけど、数学の発見はすべて200〜300年前になされたもので、この100年間は、数学的思考はただあるものに磨きをかけてきただけなんだ。並列計算の需要が生まれたのは、NSの発見があったからに他ならない。次の100年は、大幅に並列化されたアルゴリズムが登場するでしょう。そして、そのうちの1つをあなたが発明することができるのです。
mql4がMQL5より速いという事実も見たことがあります。これは、プログラマーによって最適化された行列演算でよく見られます。
しかし、私はこれが主な問題ではないと思います。OpenCLに参入することで、MQは主要なプログラミングの道と並行する道を歩んできました。おそらくこれまでは一歩後退する必要がありましたが、コンピュータ技術の将来の発展では、逐次処理と並列処理のどちらが使われるかはすでにコード次第となる統合スケーラブルシステムが見られるでしょう。
だから、道路はかなり正しい。現在では、並列計算の実装を必要とする アルゴリズムはあまり多くありませんが、それはむしろ、数学的思考が並列計算の実装のための装置を持たず、そのようなアルゴリズムを作る必要がなかったからです。
アレクセイ、ひとつだけ考えてほしいんだけど、数学の発見はすべて200〜300年前になされたもので、この100年の数学的思考は、あるものを磨いてきただけなんだ。並列計算の需要が形成されたのは、NSの発見があったからに他ならない。次の100年は、大幅に並列化されたアルゴリズムが登場するでしょう。そして、そのうちの1つをあなたが発明することができるのです。
いや、やはりかなり絶望的な状態ではないでしょうか。:)
こんにちは。
MQは、GPU計算のサポート導入という（彼らにとっての）痛手をものともせず、よくやってくれました。その痛みは、まず、根本的に新しい技術（any）を導入すると、プラットフォーム全体の信頼性や耐障害性がまず低下することと関係している。しかし、将来は並列コンピューティングに なること、遅かれ早かれこの方向で何かをしなければならないことを、彼らは完全に理解しています（最初の一歩はすでに踏み出されました - クラウド）。
PSニコライ さん、こんにちは。どうしていなくなったんですか？- LINEしてください。
ないため、事実とは異なります。数学の質的発展が途切れることはない。
また、並列計算が必要なのはNSだけでなく、もっと平凡な作業、例えばビデオのコーディングやレンダリングもある。
しかし、MQ運動の全体的なベクトルが明るいことは確かです。