Saw this earlier in Swift forum too. It demonstrate that performant Swift code is possible, but with a lot of profiling. I initially choose to use Swift in hope of better performance characteristics than Python (for some pretty heavy data preprocessing prior feeding to neural nets), but at the end, writing some simple code still 2~3x slower than in C / C++ if not more.
Hopefully at some point when Swift matures, people can start to optimize the generated code more.
Sounds like you got exactly what you wanted, faster than python but safer than c/c++.
There isn't a free lunch here. Even with eye-watering amounts of engineering into optimizer and runtime etc., you aren't going to match c performance in general any more than JVM or .NET has, for much the same reasons.
In some languages (Swift is one) you have the option of writing c-like code that performs similarly, but you can't have your cake and eat it, and you shouldn't expect to.
I'm not sure what you were trying to do but Swift can match C quite easily. But the standard library isn't optimised for that use case, so you need to avoid most of it.
Use `UnsafeBuffer` instead of the standard library `String` or `Array`, unsafe mathematical operators (`&*` instead of checked multiplication `*`) and use neither `class` nor existentials (because they involve reference counting and heap allocation).
That leaves you with the same language constructs as C and LLVM compiles it to the same instructions.
Yeah, of course you can. But at that point, it stops being the idiomatic Swift language. My original post is not a critic for the slowness of the language. It does (like the other post mentioned) better than Python which is what I set out to do.
I do think Swift can do better though, especially with ownership so that most of refcount'ed classes can be migrated to struct and still retain most of the easiness when just use these. The standard library probably can be optimized further so the idiomatic array can be sufficient for the author's case when it can etc etc.
But I wouldn't hold my breath. I was hoping it would come with the Concurrency proposal (which will likely fill the next year of major features in Swift) but they've decoupled the two. My guess is Ownership is 2-3 years away.
So your initial idea was to replace Python with a faster language, you then did that by rewriting the code in Swift, but are eventually disappointed that the code is slower than C/C++? Why not write C/C++ in the first place if you need its performance?
It is pretty well known that Swift, an inherently safer/easier language than C/C++ that does automatic reference counting cannot compete with fine-tuned C/C++.
Did you not achieve your initial goal of getting something that is faster than Python?
Hopefully at some point when Swift matures, people can start to optimize the generated code more.