Mmmm... close.

Three weeks to graduation (well, two plus finals). Still looking for a job. Seems like no one's hiring right now, not a great time to be graduating. Oh well; I'll find something I'm sure, even if it's repair work for a while.

Time is money... if I had time, I'd have money.

Three months since my last post... school's been busy. 5 weeks of classes left (plus one on break), exams, then graduation. Hopefully I'll have found a job by then, but the trail's gone cold. Haven't lost hope, reserving that for December 8th-ish.

Been working on creating my own linux distribution off and on, it's a hassle but a good learning experience. Once I finish I might make a guide. Ever tried to compile gcc in full? Takes f-o-r-e-v-e-r. Thank FSM for package managers.

Looking for a secure way to sync all my bookmarks between machines. Yeah, random thought. Anyway. Not sure if I want to trust del.icio.us, foxmarks, etc. with all of my bookmarks, I'd rather have something less public. I'll figure something out... that, or I'll forget about it for a while. Not that important.

Met Kanwal Rekhi the other day. He's had an eventful life, and during the conversations I came to full realization of who integral he was in the development of technology. Wikipedia doesn't do him justice. Was a pretty amazing experience.

Class in the morning. Bedtime. I'll try to update more often (not that anyone'll notice, I'm sure!)

Algorithm Wiki

Been pretty distracted lately with job searching, but the other day I had the random desire to start up an algorithm wiki. I'd like to have it be a compilation of actual implementations, as opposed to just pseudocode as is on Wikipedia.

http://algowiki.net/

If anyone would like to contribute, please do so.

Java Code Optimization

Update: I now have a greater understanding of this topic, and I may make another post on it sometime to make up for this poorly-informed post. The general point is that knowing how adaptive JIT compilation works can be beneficial. Put code that you know will run many times in its own method and it will be optimized better (depending, of course, on your JIT compiler).

Just another quick word today, this one about writing efficient Java code. I'm sure this is somewhat well-known to some, but I've never actually seen it written anywhere (much less explained in a programming course). However, before I say anything, know that you should always test to make sure it actually yields you better results. Depending on your compiler and JVM, you may or may not see improvement. It also largely depends on your code.

Note that this doesn't just affect Java, it has an effect on many/all JIT (Just In Time) compilers.

Take this bit of code:

    public void func1(){               
        int sum1 = 0;                  // cold
        double sqrtsum1 = 0;           // cold
        for(int i=0; i<10000; i++){    // hot
            sum += i;                  // hot
            sqrtsum += Math.sqrt(i);   // hot
            for(int j=0; j<10000; j++){// very hot
                int sumplusj = j+i;    // very hot
            }                          // very hot
        }                              // hot
    }                                  // cold

Cold means the code is executed very infrequently, while hot code is executed often. Assuming this "func1()" is called very few times, the method as a whole is cold.

The thing to notice is the hot/very hot section in the cold method. Most modern JIT compilers compile/optimize on the method level: if a method is determined to be hot (after it is executed numerous times), it is compiled and optimized. Before that, it's just interpreted, which is much slower.

The issue is having hot code in cold methods. Since the method is cold, it isn't compiled to native and optimized very quickly (if at all). Note that, depending on your specific application and setup, the hot code may not be either - in which case this won't help you.

So what can one do to remedy the situation? Extract hot code into separate methods.

    int sum1 = 0;                      // cold
    double sqrtsum1 = 0;               // cold

    public void func1(){               // cold
        for(int i=0; i<10000; i++){    // cold
            func2(i);                  // hot
        }                              // cold
    }                                  // cold

    public void func2(int i){          // hot
            sum += i;                  // hot
            sqrtsum += Math.sqrt(i);   // hot
            for(int j=0; j<10000; j++){// very hot
                int sumplusj = j+i;    // very hot
            }                          // very hot
    }

Normally one may say "but isn't there a method call overhead that makes it slower?" - if this were C or C++, perhaps. Yes, there is an overhead, but extracting the hot code out of the cold method overcomes that by a large margin.

As for the "very hot" code in the second method, it is debatable as to when to extract that as well. It is my own heuristic that the more operations in the hot section, the more the benefit. With just that one statement, there may not be much benefit (testing would be required to know for sure).

In general though, keep cold code in cold methods and hot code in hot methods. Cursory tests similar to (though more intensive) the above show a performance increase of 200%, but it's largely going to depend on your JIT compiler.

As JIT compilation evolves, this will most likely become less of an issue - I expect that it will rely less on method boundaries in the future. For now though, keep those methods hot.

Changing Things Up

Too much lately I've been working on semi-useless native code, so I think I'll play around with Android for a while.

http://code.google.com/android/
http://code.google.com/android/reference/packages.html

I can't wait to get a phone that runs Android, though I'm sure it'll be a while. Just gives me time to play around with its SDK, right? Right.

XGetWindowAttributes and You

Right at the end of a project I've been working on, I run into a very weird issue. As per the title of this post, it's with XGetWindowAttributes and the XWindowAttributes struct.

Reference page:
XGetWindowAttributes

The main reason I'm looking to use this function is for XWindowAttributes.class, which will tell me if the window I have is InputOutput (visible) or InputOnly (not visible). If there's a simpler way to detect a window's visibility, I couldn't find it.

Anyway, in my coding I have this:

    XWindowAttributes attr;
    XGetWindowAttributes(display, hwnd, &attr);
    if(attr.class == InputOutput){
        [...]
    }else{
        [...]
    }

Looks fine, yes? Well, it won't compile.

error: expected unqualified-id before class
error: expected `)' before class

Some research on the error turns up next to nothing; just a bunch of people saying that switching header include orders fixes it. Didn't fix it for me.

So then I figure, perhaps the documentation is old, and "class" has been removed. Changing "class" to a random string returns a different error, so that's not it. So I looked at the newest documentation I could find - the source. Turns out that it WAS changed, and here it is (abbridged):

typedef struct {
    int x, y;                   /* location of window */
    [...]
    Window root;                /* root of screen containing window */
#if defined(__cplusplus) || defined(c_plusplus)
    int c_class;                /* C++ InputOutput, InputOnly*/
#else
    int class;                  /* InputOutput, InputOnly*/
#endif
    int bit_gravity;            /* one of bit gravity values */
    [...]
    Screen *screen;             /* back pointer to correct screen */
} XWindowAttributes;

As it turns out, my code is C++, and apparently there's a different member for C and C++ (whoever heard of doing that? I fail to see the reasoning - though I'm sure there is some).

Anyway, a simple change of variable name to c_class fixed the errors, and it compiles successfully. Mark another one up for non-deterministic error messages.

Wider Posts!

I've edited the template a little, and now it seems a little less cramped. Of course, I'm on a widescreen so it still looks like text crunched into the middle of the screen, but I tried to keep it at a width of 800px for easy viewing on older machines (sometimes I wish they'd all just burn up and get replaced). Anyway, I checked it on a couple browsers, and it looks fine, but let me know if there's an issue.