fundamental code

The DIY Mark I CPU

Sat, 20 Apr 2024 00:00:00 -0400

Every once in a while I get the urge to reminisce about a past project. So, today let’s look back on one of my favorite projects from my undergrad computer engineering degree, or as I like to call it:

The Time When I Built a Custom CPU Because Writing Software Was Easier Than Designing Hardware

One of my lab courses focused on building a sequence of group projects with ever increasing complexity. Most of them ended up being games with a focus on an FPGA development board, a serial connection, and some custom software running on a desktop computer. The individual projects that have stuck around in my mind are:

A GAL (Generic Array Logic) and discrete component based traffic light control system with a pedestrian button.
An etch a sketch application where the FPGA acted as a hardware controller and the desktop computer translated move operations and whether the cursor was depressed into a displayed image
A game of hangman where the hardware system read key events from a PS1 keyboard and then submitted full words as guesses to the computer for updating the display.
A signal capture tool using an ADC/DAC set of chips with an on desktop visualizer
A student selected project, which for my team was a two player game of pong displayed on an analog oscilloscope.

The whole sequence of projects started out with a GAL+discrete logic based assignment. We were tasked with building up a system for a standard 4 way intersection with an set of pedestrian crossings and associated pedestrian crossing request button.

We had lookup tables in the GAL, counters, timers, logic to decode our state into which lights were on, binary to 7 segment decoder chips, etc. It was a lot. As you might be able to see what we might have needed the most was some more rigor in terms of our wiring job, but we managed to complete the task. The project was a combination of loosely planning things and organically patching any mistakes we had made while watching the system through a logic squid. It was remarkable how much physical devices slowed down development.

The subsequent projects took us one step back from 80s style of physically building out logic into the era of defining our systems in a hardware description language, namely VHDL. This sped things up considerably, though the tooling available to students was subpar at the time (or at least that was the case at my university), so I wanted to make another technological leap and move into software. That required us to have a CPU of some sort and the assignments were always about turning in the hardware description of a system, so it couldn’t be imported from an external project like OpenCores. I knew from my tinkering in open source software that the later projects would be either take less time or be more fun with a basic CPU that could be reused from project to project, so I set off and made one. Certainly it was creating something bespoke with no online resources, but at the time resources for VHDL were *sparse*.

The classes focused around state machines, so how much harder could it be to build up a programmable state machine? A computer or in our case a very very terrible minimal computer was born. The CPU itself was copied between projects with near zero changes and just enough custom peripherals were created per assignment to get the system over the finish line.

System Overview

The DE1 development board we worked with has a bunch of LEDs, some switches, a few momentary buttons, some RAM, and a few electrical connections to the rest of the world in the form of a serial port, a PS2 keyboard connection, and some general purpose IO pins. There are some other bells and whistles, but they aren’t particularly relevant.

The custom Mark 1 CPU was built to handle the orchestration between these peripherals and was as simple as you could reasonably get. At the time I was often tinkering around with some of the AVR processors and I enjoyed dealing with the simplicity of an 8 bit system, so I made the Mark 1 a fully 8 bit system. 8 bits of addressable memory, 8 bits of addressable program ROM, and only four 8-bit or less registers. By the last project the instruction set had grown to 22 opcodes and it was running at a blazing fast 50MHz. It was certainly stripped down with no interrupts, no relative jumps, no pipelines, and no variable cycle instructions, but it worked well enough for the course.

Architecture

As mentioned before, the CPU was thoroughly an 8-bit system, 8-bit addressable memory, 8-bit program ROMS, 8-bit operands, and four 8-bit or less registers. Those registers were:

The Status register (SR)
The general purpose register (REG)
The indexing register (IDX)
The program counter (PC)

SR stored system flags such as the is-equal flag, the is-zero flag, and other application specific flags. REG is used to for general loading from memory, arithmetic operations, comparisons, and temporary storage. IDX is used for stack management, indirect memory access, and iteration. PC is used to track the current position in the system ROM, which determines the current instruction; In other systems this is referred to as an Instruction Pointer (IP).

Our instruction set can be summarized below:

Memonic	Arg.	PC	SR	REG	IDX	ALU	Bus	Cycles	Notes
read	Ar	.	.	W	.	i..	R	2	$REG := (Ar)
load	V	.	.	W	.	i..	.	1	$REG := V
send	Ar	.	.	R	.	i..	W	1	(Ar) := $REG
test	V	.	W	.	.	i..	.	1	\$SR ⇐ $REG==V
jsrr	.	W	.	R	.	…	.	1	\$PC := $REG
goto	Ap	W	.	.	.	…	.	1	\$PC := Ap
brnz	Ap	W	R	.	.	i..	.	1	$PC := Ap if $REG!=0
brzz	Ap	W	R	.	.	i..	.	1	$PC := Ap if $REG==0
breq	Ap	W	R	.	.	i..	.	1	$PC := Ap if $SR.equal is true
brc0	Ap	W	R	.	.	i..	.	1	$PC := Ap if control 0 is true
brc1	Ap	W	R	.	.	i..	.	1	$PC := Ap if control 1 is true
addd	V	.	.	RW	.	i.F	.	1	\$REG := $REG + V
subx	V	.	.	RW	.	i.F	.	1	\$REG := $REG - V
spsh	V	.	.	.	RW	ii.	W	1	($IDX++) := V push V to stack
rpsh	.	.	.	R	RW	ii.	W	1	(\$IDX++) := $REG push $REG to stack
spop	.	.	.	W	RW	id.	R	2	$RED := (--$IDX) pop value to $REG
lspt	V	.	.	.	W	i..	.	1	\$IDX := V load stack pointer
sidx	V	.	.	.	W	i..	.	1	\$IDX := V set index
iidx	.	.	.	.	RW	ii.	.	1	\$IDX := $IDX+1
lidx	.	.	.	W	R	i..	R	2	\$REG := ($IDX)
swap	.	.	.	RW	RW	i..	.	1	swap(\$REG,$IDX)
trap	.	W	W	W	W	…	.	1	Reset system
noop	.	.	.	.	.	i..	.	1	Do nothing

R(ead), W(rite), .(nothing), V(alue), Ar(Address/RAM), Ap(Address/Program), ALU (PC-IDX-REG) i(ncrement ALU), d(ecrement ALU), F(ull ALU)

In total these 22 opcodes were in the final VHDL version of the CPU that I was able to locate (technically 23, but lspt and sidx are identical). No opcode encoding work was done, that was left to the VHDL generation tools, but opcodes could easily be 8 bits to fit with the overall theme of the project.

One challenge of working with this instruction set was that relative jumps are not in the instruction set which means that a list of destination addresses needed to be maintained. Most code modifications were painful if it shifted code by even one address, so the Mark I CPU even has an assembler, but I’ll get to that a bit later.

Peripherals

You might notice that the CPU only interacts with registers, the 256 bytes of memory, and a few control lines with those branch instructions. So how does it work with the rest of the IO world?

Memory mapped peripherals.

Similar to embedded microcontrollers if the CPU writes to a given 'magic' address it is going to be writing or reading values in a peripheral that’s wired onto the main bus. Heck, even memory is a peripheral in our case. For most of the projects this CPU was used in we were required to use the SRAM chip on the DE1 board.

Since I’ve lost some of the code used with the Mark I based CPU projects I don’t have an exhaustive list, but I can find evidence of memory mapped peripherals for:

SRAM : General purpose memory
A debug interface : manually Stepping the CPU and visualizing the address/data lines
A timer : for accurately and regularly tending to tasks. This peripheral had to be polled since no interrupts exist in this CPU
A UART : for communicating to computers over a serial link
Beeper : for making sounds when a player has done an action in games
A vector graphics video driver with selectable VROM banks : For rendering graphics on X/Y mode oscilloscope outputs
A PS2 keyboard driver : for typing in commands
A character LCD driver : for displaying what uses have typed
A seven segment display driver : typically for visualizing debug information
User input buttons : for binary user inputs or for stepping through the code at low speeds (It’s pretty hard to visualize things by eye at 50 MHz)

If I attempt to build another CPU in the future I expect a huge portion of the time will focus on the debug interface. I personally find them delightful. For a particularly good set of examples take a look at the Magic processor’s front panel or the currently available PDP-11 replica front panels by Obsolescence Guaranteed. In fact the user interface component is a delightful space to explore for complex systems whether that’s processors, synths, control systems, or some other complex system that needs to precisely communicate information to a skilled user.

Assembler & Examples

As mentioned before, the processor does not have relative jumps which makes program modifications tedious if we don’t have an assembler. The assembler itself is pretty trivial with most of the point being tracking the addresses of assembled instructions. In fact almost all of the meaningful bits of it can be seen in these yacc/lex snippets:

asm.y The primary grammar of the assembler

program:
       program statement '\n'
       |
       ;
statement:
         express
         | label express
         | label
         | directive
         |
         ;
directive:
         EQU SYMBOL NUMBER {$2->val=$3;}
         | START {pass++;pc=0;}
         | SRC SYMBOL {if(pass>1) printf("--%s\n",$2->name);}
         ;

express:
       OPCODE          {line($1, 0x00);}
       | OPCODE SYMBOL {line($1, $2->val);}
       | OPCODE NUMBER {line($1, $2);}
       ;
label:
     SYMBOL ':'        {$1->val=pc;}
     ;

asm.lex the tokenization of the assembler

