スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記

さて話題を紹介してみます









■スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記■より



ruby, python, php | 09:06 | 大変たいへん興味深い記事。全プログラマーにとって。HDDの代わりにSSDを利用したら、リレーショナルデータベースの性能はどれだけ向上するのでしょうか？ オラクルと富士通が共同検証を行い、その結果をホワイトペーパーとして先週発表しました...(snip)...HDDは200スレッドで性能が頭打ちなのに対し、SSDは200スレッドから300スレッ...








そのほかSQL/クエリ/DBプログラム…Web系プログラム・データベース情報で探せますよ。

そのほかの評価は↓
[ このロジックが当てはまるのは極々一部。スクリプト言語が成り立つのはボトルネックがとうとかではなく単に言語の速度差など人件費に比べたら微々たる金額の設備投資で埋め合わせることができる。考えるべきはスケー ]
[ なかなか刺激的……だが、コメント読んだらあり得ない指摘にも思えてきた。うーむ。 ]
[ スクリプト言語で書いていないであろうDBエンジンのCPUボトルネックの話のはずだが…／SSDで息の根が止まるくらいなら、最初から息をしていない。 ]
[ なるほど。コメントで、スクリプト言語はコンパイルが要らないからいいんだとか、開発・メンテナンスが楽とか多いけど、pythonでのpycファイルがもっとコンパイルされた状態になるような進化の方向性はないかな。 ]
[ 好きで使ってる人がたくさんいるからなくならないでしょ。でも、面白い視点ですね。 ]
[ スクリプト言語みたいに使い易い静的言語->Scalaは? ]
[ webアプリならＤＢ速くなってスクリプト言語で十分なレスポンス→採用では／ＳＷアーキ如何で変わるし・・・ ]
[ スクリプト言語のメリットって、速度がどうたらとかじゃなくて、「コンパイルが要らない」ってことなんじゃなかったっけ ]
[ スクリプト言語の存在自体が、今のソフトウェア開発で重要なのは実行速度だけではないということを意味すると思う。 ]
[ 一読して「おぉ」と思ったけど、これってSQLサーバーがボトルネックになってるって話のような気がしないでもない。 ]
[ 新しい視点ですねっ ]
[ スクリプトの実行速度は問題になるほど遅くないし、問題になってもPHPならHipHopのような解決もある。開発、メンテコストも考えてよね。けっきょく同じこと言ってる。要するにタイトルで釣るなと。 ]
[ 面白い論ではあるが、スクリプトを使う人の感情としては処理測度よりコンパイルが無い作り易さだと思う。 ]
[ 実際のアプリケーションで5倍とか10倍はないような ]
[ 非常に興味深いですねそういえばホリエモンがiPhoneがすごく軽快なのはオブジェクティブCだからなのかもとか言ってたな ]
[ パフォーマンスはメリット多いんだろうけど運用保守的な部分のメリットデメリットはどうなんだろうね。ファイルコピーとかも早いだろうからバックアップとかは良さそうだけど。SSD採用は現状、やっぱりコストが一番ネ ]
[ おおなるほど。こういう可能性もあるねぇ。／軽量言語が使われるのは、他に開発速度と技術者調達の都合もあると思うけどね。 ]
[ SSDが当たり前になるのかなあ。 ]
[ いいぞ!もっとやれ! ]
[ コメント欄nonameみたいなスクリプト言語使えないようなやつらからみたらこういうエントリは嬉しくて、スクリプト言語でも飯食ってるやつらは釣られる ]
[ スクリプト言語の使いやすさを取り入れようとして、C#はどんどん複雑になってるよ ]
[ スクリプト言語って意味不明。インタプリタ言語のこと?動的型付け言語のこと?//あと、SSDがそこまで高速化する未来よりも、メモリ大容量化で全てがオンメモリで処理される未来の方が近いと思う ]
[ 先にCPU性能の方がボトルネックとなってしまったようです。 ]
[ RDBMSを使う場合、アルゴリズムもSQLでできる部分はSQLで書く（のが一番速い）わけだから、大差は付かないのでは ]
[ SSDによって、ディスクアクセスやDBがボトルネックにならなくなり、CPUのボトルネックになった結果、スクリプト言語の遅さがそのままボトルネックになってしまう可能性が出てきたという話。 ]
[ この発想を持ってなかった ]
[ RTrubypythonphpスクリプト言語の息の根を止めるのは案外SSDかもなB!http://dlvr.it/f1N5 ]
[ 言語がハードウェア依存の時代ってまだ続いてたのねカﾞクシ ]
[ 処理速度と開発速度って関係性も出てくるだろうけどね ]
[ スクリプト言語の息の根を止めるのは案外SSDかもな-kwatchの日記:スクリプト言語の息の根を止めるのは案外SSDかもな-kwatchの日記ruby,python,php｜09:06｜大変たいへ... ]
[ “パフォーマンス”を単純化しすぎ。そんなんでスクリプト言語の息の根が止まっていたら、元々流行ってないと思う。 ]
[ ついでにヘタレプログラマの息も止めてくれるととありがたい。無理か…。 ]
[ SSDが主流になったらそうなるかもね、でも将来SSDが主流になると決まった訳じゃなく、新技術がぽんと出たら、SSDを一気に飛び越えてしまうかもしれないし。いやロードマップ知らないから断言できないけど。 ]
[ たしかに興味深い見方だけれど、もっといろんな視点でみないといけないと思う。 ]
[ なるほどー。ssdの価格と「極めて高速なソフトウェア」のニーズの動向次第ではあるいはあるかもなー。 ]
[ DBへのアクセスがボトルネックの時代が終わるかも?と言う話。スクリプト言語どうこうはいろんな見方があるから何とも ]
[ 長く続いたDiskI/Oボトルネックの時代が終わり，CPUボトルネックの時代が来る，という話。データストアの多重化は困難でも処理スレッドの多重化は容易だから，必ずしもそうなるとは限らないとは思うけど。 ]
[ Javaは動的スクリプト言語とか、単なるDBの問題じゃとかいろいろつっこみどころはあるけど面白いな ]
[ でも、それはCPUがボトルネックになるような処理速度を要求されるシステムの場合。普通のサーバで余裕のある処理だったら、そもそもボトルネックが存在しないことになるし、そうなると開発や保守の費用で決まる。 ]
[ はっ? ]
[ 興味深い記事。ただネットワークが早くならない限りはローカルな問題な気がする。 ]
[ かもしれないけど、まだ断言出来ないな。たまたま今回のベンチではCPUが頭打ちになったけど、処理速度においてコンパイラ＞スクリプトというのは既定ラインの話で、本来は使い分けられるべき物だからなぁ。 ]
[ 興味深すぎる ]
[ SSDは読み書きをきちんとコントロールしないと「（ハードウェア設計上の）寿命」がくる危険が。。。 ]
[ ウェブアプリ的なシステムならアプリケーション側は容易にスケールアウトできるし、すべてはアーキテクチャ次第ではなかろうか。 ]
[ ありえんティ ]
[ 「スクリプト言語の使いやすさ」のかなりの部分はスクリプト言語（動的言語）であることが担保してるんだから、「スクリプト言語並みに使いやすい静的な言語」って命題が無理筋ではなかろうか ]
[ C:スクリプト言語の息の根を止めるのは案外SSDかもな-kwatchの日記: ]
[ CPUやメモリの技術発展が著しくて動的言語でもパフォーマンス上問題がなくなる、っていうのを読んだことがあるんだけど全く逆?の見方をするんだナー ]
[ 環境や目的に応じて言語を変えるのは今に始まったことではないし、現在でも古い言語は使われている。 ]
[ そもそもプラットフォームを問わないのが利点なんじゃないの?Cじゃ、ねぇ。 ]
[ ディスクアクセスやDBがボトルネックにならない（あるいはなったとしてもペナルティが少ない）ような時代になったら、言語の速度差がそのままアプリケーションの動作速度になる可能性がある>なるほどなー。 ]
[ なるほど。やばいね! ]
[ ボトルネックがディスク→CPUになる可能性はあるけど、そうなったらCPUはもっと早くなってバランスしてくるはず。あとスクリプト言語vs静的言語という図式はもう終わっている ]
[ ぐはっ!そういう時代か!?： ]
[ いやこれは「ないわー」ってことではなくて「世の中どこになにがあるかわかったもんじゃない」ってことではないのかなあ。Matzいうところの「泳がないマグロは死ぬ」みたいな意味で。 ]
[ 『もうそろそろ「スクリプト言語並みに使いやすい静的な言語」が主流になって欲しいよね』 ]
[ ディスクアクセスやDBがボトルネックにならない（あるいはなったとしてもペナルティが少ない）ような時代になったら、言語の速度差がそのままアプリケーションの動作速度になる可能性がある ]
[ その未来にはスクリプトもJITコンパイルされて普通の言語と差が出ないんじゃないかな。だれか頭のよい人がやるさ。 ]
[ 「ディスクアクセスやDBがボトルネックにならない（あるいはなったとしてもペナルティが少ない）ような時代になったら、言語の速度差がそのままアプリケーションの動作速度になる可能性がある」確かに。 ]
[ 静的言語でもNetworkIOってボトルネックにならないのかな。あとスクリプト言語のメリットって保守のしやすさも大いにあると思う。 ]
[ マジかよ糞スクリプト売ってくる ]
[ スクリプト言語の息の根を止めるのは案外SSDかもな ]
[ ユーザサイドで動作するスクリプト言語はなくなったりはしなさそうだけれども。 ]
[ SSDが主流になり、ディスクアクセスやDBがボトルネックにならない（あるいはなったとしてもペナルティが少ない）ような時代になったら、言語の速度差がそのままアプリケーションの動作速度になる可能性がある ]
[ 「言語の実行速度」が重要ならCommonLispの出番のような気がするが。 ]
[ 時代によって重要視される技術は変わっていく。スクリプト言語を使うのが大きく不利になれば、他の言語を使えば良いだけの話。 ]
[ それは無いと思うな。人やコードのコストが根本的な問題。CPUがネックならそこだけ高速化するし多重処理に振ればよい。viahttp://www.twitter.com/tamaki8810/status/12916488918 ]
[ ApacheのCGIもC言語で書くんですよね分かります。 ]
[ OCamlは知らない人が多すぎる気がwOCaml、Haskellらへんの関数型でコンパイラって遅いのかな。自分はスクリプト猟色してるからよくないな〜。でもプログラムが冗長すぎるのがあんまりすきじゃないな。言語にこだわらない方 ]
[ もうそろそろ「スクリプト言語並みに使いやすい静的な言語」が主流になって欲しいよね。もともと速度的に不利なスクリプト言語を一生懸命高速化するよりも、そっちのほうがあるべき姿だと思うんだけど、賛同者はお ]
[ スクリプト言語が担当するレイヤーはスケールアウトさせられるから大丈夫じゃないかなあ。これからはどんどんCPUコア数も増えてくることだし。 ]
[ スクリプト言語の見方は多々ある。SSDをそう見たことはなかったな ]
[ スクリプト言語が実用的に使われたのは速度差がそのままアプリの速度差にはならないから。SSDでI/O（DBなど）がボトルネックにならなくなると言語の速度差がそのままアプリの動作速度になる可能性がある ]
[ アプリケーションとDBが同じ筐体にのってるのですか。 ]
[ やはり、次はscalaかな。RT@yukihiro_matzスクリプト言語の息の根を止めるのは案外SSDかもな-kwatchの日記: ]
[ 興味深い。あんまり関係ないかもだけど、高負荷（CAE）ソフトで、メモリを大量に積み、キャッシュをRAMDisk上にしたら、似たようなソフトなのに各社のパフォーマンスの違いがより顕著に出たなんて話を思い出した ]
[ 一つの要因として鋭い視点だと思う ]
[ SSDが普及→処理速度のネックの要因がIOではなくCPUになる→スクリプト言語は不利という論点 ]
[ 勉強になった ]
[ SSD==ささだ説 ]
[ スクリプト言語は動作環境があればOS問わないのがいいところでもあるので、なくならないと思う ]
[ 今回の検証環境ではHDD→SSDで＊DBサーバ内部の＊ボトルネックがI/OからCPUになりました、という話なだけであって、「SSDが主流になり、ディスクアクセスやDBがボトルネックにならない」というのは飛躍しすぎでないか ]
[ 動的言語でもSSDの恩恵を受けるし、元から速度最優先の所では使ってない。SSDによるコンパイル時間短縮の方がシェアに影響したりして。動的言語で改善すべきは速度よりは保守性じゃない? ]
[ SQLなんてディスクアクセスしちゃったらアウトじゃね?と否定しといて確かにいい視点だと思う。 ]
[ 興味深い話 ]
[ ディスクIOの次のボトルネック ]
[ スクリプト言語のメリットは工数を抑えられる事。言語のスピードのボトルネックはDBやディスクアクセスだけでなく、プログラム自体の設計や構造にもある。人が作る物である以上、物理性能だけで判断はできない。#web ]

このネタ、なかなかかと。

今後もしばらく注目記事をご提供しましょう。

こちらもいいかもですよ。