James Hobin

The Importance of User Testing (Tea Timer Too)

Tue, 15 Oct 2024 15:00:00 +0000

In part one of this series, I described refining my tea timer as sanding off burrs. I did smooth out my surface-level experience, but my familiarity blinded me to fundamental cracks lurking below. The most powerful method for unburying these faults is user testing. In my day job, we rely on testing with our customers to perfect our software, uncovering both bugs and new features. User testing has also been invaluable for many of my side projects (especially the games). A second pair of eyes is worth its weight in gold but is often just as difficult to acquire.

Luckily, I have a wonderful and patient mom with an unslakable thirst for tea. In other words, I had a terrific tea timer tester. One brief explanation later, my mom set a timer and turned off the timer when it finished. However, her timing journey would run into two cracks that needed repair.

The first was easy to spot: after pressing a button to start the timer my mom would wait to see if the timer had started, often pressing multiple times to make sure. This was due to the lack of immediate visual feedback. Instead, the first indication of the timer running would happen several seconds later when a lighted button turned off on the other side of the board. I added a quick animation across all the buttons, filling in this first crack.

It took a bit longer for the second flaw to surface. My mom accidentally started the timer and didn’t know how to stop it. When she asked me and I answered “unplug it” I realized that there had to be a better way. A couple of lines of code and a brief test later, I had added the final improvement (for now!) to the tea timer: long pressing to cancel.

The timer was now in a much better state thanks to my mom’s fresh perspective and all it cost was 17 cups of Upton’s Traditional Masala Chai (not sponsored but would jump at the opportunity). Behold! Its final form!

Of course, even in this state of alleged perfection there is a fundamental issue with the timer I feel like I should discuss. There are no affordances! Affordances is jargon for “bits of a thing that make it obvious how you can do stuff with it.” For example, a tea pot’s lid suggests opening it up, its handle suggests lifting it up, and its spout suggests pouring. Because I’m using a generic 4x8 grid of buttons (generic but really quite wonderful, thank you very much Adafruit) there are no affordances guiding how to use the timer. I can instead give a brief explanation on how to use the timer every time someone gets within range, but with my hourly rate this affordance workaround isn’t affordable (sorry). Perhaps part three in this tea saga is a hardware project with purpose-built design. For now, thank you for reading this journey from zero to hero! May your tea always be steeped for the appropriate time.

Tea Timer

Sat, 05 Oct 2024 15:00:00 +0000

Brewing tea is a simple process of using water to extract the bits from tea leaves. Top minds have been doing this for several years, coming up with a general idea of how long one is meant to leave the leaves in the water. Unfortunately, as a rather forgetful person, my usual tea steep of 15-30 minutes falls outside of the expert opinions on the matter. The normal way to fix this would be a phone timer, but my forgetfulness has gained the ability to silence the timer and move on without informing my brain. I embarked on a new project, creating a timer that would force me to collect my tea.

In this post I document this excellent exercise in experimentation and interaction. If learning isn’t compelling enough, I suggest watching this video of the finished timer to be overcome with jealousy:

Now the easy solution would be to buy an egg timer and put it near the tea kettle but that would make this a rather short blog post. Also, it would cost money! Outrageous! Instead, I set my sights on the free-right-now-since-I-paid-for-it-in-the-past Adafruit NeoTrellis M4. With 32 light-up buttons and the ability to play back sound files it was the perfect block of wood to hack out a timer that would get the job done.

After a short montage of AdaFruit’s excellent tutorials and my own CircuitPython programming, I had a useful creation. Pressing a button (mapped out on the colors of the leds, very straightforwards!) would result in a timer counting down and reminding me of my tea’s existence with a bright flashing light in my peripheral vision. Now that I finished this project, it was time for the project to really begin.

Wait, what?

It was terrible! I had to power cycle it every time I wanted to start a new timer! That’s the worst! It was time to sand all the splinters and other sharp bits off of this unfinished hunk of wood.

Shoring up the foundation

