3 ms·

Swift does not have many free abstractions - what specifically are you referring to? (Also Swift's pervasive atomic refcounting means that typical idiomatic co

Swift does not have many free abstractions - what specifically are you referring to? (Also Swift's pervasive atomic refcounting means that typical idiomatic code often has pretty atrocious performance.)

favorited 10y ago
Keep in mind that Swift's emphasis on value types means that idiomatic code can have very little refcounting. Obviously that's not the case when you're doing iOS/macOS applications, since you're using the ObjC runtime. Refcounting can also be dropped to non-atomic by the optimizer when it can prove that an object hasn't escaped.
- chadaustin 10y ago
  Value types only avoid refcounts if they contain only primitive fields, which is not all that often in interesting code. For example, count the number of atomic refcounts on each iteration of the following loop: // given struct S { var x: [Int] var y: [String] var z: NSView } var array: [S] for element in array { // maybe do something with the NSView } That's three atomic increments and three decrements per loop iteration, as the array entry is copied into element because it can't prove the NSView operation wouldn't cause the array to zero somehow. Given atomic memory operations are some of the most expensive things on a modern CPU, this is brutal, and a place where Rust-style memory ownership would be a big improvement. I haven't seen the optimizer convert atomic refcounts to non-atomic refcounts - do you have an example situation where that happens? (By the way, I think Swift is a delightful language, but the pervasive reference counting threw some cold water on my passion as it means today we're not really close to replacing C/C++/Rust for machine-level performance.)
- mpweiher 10y ago
  That's exactly the point: the optimizer can drop atomicity. All these ref-counts may be optimized away. Or not. The opposite of predictability.
  - pjmlp 10y ago
    That is what profilers are for. Even with pure Assembly, changing between CPU releases can have a big impact due to microcode changes or cache sizes.

favorited 10y ago

Keep in mind that Swift's emphasis on value types means that idiomatic code can have very little refcounting. Obviously that's not the case when you're doing iOS/macOS applications, since you're using the ObjC runtime. Refcounting can also be dropped to non-atomic by the optimizer when it can prove that an object hasn't escaped.

chadaustin 10y ago
Value types only avoid refcounts if they contain only primitive fields, which is not all that often in interesting code. For example, count the number of atomic refcounts on each iteration of the following loop: // given struct S { var x: [Int] var y: [String] var z: NSView } var array: [S] for element in array { // maybe do something with the NSView } That's three atomic increments and three decrements per loop iteration, as the array entry is copied into element because it can't prove the NSView operation wouldn't cause the array to zero somehow. Given atomic memory operations are some of the most expensive things on a modern CPU, this is brutal, and a place where Rust-style memory ownership would be a big improvement. I haven't seen the optimizer convert atomic refcounts to non-atomic refcounts - do you have an example situation where that happens? (By the way, I think Swift is a delightful language, but the pervasive reference counting threw some cold water on my passion as it means today we're not really close to replacing C/C++/Rust for machine-level performance.)
mpweiher 10y ago
That's exactly the point: the optimizer can drop atomicity. All these ref-counts may be optimized away. Or not. The opposite of predictability.
- pjmlp 10y ago
  That is what profilers are for. Even with pure Assembly, changing between CPU releases can have a big impact due to microcode changes or cache sizes.