Mar 05

Print this Post

The Day after the Hackathon – Time for a First Summary


What a week! The good news first: All teams left happy and have achieved their set goals. Some by far overachieved them, some left with more homework than others.

This was by far the most extraordinary and unusual event that I have organized so far. Time for a view thoughts:

  • Such an intense work atmosphere! I have never seen such a focussed and positive group of people in what is essentially a training. People stayed until they were kicked out as the computer labs were locked up at night and they were there again in the morning. Teams were always busy doing something, be it actual coding or discussing implementation strategies, performance measurements or learning the next piece of necessary information.
  • In my opinion these hackathons work and are by far the best training I have seen so far is due to the following key features:
    • Teams are working with their own codes from day 1. The hackathons do not bother teams with hello world examples, the teams work with what they care about most – their own applications.
    • Teams are preparing their codes before coming to the hackathon. After teams hear of their selection, they immediately receive homework to prepare their code for the hackathon. This includes becoming familiar with the used compute resources, having the application running on the resources and initial profiling. As a result no time of the actual hackathon is wasted with solving ssh or compile problems and by mid-Monday the teams have a clear plan what they want to accomplish until Friday.
    • Teams are required to have at least three team members. This equation is quite simple – the larger the team, the more you get done (and can even tackle really large legacy applications). Also, work division is much easier with more team members.
    • Every team has (typically) two mentors. The extremely high ration of mentors to hackers is ensuring that every team has always someone to talk to. It also brings in specialists from different domains that can help other teams as well. The high number of mentors actually enable another key feature:
    • (Almost) no central lectures. Since each team has two highly qualified mentors, they can progress at their pace and only learn new stuff when it is helping them in their current state. If a team needs to learn the basics of OpenACC, they will do so with their mentor. At the same time another mentor might teach another team how to work with cuFFT… This team tailored approach makes sure that the teams receive the input they need and not some firehose lectures.
  • What I also learned is that there are two cases when even such an intense week can be challenging:
    • You come with an “organically grown” legacy application where you do not fully understand why things are the way they are, because they were programmed by somebody way before your time. Also when your code is not following at least some basic software engineering best practices (unit tests, modular design, clean interfaces), you will be struggling.
    • You come with a C++ app that you coded like Java. There is nothing wrong with object oriented programming, but… Having tons of objects with attributes just does not go well on a GPU (and it actually also does not go well on a CPU). You will need data structures that offer some form of parallel access and bulk transfers. Without it there is no SIMD parallelism that helps both a GPU and a CPU.

If you were to ask me, if I were to host such an event again: Yes definitely! Maybe next time with even more users from Dresden. Until then, happy programming!

Permanent link to this article: https://gcoe-dresden.de/the-day-after-the-hackathon-time-for-a-first-summary/