But first it was time to clean up the code, the coolest and most exciting thing to do at any stage of a project. It was tempting to cut out this part of the post–silently suggesting that a divine light had guided my hand towards perfect code even while quickly iterating through versions–but no, there were flaws. The spring cleaning on the agenda was to trim away all of the unnecessary tutorial code and to replace hardcoded colors with the excellent fancyled library’s palettes. Emboldened by this easy progress, I also threw in some audio with the idea that I would someday hook up an external speaker to the Trellis.

Start again

The sharpest splinter on the board was having to restart the Trellis to get another timer going. I took all the code that ran the timer, shoved it in a forever-looping while True:, and moved on with my life. Well, moved on for as long as it took me to test the timer, as this shove-based coding (inspired by my shove-based cleaning) meant that the same button press that stopped the timer would also start the next timer due to the critical lack of a delay between loops. One delay later and I could finally plug the Trellis in by my kettle and call it a day.

Wait! It’s still bad!

After a few weeks of using my beloved tea timer I had a couple of Notes. First, one of my fussier teas demands a 2 minute 30 second steep. With my minimalist inputs, that wasn’t happening and the leaves were crying. Next, I could still (somehow) miss the dramatic flashing lights coming from my speaker-less Trellis. When I’d finally rush to the blinking beacon in disarray, it would also not let me know how long it had been trying to get my attention. I bought a cheap speaker that may as well have been purpose-built for using with the Trellis and solved both of the later problems. Finally, through learning to stop worrying about tea-crimes I laid the first problem to rest.

The timer was still mediocre though, stay tuned for the thrilling conclusion of our saga!

Bluetooth Rotary Phone

Wed, 11 Sep 2024 15:00:00 +0000

Old technology is just the best! It clacks, thunks, and makes all the other tactile noises one could ever need. I had the idea to make a rotary cell phone way back in high school, but when I priced out the fancy electronics required it was far outside of my budget in terms of both money and expertise. I buried the idea in my mind’s bog of unused concepts and did a few things for a couple years.

With those few things (college, jobs, marriage) out of the way and those couple years (thirteen) past, the idea of a portable rotary phone I could use to make calls bubbled up out of the bog. This time I was older and widely available technology had progressed to the point where I was able to chart a path to clickety-clackety greatness. If you want a bluetooth rotary phone of your own, read on! It’s not that difficult in the grand scheme of things.

Note: There are fewer photos than I’d like of this project’s more fiddly steps so following along may be a bit difficult in the grand scheme of things.

Components

The through-line of this project is that in the magic land of 2024 there are now devices that can plug into an old landline phone and act as a bluetooth accessory capable of making and receiving phone calls. To make a portable rotary phone, I only had to get one of these boxes, power it with a battery, and shove both into the body of a rotary phone.

Assembly

Test Run

The first step was to get everything working without doing any fancy assembly. This gave a good, working baseline and allowed me to pair the XLink BT with my phone before it was trapped inside the rotary phone’s case.

Placing XLink BT in the phone case

After the test run, I freed the XLink BT from its bulky plastic enclosure. Next, I removed the bulky weight from the inside of the rotary phone, freeing up a perfect place to slot the peeled circuit board. I then glued the XLink BT in place and screwed the phone’s electronics back in place.

Placing battery in phone

I took some time to mess around with the battery to find a good fit for it. This location had to allow the charging wire to be guided to the back of the phone while the power wire with the inline switch had to reach the XLink BT. Once I found a place, I used duct tape to hold the battery in place since I was too chicken to cross hot glue with a lithium battery.

Cabling

With all of the main players in place, it was time to hook up the cables and drill some holes in the case to let them breath. I drilled one hole in the back for the charging cable.

For the on/off switch I drilled a larger hole allowing me to insert a pencil or equivalent stick-like object to hit the switch from the outside. While not the most engineering-savvy solution, this was a lower profile and easier than making a hole for the entire switch.

Reassemble!

Cables connected and electronics arranged, I reassembled the rotary phone and it all worked! After learning what a “hook flash” is (a brief tap on the hook), I painstakingly placed a call, ready to brag about being the personification of cool that my teenage self had imagined.

Untangling WebSockets

Sat, 25 Mar 2017 15:00:00 +0000

