アカウント名:
パスワード:
まずそもそもHTTPSはキャッシュできない。キャッシュできるように設定することもできるが、常識的にそんなことをしてる奴は居ないだろうし、例えProxyを強制してるようなところでもHTTPSだけはalways_directかつno_cacheとか当たり前。ディスクにもメモリにもProxyにすら存在しないので、例え同じデータでも毎回毎回取りに行かなきゃならん。
無駄に何度も転送することになるので、個人サイト等ではサーバ自体が転送量制限に達っして終了する場合も多いし、転送量制限どころか負荷制限に引っかかって終了する可能性すらある。
次に、TCPが通信を開始する前に3ウェイハンドシェイクを必須とするのはご存知の通りだが、HTTPSは更に3往復必要になる。言わば9ウェイハンドシェイク。
また9ウェイハンドシェクの後に、実際に通信を初める前にその証明書が失効していなかを調べるOCSPの遅さも無視できない。
実際に通信が開始するまでの遅延は絶対に短くならないし、転送量や負荷も間違いなく増大する。つまり、いくらSPDYが効率的に転送可能だろうと無意味。
こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。我々はそのプログラムが実際に開始し、処理し、終了するまでの全体的な評価を求めているのに、内部処理の値だけ取ってきて「Cでするのと殆ど変わりません。」とかやられてるようなもん。妄言も大概にしろ。と言いたい。
一点だけ。httpsでも、キャッシュされます。
http://news.mynavi.jp/articles/2011/02/02/https-stories/ [mynavi.jp]
この手の人にそういうの書いても無駄だよ。どうせ「ボクの周りではみたことないもん!例外だもん!」とか返ってくるだけ。
周りの罪もない人が一見もっともらしい自信たっぷりなコメントに騙されるのを防ぐ意味がある。一対一でメッセージ送り合ってるんじゃないんだから。
>こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。
わはは。あったあった。
by 古参C++プログラマ
>こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。やれやれ。いかにもな老害のご意見。
>内部処理の値だけ取ってきて「Cでするのと殆ど変わりません。」とかやられてるようなもん。たとえばボトルネックを解析して最適化されたインライン展開の機能は無視ですか。「局所部分限定ならC++/CでもJavaと変わりません」とやられてるようなもん。
>我々はそのプログラムが実際に開始し、処理し、終了するまでの全体的な評価を求めているのに、ダウト。特にサーバーサイドでは起動終了のコストなんて無視できるようになる。
PC上で言えば、IEみたいに常駐するという禁じ手があるんだよな。#まあ立ち上がりが遅いという問題については言語に関係無くダウンロードする#コードサイズの問題があるので、MS-Officeみたいにでかいとどうしても遅くなる。
そういう話を考慮しても、C/C++のほうが速いんだよ。http://benchmarksgame.alioth.debian.org/u64q/java.php [debian.org]
けど、Javaの黎明期に、意図的に有利なコードで比較してJavaのほうが速いと主張する、いんちきベンチマークがよくあったんだよ。
いんちきベンチマーク := Javaに有利なコード公正なベンチマーク := C/C++に有利なコード
という用語の定義を最初に書かないと。
「全体的な評価」のくだりはJavaとCを比べるときはそうすべき、という話。今回のHTTP v HTTPS+SPDYで言うと、読み込み速度だけでなく、通信を始める前のハンドシェイクやその他もろもろの時間も計算に入れるべき、と#2724880は言っています。よってあなたの反論は的外れかと。
#わたしもJavaは嫌いですが、そこはオフトピですから、あまり触れないようにしましょう。
>こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。>我々はそのプログラムが実際に開始し、処理し、終了するまでの全体的な評価を求めているのに、内部処理の値だけ取ってきて「Cでするのと殆ど変わりません。」とかやられてるようなもん。>妄言も大概にしろ。と言いたい。
その御蔭で我々は、試行の条件と適用場面をちゃんと確認する癖が付いたのではないかね?感謝して頂きたい。 by Java厨
# まぁ、冗談はさておきJavaを使ってる人間ほど、シビアに使い所を見てると思うよ。# 開始終了が遅いのだから、開始終了関係ない状況で使おうぜ、とサーバ用途が伸びたりとかね。# 早くないからこそどう使うのかとかアルゴリズムを気にしたりもするし。# このベンチマークは、少し胡散臭い所があるのには賛成だよ。# 本当は素のHTTPSとも比べてやったり別のテストケースも見て考えさせるべきだわな。
># 早くないからこそどう使うのかとかアルゴリズムを気にしたりもするし。
ちまちま手動で最適化してた時代に逆戻りしてるような気が…
いくら富豪プログラミングが当たり前な世の中になってもアルゴリズムの選定が重要になる局面は残るよ。
暗号化が一般になりかつ計算機の性能が上がるにしたがっていかに遅いアルゴリズムを開発するかが勝負だったりすることもありますしね。気にする局面は減るとは思いますが、それでもクリティカルな部分では残ります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
NE-YO (スコア:0)
まずそもそもHTTPSはキャッシュできない。
キャッシュできるように設定することもできるが、常識的にそんなことをしてる奴は居ないだろうし、例えProxyを強制してるようなところでもHTTPSだけはalways_directかつno_cacheとか当たり前。
ディスクにもメモリにもProxyにすら存在しないので、例え同じデータでも毎回毎回取りに行かなきゃならん。
無駄に何度も転送することになるので、個人サイト等ではサーバ自体が転送量制限に達っして終了する場合も多いし、転送量制限どころか負荷制限に引っかかって終了する可能性すらある。
次に、TCPが通信を開始する前に3ウェイハンドシェイクを必須とするのはご存知の通りだが、HTTPSは更に3往復必要になる。
言わば9ウェイハンドシェイク。
また9ウェイハンドシェクの後に、実際に通信を初める前にその証明書が失効していなかを調べるOCSPの遅さも無視できない。
実際に通信が開始するまでの遅延は絶対に短くならないし、転送量や負荷も間違いなく増大する。
つまり、いくらSPDYが効率的に転送可能だろうと無意味。
こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。
我々はそのプログラムが実際に開始し、処理し、終了するまでの全体的な評価を求めているのに、内部処理の値だけ取ってきて「Cでするのと殆ど変わりません。」とかやられてるようなもん。
妄言も大概にしろ。と言いたい。
httpsでもキャッシュされます (スコア:2)
一点だけ。httpsでも、キャッシュされます。
http://news.mynavi.jp/articles/2011/02/02/https-stories/ [mynavi.jp]
Re: (スコア:0)
この手の人にそういうの書いても無駄だよ。
どうせ「ボクの周りではみたことないもん!例外だもん!」とか返ってくるだけ。
Re: (スコア:0)
周りの罪もない人が一見もっともらしい自信たっぷりなコメントに騙されるのを防ぐ意味がある。一対一でメッセージ送り合ってるんじゃないんだから。
Re: (スコア:0)
>こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。
わはは。あったあった。
by 古参C++プログラマ
Re: (スコア:0)
>こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。
やれやれ。いかにもな老害のご意見。
>内部処理の値だけ取ってきて「Cでするのと殆ど変わりません。」とかやられてるようなもん。
たとえばボトルネックを解析して最適化されたインライン展開の機能は無視ですか。
「局所部分限定ならC++/CでもJavaと変わりません」とやられてるようなもん。
>我々はそのプログラムが実際に開始し、処理し、終了するまでの全体的な評価を求めているのに、
ダウト。
特にサーバーサイドでは起動終了のコストなんて無視できるようになる。
PC上で言えば、IEみたいに常駐するという禁じ手があるんだよな。
#まあ立ち上がりが遅いという問題については言語に関係無くダウンロードする
#コードサイズの問題があるので、MS-Officeみたいにでかいとどうしても遅くなる。
Re: (スコア:0)
そういう話を考慮しても、C/C++のほうが速いんだよ。
http://benchmarksgame.alioth.debian.org/u64q/java.php [debian.org]
けど、Javaの黎明期に、意図的に有利なコードで比較してJavaのほうが速いと主張する、いんちきベンチマークがよくあったんだよ。
Re: (スコア:0)
いんちきベンチマーク := Javaに有利なコード
公正なベンチマーク := C/C++に有利なコード
という用語の定義を最初に書かないと。
Re: (スコア:0)
「全体的な評価」のくだりはJavaとCを比べるときはそうすべき、という話。
今回のHTTP v HTTPS+SPDYで言うと、読み込み速度だけでなく、通信を始める前のハンドシェイクやその他もろもろの時間も計算に入れるべき、と#2724880は言っています。
よってあなたの反論は的外れかと。
#わたしもJavaは嫌いですが、そこはオフトピですから、あまり触れないようにしましょう。
Re: (スコア:0)
# ハッシュ値でなんとかならんのかと思うよ。
Re: (スコア:0)
>こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。
>我々はそのプログラムが実際に開始し、処理し、終了するまでの全体的な評価を求めているのに、内部処理の値だけ取ってきて「Cでするのと殆ど変わりません。」とかやられてるようなもん。
>妄言も大概にしろ。と言いたい。
その御蔭で我々は、試行の条件と適用場面をちゃんと確認する癖が付いたのではないかね?
感謝して頂きたい。 by Java厨
# まぁ、冗談はさておきJavaを使ってる人間ほど、シビアに使い所を見てると思うよ。
# 開始終了が遅いのだから、開始終了関係ない状況で使おうぜ、とサーバ用途が伸びたりとかね。
# 早くないからこそどう使うのかとかアルゴリズムを気にしたりもするし。
# このベンチマークは、少し胡散臭い所があるのには賛成だよ。
# 本当は素のHTTPSとも比べてやったり別のテストケースも見て考えさせるべきだわな。
Re: (スコア:0)
># 早くないからこそどう使うのかとかアルゴリズムを気にしたりもするし。
ちまちま手動で最適化してた時代に逆戻りしてるような気が…
Re: (スコア:0)
いくら富豪プログラミングが当たり前な世の中になっても
アルゴリズムの選定が重要になる局面は残るよ。
暗号化が一般になりかつ計算機の性能が上がるにしたがって
いかに遅いアルゴリズムを開発するかが勝負だったりすることもありますしね。
気にする局面は減るとは思いますが、それでもクリティカルな部分では残ります。