by
Anonymous Coward
on 2009年12月22日 17時37分
(#1692798)
いや、たとえば var a = [100000]; とかやったとき、800000バイトの記憶領域を確保せざるをえないのよ。インタプリタは配列がバイト値の格納にしか使われないかどうか判断することができないから。HTML5 Canvasとかバリバリ使うスクリプトで、画像データをJavaScriptで丸抱えする必要があるときにはクリティカルに効いてくる。 問題解消のためにByteArrayを導入しようとしたけど失敗したというのが先日のストーリー [srad.jp]。仕方がないのでCanvasではCanvasPixelArrayという専用の型を定義して、実装がメモリを節約できるようにしている。少なくともFirefoxの実装では今のところ単なるJavaScriptの配列になるだけなので意味がないけど。
10倍? (スコア:1)
プログラミング分野に関わったことがないのでエロい人に教えてほしいのだが、
> C++の方が10倍効率がよいと考えれば
という仮定は妥当なの?
Re:10倍? (スコア:2, 興味深い)
だけど普通ボトルネックになるのはCPUではなくIOなので、webサーバーには効果あるけど
DBがひっかかって純粋に1/30にはならないと思う
Re:10倍? (スコア:2, 興味深い)
php_jsonというモジュールに置き換えたら、90秒以上かかってい
た処理が、1秒以内で終わるようになった。
私は、phpは詳しくないので、JSON.phpを書いたプログラマが
どのレベルか分かりませんが、IOがない処理だとそういうことも
あるということで。
Re:10倍? (スコア:1)
単純な計算性能であれば10倍というのは妥当なんですね。
教えてくれた諸氏、ありがとうございました。
Re:10倍? (スコア:1, 興味深い)
しかし、C++よりCの方が2~5倍くらい効率がいいかもしれない。
アセンブラで書けばさらに効率がいいってことにもなりかねないような。
一方で、C++、C、アセンブラの順で開発効率が落ちるわけで、効率が落ちた分の
損失も含めて議論しないとなんないですね。
Re:10倍? (スコア:1)
PHPで配列にデータを読み込んだら読んだデータの10倍くらいのメモリ消費になったのでだいたい合ってると思う。
# 記事の方、CPU効率だなんて言ってないよね?
Re: (スコア:0)
Re:10倍? (スコア:1)
それを明示的に書くか自動的にやってもらうかの違いでしかなく
実用上それほどの差があるともおもえない。
Re:10倍? (スコア:3, 興味深い)
いや、たとえば var a = [100000]; とかやったとき、800000バイトの記憶領域を確保せざるをえないのよ。インタプリタは配列がバイト値の格納にしか使われないかどうか判断することができないから。HTML5 Canvasとかバリバリ使うスクリプトで、画像データをJavaScriptで丸抱えする必要があるときにはクリティカルに効いてくる。
問題解消のためにByteArrayを導入しようとしたけど失敗したというのが先日のストーリー [srad.jp]。仕方がないのでCanvasではCanvasPixelArrayという専用の型を定義して、実装がメモリを節約できるようにしている。少なくともFirefoxの実装では今のところ単なるJavaScriptの配列になるだけなので意味がないけど。
Re: (スコア:0)
文字列を使うといいよ。文字列は単なる16bit整数の配列だと規格で保証されてるから。
と言いたいところだけど、IEだと文字列操作が異常に遅いんだよねぇ…。
Re:10倍? (スコア:1)
作成コストが100倍かかるのは事実だよ。
Re:10倍? (スコア:1, 興味深い)
ずばりPHPコンパイラの出番でしょう。
Re: (スコア:0)
いくらなんでもそりゃないんじゃない?
ライブラリ一切使いません、とかじゃあるまいし。
Re:10倍? (スコア:1)
しかしながら、Webシステムなどで頑張ってるのはDBエンジンなので、C使おうがperl使おうがそんなに差は出ない。
そういう性能的な要求が出る部分だけ、メッセージングミドルウェアとかを使ってサービスとして分離するのが良いと思う。
Re:10倍? (スコア:3, 参考になる)
Computer Language Benchmarks Game [debian.org]
縦軸が実行に要した時間、横軸が同じアルゴリズムを記述するのに要したコードサイズになっています。
やはり、まだ静的にコンパイルするCとかが速いが、Java VM など最近の JIT コンパイルも強力。
関数型言語や Lisp が意外に頑張ってる。
JavaScript, PHP, Python など LL 言語は似たような特性だが、Ruby はもう少し頑張って下さいってところだろうか。
Re: (スコア:0)
いずれにしても、それが一般的にどれほどの意味があるかは分からない。
(速度が一番重要なところも、もちろん存在するけど)
Re: (スコア:0)
実行速度という観点では平均してそれくらい速くなると思います。
ただ、開発費の増大とメンテナンス性は犠牲になります。
#>30,000のサーバーが稼働しているそうだが、例えばこのうち25,000でPHPが走っているとして(ry
#>22,500のサーバーが不要になるという計算だ
##この計算はどうなんだろう。Facebookのサービスの中身考えると採らぬ狸的な話の気がしますが。
Re: (スコア:0)
どちらも適切なエンジニアが開発したら10倍はいかないと思うがそれなりに効果はあると思うが
部門名や他の人が書いてるとおり、「開発・保守サイクルまで入れるとどうなるんだろう」ですね。
キャッシュサーバいれたり、ネットワーク最適化したり、適切なヘッダー返したり、CPUをアップグレートしたほうが
手っ取り早くリクエスト数そのもの、CPUやコネクションの占有時間を減らせるので消費電力の削減にはなると思う。
Re:10倍? (スコア:3, おもしろおかしい)
サービスという面で考えれば、そういう技術的な部分に
話を進めるよりも、もっと先にコンテンツ面の改善で
サーバーへのレスポンスが減るような仕組みを考えたほうが
実は良かったりするんじゃないだろうか。
コードの改善で実行速度を200%改善する難しさよりも、
同じページを2倍長く見る(=単位時間あたりのリクエストが1/2)
ようなコンテンツを作るほうが難易度って低いのじゃないかと技術屋は思ってしまう。
--以下ネタ
Facebookってようはmixiなんでしょ。
好きなマイミクのエッチな写真とか念視できるサービスがあれば
10分ぐらい同じ画面見続けると思うよ。主に夜に。
ごめんなさい。
Re: (スコア:0)
ハァハァするのでCO2排出量が増えます。
Re:10倍? (スコア:1)
ドウシテオレハ、ココニイルンダ!
Re: (スコア:0)
> C++の方が10倍効率がよいと考えれば
封筒裏の計算
http://blogmag.ascii.jp/tokyocurrydiary/2007/01/heinz_1.html [ascii.jp]
というやつ