I recently put off the release of Inventor IDE Alpha 5b (probably coming in August, since my honours project is highest priority now) to get something ready for DemoCamp Vancouver that I’ve been wanting for a very long time.  It’s a feature that probably won’t be released until Alpha 6, but you can be certain that I’ll try to make good use of it at D-Wave as soon as I can.  I consider it the first truly awesome feature of Inventor IDE.  It’s easiest to introduce with a picture:

Rock-solid performance data literally in the blink of an eye

(In case you’re wondering, the times are in clock cycles on a 1.66GHz laptop, so 100,000 clocks = 60 microseconds.)

A big problem in doing performance analysis is that getting reliable results and useful scaling info usually means tests that take minutes, so that the impact of the OS or other applications levels off to a constant factor.  If you try to do short tests, you get issues like these:

Bad Performance Data for 2 Mersenne Twister Implementations

Bad Performance Data for 3 Sorting Implementations

These aren’t exactly reliable results; running a short test multiple times produces wildly different results because of just a few bad data.  On Tuesday around 4am (Pacific Daylight  Time), I finally managed to find a decent approach to eliminate almost all bad data without eliminating much good data.  It’s certainly not perfect, but here are the results of running the two Mersenne Twister tests thrice each while AQUA@Home is trying to max out the CPU and the harddrive is thrashing like mad (for unknown reasons):

Much Better Mersenne Twister Performance Data

It’s worth pointing out that these times are in fact noticeably worse than the results when the CPU and harddrive aren’t under heavy load elsewhere (about 1.5 times as long).  The important thing is that the results are still remarkably consistent, and Mersenne128 is still 3.8 times faster than Mersenne32.  You can even still roughly see that Mersenne32 regenerates its data array every 624 elements and Mersenne128 regenerates every 2496 elements.  In case you’re wondering why CPU times would be so consistently longer instead of scattered, it has to do with process switches flushing the cache and TLBs, only causing cache misses in the good data, whereas the bad data still contain any process switches and other interrupts (like the 1kHz tick and page faults).

I’m still shocked that I can effectively triple-click the test run button on the performance test functions and have the results show up as fast as Windows can show the windows.  It’s even more responsive than the regular run button in the ImageProgram sample app, and that had shocked me.  That said, I found the ironic-but-not-so-important problem that it names the output files with the time only down to the second, so one that ran in the same second as another wrote over the first’s data file.

This kind of capability finally allows developers to rapidly iterate through possible performance improvements, not only making it faster to optimize, but much easier, because there’s time to try out many more optimizations in the same amount of time.  For example the faster mergesort in the top graph is from adding a special case for n=2.  In that way, it can also be used as a learning tool for developers to determine what does and doesn’t improve performance.  Best of all, because of the performance viewer’s language-independence, its platform-independence, and the many useful analyses it could do on the data, it’s applicable to many different situations; probably many I won’t think of myself, so I leave that up to you.  I’ve just shown you the first glimpse into what I’ve got planned for it. 

Today, I fixed a ton of bugs in Inventor IDE and added some simple-but-useful functionality I’d been putting off for a long time.  It occurred to me earlier today that for almost all of these bugs, I’m probably the only one who’s ever encountered them, and some of them, even I never encountered them; they’re fixed without ever being experienced.  I thought I’d share some of these bugs with you to give an idea of what I’ve been up to and what sort of bugs I encounter in Inventor IDE.

Bug #1: Huge JComboBox

This is one of those bugs that I can’t actually fix, but I managed to find a workaround after a whole lot of banging my head against the wall.  There’s at least one bug in Java’s implementation of JComboBox that uses the Windows look-and-feel.  It may have been fixed in Java 1.6 or later, but I have to build with Java 1.5 or nothing will run when somebody tries to run it with Java 1.5, even though I’m not using any Java 1.6 features.

The bug: suddenly and irregularly, the size of a JComboBox will become larger than 16384 x 16384.  When Java tries to create a buffer into which to paint the JComboBox, it runs out of memory, because 16384 x 16384 x 4 bytes per pixel = 1GB.

It took a few hours to figure this out, because the stack trace for the OutOfMemoryError doesn’t contain any of my code (since I hadn’t overridden JComboBox.paintComponent()) and the bug rarely occurs.  The way I eventually figured it out was that I put a breakpoint at one of the low levels in the stack trace, ran the code until I got a debugger trace that looked similar, and looked back at the object up the chain at the last pair of paint()/paintChildren() calls, and it turned out to be an ObservedStringComboBox (one of my classes).  It wasn’t for a few minutes that I realized the size was so huge, and I discovered that getPreferredSize() and getMinimumSize() return similarly huge sizes too, so I traced into them.  After an hour of crawling through the mess that is Java’s Swing, I found that it was probably that some object was giving a dummy value to indicate that it didn’t really know how large something was supposed to be.