;.*         /*Ignore comments*/
[ ]+            /*Ignore whitespace*/
iidx|read|test|swap|spop yylval.string=strdup(yytext); return OPCODE;
load|send|nopp|goto|subx yylval.string=strdup(yytext); return OPCODE;
rpsh|rpop|spsh|trap          yylval.string=strdup(yytext); return OPCODE;
addd|brc[0-2]|jsrr|breq|sidx yylval.string=strdup(yytext); return OPCODE;
brnz|brzz|lidx yylval.string=strdup(yytext); return OPCODE;
#[0-9a-fA-F]+   sscanf(yytext+1,"%X",&yylval); return NUMBER;
%[0-9a-zA-Z]    yylval.number = (char) yytext[1];    return NUMBER;
[_a-zA-Z]+      yylval.sym=intern(yytext);    return SYMBOL;
^\.start        return START;
^\.equ          return EQU;
^\.src          return SRC;
:               return *yytext;
\n              return *yytext;

A program consists of a sequence of statements. Those statements are either labels for code to jump to, opcodes with optional arguments, definitions of constants, or definitions of functions which are printed as comments in the generated code. Easy enough for something as low level as an assembler, right?

So, what does a real program look like? Well, let’s look at a slightly modified assembly project. Before looking at the code this is from the project where a collection of analog values are read from an external chip, then transmitted over a serial connection to be displayed on a PC.

To start off, let’s look at some constants:

;Define constants
.equ        UART_TX     #02
.equ        LEDS        #01
.equ        ADC         #06
.equ        STACKP      #21
.equ        STACK_H     #F0
.equ        BINTOASCII  #08
.equ        ASCII_H     #09
.equ        ASCII_L     #08
.equ        TMP_SEND    #A2
;brc0 is uart ready send

In this program the CPU has a few system peripherals:

A set of on board LEDs to display running values of our input memory mapped at 0x01 (write only)
The serial link to the computer (UART) memory mapped to address 0x02 (write only)
The analog to digital chip mapped at 0x06 (read only)
A binary to ascii-hex conversion ROM mapped at 0x08 (input) and 0x08..0x09 (output)

In addition the stack that is used to store data which is sent to the PC is 0x21..0xF0, which should correspond to 103 8 bit values (in hex) and a null terminator.

In addition, there is a set of comments that indicate that the UART is connected to the CPU’s control line 0 to signal when data can be sent.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        INIT_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
init:
            sidx STACKP     ;config stack
            spsh #4D        ;'M'

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        MAIN_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
main:
            goto inputs
in_ret:     goto outputs
out_ret:    goto delay
del_ret:    goto main

The beginning of the program initializes the array/stack which is used to store data which will be transmitted and then it establishes the main program flow. inputs are collected, the input is output to the computer, the system waits, and then it repeats the process.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        INPUT_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
inputs:
            read ADC        ;Get analog value
            nopp

            send BINTOASCII ;Convert to ascii
            send LEDS
            read ASCII_H
            nopp
            rpsh            ;Push values onto stack (char*)
            nopp
            read ASCII_L
            nopp
            rpsh

            swap
            test STACK_H    ;Check for end of loop
            swap
            breq send_data
send_ret:   goto in_ret

Ignore the no-operation instructions here, but as the comments indicate data is read from the ADC peripheral. The data is converted into two bytes of hex-ascii (e.g. 0xfa), then stored on the stack. At the end we check to see if the stack pointer is at its maximal value with the test instruction and if it is at that value we go to the next stage, otherwise we keep gathering more input.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        SEND_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
send_data:
            spsh #0A        ;Add new line
            spsh #00        ;Add null terminator
            sidx STACKP     ;Set start of char*
send_loop:
            lidx            ;Read in next value
            nopp
            brzz send_exit  ;Check for null terminator
            send TMP_SEND
wait:       brc0 do_send
            ;do something useful while waiting
            read ADC
            nopp
            send LEDS
            goto wait

do_send:    read TMP_SEND
            nopp
            send UART_TX    ;Transmit data

            iidx
            goto send_loop

send_exit:
            sidx STACKP      ;reset stack
            spsh #4D         ;'M'
            goto in_ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        OUTPUT_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
outputs:    goto out_ret

Now with output we’re getting to point we have something more complex. In the first 3 instructions we establish that we have a null terminated string starting at the constant address STACKP. We now want to send this string byte by byte to the UART. This is done by the send_loop. When a character is sent we have to wait for the UART to be ready for the next byte at which point we stay in the wait loop until the control line 0 indicates we can send the next character. When we do send the data it is moved from the TMP_SEND address to the UART_TX memory mapped device and we repeat the process until the full string has been sent.

Rewritten in C this looks like:

uint8_t *stack_pos;
volatile uint8_t *led;
volatile uint8_t *adc;
volatile uint8_t *uart;

void send_data(void)
{
    uint8_t chr;
    (*stack_pos++) = '\n';
    (*stack_pos++) = '\0';
    stack_pos = STACKP;

    while(1) {
        chr = *stack_pos++;
        if(chr == 0)
            break;
        while(uart_busy())
            *led = *adc;
        *uart = chr;
    }
    stack_pos = STACKP;
    (*stack_pos++) = 'M';
}

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        DELAY_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
delay:      load #00
delay_loop: addd #FF
            nopp
            nopp
            brnz delay_loop
            goto del_ret

The delay routine is the last one it counts from 0 to 256 (more or less) and we can calculate how long this should take to execute. The processor runs at 50MHz with one instruction per cycle, one loop is 4 instructions (add+2x no-op+branch). So, 256*4+1+1 (for the initial load and final goto), so roughly 20 micro-seconds. Not much time at all.

Quirks

The processor had its fair share of quirks and general limitations. While this is by no means a comprehensive list a few that were pain points at the time:

It was a 50MHz, all actions on rising edge of clock, nothing on falling edge. The speed was higher than was needed and the lack of falling edge operations resulted in several quirks around reads and writes bleeding into a 2 cycle instruction
No secondary register, so manually allocating the single register to various tasks was fiddly
No function call/return opcodes, so subroutine calls are verbose operations where the user had to save their variables before placing a return address on the stack and then making sure the called code ends with popping a value from the stack and unconditionally jumping to the current register value
Read is a multi-tick operation and multi-tick instructions do not exist, so no op instructions were manually inserted
Occasional bugs where on some revisions jumps would occur before the program counter was incremented.
256 instructions really isn’t a lot. For basic problems sure, that’s loads and when you can write arbitrary peripherals it’s workable, but I did run out of program space more than once in the development of the final project

Looking back

It’s pretty amazing looking back at the specs for the DE1 board. Those boards are still sold, but an updated revision. The newer revision is a heck of a lot more powerful than they used to be. Reading the spec sheet of the individual FPGA on my board I’ve got 18,752 logic elements and the new FPGA simply specifies 77k logic elements which gives me the sense that students aren’t running into those situations where they’ve exhausted every single logic unit on one of these boards while doing classwork. The newer board don’t even need the effort of building a custom CPU since they’ve got a built in ARM core. Heck, the ARM core has access to a full GB of RAM, which is remarkable compared to the 8MB of SDRAM on my board and the 256 bytes of address space of the Mark I CPU.

The Mark I CPU worked, it did its job and while I haven’t accomplished my personal goal of making a CPU from raw transistors it got me a decent part of the way there. If I do go all the way to transistors I’m guessing I’ll go down to 4 bits or have the pcb fab assemble the ocean of transistors. Overall it’s a fun space and simple instruction sets are really interesting. I don’t play around with them as much as I used to, but it is a delight to read through ISRs like the z80 or AVR. There’s a beauty to them that is lost in the pragmatic full instruction sets you see in x86 and arm.

So, I’ll leave this article here for now. I may well get back to it and edit it some more or extend it, but this has been sitting in my drafts folder long enough that I should put it up on my website before it collects another layer of dust.

System Profiling with Perfetto

Sun, 12 Mar 2023 00:00:00 -0500

Programs aren’t perfect and that doesn’t mean just bugs. Quite often a program will accomplish it’s goal, but not as quickly as both developers and users would like. Solving performance problems can be complicated, but it often starts at identifying why a program is slow via profiling. Profiling informs what a codebase is doing, how the work is being done, in what order code is being executed, and quite often highlights the hotspots where a few lines of code account for most of the time. Programmers have a wide variety of tools for profiling nowadays, though like most tools they do have trade-offs which create specializations. The tools can vary considerably due to the execution environment, target programming languages, and assumed root causes of a program being slow. Note, I do have to say assumed root cause because until you can quantify the behavior of a program you only have educated guesses.

Types of Profilers

Profilers will quantify the question of "How long does it take to do X?", but the profilers don’t need to be complex. For instance I could sit down, look at a program and say "I think function X() is taking longer than expected". System timers could quantify how long a program takes to run with time (e.g. a unit test for X()) or code can be modified to collect the runtime of X()

void
some_function(void)
{
    struct timespec start, end;
    //Record the time before entering X()
    clock_gettime(CLOCK_MONOTONIC, &start);

    X();

    //Record the time after exiting X()
    clock_gettime(CLOCK_MONOTONIC, &end);

    printf("X took %f ms\n", get_timediff_ms(end, start));
}

At the end of the day how it takes to run a critical section of code is what matters, though getting only a single time for a program is a very coarse metric. It’s possible that we can see what our target function X() calls and then annotate Y(), Z(), etc, though that is slow work and can produce hard to understand output. We don’t need to add these timers ourselves though as automated tooling exists.

Sampling profilers like perf, gprof, or the-poor-man’s-profiler automate our work by periodically capturing a stacktrace of a program without manual annotations. Quite often sampling profilers focus on slower events (e.g. being IO bound) and sequences of operations. A major weakness from my experiences with sampling profilers is the tooling to visualize the output of the collected traces is lackluster. My opinions are very much colored by the types of application optimization hurdles that I’ve needed to fix in the past, so take my opinion with a grain of salt.