I have a confession to make. I enjoy reading RFCs. I love the ascii-art technical diagrams, the ruthless exposition of edge-cases, and the frenzied all-caps MUST, REQUIRED, and SHALL.

In my day job, I work on a system that relies on websockets to function. It’s effectively a ten-thousand line switchboard for websocket connections that happens to have an augmented reality interface. I decided to read RFC 6455, The WebSocket Protocol, to make sure that I had the best possible handle on the internal plumbing of my work.

The most critical concept the RFC specifies is that WebSockets are an upgrade of an existing HTTP connection. This means that any information sent over websockets will be subject to all of the guarantees and limitations of TCP. First, the information will always arrive in the exact same order that it was sent. Second, it will never fail to cross the information superhighway and arrive at its destination. However, this reliability can slow down the connection, especially when the network is low quality. I had assumed that websockets were a separate UDP connection when I used them for low-latency multiplayer in Spaaaaace. It turns out that I was just lucky to never run into slow networks while testing that game. Agar.io and other, larger games likely have to care much more about websocket performance.

The second realization I had was that socket.io and other websocket libraries hide an incredible amount of features. WebSockets have special modes for sending binary information, continuing large messages, and keeping idle connections alive. These bells and whistles feel like a great place to look at for extra efficiency and performance in the future.

Finally, I realized that it would be possible for me to create an implementation of the WebSocket protocol. I had previously read most of the documentation for QUIC but after I produced a frame parser I got stuck trying to figure out how to perform a proper cryptographic handshake. The WebSocket protocol has just enough complexity to be interesting while not requiring a comprehensive education in network protocols. My implementation project turned into tokio-websocket, a labor of love which I will cover in an upcoming post.

Let's Make a JavaScript Bundler!

Sat, 28 May 2016 12:00:00 +0000

WebPack, Browserify, and the billion other JavaScript bundlers out there are black boxes into which we feed source code. While these existing tools work quickly and correctly, it’s educational to see the challenges that went in to developing them. This blog will lead you through the journey of creating a JavaScript bundler. Along the way you will learn about abstract syntax trees, digraphs, code generation, traversal orders, scoping rules, and function isolation.

Problem Specification

What does WebPack do anyway? My goal was to take one file that imports other files and turn that into only one bundled file. For complexity’s sake, I chose to support ES6-style imports and exports, which you can read more about on the always wonderful MDN here. I could then fully specify the problem. I wanted to take an entry point, like this:

import a from './a.js';
a()

an included file, like this:

export default function a() {
  console.log('Hello world!');
}

and get a file that will print “Hello world!”.

In terms of syntax, this means supporting the following constructs:

export default expr;
export let a = 2;
export var b = 3;
export const c = 'c';
export function d() {
}

import a from 'source'
import {b, c} from 'source'

Implementation

Step One: AST Printing [138e34b]

I first needed to figure out how to take a JavaScript file and get all of its export and import declarations. In technical terms, I wanted to parse a file to get its AST (abstract syntax tree). As a first step, the code visits every node in this tree, printing the node out if it’s an export or import.

For actually creating this code, AST Explorer is invaluable. We merely need to type the example code above to see exactly what its AST will look like. AST Explorer also allows us to select the parsing engine to use. This project uses Recast for its ability to rewrite ASTs.

Step Two: File Info Printing [b406f0a]

With printing in place, I thought the next step was to store the import and export information in an object. For each export the code stores the exported identifier and its exported name (or “default”). For each import the code stores its identifier, local name, and source. This information can be thought of abstractly as a directed graph (digraph). By pruning orphans or performing other operations on this digraph we can easily create powerful tools like tree shaking. However, this abstraction is too removed from the code generation of I needed for the bundling process.

Step Three: Recasting [ed95f1f]

Now I needed to produce executable code. This was a straightforward extension of the previous work because the modification simply transforms import and export to equivalent statements.

The overall target post-transform looks like this:

(function(scope) {
  // export default function a() {}
  function a() {
    console.log('Hello world!');
  }
  scope['a.js']['default'] = a;
})(scope);
(function(scope) {
  // import a from a.js;
  var a = scope['a.js']['default']
  a();
})(scope);