The solution: I’ve overridden JComponent.paintComponent() in both classes I have that extend JComboBox, and they check whether the width or height is over 16384, in which case, they do a rough estimation of the size based on the string widths of their options.  Then, they call setSize(), setMinimumSize(), setPreferredSize(), and setMaximumSize(), just to make sure, before calling the original paintComponent().  It successfully picked up the error when it occurred, and set the JComboBox to a reasonable size that didn’t look out of place.

Bug #2: Where’s the caret?

This bug has been around for quite some time, and although I was stumped on a good way to solve it (partly due to the next bug), it’s solution was a one-character change.

The bug:

The caret is currently at the beginning of the first "SegmentDescriptor", but it's impossible to see.

The border of the LineFields blocks out the one pixel-width of the caret that would be visible if it had no border.

The solution:

The exact same thing, but everything in a LineField is drawn 2 pixels to the right

This was literally solved by changing the insets from (0,0,0,0) to (0,2,0,0).  Now the full caret is visible.  (It didn’t look as good with just one pixel-width showing, so I have both pixels showing.)

Bug #3: The layout war

I hate layout issues; Java seems to have a neverending supply of them, which is why I removed LayoutManagers from a vast majority of the components that need good layout.  There were a few major layout bugs that I still had though, and the most ridiculous-looking was to do with the layout of my ObservedStringTables (shown above correctly, but I’ll use a new example).

The bug: the ObservedStringTable should control the layout of the LineFields it contains, since they should be kept looking tabular, but many LineFields elsewhere are supposed to resize automatically to fit the current size of their text, so that behaviour was built into LineField.

An enumeration isn't supposed to look this bad (btw, here, it auto-increments by "sizeof SegmentDescriptor" if no value specified)

The solution: it’s not a great solution, but by the time it’s lack of greatness would matter, it’ll have changed or need changing for other reasons already.  I just have LineField check whether it’s in an ObservedStringTable, and if it is, it doesn’t change its own size.

Finally, it looks like a table

In case you’re wondering, yes, the caret is now not visible if it’s at the end of the Increment field.  I’ll fix it now, ’cause I’ll forget something small like that… there we go; insets are now (0,2,0,2). 

Bug #4: When the impossible is possible

Moving away from UI-related bugs, this bug was technically fixed today, though only because today started at midnight, not when I got up (11:30 AM).  A few days ago, I added support for compiling inline functions that have only text-replacement parameters (i.e. macros minus support for elaborate macro stuff).  That way, I can use it for having debug output functions in PwnOS that don’t get called at all if “TEXT_TESTING_MODE” is false.  However, fairly often when compiling, though unpredictably, there’d be an ArrayIndexOutOfBoundsException when adding a reference to a line or when adding an error to a line.

It’s fairly common to add errors to lines during compilation, since the error detection doesn’t check for everything before compile-time, but the only code that would be adding references to lines would be the code for inline function compiling.  When I encounter a call to an inline function, I copy the function, replace the parameter references in the code with their given values, and remove the parameters.  Then I compile it as a regular function, just in the middle of another function.  The weird thing about this error is that upon adding a check to make sure that the array was large enough (which was even redundant, because the line before had been a call to ensureRefCapacity(), which expands the reference array if needed), it still had the same array index exception.  The only way I could think of that this could happen is if multiple threads were messing around with the same line at the same time, but the odds of that were pretty low, considering I’d explicitly designed the compilation not to modify anything concurrently.

The bug: when a parameter is removed from a function that is in global scope, things observing the global scope get notified about it.  A temporary copy of an inline function shouldn’t really be notifying the global scope about its parameters being removed, and updating code based on a notification is probably not something that should occur while compiling.  Sure enough, functions didn’t like getting told that a temporary function they can’t actually access has lost a parameter.

The solution: this is one bug where I haven’t actually determined exactly how/why it was occurring, but the stack traces and stepping through debugging clearly showed that the error was only occurring when a temporary function was broadcasting to everybody that it had lost a parameter, which it shouldn’t be doing.  I just stopped temporary functions from notifying the global scope of anything.  It’s usually not advisable to fix something without fully understanding it, but often, such a restriction would mean that few bugs would get fixed.  For now, I’m okay with this lack of understanding, because I’ll need to re-investigate and adjust this type of thing when I add support for function overloading when I add support for C, and until then, it’s unlikely that any oversight here will rear its head again.

