6 ms·

Swift does not use virtual machine and garbage collection, it competes more to c++ and rust and if Apple is serious about pushing it cross platform that's defin

Swift does not use virtual machine and garbage collection, it competes more to c++ and rust and if Apple is serious about pushing it cross platform that's definitely a welcome move, in fact, I can't wait even though I have never programmed in swift. the main point is that, it's memory safe, and seems much easier to code than rust.

glhaynes 2y ago
Memory safe and, with Swift 6, data race safe.
timeon 2y ago
> Swift does not use virtual machine and garbage collection, it competes more to c++ and rust Doesn't it use ARC by default?
- azinman2 2y ago
  Which is reference counting, not garbage collection. Ref counts free when count = 0. Garbage collection scans all object pointers and looks for loops / no missing pointers.
  - vor_ 2y ago
    Reference counting is a kind of garbage collection.
  - mkl 2y ago
    That's tracing garbage collection. Reference counting is another type of garbage collection. https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Strategies https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...
    - derrasterpunkt 2y ago
      Reference counting is not tracing garbage collection. To also quote a Wikipedia Link: „The main advantage of the reference counting over tracing garbage collection is that objects are reclaimed as soon as they can no longer be referenced, and in an incremental fashion, without long pauses for collection cycles and with clearly defined lifetime of every object.“ + https://en.wikipedia.org/wiki/Reference_counting https://en.wikipedia.org/wiki/Reference_counting
      - vor_ 2y ago
        > Reference counting is not tracing garbage collection. ??? They didn't say it was.
      - mkl 2y ago
        Of course reference counting is not tracing garbage collection. I never said it was. The comment I replied to claimed reference counting was not garbage collection at all and seemed to think tracing garbage collection was the only kind of garbage collection. Reference counting and tracing garbage collection are two different types of garbage collection.
- synergy20 2y ago
  it does, I thought ARC is more performant than GC and has no stop-the-world issue,thus not a GC
  - pebal 2y ago
    ARC is a variation of GC. Besides, a tracing GC doesn't have to stop the world at all.
  - neonsunset 2y ago
    Usually, it's the other way around: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... binary-trees is almost completely dominated by the time spent in allocator code, and stresses its throughput. This benchmark showcases how big of a gap is between manual per-thread arenas, then tracing generational multi-heap GCs, then ARC and more specialized designs like Go GC. Honorable mention goes to BEAM which also showcases excellent throughput by having process-level independent GCs, in this case resembling the behavior of .NET's and OpenJDK GC implementations.
    - astrange 2y ago
      A tree is indeed a bad fit for RC; so is anything else where you have multiple references to something but know there is a single real owner. I'd suggest keeping strong references to all the tree nodes in an array, then having everything within the tree be unowned. Basically fake arena allocation. Actually, the way it's written: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-swift-3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... is a common way you see toy data structures code written, but it's inefficient (because pointer chasing is slow) and there's better patterns. If you use the arena method above, you could use indexes into the arena. If not, intrusive data structures (where the references are inside Node instead of inside Tree) are better.
      - neonsunset 2y ago
        Pointer chasing is irrelevant here. It takes <= 15% of the execution time, and CPUs have gotten good at it. If it takes more - it speaks more about the quality of the allocator which has poor memory locality. As noted in my previous comment, it is dominated by the time spent in the allocator/GC code. Please read https://benchmarksgame-team.pages.debian.net/benchmarksgame/description/binarytrees.html#binarytrees https://benchmarksgame-team.pages.debian.net/benchmarksgame/... The requirement to implement the same algorithm with the same data structure is what makes this benchmark interesting and informative. Don't tell me "allocate parent object A, allocate child objects C, D and E and assign them to A's fields, then allocate array F and G, and assign them to D's fields" isn't the bread and butter of all kinds of application logic, something that this benchmark stresses.
kaba0 2y ago
> garbage collection Reference counting is garbage collection, and it performs significantly worse from a throughput perspective than tracing GC, which is possibly the most common metric for web server type workloads. It really is not nitpicking, we should just really use tracing GC when we mean it.
rudedogg 2y ago
It has nowhere near the performance characteristics of those languages. It could, but it doesn’t. Look up a variety of language benchmarks. It’s typically ranked around Python/Javascript. You can get as fast as C but the code is very atypical.
- azinman2 2y ago
  There's no way it's close to Python. Where are the benchmarks? https://github.com/sh3244/swift-vs-python https://github.com/sh3244/swift-vs-python Shows a huge difference, as expected for a typed memory-safe compiled language using LLVM versus an interpreted language with a global interpreter lock.
  - rudedogg 2y ago
    https://forums.swift.org/t/really-bad-performance-with-concurrecny-and-how-to-optimize-the-code/63732/21 https://forums.swift.org/t/really-bad-performance-with-concu...
    - KerrAvon 2y ago
      The thread you just posted has a bunch of posts indicating this was not the actually the same program in Python and Swift; further, the Swift version was written poorly. Plus, the graph in the final post shows whatever Swift version someone ran tests on as much faster than Python.