Each import becomes var localName = scope[source][exportedName];, and each export becomes scope[source][exportedName] = localName;.

To perform this transformation, we can use Recast’s included-by-default AST generation functions in addition to its printing functionality. It turns out that Recast was designed to do exactly this type of AST modification.

Bug One: Reversing DFS Order [b2a7e0a]

This code uses the wrong traversal order, with each import statement preceding its corresponding export.

It generates this:

var test2 = scope["./testmulti.js"]["test2"];
var test3 = scope["./testmulti.js"]["test3"];

scope["test.js"]["default"] = function test() {
  console.log('test!');
};

test();
test2();
test3();

var test3 = scope["./test3.js"]["default"];
scope["./testmulti.js"]["test3"] = test3;

scope["./testmulti.js"]["test2"] = function test2() {
  console.log('testmulti');
};

scope["./test3.js"]["default"] = function() {
  console.log('test3!');
};

Simply moving the concatenation line below the for loop results in the more correct output:

var scope = {
  "test.js": {},
  "./testmulti.js": {},
  "./test3.js": {}
};

scope["./test3.js"]["default"] = function() {
  console.log('test3!');
};

var test3 = scope["./test3.js"]["default"];
scope["./testmulti.js"]["test3"] = test3;

scope["./testmulti.js"]["test2"] = function test2() {
  console.log('testmulti');
};

var test2 = scope["./testmulti.js"]["test2"];
var test3 = scope["./testmulti.js"]["test3"];

scope["test.js"]["default"] = function test() {
  console.log('test!');
};

test();
test2();
test3();

Bug Two: Scope Object Bootstrapping [828826f]

There’s also the small problem of the code’s reliance on this scope object. I needed to initialize it based on the complete set of imports and exports expected by the code. Conveniently, I knew how to do this from step two’s file info printing and was able to generate the following object through a simple code generation step guided by data that was already lying around.

var scope = {
  "test.js": {},
  "./testmulti.js": {},
  "./test3.js": {}
};

Bug Three: Scoping Rules [40b87be]

However, it turns out this output, while pretty, is not correct JavaScript. Because of JavaScript’s scoping rules, the attempt to call the function b shown below will fail because b exists in only the statement’s scope and not the block’s (the entire file in this case). In AST terms, this is the difference between a FunctionExpression (var f = function() {}) vs FunctionDeclaration (function f() {}).

Now we get executable output:

var scope = {
  "test.js": {},
  "./testmulti.js": {},
  "./test3.js": {}
};

scope["./test3.js"]["default"] = function() {
  console.log('test3!');
};

var test3 = scope["./test3.js"]["default"];
scope["./testmulti.js"]["test3"] = test3;

function test2() {
  console.log('testmulti');
}

scope["./testmulti.js"]["test2"] = test2;

var test2 = scope["./testmulti.js"]["test2"];
var test3 = scope["./testmulti.js"]["test3"];

function test() {
  console.log('test!');
}

scope["test.js"]["default"] = test;

test();
test2();
test3();

Bug Three: Isolation [9d2a023]

The final issue with this output is that it doesn’t provide one of the key features of modularized JavaScript: there is no isolation between files. If two files have a variable with the same name, there is the potential for some very strange behavior.

Luckily, JavaScript’s function closures provide isolated scopes for all of our files. A simple utility function later, each file gets its own local scope to use as it pleases while still exporting properly to the global scope.

var scope = {
  "test.js": {},
  "./testmulti.js": {},
  "./test3.js": {}
};

(function(scope) {
  scope["./test3.js"]["default"] = function() {
    console.log('test3!');
  };
})(scope);

(function(scope) {
  var test3 = scope["./test3.js"]["default"];
  scope["./testmulti.js"]["test3"] = test3;

  function test2() {
    console.log('testmulti');
  }

  scope["./testmulti.js"]["test2"] = test2;
})(scope);

(function(scope) {
  var test2 = scope["./testmulti.js"]["test2"];
  var test3 = scope["./testmulti.js"]["test3"];

  function test() {
    console.log('test!');
  }

  scope["test.js"]["default"] = test;

  test();
  test2();
  test3();
})(scope);

Conclusion

