3 ms·
Interesting. When you say 'So the compiler is indeed able to keep performance for these small structs on par with primitives', is this based on your experiments
by m_mueller 12y ago
Interesting. When you say 'So the compiler is indeed able to keep performance for these small structs on par with primitives', is this based on your experiments or on some theoretical analysis? If the former that's indeed impressive - I would guess that behind the curtains it uses some kind of macro based approach rather than actually implementing it as a struct where you're always going to have some additional integer ops to calculate addresses? If the latter I don't quite get how you arrive at that conclusion, could you expand?
- sriku 12y agoA 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.