Yesterday’s Bug: The complete round-off problem

So this wasn’t from today, but it’s a cool quirk of floating-point calculation with which programmers should familiarize themselves.  Suppose that you have an array of floats (4-byte real numbers) that’s 2 billion elements long, and every single element contains the value 1.  If you simply go through the array and sum up the values of the elements, what is the final sum?

You might guess that it’s 2 billion plus or minus some relatively small amount of error, but in fact, the sum is exactly 8,388,608.  This is the case whether you have 10 million elements, 2 billion elements, or 1 trillion elements.  The answer is still 8,388,608.  Why?

floats have 23 bits of mantissa, and once they get to the value 8,388,608 (i.e. 1.0000…0×2^23), adding the value 1 would make it 8,388,609, but this can’t be represented exactly in floating point, so it gets rounded down (following the round even rule), back to 8,388,608.  This happens for every single 1 that is added after that too.  In general, when adding many values that are all positive (or all negative) of similar magnitude, the final sum will be around 8,388,608 times the average value.

This is exactly what I found in a piece of code I had changed to use floats instead of doubles at work (at D-Wave).  It was trying to add 14,400,000 elements with roughly the value 1, and it gave 8,388,608 every time.  Instead of reading the sum, I was actually reading the average, 0.582542 instead of about 1.0, so it wasn’t immediately apparent why it was wrong.  I realized that this was the error when I ran it for 144,000,000 elements and got 0.058254, which is 10 times less for 10 times as many elements, meaning that the sum hadn’t changed.  That brings up the question, how do you add up the elements in an array to avoid this?

The solution: Well, the way I fixed it at work was to just change it back to using a double (8-byte real number) to accumulate the values.  That doesn’t encounter the complete round-off problem until 2^52 additions; it can still result in bad round-off error before then, but it shouldn’t be an issue for the piece of code we were doing this in.  Is there a way that works for any number of additions?

One way that works in O(logn) extra space (or inline if you can destroy the data), while still being in O(n) time, is that you break it up by adding every pair, then adding every pair of those, then adding every pair of those, etc.  The way that can be done in O(logn) space is that you keep a value for every level, all starting at zero, and when you’re done a level, you add the value to the next level up.  If that was the end of the next level up, it goes up more, else you go back to the next at the bottom.  This is equivalent to splitting it up recursively (using O(logn) stack space), only without the disadvantages of recursion.  It also has the advantage that it could be done with data coming in over time.  Note that there’s still the issue of round-off from adding positive and negative numbers that sum to near zero, but there’s not much that can be done about that.

Edit: Here’s code for this approach (untested):

float sum(const float*const array,const size_t size) {
    // Assuming there is a function to compute the ceiling of log_2 of size
    // The -1 is because the lowest level (pairs) gets added immediately instead of waiting
    const size_t logSize = ceilLog2(size)-1;
    float accumulators[logSize] = {0};
    bool isSecondHalf[logSize] = {0};
    float sum;
    for (size_t i=0; i<size-1; i+=2) {
        // Add together a pair of elements
        sum = array[i];
        sum += array[i+1];
        size_t level = 0;
        // Go up the tree until reaching the end
        // or a place where it's the first half
        while (isSecondHalf[level]) {
            isSecondHalf[level] = 0;
            accumulators[level] = 0;
            sum += accumulators[level+1]
            ++level;
            // Handle case of size being an exact power of two
            if (level==logSize) {
                return sum;
            }
        }
        // Save the sum at the highest level reached
        accumulators[level] = sum;
        // Now on the second half of that level
        isSecondHalf[level] = 1;
    }
    // Make sure to get the last element if there were an odd number of elements
    sum = (size&1) ? array[size-1] : 0;
    // Add up all values left in accumulators (order matters)
    for (size_t level=0; level<logSize-1; ++level) {
        sum += accumulators[level];
    }
    return sum;
}

After fixing dozens of bugs (probably between 50 and 75), adding a Stop button to stop a running app, and adding support for building operating system code, Inventor IDE Alpha 5a is now out. 

It now no longer freezes if an error (like running out of memory) occurs while compiling, and numerous other checks for errors were added.  If you get an error message, please send me a screenshot and a description of what led to it.  I’ve got a cool idea for a full debugging system for reproducing errors, but unfortunately, there’s no way that I have time to make it.