The bundler works! It creates an executable file with properly isolated imports. Along the way I used recast’s wonderful JavaScript parsing and AST modification to simplify the bundler’s design. Hopefully you learned something from one of the fun scenarios I encountered. If not, stay tuned for part 2: tree shaking!

CMS.609 Program 0.5

Wed, 16 Mar 2016 12:00:00 +0000

A class I am taking this semester, CMS.609: The Word Made Digital, involves the creation of four to eight computer programs. These programs are intended to explore the intersection of technology with literature. I will write a blog post for each program to discuss my process and artistic intent. This first entry details the creation of Program 0.5. What follows is a story of the wonderful benefits of overdesigning a simple system.

First, context. CMS.609’s professor, Nick Montfort, presented several text generators including Nanette Wylde’s Electronic Flipbooks to guide us in the creation of a “very simple text generator that is nevertheless interesting.” The course description has the other examples. Many of these generators can be viewed as the guided random choice of words in a frame. I viewed my assignment as determining a perfect union of words and frame.

Drawing from the historical computation vibe of the Commodore-64-based examples, I chose to develop a piece using interactive fiction as a frame. In it, a computer would play through an IF game at random. The overdesigning began when I decided it would be fun to write this IF game and its engine from scratch. The engine I designed modeled the game as actions, responses, and words. While I eventually generalized responses as words, the all-encompassing engine was as much of a blessing as a curse.

I probably could have realized that I was taking the first steps down a dark path when I decided to create a tiny domain-specific language for representing the game’s sentences. Instead of having to write `“I “ + randomVerb() + “ the “

randomNoun(), I wanted to be able to write “I $verb the $noun”`. Between the potential productivity gains and the cool challenge of writing a DSL I desperately desired the dollar signs.

The first bug appeared moments after the first version’s completion. I decided that there should be adjectives for items, and that this would be represented as a $itemAdjective $item. Unfortunately, this was turning into a swordAdjective goblet instead of a shiny goblet. The DSL engine was selecting to interpret the phrase as a ($item)Adjective $item because I defined $item before $itemAdjective. There were three possible solutions to this problem. The first would be to live in fear of the engine, moving the declaration of itemAdjective before item according to its whims. The second would be to force the engine into reordering its declarations, obeying its cruel leader without question. The third was to lovingly teach the engine how it could stop making prefix-based errors in the future. The nice option was also the only option that did not feel hacky and brittle. Instead of relying on the specific implementation, I instead told the engine that keywords were of the form $something or $somethingElse. With this knowledge it knew to continue reading after the $item in $itemAdjective. While not fitting into the happy tone of this story, the actual fix was to teach the engine greed in the form of the greedy regular expression /\$\w+/. This supplanted the for-every-keyword loop of find-and-replacing with a targeted, efficient search.

The dark and winding road did not end there. It instead wended its way into a thicket of arbitrarily nested keyword substitutions. A standard substitution starts with a base sentence, like You see a $itemAdjective $item. After the first step of substitutions, it becomes You see a $gem-encrusted sword. The final selection then fills in $gem, leaving You see a ruby-encrusted sword. A more detailed representation of this execution is as follows:

You see a $itemAdjective $item.
$itemAdjective -> $gem-encrusted
$item -> sword

You see a $gem-encrusted sword.
$gem -> ruby

You see a ruby-encrusted sword.

Note that this is completely unnecessary for an MVP as "$gem-encrusted" could instead be manually expanded to ["ruby-encrusted", "sapphire-encrusted", "garnet-encrusted"], etc. through a bit of copy-pasting. Luckily, the generic design required to fix the $itemAdjective bug made supporting these recursive substitutions a simple matter of inserting a while loop to make the engine continue until it sees no keywords.

At the end of the day, the overcomplicated but generic design ended up saving just as much time as it cost. As an added bonus, it was more educational than hiding bugs through copy-pasting. To paraphrase a saying from Germany, why do it quickly when you can do it difficultly?

Low-level Optimization in a High-level Language

Tue, 01 Dec 2015 04:00:00 +0000

