3 ms·

I think the optimizations for both need to be looked into carefully. For the following micro benchmark, Swift came in 1.5x slower than the C version. Both were

by sriku 12y ago

I think the optimizations for both need to be looked into carefully. For the following micro benchmark, Swift came in 1.5x slower than the C version. Both were built in Release mode with "-O3", and both with "Debug" checked OFF in their respective schemes. This factor is way smaller than the orders of magnitude being reported by the OP. Can't seem to find OP's benchmark source too. Swift - var j : Int = 0 var k : Int = 0; var i : Int = 0; for (i = 0; i < 1000; i += 1) { k = 0; for (j = 0; j < 1000000; j += 1) { k += j % 7; } } C - int j = 0, k = 0; int i = 0; for (i = 0; i < 1000; ++i) { k = 0; for (j = 0; j < 1000000; ++j) { k += j % 7; } } update: If I use "fastest unchecked" mode when building swift instead of the "fastest" mode, the swift version is 8% faster than the C version. machine: 1.7GHz core i5 macbook air (mid 2011), 4GB RAM. edit: For clarity, "1.5x slower" means "swift took 1.5x the time C took" and "8% faster" means "C took 1.08x the time swift took". edit: To OP - Please put a link to your benchmark source and projects somewhere, or show your project settings as a snapshot or something. For one, I don't believe any of your results based on my own trials. edit: Changed ++i and ++j to i+=1 and j+=1. This is the version that is 8% faster than C. OP seems right in that i+=1 seems faster than ++i. edit: (It's becoming impractical to keep this in sync with my project.) When using Int/int, I get swift 8% faster and when using Int64/int64_t, I get C to be 17% faster.

m_mueller 12y ago
Finally some actual data, thank you! Do you know the functionality behind 'fastest unchecked'? Does it only leave away memory bounds checks or arithmetic overflow checks or all of it? Depending on how it works, Swift could be quite interesting for HPC programming in the future. My dream workflow would be something like create working and correct program with all the comfort of modern languages / IDEs --> switch to unchecked-but-warn (or whatever that's called like), run some test suites and get rid of all warnings. --> switch on highest optimizations and switch off checking, verify results. --> port to multicore / multinode / accelerators using some directive based approach. note that you won't have much safety on todays' accelerators anyways, so removing that safety net when still in an easily debuggable environment is going to make life easier when debugging the accelerated code - it's all about being able to exclude error classes.
- 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 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 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.
ttflee 12y ago
The default optimization level is `Os' (instead of `O3') for iOS projects. Would you please also benchmark the two under -Os option?
- sriku 12y ago
  Here are median values based on a few trial runs with -Os (but I'm still building and running for MacOSX only). Int/int : Swift = 2.7s, ObjC = 3.4s (Swift is 25% faster) Int64/int64_t : Swift = ObjC = 2.7s (indistinguishable) edit: Swift compiler is still building in "fastest unchecked" mode for both.
BruceIV 12y ago
I'm curious what the effect of using the overflow arithmetic operators in Swift would be. (See near bottom of https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html#//apple_ref/doc/uid/TP40014097-CH27-XID_28 https://developer.apple.com/library/prerelease/ios/documenta...)

by sriku 12y ago

m_mueller 12y ago

Finally some actual data, thank you! Do you know the functionality behind 'fastest unchecked'? Does it only leave away memory bounds checks or arithmetic overflow checks or all of it? Depending on how it works, Swift could be quite interesting for HPC programming in the future. My dream workflow would be something like create working and correct program with all the comfort of modern languages / IDEs --> switch to unchecked-but-warn (or whatever that's called like), run some test suites and get rid of all warnings. --> switch on highest optimizations and switch off checking, verify results. --> port to multicore / multinode / accelerators using some directive based approach. note that you won't have much safety on todays' accelerators anyways, so removing that safety net when still in an easily debuggable environment is going to make life easier when debugging the accelerated code - it's all about being able to exclude error classes.

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

ttflee 12y ago

The default optimization level is `Os' (instead of `O3') for iOS projects. Would you please also benchmark the two under -Os option?

sriku 12y ago
Here are median values based on a few trial runs with -Os (but I'm still building and running for MacOSX only). Int/int : Swift = 2.7s, ObjC = 3.4s (Swift is 25% faster) Int64/int64_t : Swift = ObjC = 2.7s (indistinguishable) edit: Swift compiler is still building in "fastest unchecked" mode for both.

BruceIV 12y ago

I'm curious what the effect of using the overflow arithmetic operators in Swift would be. (See near bottom of https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html#//apple_ref/doc/uid/TP40014097-CH27-XID_28 https://developer.apple.com/library/prerelease/ios/documenta...)