C などの言語が最終的に Web 開発に使用されなかったのはなぜですか? 確かに、コンパイルによる速度の向上は、負荷の高いサイトに役立つでしょうか?
15 に答える
もう1つの理由は、大きなサーバーでは、実行速度は接続速度ほど問題ではないということです。ほとんどの時間はデータの送受信に費やされており、数の計算には費やされていません。実際、多くの計算を行う特定のWebサービスでは、ハードクランチはコンパイルされたプログラムとして実行される可能性があります。
さらに、インタプリタ言語はコンパイルする必要がないため(大規模なプロジェクトでは時間がかかる場合があります)、通常はアジャイルなWebソリューションの開発に適しています。
ほとんどの Web アプリケーションはデータベースと通信します。これらのアプリの圧倒的多数は、ほぼすべての時間をデータベースとの通信に費やしています。そのため、アプリケーションへの任意のリクエストに対して、アプリケーション サーバーで少量の処理が行われ、データベースを待つ間に長い一時停止が発生します。リクエストの時間のうち、実際のアプリケーション サーバー コードで費やされる割合は非常に小さいため、C/C++ でコードを記述して最適化しても、応答時間はほとんど目立たないほどわずかに改善されます。
したがって、C/C++ に集中して最後の CPU サイクルをすべて節約するよりも、開発者の生産性を心配する方が理にかなっています。開発者は非常に高価です。また、通常、C/C++ よりもスクリプト言語や Java の方がはるかに生産的です。
もちろん、これには例外があります。また、アプリケーションへの一部の要求が CPU またはメモリを集中的に使用する場合は、C/C++ で記述する必要があります。ただし、アプリケーションの残りの部分については、言語を最適化するよりも、アルゴリズム、データ構造、データベースとの通信、および開発者の生産性を最適化することに集中した方がよいでしょう。
スクリプト言語には、C に比べて次の利点があります。
- はるかに高速な開発
- 現在、この質問に関連するものはすべて実行時にコンパイルされています。場合によっては、これにより同等の C プログラムよりも高速になる可能性があるため、パフォーマンスはもはや問題ではありません。
- メンテナンスコストが大幅に削減
- アジャイル手法 (単体テストなど) を使用して開発することで、はるかに優れたコードを作成できます。ええ、Cでもそれを行うことができますが、それははるかに手間がかかります.
- Web 開発を行っている場合、ほとんどの作業を行う巨大なフレームワークがあります。
- 彼らは変化に対してはるかにオープンです。新しい機能の実装には数分かかる場合があります。
- 何かが壊れている場合は、サーバーにログインし、コンソールでテキスト エディターを起動して問題を修正できます。再起動する必要がない場合もあります。
Cは早い段階でWebアプリケーションに使用されていました-私はそれにさまざまなCGIスクリプトを書きました。
ただし、時間の経過とともに、より生産性の高い言語(たとえば、C#やJava-もちろんこれらだけではありません)は、Webアプリケーションにとって「十分に効率的」であることが証明されています。C#とJavaの両方が中間コードにコンパイルされてからJITコンパイルされることに注意してください。これにより、「ほぼ」ネイティブコードのパフォーマンスが実現されます。なぜ代わりにCを使用したいのですか?
PHPのような伝統的な「本物のインタプリタ」言語でさえ、私が知る限り、最近では実行時にコンパイルされることがよくあります。(特にPHPに関する私の知識はすべて中古品です。たぶんそれは常にコンパイルされています...そして同様に、常に解釈されるWebプラットフォームがあると確信しています。)
少なくとも最初は、バックエンドコード(私はあなたが話していることだと思います)によって行われた作業の多くはテキスト指向でした。彼らは、最初から直接ページを作成するか、データベースのデータとテンプレートを組み合わせてページを作成しました。
Cは...常にテキスト処理に適しているわけではありません。C文字列は非常に基本的であり、もちろんCでのテキスト処理は高速に実行できますが、開発に少し時間がかかることが多く、正しく理解するには、もう少し役立つ言語よりもいくらか深いスキルが必要です。
ほとんどのスクリプト言語 (Python、Ruby など) は、C への橋渡しが簡単に (ほとんど些細なことで) あることを指摘しておく価値があります (私は Python プログラム用の C 拡張機能をいくつか書きましたが、その簡単さに感銘を受けました)。 「遅い」スクリプト言語を使用しているために Web サイトや Web アプリケーションにボトルネックがある場合は、通常、パフォーマンスが重要なセクションを C などのより高速な言語で記述できます。などは、スクリプト言語でインターフェイスを記述し、C などの他の言語で面倒な作業を行います。
素晴らしい質問です。その理由は基本的にウェブの進化によるものです。次の手順で考えてみましょう。
1) Basic text on the 'net' -> 2) Some 'markup' added to text -> 3) the "center" tag and "marquee" are formed!!! what progress!!! -> 4) scripting on the client!!! 5) -> hmm... scripting on the server!!!
While I formed this answer to be a bit goofy, it's really true. The interenet, and most especially the "web", has been an amazing evolutionary process. Really, requirements for more powerful languages (and more performant languages) has only been a more recent thing.
Also, look at the tools. I did my PHP in notepad (and some other simple apps). When I was first doing web development, my computer didn't have enough harddrive space to support Visual Studio 2008 :)
余談ですが、「.exe」アプリ (「 SunBiz 」は「exe」に投稿されると思います) があり、しばらくの間、いくつかのコンパイル済み CGI アプリがありましたが、それらははるかに少なかったです。
それは主に、その場でそれらを変更するのが迅速かつ簡単だからです。コンパイルされた言語には、サーバーと一致する必要がある開発環境が必要です。スクリプトを使用すると、ftpツールを使用してテキストを直接編集し、保存することができます。任意のOSまたはタイプの任意のコンピューターからこれを実行するこの機能により、私の命(または正しくは私のWebサイトの命)を何度も節約できました。
C と Perl/PHP で文字列の解析/操作を行ってみればわかるでしょう。
ところで: パフォーマンスはもはや問題ではないと多くの人が述べているのはなぜですか? 小さなホームページ/ブログでは問題にならないかもしれませんが、大規模な Web アプリケーションは、Java、PHP、または Ruby で記述されているかどうかに関係なく、パフォーマンス (CPU/ネットワーク/メモリ) を調整する必要があります。
したがって、C/C++ に集中して最後の CPU サイクルをすべて節約するよりも、開発者の生産性を心配する方が理にかなっています。開発者は非常に高価です。また、通常、C/C++ よりもスクリプト言語や Java の方がはるかに生産的です。
ああ、非常に、非常に真実です。より動的な言語を使用することで開発者の 1 週間がスケジュールから削られた場合、支払う必要のないその 1 週間のプログラマーの時間は、追加のサーバーを購入することになります。いくつかの巨大な獣の代わりにたくさんの安価なサーバーが好きなら、おそらく複数のサーバー.
世界のほとんどの場合 (つまり、Google/Amazon/eBay などではありません)、サーバーを 1 台追加するだけで、言語の選択に起因する生のパフォーマンスの損失を十分に補うことができます。
この問題に関する私の考えは次のとおりです。
- 元の CGI アプリケーションには独自の OS プロセスが必要でした。これはもちろんリソースを大量に消費します。すべてを単一のプロセスにバンドルしようとすることも、ネイティブ コードでは簡単ではありません。アプリケーションで何か問題が発生すると、サーバー全体が簡単にダウンする可能性があるからです。これらは、インタープリターまたは仮想マシンを使用すると、はるかに簡単に処理できます。もちろん、ネイティブ コードでも同じことができますが、フレームワークを実装するのははるかに難しいと思います。最終的には、インタープリターや VM に似たものを実装することになります。
- 解釈された言語は、オペレーティング システム間で移植可能です。
- もちろん、大きな利点は、現代語を使用することで得られる生産性の向上です。
- もちろん、パフォーマンスは重要です。ただし、インタープリター言語または VM 言語は、この点で (JIT コンパイルなどのテクノロジを使用して) ますます良くなり、ネイティブ コードのパフォーマンスに近づきつつあります。また、実行プロセスに費やされた時間だけを比較するのは公平ではありません。サーバーからのリクエストの受信、適切なアプリケーションへの委譲、実行、サーバーへの結果の返信など、一連のシーケンス全体を測定する必要があります。これらすべてにおいて、ネイティブ アプリケーションの方が高速でしょうか?
イントロスペクションや eval() のような関数など、動的言語の非常に便利な機能の多くは、本当に難しい/不可能ですか? ネイティブ コードにコンパイルされる言語で実装します。
そうは言っても、ほとんどの「スクリプト」言語は、ある種の中間コードに (オンザフライで) コンパイルし、それを解釈 (Python、Ruby、Perl) するか、JIT コンパイルしてネイティブ コード (JSP、.NET) にすることさえできます。
私の会社では、Web アプリケーションに C++ (ISAPI 拡張機能) を使用しています。ほとんどすべてがコンパイルされたバイナリで行われます。また、スクリプトを必要とするシステムの部分には JavaScript エンジンを使用しています (そうです、サーバーサイド JavaScript)。この設計の理由は速度ですが、年齢も要因です...これは古いコードベースです。また、製品を一部の顧客に配布してホストするようにしています。そのため、コンパイルするとソース コードが保護されます (多くの解釈された言語は簡単に逆コンパイルできます。PHP と Perl の場合は、まったくコンパイルされません)。
業界は、実行速度は問題ではないという大規模な妄想に苦しんでいるためです(受け入れられた回答で示されているように)。
本当の理由は、既存のフレームワークを使用するとインタープリター言語の方が使い始めやすく、Web アプリケーションでの作業が簡単で楽しいように見えるからだと思います。
実際に Web アプリケーションで数値計算を行う必要があるケースは非常に多くありますが、開発者は (コストがかかるため) それらを実行しないか、タスクを外部サーバー (データベース サーバーまたはその他のサーバー) に委任することになります。他のサーバー。
これは、いわゆる「マイクロ サービス」アーキテクチャの最近の急増に見られます。
昔のWeb開発の唯一の選択肢であるスクリプト言語。現在、他の選択肢(Java、.NET ..)があるので、状況はそれほど悪くありません。
プラットフォームとしてのCは、Web /アプリケーションサーバーからロードして実行できるモジュールを構築するのが難しいため、Web開発ではあまり成功しませんでしたが、動的Webアプリケーションを構築するための最初のフレームワークの1つは、主にMicrosoftのIIS用のISAPIモジュールでした。 C ++で開発され、コンパイルされた場所。