Alpha 5b should be out soon with a project settings dialog box, so that you can choose to make a 64-bit executable, set up the segments in an operating system build, and hopefully create a DLL that actually has exports.

Alpha 6 will introduce what I consider the first truly awesome feature of Inventor IDE, and it’s something I’ve been waiting years to see in an IDE, even though it’s so simple, but you’ll just have to wait to see what it is… or badger me until I spill the beans. 

In other news, Code Cortex is now incorporated, so I can start applying for funding, and if that works out, hopefully I’ll finally be able to start paying people for their work.  Also, I stumbled upon some notes I took at a CUTC 2006 presentation by Infusion Development’s CEO, Greg Brill, and I remembered how inspiring and encouraging they were:

• make something you’re passionate about first; don’t think too hard about the business stuff
• find the opportunity missed by the industry now; who’s being ignored?
• business plan sometimes comes after the success
• shut up; do something!
• try it; fail
• business is easy: find a need, fill a need
• learn
• if you love it, you’ll do it

I get a lot of discouraging, useless business advice, usually from people who only care about making money, so Mr. Brill’s talk gave me hope that one person really can make a difference.

First, I’d like to say sorry that I haven’t yet posted the contest that I’ve planned to hold.  I’ve now got a source of legal advice, and since the first contest is for a fairly important-but-simple component of Inventor IDE, I don’t want to risk screwing it up until I get a lawyer’s ideas for it.  I might hold the competition on Top Coder, but it looks like they’ve changed their model of letting people host contests.  If I can find someone up for making some really cool interactive GUI components, I could contract it out to them, but I’d like to see what different people can come up with, since there’s a lot of room for creativity.

Also, sorry to those who’ve experienced bugs with Inventor IDE alpha 5.  I was going to make a special build just for one bug reporter so that I can fix a freezing bug that I can’t reproduce on my machine.  However there should really be a more extensive debugging system, logging information to files that can help me identify what went wrong when I get a bug report.  As such, I’ll release the regular version with logging of error information, and a special debugging version that will periodically check for model consistency and log extensively, even when no error has occurred, so that errors can be fixed more easily.  I can’t give a reliable ETA on this release yet, since I’ve got a lot going on this week, but it’s something I really need for future releases anyway.

After many months of mind-breaking work, Inventor IDE Alpha 5 is finally here with built-in assembling, a greatly-improved UI, and a new sample application!  These should make the rest of the assembly language video tutorial go much more smoothly.  I encourage those of you running Windows to download it and press the bright green Run button to see what I mean.  (Sorry to Linux users without WINE; I only have it compiling to 32-bit Windows executables so far.)  I was going to post more videos this weekend, but some last-minute bugs cropped up that couldn’t be ignored.

Also of note is that soon (probably a couple of weeks, since I’m swamped with 3 performances, 3 assignments, and 2 exams in these next 2 weeks) I’ll be posting details of some competitions I’ll be holding to let you all get involved with developing important (and very cool) pieces of Inventor IDE.  It’s no fun doing this all alone, so I’m eager to see what people come up with for creative and cutting-edge components. 

I don’t want to jinx it, but if all goes well I may be able to get enough government funding for Code Cortex to start paying people a salary too.

The fourth video in the assembly language  tutorial, (episode 3, since real programmers number things from 0 ), is finally up.  I had some problems with the upload and conversion, mostly because 30-minute, 800×600, losslessly-compressed videos are huge, but now it’s fine.  I’ll make shorter videos from now on, since it can be a bit much to absorb in one sitting anyway.

On a completely different note, my friend, Ben, has produced a C++ version of the hypercube application that uses OpenGL, cutting the CPU use to around 2%.  I’ll post it eventually, but I’ve got a lot on my plate right now.  I should have some form of assembling and linking (probably not working correctly, but close) working in Inventor IDE by Monday.  I won’t release it until it’s stable, though, since that’s not the sort of thing you want to use until it’s rock solid.

I’ve been making lots of progress on assembling support for Inventor IDE in the past couple of weeks.  In particular, I’ve looked at what I’m calling the x86 jump encoding problem.  The only piece of literature I’ve found referring to this problem calls it branch displacement optimization, but it allows convoluted declarations that are never useful, making the problem NP-complete.  There is a simple quadratic-time algorithm to solve the problem optimally (assuming there are no declarations of arrays whose size depends on the negative of the size of any code; if you do, you’ve got bigger problems than a few extra bytes of data), and I went in search of a simple linear-time algorithm to solve it optimally.