- pzo 2y ago
  It is slower, like probably ~3x but lets not exaggerate that it ranks around python https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
darby_nine 2y ago
> garbage collection is reference counting not considered a form of garbage collection?
- syndeo 2y ago
  Nope; no having to pause execution and clean up. Miguel de Icaza (the creator of Mono) explicitly mentions this as one of Swift's key strengths over GC languages like C# during a talk about Swift at GodotCon 2023: https://www.youtube.com/watch?v=tzt36EGKEZo&t=7s&pp=ygURc3dpZnQgZ29kb3QgaWNhemE%3D https://www.youtube.com/watch?v=tzt36EGKEZo&t=7s&pp=ygURc3dp...
  - neonsunset 2y ago
    Perhaps? Most scenarios that explicitly involve .NET's GC vs Swift's ARC display much better performance of the former, to the point where the fact that ARC does not have GC pauses does not help if the whole things is multiple times slower, in many ways it's like Go's """low-pause""" GC design discussions that completely ignore allocation throttling and write barrier cost. Swift lacking proper performant GC is a disadvantage. Upcoming features solve it by likely enabling more scenarios to sidestep ARC, but their impact on the Swift as a whole, and user applications that use them, is yet to be seen. It's important to always remember - there's no free lunch. I'm sad that Miguel de Icaza seems to have a bone to pick with C# nowadays, but it's not surprising given Xamarin story.
    - astrange 2y ago
      > Perhaps? Most scenarios that explicitly involve .NET's GC vs Swift's ARC display much better performance of the former By which you mean "less CPU cycles on a desktop machine with plenty of memory"? That's not when ARC is more performant; it's better on smaller devices that are under memory pressure and have swapped out some of your memory. In which case you have to swap it back in to go scan for pointers. And if you're a low-priority daemon then you evict higher priority pages in the process.
      - 2y ago
pzo 2y ago
there is Kotlin Native - "Kotlin/Native is a technology for compiling Kotlin code to native binaries which can run without a virtual machine." https://kotlinlang.org/docs/native-overview.html https://kotlinlang.org/docs/native-overview.html
vetinari 2y ago
There is kotlin native, which generates native code, using the same llvm that c++, rust and swift use. It doesn't have to use virtual machine, it is just one of targets.
- deleted 2y ago
  [deleted]
- synergy20 2y ago
  not sure if it is 'production ready' and how does its performance/size go comparing to c++/rust/swift, in the end though, it's the ecosystem that matters.

glhaynes 2y ago

Memory safe and, with Swift 6, data race safe.

timeon 2y ago

> Swift does not use virtual machine and garbage collection, it competes more to c++ and rust Doesn't it use ARC by default?

azinman2 2y ago
Which is reference counting, not garbage collection. Ref counts free when count = 0. Garbage collection scans all object pointers and looks for loops / no missing pointers.
- vor_ 2y ago
  Reference counting is a kind of garbage collection.
- mkl 2y ago
  That's tracing garbage collection. Reference counting is another type of garbage collection. https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Strategies https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...
  - derrasterpunkt 2y ago
    Reference counting is not tracing garbage collection. To also quote a Wikipedia Link: „The main advantage of the reference counting over tracing garbage collection is that objects are reclaimed as soon as they can no longer be referenced, and in an incremental fashion, without long pauses for collection cycles and with clearly defined lifetime of every object.“ + https://en.wikipedia.org/wiki/Reference_counting https://en.wikipedia.org/wiki/Reference_counting
    - vor_ 2y ago
      > Reference counting is not tracing garbage collection. ??? They didn't say it was.
    - mkl 2y ago
      Of course reference counting is not tracing garbage collection. I never said it was. The comment I replied to claimed reference counting was not garbage collection at all and seemed to think tracing garbage collection was the only kind of garbage collection. Reference counting and tracing garbage collection are two different types of garbage collection.
synergy20 2y ago
it does, I thought ARC is more performant than GC and has no stop-the-world issue,thus not a GC
- pebal 2y ago
  ARC is a variation of GC. Besides, a tracing GC doesn't have to stop the world at all.