My favored type of profiler is the instrumenting profiler which involves modifications to the program to generate information about the execution flow. Out of all of the instrumenting profilers, valgrind is my go-to tool. Valgrind automates the instrumentation needed to perform profiling, to track memory allocations, and to detect several classes of memory faults common in C and C++ programs. Valgrind executes every instruction in a VM and thus can see the exact pathway the program uses, but at a fairly high cost. A program executing 20x slower under valgrind isn’t unexpected, but that’s the price paid for convenient access to a program’s behavior. If you are working with compute bound single threaded tasks I can’t recommend kcachegrind’s visualization of valgrind’s output enough.

System Profilers

So, why do we need anything more than the profilers already mentioned? Well, a lot of the tools don’t do a great job at representing performance issues that occur across multiple threads, multiple programs, or are centered around inconsistencies in resources external to an application (IO/drivers/etc). A fair number of these problems are difficult to manage in the best of times and they’re becoming more common as system complexity increases with more powerful hardware. Sampling profilers can be used in some of these situations to generate traces, though as I mentioned before the data visualization associated with the sampling profilers is non-ideal to non-existent. Although I love valgrind, the output of the profiling is more focused on a statistical overview rather than a sequential trace of what’s happened. So, let’s take a look at another instrumenting profiler, Perfetto.

Perfetto is in the domain of system level profilers, which I haven’t had many chances to work with. In fact, I’ve tended to avoid those options since they’re quite frequently built around server system profiling which can be both quite complex to setup and focus around understanding even more complex systems that you might just want to avoid. Recently though I had to bite the bullet as the new complexity was justifiable.

Perfetto is an instrumenting profiler, but in this case the instrumentation isn’t inserted automatically. Manual instrumentation isn’t ideal, but it does mean that effort can be spent on only recording relevant events in traces. After instrumentation has been added to the source of an application, the program can be run, and events can be used to create a trace via a logging daemon. With a daemon monitoring events, multiple applications can be logged simultaneously, information about system state can be logged to the daemon, and Perfetto showcases these features.

Being able to log out complex profiling traces is next to useless without good data visualization, but Perfetto provides the needed tooling. The logged data can be visualized in a multi-threaded, multi-application, flame graph style view with additional events flagged as needed, and metrics plotted over time. If that doesn’t sound like enough, the logged information can be queried via a SQL style interface, which comes in handy for when you want to programmatically aggregate results. I do certainly miss the full trace summaries present in kcachegrind, so it isn’t perfect, but it does a solid job at answering: "What happened at 50 seconds into this program run?".

How does Perfetto help you visualize program traces?

So, what does Perfetto look like in practice? The main view is a collection of flamegraphs in separate tracks. Each track is likely to be a different thread of execution or a separate process. Each event in the flamegraph typically represents one function call, though since they’re user defined it’s much more coarse than watching the true callstack.

The UI lets you see the total elapsed period of time recorded in a trace and lets you smoothly zoom into smaller and smaller segments of time. Vertically all of the tracks are stacked on each other highlighting the individual applications recorded, individual threads within the applications, and get detail information on any of the individual segments.

It’s even possible to query the recorded events using SQL.

Why would you want to query the profiling traces with SQL? Well, queries can be used to aggregate performance with modest difficulty as opposed to the task being a monumental exercise in reverse engineering of the formats used to store the serialized traces.

Speed

You never want to encounter a Heisenbug, or in other words a bug which disappears when it’s observed. We all have had them: the hardware glitch that can’t replicate when you show it to someone, a web browser that works only in developer mode… It’s enough to build superstitions. The same problem can and does arise in profiling because at the end of the day by observing the program you’re altering the speed it’s being run at. Even slight changes in the speed can make some bottlenecks disappear, new ones appear, and when your tools are unreliable you can waste time fixing problems that were never really there in the first place. That’s not even considering how changing the speed of a program can impact various data races and other quirks of threading behavior.

So, ideally when profiling the speed of the underlying program should be as close as is possible to normal operations. Valgrind clearly violates that principle with 20x slowdowns, but that is why those profiles tend to be useful primarily for compute bound profiling tasks. Perfetto addresses this concern by making trace events lightweight and cheap to record. From Perfetto documentation we can see that every logged event is very cheap:

Scenario

Runtime on Pixel 3 XL

Runtime on ThinkStation P920

TRACE_EVENT(…) (disabled)

2 ns

1 ns

TRACE_EVENT("cat", "name")

285 ns

630 ns

TRACE_EVENT("cat", "name", <lambda>)

304 ns

663 ns

TRACE_EVENT("cat", "name", "key", value)

354 ns

664 ns

DataSource::Trace(<lambda>) (disabled)

2 ns

1 ns

DataSource::Trace(<lambda>)

133 ns

58 ns

How is Perfetto integrated?

The biggest drawback of Perfetto is that events need to be manually added to the application(s) being profiled. Events are added through one of several macros or functions with a few of them being documented in the table listing event tracing costs. The primary macro is TRACE_EVENT(), which creates a scope bound event with a category, a name, and optionally a set of keys/values pairs. Thanks to C++'s RAII, trace event create a starting event along with an ending event which is passed into the generated profiling trace. Typically you’ll see code along the lines of:

void
func_name(int arg1) {
    TRACE_EVENT("some_category", "func_name", "arg1", arg1);
    //Do the normal work of the function
}

While the TRACE_EVENT() macro is the most common method for sending events, there’s also more advanced methods which enable flags, counters, flows, and as was shown in the previous table even faster data logging. Counters for instance provide a way of storing a quantitative measure over time such as worker’s assigned to a task, the current framerate, system fan speed, etc. With a time series plot in the data visualization it’s all the easier to hone into the specific parts of the trace that you care to analyze. Some of the functionality of Perfetto is still in flux, but as it stands it’s quite a powerful tool to add to a diagnostic toolbox.

In Summary

Overall Perfetto is a pretty neat profiling suite. It’s not the first hammer in my toolbox that I’d bring out to optimize or otherwise understand a codebase, but when you need a way of understanding a multi-thread or multi-process system it’s the sledge that will get the job done. So, next time you have an eldritch horror of a computer system to tame, consider checking Perfetto out. Better yet, to explore the data visualization load up one of the pre-recorded example traces available in the online user interface.

SVN-Externs Considered Harmful

Tue, 20 Dec 2022 00:00:00 -0500

SVN externs are terrible and you shouldn’t use them. Also don’t use SVN if you’re able to avoid it, but that’s likely already done in modern organizations.

What is SVN?

Before digging into the meat of why svn externs are terrible, let’s start off with what SVN (Subversion) is; SVN is a system used to store source code and assets for software projects. The main repository is stored on a remote server and is represented as a collection of files and folders. You as a SVN user can check out any subfolder or file within a repository. In the case of an organization wanting multiple concurrent projects they’re stored in separate folders.

For one repository there is only a single history stored on the server that marches forward linearly with the revision id tracker which consists of a number counting up from the first commit. So you will see r1 (revision 1) all the way up to whatever stage the current history is in e.g. r14234. What about tagging a copy of source code or branching it to do separate development which later on gets merged? Well, SVN 'supports' those features, but at the same time it doesn’t really… A tag or a branch is just copying the files in a project to another named folder. There are conventions about the names and locations of those new folders, but it’s IMO a fairly weak feature.

What are SVN externs?

Let’s say that you have in your SVN repository two projects:

/ project1 / trunk
           / branches
/ project2 / trunk
           / branches

Perhaps project 2 uses project 1, or in other words it depends on that project’s code and resources. Dependency management is tricky and there’s a number of approaches, one of which is to copy code from project 1 into project 2, so when you build project 2, you end up building both projects together. However if you copy code from project 1, that means the copy can get out of date. So, instead you can reference the code from project 1 instead of copying it. That’s a good thing, right?

Well…… no, not from my point of view, at least without additional semantics. Just inserting a reference isn’t a great thing because when you’re working on project 2 you shouldn’t be impacted negatively by changes in project 1 and thus you don’t want breaking changes to interrupt your development unless you’re agreeing to trying out those breaking changes. SVN externs will take a copy of whatever you point them at, which can be used responsibly.

Consider the previous example again:

/ project1 / trunk    /              src / library.h
           / branches / branch1    / src / library.h
           / tags     / release_v1 / src / library.h
                        release_v2 / src / library.h
/ project2 / trunk / dependencies / $external_resource
           / branches

Here $external resource can point to a known working copy of project one which isn’t expected to change e.g. /project1/tags/release_v2 . If that’s the target, then when release_v3 is changed, then someone in project2 can update the library they’ve chosen to use to /project1/tags/release_v3. But, here’s where svn-externs get to be evil: $external_resource can be /project1/trunk/, /project1/branches/branch1, an individual file like /project1/trunk/src/library.h, or even a reference to a different SVN repository that you don’t control at all e.g. https://example.com/totally/not/your/repository/library.h.

If it’s any of those locations, the developers on project 1 can make changes which without any release process are immediately reflected in project 2. Why is that bad? Well, developers in project 1 aren’t informed about who is using their code as such by SVN. Who knows if a single file that you made is essentially getting copied all over the place. Who knows if your self consistent build process is going to be scrambled by being only partially copied elsewhere? Since svn externs make it equally easy to grab parts of libraries and live/tagged versions it encourages other projects to use internals (they don’t need the whole library) and use development copies (who wants to update versions later on), which end poorly for people trying to work on the project getting sliced up. Those developers are left guessing who is using their code and how they’re using it since unless you write additional tooling it’s near impossible to know how many externs there are within a given repo.

