3 ms·

Yes I've seen that[1] but I think it's premature to extrapolate general conclusions about server engineering from a low-level network driver. Chris Lattner has

Yes I've seen that[1] but I think it's premature to extrapolate general conclusions about server engineering from a low-level network driver. Chris Lattner has noted that Swift will take longer to optimize for cases like low-level systems programming because unlike most languages it was initially designed for generality.[2] What's interesting about Swift on the server is that the super lightweight runtime and lack of a tracing garbage collector hold the potential of much more consistent latency with low memory overhead. And as for reference counting overhead, application-level code is much more likely to be able to take advantage of Swift's preferred functional-esque "value type semantics", which don't suffer from that. [1] https://news.ycombinator.com/item?id=18788069 https://news.ycombinator.com/item?id=18788069 [2] https://developers.slashdot.org/story/17/01/23/085232/slashdots-interview-with-swift-creator-chris-lattner https://developers.slashdot.org/story/17/01/23/085232/slashd...

firethief 8y ago
OCaml is hardly a language specialized for low level network drivers
- abalone 8y ago
  Actually OCaml has low-level memory manipulation features that help like cstruct.[1] Swift isn't currently optimized for the direct manipulation of external device memory. That's solvable, but moreover it's not really something you can extrapolate from to draw conclusions about server applications. [1] https://dsheets.github.io/codoc/cstruct.1.5.0/_build/lib/cstruct/ https://dsheets.github.io/codoc/cstruct.1.5.0/_build/lib/cst...
pjmlp 8y ago
Value type semantics exist in plenty of GC enabled languages, like those from CCC benchmarks, hardly a Swift advantage.
- abalone 8y ago
  Didn't say they weren't. Not sure if you misunderstood my comment. It's a mistake to extrapolate too much about the "reference counting vs tracing GC" question from this one low-level driver benchmark. In fact reading their paper, they don't understand why Swift ARC traffic was so high.[1] They weren't allocating a lot of objects or copying. It's probably just an unoptimized use case or bug, not something fundamental in the memory management model. Swift is still quite young. [1] https://github.com/ixy-languages/ixy.swift/blob/master/performance/README.md https://github.com/ixy-languages/ixy.swift/blob/master/perfo...
  - pjmlp 8y ago
    Check the language report from Mesa/Cedar, which used reference counting with a cycle collector, already back then they weren't that inspiring. The fact that the language designers switched to tracing GC on their further work, namely Modula-2+ and Modula-3. Or that Wirth after his 2nd sabbatical year at Xerox PARC decided for tracing GC on his system programming languages, Finally Microsoft own research, also using tracing GCs. All in all quite telling, where they seen performance gains to be held. Swift's approach makes sense from Objective-C compatibility point of view. Which also made sense given the failure to add a tracing GC while keeping the underlying C semantics. From performance point of view not so much. Having a tracing GC doesn't remove the possibility to have stack allocations, even when they look like heap ones, implement pools or whatever. Unfortunately Java's approach of not having the same type system as older GC enabled systems programming languages created a bad picture of what is actually available out there.
    - abalone 8y ago
      This is not really strong evidence. A analysis from the 80s and a possibly buggy driver benchmark. You’re digging deep. Look, tracing GC has come a long way. I’m not saying it’s unsuitable for servers at all. I’m just excited to see what sidestepping its problems entirely can do for server apps, especially with respect to tail latency and energy efficiency, increasingly salient metrics for services at scale.

firethief 8y ago

OCaml is hardly a language specialized for low level network drivers

abalone 8y ago
Actually OCaml has low-level memory manipulation features that help like cstruct.[1] Swift isn't currently optimized for the direct manipulation of external device memory. That's solvable, but moreover it's not really something you can extrapolate from to draw conclusions about server applications. [1] https://dsheets.github.io/codoc/cstruct.1.5.0/_build/lib/cstruct/ https://dsheets.github.io/codoc/cstruct.1.5.0/_build/lib/cst...

pjmlp 8y ago

Value type semantics exist in plenty of GC enabled languages, like those from CCC benchmarks, hardly a Swift advantage.

abalone 8y ago
Didn't say they weren't. Not sure if you misunderstood my comment. It's a mistake to extrapolate too much about the "reference counting vs tracing GC" question from this one low-level driver benchmark. In fact reading their paper, they don't understand why Swift ARC traffic was so high.[1] They weren't allocating a lot of objects or copying. It's probably just an unoptimized use case or bug, not something fundamental in the memory management model. Swift is still quite young. [1] https://github.com/ixy-languages/ixy.swift/blob/master/performance/README.md https://github.com/ixy-languages/ixy.swift/blob/master/perfo...
- pjmlp 8y ago
  Check the language report from Mesa/Cedar, which used reference counting with a cycle collector, already back then they weren't that inspiring. The fact that the language designers switched to tracing GC on their further work, namely Modula-2+ and Modula-3. Or that Wirth after his 2nd sabbatical year at Xerox PARC decided for tracing GC on his system programming languages, Finally Microsoft own research, also using tracing GCs. All in all quite telling, where they seen performance gains to be held. Swift's approach makes sense from Objective-C compatibility point of view. Which also made sense given the failure to add a tracing GC while keeping the underlying C semantics. From performance point of view not so much. Having a tracing GC doesn't remove the possibility to have stack allocations, even when they look like heap ones, implement pools or whatever. Unfortunately Java's approach of not having the same type system as older GC enabled systems programming languages created a bad picture of what is actually available out there.
  - abalone 8y ago
    This is not really strong evidence. A analysis from the 80s and a possibly buggy driver benchmark. You’re digging deep. Look, tracing GC has come a long way. I’m not saying it’s unsuitable for servers at all. I’m just excited to see what sidestepping its problems entirely can do for server apps, especially with respect to tail latency and energy efficiency, increasingly salient metrics for services at scale.