Monday, December 12, 2011

Looking at Ammo pt4

Just to make sure that NumberDictionaryShape was the problem, I looked inside V8 to see how it classifies the functions.  Inside the src folder in object.h, I discovered V8's object implementation.

The function that takes the most process time comes to mind. v8::internal::HashTable<v8::internal::NumberDictionaryShape, unsigned int>::FindEntry(v8::internal::Isolate*, unsigned int)





























One of the comments say this:
  // In the slow mode the elements is either a NumberDictionary, an
  // ExternalArray, or a FixedArray parameter map for a (non-strict)
  // arguments object. 


Chrome says to avoid dictionary objects, and ammo.js definitely uses them. 

Sunday, December 11, 2011

Looking at Ammo pt3

V8 has a profiler in the developer's version of chrome, but it also does not run the demo.  I opted to use V8 alone.  This profiler records the stacks from c++ and JavaScript code.  I ran ammo.js through V8. 

Here is the log.

The log alone does not give useful information at a glance.  After processing the log, I got this.

First thing I noticed was one function that is taking the most processing time.
v8::internal::HashTable<v8::internal::NumberDictionaryShape, unsigned int>::FindEntry(v8::internal::Isolate*, unsigned int)

The word NumberDictionaryShape was a clue to the problem.  The ammo.js demo has to make many property calls to change the block's position as they fall or fly, and NumberDictionaryShape sounds like an abstract class of a physical object. One of Chrome's main optimizations was the avoidance of dictionary lookups.  The slow speeds seemed to suggest that this is the case.  

Now what?

Looking at Ammo pt2

Here is a snapshot of chromes cpu profiler.










































Chromes CPU profiler recognizes that something is taking up roughly 80% of total process time.  I had to look somewhere else to find out what it was.

Saturday, December 10, 2011

Looking at Ammo pt1

Since it is a complete physics engine, Ammo.js is a particularly interesting piece of JavaScript that I investigated.  Because of the scale and newness of this technology, it has a share of problems, one being performance.  First, I tested it among several browsers.  I used Firefox and chrome. Using the ammo.js demo, there was a large fps difference in rendering between firefox and chrome.  Surprisingly, Firefox was faster even though chrome is normally faster in every other aspect.

Noting the difference between the browsers helped find the problem with ammo.  Both browsers have a different implementation for their JavaScript engines.  Chrome developers have taken it upon themselves to create a very sophisticated JavaScript engine, so it is safe to assume that some part of Ammo is breaking inside Chrome.  The demo used webgl which Chrome handles faster, so the fact that it ran slower points to the physics being the bottleneck. 



A closer look

Other applications with more intense graphics to render run more smoothly than this demo.  The large cap between the rendering makes me think it is the physics

Javascript and Chrome

To understand better about the previous examples of physics in JavaScript, I decided to learn how chrome handles JavaScript.  V8 is the open source JavaScript engine developed by Google for chrome.  Written in C++, the engine was created for high performance.  It implements three key design aspects that are responsible for its considerable performance.  By a glancing comparison, Chrome appears to be faster than all of its competitors.

The three key design aspects for v8 are:
  • Fast Property Access
  • Dynamic Machine Code Generation
  • Efficient Garbage Collection

Fast Property Access 
JavaScript dynamically controls its properties allowing an object to add or remove properties on the fly.  JavaScript typically uses a dictionary-like object to hold an object and its properties.  Most JavaScript engines access these dictionary objects by dynamic lookup.  Dictionary lookup is generally slower and should be avoided.  V8 handles this by creating hidden classes.


    For example, a function, point, was created with two properties.

    function Point(x, y) {
      this.x = x;
      this.y = y;
    }

    First, hidden class for point is created


    When this.x = x; is accessed, the initial class is reused by adding another hidden class with directions to access the property

    When this.y = y; is accessed,anther class is made with offset directions
    Every point object used after this initialization will refer to class C0, and any property access for x or y will refer to the hidden class that holds the directions to the memory holding it.

    Dynamic Machine Code Generation
    As opposed to intermediate byte code, v8 directly translates JavaScript to machine code.  Inline caching is used for property access that can later be dynamically changed.  The inline caching attempts to predict future calls to a lookup and place the results for easy access.  There are cases where the optimization would fail, so the runtime temporarily pulls out of the optimized code to patch the problem.  If the patching fails, the unoptimized code runs.

    Efficient Garbage Collection
    V8 employs stop-the-world, generational, accurate, garbage collection which means it does several things:
    • stops program execution when performing a garbage collection cycle.
    • processes only part of the object heap in most garbage collection cycles. This minimizes the impact of stopping the application.
    • always knows exactly where all objects and pointers are in memory. This avoids falsely identifying objects as pointers which can result in memory leaks.

    Friday, December 9, 2011

    A look at physics in javascript

    JavaScript can do many interesting things, but one thing that is not commonly seen is a physics engine done entirely in JavaScript.  Physics can make a falling object much more interesting to watch.  Here are a few examples to prove my point:
    Pl4n3s world
    Box2DJS
    Kripken
    Ammo.js demos
    Three.js demo

    The last three examples requires WebGL to be enabled on your browser.  The WebGL examples showcase what future web applications should look like, one of those things including web gaming.  



    Needless to say, this is great for the future