A particularly cheap way of breaking cycles are simple boolean flags:

class Foo(object):
   listen = True
   def some_method(self):
       self.listen = False
       try:
           # do stuff that triggers some_event
       finally: 
            self.listen = True
 
    def on_some_event(self):
        if not self.listen:
            return
        # handle event normally

Boolean flags are great. They’re simple, they’ll make your code harder and half of the time, you’ll forget to set them to True after you’re done. Or you forget the try...finally... block. Or you forget to check them in the event handler. What could possibly go wrong.

Fortunately, some GUI toolkits provide ways to temporarily disable event handling for specific events, like GObject’s handler_block_by_func. This approach has two problems:

• You have to know the object (or objects) that emits the event.
• It only works for GObject events (signals).

Since I do have classes with their own event handling mechanism, in order to be independent of GObject and since it’s not really difficult to implement, I wanted a cross-event-framework way of temporarily blocking event handling. Or, maybe I just wanted to write another decorator/context manager very badly. Maybe a little bit of both.

class Foo(object):
    def some_method(self):
        with self.on_some_event.suspend():
            # do stuff that triggers some_event
 
    @suspendable
    def on_some_event(self):
        # handle event normally

The event handlers are wrapped inside another method which swallows the event when the context manager is in suspended mode. The code remains blissfully ignorant of threading issues for now and also breaks down if the event handlers have meaningful result values. I’ve never encountered this so far, but adding default return values to the decorator is a simple extension. The methods are still proper bound methods and docstrings etc. are all conserved.

Without further ado, the code:

class Suspender(object):
    def __init__(self):
        self.is_suspended = 0
 
    @contextmanager
    def __call__(self):
        self.is_suspended += 1
        try:
            yield
        finally:
            self.is_suspended -= 1
 
    @classmethod
    def suspendable(cls, meth):
        suspend_manager = cls()
 
        wrapper = suspend_manager.add_suspendable(meth)
        wrapper.suspend = suspend_manager
        wrapper.add_suspendable = suspend_manager.add_suspendable
        return wrapper
 
 
    def add_suspendable(self, meth):
        @wraps(meth)
        def suspended_wrapper(*args):
            if self.is_suspended == 0:
                meth(*args)
 
        return suspended_wrapper
 
suspendable = Suspender.suspendable

It’s possible to have several event handlers block by a single context manager using the add_suspendable decorator added to suspendable methods:

@suspendable
def on_some_event(self): ...
 
@on_some_event.add_suspendable
def on_misc_event(self): ...

Calling the suspend() context manager for on_some_event will also block on_misc_event.

The context manager does not prevent the event from being propagated, so it’s not a speed optimization; due to the added boolean check event + call indirection, handling actually becomes slightly slower. It likely won’t make a difference. If it does, event cycles are the least of your problems.

The slides can be found on the Talks page.

After the bleak, joyless work of releasing software, plugging holes of preventing users from clicking buttons they should not have clicked in the first place, writing unctuous documentation and release notes and wrapping code into neat little installers with tiny bows and bells that gently tingle when touched, there are few things as profoundly satisfying as taking code that looked like line noise in the first place, applying some non-trivial transformation to it and still have it look like line noise, only now it’s twice as fast, or half as long or of some other inaccessible quality that can, on some technical level, be referred to as “cool”.

Quite some time ago, I decided that this time, “cool” will mean “runs on graphics hardware, possibly faster”. For this end, I took my trusty T61 to work, downloaded the latest CUDA toolkit, found out that nearly all examples crashed when compiled, installed the latest beta drivers from NVIDIA, noticed that everything worked now and started playing around with the examples.

After some time marveling at ball pit simulations and similarly telling examples, I printed out the CUDA programming guide and spent a considerable amount of time marveling at how well the NVidia green looked when printed with our institute’s color laser printer, before reading its more important parts.

Technical Details

Roughly said, modern graphics hardware from NVIDIA consists of an array of multiprocessors. Each multiprocessor has eight cores, some shared memory, a controller unit and units for transcendental functions. Kernels (methods that run on the device, as opposed to host code) are automatically distributed to the available multiprocessors (their number depending on the hardware, with as many as 120 on the Tesla cards).

