FirefoxのJavaScriptエンジン「Spidermonkey」はChromeの「V8」より高速 35
ストーリー by hylom
1つの評価要素としてどうぞ 部門より
1つの評価要素としてどうぞ 部門より
あるAnonymous Coward 曰く、
FirefoxのJavaScriptエンジン「Spidermonkey」が、JavaScriptベンチマークスコアにおいてGoogle Chromeの「V8」やWebKitの「JSC」を上回ったそうだ（GIGAZINE）。
調査を行ったのは、MozillaのJavaScriptチームが運営するAreWeFastYet?で、テストにはKraken、SunSpider、GoogleのOctaneといったJavaScriptベンチマークを使用したという。ARE WE FAST YET?が公開している2012年からのベンチマーク結果を表わしたグラフでは、2014年2月以前はChrome V8が最も実行速度が速かったものの、それ以降はSpidermonkeyが僅差で逆転して1番手をキープしている。
ただし、MozillaハッカーのRobert O'Callahan氏は「実際に使用した際のパフォーマンスはベンチマークソフト上のスコアよりも複雑である」と逃げ場も用意している。
MacOSXで上回ってるだけでWindowsではまだ互角 (スコア:3)
http://arewefastyet.com/#machine=17 [arewefastyet.com]
これ見ると中々抜けないでいる(というか良く追いついたなという感じだが)
それと、包括的なベンチマークのoctaneはasm.jsの項目があって、それはSpiderMonkeyではなく
別のエンジンでAOTコンパイルしてて圧倒的なスコアを出して全体のスコアを押し上げている。
だから、それを除くとまだ勝ってるとは言えないと思っている。
ただ、少し前まではoctaneで半分ぐらいのスコアだったのが怒涛の追い上げでここまで来たのは
SpiderMonkeyの設計の良さを表してると思う。
まだ静的型言語のJavaほどの速度にはなってないけど、いずれJavaにも追いついて欲しい。
Re: (スコア:0)
設計はクソ悪いことで有名だよ。
古くからのコードが密結合でリファクタリングが困難。
ちょっと前も新しいGC入れるために、前準備だけで１年くらいかかったんだから。
そのときのリファクタリングのおかげでようやく最近まともなコードになってきているけど、
設計という点ではJSとのバインディング部分などV8にまだまだ追いついてない。
速度が向上したのは単に、複数JITエンジンの導入で新しいコードをどんどん追加したから。
それとマイクロベンチではとうにJavaを抜いてる。
http://www.j15r.com/blog/2014/05/23/Box2d_2014_Update [j15r.com]
言語自体の性能は物理演算かデコー
Re:MacOSXで上回ってるだけでWindowsではまだ互角 (スコア:2)
> ちょっと前も新しいGC入れるために、前準備だけで１年くらいかかったんだから。
ポインタがデータを直接参照してたのを、全部直したってやつでしょ。
それで設計が悪かったとは思えないけど。
> 速度が向上したのは単に、複数JITエンジンの導入で新しいコードをどんどん追加したから。
多段階のJITコンパイルを行うのは他のJSエンジンよりも早い段階からやってたから成果が出てると思うし、
その新しいコードの事を言ってたんだけど。
> それとマイクロベンチではとうにJavaを抜いてる。
いや、全然抜いてないよね。倍ぐらい遅いよ。
抜いてるのはasm.jsのコードでこれは別のAOTのエンジン(OdinMonkey)で実行してるやつ。
Re: (スコア:0)
ごめんけど何が言いたいのかさっぱりわからない。
各エンジンは分離して考えるものじゃないし、今回抜いたとされるOctaneベンチにさえasm.jsのコードは入ってる。
なんか屁理屈を言いたいんだろうなとは分かるが、屁理屈にもなってない。
Re:MacOSXで上回ってるだけでWindowsではまだ互角 (スコア:2)
> 各エンジンは分離して考えるものじゃないし、今回抜いたとされるOctaneベンチにさえasm.jsのコードは入ってる。
OdinMonkeyはAOTでSpiderMonkeyはJITだから根本的に別のエンジンなんで、
Javaやその他のJITエンジンと平等に比べるのは不公平だけど、その辺の技術的な違いは分かってるものと思ってたけど
知らなかったとは失礼しました。
Re: (スコア:0)
ごめんけど？？
Re: (スコア:0)
別のACですが、方言ですね。私もたまに使います。
「申し訳ないですが」とでも訳しておけば良いのでは。
Re: (スコア:0)
ごめんけど
↓
こめん、悪いんだけど
ＧＰＵみたいに (スコア:2)
特定ベンチマークコードに最適化してたりして
Re: (スコア:0)
それなんてさむそん？
Re: (スコア:0)
オープンソースなんだから、ベンチマークに特化して変なコード入れたらすぐわかる。
Re: (スコア:0)
変なコードではなく、各エンジンはベンチマーク向けに最適化してるし、そのためにベンチマークが作られてる。
ベンチマークは現在重要だと思われるパターン、時には特定のプロダクトのコードの寄せ集めで、それが速くなることを目的にしている。
もう、あらゆるコードが速くなるような最適化は無理だし、誰も考えてない。
今やっていることは特定のパターンへの最適化を入れることの繰り返し。
Re: (スコア:0)
「ベンチマークとして優れている≒個人的尺度や体感に近い結果が出ると感じる人の多い評価手法へ最適化する」こと自体は間違っちゃいない。
まあPDCAサイクル同様、評価に基づく対策に有効性を感じない人が増えたならスパイラルアップすればいいだけのことで、むしろユーザはベンチマーク自体の方を批判的視点で見るべきだな。
Re: (スコア:0)
もうベンチマークの対象及びエンジンが最適化に注力するポイントが、世間のコードとマッチしてないから良くないとかそういう段階じゃない。
逆に世間のコードの方が見習わないといけない。
開発リソースの割り振りに疑問 (スコア:2, 興味深い)
Firefoxはパフォーマンス調整よりも
安定性に重点を置かなきゃまずい実情なんだけどなぁ
ブラウザ本体守るためのplugin-containerが落ちると
ブラウザ本体巻き込んで落ちるとか
特にOMTC有効にするとタブの開閉だけで落ちるとか
このあたりEMET [microsoft.com]入れてると顕著なので
根本的なところで行儀悪いまたはムリ筋の迂回をした作りになってるんじゃないかなと
# EMET入れてなかったら落ちずに攻撃者の突破口盛りだくさんみたいな
パフォーマンス的に快適になって
うれしくないわけじゃないですけれど
安定して使えてこそですからねぇ
# そりゃChromeに浮気したくもなりますです
Re:開発リソースの割り振りに疑問 (スコア:1)
Firefoxもマルチプロセス化とか、安定性に取り組んでる。
そもそも（ネイティブ）プラグインレスにすることが目的なので、その周りの不安定性は重要ではない。
Re: (スコア:0)
2行しか書いてないのに1行目と2行目で矛盾してるんだが…
Re: (スコア:0)
矛盾してない。使わないことが最も安定ということだから。
使わなくて当たり前なの。
わざわざ使うということはそれはユーザーがわざわざ自ら不安定にしてるということで、Firefoxの責任ではない。
Re: (スコア:0)
Firefoxの存在意義って。。。
# Chromeアドオン充実してきたものね
Re: (スコア:0)
もういらない子になっちゃってるよね、実際。
自由にカスタマイズできる、というもChromeに持って行かれてるし。
AndroidやiOSとの連携でもChromeの方が優位だし。
優位と言えるのはオープンソースで最も透明性の高いウェブブラウザってくらいじゃないかな。
WebkitやChromiumもオープンソースではあるけど、素の状態から使う人は極めて稀だろうし。
IEも10あたりからマシになったしね。
もう安らかに眠ってもらっても困らない。
Re:開発リソースの割り振りに疑問 (スコア:1)
Chrome は Proxyの設定くらいできるようになったらいいのにね。
Re:開発リソースの割り振りに疑問 (スコア:1)
Chromeが無くなってもFirefoxが無くなってもそんなに困らないが、少し困る。両方無くなると大いに困る。
Re: (スコア:0)
>自由にカスタマイズできる、というもChromeに持って行かれてる
タブバーの位置くらい変えられるようにしてから言ってほしいな。
Re: (スコア:0)
FirefoxというよりFirebugが昔ながらのデバッグツールという感じで古い世代の自分には使いやすい。
という理由でFirefoxメインだったり。
Re: (スコア:0)
マジキチ
Re: (スコア:0)
FirefoxがFlashやPDFのJSランタイムを支援してブラウザにも乗せてること知れば別に当然と思えるでしょう。
Re:開発リソースの割り振りに疑問 (スコア:1)
たしかにFirefox+EMETはいろいろ言いたくなるポイントが多いですね。。。。
といっても「根本的なところで行儀悪いまたはムリ筋の迂回をした作り」なのは
EMETのフック周りも大なり小なりおんなじような感じなので
ぶっちゃけどっちが悪いのか何とも言えないんじゃないかなーとおもっています
# 起動が劇的に遅くなるのだけは何とかしてほしいですけど
ひどいタレコミ (スコア:0)
最後の段落がGIGAZINEの訳の丸パクリ。
Re:ひどいタレコミ (スコア:3, 参考になる)
ひどいタレコミなのはその通り。でも、それは丸パクリだからじゃないです。
原文は
と、謙虚な部分と誇っている部分の二つが併記されています。GIGAZINEはその謙虚な部分を引用したわけです。
タレコミ人はその謙虚な部分だけをもって「逃げ場も用意している」などと余計なことを書き加えた部分がひどい。まず間違いなく、タレコミ人は原文を読んでいないでしょう。
Re: (スコア:0)
あそこのは、どの記事もポジティブが基本で（ツッコミを入れたいけど、めんどいからね～）いいですよね :P
ビジュアル＋解説って、騙されやすいというか、本物に見えるよね。特に海外のネタは... とかく難儀なもので。
# 全ては、MADかも？から、始めるしかない。
Re:酷い言いがかり (スコア:1)
This puts us in a position of strength, so we can say "these benchmarks are not very interesting;
let's talk about other benchmarks (e.g. asm.js-related) and language features" without being accused
of being sore losers.
Congratulations to the Spidermonkey team; great job!
これで我々の方が強い立場になったのだから、
「こんなベンチマークはあまり面白くないね。他のベンチマーク（asm.js 関連とか）や言語機能の話をしようよ。」
って言っても、負け犬の遠吠えだなんて責められないよね。
おめでとう、SpiderMonkey チーム。でかしたぞ！
# どうみても逃げ道じゃないんだが…？
Re: (スコア:0)
原文を最後まで読みましたけど？
タレコミがひどい事に変わりはありませんが
つかの間の１位 (スコア:0)
V8は最近はしばらく前からずっと新しい最適化エンジンのturbofanに注力してるので現行のエンジンの改善にはさほど取り組んでいない。
turbofanが完成するまでの間だけのつかの間の優勢。
Re:つかの間の１位 (スコア:2, 興味深い)
その点、Robert O'Callahan氏の原文ではちゃんと触れている。
Mozillia側（Robert O'Callahan氏）としては
「ベンチマークも一つの指標として大事だけど、実際の使用感はいろいろ複雑な要素が絡み合うからいかんとも言い難い。「だからどうした」と言われればそれまで。むしろベンチマークで勝ったことで我々が「だからどうした。そんなつまんない事より他のもっと大事な（面白い）こと話そうぜ！」って堂々いえるようになったことがうれしい」（超意訳）
ってことらしい。