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

[nmyzk]

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にも一長一短あると思います。)