..

Master's Thesis + knowledge yap

how I pivoted from embedded systems to high performance computing


Evaluating Rust’s viability for HPC applications – GitHubReport


I’m not going to comment much on the actual work, only briefly describe it. Instead, I want to focus on how I applied knowledge from another field of computing to a brand new, unfamiliar one.


The idea behind this project was to evaluate Rust’s capabilities when it comes to shared-memory parallelism. We took as reference an existing Monte-Carlo particle transport proxy-app and I ported it to Rust. Aside from obliterating the original performance-wise (disclaimer: it was C-style C++), we made interesting observations on Rust’s ecosystem and stricter compilation rules, and how it creates a more agreeable programming pipeline.

The most important takeaway is probably the methodology used for the implementation. Rust gives the necessary tools to approach the problem iteratively: your first roll should focus on algorithmic correctness; once the first results are secured, ensuring correctness from one refactor to the other is trivial thanks to the language’s features.

It just works.


I should probably give a little background before I start talking about skills and how to transpose knowledge. This work was realized as part of my end-of-study internship. It was my first experience programming in a professional setting. Keep in mind the setting leaned closer to academia than industry though.

Going into this, I only had knowledge from the courses I attended in my school. I was trained in embedded systems and cybersecurity. I will skip going over the latter since I didn’t get to use much of what I learned there. My embedded systems courses covered material from software to hardware, including CMOS transistors and HDL usage. I walked into this internship with knowledge about how computers work at the lowest level, not knowing much about concurrency besides the basics: POSIX threads, synchronization primitives, rudimentary scheduling.

Knowing how computers fundamentally work is a massive advantage for systems programming. You might think “duh, it’s basically required”, and I agree; yet, slopware is being written this very moment because some people don’t (want to) understand that. The reason I emphasize the importance of low-level knowledge is not to advocate for any form of elitism (yet), but to introduce my main point:

There is no such thing as "transposed knowledge", only common components which therefore apply to a multitude of domains.

Let me develop a bit on this. The idea is to not think of knowledge / skills / data as containerized slots with very limited, predefined links between them. Instead, see all of those as folders stored in your drawer. Every time you interact with a given subject where some skills might apply, you get to pull out a few folders and mess with them. Trash some of what you previously wrote, add new lines, improve the accuracy of existing notes…

At some point, you have enough folders with enough content in each to start discerning common attributes and reccuring patterns. This is where the supposedly “transposed knowledge” is found.

If I come back to my original case, my point stands: I did not magically transmute embedded systems concepts to high performance computing. I simply identified (unconsciously at the time) useful ideas that happen to also apply in my new domain. I thought about the cost of operation from an instruction perspective, common hazards in execution, and locality of reference.

And then, there’s the most important part, which I still do to this day: I shut up and listen when extremely competent people talk near me. This is the “open your folder and write” part of the process. Having access to specialists in their domain is comparable to a cheat code in a video game. You get to bootstrap your understanding of said domains, for the price of being silent every once in a while. This is how you fill your drawers. This is how you get to the point where you can “transpose” knowledge.

I’ll finish with this: you don’t need to fully understand every single new thing before moving on to the next. Accept that your brain can assimilate knowledge at a limited rate, and it needs you to approach the learning process incrementally. Blackbox what you don’t know, research it later. Apply what you know. Repeat.

You may even come back to some subject not realizing your understanding improved over time.