Kernel invocations are organized in 3-dimensional thread blocks and 2-dimensional grids. A single thread block can have at most 512 threads (i.e. x × y × z ⩽ 512) and is always executed by a single multiprocessor. Thread blocks are organized in a grid (with at most 65,536 elements on each dimension), which are distributed to the available multiprocessors, and thus inherently scalable.

A multiprocessor divides the threads of a block into warps and all threads of a single warp are executed in parallel. Optimal performance is reached when the control flow in threads of the same warp does not diverge based on the input data, the cores are optimized to execute the same code in several threads on different data (therefore the name SIMT—Single instruction, multiple thread—for this architecture).

There is also a memory hierarchy, from registers to on-die shared memory to global device memory. Data has to be explicitly copied from the system RAM to device memory, which is costly and should be minimized.

In other words, if you have a computation that has to be executed many, many times on different input data, move it the GPU instead and use the freed CPU cycles for shuffling around the data. In other words, ZOOOOOOM.

Some Experiments

Back in the day, we had to write code for training Gaussian Mixture Models. At the core of the algorithm, an auxiliary vector containing each point in the training set has to be created for each Gaussian. The creation of the auxiliar vector includes exponentiation, which proved to be quite costly, since it accounted for 50% of the running time of the program¹.

Instead of doing comparedly boring optimization work for running that algorithm on a single processor, and even more boring work to have it run on two processors, I partially ported it to have the auxiliary vectors be computed on the GPU, with the result that by moving only this one part of the computation leads to the three-fold speed increase for the whole program.

On my machine (2 GiB RAM, 2.2 GHz Core 2 Duo, NVS 140M with 2 multiprocessors), running the C++-only version² takes 33s for 90,000 points and three Gaussians. Running the computation with the same data set on the GPU takes 11s.

How is it done

In order to invoke a kernel running on the GPU, the code has to be compiled with nvcc, NVIDIA’s compiler for CUDA. It separates device, which is compiled to some binary code, from host code which is transformed and handed over to the platform compiler. Therefore, it is needed to write some intermediate methods which can be called from “normal” C++ and that take care of shuffling data to the device and invoking the kernel methods³:

typedef float PROB;
 
#define BLOCK_SIZE 16
 
Matrix d_in;
Matrix d_out;
 
__device__ __constant__ KernelGaussian d_params[20];
 
extern "C"
void LoadPoints(Matrix in, size_t params) 
{
    d_in.height = in.height;
    d_in.width = in.width;    
    size_t size_in = in.width * in.height * sizeof(PROB);
 
    cutilSafeCall(cudaMalloc((void**) &d_in.elements, size_in));
    cutilSafeCall(cudaMemcpy(d_in.elements, in.elements, size_in, cudaMemcpyHostToDevice));
 
    d_out.width = in.width;
    d_out.height = params;
 
    size_t size_out = d_out.width * d_out.height * sizeof(PROB);
    cudaMalloc((void**) &d_out.elements, size_out);
}
 
__global__ void computeAuxVectors(Matrix in, Matrix out) 
{
    int p = blockIdx.y * BLOCK_SIZE + threadIdx.y;
    KernelGaussian g = d_params[blockIdx.x];
    PROB d = (in.elements[p] - g.mean) / g.stddev;
    out.elements[blockIdx.x * out.width + p] = g.factor * expf(-0.5*d*d);
}
extern "C"
void RunComputeAuxVectors(
        KernelGaussian* g, 
        std::vector<std::vector<PROB> >& out, 
        size_t points, size_t params)
{
    cutilSafeCall(
        cudaMemcpyToSymbol(
          d_params, g, 
          params*sizeof(KernelGaussian), 
          0, cudaMemcpyHostToDevice));
 
    dim3 dimGrid(params, points / BLOCK_SIZE);
    dim3 dimBlock(1, BLOCK_SIZE);
    computeAuxVectors<<<dimGrid, dimBlock>>>(d_in, d_out);
    cutilCheckMsg("Kernel execution failed");
 
    for(size_t i = 0; i < params; ++i) {
        cutilSafeCall(
            cudaMemcpy(
              &out[i][0], &d_out.elements[i * points], 
              sizeof(PROB) * points, 
              cudaMemcpyDeviceToHost));
    }
}

