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

181–190 of 235 posts

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

#181

Post by tgma »

dgs_sgd wrote: post #118
mpweiher wrote: post #111

Earlier quoted context omitted.

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?

Which other sufficiently popular modern language that's more efficient than Java lacks a tracing GC?

Rust and Swift are pretty much the only two choices and Rust is arguably much more pain in the ass for the average joe enterprise coder.

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

#182

Post by tgma »

javanonymous wrote: post #93
tiffanyh wrote: 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 JVM tends to use as much memory as it can for performance reasons. It is not a reliable indicator of how much memory it actually needs. Why spend resources on clearing memory if there's still unused memory left? If memory is an issue, you can set a limit and the JVM will probably still work fine

Your comment is definitely true. However, if you study GC performance academic papers over the past three for four decades, they pretty much conclude GC overhead, amortized, can be on par with manual alloc/free[1], but usually the unwritten assumption is they have unbounded memory for that to be true. If you study how much memory in practice you need not to suffer a performance loss on an amortized basis, you'd arrive at 2-3x, so I'd claim it is fair to assume Java needs 2-3x as much memory as Swift/C++/Rust to run comfortably.

You can actually witness this to some degree on Android vs iPhone. iPhone comfortably runs with 4GB RAM and Android would be slow as dog.

[1]: I don't dispute the results, but I also like to note that as a researcher in Computer Science in that domain, you were probably looking to prove how great GC is, not the opposite.

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

#183

Post by tgma »

cellularmitosis wrote: post #131
javanonymous wrote: post #93

Earlier quoted context omitted.

The JVM tends to use as much memory as it can for performance reasons. It is not a reliable indicator of how much memory it actually needs. Why spend resources on clearing memory if there's still unused memory left? If memory is an issue, you can set a limit and the JVM will probably still work fine

If it were such an easy problem to fix, don’t you think they would have done so rather than rewriting in Swift?

No one gets promoted fixing bugs. Rewriting an entire system is a great way to achieve that.

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

#184

Post by mrighele »

cogman10 wrote: post #117
mrighele wrote: post #82

Earlier quoted context omitted.

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 fre…

A moving garbage collector is not that rare, other languages have it. I think C# has one for example, OCaml and SBCL too.

I know about the trade-offs that a moving GC does, but the rule is about double memory usage, not ten times more like a 90% reduction would seem to imply.

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

#185

Post by tgma »

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…

IBM is a huge and quite balkanized company and I don't think there was ever a centralized push towards Swift outside some excited parties. With that, I would note that circa 2018 there was a DRAM shortage in the industry and people started thinking more about memory conservation in datacenter workloads.

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

#186

Post by dwaite »

maz1b wrote: post #24

I've always wondered a slight amount as to why larger enterprises (which have the resources to hire specialists) don't hire people with expertise in say things like Rust, or Elixir/Phoenix? It's one thing to say that we want to hire commonly available developers like in Java or C#, but if you have a long term plan and execution strategy, why not pick technology that may pay off larger dividends? ITT: I get why they c…

it sounds like you are asking why enterprises aren't choosing to write Rust code vs Java code. I wouldn't turn away a developer just because they had experience with Elixir.

It really comes down to whether there's someone making the case that a particular application/subsystem has specialized needs that would warrant hiring experts, and whether they can make the case successfully that the system should use technologies that would require additional training and impose additional project risk.

Until you are dealing not with enterprise applications but actual services, it can be difficult to even maintain development teams for maintenance - if your one ruby dev leaves, there may be nobody keeping the app running.

Even when you are producing services - if they are monolithic, you'll also be strongly encouraged to stick with a single technology stack.

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

#187

Post by k_bx »

artdigital wrote: post #132

Hearing a company like Apple is using swift on the server side changed my view on server Swift I’ll definitely take a look again, great to see it becoming mature enough to be another viable option

The big questions are: how's package management, community, ease of forking, patching and other dependency management related stuff. Server-side development needs those questions to have good answers.

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

#188

Post by wiseowise »

tgma wrote: post #182
javanonymous wrote: post #93

Earlier quoted context omitted.

The JVM tends to use as much memory as it can for performance reasons. It is not a reliable indicator of how much memory it actually needs. Why spend resources on clearing memory if there's still unused memory left? If memory is an issue, you can set a limit and the JVM will probably still work fine

Your comment is definitely true. However, if you study GC performance academic papers over the past three for four decades, they pretty much conclude GC overhead, amortized, can be on par with manual alloc/free[1], but usually the unwritten assumption is they have unbounded memory for that to be true. If you study how much memory in practice you need not to suffer a performance loss on an amortized basis, you'd arriv…

Android doesn’t even run JVM.

> iPhone comfortably runs with 4GB RAM and Android would be slow as dog.

This has nothing to do with RAM. Without load, Android wouldn’t even push 2GB, it would be still slower than iPhone because of different trade-offs they make in architecture.

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

#189

Post by wiseowise »

cellularmitosis wrote: post #131
javanonymous wrote: post #93

Earlier quoted context omitted.

The JVM tends to use as much memory as it can for performance reasons. It is not a reliable indicator of how much memory it actually needs. Why spend resources on clearing memory if there's still unused memory left? If memory is an issue, you can set a limit and the JVM will probably still work fine

If it were such an easy problem to fix, don’t you think they would have done so rather than rewriting in Swift?

But then you don’t get promo and “fun” work!

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

#190

Post by tgma »

wiseowise wrote: post #188
tgma wrote: post #182

Earlier quoted context omitted.

Your comment is definitely true. However, if you study GC performance academic papers over the past three for four decades, they pretty much conclude GC overhead, amortized, can be on par with manual alloc/free[1], but usually the unwritten assumption is they have unbounded memory for that to be true. If you study how much memory in practice you need not to suffer a performance loss on an amortized basis, you'd arriv…

Android doesn’t even run JVM. > iPhone comfortably runs with 4GB RAM and Android would be slow as dog. This has nothing to do with RAM. Without load, Android wouldn’t even push 2GB, it would be still slower than iPhone because of different trade-offs they make in architecture.

The point was GC cost in general, not which Java/JVM implementation you choose. Try comparing two Androids with the same chipset at 4GB vs 8GB RAM.

Anyhow, that was just an anecdotal unscientific experiment to give you some idea--obviously they are two different codebases. The literature is there to quantify the matter as I noted.

Post reply on HN