- neonsunset 2y ago
  Usually, it's the other way around: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... binary-trees is almost completely dominated by the time spent in allocator code, and stresses its throughput. This benchmark showcases how big of a gap is between manual per-thread arenas, then tracing generational multi-heap GCs, then ARC and more specialized designs like Go GC. Honorable mention goes to BEAM which also showcases excellent throughput by having process-level independent GCs, in this case resembling the behavior of .NET's and OpenJDK GC implementations.
  - astrange 2y ago
    A tree is indeed a bad fit for RC; so is anything else where you have multiple references to something but know there is a single real owner. I'd suggest keeping strong references to all the tree nodes in an array, then having everything within the tree be unowned. Basically fake arena allocation. Actually, the way it's written: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-swift-3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... is a common way you see toy data structures code written, but it's inefficient (because pointer chasing is slow) and there's better patterns. If you use the arena method above, you could use indexes into the arena. If not, intrusive data structures (where the references are inside Node instead of inside Tree) are better.
    - neonsunset 2y ago
      Pointer chasing is irrelevant here. It takes <= 15% of the execution time, and CPUs have gotten good at it. If it takes more - it speaks more about the quality of the allocator which has poor memory locality. As noted in my previous comment, it is dominated by the time spent in the allocator/GC code. Please read https://benchmarksgame-team.pages.debian.net/benchmarksgame/description/binarytrees.html#binarytrees https://benchmarksgame-team.pages.debian.net/benchmarksgame/... The requirement to implement the same algorithm with the same data structure is what makes this benchmark interesting and informative. Don't tell me "allocate parent object A, allocate child objects C, D and E and assign them to A's fields, then allocate array F and G, and assign them to D's fields" isn't the bread and butter of all kinds of application logic, something that this benchmark stresses.

kaba0 2y ago

> garbage collection Reference counting is garbage collection, and it performs significantly worse from a throughput perspective than tracing GC, which is possibly the most common metric for web server type workloads. It really is not nitpicking, we should just really use tracing GC when we mean it.

rudedogg 2y ago

It has nowhere near the performance characteristics of those languages. It could, but it doesn’t. Look up a variety of language benchmarks. It’s typically ranked around Python/Javascript. You can get as fast as C but the code is very atypical.

azinman2 2y ago
There's no way it's close to Python. Where are the benchmarks? https://github.com/sh3244/swift-vs-python https://github.com/sh3244/swift-vs-python Shows a huge difference, as expected for a typed memory-safe compiled language using LLVM versus an interpreted language with a global interpreter lock.
- rudedogg 2y ago
  https://forums.swift.org/t/really-bad-performance-with-concurrecny-and-how-to-optimize-the-code/63732/21 https://forums.swift.org/t/really-bad-performance-with-concu...
  - KerrAvon 2y ago
    The thread you just posted has a bunch of posts indicating this was not the actually the same program in Python and Swift; further, the Swift version was written poorly. Plus, the graph in the final post shows whatever Swift version someone ran tests on as much faster than Python.
pzo 2y ago
It is slower, like probably ~3x but lets not exaggerate that it ranks around python https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

darby_nine 2y ago

> garbage collection is reference counting not considered a form of garbage collection?

syndeo 2y ago
Nope; no having to pause execution and clean up. Miguel de Icaza (the creator of Mono) explicitly mentions this as one of Swift's key strengths over GC languages like C# during a talk about Swift at GodotCon 2023: https://www.youtube.com/watch?v=tzt36EGKEZo&t=7s&pp=ygURc3dpZnQgZ29kb3QgaWNhemE%3D https://www.youtube.com/watch?v=tzt36EGKEZo&t=7s&pp=ygURc3dp...
- neonsunset 2y ago
  Perhaps? Most scenarios that explicitly involve .NET's GC vs Swift's ARC display much better performance of the former, to the point where the fact that ARC does not have GC pauses does not help if the whole things is multiple times slower, in many ways it's like Go's """low-pause""" GC design discussions that completely ignore allocation throttling and write barrier cost. Swift lacking proper performant GC is a disadvantage. Upcoming features solve it by likely enabling more scenarios to sidestep ARC, but their impact on the Swift as a whole, and user applications that use them, is yet to be seen. It's important to always remember - there's no free lunch. I'm sad that Miguel de Icaza seems to have a bone to pick with C# nowadays, but it's not surprising given Xamarin story.
  - astrange 2y ago
    > Perhaps? Most scenarios that explicitly involve .NET's GC vs Swift's ARC display much better performance of the former By which you mean "less CPU cycles on a desktop machine with plenty of memory"? That's not when ARC is more performant; it's better on smaller devices that are under memory pressure and have swapped out some of your memory. In which case you have to swap it back in to go scan for pointers. And if you're a low-priority daemon then you evict higher priority pages in the process.
    - 2y ago

pzo 2y ago

there is Kotlin Native - "Kotlin/Native is a technology for compiling Kotlin code to native binaries which can run without a virtual machine." https://kotlinlang.org/docs/native-overview.html https://kotlinlang.org/docs/native-overview.html

vetinari 2y ago

There is kotlin native, which generates native code, using the same llvm that c++, rust and swift use. It doesn't have to use virtual machine, it is just one of targets.

deleted 2y ago
[deleted]
synergy20 2y ago
not sure if it is 'production ready' and how does its performance/size go comparing to c++/rust/swift, in the end though, it's the ecosystem that matters.