In the past week I managed to create such an algorithm. :)  It is simple, using no obscure data structures, no recursion, and no randomization, plus it should be as fast or faster than the quadratic-time algorithms on average.  I’ve also since come up with a simple way to eliminate most jumps from consideration in the single pass through to determine the initial jump distances.  Simplicity is nice.

On a semi-related note, I won’t have the next video in my video tutorial on assembly language out by year’s end because of my current lack of internet access at home and all of the time I’ve been spending on Inventor IDE, but it should be out no later than January 5th or 6th.  Sorry for the delay.

That’s an exaggeration, of course, but what I’m really trying to say is that working alone on a project for an extended period of time really sucks the life out of me.  With my busy schedule this term, I’m finding it really hard to find time to work on Inventor IDE.  Next term I’ll be working on it as part of a directed study, and I do have a hard deadline of the end of 2008 for getting built-in assembling fully functional, but progress has been slow.

I got asked about teamwork in an interview with Microsoft’s Photosynth group, so that got me really thinking about team dynamics.  At the very least, on any sizable project, having someone else to bounce ideas off of is a must.  Since for assignments 1 and 2, the professor of the course I’m helping with hasn’t posted my alternate assignments, until I get built-in assembling working and start posting about it widely, I won’t even have many users off of which  to bounce ideas about Inventor IDE.

Beyond that, assuming there’s an actual team, there must be some sort of division of labour such that what needs to get done gets done without losing the members.  I’ve started organizing the team for the next big Code Cortex project, codenamed PwnOS, and it’s interesting trying to figure out how to split up the work and to keep people interested.  Conveniently, the team came up with a great idea: each person investigates a device protocol and goes through developing support for that device.  It works perfectly, since getting a device to work is one of the really satisfying parts of OS development, and it only depends on having as much of a bootloader as I’ve already got.  I can then focus on getting some of the other parts of the OS up and running without everyone waiting for me.

Other good news includes that I’ve found someone quite eager to get a third (unnamed) project off the ground, and I may have found another person to help with Inventor IDE next term.  It’ll take lots of work to get things going, but I’m optimistic that we can find a way to make things work, together.

So how did I do on that agenda I listed for August?  This is what got done for Inventor IDE Alpha 4:

• Layout problems fixed
• Enough support for external includes for COMP 2003, but it still needs some work for the future
• The first two videos of the video tutorial are out, with the rest coming over the next few weeks (It turned out that they weren’t needed immediately.)
• Most auto-complete cases handled
• Slightly more go-to-definition support
• Tons of bugs fixed

That means that the next thing on the agenda (other than more tutorial videos) is built-in assembling.  I can’t wait until I can just hit a “run” button and have the thing compile and run.  Check out the assembly language video tutorial at ShowMeDo, and be sure to post any questions or comments about it or Inventor IDE on the forum I’ve just set up.

Don’t worry, no damage done to the code… though I suppose there could have been if I wasn’t careful. Then what am I talking about when I say catastrophic? Well, as always, complexity came back to bite me, whereby a bug of the following type occurs in the development version of Inventor IDE (and probably Alpha 3 and earlier too).

• A common operation doesn’t work properly. (e.g. in this case, dragging text or pasting text will cause it in certain cases)
• Any further operations by the user to fix the invalid result of the failed operation will not work. (e.g. in this case, even typing is unreliable after the bug occurs)
• Some further operations by the user to fix the problem make the problem worse or different. (e.g. in this case, deleting anything in global scope deletes the object but doesn’t remove the object’s representation from the UI or update any references to the object)
• The only indication the user has that there is a bug is that things are going horribly wrong. (unless they can see the stack traces mounting in the optional console when running a JAR file)

The bug in this case involves a few operations involving editing text containing line labels (very common in assembly). In order to support refactoring of line labels in the code, I’ve got a bunch of special cases, and it seems that once again, they don’t handle every case. That’s right, I’ve had bugs with them before, including one I knew about but haven’t fixed yet because it wasn’t as serious or common as the many other problems (it was that swapping two adjacent line labels didn’t work).

This isn’t something easy to ignore either, because both C/C++ and Java have line labels, and more importantly, refactoring of local variables not at the top of a function in C/C++ and Java will need to work almost the same way as refactoring of line labels. This time, I’ll try to find a simpler solution that could be applied to any sort of declaration on a line.

It does set back some of what I was hoping to do by September 4th, but I’ll still at least finish what I really had to get done. Thankfully, that layout problem is almost completely fixed after a lot of work.