マルチスレッド・マルチコアへの対応について

[hmino]

復活の帝王さん、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」では実現不可能な部分については新たなプラットフォームが必要であるとも考えており、研究開発しております。
もちろん「ネイティブアプリケーション」と比較しても負けないだけの「パフォーマンス」は常に追求していくつもりです。

そういった意味でも引き続き、貴重なご意見よろしくお願いいたします。


三野