What does "real-time" actually mean, isn't it just "fast"?

No, real-time is about meeting timing deadlines deterministically, not about raw speed. A real-time system is correct only if it produces the right result within a specified time bound, and the property that matters is the worst case, not the average. A system that always responds within 100 microseconds is more "real-time" than one that's usually 10 microseconds but occasionally spikes to 10 milliseconds, because the second one can miss its deadline. So "fast" describes average throughput, while "real-time" describes guaranteed, bounded, predictable timing. This distinction drives the whole engineering approach: instead of optimizing the common case, you bound and verify the worst case, you care about worst-case execution time, bounded interrupt latency, and avoiding anything with unpredictable timing (dynamic allocation, unbounded loops, GC pauses). A slow but perfectly bounded system can be hard-real-time; a blazing-fast but occasionally-stalling system cannot. Conflating real-time with fast is the single most common misconception, and it leads people to optimize the wrong thing.