If you think that’s bad, let me remark that recursive SVN externs are a thing and I’m thankful that it looks like they’re rarely used. At least that’s based on both git-svn and git-svn-ext struggling with those cases. Heck at least last time I tried to use it git-svn barely supported SVN externs.

Along the same lines of tooling breaking on externs, even good old commandline svn starts to get ugly with externs. SVN status, similar to other scm status tools, will output one line per file that’s modified.

So you might see:

D  oldcode.rb
A  newcode.py
M  workingcode.sh

That status would indicate that you deleted a ruby file, added a python file, and modified a shell script. The repository can contain many more files, but if they’re unmodified then you don’t get any status information on them because obviously you only care about what’s changed. Well, welcome to the world of SVN externs. Every Single Time you run svn status with a repository that has an extern it will end up having a X status on the file/folder that’s an extern reference. It doesn’t matter if it’s modified or not.

So you might see for a repository that you haven’t made any modifications:

X internal/project1
X vendor/libA
X vendor/libB
X vendor/libC

Performing status on external item at 'internal/project1':
   X internal/project1/recursive-extern

Performing status on external item at 'internal/project1/recursive-extern':

Performing status on external item at 'vendor/libA':

Performing status on external item at 'vendor/libB':

Performing status on external item at 'vendor/libC':

It’s maddening…

Not to mention that working with svn externs isn’t via some 'svn extern' command, it’s via 'svn propget', 'svn propset', etc. It’s a thoroughly unpleasant experience through and through.

In conclusion, next time you hear someone complain about git submodules, feel free to say "hey, at least it isn’t svn externs".

Building a plant table: (3/3) putting it together

Sun, 05 Jun 2022 00:00:00 -0400

Well, this draft has been sitting unpublished for a while, but it’s time for the third part of my ad-hoc build series.

With the two pre-requisite jigs out of the way (1 2) here’s the main project. Essentially with winter arriving I had some typically outdoor plants which needed to be moved back inside to avoid the frost. My current home has reasonably high windows and narrow windowsills, so some sort of table was needed for my plants to get a reasonable amount of sunlight.

I started out with a simple stool that I had built with pine reclaimed from an old door. If you’ve got a landlord who takes a door off the hinges and tells you to get rid of it, what else are you going to do, eh?

So, while my stool does not look all that nice, it did give an initial sense of scale and provided a baseline for what felt right. Starting out, it was too short, stout, and generally too blocky. So at a high level whatever I prototyped would end up being a slimmed down tall stool. To make the profile leaner, the top would end up being circular, the legs thinner, and only three legs would get used. Placing the legs at an angle would help with the outline of the design, though it would complicate the joinery somewhat. Having linkages from legs to all of their neighbors would be possible, but it would be more complex to do as well as not being all that visually interesting. So to stabilize the table all three would be joined to the top and joined together at some point lower down in the frame

Figure 1. Old stool for comparison

With the general plan in mind it was a matter of estimating what sizes felt right and rectifying that with what stock was available. While I had plants which certainly could use a better perch, using up old material and `scrap' was a primary project goal. Starting out with the table top it was a matter of placing a plant down on a sheet of cardboard, roughly tracing the desired outline relative to one of the objects it was going to hold. From there without any measurement a set of dividers could be used as a compass to get an accurate circle which could be cut out.

Figure 2. Cardboard tracing

The height of the table was initially measured by done by walking over to a window, eyeballing where it feels like the plants should be and then just placing a hand on my side at that height. While a smarter person would have simply measured the distance directly the destination of the tables wasn’t in the same room as the tools themselves. So, some measurement error may have accumulated, but that just adds to the character of the process.

As per the leg and top thickness, that was purely a constraint of what was easily on hand without milling fresh boards, creating additional scrap. Initially the plan was to make only one table, but hey who makes a project without some scope creep. The first part built out was the table tops. Each top is built out of a collection of scrap pieces which admittedly didn’t fit together all that well. As such, it was a concern that some of the tops would well, come out horribly? So far though, the low precision of a bandsaw & handtool combination has held together well with standard wood glue.

I ended up making three tops with one on the thin side and two chunkier tops. As they all turned out reasonably, so three tables it was. When it came to the legs there was a similar split of enough stock for three thin legs and six slightly thicker ones. The thin stock was slightly shorter as well, so to have a set of unique tables each one started out at a different height.

Figure 3. Mortise Template

The build progressed fairly quickly from there. The above template was used to locate the top mortises, then the lowers were added about 2/3rds of the way down. The linkages of the lowers were more cherry stock available at the same rough dimensions as the legs themselves. Once everything was together and with some light calculation the lowers were cut to length and used to align a base joining plate.

The joining plate was a disk cut out on the circle jig (link), and the lowers were manually marked on it for where they’d fit into three recesses. Not as accurate as layout out the locations ahead of time, but there was much less math involved by seeing where parts naturally aligned.

The final results were pleasing in my opinion

Figure 4. Final tables

Figure 5. Table tops

Figure 6. With a houseplant

Now it’s not to say there weren’t any flaws. A good set of photos could hide them, but I’ll mention them anyways. You can’t advance your craft without acknowledging where you can improve.

The bridle joints for the lower supports have some gaps due to the stock being out of square. It’s tricky for me to resolve this issue with my current tools, but becoming more proficient at jointing stock with hand planes should reduce this problem.
Lower joints were connected asymmetrically. Doing all of the math for the lower lengths, and how they were slotted into the joining plate would have resolved this issue.
Gaps were present where the legs connected to the top. I’m not sure of the complete fix here, though I suspect that the angles were slightly off between the upper tendon wall and the base of the tendon. Either that or the tendon bases were just trimmed with my chisel too sloppily. Some better marking, chiseling, and additional glue might resolve this particular issue.
Gaps within the table tops were initially visible. I’m not sure how to fix this one with my current set of tools, so perhaps additional tooling like a sander with a right angle bed might help square up endgrain without creating tear out you’d expect from planes or routers.

I might eventually return to this project to make a set of plans, but for the time being I’ll leave a set of freecad sketches to anyone interested: FreeCAD model.

Building a plant table: (2/3) quick angled bridle joints

Sun, 07 Feb 2021 00:00:00 -0500

Like the previous post, we’re working towards the construction of a plant table. The design I was building attempted to look slim and modern. One aspect of that was thin angled legs. Thin legs aren’t all that stable, on their own, so ideally there is a connection to the table top and then a second connection lower down. Attaching to the top and attaching further down the legs means angled jointery. The intent was to have a linkage come off the legs about 2/3rds of the way down and each linkage would connect to a base. Initially I was planning on a simple angled mortise & tendon joint, however the legs were thin enough that it seemed like a location which could easily crack down the line. Stylistically I could see either a proud tendon in the style of greene and greene or a stopped tendon looking nice, but no need to overcomplicate things.

I ended up going with a T bridle joint. As for the angle of the legs, they were all splayed out by an extra 10 degrees. With a 10 degree splay, it looks like:

Figure 1. Angled T-bridle joint

So, with that goal in mind, what’s a good way to create the joint? The leg has exposed jointery which is easy to mark so that piece is an everyday normal bit of woodworking. The angle within the horizontal linkages though is less trivial to do by hand. In order to ensure the internal face of the linkage mated well with the leg power tools.

Typically I end up using my mortise machine for cutting holes like that. In this case it was just a matter of using the machine at an angle. The built in fence and clamping wasn’t designed for it, however with a simple wedge and some support blocks we could get going.

Figure 2. Mortise Wideshot

Once we have a piece that we want to turn into a linkage, we can place it on the wedge, use the support blocks to relieve pressure, and attach a single clamp to hold it laterally. By using the mortising machine like this the inside angled edge can be cut cleanly.

After carving the initial hole it’s possible to use the rest of the waste with a bandsaw. As previously mentioned the jointery on the leg can be easily accessed, but it is somewhat unwieldy for my power tools, though a table saw could make quick work of the joint. In my case, some hand saws, a bit of chiseling, and a router plane made fast work. So, what does the result look like? Something like:

The last picture shows the three legs with the lowers linkages roughly lined up. A cap will connect the lowers, but I’ll leave that detail for the final post in this series.

As per how well does it work, it does a decent job. Since a through mortise is being created there is some occasional blowout. The tearing could be minimized by using a wider sacrificial wedge, but I’ll leave that until next time. While mortise machines aren’t a common shop tool I figured I’d throw this tool tip out there for others or at worst, myself next time I approach a similar task.

Building a plant table: (1/3) starting with a circle jig

Sun, 31 Jan 2021 00:00:00 -0500

For a change of pace I’m going to talk about a crafting project rather than something related to music or programming. To kick of hopefully some new retrospectives of projects, let’s begin with a three part journey into the construction of a simple custom `plant table'. This table was built a month or two back and it’s the first nice furniture project I’ve completed without plans or other inspiration that I’m satisfied with. For an idea starting out as a way to use leftovers from a previous project everything went fairly smoothly. We’ll get to the final project in the third part, but let’s start off with some jigs built along the way.

My design called for a circular top, so being able to reliably cut circles of a desired size was how I started off. With a bit of searching I could have likely found something nearly identical to the circle jig that I designed and built, but like other steps along the way I wanted to use what was on hand and what was easiest to setup giving the tooling of my own woodshop.