The matrix d_in holds the points, which are constant over the whole computation and therefore copied over to the device exactly once. d_out is the matrix that holds the auxiliary values computed for each point and each Gaussians. For faster retrieval, the Gaussians are stored in constant device memory (d_params), which is set to contain 20 elements at most, i.e. the algorithm is limited to learn mixture models with at most 20 Gaussians.

In the method LoadPoints, device memory is allocated for the points and the output vectors and the points are copied from host to device memory using cudaMemcpy.

The actual invocation of the kernel is done in the host method RunComputeAuxVectors, which first copies the parameters into the constant storage and invokes the kernel computeAuxVectors using the new <<>> syntax. grid holds the dimensions of the grid, which is number of gaussians× points / BLOCK_SIZE. The block size is the width of a thread block and somewhat arbitrarily chosen to be 16⁴, currently this also limits the number of points to be a multiple of 16⁵. After the blocking kernel invocation, the results are copied back into host memory.

Important:

• My card only supports single-precision floats, newer ones also have double-precision
• blockIdx and threadIdx are global variables provided by CUDA compiler
• __global__ methods are run on the device and can be called from both host and device code
• Currently, the device memory for d_in and d_out is never freed, the program simply exits

Results

Working with CUDA is definitely fun (if rewarding), the system itself is quite unforgiving though. Wrapping each invocation of a CUDA method into cutilSafeCall therefore is strongly recommended, in case of an error it will print a (not always helpful) error message and exit. Though in this case the code running on the GPU itself is quite trivial, it can be hard to figure out what is going wrong, because the GPU itself is a black box, and it’s not possible to simply print out a message⁶. It’s possible to emulate the code on the CPU, and there are other tools available which I haven’t tried out.

I’ve also started toying around with my original idea, having the constraint checks for the TIGER query evaluation run on the graphics hardware and initial results are mixed. Still, if nothing at all, this gives me justification to spent a lot of money on expensive graphics hardware for my next computer—it’s all for science, this harsh and demanding mistress.

1. There might be a smart way of getting rid of the exp() call, though I haven’t found it yet
2. compiled using g++ 4.4.0 -O3
3. looking at the SDK examples was quite helpful here
4. I didn’t try out other block sizes
5. this is a restriction of the implementation, one could simply pad the points with however many zeros as needed and compute a little more
6. or maybe it is, and I don’t know how to do it…

Abstract

In the Computational Linguistics community, much work is put into the creation of large, high-quality linguistic resources, often with complex annotation. In order to make these resources accessible to nontechnical audiences, formalisms for searching and filtering are needed.

The TIGER query language can, by describing partial structures, be used to search treebanks with syntactic annotation. Recently, augmented treebanks have been published, including the SALSA corpus which features frame semantic annotation on top of syntactic structure. Query languages, however, need to keep up with newly introduced annotation, allowing it to be searchable and easy to access.

We design an extension for the TIGER language which allows searching for frame structures along with syntactic annotation. To achieve this, the TIGER object model is expanded to include frame semantics, while remaining fully backwards-compatible.

Finally, these extensions have been added to our own implementation of TIGER, which includes novel indexing features not found in the original work of Lezius (2002a).

What does it all mean?

In the most basic sense of all, the TIGER query language allows specification of nodes (which are flat feature structures) and relations between these nodes. So far, only syntactic nodes (words and phrases) and syntactic relations (dominance, precedence and structure sharing) were supported in the query language, while the underlying annotation formalism had been extended to include frame semantics as well. My conservative extension of the query language introduces types and relations for frame semantics. This makes it possible to express linguistic queries such as Find all sentences where the role TOPIC in the frame
STATEMENT is realized by a PP with the preposition “über”, which was not possible previously:

{frame="Statement"} > #r:{role="Topic"} &
#pp:[cat="PP"] >AC [word="über"] &
#r > #pp & arity(#r, 1)

What is cryptically referred to as “novel indexing techniques” are improvements to the candidate selection for relation checks, which now exploits some graph-theoretic notions which can be used as rough filters prior to actual relation checks, which can be quite expensive. All in all, the implementation is generally faster than TIGERSearch (the original implementation by Lezius) for complex queries, for simple queries, it is slower, because our node index is slower.

Can I try it out

A demo system for the original and extended query language is online on the CoLi webservers in Saarbrücken. With regard to features, this is the latest version, since then I committed one bugfix to the query evaluator.

Will you continue work on it?

