+- 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
RE: マルチスレッド・マルチコアへの対応について - hokada - 09-08-2011
>> 最後に、マルチスレッドが今のCurl RTEに非常に大きな性能劣化を起こしているというような問題は今のところありません。
> hokada さんのCurlに対するポジションが分からない(例：住商の方、Curlの一開発者、Curl RTEの開発者・・・等々)＋「大きな」は主観なのですが・・・
> これについて、言い切れる根拠は何なのでしょうか？「把握していないだけ」ということではないでしょうか？
小職はCurl製品の開発チームです。「[/font][/color]疑似的な(？)マルチスレッドで性能劣化を起こしているのでは？」という質問に対して、Curl RTEは内部的にマルチスレッドで動いていますが、その仕組み上で性能問題を抱えていることは、内部で管理しているバグとして、現在のところ存在しておりませんという意味です。また、ユーザが利用できるサブアプレットでも、性能問題はあがっておりません。もちろんおっしゃられる通り、共有メモリとIPCでは速度が違うというのはありますが、それが非常にボトルネックなっているという報告も今のところ受けておりません。（逆にそういった現象があれば、是非報告いただければと思います。）
ちなみにCurlの内部的な仕組みは公開しておりませんので、これより深い説明は公開できないことをご了承ください。
> ... 速度比較しているのもAjax、Flexです。いずれもクライアント部分はスクリプト言語(ですよね？)
Flex（Action Script）はコンパイルされ、swf形式になります。
> 上記URLの公式情報だけから判断すると「Curlって他のリッチクライアント言語より速いですか？」という質問に対して「速いですよ」は特別誤った回答ではないですよね？
弊社内部では他社製品との比較はもちろん行っております。しかし、一般公開できるものではありません。ご了承ください。ただし、確認したところCurlユーザー企業様ではやはりそういった他社製品との比較を行っているようで、Curlが勝つ部分と.NETが勝つ部分様々なのが正直なところです。ただし、われわれとしましてはこのような部分についても今後改善していくようにしていくつもりです。
RE: マルチスレッド・マルチコアへの対応について - nmyzk - 09-08-2011
onyoさんの意見に賛成です。
復活の帝王さんは上位設計からの検討に影響が……とかかれてましたが、
C/S→Web→リッチクライアントという技術の変遷を辿ると
単純にC/Sと同様の考え方(マルチスレッド/マルチコア対応)というのは
必ずしも必要でないと思います。
誤解を恐れずに述べるのであれば、
現在のシステム構成の傾向は、冗長化あるいはクラウド化したサーバに
主処理を集約させておき、クライアントには
必要最低限の処理を行わせるのが一般的に思います。
リッチクライアントが出てきた当初は
ここまでサーバの処理能力が上がると思われていませんでしたから、
クライアントが行う処理を増やす設計を行う事が
リッチクライアントアプリケーションに必要でした。
しかし現在は、いわゆるビジネスロジックはサービス化してサーバ側ににおいて、
クライアントはそのやりとりとGUIだけに特化させる考え方を取る方が
開発の効率も良いと思います。
そうした時に、別に難しいスレッド管理で複雑な処理を考えなくても
非同期通信などで事足りるCurlは必要十分な機能を満たしていると思います。
.Netの開発経験も有りますので双方の技術はそれなりに知見を持っているつもりですが、
最近.Netで別にスレッド管理するプログラムを構築したことはありません。
非同期通信や非同期のプロセス呼び出しなどで大概の事が実現できるため、
Curlも.Netもあまり大きな違いは感じないと思います。
(Curlは以前は出来なかったようですが、Ver8から非同期のshell実行も出来るようです。)
復活の帝王さんは盛んに処理速度の事を上げていますが、
上記の視点(クライアントの処理をGUIに特化させる)で考えた時に
体感出来るほどの処理速度の違いは無い様に思います。
どちらかと言うとCurlの方が遅いかもしれませんが、
その分Curlはマルチプラットフォーム、サーバ非依存という性質を持っています。
.NetはあくまでWindowsのみ、かつバージョンにより対応OSも細かく分かれますので
その点は不利と言わざるを得ないかもしれません。
ただ、あくまでニュートラルな立場で意見を申しますと
テクノロジーというか、開発環境においては.Netの方が優れていますね。
Visual Studioでの開発において、プログラミングの必要な箇所を
ほぼビジネスロジックのみに集約できるのは素晴らしいの一言に尽きます。
Curlは.Netと比べAPIの豊富さや柔軟さはありますが、
どうしてもレイアウトの調整やイベントの設定など
細かな所でプログラミングが必要ですから、その点は劣っていると思います。
まあ、集団開発における開発の自動化と効率化については
様々な考えがあり、一概にどちらが正しいとは言いかねるのですが。
(その点はVisual StudioにもCDEにも一長一短あると思います。)
RE: マルチスレッド・マルチコアへの対応について - 復活の帝王 - 09-08-2011
onyoさん、hokadaさん
返信ありがとうございます。
＞onyoさん
今回の背景にあるのは、あるアプリケーション(Win32ネイティブ)を移行するにあたり、Curlで作成したら？との仮定からです。
私個人は「もとがローカルアプリなんだから、EXE作れば(＝Windowsフォームで作る)良いんじゃないの？」との思いだったのですが
Curlでは無理なのか？という話から検証している次第です。
Windowsフォームで作るのとどういう違いが出てどういうアドバンテージがあるのか？何が苦手なのか？を調べている途中です。
前提が伝わっていなくて申し訳ありません。
ちなみに私は.NETでのGUI開発において、スレッドがなければ話にならなかった事を逆に経験しています。
もっとも、他に実現手段がないのか？という点については精査していません。
＞hokadaさん
書き込み内容からもしかして？とは思っていましたが、中の人(？)ということでしたか。それならば納得です。
Flexの件は失礼しました。一応調べたのですが、使ったことがなかったので・・・ごめんなさい。
一般公開の件も企業秘密（？）ということでしたら仕方ありません。
なお最後に中の人と知っての話ですが。
実際にCurlで作られているシステムをこの２年担当している者としては機能的な面、速度的な面、開発者視点、において.NETでの開発と比べ期待を裏切られた事が多々あります。
こちらから公式に問題として挙げていないということもあるかと思いますし、こちらの作りが悪いことに起因することもあるかと思います。
しかし.NETで作った過去のシステムだと始末書ものの問題、品質が挙がっていることも事実です。(エンドユーザが違うからなのですが)
(レアケースかもしれませんが)中の人が知らない(いや、ご存じなのかもしれませんが)問題もユーザサイドで起こっていることをご留意頂ければ幸いです。
RE: マルチスレッド・マルチコアへの対応について - 復活の帝王 - 09-08-2011
nmyzksさん
入れ違いになりましたm(__)m
> 復活の帝王さんは盛んに処理速度の事を上げていますが、
> 上記の視点(クライアントの処理をGUIに特化させる)で考えた時に
> 体感出来るほどの処理速度の違いは無い様に思います。
これは現在の流れがそう、という事からそう言われていますが「現在の流れがそうだから、クライアントの処理をGUIに特化させる」
というシステムサイドの要求が通るかは不明であり「だから違いはないだろう」という話の進め方にはいささか違和感を覚えます。
相変わらずローカルアプリケーションは存在する訳ですし、全てのアプリがその様な流れではないですよね？
> .NetはあくまでWindowsのみ、かつバージョンにより対応OSも細かく分かれますので
> その点は不利と言わざるを得ないかもしれません。
Windowsのみ、という点はその通りですが、意地悪な言い方をすれば
「現在のクライアント側の構成は、Windowsが主流であり、Linuxなどはサーバ側のOSが主であると一般的に思います。」
となり
「マルチプラットフォームという点を挙げられていますが、上記の視点で考えた時にそれほどの違いは無い様に思います。」
となります。また「バージョンにより対応OSも細かく分かれますので」についてはCurlも同じと認識しているのですが違いますか？
RE: マルチスレッド・マルチコアへの対応について - hokada - 09-08-2011
復活の帝王さん
> (レアケースかもしれませんが)中の人が知らない(いや、ご存じなのかもしれませんが)問題もユーザサイドで起こっていることをご留意頂ければ幸いです。
逆に、いろいろなニーズや問題点などをいただけると、今後製品の方向性を検討する材料としていけるので助かります。そういったニーズの収集もこのコミュニティサイトを立ち上げた理由の一つです。
今後ともよろしくお願いいたします。
RE: マルチスレッド・マルチコアへの対応について - hmino - 09-08-2011
復活の帝王さん、onyoさん、nmyzkさん
はじめまして。
マーケティングの三野と申します。
皆さま、貴重なご意見ありがとうございます。
速度比較についてはいつもついてまわりますね。
本線とはそれるかもしれませんが、別視点で「速度」についてコメントさせていただきます。
Curlの思想はもともと「Web上でクロスプラットフォームでハイパフォーマンス動作する」という思想のもと作られています。
その思想のもと、考えられたのが、「Curl言語」、「JITコンパイル方式」、また「ソースコード配信」です。
メリットとしてはソースコードベースなのでクライアントへのモジュールのサイズが小さいことや１つのソースで管理できることなど様々あります。そのため、サイズは通信速度に依存してくるため、通信速度が様々な場合、.NETアプリケーションとCurlアプリケーションでの初期起動の場合は圧倒的にCurlのほうが「速い」です。
ただし、JITコンパイル方式のため、クライアントでのコンパイルコストがネイティブアプリケーションよりも多少かかることや、コンパイラ、エンジンの「Curl RTE」１つで様々なプラットフォームを吸収しているためのコスト(ここは内部仕様なので詳しく話せませんが)など「アプリケーションが起動するまでの「速度」」に関してネイディブのアプリケーションと比べると若干遅い場合があるのは認識しています。しかし、この部分についても2回目以降の起動を「速く」するため、パッケージキャッシュの機能をCurlは用意しています。
ちなみに.NETアプリケーションはやはり「ネイティブアプリ」と認識しており、リッチクライアントのカテゴリに入ってはいるものの「ノータッチデプロイメント」、「UpdaterApplicationBlock」を経て（前記２つの方式は問題あったようです。）、「ClickOnce」という技術を用いて1クリックでインストールができるようになっただけと認識しております。
.NETの出現の背景は昔でいうところの「DLL Hell」問題を解決するために出てきたと思いますが、出てきた当初はアプリケーションのモジュール単位の更新ができないなど問題など様々あったと思います。今では「Side by Side機能」などによって解決されていると思いますが。
また、.NETはやはり「Windows」依存があると思いますが、その.NETの世界をWebへ持ち込むコンセプトで打ち出されたのが「SilverLight」です。以前MS、Adobeの方とディスカッションする機会があるときにそう言っておりました。
Curlの場合は「Curl RTE」はインストールする必要がありますが、ユーザーが作ったCurlアプリケーションは「インストール」されるわけではありません。通常はメモリ上に展開されるだけです。
しかしVer４以降、オフラインでの利用も考慮し、新たに「OCC（随時接続コンピューティング）」の機能を追加したのもありますが、それはCurlのセキュリティポリシーを保ったうえでのアーキテクチャになってます。（セキュリティの考え方については長くなってしまうのでここでは割愛させていただきますが）
Curlは「Curl RTE」という１つのプラットフォームで「ネイティブアプリケーション」「Webアプリケーション」のどちらともの「いいところ」を取り入れていこうと考え、拡張しております。
それを「Curl言語」という１つの言語で開発できることもメリットだと考えています。
また、将来「Curl RTE」では実現不可能な部分については新たなプラットフォームが必要であるとも考えており、研究開発しております。
もちろん「ネイティブアプリケーション」と比較しても負けないだけの「パフォーマンス」は常に追求していくつもりです。
そういった意味でも引き続き、貴重なご意見よろしくお願いいたします。
三野