Execution Environment, plus Who's your Daddy?

Following my posts on Boxely (pt 1 and pt 2) and the OCP, I had planned to talk about the EE (Execution Engine) in some detail. But John Robinson (aka JR), who's been the Chief Architect and (with Dave Besbris) one of the prime drivers of the OCP, beat me to it.

He jumps right to features and benefits, and so is more succinct than I would have been. Its a good read. Plus, it saves me the trouble :)

A few comments:

• The EE (as the underlying engine of the OCP) is about supporting a more scalable, abstracted runtime environment. For example, a lot of design time went into versioning and deployment considerations, and a lot of thought went in to figuring out how to minimize service APIs.
  There's a big difference between object-oriented or component development and the services model we're advocating in the OCP (which isn't necessarily fully reflected in all of our first generation services).
• Although the EE provides native platform interop, we specifically limited how MUCH of the interop we exposed (feature wise) for two reasons: (1) to insure greater portabililty and less reliance on the underlying infrastructure (by portability, I even mean things like: we don't support any design patterns that only make sense in compiled lanuages vs. interpreted ones like Javascript), and (2) even more, to limit the number of design patterns we used in the construction/consumption of our services to make our APIs more consistent and learnable.
  A rationale platform is more than just a collection of services.
• One of the core guiding priniciples of the OCP is data driven design: factoring policy OUT of code - turning technology limitations into business and product choices, as they should be.
  

Who's your Daddy?
Completely unrelated to the EE, but if you read further down on JR's blog, you'll see that he discusses a coding contest some of us former hard-core coders had here at AOL a few weeks ago - as John notes, it wasn't anything official, just an informal challenge a small group of us conducted for one week (after hours, of course :)).

The challenge was to write a fast, efficient memory allocator for small blocks (1024 bytes or less), as compared to the Microsoft C common runtime (MSVCRT) and SmartHeap. We used both a custom test and the smart heap benchmark for comparison.

John goes into some more details in his post - I just wanted to point out that I was the winner :)

I'll post the code and benchmark harness at some point in the near future, but the scores (per the system JR mentions on his blog) were as follows:

Lower is better (names changed to protect the innocent):

1. Sree Kotay 13584.3
2. Bave Desbris 15652.2
3. Rohn Jobinson 16378.4
4. Mat Peenan 16709.2
5. Microsoft CRT 52516.8
6. Park Moesch [no show]
7. Cave Dorboy [no show]

Justin Uberti kindly judged for us.

We couldn't benchmark smartheap entirely accurately (because it doesn't call our base allocator for memory efficiency measurement), but using the amount reported by the OS as a proxy, well, suffice it to say that it came out in middle of the pack, in both speed and efficiency.

So, in summation: NYAH NYAH NYAH hahah!!!! :P