Senior C++ — C++-Interviewfragen

Wie beeinflussen Cache Misses die Art, wie du Daten anordnest?

Ein Miss auf den Hauptspeicher kostet in der Größenordnung von ein paar hundert Zyklen, sodass eine theoretisch bessere Datenstruktur klar gegen ein zusammenhängendes Array verlieren kann. Das führt dazu, Daten so anzuordnen, wie sie durchlaufen werden – Structure-of-Arrays, wenn man ein Feld über viele Objekte hinweg anfasst, heiße Felder eng zusammenpacken und Pointer-Chasing in der inneren Schleife vermeiden. False Sharing ist dasselbe Problem umgekehrt: Zwei Threads schreiben in unterschiedliche Variablen derselben Cache-Line und serialisieren sich dadurch gegenseitig, die Lösung ist Padding auf Cache-Line-Größe.

Wann lohnt sich Lock-Free, und was unterscheidet es von Wait-Free?

Lock-Free garantiert, dass irgendein Thread Fortschritt macht; Wait-Free garantiert, dass jeder Thread in einer begrenzten Anzahl Schritte Fortschritt macht. Lock-Free lohnt sich bei echter Contention auf einer kleinen, gut verstandenen Struktur – einer Queue, einem Counter –, wo ein Mutex messbar dominiert. Als Standardansatz lohnt es sich nicht: Der Code ist schwer korrekt zu schreiben, schwer zu testen, und ein gut genutzter Mutex ist im unkonkurrierten Fall schnell – die ehrliche Antwort beginnt also meist mit einer Messung.

Erkläre Memory Ordering bei `std::atomic`.

seq_cst ist die Voreinstellung und liefert eine einzige totale Ordnung über alle Threads hinweg – korrekt und am leichtesten nachzuvollziehen. acquire/release-Paare stellen ein Happens-Before zwischen dem freigebenden Store und dem übernehmenden Load her, genau das macht ein Lock intern, und das reicht für die meisten Producer-Consumer-Muster. relaxed garantiert nur Atomarität, keine Ordnung, und passt zu Dingen wie einem Statistik-Counter. Die Ordnung abzuschwächen ist eine gemessene Optimierung, kein Ausgangspunkt.

Ein Projekt braucht zwanzig Minuten zum Bauen. Wie gehst du das an?

Zuerst messen – welche Translation Units und welche Header dominieren. Dann den Header-Graphen kürzen: Forward Declarations statt Includes, PIMPL für breit eingebundene Klassen und Templates aus Headern herausziehen, wo die Instanziierungskosten wirklich ins Gewicht fallen. Danach kommen die mechanischen Gewinne – Precompiled Headers, ccache, Parallelität, Unity Builds und ein Linker wie lld oder mold. Module lösen das Problem sauber dort, wo die Toolchain dafür bereit ist.

Code ist langsamer, als er sein sollte. Was ist deine Methode?

Ausgehen von einer reproduzierbaren Messung, denn die Intuition zur C++-Performance liegt oft genug falsch, um gefährlich zu sein. Profilen, um herauszufinden, wo die Zeit tatsächlich hingeht, und erst danach den Algorithmus statt Mikrooptimierungen betrachten. Prüfen, was der Optimizer tatsächlich gemacht hat, statt es anzunehmen – der generierte Code beantwortet Fragen, die das Lesen des Quellcodes nicht beantworten kann. Und die Umgebung kontrollieren: Build-Flags, aufgewärmte Caches, Frequency Scaling und Rauschen von anderen Prozessen liefern sonst Zahlen, die nicht real sind.