A year ago I took Performance Engineering Optimization. The first lecture launched into a study of matrix multiplication. Starting with a simple python program, the professor ran through a series of optimization techniques that sped up the program by a factor of 52,479. However, the first step in this process was to switch to C. I began wondering what would happen if we had stayed with Python or another high-level language. I have finally followed through with JavaScript. Read on for a whirlwind tour of low-level optimizations and a few JavaScript-specific tricks.

Base Code

12330 ms

No optimization would be complete without a naive implementation to poke and prod into a perfected program. In this case, it is a simple triply-nested for loop performing the multiplication of two 1024 by 1024 matrices.

function matMul(a, b, c) {
  var n = 1024;
  for (var i = 0; i < n; i++) {
    for (var j = 0; j < n; j++) {
      for (var k = 0; k < n; k++) {
        c[i][j] += a[i][k] * b[k][j];
      }
    }
  }
}

Testing Methods

The performance testing code initializes a, b, and c once and then runs four warmup runs followed by sixteen measured runs. Note that only the first run is a true matrix multiply because c is not reset to 0. This has no effect on performance. The warmup runs were intended to limit the effect of JIT warmup on the time. Even though this was clever at the time, this discarding had no significant effect on test results. This is especially true after my switch from average time to minimum time. The minimum more accurately represents the peak performance of the code and obsoletes the warmup period.

Firefox Nightly was used for all test runs on a 4 core 2.6 GHz i7 with 16 GB 1600 MHz RAM. 1024 by 1024 matrices were used to provide a balance between fast execution and reliable results.

Using Globals

9160 ms: 1.35x

The first concern I noticed was that the performance recording showed that there were five incremental garbage collections during the run. I assumed that this was due to either function parameter passing or closures involving some amount of copying, even though arrays are passed by reference. The 3000 ms saved confirms this hypothesis.

Typed Arrays

7830 ms: 1.57x

Switching from a basic JavaScript Array to the specialized and pre-allocated Float64Array yielded a significant speedup while requiring almost no actual work. As any Haskell fanatic will tell you, the easiest way to improve a program is to embed more type information. In this case, a Float64Array improves the memory locality of the matrices.

Aggregated Typed Arrays

7315 ms: 1.69x

The previous matrix representation was an Array of Float64Arrays. I expected that this would have significant overhead. This led me to my next optimization, storing each matrix as a single Float64Array with manually computed indexing. While computing the index as i * n + j yielded no improvement, calculating the index as (i << LOG_N) | j yielded the slight speedup.

for (var i = 0; i < n; i++) {
  for (var j = 0; j < n; j++) {
    for (var k = 0; k < n; k++) {
        // Aggregated
        c[i * n + j] += a[i * n + k] * b[k * n + j];
        // Logical + Aggregated
        c[(i << LOG_N) | j] += a[(i << LOG_N) | k] * b[(j << LOG_N) | k];
    }
  }
}

Transposition

2900 ms: 4.25x

I decided to move on from high-level quibbles and get into the cache-level optimizations I had learned in the Performance Engineering lecture. The first of these is transposition. A standard matrix multiplication works by going across the rows of one matrix and down the columns of the other. Like a person raised reading English, modern CPUs are good at reading left-to-right and bad at reading top-to-bottom. This optimization transposes (rotates and flips) the second matrix so that the computer can read both input matrices left-to-right.

Note that this uses standard aggregated indices for clarity:

for (var i = 0; i < n; i++) {
  for (var j = 0; j < n; j++) {
    for (var k = 0; k < n; k++) {
      c[i * n + j] += a[i * n + k] * b[j * n + k];
    }
  }
}

Tiling

2950 ms: 4.18x

Another low-level optimization intended to improve cache usage, tiling splits the matrix into submatrices that are intended to fit entirely within the processor’s cache. Unfortunately, this optimization had no actual effect, serving as a cautionary tale for pushing low-level tricks into high-level languages.

for (var ih = 0; ih < n; ih += tileSize) {
  for (var jh = 0; jh < n; jh += tileSize) {
    for (var kh = 0; kh < n; kh += tileSize) {
      for (var il = 0; il < tileSize; il++) {
        for (var jl = 0; jl < tileSize; jl++) {
          for (var kl = 0; kl < tileSize; kl++) {
            c[((ih | il) << LOG_N) | (jh | jl)] +=
                a[((ih | il) << LOG_N) | (kh | kl)] *
                b[((jh | jl) << LOG_N) | (kh | kl)];
          }
        }
      }
    }
  }
}

