Search Unity

一年ちょっと前、私たちはUnityのWebGLに関する異なるブラウザー間でのパフォーマンスベンチマークのブログ記事をアップしました。そろそろこのベンチマークも立ち戻って更新する時期だと思いましたので、どのように数値が変わったのか調べてみました。

Microsoftはその後、Windows 10で新しいEdgeブラウザーをリリースしました。このブラウザーはasm.jsをサポートし、かつその機能はデフォルトで有効になっています – だので、どのくらい良い結果が出るのか大変興味がありました。その他、私たちはShared Array Buffersが有効になってマルチスレッドでコードが実行出来るようになったUnityの実験ビルドも作ったので、それでどのくらいのパフォーマンスの改善が見込めるのかもチェックしたいと思いました。このバージョンのUnityはShared Array Bufferサポートが有効になったFirefoxのナイトリービルドを使ってテストすることにしました。

もしお使いのブラウザーで今回のベンチマークを実行したい場合は、ぜひブラウザでこちらをアクセスして試してみて下さい。

Untitled 2

去年のベンチマークからの手順の変更点に関するノート:

  • このベンチマークは今回アップデートしたベンチマーク・スイートをUnity 5.3でビルドしたものを使用しています。ベンチマーク・スイートのプロジェクトフォルダーはこちらからダウンロード出来ますので、お使いのローカル環境や別のプラットフォームでもご自由にお試しいただけます。
  • このバージョンは前回存在していた全てのアートワークやアイキャンディーを除去しています。それらはベンチマークに一切の価値を付与しませんし、プログラマーによるアートはどちらにしろショボいのでやめにしました。アセットを除去することでビルドも小さくなりましたし、より重要な点はプロジェクトフォルダーを再配布することが可能になったということです。(上記のリンクを参照下さい)
  • “Mandelbrot GPU”(マンデルブロGPU)はブラウザ間の差異をあまり示さず、基本的に単なるGPUのベンチマークでしかなかったので、テストスイートから除外することにしました。副作用としては、これによりブラウザーの全体スコアの相対的な差の値が前回よりもより小さくなるという影響が出ています。
  • 去年までは入れていたネイティブスタンドアローンビルドとの比較も誤解を招きやすいので除去することにしました。私たちはプラットフォームが異なるときに実際には全く違うコードを実行するので(たとえば異なるクオリティ設定で全く違うシェーダー実装を使用したり、そもそもスクリプトエンジン自体が違ったりもします)これはミスリーディングな比較だと判断しました。
  • 私たちは以前ベンチマークを実行するときには、最新であった EdgeHTML 12 (Edge 20.10240.16384.0) を使用しましたが、デフォルトではasm.jsのサポートは有効ではなかったので、これを手動で有効にして利用しました。今現在ではEdgeHTML 13がリリースされており、デフォルトでasm.jsのサポートがデフォルトで有効になっています。

こちらがベンチマーク・スイートによるそれぞれのブラウザーでの総合スコアです。ベンチマークは 3.3.GHzの Core i7 CPU と Nvidia GTX 960 GPU を載せたWindows 10 PCでの実行結果です。Shared Array Buffers サポートの入ったFirefox 45はナイトリービルドのFirefoxと実験ビルドのUnityを使っているので、グレーのバーで表現しています:

Screen Shot 2015-11-30 at 1.51.33 PM

こちらがMac OS Xでの異なるブラウザー間のスコアです。2.6 GHz のCore i7 CPUを載せたRetina MacBook Pro 15”での実行結果になります(他のブラウザーとSafariの比較用にどうぞ):

Screen Shot 2015-11-10 at 11.12.52 AM

こちらがWindowsでの個々のベンチマークの違いです。個々のテストについて、32bit版のFirefox 41を1.0としてスケールしています:

Screen Shot 2015-11-30 at 1.52.40 PM

こちらがOS Xについての個々のベンチマークです。こちらも個々のテストのFirefoxを1.0としています:

Screen Shot 2015-11-10 at 10.00.57 AM

こちらが去年のベンチマークに対する今年のベンチマーク結果の全体的な比較です。去年からパフォーマンスがどのように変わったかが分かります。これは 2.6 GHz Core i7 CPUのRetina MacBook Pro 15”を使ったMac OS Xでのスコアの比較です:

Screen Shot 2015-11-10 at 10.22.29 AM

最後に、こちらがUnityのコンテンツが起動するまでの時間に対するベンチマークになります。下のバーは個々のブラウザーでベンチマークプロジェクトを開いてから最初のフレームがレンダリングされるまでの秒数です。このとき、コンテンツはローカルディスクから読み込まれているので、ネットワークからのダウンロード時間は無視されています。Firefoxはasm.jsのコンパイル結果をキャッシュするので、同じコンテンツが2回目にロードされる時にはコンパイルがスキップ出来、結果ロードが高速になります。ベンチマークではFirefoxはこの2つのケース(最初のロード(cold)と2回目のasm.jsのコンパイルキャッシュが聞いた時のロード(hot))を載せています:

Screen Shot 2015-11-30 at 1.35.35 PM

わかったこと:

  • 64bit版のFirefox 42が現在出荷されているブラウザーの中でベンチマークでは最速をマークしました。32bit版のFirefoxは64bit版に比べて目に見えて遅いことも分かりました。
  • 新しい挑戦者として登場したEdgeはベンチマークでは2位にマークし、ほとんどのベンチマークにおいてFirefoxに近い結果を叩き出しました。(しかも、32bit版のFirefoxよりも高速でした)WebGLのレンダリング負荷を試すベンチマーク各種(ParticlesやAsteroid Field)では、Edgeは全てのテストしたブラウザーの中で最高のパフォーマンスを記録しました。
  • Safariは1年前はChromeに比べて大幅に遅い結果を出していましたが、今回はChromeに匹敵するパフォーマンスを発揮しました。
  • Internet Explorer 11 は概ねすべてのベンチマークで他のブラウザーより大幅に遅く、基本的にはUnityのWebGLコンテンツを再生するには遅すぎるブラウザーと言えます。
  • Shared Array Buffersを有効にしたUnityのビルドはパフォーマンスを大幅に(ベンチマークによっては数倍)改善することが分かりました。これは将来期待できるパフォーマンスの改善がどの程度かということの見通しとして有効な情報だと言えます。
  • 全体的に、Firefoxでは、1年前と比べて大体18%パフォーマンスの改善が見られました。これはFirefox 41がFirefox 32に比べてより高速に動作するようになったことも一因だと考えられますが、より大きくはUnity自体の改善とemscriptenコンパイラーの改善による結果と考えられます。この結果は64bit版のFirefoxが長く存在するOS Xに関するものです。Windowsではそもそも64bit版のFirefox自体がようやくリリースされたことにより、改善の幅はより大きなものとなるでしょう。
  • ロード時間を見てみると、ほとんどのモダンなブラウザーはベンチマークプロジェクトを大体5〜7秒でロード出来ています。Firefoxはasm.jsのコンパイル結果をキャッシュ出来るので、2回目のロードを1.5〜2秒まで圧縮できています。

38 replies on “WebGLベンチマーク結果のアップデート”

I can’t run the benchmark in Internet Explorer 11 ( Inori version ), the WebGL player return an Out of memory error.

On Linux, without proprietary drivers and running Firefox, the benchmark “runs”, I mean, the whole screen is messed up, but at least it runs. With proprietary drivers on, I got a wonderfull pinkish bubblegum screen, and nothing works.

Sorry about double post, but the WebGL bench just started in Internet Explorer 11 (Inori version), it seems that the Out of Memory is pretty random…

My scores:

Mandelbrot Script: 15 169
Instantiate & Destroy : 10 806
CryptoHast Script: 46 588
Animation & Skinning: 34
Asteroid Field: 2 148
Particles: 13 010
Physics Meshes: 29
Physics Cubes: 38
Physics Spheres: 51
2D Physics Spheres: 103
2D Physics Boxes: 72
AI Agents: 250

Overall Score: 11 476

Glad to see some benchmarks around this. I was especially surprised to see how the different browsers performed on my own hardware. I definitely get different results on Windows 10. I actually get Edge>Firefox>Chrome. Not entirely sure why though.

As far as performance, its getting to “good enough” for many things. I won’t be trying to push AAA content directly in the browser, but for things like social games and apps – its definitely pretty close to where I don’t care so much about the benchmarks anymore.

Is there an available demo built using the shared array buffers? I have a 24-core workstation I’d like to test scalability on.