Hopefully, yes. Current directions of ongoing development include:

• In Progress:
  • Client-side rendering of trees in the query front-end (using the HTML5 canvas)
• Planned:
  • Custom-written node index
  • Relations between graphs and nodes in different graphs

I’m also running some experiments for massively parallel constraint evaluation using GPUs, but that might not lead anywhere and depends on the availabity of special hardware.

Thanks

Again, special thanks go to Martin Lazarov and Armin Schmidt, who both read the full draft version and provided many comments and corrections.

Apart from having mastered a small coding challenge, as it turned out to be, this also gives you greater control over the scrolling itself, like making sure that certain elements are visible, viewport panning etc.

Anyway, especially when using PyGTK, it’s a bit unclear on how to proceed. From the documentation, it somehow gets clear that it has to do with the signal set_scroll_adjustment_signal:

This signal is emitted when a widget of this class is added to a scrolling aware parent, gtk_widget_set_scroll_adjustments() handles the emission. Implementation of this signal is optional.

This is not a signal name, but a signal ID¹ that has to be set in GtkWidgetClass².

Some more documentation reading reveals that you can set this signal by using the set_set_scroll_adjustments_signal method on a widget:

class ScrollableWidget(gtk.DrawingArea):
    __gsignals__ = {
        "set-scroll-adjustments": {
            gobject.SIGNAL_RUN_LAST,
            gobject.TYPE_NONE, (gtk.Adjustment, gtk.Adjustment)),
    }
 
    def __init__(self):
        gtk.DrawingArea.__init__(self)
        self.set_set_scroll_adjustments_signal("set-scroll-adjustments")

It doesn’t really matter how you call the signal as long as it takes two arguments (the horizontal and vertical adjustment). This will make the method set_scroll_adjustments (which you can’t override from within Python) return True when it is called and signal that the widget supports scrolling.

This, however, is only half the way, because the scrollable widget still needs the adjustments handed in via said methods. It’s of course possible to connect to the signal explicitly, but there’s an even more direct way by using action signals.

Action signals are the C programmer’s idea of “generic methods”. In order to create such a signal, it has to have the flag gobject.SIGNAL_ACTION and they are directly connected to a function which is then called on each signal emission. While in C, you have to provide a function pointer, in Python you can just implement functions with a compounded magic name³ and have it called automatically. I haven’t found any documentation on that in the PyGObject or PyGTK docs, only some examples in the web:

class ScrollableWidget(gtk.DrawingArea):
    __gsignals__ = {
        "set-scroll-adjustments": {
            gobject.SIGNAL_RUN_LAST | gobject.SIGNAL_ACTION, 
            gobject.TYPE_NONE, (gtk.Adjustment, gtk.Adjustment)),
    }
 
    def __init__(self):
        gtk.DrawingArea.__init__(self)
        self.set_set_scroll_adjustments_signal("set-scroll-adjustments")
 
    def do_set_scroll_adjustments(self, h_adjustment, v_adjustment):
         # do some useful stuff here, like saving them
         ...

The method being called on emission has to start with do_, following by the signal names with hyphens replaced by underscores.

The adjustment objects can then be configured to one’s own liking to have scroll bars show up or not. However, to know when the user did some scrolling, it’s necessary to listen on some signals:

    def do_set_scroll_adjustments(self, h_adjustment, v_adjustment):
        h_adjustment.connect("value-changed", self._scroll_value_changed)
        self._hadj = h_adjustment
        v_adjustment.connect("value-changed", self._scroll_value_changed)
        self._vadj = v_adjustment

To make the scroll bar show up, modify upper, lower and page_size on the adjustments.

self._hadj.lower = 0
self._hadj.upper = 50
self._hadj.page_size = 10

This tells the scrollbar that the size of the underlying picture (upper - lower) is 50, while the visible size (page_size) is 10.

The page size obviously depends on the current size of the widget, which can be retrieved from the underlying gtk.gdk.Window:

width, height = self.window.get_size()

The current position of the scroll bar is controlled by the property value of the adjustment object and should be in the range [lower .. upper - page_size]. Whenever the property is changed, the value-changed signal is emitted, which we’ve connected to previously, and the widget can be repainted.

If you’re curious, you can also see the whole gloriousness in actual working code.