SIMD

665 ms: 18.54x

The lecture next covered vectorization, the art of performing a Single Instruction on Multiple Data (SIMD). Vectorization was recently implemented in Firefox Nightly and does not yet exist in any other browsers. Always wanting to explore new possibilities, I put together a simple use of the SIMD API to vectorize the matrix multiplication, allowing it to work on two values at once.

With SIMD.Float64x2 this was sadly the slowest optimization, clocking in at a 47x decrease in performance. However, this doesn’t doom the SIMD API. Float32x4, which works on four values at once instead of two, delivered an 18x speedup. While the youthful SIMD API has some rough patches, it is still impressively powerful.

for (var i = 0; i < n; i++) {
	for (var jh = 0; jh < n; jh += 4) {
		for (var k = 0; k < n; k += 4) {
			for (var jl = 0; jl < 4; jl++) {
				var simdC = SIMD.Float32x4.load(c, (i << LOG_N) | jh);
				var simdA = SIMD.Float32x4.load(a, (i << LOG_N) | k);
				var simdB = SIMD.Float32x4.load(b, ((jh + jl) << LOG_N) | k);
				var simdMul = SIMD.Float32x4.mul(simdA, simdB);
				var simdCPlusAB = SIMD.Float32x4.add(simdC, simdMul);
				SIMD.Float32x4.store(c, (i << LOG_N) | jh, simdCPlusAB);
			}
		}
	}
}

Parallelization

215 ms: 57.35x

At this point the only remaining speedup covered in the lecture is parallelization. In C this involves wrangling threading libraries and in JavaScript this means dealing with WebWorkers and array copying. I opted for a simple hard-coded split-into-four approach in which each worker produces one quarter of the output. This exceeded my expectations, showing the extensive optimizations in the browser for passing Arrays to WebWorkers.

Wrapping Up

While a 57x speedup sounds impressive on paper, what is more important is that all of these techniques work. Using “port it to C” as the holy grail of optimization is simplistic and limiting when low-level rewrites and JavaScript implementation tricks are available.

JavaScript doesn’t have to be slow.

View the code

The First Project

Mon, 23 Jun 2014 12:00:00 +0000

Phones break. Firefox OS phones break too (for now). This breaking usually leaves behind visible trails that reveal what caused the initial break. In physical terms, if something hits your window it will leave cracks that will be different based on whether the object was a golfball or a brick. If you are lucky, you may have a security camera that happened to take pictures of the window-smashing object.

However, when software cracks it usually will automatically repair the damage. On phones, this is as simple as restarting the app or rebooting the phone, and users do it all the time. To make matters worse, the security camera that might have recorded whatever broke the phone suffers from short-term memory loss. When the phone is connected to a computer, debugging tools interface with the security camera (the logs), but phones can not be connected to a computer 24/7.

My first project this summer has been creating a way to yank the tape out of the security camera before it gets erased and throw it into the digital equivalent of two VHSs, a rats nest of cables, and a sketchy understanding of the FBI anti-piracy warning. It has been an exercise in weird device implementations, waiting for code review, and cursing NetScape.

In conclusion, timezones are evil, virtual devices are horrible, and interning is fun.

The First Week

Thu, 12 Jun 2014 12:00:00 +0000

How do I…

There is a question that exists at the heart of all programming disciplines, that divides the wheat from the chaff, that casts apart the cream from the crop, that abuses metaphors to make a point more dramatically. This universal question is no other than “How do I…?”

When learning a new language, a new library, or any new tool, “How do I” forms the basis for learning the underlying system. If I am trying to use a sewing machine, “How do I make a pair of pants?” will lead me down the path of needle-threading, seaming, pedalling, and countless other skills. Most importantly, I will learn these skills on an as-needed basis, without the need to study the machine’s book-sized manual.