The basic principle behind any bandsaw circle jig is to allow for the workpiece to be pivoted around a point and for that point to be positioned to be perpendicular to the leading edge of the blade. Different jigs accomplish this structure in their own ways, but the basic principle holds true.

Figure 1. Bandsaw Jig Concept, only a few pieces are involved to use a bandsaw to consistently and quickly cut a circle

The pivot could be constructed by gluing or clamping to a rotating base or through other fixtures, but other plans I’ve seen stick to the simpler option of a partially exposed nail. The nail sticks out just enough to dig into the bottom of the workpiece and let it spin without falling off. It does leave a small mark on the base, but house guests typically don’t inspect the bottoms of tables. Another design choice is how the woodworker can use the jib to start the cut. As the miter slot is already there, I used that to both support the jig as well as to guide the workpiece when getting started. Lastly, since most of the full table project’s design was done in an ad-hoc fashion, the jig was also made to be adjustable (within reason).

Lastly, the jig was made to I used a simple mdf construction which tapered into a point to allow for easy alignment of the jig along the miter slot. Since most of the full table project’s design was done in an ad-hoc fashion, the jig was also made to be adjustable (within reason).

Figure 2. My frequently used bandsaw

Figure 3. The jig installed ready to cut

As can be seen in Fig. 3, the jig is mostly made out of some MDF. The material was extra from I had from making a previous router template ( the same project which yielded some extra cherry which is used extensively in this 3 part series). The jig has a fixed base which can travel along the miter gauge, a slide which has the nail pivot, and an optional clamp which can be used as both a handle and as way to secure the slide in place. The base of the jig has a pointed tip to help align the pivot point such that the blade will be cutting along the circle’s tangent. The alignment can be seen below, and the tip is easy enough to see even when a workpiece is being cut on top of the jig.

Figure 4. Blade alignment

Utility: So, does it work?

The jig was not a perfect solution, but given the minimum radius of the blade that I normally have on the bandsaw it works great. I typically stick with a 1/2" resawing blade as milling lumber to size is one of the major jobs of my bandsaw. The blade size limits me to 2 1/2" radius circles, so the jig doesn’t need to work with much smaller ones for now. Smaller crafts could be done with another blade, but well, I haven’t even gotten around to the classical bandsaw box projects nor the bandsaw animals seen on some woodworking group pages.

Figure 5. Result of jig

When cutting I keep the blade guard much closer to the material. The guard is higher in pictures as to not obstruct the workpiece.

As you can see, it certainly produces circles. The surface finish isn’t perfect, but that’s more of a function of the blade that I’ve chosen to use than the jig itself. Either way the large circles are easy enough to sand.

While I kept the initial table tops relatively simple the jig would also make it possible to cut a bevel on the underside of the circular tops. One pass would be needed to turn the rectangular stock into a cylinder. A second pass could then be done after tilting the bandsaw table and then repeating the process. Of course one could argue that it would be simpler to use a router for such a feature, but it depends on the amount of material getting removed.

Is this something you’d want?

Heh, my guess is likely not, but sometimes projects feel like a metaphorical ``If a tree falls in a forest and no one is around, does it make a sound?'' situation. Documenting what was done and why it was done is a key part of working on projects even if no one goes to replicate it down the road. It adds perspective, provides a chance to reflect on what was done, and helps to streamline the next project along the way. So, the general design likely works and the measurements should serve as a way of getting an idea of the scale of things.

For your own, make sure the material fits your miter slot in both the size of the slot as well as the distance from the bandsaw blade. The slot width/depth should be standardized, but that sort of assumption has bitten me before.

Figure 6. Rough plans

Full FreeCAD files are available, though keep in mind this project has acted as my first hands on less in FreeCAD and more generally CAD in general. I mostly stick to non-computerized methods, but those methods are not great for building long term documentation.

MRuby-Zest: a Scriptable Audio GUI Framework

Sat, 16 Jun 2018 00:00:00 -0400

Screenshot of framework in action

Abstract/Intro from paper

Audio tools face a set of uncommon user interface design and implementation challenges. These constraints make high quality interfaces within the open source realm particular difficult to execute on volunteer time. The challenges include producing a unique identity for the application, providing easy to use controls for the parameters of the application, and providing interesting ways to visualize the data within the application. Additionally, existing toolkits produce technical issues when embedding within plugin hosts. MRuby-Zest is a new toolkit that was build while the ZynAddSubFX user interface was rewritten. This toolkit possesses unique characteristics within open source toolkits which target the problems specific to audio applications.

MRuby-Zest was created to address long standing issues in the ZynAddSubFX user interface. The MRuby-Zest framework was built with 5 characteristics in mind. MRuby-Zest should be:

Scriptable: Implementation uses a first class higher level language
Dynamically Resizable: Fluid layouts which do not have any fixed sizes
Hot Reloadable: Reloads a modified implementation without restarting
Embeddable: Can be placed within another UI without conflicts
Maintainable: Relatively simple to read and write GUI code

To do this MRuby-Zest takes Qt’s QML language, replaced the scripting language with Ruby, integrated it with the nanovg OpenGL rendering library, and began to leverage parameter metadata that ZynAddSubFX produces via the rtosc library. Building the toolkit within Ruby instead of on-top of a pre-existing C/C++ toolkit has made MRuby-Zest particularly flexible when it comes to expanding it’s feature-set.

More information

video of LAC-2018 presentation, LAC 2018 paper, source code, slides

Total Variation Denoising

Sat, 02 Sep 2017 00:00:00 -0400

Working with data is an important part of my day-to-day work. No matter if it’s speech, music, images, brain waves, or some other stream of data there’s plenty of it and there’s always some quality issue associated with working with the data. In this post I’m interested in providing an introduction to one technique which can be utilized to reduce the amount of noise present in some of these classes of signals.

Noise might seem abstract at first, but it’s relatively simple to quantify it. If the original signal, $x$, is known, then the noise, $n$, is any deviation in the observation, $y$, from the original signal.

$$y = x + n$$

Typically the deviation is measured via the squared error across all elements in a given signal:

$$\text{error} = ||x-y||^2_2 = \sum_i (x_i-y_i)^2$$

When only the noisy signal, $y$, is observed it is difficult to separate the noise from the signal. There is a wealth of literature on separating noise and many algorithms focus on identifying underlying repeating structures. The algorithm that this post focuses on is one which reduces the total variation over a given signal. One example of a signal with little variation is a step function:

A step function only has one point where a sample of the signal varies from the previous sample. The Total Variation denoising technique focuses on minimizing the number of points where the signal varies and the amount the signal varies at each point. Restricting signal variation works as an effective denoiser as many types of noise (e.g. white noise) contain much more variation than the underlying signal. At a high level Total Variation (TV) denoising works by minimizing the cost of the output $y$ given input signal $x$ as described below:

$$\text{cost} = \text{error}(x, y) + \text{weight}*\text{sparseness}(\text{transform}(y))$$

Mathematically the full cost of TV denoising is:

$$ \begin{aligned} \text{cost} &= \text{error} + \text{TV-cost} \\ \text{cost} &= ||x-y||_2^2 + \lambda ||y||_{TV} \\ ||y||_{TV} &= \sum |y_i-y_{i-1}| \end{aligned}$$

To see how the above optimization can recover a noisy signal, lets look at a noisy version of the step function:

After using the TV norm to denoise only a few points of variation are left:

The process of getting the final TV denoised output involves many iterations of updating where variations occur. Over the course of iterations opposing variations cancel out and smaller variations are driven to $\Delta y = 0$. As the number of non-zero points increase a sparse solution is produced and noise is eliminated. For higher values of the TV weight, $\lambda$, the solution will be more sparse. For the noisy step function, $y$ and $\Delta y$ over several iterations look like:

For piecewise constant signals, the TV norm alone works quite well, however there are problems which arise with the output when the original signal is not a series of flat steps. To illustrate this consider a piecewise linear signal. When TV denoising is applied a stair stepping effect is created as shown below:

One of the extensions to TV based denoising is to add 'group sparsity' to the cost of variation. Standard TV denoising results in a sparse set of points where there is non-zero variation, resulting in a few piecewise constant regions. With the TV norm, the cost of varying at point $\Delta y_i$ within the signal does not depend upon which other, $\Delta y_j,\Delta y_k,\text{etc}$, points vary. Group Sparse Total Variation, GSTV, on the other hand reduces the cost for smaller variation in nearby points. GSTV therefore generally produces smoother results with more gentle curves for higher order group sparsity values as variation occurs over several nearby points rather than a singular one. Applying GSTV to the previous example results in a much smoother representation which more accurately models the underlying data.

Now that some artificial examples have been investigated, lets take a brief look at some real world data. One example of data which is expected to have relatively few points of abrupt change is the price of goods. In this case we’re looking at the price of corn in the United States 2000 to 2017 in USD per bushel as retrieved from http://www.farmdoc.illinois.edu/manage/uspricehistory/USPrice.asp . With real data it’s harder to define noise (or what part of the signal is unwanted); However, by using higher levels of denoising the overall trends can be observed within the time-series data:

If this short into was interesting I’d recommend trying out TV/GSTV techniques on your own problems. For more in depth information there’s a good few papers out there on the topic with the original GSTV work being:

I. W. Selesnick and P.-Y. Chen, 'Total Variation Denoising with Overlapping Group Sparsity', IEEE Int. Conf. Acoust., Speech, Signal Processing (ICASSP). May, 2013.
http://eeweb.poly.edu/iselesni/gstv/ - contains above paper as well as a MATLAB implementation

And if you’re using Julia, feel free to grab my re-implementation of Total Variation and Group Sparse Total Variation at https://github.com/fundamental/TotalVariation.jl

