The Swifty Future of Foundation

Claims that Swift ( or Java or C# or whatever ) implementations of particular feature are
faster than equivalent C implementation just don’t make sense given that Swift itself is written in C++.
It is pretty much always case of comparing some kind of inferior algorithm implementation to something more optimized algorithimically.

@Walter I haven’t seen exactly what they are comparing here, but in the case of Calendar I think the algorithmic stuff is in ICU in both cases, so it may be that there is less overhead calling from Swift, e.g. because they can just pass in the pointer to a Swift String’s UTF-8 storage instead of transcoding a CFStringRef.

@Walter:
"Claims that Swift ( or Java or C# or whatever ) implementations of particular feature are faster than equivalent C implementation just don’t make sense given that Swift itself is written in C++."

That argument doesn't make sense to me. Even if Swift compiler were written in Python, and that wouldn't affect the performance of the compiled code.

(I don't actually think that Swift compiles to noticeable faster code than C. However, in theory it could happen that some Swift language constructs are difficult to map to C, and that results in slowdowns when you try to express some behavior in C. More likely, as @Michael notes, the actual advantage is that impedance mismatches are avoided at interfaces.)

Also, the C++ aspect of the Swift toolchain has little relevance here: the Swift compiler may be overwhelmingly in C++ (and LLVM entirely so, of course), but this is beside the point as those don't run as part of the benchmark (e.g. in cross-compilation they run on the build machine, not the target).

The Swift standard library, on the other hand, is implemented in Swift. Well, a Swift dialect that has access to raw memory arrays and other facilities (not entirely unlike unsafe Rust), but you get the drift.

Many libraries, including CryptoKit, (a large part of) Foundation, Combine, are not related to system API directly. Apple has open-source version of them but uses another close one on their platforms (Combine is not open-source, but there's https://github.com/OpenCombine/OpenCombine). While Microsoft chooses to use the same new .NET Core implementation across Windows, Linux, macOS, etc.

And if they want, SwiftUI can also be open-sourced to leverage public AppKit/UIKit API. I think Windows's new WinUI 3 goes such approach.

@Daveed @Pierre I imagine that @Walter was referring to the fact that the Swift runtime is implemented in C++.

Thanks, I thought the C++ parts of the runtime were limited to things like ARC and hadn’t noticed that such a significant part of the Swift core library (to top it off, it’s a language that heavily blurs the distinction between core language features and standard library functionality) was in C++; possibly because that code hasn’t shown much in my profiling (a lot of this functionality is also implemented in the compiler so it can be and often is emitted inline and then subject to optimizations). Maybe that’s what they ought to rewrite in Swift first, instead of subjecting non-Swift programs to transitively including the Swift libraries through Foundation…

As usual, the language is carefully confusing in order to make Swift look good.

" is 1.5x to 18x as fast as the C one (calling from Swift in various synthetic benchmarks like creation, date calculation)"

This looks like the Swift implementation is 1.5x to 18x as fast as the C one. But wait, what's that in parentheses?

"calling from Swift"

Of course putting that in parentheses deliberately makes it look like that's a minor, irrelevant detail. But I bet it's not. I am quite certain that the new Swift implementation is 1.5x to 18x as fast *only* when calling from Swift, because any material speed advantage will come exclusively from eliminating bridging.

@Marcel Yep, though I doubt that they are trying to be confusing. I mean, the context of the announcement is “no longer pays conversion costs.” Swift created the problem and then solved it by rewriting the stuff it touched. Still, it’s good news compared with the status quo.