4 ms·

De Icaza suggests that the GC hasn't improved sufficiently even in the modern .NET era, and maybe that's true in certain cases. But in practice, dozens of big-b

by TillE 3y ago

De Icaza suggests that the GC hasn't improved sufficiently even in the modern .NET era, and maybe that's true in certain cases. But in practice, dozens of big-budget 3D games have been made with Unity, using a janky old Mono runtime that performs far worse than .NET 8. Swift is a really interesting language, and Apple does distribute official toolchain binaries for Linux and Windows. But yeah it's still a bit of an awkward choice if you're not using Xcode, hopefully that improves.

neonsunset 3y ago
There is no such thing as a free lunch :) Modern GC implementations offer an important advantage - very cheap allocations and batched deallocations which allow to sustain high allocation traffic that goes through the heap. This comes at a cost of non-deterministic memory usage and object de-allocation. Further tradeoff is made between GC pause times, allocation throttling (Go) and even higher memory footprint (ZGC). My knowledge on the exact overhead of Swift's reference counting is very limited but there's a good chance it comes with significant upfront cost that you don't have to pay in languages with GC or with compile-time-defined allocation semantics (Rust and C++ RAII). There's a reason why Apple invested in atomics being as cheap[0] as they are on their ARM64 cores. Overall, every time I find Swift benchmark numbers on the internet, they turn out to be far[1][2] from near-Rust performance despite being a language built on top of LLVM. [0] https://dougallj.github.io/applecpu/firestorm-int.html https://dougallj.github.io/applecpu/firestorm-int.html (e.g. CAS, CASAL, DMB) [1] https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages [2] https://github.com/jinyus/related_post_gen#multicore-results https://github.com/jinyus/related_post_gen#multicore-results
pjmlp 3y ago
C# is now following the same adoption patterns as C and Pascal dialects when games were in Assembly, C++ when games were mostly C. CAPCOM has their own engine based on a fork from .NET Core, used it on Devil May Cry for the PlayStation 5. Good luck getting similar adoption for Swift outside Apple platforms, specially game consoles. If not C# alongside C++, studios would rather use Rust not Swift, e.g. Embark and Activision. Metal has now C++ bindings, as Apple had to cede Objective-C and Swift bindings weren't being welcomed by major studios. I like Swift, however I don't see SwiftGodot going anywhere outside iDevices. That isn't bad if that is the goal though, plenty of companies are doing quite well being single platform.
- zengid 3y ago
  I agree here, and I think Icaza is just motivated to make something for himself, because as he explained in the talk, he loves Apple products and APIs. Swift cross-platform would be a great thing.. I see that The Browser Company is using it for their browser project [0]. It's got a good mix of speed and ergonomics, and Apple seems hell bent on using swift for everything, even at the kernel level (I can't look up sources atm but Sean Parent has said this on ADSP podcast, and you can see the various talks from C++ conferences about swift as a "successor language"). You're right though, Swift is always going to be beholden to Apples whims, just like C# and Microsoft. I feel like Rust has the best shot at being "the cross-platform language to rule them all", but it has a long way to go in terms of being as ergonomic as Swift or C#. [0] https://speakinginswift.substack.com/p/interoperability-swifts-super-power https://speakinginswift.substack.com/p/interoperability-swif...

by TillE 3y ago

neonsunset 3y ago

There is no such thing as a free lunch :) Modern GC implementations offer an important advantage - very cheap allocations and batched deallocations which allow to sustain high allocation traffic that goes through the heap. This comes at a cost of non-deterministic memory usage and object de-allocation. Further tradeoff is made between GC pause times, allocation throttling (Go) and even higher memory footprint (ZGC). My knowledge on the exact overhead of Swift's reference counting is very limited but there's a good chance it comes with significant upfront cost that you don't have to pay in languages with GC or with compile-time-defined allocation semantics (Rust and C++ RAII). There's a reason why Apple invested in atomics being as cheap[0] as they are on their ARM64 cores. Overall, every time I find Swift benchmark numbers on the internet, they turn out to be far[1][2] from near-Rust performance despite being a language built on top of LLVM. [0] https://dougallj.github.io/applecpu/firestorm-int.html https://dougallj.github.io/applecpu/firestorm-int.html (e.g. CAS, CASAL, DMB) [1] https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages [2] https://github.com/jinyus/related_post_gen#multicore-results https://github.com/jinyus/related_post_gen#multicore-results

pjmlp 3y ago

C# is now following the same adoption patterns as C and Pascal dialects when games were in Assembly, C++ when games were mostly C. CAPCOM has their own engine based on a fork from .NET Core, used it on Devil May Cry for the PlayStation 5. Good luck getting similar adoption for Swift outside Apple platforms, specially game consoles. If not C# alongside C++, studios would rather use Rust not Swift, e.g. Embark and Activision. Metal has now C++ bindings, as Apple had to cede Objective-C and Swift bindings weren't being welcomed by major studios. I like Swift, however I don't see SwiftGodot going anywhere outside iDevices. That isn't bad if that is the goal though, plenty of companies are doing quite well being single platform.

zengid 3y ago
I agree here, and I think Icaza is just motivated to make something for himself, because as he explained in the talk, he loves Apple products and APIs. Swift cross-platform would be a great thing.. I see that The Browser Company is using it for their browser project [0]. It's got a good mix of speed and ergonomics, and Apple seems hell bent on using swift for everything, even at the kernel level (I can't look up sources atm but Sean Parent has said this on ADSP podcast, and you can see the various talks from C++ conferences about swift as a "successor language"). You're right though, Swift is always going to be beholden to Apples whims, just like C# and Microsoft. I feel like Rust has the best shot at being "the cross-platform language to rule them all", but it has a long way to go in terms of being as ergonomic as Swift or C#. [0] https://speakinginswift.substack.com/p/interoperability-swifts-super-power https://speakinginswift.substack.com/p/interoperability-swif...