TL;DR I have 3 possible thesis subjects all involving CUDA: Developing a methodology for rewriting applications where around 50% of the code ends up on the gpu. Making a table of things to study about CUDA and in which order and how much when you have to take part in a commercial project. Comparing CUDA and Tensorflow in a non machine learning task. The first feels a weak subject, second a little stronger, the last one solid. But what do you think?
Due to the fact that my supervisor is currently unavailable and will be such for some time, I thought I’d ask feedback from a wider audience.
I have currently thought of 3 possible subjects for my master’s thesis, from which 2 feel a bit weak and one feels more solid. However please correct me if I’m wrong.
Since I have been involved in a CUDA project for the past 9 months where we port SAR algorithms to the GPU from the ESA SNAP, then an idea was to try to write down a methodology for porting code into big kernels. It feels like that we need to send around 50% of the original code to the GPU. Considering that during this project and a few shorter ones before I’ve ported a number of algorithms to CUDA, then this made sense, as it should create some habits.
However closer inspection revealed that it’s mostly about mixing functions with same loop iteration counts, which I managed to write down in less than an A4. Everything else is fine grade tuning which I can read from official NVIDIA sources. Does not feel like a deep subject. Perhaps if I had the experience of a senior developer, then perhaps, I could come up with more.
The second idea was about a question that I so far have not been able to answer, but would like to. If a new person comes to work for us and we want to include said person in a CUDA project, but naturally there isn’t a lot of funds for preparation time, then what should they learn to be able to successfully take part in the project? Let’s say that they have 5 workdays. Also what more can they learn and how much would they benefit from it?
The idea started from the fact that I know only the basic techniques for writing CUDA and I can produce reasonable results. However as I have been reading various materials my skills are imporving and so are my results, but as practice has shown, all those new skills are not essential to produce results that make your client happy. I have doubts for this subject, as it will most likely be too subjective and I don’t have something like a testgroup. However if I could produce a table on the subject, then that would be of practical use.
The third idea comes from the fact that my colleague insisted that writing SAR algorithms on Tensorflow is faster because it already has a vast math library that has all of the needed math functions. Just wire them together. He works on the same project as I do and he wrote his algorithm using Tensorflow. However as practice has shown, he greatly underestimated the complexity of porting SAR algorithms to the gpu and honestly it feels that there has been no victory in development time. It might even be slower to write on Tensorflow, but there is no objective way to know. However the subject of which is faster and by how much and under what conditions is still open and we don’t know. Answering this question would mean me writing his algorithm into CUDA and comparing the 2. This will take time, but I can afford that. This seems the most solid, as all of the comparisons I’ve seen so far are about machine learning capabilities and it would yield concrete results of what people should do or not do and under which conditions.
So these are my current thoughts. I’ve you’ve read this far I thank you already and will thank you again if you leave some feedback :)
Exactly how unavailable is your supervisor? Can they be reached by phone, email, physical letter?
Different institutions have different ideas about what is required of a master’s thesis, e.g. how “research-y” it has to be, whether software or hardware implementation work is a requirement. I did my thesis work a long time ago, but as I recall it was highly desirable that potential thesis topics were aligned with and relevant to the research interests of the supervisor, and in many cases the topics were in fact suggested by the supervisor.
So I see no alternative to communicating with your supervisor to hash this out, even if that conversation cannot happen in person right now. I don’t see how random people on the internet would be able to guide you appropriately.
The CUDA course here can be covered in 5 days (2 hours lecture, 1 hour “lab” i.e. homework, each morning and each afternoon). As a handy feature, it leaves Friday afternoon open for a beer party.
When I did my Master’s work, my supervisor (Mike Savic RIP) said “here - this is what you’re doing” and I said “OK”. Turns out it was working on a neural network to detect the sound of breaking glass in a noisy background. Given that it was 1988, there is no way I could have picked a better topic.
After speaking to another teacher who I know, I got the feeling that my supervisor might be dealing with personal issues, so I went into a completely independent mode after that.
I’m not asking for random people to guide me through my work, I’m asking for random people who know about CUDA to bounce some ideas, so I could find my focus. To get a start. From there I usually can find my way. Besides, CUDA is not a skill my supervisor has, so I thought that perhaps I’d find experts here, who have a more clearer view of the situation. And as for the fact that I earn a living with this, I find it difficult to make up a research question, because I don’t feel that I’m short of anything.
You see in our university’s Computer science department, you can get a subject from you teacher, or if you want to do your thesis in a very specific area(like CUDA), you need to come up with it yourself. The latter seems to be encouraged. This also involves finding a supervisor. Since no one there knows anything about CUDA, I just asked one who is good with algorithms and he said yes. The deal in this case is that he guides me through all of the formal stuff and helps evaluate the results, but the work is my burden to bear.
How researchy does it have to be? Not all that much actually: The focus is producing a solution to your question that other people can use too. And you have to explain why is it useful and exactly how to do it and that it is new. It can be a completely new thing never seen before or an upgrade to something already existing.
Thanks for that course. I’ll keep this link around. I guess that scratches option nr 2.
As a random person on the internet who knows a bit about CUDA but nothing about Tensorflow my two cents would be that feasibility studies with measurable and reproducible performance results based on prototype implementation that can be compared to published results are useful, both to the student and others.
On the upside: you will likely learn a lot both in terms of domain knowledge and practical implementation skill. On the downside: expect many months of backbreaking work.
My own thesis work was mostly a DES implementation (ECB mode only) on a Xilinx FPGA. I did that at an institute for system security and picked this topic from a list of about five suggested topics provided by supervisor. Although introduced some years prior, FPGAs were cutting edge technology at the time with people still exploring all kind of new application areas. There had been about a dozen or so DES implementations in both software and ASICs that had been disclosed in publications, including performance data.
While doing this work, I made contact with two or three other students around the world via internet newsgroups who were attempting more or less the same thing in more or less the same time frame, so clearly there was an interest in finding out whether FPGA implementation was feasible, and if so, what performance could be achieved.
I did eventually manage to fit my design into the FPGA using only automated place & route tools (no hand placement, no pre-routing), running at a frequency of about 13 MHz, which delivered reasonably competitive performance compared to published performance numbers.
In order to accomplish this, I pulled 60-hour weeks at the institute for about seven months straight. I went through no fewer than three different toolchains, all with their own set of issues waiting to be discovered. There have been only a few other instances in my life since then where I had to work this hard.