How about mobile browser?

i tried a small project with just a ugui scroll view, only have 15 fps in release WebGL in iphone 6s safari.

Looking forward to see better performance in mobile browser :D

My results on Firefox 43 64 bits, Windows 8.1 64bits, NVIDIA GTX 780 (358.87):

With Angle (D3D11?) : 67794

With “webgl.disable-angle” : 68138

Seeing your results, either something went wrong in 43 or I’ve done something wrong in my Fox config.

Fedora Linux 23
AMD A8-6600K APU
Firefox 42
54965 overall

The results published in the blog are basically useless, because of being normalized. Since they don’t give the numbers in a way that I can use to compare my own results to the published results, it is all meaningless. Even after you run it yourself, you get no comparative information, and the types of things tested are very different from each other. Presumably there is some sort of typical reason common to published benchmarks why this would be concealed. ;)

OSX 10.11
Firefox 43.0

iMac 24GB Ram, 4GB 780m.

During the Particles benchmark, firefox throws up a dialog “Out of memory. If you are the developer of this content, try allocating more memory to your WebGL build in the WebGL player settings.”

I would also have liked to see results from linux in comparison. I guess we would still see some funny results heading in unknown direction, but knowing is always better than guessing :)

Sad that Firefox 43 and 46 was not tested.
Also It could be a very useful idea to bench also on Linux. The gpu drivers are really different.

And what about the layout engine of the future ? Servo + webrender +browser.html

I took a look at webgl export in 5.3 .. safe to say i won’t be bothering with it, the output scene lighting was completely off from the web standalone, and performance of the scene even after changing settings to be as low as possible was just not worth it.

And the webgl compile time turned my pc into barely useable brick for way too long, no idea who’s bright idea it was to set all compiling processes thread priority onto anything but ‘below normal’ kinda stupid given there is no setting in unity to set the thread priority before it starts, probably the same programmer who set the lighting building processes to the same.

oh and to top it off the webgl version left a 70mb opengl.js with the total size for webgl export being 82mb. Unity provides no way of seeing what the hell its exported out. For comparison the web standalone export was 3mb.

Maybe in 2017 webgl might be worth checking out again right now its bleh, ofc UE current track of releasing decent updates with actual built in engine features as opposed go find and buy such improvements at the asset store might have me switching to that in 2016 instead.

Firefox 43 64 bit / Windows 10 64 / i3 530@4 GHz+8GB RAM / GeForce 750 Ti

My results:

Native WegGL+WebGL2 – 64590
Native WegGL – 61865
Angle D3D11 – 54857
Angle – 50575

Firefox 43.0 Out of memory during particle system.
OS X EL Capitan
Mac Book Pro Retina
mid 2014, 2,5 Ghz, 16 GB RAM,

Great work.

Will Shared Array Buffers be mapped to C# threads so our own multi-threaded code can take advantage of them via IL2CPP?

Any news on progress with SIMD, WebGL 2.0, WebVR and WebAssemby.

I disagree with the decision to omit standalone results from the comparison.

It’s important to understand the performance hit you’re going to take by choosing WebGL over standalone. Which areas are significantly weaker? Which are nearly comparable?

Further, performance is increasing over time on standalone as well and it’s valuable to compare the changes on each platform. If performance increases on standalone are outpacing those of WebGL, that means the gap between the platforms is increasing even in the face of the WebGL improvements and will affect the decision to leverage the platform. Likewise, if the gap is closing, that makes a stronger case for WebGL.

I have to wonder if the comparison was omitted because it potentially paints WebGL in a more negative light, but imho the comparison is crucial to making an informed decision. Sure, we can do the benchmarks ourselves, but why omit the information when you’re already publishing results publicly?

Awesome, I was in the middle of writing a presentation on Unity’s WebGL benchmarks when you updated this today.

Thanks for keeping us in the loop, looking forward to seeing how browsers improve perf over time.

Great to see more info on WebGL builds.

What about mobile ( other WebGL tech seem to work ok, eg Blend4Web, PlayCanvas etc ), would be cool to have WebGL as a potential option for smaller games across desktop and mobile.

Also would be cool to have report on reduced file size ( if any ), of say a single cube, to get an idea of the overhead pre adding assets. Maybe build times as well.

Keep up the great work in this area!
Mal

Comments are closed.