Thesis

Finally, after too many years study­ing at DIKU, I’m about to start on my master’s the­sis. That feels weird.

But I’m still not sure what I want to write about. I’ve got a few ideas, mainly by ask­ing some of the pro­fes­sors I might want as advi­sors if they had any inter­est­ing projects lying around.

So far, this is what I have:

1. Effi­cient inver­sion of huge block-diagonal matri­ces on a CELL processor
2. Multi-threaded imple­men­ta­tion of the C++ STL
3. writ­ing a GPU shader lan­guage, prob­a­bly in a more func­tional style than exist­ing lan­guages, tak­ing advan­tage of the inher­ently side-effects-free platform

The first one is based on a project I did last year. It was fun, and there’s still plenty left to do. The algo­rithm may sound dull (matrix inver­sion?), but the fun part is imple­ment­ing it on a CELL, and the algo­rithm has a lot of steps that are chal­leng­ing to imple­ment effi­ciently on the hard­ware. Work­ing with a CELL is inter­est­ing, and since I’ve done it before, I can get started rel­a­tively quickly, side­step­ping all the begin­ners’ trou­ble fig­ur­ing out how to pro­gram the mon­ster. So that’s def­i­nitely an option. On the down­side, it’s, well, stuff I’ve done before, more or less.

The sec­ond sounds like a blast, to be hon­est. It could be a lot of fun. Unlike the CELL project, I wouldn’t have to worry about weird hard­ware lim­i­ta­tions, but can instead focus on crazy C++ tem­plates and generic pro­gram­ming. I still have to fig­ure out a spe­cific angle on it though. Sim­ply imple­ment­ing mul­ti­threaded ver­sions of the func­tions in the algorithm header is obvi­ous, but has been done already. Imple­ment­ing the con­tain­ers with mul­ti­thread­ing in mind might be inter­est­ing, but then the prob­lem is no longer that of auto­mat­i­cally par­al­leliz­ing code (which is fun), but rather that of ensur­ing our code is thread-safe (which is… less fun). A third option might be to use such a par­al­lel STL imple­men­ta­tion to solve some problem.

The third one is a pet project I got the idea for a year or so ago. I’m still not sure about it. I think the basic idea is good, and it could be fun, (and would be rel­e­vant if I want to get into the games indus­try after I grad­u­ate) but there are a lot of unknowns involved:

• I’m not exactly a hard­core com­piler writer. I’ve taken both the basic and advanced com­piler courses at uni, and passed them with good grades and with­out too much trou­ble, but all the more the­o­ret­i­cal courses about par­tial eval­u­a­tion, big-step seman­tics and other fancy the­ory just leave me cold. I doubt any of that will be nec­es­sary, but.… is it a risk I want to take on my thesis?
• GPUs have a lot of unusual hard­ware char­ac­ter­is­tics I’ll have to deal with — first of course, that they are inher­ently SIMD instruc­tion sets, sec­ond that there is very lit­tle sup­port for branch/jump instruc­tions, a fixed num­ber of reg­is­ters and no mem­ory you can spill into. Writ­ing a com­piler for that seems
• It’ll most likely have to tar­get one of the exist­ing shader lan­guages (Cg, GLSL, HLSL). Is that prac­ti­cal? How should it inter­face with OpenGL/Direct3D, if it were to be use­ful in practice?
• It seems like a lot of work…

So yeah, the last one has a cer­tain attrac­tion in that it’s my idea, where the oth­ers are sug­ges­tions I’ve been given, but it’s also scary as hell. And like I said, the two first sug­ges­tions are great fun too.

What to do? I’ll have to decide in a cou­ple of days. I don’t want to wait any longer before start­ing on it.

Tags: c++, cell, compiler, diku, shaders, stl, thesis

Programming | RSS 2.0 | Respond | Trackback |