4 ms·
A lot of this is in the category of "not-entirely random guess" :) .. need to dig deeper to see this. Here is why I said what I did (and I did mean the former)
by sriku 12y ago
A lot of this is in the category of "not-entirely random guess" :) .. need to dig deeper to see this.
Here is why I said what I did (and I did mean the former) --
My micro-benchmark is actually comparing the struct-based code in Swift with primitive-based code in C. If "k += j % 7" is to be interpreted literally in Swift sans optimization, it would be two function calls and two stack word copies (structs go on the stack and by copy, whereas classes go on the heap and by reference). k and j are both structs and so operator overloading is needed to write this expression. That the Swift compiler generates comparable-to-C performance in these cases is good news I think.
One major caveat with these benchmarks is that the same LLVM backend is being used for both. I'd like to be able to compare Swift with C/ObjC as compiled by GCC as well for a truer picture of "faster than C".
For practical purposes, I think this is nicely close. I haven't tried the ObjC bridge yet though.