http://www.cs.chalmers.se/Cs/Grundutb/Kurser/ppxt/HT2007/general/languages/armstrong-erlang_history.pdf

It showed up on programming.reddit for about a day, and then disappeared right back into the deep waters - which is too bad, because the paper is illuminating.

Erlang is a language with strong built-in support for concurrency based on message passing. As the author describes it:

Erlang was designed for writing concurrent programs that “run forever.” Erlang uses concurrent processes to structure the program. These processes have no shared memory and communicate by asynchronous message passing. Erlang processes are lightweight and belong to the language, not the operating system.

Reading the paper, I had several delightful “aha!” moments, where the details of Erlang design just clicked together. And I don’t mean the mundane issues, like single-assignment variables (hello, Prolog!), or interactively modifiable code (hello, Lisp!). Rather, the history put some architectural bits in perspective.

At a certain level, I always knew that Erlang was designed for programming telephone exchanges. But this paper really conveys the feel for what that means: huge collections of loosely coupled finite-state machines, all running in parallel, doing little bits of protocol validation here and there, but mostly staying dormant.

Typically, the software for call control is modeled using finite state machines that undergo state transitions in response to protocol messages. From the software point of view, the system behaves as a very large collection of parallel processes. At any point in time, most of the processes are waiting for an event caused by the reception of a message or the triggering of a timer. When an event occurs, the process does a small amount of computation, changes state, possibly sends messages to other processes and then waits for the next event. The amount of computation involved is very small.

Which definitely explains a number of their implementation choices which, without this motivation, look highly unusual. Let me highlight just three of them.

First, there’s strong emphasis on easily tracking and manipulating the flow of control, rather than data. Everything is based on message passing. This makes Erlang perfect for control problems: monitoring the state of the world, dispatching events, tracking protocols. It also makes perfect sense, given the pragmatic need to support massive collections of concurrent FSMs.

But here’s the flip side: there is little support for processing large, shared data structures - unless they come from an external source, such as a database, which takes responsibility for locking and synchronization.

So when it comes to problems that really want to be done in a straightforward shared-data style (SIMD scientific computing comes to mind), that’s not as easy anymore - even if the problem itself is inherently parallelizable. One gets a sense that Erlang’s concurrency primitives are general-purpose, but they’re definitely oriented towards very specific applications of concurrency.

Second, I enjoyed the explanation of one particular detail of Erlang: in the message-passing implementation, individual processes don’t handle messages immediately. Instead, there’s a concept of “mailboxes” where messages get queued up, and handled only when the process is in the right state, and has all the messages it needs.

This seems unusual, especially coming from the traditional programming background, where messages are merely a vehicle for doing RPC. But that’s not how this language uses them.

Erlang’s finite state machines implement and validate message-oriented protocols. Immediate message handling would make this much more complicated:

[W]e observed that handling out-of-order messages in a finite state machine led to an explosion in the state space of the finite state machine. This happens more often than you think, in particular when processing remote procedure calls. Most of the telecommunications programs we write deal with message-oriented protocols.

This is a pretty nice idea. In my own previous attempts at building large collections of parallel FSMs, I encountered similar problems, caused by immediate input processing. I ended up having to split a single “conceptual FSM” into multiple concrete FSMs, and broadcast all inputs to all of them, just to be able to deal with out-of-order messages. But then coordinating them all turned into a major problem. In retrospect, a message-based approach with mailboxes and pattern matching over those mailboxes would have been a clear win.

Third, Erlang is somewhat infamous for its distributed error handling mechanism. Most languages are very specific about how errors propagage - Java and C# errors, for example, always travel up the call stack; one could imagine a similar scheme for a message-passing system.

Erlang, however, completely washes its hands of this responsibility. Failed processes post an error, but it’s up to the programmer to make sure some other process somewhere else is looking for those errors.

I was always curious what prompted such an unusual mechanism, and the paper illuminates that:

