That's not a fair characterization of Swift's runtime. Swift is similar to C++ in that it compiles down a lot of stuff so it doesn't need to make runtime decisions.
Swift could theoretically be as fast or faster than C/C++, but C/C++ have decades compiler optimizations that are going to be hard to beat. I say Swift has the potential to be faster because of the pointer aliasing problems of C/C++, which Swift can potentially optimize (like why Fortran still can beat C).
But your question about runtimes and performance are kind of a red herring. High performance means utilizing the underlying hardware well. A lot of the popular modern languages were designed for convenience over speed and were designed in an era of ever-increasing single processor CPU speeds. Very few languages map to how hardware actually works so they give up speed. Few mainstream languages automatically vectorize _well_ and _reliably_ to automatically exploit SIMD (C/C++ don't really do this...we generally have to write the intrinsics ourselves if we care). Few mainstream languages do a good job exploiting the multiple cores/CPUs available to us (don't say threads...they are pretty poor. This is one interesting feature of Go). Cache locality is now extremely important to high performance and most languages don't let us really control this. (C/C++ give us some say on our memory layouts.)
Swift could theoretically be as fast or faster than C/C++, but C/C++ have decades compiler optimizations that are going to be hard to beat. I say Swift has the potential to be faster because of the pointer aliasing problems of C/C++, which Swift can potentially optimize (like why Fortran still can beat C).
But your question about runtimes and performance are kind of a red herring. High performance means utilizing the underlying hardware well. A lot of the popular modern languages were designed for convenience over speed and were designed in an era of ever-increasing single processor CPU speeds. Very few languages map to how hardware actually works so they give up speed. Few mainstream languages automatically vectorize _well_ and _reliably_ to automatically exploit SIMD (C/C++ don't really do this...we generally have to write the intrinsics ourselves if we care). Few mainstream languages do a good job exploiting the multiple cores/CPUs available to us (don't say threads...they are pretty poor. This is one interesting feature of Go). Cache locality is now extremely important to high performance and most languages don't let us really control this. (C/C++ give us some say on our memory layouts.)