3 ms·
> Does it only leave away memory bounds checks or arithmetic overflow checks or all of it? My guess is only arithmetic checks and not array bounds checks. If a
by sriku 12y ago
> Does it only leave away memory bounds checks or arithmetic overflow checks or all of it?
My guess is only arithmetic checks and not array bounds checks. If array bounds checking is removed, the language won't be any safer (security wise) than C, hence I think that's kept through out.
Btw "Int" and "Int64" in Swift are actually "struct"s and not a primitive type like in C. So the compiler is indeed able to keep performance for these small structs on par with primitives. This is promising for swift's claimed speed I think. These structs have extension methods like uncheckedAdd(), uncheckedDivide() and so on, which lends some evidence to my "unchecked refers only to arithmetic" guess.
edit: .. that Int/Int64 are structs means that the + and += are all overloaded operators, compared to the raw operators used in C. Given that, the compiler, I must say, is impressive.
- m_mueller 12y agoInteresting. 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.