The idea of links and of the mechanism by which all processes in a set die was due to Mike Williams. Mike’s idea was inspired by the design of the release mechanism used in old analogue telephones and exchanges. In the analogue telephones and in the early electromechanical exchanges, three wires called A, B and C were connected to the phones. The C wire went back to the exchange and through all the electromechanical relays involved in setting up a call. If anything went wrong, or if either partner terminated the call, then the C wire was grounded. Grounding the C wire caused a knock-on effect in the exchange that freed all resources connected to the C line.

This is very powerful. You want errors to propagate via some unexpected route, to a master controller that shuts down all sorts of things, and then maybe attempts recovery? You can set that up fairly easily.

At the same time, it feels dangerous, since one is no longer relying on the runtime for error handling. Now it’s up to the programmers to design an error propagation network. But relying on convention doesn’t scale very well; and besides, isn’t this why we have compilers, to do the boring enforcement work for us?

All in all, a fascinating read!

Last week I discovered a very nice language named Clojure. It’s based on Lisp, but hosted on the Java platform, and running inside the JVM. It has some lovely features, like native support for Java collections, and a clean API that ditches a lot of the old ANSI CL library cruft.

But the best part for me was language interop: Clojure can effortlessly load and use any external Java library. And there is a ton of good ones out there, including a rich set that comes with the Java platform. (This may seem like a minor point, but most free Lisps lack good libraries; only the non-free Allegro CL has really extensive, cross-platform ones.)

So I decided to take the language for a spin, especially exercising the language interop bit. For example, by building a little web server to serve up some dynamic content. You know, web development 101 kind of stuff. This turns out to be really easy to do.

Since Clojure is backed by Java, we can use an existing server library to do the heavy lifting for us. Several high-quality ones are available - I went with Jetty, a servlet-based engine that’s really easy to embed in custom applications. Using a servlet container will take care of all the mundane bookkeeping for us.

In the following posting, I’m reproducing the steps required to get a Clojure-based web server up and running, in much less than 100 lines of code. Hope you find it interesting!

I’ll split this into three parts:

1. Getting Jetty and setting up your Clojure environment
2. Creating a server that only serves up static pages
3. Modifying the server to provide dynamic content

Let’s go through them.

1. Getting Jetty and environment setup.

(The following requires Clojure release 2008/03/29 or later.)

Jetty is a huge library, but we’ll only need three jars from it. So let’s do the following:

• Download Jetty 6.1.9, or whichever is latest, from the official site
• Get the following jar files from the archive, and place them in some preferred directory (I put them under clojure/lib):
  • jetty-6.1.9.jar
  • jetty-util-6.1.9.jar
  • servlet-api-2.5-6.1.9.jar
• In whatever script / batch file / elisp command you use to start up your Clojure instance, modify your classpath to include them. In my case, I end up with the enormous:

“java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4096 -cp c:/users/rob/documents/clojure/clojure.jar;c:/users/rob/documents/clojure/lib/jetty-6.1.9.jar;c:/users/rob/documents/clojure/lib/jetty-util-6.1.9.jar;c:/users/rob/documents/clojure/lib/servlet-api-2.5-6.1.9.jar clojure.lang.Repl c:/users/rob/documents/clojure/src/boot.clj”

To verify, start up your Clojure instance, and try creating a new Jetty Server instance - it should look something like the following:

Clojure
user=> (import '(org.mortbay.jetty Server))
nil
user=> (new Server)
Server@1f0f8ff
user=>

All right, now we’re ready to have some fun.

2. Writing a server for static pages

Jetty comes with a default servlet for static html pages. We just need to configure it.

We could do this from an xml file, as recommended for Jetty deployment in production environments. But that’s more work than is needed for this experiment.  :)  Instead, we’ll configure a small and minimal server instance from Clojure code itself.

First, a big bunch of imports:

