Live data from Hacker News

Swift at Apple: Migrating the Password Monitoring Service from Java

swift.org

11–20 of 235 posts

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#11
post #8
post #5

> In comparison with the previous Java service, the updated backend delivers a 40% increase in performance, along with improved scalability, security, and availability. As is always the case with such rewrites, the big question is whether the improvements came from the choice of language or because they updated a crusty legacy codebase and fixed bugs/bottlenecks.

I'd typically agree with your comment but ... Given that they also experienced a 90% reduction in Memory Usage (presumably from Java GC vs Swift AOT memory management) - it seems more likely the gains are in fact from the difference in languages.

The java runtime is a beast. Even the fact that another runtime is just capable to do a similar thing is impressive, disregard the fact that it might be better. Even being on par makes it interesting for me to maybe try it on my own.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#12
post #9

Earlier quoted context omitted.

IMO, Apple has quite the track record of never "meeting X where they are". They could make Xcode cross platform, but they never will.

There would be no point in doing that. All the devs they care about already have Macs. If you are on Windows or Linux and you want to work on Swift server side code then you can use their official LSP or VSCode extension in your favorite editor.

There's always XTool https://github.com/xtool-org/xtool

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#13

A win on the board for ARC? Can anyone with more deep GC knowledge explain why this might be, considering the tweaks they made to G1? Is this a specific workload advantage, or does it apply generally?

It has been a long time, but I worked on GC at one point. My guess is that it’s the memory footprint (and loss of cache locality) that’s to blame. Copying or mark/sweep can be fast, but only if you give them lots of extra memory to accumulate garbage between GC passes. ARC does a little extra CPU work all the time, but it has good locality, and doesn’t need the extra memory.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#16
post #8

Earlier quoted context omitted.

I'd typically agree with your comment but ... Given that they also experienced a 90% reduction in Memory Usage (presumably from Java GC vs Swift AOT memory management) - it seems more likely the gains are in fact from the difference in languages.

The typical rule of thumb is that getting good performance out of tracing GC requires doubling your memory usage, so a 90% reduction suggests that they made significant improvements on top of the language switch.

I remember the 2x rule from 20 years ago - do you know if things have changed? If locality is more important now, tracing GC might never be as performant as reference counting. Either you use 2x the memory and thrash your cache, or you use less and spend too much CPU time collecting.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#17

A win on the board for ARC? Can anyone with more deep GC knowledge explain why this might be, considering the tweaks they made to G1? Is this a specific workload advantage, or does it apply generally?

The way to write performant Swift is classless so without ARC, but classes have been necessary for many areas. Recently, Swift’s been leveraging a lot of ownership features similar to Rust to make it possible to do more without classes, and I’d guess Apple teams would be using those

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#20
post #5

> In comparison with the previous Java service, the updated backend delivers a 40% increase in performance, along with improved scalability, security, and availability. As is always the case with such rewrites, the big question is whether the improvements came from the choice of language or because they updated a crusty legacy codebase and fixed bugs/bottlenecks.

Imagine what rust or go could have achieved
Post reply on HN