In programming, this practice is so wide-spread that there are meta-“How do I” commentaries. My favorite two of these are the both dreaded and beloved yak stack and the opaque WAYRTTD.

A yak stack is where all of the sub-“How do I”’s end up. For example, if I am trying to butter toast, I first need to know how to get butter, locate a knife, and operate a toaster. WAYRTTD stands for “What Are You Really Trying To Do?”, a question evoked by the more specific “How do I”’s.

This week, my yak stack overflowed several times and WAYRRTDs occasionally prompted me to divulge my true intentions. My task was to read the operating system’s logs and save them to a file. Little did I know that this task was an iceberg of complexity. My first hint came when any file IO function called on the log file failed. Because Firefox OS uses the Netscape Portable Runtime, which for brevity I will refer to as Satan, there were two different ways of opening the file, and eight different ways of reading from the file once it was opened. Satan also made sure each of these operations were abstracted behind several layers of indirection. I spent the better part of the day trying to bargain with Satan to get one of these combinations of opening and reading to function. After I gave up on bargaining with the dark lord, it was time to start building the yak stack.

If mashing together opening and reading functions is trying out different chants your local Satanist swears will summon the demon himself, the yak stack is opening a portal to the first circle of hell to pal it up with the virtuous pagans. To put it in simpler terms: “Abandon all hope, ye who enter here.”

My deliverance came in the form of the lovely people of Mozilla. My mentor gave me the username of a knowledgeable person on IRC who was able to take my current study of the demonic arts and convert it to my first real amount of progress. After this introduction, everything was sunshine and rainbows. Any problems I could not solve I would bounce of this friendly individual and our collective wills would quickly demolish it.

To summarize, if you are trying to summon the devil, make sure you can talk to a very skilled demonologist.

Why Rust is better than C++, a case study

Sat, 15 Mar 2014 19:00:00 +0000

For the past week I have been working on transferring LLVM’s wonderful Kaleidoscope tutorial to Rust as a way to gauge the possibility of finally introducing a proper REPL into the language. I am still working on getting the JIT compiler functioning, but I thought I may as well document some thoughts about where Rust is infinitely superior to C++ and where it still needs some improvement.

Globals are evil

C++ can be a horribly difficult language to read. Just look at the following example:

static PrototypeAST *ParsePrototype() {
  if (CurTok != tok_identifier)
    return ErrorP("Expected function name in prototype");

  std::string FnName = IdentifierStr;
  getNextToken();

  if (CurTok != '(')
    return ErrorP("Expected '(' in prototype");

This is a function which returns an optionally null pointer. The variables CurTok, tok_identifier, and IdentifierStr are all from other unknown location. It’s not even clear what type CurTok and tok_identifier could be. The only reason we know the type of IdentifierStr is that it was copied into the string FnName. The potential side effects of getNextToken are unknown and the results of ErrorP are unclear.

In constrast, this same example when translated to Rust becomes:

fn parsePrototype(&mut self) -> ParseResult<~PrototypeAst> {
  let fnName: ~str = match self.currentToken {
    Identifier(ref name) => name.clone(),
    _ => return Err(~"Expected function name in prototype")
  };

  self.getNextToken();
  if self.currentToken != Char('(') {
    return Err(~"Expected '(' in prototype");
  }

Pattern matches reduce the ambiguity of CurTok and tok_identifier, allowing the possible input tokens to be clearly demarcated without requiring global mutable state. In addition, the error handling now occurs through a Result class which will force callers of this method to employ error checking. This makes it impossible for a missing if(!result) to cause a program crash.

Tracking a moving target

If everything I had to say about Rust were positive, I would be lying. An occasional downside to Rust is its current “move fast break things” attitude. At one point in development I went from a perfect clean build to around 30 warnings because of the deprecation of owned vectors. While refactoring to the new Vec struct was not horrific, it was two minutes I could have spent documenting or refactoring.

Overall, working with Rust for this project was both fun and refreshing, and I highly recommend trying out the language. Programming with Rust is kind of like programming with Haskell: the semantics are tricky and the learning curve can be steep, but becoming proficient in it teaches a way of thought that will stay with you across all languages.

If you want to check out current work on Rusty Kaleidoscope, you can find it here.