Hacker News new | comments | show | ask | jobs | submit login
Box2d Revisited (j15r.com)
67 points by mmastrac 1495 days ago | hide | past | web | 41 comments | favorite



I'm curious whether the performance varies if you used a C compiler from the last five years -- GCC 4.2.1 was released in July 2007. (I'm not claimed the author of the post is unfairly biasing the results, I'm just honestly curious.)


To answer my own question, I got:

  gcc 4.6.3: 3.554688 +/- 4.786550
  clang trunk: 3.593750 +/- 4.798172  
  Chrome: 41.03515625 +/- 9.331709130062185
Which puts Chrome at about 11x these native compilers, consistent with the blog post.


    gcc 4.8.0: 1.640625 +/- 3.703323
    clang 3.2: 1.718750 +/- 3.772718
    chrome   : 23.28515625 +/- 3.636932727324763
So chrome is about ~14x the native compilers.

Changing gcc to use -O2 instead of -O3 gets: 1.562500 +/- 3.630922.


What about -Ofast which enables -ffast-math?


The makefile supplied with the repo specifies -ffast-math. It uses these CFLAGS:

    CFLAGS=-s -O3 -msse -mfpmath=sse -ffast-math -fomit-frame-pointer -IBox2D_v2.2.1 -DNDEBUG=1
Using -Ofast gets the same results as -O2.


Thanks for the info, I should have guessed that he enabled -ffast-math manually.


FWIW, I just ran it through Clang 4.1 (the standard on XCode these days), and got roughly identical performance. I'm still compiling gcc 4.8 just to be sure, but it seems unlikely to make much of a difference.


There's no Clang 4.1, though. You probably mean "the Clang that comes with version 4.1 of XCode"?

Clang 3.3 will be released soon.


Good point. Apple helpfully reports the rather confusing version string "Apple clang version 4.1 (tags/Apple/clang-421.11.65) (based on LLVM 3.1svn)" :P


Ditto for gcc-4.8. Roughly the same (ever so slightly worse) performance.


I can't zoom on this page with my phone and, due to that, can't read it at all except with the "Reader" function.


That enormous position:fixed header makes it difficult to read even on a desktop.


What phone browser are you using? It seems ok on my Nexus 4 and mobile Safari, but I may need to fix the viewport or some such thing.


Something strange happens on the default android browser.

http://goput.it/p1l.png


Interesting how JS still doesn't live up to AS3. Everyone always discredits Flash... but if you're trying to make a Physics-based browser game, it still seems appropriate!


Well, the asm.js version of the benchmark is JS, and it outperformed AS3. Although as cpleppert said, perhaps an alchemy version for Flash would be faster than AS3, that would be interesting to see.

But, I'm not aware of an alchemy version of Box2D for Flash that is convenient to use from normal Flash (what presumably the rest of the game is written in), while for asm.js there is such a version (that is easily usable from normal JS), here's a demo

http://kripken.github.io/box2d.js/webgl_demo/box2d.html

So comparing currently usable versions of Box2D, the fastest JS one (the asm.js one) is faster than the fastest Flash one.


You could get even better performance if you directly coded against the alchemy VM instructions or used alchemy directly. This would be comparable to asm.js or coding Java against the unsafe memory operators.


Interesting that NaCl is far closer to native performance than asm.js. Can that performance gap be closed?


I'm not sure I'd call that "far" different, but asm.js is certainly in early stages so it probably will get faster.


    C (gcc 4.2.1)	2.62 +/- 0.24	1.0x
    NaCl (x86-32)	3.39 +/- 0.25	1.3x
    asm.js (Firefox Nightly)	5.12 +/- 0.59	1.9x
NaCl is 30% slower, asm.js is 90% slower.


Your conclusion doesn't follow from your data. 5.12 is not 90% slower than 2.62, it's 51% slower.


He says NaCl is 30% slower than _c++_, asm.js is 90% slower than _c++_ which is correct.


For asm.js to be 90% slower than c++, it would have to run at 10% the speed of c++, not 51% of its speed, which is what the data shows. 100% slower is not 1/2 the speed, it's no speed at all.

Take some speed x. Increasing it by 100% gives 2x. Decreasing it by 100% gives zero.

Expressed another way, 100% of x is x. Add 100% = 2x, Subtract 100% = zero. The original claim is "90% slower." Clearly the OP either meant 51% slower or 49% slower, depending on how one reads it.

a = 2.62

b = 5.19

a / b = 0.5048, or 50.48%: "b has 50.48 percent the speed of a".

EDIT: wow, once again downvoted for being right and proving it.


English conventions are inconsistent. "X is 2x slower than Y" usually means that Y runs at twice the speed of X. Since 90% = 0.9, "X is 90% slower than Y" would mean that X is actually faster than Y. Therefore it's better to state it in an unambiguous way, e.g. X took 2x as much time as Y, or just look at the numbers directly.


> English conventions are inconsistent.

Yes, and it's an argument for expressing these ideas with mathematics instead of words.

> Therefore it's better to state it in an unambiguous way, e.g. X took 2x as much time as Y, or just look at the numbers directly.

Complete agreement.


Please revisit your web design.

http://imgur.com/fBZZXYY.png


I might be able to do that more effectively if you'd point out what browser you're running.


That was the Hacker News app which uses the Android browser. I am running Android 4.2.2.


I'd love to see the numbers for the asm.js version running in Safari and Chrome


You can grab his repo and try it yourself, but as I commented on the blogpost, on my machine I see firefox without asm.js optimizations and chrome as being about the same speed, both of them are half the speed of firefox with asm.js optimizations. (I don't have a machine with safari to test on.)

Which means the asm.js version is faster than other JS versions, even without specific asm.js optimizations.


Thanks. I didn't do it myself because I wasn't able to find the asm.js version version, I must be blind.


Not too useful as does not include one of the very popular ports and an additional major platform:

http://farseerphysics.codeplex.com/

:(


I don't get this comment. This is about performance in browsers, not different physics engines...?!


It looks like Farseer is based on Box2D, but extended, so it makes a kind of sense. I suspect the .NET VM performance will be somewhere around what the JVM gets, so it shouldn't be too much of a surprise.


I must admit to being unfamiliar with Farseer, but if you feel like submitting a pull request, I'll figure out a way to run it on my Mac (I presume the "platform" you're referring to is .NET, or perhaps WinMo).


It doesn't make sense to test farseer on anything but Windows. I would be curious to see how .NET stands these days with relation to Java and native.


>> It doesn't make sense to test farseer on anything but Windows

You may want to read this to catch up: http://en.wikipedia.org/wiki/Mono_(software)


I know about Mono. I don't think its as fast as Microsoft's own CLR, though I would definitely be happy if it was.


It's perfectly useful as comparison of browser-based Box2d ports, and how they perform relative to the original C library.


Farseer can run in browser using Silverlight.


Is NaCl even cross-browser?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: