Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift at Apple: Migrating the Password Monitoring Service from Java

swift.org

Post reply on HN
Print view View original

111–120 of 235 posts

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

#111

Post by mpweiher »

paxys wrote: 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.

With the 90% reduction in memory consumption, I'd wager that most if not all the performance improvement came from that. In fact, it is a little surprising that hardware utilization only dropped 50%.

Reduced memory consumption for cloud applications was apparently also the primary reason IBM was interested in Swift for a while. Most cloud applications apparently sit mostly idle most of the time, so the number of clients you can multiplex on single physical host is limited by memory consumption, not CPU throughput.

And Java, with the JIT and the GC, has horrible memory consumption.

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

#112

Post by dontlaugh »

latchkey wrote: post #101
dontlaugh wrote: post #98

Earlier quoted context omitted.

I’m not focused on a number, I’m just pointing out Go’s optimisation potential is lower than other options. Of course it’s a trade off and their reasons are fine, but rewrites are expensive and disruptive. I would have picked something that can avoid a second rewrite later on.

[flagged]

I'm well aware of how they're doing it. It makes sense to start with a mostly-automated rewrite, what they confusingly call a "port".

But after that step, the end result will be maintained and changed manually. It makes perfect sense to make improvements (including to performance) this way. All I'm questioning is the choice of target, since it excludes some possible future improvements. If you're rewriting (semi-automated or not), it's an opportunity to future-proof as well.

I don't understand why you're being so confrontational about mere technical disagreement.

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

#113

Post by jbverschoor »

paxys wrote: post #42
misiek08 wrote: post #30

Earlier quoted context omitted.

I love to always see such comments. On JVM you use crap like Spring and over-engineer everything. 20 types, interfaces and objects to keep single string in memory. JVM also like memory, but can be tailored to look okayish, still worse than opponents.

And I'm 100% sure you can do the same in Swift.

Sure, And you can also make beautiful code in php, or shot code in Java

It’s the history, standard libs, and all the legacy tutorials which don’t get erased from the net

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

#114

Post by paxys »

candiddevmike wrote: post #6
quux wrote: post #2

I'm hoping to hear some good news at WWDC for swift development in editors other than Xcode (VSCode, Neovim, etc.) Last year they said "we need to meet backend developers where they are" and announced plans to improve sourcekit-lsp and other efforts.

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

Who even wants Xcode to be cross platform? People can barely tolerate it on macs.

What you really mean is people want the iOS development toolchain to be cross platform, and that would mean porting iOS to run in a hypervisor on linux/windows (to get the simulator to work). That is way too big a lift to make sense.

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

#115

Post by latchkey »

dontlaugh wrote: post #112
latchkey wrote: post #101

Earlier quoted context omitted.

[flagged]

I'm well aware of how they're doing it. It makes sense to start with a mostly-automated rewrite, what they confusingly call a "port". But after that step, the end result will be maintained and changed manually. It makes perfect sense to make improvements (including to performance) this way. All I'm questioning is the choice of target, since it excludes some possible future improvements. If you're rewriting (semi-auto…

I'm not disagreeing with you and it is weird that my comment above got flagged given that I'm not attacking you. ¯\_(ツ)_/¯

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

#117

Post by cogman10 »

mrighele wrote: post #82
plorkyeran wrote: post #10

Earlier quoted context omitted.

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.

The 90% reduction doesn't necessarily have to be related only to GC. In my experience Java is a memory hog even compared to other garbage collected languages (that's my main gripe about the language). I think a good part of the reason is that if you exclude primitive types, almost everything in Java is an heap-allocated object and Java objects are fairly "fat": every single instance has an header of between 96 and 12…

The java GC approach is somewhat unique compared to other languages. There are multiple GCs and pretty much all of them are moving collectors. That means the JVM fairly rarely ends up freeing memory that it's claimed. A big spike will mean that it holds onto the spike's amount of memory.

Many other GCed languages, such as swift, CPython, Go, do not use a moving collector. Instead, they allocate and pin memory and free it when not in use.

The benefit to the JVM approach is heap allocations are wicked fast on pretty much all its collectors. Generally, to allocate it's a check to see if space is available and a pointer bump. For the other languages, you are bound to end up using a skiplist and/or arena allocator provided by your malloc implementation. Roughly O(log(n)) vs O(1) in performance terms.

Don't get me wrong, the object header does eat a fair chunk of memory. Roughly double what another language will take. However, a lot of people confuse the memory which the JVM has claimed from the OS (and is thus reported by the OS) with the memory the JVM is actively using. 2 different things.

It just so happens that for moving collectors like the JVM typically uses more reserved memory means fewer garbage collections and time spend garbage collecting.

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

#118

Post by dgs_sgd »

mpweiher wrote: post #111
paxys wrote: 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.

With the 90% reduction in memory consumption, I'd wager that most if not all the performance improvement came from that. In fact, it is a little surprising that hardware utilization only dropped 50%. Reduced memory consumption for cloud applications was apparently also the primary reason IBM was interested in Swift for a while. Most cloud applications apparently sit mostly idle most of the time, so the number of clie…

Interesting. If IBM was trying to solve for memory consumption, why do you think they picked Swift over alternatives that might also have achieved lower memory consumption?

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

#119

Post by cogman10 »

username223 wrote: post #16
plorkyeran wrote: post #10

Earlier quoted context omitted.

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.

It all depends, but one major advantage of the way the JVM GCs is related memory will tend to be colocated. This is particularly true of the serial, parallel, and G1GC collectors.

Let's say you have an object that looks like A -> B -> C. Even if the allocation of A/B/C happened at very temporally different times and inbetween different allocations, the next time the GC runs as it traverses the graph it will see and place in memory [A, B, C] assuming A is still live. That means even if the memory originally looks something like [A, D, B, Q, R, S, T, C] the act of collecting and compacting has a tendency to colocate.

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

#120

Post by acdha »

username223 wrote: post #77
jeroenhd wrote: post #21

Earlier quoted context omitted.

Java has had AOT compilation for a while, so traditional GC and its massive overhead are no longer a strict necessity. Even AOT Java will probably stay behind Swift or any other natively compiled language in terms of memory usage, but it shouldn't be that drastic. As for performance and locality, Java's on-the-fly pointer reordering/compression can give it an edge over even some compiled languages in certain algorith…

> Java has had AOT compilation for a while, so traditional GC and its massive overhead are no longer a strict necessity. You mean it does escape analysis and stack-allocates what it can? That would definitely help, but not eliminate the GC. Or are you thinking of something else? Thinking about it more, I remember that Java also has some performance-hostile design decisions baked in (e.g. almost everything's an Object…

Java also has a lot of culture making optimization-resistant code so there’s the question of whether you’re talking about the language itself or various widespread libraries, especially if they’re old enough to have patterns designed around aesthetics or now-moot language limitations rather than performance.

I’ve replaced Java code with Python a few times and each time even though we did it for maintenance (more Python devs available) we saw memory usage more than halved while performance at least doubled because the code used simpler functions and structures. Java has a far more advanced GC and JIT but at some point the weight of code and indirection wins out.

Post reply on HN