Swift's ARC implementation has a little bit of performance catchup to do in regards to tracing GCs.
IMO this example should be taken with a grain of salt, since at a cursory glance it looks like they are leaning heavily on reference-types, which is not really idiomatic swift, and is a worst-case for tightly-looping code which this is. I would love to spend even a half hour trying to optimize this code to see what the results could be, but there is specialized hardware required to run the benchmark, so it's not really practical for 3rd parties to attempt to achieve a better result.
It's fair to say that ARC has performance issues, but the story is a bit more complex than that. By relying heavily on value types, it's possible to write Swift code which carries very little ARC cost (although there are additional issues with copy-on-write performance). Also ARC is more memory efficient than most GC solutions, so there are tradeoffs involved.
Languages with tracing GC implementations also have value types, thus they would keep winning.
Top performance reference counting implementations are tracing GC in disguise.
what about kotlin native https://kotlinlang.org/docs/reference/native-overview.html ?
Re:Lightweight API Design in Swift
by singularity2001 on Tuesday November 26, 2019 @05:59AM
(#21637198)
Kotlinc takes 10 seconds to compile Hello World, 30 seconds with wasm target. Seems almost conceptually unfixable.
swiftc isn't also not that blazing fast.
For me Delphi, .NET Native, D are some of the targets to beat in compilation time.
They all share a common trait though, not built on top of LLVM.
I would say Rust is a better point of comparison for Swift given the emphasis both languages have on strong type systems and static analysis. Neither one is super fast, but 10 seconds for a hello world is insanely slow.
And both are slowed down by LLVM.
F#, Standard ML, OCaml and Haskell also have such strong type systems.
Re:Lightweight API Design in Swift
by jbverschoor on Thursday November 28, 2019 @01:20PM
(#21659246)
Swift was out before kotlin.
To me personally though the showstopper for Kotlin is that it runs on Java VM. That was the design goal of course, i.e. to become a major "upgrade" of Java esp. on Android. Java VM (with its GC) is a creation of the pre-mobile era when all we had was desktop computers, ever growing processing power and an assumption that you have infinite supply of electric power. It's a different philosophy and design. I think Google's choice of using it on a mobile platform was unfortunate, though at the time (i.e. before the iPhone) many popular mobile platforms did run on Java VM so it seemed like a natural choice.