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.
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.