Linux & Multi-Screen Touch Screen Setups

Tue, 04 Jul 2017 00:00:00 -0400

While working on the Zyn-Fusion UI I ended up getting a touch screen to help with the testing process. After getting the screen, buying several incorrect HDMI cables, and setting up the screen I found out that the touch events weren’t working as expected. In fact they were often showing up on the wrong screen. If I disabled my primary monitor and only used the touch screen, then events were spot on, so this was only a multi-monitor setup issue.

So, what caused the problem and how can it be fixed?

Well, by default the mouse/touch events which were emitted by the new screen were scaled to the total available area treating multiple screens as a single larger screen. Fortunately X11 provides one solution through xinput. Just running the xinput tool lists out a collection of devices which provide mouse and keyboard events to X11.

mark@cvar:~$ xinput
| Virtual core pointer                          id=2    [master pointer  (3)]
|   > Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
|   > PixArt USB Optical Mouse                  id=8    [slave  pointer  (2)]
|   > ILITEK Multi-Touch-V3004                  id=11   [slave  pointer  (2)]
| Virtual core keyboard                         id=3    [master keyboard (2)]
    > Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    > Power Button                              id=6    [slave  keyboard (3)]
    > Power Button                              id=7    [slave  keyboard (3)]
    > AT Translated Set 2 keyboard              id=9    [slave  keyboard (3)]
    > Speakup                                   id=10   [slave  keyboard (3)]

In this case the monitor is device 11 which has it’s own set of properties.

mark@cvar:~$ xinput list-props 11
Device 'ILITEK Multi-Touch-V3004':
        Device Enabled (152):   1
        Coordinate Transformation Matrix (154): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        Device Accel Profile (282):     0
        Device Accel Constant Deceleration (283):       1.000000
        Device Accel Adaptive Deceleration (284):       1.000000
        Device Accel Velocity Scaling (285):    10.000000
        Device Product ID (272):        8746, 136
        Device Node (273):      "/dev/input/event13"
        Evdev Axis Inversion (286):     0, 0
        Evdev Axis Calibration (287):   <no items>
        Evdev Axes Swap (288):  0
        Axis Labels (289):      "Abs MT Position X" (689), "Abs MT Position Y" (690), "None" (0), "None" (0)
        Button Labels (290):    "Button Unknown" (275), "Button Unknown" (275), "Button Unknown" (275), "Button Wheel Up" (158), "Button Wheel Down" (159)
        Evdev Scrolling Distance (291): 0, 0, 0
        Evdev Middle Button Emulation (292):    0
        Evdev Middle Button Timeout (293):      50
        Evdev Third Button Emulation (294):     0
        Evdev Third Button Emulation Timeout (295):     1000
        Evdev Third Button Emulation Button (296):      3
        Evdev Third Button Emulation Threshold (297):   20
        Evdev Wheel Emulation (298):    0
        Evdev Wheel Emulation Axes (299):       0, 0, 4, 5
        Evdev Wheel Emulation Inertia (300):    10
        Evdev Wheel Emulation Timeout (301):    200
        Evdev Wheel Emulation Button (302):     4
        Evdev Drag Lock Buttons (303):  0

Notably xinput provides a property to describe a coordinate transformation which can be used to remap the x and y values of the cursor events. The transformation matrix here is a 3x3 matrix used to transform 2D coordinates and is a fairly common sight in computer graphics. It translates from $(x,y)$ to $(x',y')$ as defined by:

$$ \begin{bmatrix} x' \\ y' \\ 1 \end{bmatrix} = \begin{bmatrix} a & b & c\\ d & e & f\\ h & i & j \end{bmatrix} \times \begin{bmatrix} x \\ y \\ 1 \end{bmatrix} $$

The transformation matrix allows for stretching, shearing, translation, flipping, scaling, etc. For the sorts of problems you may see introduced by a multi-monitor setup I would only expect people to care about translating ($t$) the events and then re-scaling ($s$) them to the offset area. Using these two parameters, the transformation matrix equation is simplified to:

$$ \begin{bmatrix} x' \\ y' \\ 1 \end{bmatrix} = \begin{bmatrix} s_x & 0 & t_x\\ 0 & s_y & s_y\\ 0 & 0 & 1 \end{bmatrix} \times \begin{bmatrix} x \\ y \\ 1 \end{bmatrix} $$

Or without the matrix representation:

$$ \begin{aligned} x' &= s_x x + t_x\\ y' &= s_y y + t_y \end{aligned} $$

With that background out of the way, let’s see how this applied to my specific monitor setup:

As I mentioned earlier the touch events were scaled to the dimensions of the larger virtual screen. Since the touch screen is larger this means the y axis is mapped correctly and the x axis is mapped for pixels 0..3200 (both screens) instead of pixels 1281..3200 (left screen only). Since the xinput scales theses parameters based upon the total screen size, we can divide by the total x size (3200) to learn that the x axis maps to 0..1 rather than 0.4..1.0. Solving the above equations we can remap the touch events using $s_x=0.6$ and $t_x=0.4$. This results in the transformation matrix:

$$ \begin{bmatrix} 0.6 & 0 & 0.4\\ 0 & 1 & 0\\ 0 & 0 & 1 \end{bmatrix} $$

The last step is to provide the new transformation matrix to xinput:

xinput set-prop 11 'Coordinate Transformation Matrix' 0.6 0 0.4 0 1 0 0 0 1

Now cursor events map onto the correct screen accurately and the code to change the xinput properties can be easily put into a shell script.

Profiling MRuby Code

Tue, 14 Feb 2017 00:00:00 -0500

I loathe inefficient, slow, or bloated software. Unfortunately, I’ve written plenty of code that’s terrible in this sense and if you program frequently, then I’d wager you have written quite a few inefficient lines of code as well. Fortunately code isn’t written in stone after the first pass and we as programmers can optimize it. Most of the time the speed of a single line of code doesn’t matter or contribute to the overall inefficiency in an application. Sometimes, though, a change to a few lines can make all the difference.

Profilers

Finding those lines of code however is a challenging task unless you have access to some means of profiling the program and finding out which sections of code are run the most frequently and the lines which use up the most time. Each programming language tends to have it’s own tools, though if you’re tackling a mixed ruby/C codebase then you might be familiar with: RubyProf, callgrind, gprof, or the poor man’s profiler.

Based upon the title of this article I’m guessing that you may be interested in profiling the embeddable ruby implementation 'mruby'. While I was developing my own application using mruby, I tended to profile ruby code with timers:

before = Time.new()
run_routine()
after  = Time.new()
puts("run_routine took #{1000*(after-before)} ms")

This provided limited information, but it helped direct the development to a few hotspots and then additional profiling of the C portion of the codebase was done with callgrind. Callgrind for me is a holy grail of profiling CPU bound programs. Through kcachegrind it provides an easy to explore callgraph, relative and absolute timing information, source level information, and information at the assembly level. Callgrind combined with kcachgrind make it easy to understand where the hotspots for a program are, what is the callgraph that generates these issues, and what compiled assembly creates the issues. If you’re trying to optimize a C/C++ codebase just use callgrind. It slows down the overall execution by at least an order of magnitude, but the information provided is superb.

MRuby-Profiler

Back to mruby, the initial timer based profiling doesn’t have many of the advantages of callgrind, or other profiler tools. Adding timers was a manual process, it provided very coarse information, and it provided only a limited slice of the whole program. As such, a full mruby VM profiler should be preferred. The mruby-profiler gem is one such tool.

MRuby-profiler works by observing the progression of the mruby virtual machine via a callback which is invoked every time the VM executes a new ruby instruction. This allows for the profiler to have an exact count for how many times an instruction is invoked, a reasonably accurate time for the execution of each instruction, information about the call graph, and often detailed line-by-line source level times.

Example

Now that the mruby-profiler gem is introduced, let’s take a look at a simple example run. In the top-left you’ll see a simple ruby program, on the right mruby-profiler’s source annotated output, and in the bottom-left mruby-profiler’s no-source VM instruction only output.

def test_code
    var1 = []
    100.times do |x|
        var1 << x
    end

    var1.each_with_index do |x, ind|
        var1[ind] = 0.1 + 2.0*x + 4.3*x**2.0
    end

    var1
end

test_code

0000 0.00011 def test_code
        1 0.00002    OP_TCLASS     R1
        1 0.00003    OP_LAMBDA     R2      I(+1)   1
        1 0.00003    OP_METHOD     R1      :test_code
        1 0.00003    OP_ENTER      0:0:0:0:0:0:0
0001 0.00004     var1 = []
        1 0.00004    OP_ARRAY      R2      R3      0
0002 0.00186     100.times do |x|
        1 0.00002    OP_LOADI      R3      100
        1 0.00005    OP_LAMBDA     R4      I(+1)   2
        1 0.00007    OP_SENDB      R3      :times  0
      100 0.00172    OP_ENTER      1:0:0:0:0:0:0
0003 0.00957         var1 << x
      100 0.00142    OP_GETUPVAR   R3      2       0
      100 0.00128    OP_MOVE       R4      R1
      100 0.00479    OP_SEND       R3      :<<     1
      100 0.00208    OP_RETURN     R3      return
0004 0.00000     end
0005 0.00000
0006 0.00186     var1.each_with_index do |x, ind|
        1 0.00002    OP_MOVE       R3      R2
        1 0.00004    OP_LAMBDA     R4      I(+2)   2
        1 0.00006    OP_SENDB      R3      :each_with_index 0
      100 0.00175    OP_ENTER      2:0:0:0:0:0:0