1. which you usually don’t seen when coding with PyGTK
2. ditto
3. a technique which I thoroughly dislike and should be converted to be used with decorators

• +2 GB RAM (4 GB overall)
• 3G card
• USB Port Replicator
• DisplayPort->DVI converter

Being in Switzerland, I had the choice between CH and US keyboard layout. Since CH is physically the same as the German layout (105 keys), I took it and haven’t really noticed that the keys have different symbols (as far as most of the special characters are concered) printed on that what appears on the screen when I hit them. I should really get Das Keyboard after all.

The X301 is not quite the workhorse the T61 is, which is especially noticeable from graphics speed, although that might be due to an Intel driver being in several different transitions right now. The SSD compensates for that, booting and starting up is a breeze. Fortunately, I don’t have to do much booting these days, because unlike other major graphics hardware creators, Intel’s developers are able to support powersave modes on Linux hardware, both Suspend-to-RAM and Suspend-to-disk.

Everything else works more or less, even the DisplayPort, dutyfully serving my 24″ screen at the university. The pièce de résistance is definitely the 3G card. I had to install it myself, which was quite a bit more involved than what I would have liked, but it worked on the second try. I got myself a prepaid data contract which allows me to surf the net for 3 CHF/h, which is a good complement to free wireless access at most public hotspots in Switzerland, which is due to SWITCH. The wireless became especially hand today, when I was shopping for a new router without having a clue about what’s good. Standing in the Media Markt (yes, this very pillar of the German retail market also metastasised into Switzerland) network hardware aisles browsing the web with a notebook probably didn’t look as superior as doing the same thing with a smartphone, but it helped me finding a router.

What really sets the X301 apart is the weight. I’m quite used to it by now, since I’ve had it for over a month, but it’s usually the first response I get when I hand it over to somebody else. It is, however, very noticeable in direct comparison, and the T61 feels clunky and hugely oversized when I carry it around or use it on my lap. The battery lifetime is okay, usually I get 3h under Linux. There’s probably some more running time to be gotten, but I’m more or less done tweaking the system for now and using it for actual work; or for blogging, emailing and chatting on my nice, new, comfy chair.

Bis dahin also bin ich in Zürich, von der Urbanität her durchaus ein Aufstieg, dafür laufe ich aber deutlich länger als 5 min zum nächsten Karstadt (bzw. der Innenstadt). Das mir nächste Zentrum hat aber neben meinem Arbeitsplatz auch genügend andere Geschäfte zu bieten, sodass sich solche Verluste leichter verschmerzen lassen.

Nach einer dann doch wieder recht hektischen Umzugsphase bin ich seit dem 15. 4. offiziell Assistent an der Universität Zürich (immerhin Nummer 53 im Academic Ranking of World Universities und damit vor allen deutschen Universitäten). Das beinhaltet neben der Lehre (ab dem Herbstsemester) auch Arbeit am TreeAligner) und allem anderen, was mir so einfällt, bisher größtenteils Release-Polishing für die grandiose 1.1, nachdem es eine Version 1.0 nie gab—ein Release-Trick, den sich noch so einige von uns abschauen sollten. Sobald das abgeschlossen ist, dem Plan nach so Mitte Mai, geht es mit voller Kraft auf dem Query-Modul weiter, dazu aber morgen mehr.

In a corpus, the frequency of any word is inversely proportional to its rank.

Translated into less-wordy terms, it means that some words (events) occur very often and many words only occur a few times, or only once.

Zipf’s Law also holds for similar structures like DNA, but the distribution can also be observed in the user reputation of Stack Overflow. The following three graphs contain the reputation (X) and the frequency of this particular reputation value (Y) on log-scaled axes. With increasing normalization, the plot gets more Zipf-like, with the typical long “tails” at the lower end.

If we plot the mass distribution of reputation orderd by decreasing reputation on log-log axes, we get something that looks like the cumulative of an exponential distribution:

On 2009-02-05, the total amount of reputation on Stack Overflow was 8,491,989, and around 15% of the users make up 85% of the reputation (not completely Pareto’s 80-20), with the top user (of 41,082) owning 0.39% of the overall reputation.

For these graphs, I’ve scraped the user overview pages, scraping every single user page would allow for more interesting (and accurate, since inactive users can be removed) statistics, but I’d rather wait for a proper API.