+- Curl Global Community (https://communities.curl.com)
+-- Forum: Discussions (https://communities.curl.com/forumdisplay.php?fid=1)
+--- Forum: General Curl questions (https://communities.curl.com/forumdisplay.php?fid=2)
+--- Thread: マルチスレッド・マルチコアへの対応について (/showthread.php?tid=257)
Pages:
1
2
マルチスレッド・マルチコアへの対応について - 復活の帝王 - 08-30-2011
Curlはマルチスレッド・マルチコアへの対応はどうなっていますか？
・現時点では対応していないが、ロードマップ上対応が予定されている
・Ver.xxから対応してる
など。情報がありましたら情報ソースと共に教えて頂けると助かります。
RE: マルチスレッド・マルチコアへの対応について - kino - 08-30-2011
復活の帝王さん
マルチスレッドの言葉は難しいですが、
Curlはマルチスレッドではないと思います。
理由は、
処理が同時並行で実施されるわけではない
割り込みでタイマーイベントが処理されることもない
からです。
ですが、サブアプレットをつかったり、CurlEXTライブラリにバックグランド・タスクAPIというのがありますので、それらを用いると近しいものが作れるのではと思います。
http://developers.curlap.com/re-reference/54-curl-ext-lib/738-backgroundtask.html
RE: マルチスレッド・マルチコアへの対応について - 復活の帝王 - 08-30-2011
(08-30-2011, 03:26 PM)kino Wrote: 復活の帝王さんありがとうございます。
マルチスレッドの言葉は難しいですが、
Curlはマルチスレッドではないと思います。
理由は、
処理が同時並行で実施されるわけではない
割り込みでタイマーイベントが処理されることもない
からです。
ですが、サブアプレットをつかったり、CurlEXTライブラリにバックグランド・タスクAPIというのがありますので、それらを用いると近しいものが作れるのではと思います。
http://developers.curlap.com/re-reference/54-curl-ext-lib/738-backgroundtask.html
CurlEXTライブラリのバックグランド・タスクAPIとサンプルを確認しましたが
「それらを用いると近しいものが作れるのでは」
という記載が気になりました。
日本語をそのまま解釈すると「近いけどそのものではない」と受け取れます。
具体的には何が足りない・どう違うのでしょうか？
またバックグランド・タスクAPIの原理がよく分かりません。(ので、何に注意して使用するべきか分かりません)
Curlのプログラムは一つの仮想的な世界(RTE)の中で動いている物、と理解しています。
私はRTE自身がマルチスレッドに非対応だから無理なのかと理解していたのですが、それをどうやって実現しているのでしょう？
すいません、質問ばかりで・・・。
RE: マルチスレッド・マルチコアへの対応について - hokada - 08-30-2011
Curlのアプレットは１つのスレッドとして作られます。そのため、複数アプレットを実行すれば、複数のスレッドが生成されます。また、Curlにはサブアプレットという仕組みがあり、あるアプレットから別の子アプレットを生成することができ、その子アプレットは複数個作れます。
そのため、マルチスレッドで動作していますが、本来他の言語が持つような機能をすべては対応しておりません。（例えばメモリ共有できないなどの制約があります。但し、サブアプレット（スレッド）間通信などの機能があります。対応している機能については、ヘルプドキュメントを参照いただければと思います。）
CurlEXTのバックグラウンドタスクAPIというものは、そのサブアプレットの標準APIを簡易に利用できるようにしたものです。
Curlの内部の話は、オープンソースではないので詳しくはできませんが、当然複数スレッドでいくつかの処理は並行的に動作します。
RE: マルチスレッド・マルチコアへの対応について - 復活の帝王 - 09-05-2011
(08-30-2011, 06:01 PM)hokada Wrote: Curlのアプレットは１つのスレッドとして作られます。そのため、複数アプレットを実行すれば、複数のスレッドが生成されます。また、Curlにはサブアプレットという仕組みがあり、あるアプレットから別の子アプレットを生成することができ、その子アプレットは複数個作れます。なるほど。回答ありがとうございます。
そのため、マルチスレッドで動作していますが、本来他の言語が持つような機能をすべては対応しておりません。（例えばメモリ共有できないなどの制約があります。但し、サブアプレット（スレッド）間通信などの機能があります。対応している機能については、ヘルプドキュメントを参照いただければと思います。）
CurlEXTのバックグラウンドタスクAPIというものは、そのサブアプレットの標準APIを簡易に利用できるようにしたものです。
Curlの内部の話は、オープンソースではないので詳しくはできませんが、当然複数スレッドでいくつかの処理は並行的に動作します。
> 対応している機能については、ヘルプドキュメントを参照いただければと思います。
これはどこの事を指されていますか？
http://developers.curlap.com/re-reference/54-curl-ext-lib/738-backgroundtask.html
には使い方はあるのですが・・・。申し訳ないのですが、どのHelpをどういったキーワードでかければ
良いのか教えて頂けると助かります。
また制約についても↑を見れば分かるとは思うのですが、これに伴うユーザレベルでのメリット・デメリットを教えて下さい。
バックグラウンドタスクAPIがそうなのかは別として。
例えばスレッド間通信と単純にネイティブな変数を確認するのとを比較した場合、通常は後者の方が早いと私は認識しています。
この場合、デメリットは「速度低下」になるかと思います。
今までの回答を見ている限り、あくまでも疑似の印象がぬぐえず、かつあまりメリットが見いだせないのです。
(とはいうものの今の時点ではデメリットも見えないのですが。)
RE: マルチスレッド・マルチコアへの対応について - hokada - 09-05-2011
>> 対応している機能については、ヘルプドキュメントを参照いただければと思います。
> これはどこの事を指されていますか？
> http://developers.curlap.com/re-reference/54-curl-ext-lib/738-backgroundtask.html
> には使い方はあるのですが・・・。申し訳ないのですが、どのHelpをどういったキーワードでかければ
> 良いのか教えて頂けると助かります。
>
> また制約についても↑を見れば分かるとは思うのですが、これに伴うユーザレベルでのメリット・デメリットを教えて下さい。
ヘルプドキュメントは、IDEに入っている「Curl IDEドキュメント」です。キーワードは、前の返信でも書きましたように「サブアプレット」とか、実際のクラスである「AppletData」などで引っかかると思います。
> バックグラウンドタスクAPIがそうなのかは別として。
> 例えばスレッド間通信と単純にネイティブな変数を確認するのとを比較した場合、通常は後者の方が早いと私は認識しています。
> この場合、デメリットは「速度低下」になるかと思います。
>
> 今までの回答を見ている限り、あくまでも疑似の印象がぬぐえず、かつあまりメリットが見いだせないのです。
> (とはいうものの今の時点ではデメリットも見えないのですが。)
う～ん？申し訳ないですが、何をしたいのかよくわかりませんが、メモリ共有ができないと実現できないアプリケーションがあるのであれば、利用することはできないかもしれませんね。また、非常にスピードが遅いということがあれば、それはまた改善すべき別問題ですね。
開発当初の設計思想がどうだったかはハッキリとは認識していませんが、「疑似的なマルチスレッド」ではなくサブアプレットという別機能を提供していると思います。メモリ共有をさせないという仕様も、例えば、開発者のミスなどでクラッシュを引き起こすのを避けるためだと思います。（あくまで想像ですが・・・。）そういう意味ではメリット（？）になるかもしれないですね。
バックグラウンドタスクAPIは、確かに疑似的っぽいAPIかもしれませんが・・・。
RE: マルチスレッド・マルチコアへの対応について - 復活の帝王 - 09-05-2011
回答、ありがとうございます。
(09-05-2011, 02:00 PM)hokada Wrote: ヘルプドキュメントは、IDEに入っている「Curl IDEドキュメント」です。キーワードは、前の返信でも書きましたように「サブアプレット」とか、実際のクラスである「AppletData」などで引っかかると思います。使用しているのはCurl5.0なのですが、これでは「サブアプレット」というキーワードは引っかかりませんでした。
「AppletData」は掛かりました。まずはこれを読んでみます。
Quote:う～ん？申し訳ないですが、何をしたいのかよくわかりませんが、メモリ共有ができないと実現できないアプリケーションがあるのであれば、利用することはできないかもしれませんね。また、非常にスピードが遅いということがあれば、それはまた改善すべき別問題ですね。伝わっておらずすいません。
開 発当初の設計思想がどうだったかはハッキリとは認識していませんが、「疑似的なマルチスレッド」ではなくサブアプレットという別機能を提供していると思い ます。メモリ共有をさせないという仕様も、例えば、開発者のミスなどでクラッシュを引き起こすのを避けるためだと思います。（あくまで想像です が・・・。）そういう意味ではメリット（？）になるかもしれないですね。
バックグラウンドタスクAPIは、確かに疑似的っぽいAPIかもしれませんが・・・。
「何がしたい」というのではありません。どちらかというと「何が出来るか？出来ないか？」です。
元々、Curlの思想としては「リッチクライアント」であり、これは「ファットクライアント」(例えばEXEなど)と
「Webクライアント」(ブラウザベース)のいいとこ取り、を目指して作られたものと理解しています。
私は元々ファットクライアントを作成してきた人間なので、それと比較して「何が出来るか？何が出来ないのか？」
「どう違うのか？違わないのか？(例えば速度など)」を知りたいのです。
私が以前に某Curlの技術者に聞いたところ「基本的にスレッドを作成できない」との回答だったので
「・・・って事はマルチコアの恩恵って無理じゃないの？」と感じ、この質問となった次第です。
しかし今回「似た様な事が出来る(ただし多少の制約はある)」との回答だったので
「じゃぁ基本的に上位設計の思想としては同じと思って良い？」と思い「ユーザレベルでのメリット・デメリット」
をお聞きしました。
とはいうものの、同一の事を行うアプリをWindowsFormプラットフォームで、仮に作った場合と比較すると
明らかに遅い部分が見受けられます。ということは、今までと同じ感覚で上位設計を行うと、実用上問題が
出る可能性が非常に高い事になります。
これがなぜ起こるのか？が分からないため、それをプラットフォームの特性から探っている次第です。
(その一つの要因として「もしかしてマルチスレッドが関係あるのか？！」と思ったのが質問のトリガーです)
RE: マルチスレッド・マルチコアへの対応について - hokada - 09-07-2011
ぼんやりとしていて、回答が難しいですが、個人的な見解では、性能面でVC++などで開発したC/Sのアプリと比較した場合、恐らくそれよりは遅くなる部分が多い気がします。（正確には検証しなければ、実際には分からないですが。。。）
例えば、通信について、C/SではOracleのようなOO4Oなどの独自プロトコルなどで通信する場合と、リッチクライアントでHTTPで通信して、さらにアプリケーションサーバを介すことと比較すれば、当然前者の方が早くなるはずです。もちろん、性能だけ比較すればの話ですが・・・・。
また、GUIの機能もC/S時代と比較すると各段に増えていると思います。（最近ではC/Sのことあまり覚えていないので間違っているかもしれませんが・・・。） 機能が増えたり、見た目が複雑になればその分速度も落ちる可能性は高いと思います。もちろん、それでも性能を向上するため仕組みはいくつか取り入れています。また、速度重視の機能が少ないコンポーネントを提供することも可能ですが、機能が非常に少ないコンポーネントであれば、ユーザ側で作るのも難しくないかなとも思います。もちろん、ニーズが多ければ開発して、提供していきたいとは考えています。
ちなみに、これはC/Sとの比較だけでなく、FlexやSilverLightなどとの比較でも同じことが言えるかもしれません。さらに、１つのGUIコンポーネントでも機能が違うので、こういったケースは早いけど、こういったケースは遅いということも出てくると思います。
それ以外では、WindowsというOSを作っているMicrosoftが作っているVC++には、それなりの性能的な分があるのではとは個人的には思っています。
最後に、マルチスレッドが今のCurl RTEに非常に大きな性能劣化を起こしているというような問題は今のところありません。
RE: マルチスレッド・マルチコアへの対応について - 復活の帝王 - 09-08-2011
hokada さん
回答ありがとうございます。
VC++など、とあげられているのは私の「WindowsFormプラットフォーム」というキーワードに対して、でしょうか？
だとするならば、ここでの「WindowsFormプラットフォーム」というのは.NET(で作るEXEなど)の事を示しています。
＃VC++などはWin32ネイティブアプリなので、当然のことながら速いのは承知しています。
なので、以下、Win32ネイティブアプリとの比較ではなく、「リッチクライアント」というキーワードだけでいえば同じ土俵のCurlと.NETの比較として進めます。
.NET(で作るEXEなど)が「リッチクライアント」なのか？SilverLightと比べるべきではないのか？という疑問は出るかと思いますが、私は下記の資料をみてそう判断しました。(古いです)
http://www.nri.co.jp/opinion/g_souhatsu/pdf/gs20040204.pdf
機能が以前(例えば旧VB系、MFCと比較して)増えているのも承知しています。しかしながらそれは.NETテクノロジーも同じです。
(私見ですが)むしろコンポーネントにおいては.NETの方が優位性が高いのではないでしょうか？
Curl、.NET(で作るEXEなど)をさわった年数はほぼ同じですが、今までの使用感からいえばCurlの方が遅い部分が多い気がします(というかCurlって速い～と感じたことがない。同じく、正確には様々な角度から検証しなければ、実際には分からないですが。。。)
今回「本当にそうなんか？」と考えて、あくまでも一例として「同一の事を行うアプリをWindowsFormプラットフォームで、作った場合と比較」をしてみたわけです。
> 最後に、マルチスレッドが今のCurl RTEに非常に大きな性能劣化を起こしているというような問題は今のところありません。
hokada さんのCurlに対するポジションが分からない(例：住商の方、Curlの一開発者、Curl RTEの開発者・・・等々)＋「大きな」は主観なのですが・・・
これについて、言い切れる根拠は何なのでしょうか？「把握していないだけ」ということではないでしょうか？
例えば。Curlの製品紹介ページを見ても
http://www.curlap.com/products/curl.html
何と比べて？という記載が非常に少なく、速度比較しているのもAjax、Flexです。いずれもクライアント部分はスクリプト言語(ですよね？
)であり、コンパイル言語と比較すると一般的に遅いのが常識、と思っています。コンパイル言語、としての比較はどうなのか？がありません。
上記URLの公式情報だけから判断すると「Curlって他のリッチクライアント言語より速いですか？」という質問に対して「速いですよ」は特別誤った回答ではないですよね？
しかし、上に書いた様にコンパイル言語と比較してどうなのか？についてはないわけです。よって「じゃぁ.NET(で作るEXEなど)よりも速いんですね？」という回答には「わからない」となりますよね？
そういった様に「把握していない情報」という事はどうなんだろ？と思って、お聞きしました。
もしCurl RTEの奥深くの開発を行っている方ならば「ふ～ん、出てない(出せない)けど、技術的にそういった情報をお持ちなんだ」で納得します。
RE: マルチスレッド・マルチコアへの対応について - onyo - 09-08-2011
復活の帝王様、hokada様
とても興味深く読ませて頂きましたので
私見にてお邪魔します。
質問の原点に帰りますが
Curl（クライアントアプリケーション）
でマルチスレッドを有効利用したいと思われるシーンってなんでしょう？
Curlは明示的にスレッドを作成し、制御することはできませんが
シングルスレッドでも非同期処理を行うことが可能です。
一般的にマルチスレッドを利用するメリットは以下になるかと思います。
・レスポンス・タイムの向上
・スループットの向上
私の場合、SOAP通信やORBを利用したシステムにおいて
レスポンス・タイムの向上は課題でしたが
非同期通信を行うことにより、シングルスレッドでも
ユーザアビリティを損なうことなく実現が可能でした。
サーバ処理がマルチスレッドなら
クライアントからの複数リクエストを処理することには
障害はありませんでした。
スループットの向上については
例えば、ディスクにアクセスしているときの
CPU待機時間の利用というのが考えられます。
これについても、非同期処理を利用することにより
性能改善を計ることができました。
スレッド作成とスケジューリングには膨大なCPUオーバーヘッド
がかかり、マルチスレッドにしたからといって速くなるとは限らない
場合もあります。特にクライアントマシンでのCPUでは
この問題は、顕著に現れます。
私見ですが、Webアプリケーションにおいて
マルチスレッド、マルチプロセッサ環境を
効率よく利用するシーンとは
主に、サーバが複数のクライアントリクエストを受付ける
場合に効果を発揮するのではないかと思います。
尤も、クライアント側でマルチスレッドを
実現することがとても有用であるシーンがあるのであれば
なんとも言い難いのですが・・・
.NETの開発にも携わったことがありますが、開発時間と設計コストを考慮したうえで
クライアント側でマルチスレッドを有効利用するシーンに
巡り合ったことが、あまりありません。
私自身は単なるCurlの利用者ですので、
Curlがマルチスレッドに対応しない背景は知りませんが、
簡単に言えば、Curlはシングルスレッドで
必要十分だと思う次第でありました。