8 ms·

The part of this (really excellent) writeup that caught my attention was this: someone writing a bootloader or firmware can stick to using Swift structs and ha

The part of this (really excellent) writeup that caught my attention was this: someone writing a bootloader or firmware can stick to using Swift structs and have a simple guarantee of no dynamic overhead or runtime dependence There seems to be a pretty strong implication here that Swift could be used to write firmware/bootloaders, and other low level constructs - including operating systems. Has anyone worked with Swift yet on that type of project?

sandij 11y ago
‘It’s designed to scale from “hello, world” to an entire operating system.’ https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ https://developer.apple.com/library/ios/documentation/Swift/...
pjmlp 11y ago
"Swift is a successor to both the C and Objective-C languages." https://developer.apple.com/swift/ https://developer.apple.com/swift/ It is only a matter of trying and seeing what might still be missing in terms of toolchain.
mpweiher 11y ago
Except for the minor part that it's not true. The performance variations in Swift are (as of now) much larger and less predictable than the overhead of dynamic messaging in Objective-C, and the latter can always be removed by using IMP-caching or converting to a C function.
- Someone 11y ago
  The claim is not about Swift in general, but of a limited subset of the language: "someone writing a boot loader or firmware can stick to using Swift structs and have a simple guarantee of no dynamic overhead or runtime dependence" Based on what I know about Swift (reading Apple's manual, a tiny bit of experimenting, and decent knowledge about how compilers work), I would expect Swift to compile purely statically, like C, for this case. Performance may still be lower because the compiler is newer, but I wouldn't expect performance variations. And of course, the standard library may not be optimal for this use case. The implementation of strings, for example, may be too dynamic for embedded work.
  - mpweiher 11y ago
    My measurements were also with a limited subsets: integers, floats and arrays. Depending on compiler optimization settings, you get from 30% to 1000x (yes, 3 orders of magnitude!) slower than C. Yes, technically that's not "dynamic" overhead, but from where I stand that's still orders of magnitude more variability and unpredictability (for reasonable values of "predictability") than even byte-coded Smalltalk.
    - mikeash 11y ago
      If you're using arrays, you've departed from the limited subset in question. They're structs on the outside but complicated on the inside.
      - mpweiher 11y ago
        Then that's a design flaw. Oh wait, I know: I'm holding it wrong. Sorry, obviously my fault.
      - mwcampbell 11y ago
        I wonder why the designers of Swift decided to make arrays structs on the outside but complex on the inside. Why not make them objects, i.e. reference types, as in Java and .NET?
        mikeash 11y ago
        Because having collections be value types makes them really nice to work with.
    - bjourne 11y ago
      Unbounded integers are much slower than wrap-around integers that C uses. So, unless you are comparing some kind of Swift int64 type with C ints, you are comparing apples to oranges. The reason is that for every "x + 1" expression, Swift has to ensure that the value doesn't overflow the size of a hardware register. C of course has no such qualms.

sandij 11y ago

‘It’s designed to scale from “hello, world” to an entire operating system.’ https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ https://developer.apple.com/library/ios/documentation/Swift/...

pjmlp 11y ago

"Swift is a successor to both the C and Objective-C languages." https://developer.apple.com/swift/ https://developer.apple.com/swift/ It is only a matter of trying and seeing what might still be missing in terms of toolchain.

mpweiher 11y ago

Except for the minor part that it's not true. The performance variations in Swift are (as of now) much larger and less predictable than the overhead of dynamic messaging in Objective-C, and the latter can always be removed by using IMP-caching or converting to a C function.

Someone 11y ago
The claim is not about Swift in general, but of a limited subset of the language: "someone writing a boot loader or firmware can stick to using Swift structs and have a simple guarantee of no dynamic overhead or runtime dependence" Based on what I know about Swift (reading Apple's manual, a tiny bit of experimenting, and decent knowledge about how compilers work), I would expect Swift to compile purely statically, like C, for this case. Performance may still be lower because the compiler is newer, but I wouldn't expect performance variations. And of course, the standard library may not be optimal for this use case. The implementation of strings, for example, may be too dynamic for embedded work.
- mpweiher 11y ago
  My measurements were also with a limited subsets: integers, floats and arrays. Depending on compiler optimization settings, you get from 30% to 1000x (yes, 3 orders of magnitude!) slower than C. Yes, technically that's not "dynamic" overhead, but from where I stand that's still orders of magnitude more variability and unpredictability (for reasonable values of "predictability") than even byte-coded Smalltalk.
  - mikeash 11y ago
    If you're using arrays, you've departed from the limited subset in question. They're structs on the outside but complicated on the inside.
    - mpweiher 11y ago
      Then that's a design flaw. Oh wait, I know: I'm holding it wrong. Sorry, obviously my fault.
    - mwcampbell 11y ago
      I wonder why the designers of Swift decided to make arrays structs on the outside but complex on the inside. Why not make them objects, i.e. reference types, as in Java and .NET?
      - mikeash 11y ago
        Because having collections be value types makes them really nice to work with.
  - bjourne 11y ago
    Unbounded integers are much slower than wrap-around integers that C uses. So, unless you are comparing some kind of Swift int64 type with C ints, you are comparing apples to oranges. The reason is that for every "x + 1" expression, Swift has to ensure that the value doesn't overflow the size of a hardware register. C of course has no such qualms.