I feel very honored to receive
the ITU Teaching Prize this year.
As part of the award ceremony at
ITU, I gave a brief presentation on what I teach to the general public. For
this month’s blog post, I decided to share what I talked about during that
presentation. The slides associated with this talk can be found here.
This post is almost the same as my narration during the talk. I just elaborate
a bit more here on some topics.
I work in a sub-field of computer
science called systems. I love this field and feel very happy that I get
to teach it.
What do we mean by systems?
I tend to work with
data-intensive systems, which are systems that deal with storing, managing, and
processing data. Therefore, I have my bias in my definition of systems.
A computer system is composed of
layers.
At the bottom, we have the
hardware, which could be the devices you use to store data or processors to
compute insights from your data.
Next, we have the operating
system layer like Linux, Windows …, whichever is your favorite, that helps us
manage the hardware resources as we run several applications on top of that
hardware.
Then, we have the frameworks that
help us build applications. Especially here my bias comes into play because the
framework examples I have are all related to data-intensive systems. These
frameworks can be database systems like PostgreSQL, big data processing
platforms like Apache Spark, or machine learning frameworks like TensorFlow and
PyTorch.
Finally, we have the applications.
The systems field deals with
building the layers underneath the applications to support those applications.
In my research, more
specifically, I look at how these systems perform and whether we can improve this
performance, because sub-optimal performance means you are paying a higher cost
for something than you should. This cost could be money, time, energy, carbon
footprint …, and usually these costs are all inter-linked.
Understanding the performance of
a system often feels like being the doctor of a computer system to me. You do
tests, collect a lot of data, and try to understand if there is something wrong
with the system. For example, a thing we commonly do is to break down the
execution cycles of a data-intensive system. The high-level breakdown could be
as simple as categorizing the cycles that are busy, meaning your
processor is actually doing something, or stalled, where your processor
is waiting idly. If you notice a lot of stall time, then you may want to break
down these stall cycles to understand where they come from. For example, they
could be because of the complex code you have to execute in the system leading
to many instruction cache misses. Then, the next question to ask may be “where
do these problematic instructions come from?” and we go on like this to
identify the issue and how to fix it.
To know how to investigate a system’s performance and come up with solutions to improve it, there are three key things to know.
- How to devise a methodology to design experiments so that you can investigate the system’s performance,
- The toolset to run the necessary experiments and collect the results, and
- At least a basic understanding of the systems layers, even if you aren’t an expert in all of them, to be able to interpret your results and come up with solutions.
This is essentially what I teach.
Before I conclude, I also would
like to touch upon diversity.
It is not news that women are
underrepresented in computer science, and systems is among the sub-fields,
where the female representation is consistently under the computer science
average.[1]
I am just one data point in the reported statistics, which sometimes feels like
an over-simplification of my personal experiences in the field. I also acknowledge
that this is a binary view on diversity, so I will try to talk about things in
more general terms.
When I started my PhD, there was,
and to some extent there still is, this stereotype of a successful systems
person:
A successful systems person walks
with a bravado, gives the impression that they already knew all the systems
layers well when they were born, writes code for fun in their free time, and
always has strong opinions, which they aggressively present to the world.
If you fit into this stereotype,
it is perfectly fine, there is nothing wrong with that, and I am not here to
judge. But if this stereotype is the only thing that we keep putting on the
pedestal or creating a cult around, it will always be hard to reach a more
diverse pool of talent.
I questioned my place in this
field throughout my PhD due to this stereotype even though I loved systems
research. This was partially because, early in my PhD, some of the more senior
researchers, who could more easily fit into that stereotype, implied that I might
not have what it takes to become a successful systems researcher. Luckily, I
also had interactions with other senior people who chose to encourage me
instead.
Now I am in a senior position,
and I am well-aware that I have the power to both enforce that stereotype and
break it, especially through my teaching. Thus, one of the things that I emphasize
in my interactions with students is that everyone can learn computer systems as
long as they are willing to learn and have the time. This is probably true for
any topic you wish to learn anyway.
To conclude, I am really thankful
to receive this award, and there are many I want to thank.
When I was in high school, once
our literature teacher asked us to write an acknowledgements letter, and I
wrote 12 pages.
But I will keep things brief here.
I would like to thank DIAS lab at
EPFL, where I did my PhD, for giving me a safe environment to become a systems
person.
I would like to thank my colleagues
at ITU in general, and at DASYA lab in particular, for a supportive environment
and helping me grow as an academic and a systems person.
I would like to thank Peter
Sestoft for nominating me for this award in the first place.
Finally, I would like to thank all
the students whom I had the privilege to teach. I know I am here to teach you,
but I also learn from you all the time, and I really appreciate that.