0007 0.03609         var1[ind] = 0.1 + 2.0*x + 4.3*x**2.0
      100 0.00142    OP_LOADL      R4      L(0)    ; 0.1
      100 0.00139    OP_LOADL      R5      L(1)    ; 2
      100 0.00142    OP_MOVE       R6      R1
      100 0.00167    OP_MUL        R5      :*      1
      100 0.00145    OP_ADD        R4      :+      1
      100 0.00148    OP_LOADL      R5      L(2)    ; 4.3
      100 0.00141    OP_MOVE       R6      R1
      100 0.00143    OP_LOADL      R7      L(1)    ; 2
      100 0.00850    OP_SEND       R6      :**     1
      100 0.00157    OP_MUL        R5      :*      1
      100 0.00152    OP_ADD        R4      :+      1
      100 0.00158    OP_GETUPVAR   R5      2       0
      100 0.00128    OP_MOVE       R6      R2
      100 0.00141    OP_MOVE       R7      R4
      100 0.00647    OP_SEND       R5      :[]=    2
      100 0.00209    OP_RETURN     R4      return
0008 0.00000     end
0009 0.00000
0010 0.00004     var1
        1 0.00004    OP_RETURN     R2      return
0011 0.00000 end
0012 0.00000
0013 0.00225 test_code
        1 0.00001    OP_LOADSELF   R1
        1 0.00005    OP_SEND       R1      :test_code      0
        1 0.00218    OP_STOP

Fixnum#times 0.01822
     1 0.00002    OP_ENTER      0:0:0:0:0:0:1
     1 0.00001    OP_LOADSELF   R3
     1 0.00011    OP_SEND       R3      :block_given?   0
     1 0.00001    OP_JMPNOT     R3      002
     1 0.00001    OP_JMP                005
     0 0.00000    OP_LOADSELF   R3
     0 0.00000    OP_LOADSYM    R4      :times
     0 0.00000    OP_SEND       R3      :to_enum        1
     0 0.00000    OP_RETURN     R3      return
     1 0.00001    OP_LOADI      R2      0
     1 0.00001    OP_JMP                007
   100 0.00128    OP_MOVE       R3      R1
   100 0.00142    OP_MOVE       R4      R2
   100 0.00546    OP_SEND       R3      :call   1
   100 0.00128    OP_MOVE       R3      R2
   100 0.00164    OP_ADDI       R3      :+      1
   100 0.00128    OP_MOVE       R2      R3
   101 0.00144    OP_MOVE       R3      R2
   101 0.00138    OP_LOADSELF   R4
   101 0.00143    OP_LT R3      :<      1
   101 0.00138    OP_JMPIF      R3      -09
     1 0.00001    OP_LOADSELF   R3
     1 0.00002    OP_RETURN     R3      return