(import
 '(java.io File)
 '(javax.servlet.http HttpServlet HttpServletRequest HttpServletResponse)
 '(org.mortbay.jetty Server Handler Connector NCSARequestLog)
 '(org.mortbay.jetty.handler HandlerCollection ContextHandlerCollection RequestLogHandler)
 '(org.mortbay.jetty.nio BlockingChannelConnector)
 '(org.mortbay.jetty.servlet Context DefaultServlet ServletHolder SessionHandler))

Now let’s add a few constants that we’ll need later on (customize as needed, of course):

;; server port
(def *port* 8080)

;; static pages will be served from this directory
(def *wwwdir* "C:/Users/Rob/Documents/Projects/Clojure Http Server/pages")

;; log files go here
(def *logdir* "C:/Users/Rob/Documents/Projects/Clojure Http Server/log")

;; specifies naming pattern for log files
(def *logfiles* "log.yyyy_mm_dd.txt")

The Jetty server itself contains some connectors, which read data from sockets and feed it to a bunch handlers. Let’s make one.

;; create connector on the specified port
(defn make-connectors [port]
  (let [conn (new BlockingChannelConnector)]
    (. conn (setPort port))
    (into-array [conn])))

One of the built-in handlers is a logger, which just writes out an access log file. Another built-in one is a context handler, which contains a set of servlets. It preprocesses any received data, and then hands it over to one of its servlets, based on the path being requested in the URL.

Here’s how I configure both of them:

;; configures a default servlet to serve static pages from the "/" directory
(defn configure-context-handlers [contexts]
  (let [context (new Context contexts "/" (. Context NO_SESSIONS))]
    (. context (setWelcomeFiles (into-array ["index.html"])))
    (. context (setResourceBase (. (new File *wwwdir*) (getPath))))
    (. context (setSessionHandler (new SessionHandler)))
    (. context (addServlet (new ServletHolder (new DefaultServlet)) “/*”))
    context))

;; set up handlers: the context ones, and a logger to track all http requests
(defn make-handlers [contexts]
  (let [handlers (new HandlerCollection)
        logger (new RequestLogHandler)
        logfile (new File *logdir* *logfiles*)]

    (. logger (setRequestLog (new NCSARequestLog (. logfile (getPath)))))
    (. handlers (addHandler logger))
    (. handlers (addHandler contexts))
    handlers))

All that’s left is standing up the actual server. That’s frighteningly easy:

;; make an empty collection of context handlers - we'll configure it later
(defn make-contexts []
  (new ContextHandlerCollection))

;; make an instance of the http server
(defn make-server
  ([] (make-server *port*))
  ([port]
     (let [contexts (make-contexts)
           connectors (make-connectors port)
           handlers (make-handlers contexts)
           server (new Server)]
       (. server (setConnectors connectors))
       (. server (setHandler handlers))
       (configure-context-handlers contexts)
       server)))

And that’s it! Go ahead, try it!

First, place an “index.html” page in the directory you specified under *wwwdir*. Then run the server:

user=> (def server (make-server))
2008-04-26 23:32:02.752::INFO:  Logging to STDERR via org.mortbay.log.StdErrLog
#<Var: user/server>
user=> (. server (start))
2008-04-26 23:32:10.863::INFO:  jetty-6.1.9
2008-04-26 23:32:10.898::INFO:  Opened C:\Users\Rob\Documents\Projects\Clojure Http Server\log\log.2008_04_27.txt
2008-04-26 23:32:10.962::INFO:  Started BlockingChannelConnector@0.0.0.0:8080
nil

… and then navigate over to the right page:

To stop the server, just call the method with the same name:

user=> (. server (stop))
nil
 

3. Servlet that produces dynamic content

The next step is writing our own servlet, which will serve arbitrary, dynamic content. The Java Servlet API is quite powerful, and makes it easy to build all sorts of wacky web wonders.

Let’s start by writing our own request processing function: it will take an HTTP request and response objects, and just write out current time as the response:

(defn process [#^HttpServletRequest req #^HttpServletResponse resp]
  (let [out (. resp (getOutputStream))]
    (. out (println (str “Test Successful at ” (new java.util.Date)))))) 

(The type hints aren’t strictly necessary, but they’re there for my sanity, to remind me what Java classes are hiding behind the various variables.)

Also, make a new servlet that will use this function to process each request:

;; implementation of an HttpServlet, overriding just one function:
;;   protected void doGet(HttpServletRequest req, HttpServletResponse resp)
(defn make-test-servlet []
     (proxy [HttpServlet] []
       (doGet [#^HttpServletRequest req #^HttpServletResponse resp]
          (process req resp))))

Finally, hook it up to the context handler, so that it will serve all requests for the “/test” URL. We just modify the function mentioned above, by adding a single line highlighted below:

(defn configure-context-handlers [contexts]
  (let [context (new Context contexts "/" (. Context NO_SESSIONS))]
    (. context (setWelcomeFiles (into-array ["index.html"])))
    (. context (setResourceBase (. (new File *wwwdir*) (getPath))))
    (. context (setSessionHandler (new SessionHandler)))
    (. context (addServlet (new ServletHolder (new DefaultServlet)) “/*”))
    (. context (addServlet (new ServletHolder (make-test-servlet)) “/test”))
    context))

That’s that! Now run the server again, and check out the results:

Final Words

This is clearly just an experiment, and not a production-ready system. But using Jetty as the server engine makes the system easy to build and very robust - it’s easy to imagine how one could go about building an actual, fully-featured web service around this technology.

Hope this was amusing!

The typical example is reading from disk, or accessing a database. Disk operations are orders of magnitude slower than operations on memory. If the data we need is already loaded and in memory, that’s great, we can use it immediately - but if it isn’t, we’ll have to load it first. And we wouldn’t want to put the whole game on hold, while we wait for the drive to seek to the appropriate sector on the disk.

The standard solution is to split the work into multiple threads: the fast main thread, which handles time-sensitive processing, and a worker thread (or a pool of threads), which will handle anything that could potentially block. But how to implement this?

In an ideal world, we’d just hand over the current continuation to a new lightweight process, operating on immutable data, and that would take care of everything. But ours is not an ideal world; we have to deal with messy details.

In practice, there are significant differences of opinion on how to go about farming out slow tasks to asynchronous workers. This will depend greatly on what the language allows, and what kind of bookkeeping we’re willing to live with.

Pool of work unit processors

Some higher-level languages have very nice abstractions for dealing with units of work. At the heart of this abstraction is a dispatcher: we give it a work unit, and it will take care of executing it independently of the main thread. Dispatchers typically manage their own pool of worker threads - each incoming work unit gets assigned to the next available thread, or queued up for future execution if all workers are busy.

An example of a dispatcher in Java is the Executor interface. One might say something like:

  final ProxyObject proxy = ProxyFactory.get(creatureType);
  executor.execute(new Runnable() {
    // this might take a while:
    ObjectData data = db.load(proxy.id);
    proxy.update(data);
  }

The code snippet creates a new anonymous Runnable object with a specific payload (loading data from the database, updating the proxy object with the results). The call to execute() returns immediately - and the work unit will be executed sometime in the future on a separate thread. (Anonymous class instances are a particular feature of Java, of course, but it’s possible to achieve the same effect by passing in callback functions or their equivalents.)

This level of abstraction is very convenient. Having customized work units whenever we need them lets us keep all game logic in the same place: the work unit code is written in the same place as the rest of game logic, even though it will be executed on a different thread, at some other point in time. This makes the code easy to follow.

It’s also easy to chain work units together. For example, suppose we have a multi-step process: read from the database, do some processing on the results, then use that to read something else from the database. It’s very clear how to write a work unit that does the processing, and in turn creates another work unit.

But that’s also a problem: any shared data will now require explicit synchronization, since it will be accessed from other threads at unpredictable points in the future. In the example above, the proxy object will have to be made safe for updates from multiple threads. Ad hoc work units mean we have to pay the cost of making shared data thread-safe.

Standalone processor

Sometimes sharing work units across threads is unavailable (eg. because of platform limitations) or undesirable. We can then use a more traditional solution: a dedicated processor that runs on a separate thread, which accepts work requests, and takes care of everything.

For example, a game thread might ask a resource loader for some resource by its id, and get a proxy back:

  ProxyObject proxy = app.resourceLoader.startLoading(creatureType);

…and that’s it. An empty proxy object is now ready to use, albeit lacking any useful data. At some point in the future, the processor will do all the blocking operations, and process their results: read from the database, lock the proxy, and clobber its contents with updated data. But this will be invisible to the caller. (Async proxies are another interesting abstraction, one deserving its own topic.)

Performance and access control are the main benefits of this approach. If the processor runs only its own processing code, instead of arbitrary work units, it’s much easier to inspect what it does and tune its performance. As for access control, the loader does not exist in the same “code space” as the game logic, and has no access to local game data. We need to explicitly give it access to anything that it might need. This way it’s easier to keep track of which threads are accessing what kind of data, and see where we need to provide locks or other synchronization mechanisms.

But its generality is also a problem. Ad-hoc work units are very easy to customize - we can do custom processing depending on the surrounding game logic (eg. a work unit for an agent might do one thing, a work unit for a scenery object might do something else, and so on). A generic processor, however, will not have this kind of game-specific logic.

Since it will be used by all parts of the game (and possibly more than one game), developers will be tempted to treat it as a library, and keep it general, abstract, and reusable. While that’s an excellent approach for a library, it limits what it can do for a specific game.

If customization is desirable, it will be up to the game system to find a way to manipulate the results of asynchronous processing. As a result, client objects (eg. proxies) may end up inheriting a lot of responsibility for post-processing the results.

Separation

These two cases illustrate two popular approaches to dealing with slow, I/O-bound operations:

1. Having a separate pool of worker threads and ad hoc asynchronous work units
2. Having a dedicated subsystem that is completely responsible for a limited set of desirable asynchronous operations

Dedicated system approach is more popular with performance-minded applications, such as console games, because the system’s performance can be more precisely managed. Tight control also allows for certain optimizations, such as pre-fetching data before it’s actually needed.

Ad hoc execution of asynchronous work units affords greater flexibility. They are easier to customize than a generic library, and there are no concerns about how exactly to split the work between the library and game code. At the same time, the solution requires a sacrifice of control. It’s more common in applications where it’s acceptable to trade some performance in exchange for readability and customizability.

It’s mostly straightforward, except for dealing with spaces in path names. It turns out that slime.el uses the (split-string) function to pull apart the Lisp command line, which won’t work with the default “c:\program files\…” location. Here’s how to fix that, using symbolic links (yes, Windows supports them too!).

The following was tested on a Vista box, SBCL 1.0.13, and Slime 2.0 on Emacs 22.2.1.

Installing SBCL:

1. Download and install SBCL. By default, it will install to c:\Program Files\Steel Bank Common Lisp\1.0.13
2. Run cmd.exe as Administrator (required for symbolic links)
3. Set up a link from SBCL install directory, to some location without spaces. Note that the syntax is an inverse of the Unix ‘ln’ command.
   

   C:\Users\Rob\Documents>ver
   Microsoft Windows [Version 6.0.6000]

   C:\Users\Rob\Documents>mklink /d SBCL “c:\Program Files\Steel Bank Common Lisp\1.0.13″
   symbolic link created for SBCL <<===>> c:\Program Files\Steel Bank Common Lisp\1.0.13

   C:\Users\Rob\Documents>dir sbcl*
   …
   04/09/2008 09:07 PM <SYMLINKD> SBCL [c:\Program Files\Steel Bank Common Lisp\1.0.13]

Installing Emacs and Slime:

1. Download Emacs, unzip it to any location (eg. c:\Program Files\emacs). If desired, run the emacs\bin\addpm.exe program to add a link to the start menu.
2. Download Slime, and unzip it under your emacs/site-lisp directory.
3. Add the following to your ~/.emacs file:
   

   (setq inferior-lisp-program “c:/users/rob/documents/sbcl/sbcl.exe –core c:/users/rob/documents/sbcl/sbcl.core”)
   (require ’slime)
   (slime-setup) 

4. Restart Emacs, and then run M-x run-lisp to test whether Lisp starts up.
5. Start slime with M-x slime. Happy hacking!

Below is a live view into my room - stop by and say hello!

The popular funding models are: 

• Indirect ad sales - ad rotator networks, etc., which let people participate in a larger pool of ad space providers
• Direct ad sales - such as doing a deal with a specific client, for banner or in-game ads
• Shareware model - aka try-and-buy, typically with a content lock (e.g. first level free) or a time lock (first hour free)
• Subscription - the standard MMO approach, pay per month
• Virtual goods model - aka free to play, pay for items

Of these, advertising is the most popular entry-level option, but it has its pros and cons.

Indirect ads are the easiest to get into - just sign up with AdSense or one of the other ad networks, and watch the money come flowing in! Except apparently it’s not that much money. People were mentioning ad revenue figures on the order of a few cents per thousand impressions. ¹ 

Direct ad sales seem to fare better, since you can deal with clients who want to target specific demographics. In their Worlds in Motion session, the WarBook devs praised this model. But they also admitted to 700 million pageviews per month (across all of their games), and their access to players’ demographic info makes them very appealing to advertisers. A brand new project won’t be able to play in that league.

The other popular model is shareware - downloadable games with free trial versions, and full versions available for purchase. It’s a classic model (Doom and Quake come to mind), with the trial version typically limited in content (e.g. first level or chapter free) or game time (e.g. first hour free).

This model was the focus of much discussion, since it’s the primary model for the established players. It’s clear that it can do wonders for hit games, especially since the full game price is customarily set at $10 or $20. But standard games don’t fare as well. Only ~1% of players end up buying the full version, and even then, distributors take a significant chunk. Additionally, most downloadable games get their players from portals, which exhibit significant churn due to a large number of very similar games being created - so differentiation and getting to the top of listings are both difficult.

The other two models are subscriptions, and “free to play, pay for items.” The latter has worked very well for us, while the former works for others, including the 800-pound gorilla of MMOs. Both systems have a significant optimal case, however - they’re best for games where players are compelled to keep coming back to the game, over and over again. Fitting this against ”consumable” games is non-trivial.

So the dominant model is still content-limited shareware, but it’s not an optimal case: budgets can be brutal unless your game becomes a huge hit. But banking on blockbusters is a classic hit-driven studio funding scheme, with familiar drawbacks, only recapitulated on a smaller scale. A more stable model is something like subscriptions or virtual items, which scale nicely, but they require a larger, continuous kind of a game.

The viral coefficient is a measure of how many new users are brought in by each existing user. It’s a quick and easy way to measure growth: if the coefficient is 1.0, the site grows linearly, and if it’s less than that, it will slow down. And if the coefficent is higher than 1.0, you have superlinear growth of a runaway hit.

In an invite-only situation (e.g. gmail closed beta), it’s easiest to calculate this directly, based on how many people are being invited by each new user, and how many of the invitees create new accounts themselves. The viral coefficient is simply:

v = new user invites accepted / new users
   = accepts_t / δp_t-1

where δp_t denote the number of new users who join in time slice t (ie, the increase in population between p_t-1 and p_t). 

But most sites have an open account creation policy. For those, we’ll have to estimate population acceleration from raw population deltas. Let’s assume that each accepted invite is quivalent to creating a new account at the next time slice. Then we can estimate virability as:

v ≈ δp_t / δp_t-1
   = (p_t - p_t-1) / (p_t-1 - p_t-2)

which is an acceleration metric, easy to compute from historical data. 
 

Population Forecasting 

Viral estimate calculated as momentary acceleration will fluctuate over time. But we can use it for some short term forecasting.

To calculate expected future population p_t some t steps in the future, given the viral coefficient and present population p₀, we first invert the above:

δp_t = v δp_t-1 = … = v^t δp₀

and plug this right back in:

p_t = δp_t + p_t-1
    = Σ_k≤t  δp_k + p₀
    = Σ_k≤t  v^k δp₀ + p₀

This describes a geometric series. When v ≠ 1, p_t  = δp₀ (1 - v^t+1) / (1 - v) + p₀ 

Quick note on methodology: I ran these primitive operations in a tight loop of a few million iterations, to get average runtime per iteration (subtracting out the runtime of an empty loop, of course), and then repeated this a handful of times. I’m reporting mean numbers below, and standard deviations only when they’re unusual.

The raw times aren’t very important (benchmarks were done on an old Athlon 2400+ that’s living out its retirement years under my kitchen table). But the proportional differences between them can be surprising - especially the order-of-magnitude ones.

Now, on to some delicious results!

Numbers

Some obligatory numeric operation benchmarks:

Signed integer addition: 6.3ns
Signed integer multiplication: 13.1ns
Signed integer division: 15.3ns

Unsigned integer addition: 9.6ns
Unsigned integer multiplication: 28.3ns
Unsigned integer division: 32.4ns

Double addition: 9.4ns
Double multiplication: 7.4ns
Double division: 7.1ns

There’s really no reason not to use doubles for virtually all math operations; they’re much cheaper (possibly because they don’t try to do any bounds checks).

The one exception would be array indexing, where one really wants to guarantee that the index is an integer. Fortunately, conversions are pretty inexpensive as well:

Integer -> Number conversion: 7.3ns
Number -> integer conversion: 5.0ns

Now for some math library operations:

Math.sqrt: 137.9ns
Math.sin: 183.3ns
Math.round: 197.9ns
Math.floor: 160.2ns

That’s pretty good, much faster than regular function calls (see below) - probably because these are native, instead of bottoming out in bytecode like everything else. Still, a square root is on the order of about 20 times more expensive than arithmetic operations.

Function Calls

Speaking of which, here are the regular function calls - just the call, with no body:

Function call (no arguments): 239.8ns
Function call (unary): 257.6ns
Function call (binary): 269.0ns

Pretty standard stuff, with cost increasing (linearly?) as a function of the number of arguments. It’s more expensive than calling native functions, but not significantly higher. Still, it does put an upper limit of about 4 million function calls a second, or 100,000 calls per frame, on my test machine.

By the way, this was completely unexpected:

Anonymous function declaration: 11368.8ns (s = 105.3)

Creating an instance of an anonymous function costs 11 microseconds? Ouch. I’m a big fan of treating everything as lists of data, and map-filtering them with ad-hoc anonymous functions. But now I have to be more careful.

Arrays

For array access, I’ve only checked access of a single array element, many times over. Some numbers:

Writing from variable to array: 69.0ns, s = 1.9
Reading from array to variable: 106.3ns, s = 105.5
Reading from object with integer keys: 72.0ns, s = 1.9
Reading from object with string keys: 242.8ns, s = 1.8

First, I thought it was interesting that an object with integer keys is just as fast as an array with integer keys, suggesting a shared underlying implementation. An object with string keys is slower, however.

Two, the array reading measurement is not only pretty high, it also has a very high standard deviation, as if the measurements included a few really expensive outliers. Am I running into intermittent delays when accessing array data; perhaps cache stalls?

Finally, some results trying to iterate over a large array:

Iteration over array using ‘for each’ special syntax: 8576.8ns, s = 2.4
Iteration over array using int: 20483.5ns, s = 4.6
Iteration over array using uint: 19665.3ns, s = 2.8
Iteration over array using forEach: 31416.8ns, s = 47.7

I’m not susprised that code inside a for loop is faster than code inside a function called via forEach. What I am surprised about, is that the “for each ( … )” special form is much faster than the standard “for ( ; ; )” iteration with array lookup. That’s not what you’d expect in a language like C; I’m curious what’s going on under the hood.

Afterwards, I got to hang out with some nice Yahoo people, and chat about their research and the future of web-based social interaction. Very stimulating. I wish I could do that more often.