From these outputs, we can see that the most expensive line in the program is line 7 which takes roughly 36 ms to execute over the course of this entire program. The '**' operator takes a large portion of that time (8.5 ms) and is executed 100 times as expected. The first '100.times' loop takes 1.8 ms + 9.5 ms + 18.2 ms (from the overhead of Fixnum#times itself). Within the output, line numbers, source code, VM instruction call counts, and VM instruction self times can be seen fairly clearly.

Complications In Profiling

The mruby-profiler gem makes profiling much easier, however there are a few limits with it’s current implementation.

Entering and Exiting The MRuby VM

The timers within mruby-profiler are relatively simple and in most code they tend to work very well. They do fail when interacting with any program which ends up doing a fair amount of work within C which ends up calling ruby methods from C. To elaborate on that, let’s first look at how mruby-profiler calculates how much time is spent at a given mruby opcode.

The mruby-profiler gem uses the code fetch hook within the mruby VM. Every time an opcode is executed by the mruby VM the code fetch hook is called. MRuby-profiler records the time when an instruction is fetched. When the next fetch occurs the difference in time is assumed to be the amount of time spent in the previous instruction.

Generally this model works well. For normal ruby code it’s completely accurate, for ruby calling simple C routines the appropriate amount of time is given to the OP_SEND instruction which lead to the C call, but it fails with a mixture of C/ruby calls. Consider the below sequence of events:

C code calls one ruby method
C code works on a long running task
C code calls another ruby method

During step 2 no ruby opcodes will be observed by mruby-profiler. Thus, when step 3 occurs and a new VM opcode is fetched, then all the time that was spent in step 2 is attributed to the last instruction in step 1. Typically the last instruction of a mruby method would be OP_RETURN. So, if you spot an OP_RETURN which is taking much more time than it should, be aware that it may be counting time spent in a calling C function.

A lack of cumulative child function time

In general I’d say having method/instruction time presented as 'self-time' is preferable in a reasonably well architected system. Self-time presents how much time could effectively be saved by optimizing the method by itself without considering the rest of the code it ends up calling.

Self-time, however, can create a few problems with interpreting the results of mruby-profiler. If a hotspot function is called a large number of times, it can be tricky to backtrack which functions called it a significant number of times or with a particular type of data which took the hotspot function longer to evaluate. The lack of cumulative times also make it hard to evaluate if a particular function is 'expensive to call'. It is possible to have an 'expensive to call' function which does not use a significant amount of time with called functions which also do not use much time. If, however, there is a sufficiently deep call stack, then an innocuous function can still become very expensive in the cumulative sense (i.e. "death by a million cuts")

The last issue is one that’s more ruby specific. I’d say it’s fair to say that if you enjoy ruby you use blocks… You use them a lot. For those of you unfamiliar with what a block is here’s a simple example:

object.method do |optional_args|
    work_on_block
end

irep 0x9b433e0 nregs=3 nlocals=1 pools=0 syms=2 reps=1
file: tmp.rb
    1 000 OP_LOADSELF   R1
    1 001 OP_SEND       R1      :object 0
    1 002 OP_LAMBDA     R2      I(+1)   2
    1 003 OP_SENDB      R1      :method 0
    1 004 OP_STOP

irep 0x9b494a8 nregs=5 nlocals=3 pools=0 syms=1 reps=0
file: tmp.rb
    1 000 OP_ENTER      1:0:0:0:0:0:0
    2 001 OP_LOADSELF   R3
    2 002 OP_SEND       R3      :work_on_block  0
    2 003 OP_RETURN     R3      return

In the ruby code :method is called with the block (do..end). The block is encoded as a lambda function (the second irep) and method ends up calling the lambda. Just like in the very first example, with Fixnum#times, the cost involved with :method is associated with :method’s implementation and not the object.method call. When the block accepting method adds a significant amount of overhead it’s very easy to overlook using self-time and you should be aware of it when profiling. In the case of iteration, we’ll revisit block-method overhead later in this article.

While at the moment mruby-profiler doesn’t present cumulative time information it does capture it from the MRuby VM (or at least it appeared to when I looked at the source). It’s not in the most convenient format, but at least the data is there, it’s just the analysis which needs to be updated (and that’s all ruby). The mruby-profiler gem is still missing the functionality, but I imagine it could be added reasonably easily in the future.

Bugs

Of course another limitation of using both mruby and mruby-profiler is that both of them are going to have more bugs than other tools with more widespread use. When I initially found mruby-profiler it tended to crash in a variety of ways for the codebase I was profiling (I’d recommend using the fixes I’ve proposed to mruby-profiler via a pull request if it hasn’t yet been merged). When I initially began using MRuby I encountered a few bugs, though MRuby has become a fair bit more stable over the past year. Lastly, while mruby-profiler does provide an output for kcachgrind, be aware that it is incomplete and there are some bugs in the output (though it is entirely unclear if they are from mruby’s debug info or a bug within mruby-profiler).

Deciding when to move from ruby to C

One of the great things about MRuby (and one of the major reasons why I’ve used it for a sizable user interface project) is that it’s extremely easy to move a routine from ruby to C. Of course it’s still easier to leave code as ruby (otherwise I would have just written everything in C), so what tasks does ruby struggle with?

Heavy numerical tasks

Like most interpreted languages, heavy mathematical operations aren’t 'fast'. Of course, they may be fast enough, but major gains can be made by using a compiled and heavily optimized language like C.

Consider the below ruby code:

def func(array)
  array.map do |x|
    Math.abs(Math.sin(x + 2 + 7 * 8 + 3))
  end
end

void func(float *f, int len)
{
    for(int i=0; i<len; ++i)
        f[i] = fabsf(sinf(f[i] + 2 + 7 * 8 + 3));
}

irep 0x8d24b40 nregs=5 nlocals=3 pools=0 syms=1 reps=1
file: tmp.rb
    1 000 OP_ENTER      1:0:0:0:0:0:0
    2 001 OP_MOVE       R3      R1              ; R1:array
    2 002 OP_LAMBDA     R4      I(+1)   2
    2 003 OP_SENDB      R3      :map    0
    2 004 OP_RETURN     R3      return

irep 0x8d24b90 nregs=9 nlocals=3 pools=0 syms=5 reps=0
file: tmp.rb
    2 000 OP_ENTER      1:0:0:0:0:0:0
    3 001 OP_GETCONST   R3      :Math
    3 002 OP_GETCONST   R4      :Math
    3 003 OP_MOVE       R5      R1              ; R1:x
    3 004 OP_ADDI       R5      :+      2
    3 005 OP_LOADI      R6      7
    3 006 OP_LOADI      R7      8
    3 007 OP_MUL        R6      :*      1
    3 008 OP_ADD        R5      :+      1
    3 009 OP_ADDI       R5      :+      3
    3 010 OP_SEND       R4      :sin    1
    3 011 OP_SEND       R3      :abs    1
    3 012 OP_RETURN     R3      return

func:
.LFB9:
    .cfi_startproc
    movl    4(%esp), %ecx
    movl    8(%esp), %edx
    testl   %edx, %edx
    jle .L1
    movl    %ecx, %eax
    leal    (%ecx,%edx,4), %edx
    flds    .LC0
.L3:
    fld %st(0)
    fadds   (%eax)
    fsin
    fabs
    fstps   (%eax)
    addl    $4, %eax
    cmpl    %edx, %eax
    jne .L3
    fstp    %st(0)
.L1:
    ret

The ruby VM instructions are reasonably quick, but when comparing 12 ruby opcodes to 4 assembly instructions (fld..fstps), it’s rather obvious that there’s going to be a pretty reasonable difference in speed. MRuby isn’t going to simplify any of the math that you supply it with and each opcode (simple or not) is going to take a fair bit longer than a single assembly instruction.

Heavy Member Access

Accessing data stored in mruby classes isn’t all that cheap even for simple attributes. Each member access in idiomatic ruby results in a method call via OP_SEND. Evaluating each method call is relatively expensive compared to other opcodes and each call tends to involve a setup phase for the arguments of each method. In comparison for C to access member variables it’s as simple as fetching memory at an offset to the base of the structure.

class Y
    attr_accessor :a, :b, :c, :d
end

def func(array, y)
  array.map do |x|
    x + y.a + y.b * y.c + y.d
  end
end

struct Y {
    float a, b, c, d;
};

void func(float *f, int len, struct Y y)
{
    for(int i=0; i<len; ++i)
        f[i] = f[i] + y.a + y.b * y.c + y.d;
}

irep 0x94feb90 nregs=6 nlocals=4 pools=0 syms=1 reps=1
file: tmp.rb
    5 000 OP_ENTER      2:0:0:0:0:0:0
    6 001 OP_MOVE       R4      R1              ; R1:array
    6 002 OP_LAMBDA     R5      I(+1)   2
    6 003 OP_SENDB      R4      :map    0
    6 004 OP_RETURN     R4      return

irep 0x9510068 nregs=7 nlocals=3 pools=0 syms=6 reps=0
file: tmp.rb
    6 000 OP_ENTER      1:0:0:0:0:0:0
    7 001 OP_MOVE       R3      R1              ; R1:x
    7 002 OP_GETUPVAR   R4      2       0
    7 003 OP_SEND       R4      :a      0
    7 004 OP_ADD        R3      :+      1
    7 005 OP_GETUPVAR   R4      2       0
    7 006 OP_SEND       R4      :b      0
    7 007 OP_GETUPVAR   R5      2       0
    7 008 OP_SEND       R5      :c      0
    7 009 OP_MUL        R4      :*      1
    7 010 OP_ADD        R3      :+      1
    7 011 OP_GETUPVAR   R4      2       0
    7 012 OP_SEND       R4      :d      0
    7 013 OP_ADD        R3      :+      1
    7 014 OP_RETURN     R3      return

func:
.LFB0:
    .cfi_startproc
    movl    4(%esp), %ecx
    movl    8(%esp), %edx
    testl   %edx, %edx
    jle .L1
    flds    24(%esp)
    fadds   12(%esp)
    flds    20(%esp)
    fmuls   16(%esp)
    faddp   %st, %st(1)
    movl    %ecx, %eax
    leal    (%ecx,%edx,4), %edx
.L3:
    fld %st(0)
    fadds   (%eax)
    fstps   (%eax)
    addl    $4, %eax
    cmpl    %edx, %eax
    jne .L3
    fstp    %st(0)
.L1:
    ret

The mruby VM is fast, but when dealing with these member variable references the overhead adds up. The relatively basic loop results in a 15 opcode body. Of those opcodes, 4 are method calls, and 4 involve setting up the method calls. C doesn’t even need a separate instruction to fetch the values due to the addressing modes that x86 provides. Additionally, C can recognize that the member variables are constant and calculate their affect once outside the loop body. That leaves 3 (fld..fstps) instructions in the loop body for a tight C loop.

Loops of any sort

Actually, going one step beyond, loops over large amounts of data are just bad for performance in MRuby due to the overhead introduced by Array#each/Array#map/etc.

$dummy = 0
def func(array)
  array.each do |x|
    $dummy = x
  end
end

volatile int dummy;
void func(int *x, int len)
{
    for(int i=0; i<len; ++i)
        dummy = x[i];
}

irep 0x8fa1b40 nregs=5 nlocals=3 pools=0 syms=1 reps=1
file: tmp.rb
    2 000 OP_ENTER      1:0:0:0:0:0:0
    3 001 OP_MOVE       R3      R1              ; R1:array
    3 002 OP_LAMBDA     R4      I(+1)   2
    3 003 OP_SENDB      R3      :each   0
    3 004 OP_RETURN     R3      return

irep 0x8fa1b90 nregs=4 nlocals=3 pools=0 syms=1 reps=0
file: tmp.rb
    3 000 OP_ENTER      1:0:0:0:0:0:0
    4 001 OP_SETGLOBAL  :$dummy R1              ; R1:x
    4 002 OP_RETURN     R1      return  ; R1:x

func:
    .cfi_startproc
    testl   %esi, %esi
    jle .L1
    movl    $0, %eax
.L3:
    movl    (%rdi,%rax,4), %edx
    movl    %edx, dummy(%rip)
    addq    $1, %rax
    cmpl    %eax, %esi
    jg  .L3
.L1:
    rep ret

In previous examples the loop overhead for C was neglected. For this example, 3 instructions: addq, cmpl, and jg are the overhead per loop iteration. Ruby’s is hidden in the :each method of the container. If you’re in an optimizing mindset, you might think that since :each is the idiomatic way to build loops in ruby it would be built to limit overhead.

Nope:

class Array
  def each(&block)
    return to_enum :each unless block_given?

    idx, length = -1, self.length-1
    while idx < length and length <= self.length and length = self.length-1
      elm = self[idx += 1]
      unless elm
        if elm.nil? and length >= self.length
          break
        end
      end
      block.call(elm)
    end
    self
  end
end

Translating that to VM instructions results in 25 opcodes overhead per loop with 4 method calls (:[], :call, :length, :length). Ouch…

So, Array#each/Array#map/etc have a lot of overhead when you get to optimizing. What about other types of loops? A standard for loop is just an alias to :each. A while loop however avoids much of the setup and per iteration cost.

$dummy = 0
def func(array)
  for x in 0...array.length do
    $dummy = array[x]
  end
end
irep 0x904db40 nregs=7 nlocals=4 pools=0 syms=2 reps=1
file: tmp.rb
    2 000 OP_ENTER      1:0:0:0:0:0:0
    3 001 OP_LOADI      R4      0
    3 002 OP_MOVE       R5      R1              ; R1:array
    3 003 OP_SEND       R5      :length 0
    3 004 OP_RANGE      R4      R4      1
    3 005 OP_LAMBDA     R5      I(+1)   2
    3 006 OP_SENDB      R4      :each   0
    3 007 OP_RETURN     R4      return

irep 0x904db90 nregs=5 nlocals=1 pools=0 syms=2 reps=0
file: tmp.rb
    3 000 OP_ENTER      1:0:0:0:0:0:0
    3 001 OP_SETUPVAR   R1      3       0
    4 002 OP_GETUPVAR   R2      1       0
    4 003 OP_GETUPVAR   R3      3       0
    4 004 OP_SEND       R2      :[]     1
    4 005 OP_SETGLOBAL  :$dummy R2
    4 006 OP_RETURN     R2      return

$dummy = 0
def func2(array)
  itr = 0
  n   = array.length
  while itr < n
    $dummy = array[itr]
    itr += 1
  end
end
irep 0x90fbb40 nregs=8 nlocals=5 pools=0 syms=5 reps=0
file: tmp.rb
    2 000 OP_ENTER      1:0:0:0:0:0:0
    3 001 OP_LOADI      R3      0               ; R3:itr
    4 002 OP_MOVE       R5      R1              ; R1:array
    4 003 OP_SEND       R5      :length 0
    4 004 OP_MOVE       R4      R5              ; R4:n
    5 005 OP_JMP                013
    6 006 OP_MOVE       R5      R1              ; R1:array
    6 007 OP_MOVE       R6      R3              ; R3:itr
    6 008 OP_SEND       R5      :[]     1
    6 009 OP_SETGLOBAL  :$dummy R5
    7 010 OP_MOVE       R5      R3              ; R3:itr
    7 011 OP_ADDI       R5      :+      1
    7 012 OP_MOVE       R3      R5              ; R3:itr
    5 013 OP_MOVE       R5      R3              ; R3:itr
    5 014 OP_MOVE       R6      R4              ; R4:n
    5 015 OP_LT R5      :<      1
    5 016 OP_JMPIF      R5      006
    5 017 OP_LOADNIL    R5
    5 018 OP_RETURN     R5      return

There’s still plenty of register shuffling with the while loop, but 6-7 opcodes of overhead per iteration and only one method call (:[]) sure beats 25 extra opcodes per loop. So, if you want to keep a hotspot in pure ruby, you might have more luck with inlining a while loop or using :each_index which is a middle ground in terms of cost.

Conclusions

MRuby is reasonably fast, though once you’re ploughing through enough data and code, then hotspots slowing things down are basically inevitable. MRuby makes it pretty easy to patch up these hotspots by seamlessly implementing the methods in C. To keep a codebase quick you still need to find hotspots in code and tools like mruby-prof make this task a lot easier. I hope this ramble about using mruby-profiler is helpful.