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

121–130 of 235 posts

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

#121

Post by dontlaugh »

latchkey wrote: post #115
dontlaugh wrote: post #112

Earlier quoted context omitted.

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. ¯\_(ツ)_/¯

I don't know, I didn't flag it.

I'm disagreeing with MS's choice and you seemed to disagree with that, even claiming I hadn't read their rewrite plan and reasoning.

Doesn't really matter.

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

#122

Post by Daedren »

ohdeargodno wrote: post #38

>Java’s G1 Garbage Collector (GC) mitigated some limitations of earlier collectors The... existing and default GC since JDK 6 G1GC ? >managing garbage collection at scale remains a challenge due to issues like prolonged GC pauses under high loads, increased performance overhead, and the complexity of fine-tuning for diverse workloads. Man if only we had invented other garbage collectors like ZGC ( https://openjdk.org…

The funny part is that there's probably zero chance they used Swift 6 for this, because it's impossible to have released Swift 6 without having, you know, actually used the language for something.

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

#123

Post by cogman10 »

SigmundA wrote: post #103
MBCook wrote: post #89

Earlier quoted context omitted.

It does for primitives. For user defined stuff we’ve recently gained records, which are a step in that direction, and a full solution is coming.

What about structs?

I'm not sure with the semantics of structs for C#.

What java is getting in the future is immutable data values where the reference is the value.

When you have something like

   class Foo {
     int a;
     int b;
   }

   var c = new Foo();
in java, effectively the representation of `c` is a reference which ultimately points to the heap storage locations of `a, b`. In C++ terms, you could think of the interactions as being `c->b`.

When values land, the representation of `c` can instead be (the JVM gets to decide, it could keep the old definition for various performance reasons) something like [type, a, b]. Or in C++ terms the memory layout can be analogous to the following:

    struct Foo { int a, int b };

    struct Foo c;
    c.a = 1;
    c.b = 2;

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

#124

Post by tialaramex »

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.

Sure, maybe you can get money to have some businesses try out rewriting their line-of-business software in the same language versus in a different language and get some results.

My expectation is that if you put the work in you can get actual hard numbers, which will promptly be ignored by every future person asking the same "question" with the same implied answer.

If the "just rewrite it and it'll be better" people were as right as they often seem to believe they are, a big mystery is JWZ's "Cascade of Attention-Deficit Teenagers" phenomenon. In this scenario the same software is rewritten, over, and over, and over, yet it doesn't get faster and doesn't even fix many serious bugs.

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

#125

Post by cogman10 »

CharlesW wrote: post #96
mtrovo wrote: post #86

Without a deeper profiling analysis of the Java application it's hard to not consider this whole piece just advertorial content. Where exactly were the bottlenecks in Java or top delta gains compared to Swift. The service scope looks so simple that there might be some underlying problem with the previous version, be it the code not scaling well with the irregular batch nature of traffic or custom cryptography code no…

> Without a deeper profiling analysis of the Java application it's hard to not consider this whole piece just advertorial content. I'd be surprised if anything Apple wrote would satisfy you. TFA makes it clear that they first optimized the Java version as much as it could be under Java's GC, that they evaluated several languages (not just Swift) once it became clear that a rewrite was necessary, that they "benchmarke…

Ok, I'm pretty skeptical that they actually did optimize what they could. In fact, reading between the lines it sounds like they barely tried at all.

For example, they mention G1GC as being better than what was originally there but not good enough. Yet the problems they mention, prolonged GC pauses, indicates that G1GC was not the right collector for them. Instead, they should have been using ZGC.

The call out of G1GC as being "new" is also pretty odd as it was added to the JVM in Java 9, released in 2016. Meaning, they are talking about a 9 year old collector as if it were brand new. Did they JUST update to java 11?

And if they are complaining about startup time, then why no mention of AppCDS usage? Or more extreme, CRaC? What about doing an AOT compile with Graal?

The only mention they have is the garbage collector, which is simply just one aspect of the JVM.

And, not for nothing, the JVM has made pretty humongous strides in startup time and GC performance throughout the versions. Theres pretty large performance wins going from 11->17 and 17->21.

I'm sorry, but this really reads as Apple marketing looking for a reason to tout swift as being super great.

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

#126

Post by potatolicious »

ivan_gammel wrote: post #104
potatolicious wrote: post #83

Earlier quoted context omitted.

> "why not just run the checks at the backend's discretion?" Because the other side may not be listening when the compute is done, and you don't want to cache the result of the computation because of privacy. The sequence of events is: 1. Phone fires off a request to the backend. 2. Phone waits for response from backend. The gap between 1 and 2 cannot be long because the phone is burning battery the entire time while…

Is it really a problem? Client can pass an encryption key with the request and then collect encrypted result later. As long as computation is done and result is encrypted, server can forget the key, so cache is no longer a privacy concern.

You can, and in situations where the computation is unavoidably long that's what you'd do. But if you can do a bit of work to guarantee the computation is fast then it removes a potential failure mode from the system - a particularly nasty one at that.

If you forget to dump the key (or if the deletion is not clean) then you've got an absolute whopper of a privacy breach.

Also worth noting that you can't dump the key until the computation is complete, so you'd need to persist the key in some way which opens up another failure surface. Again, if it can't be avoided that's one thing, but if it can you'd rather not have the key persist at all.

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

#127

Post by cogman10 »

I'm honestly very skeptical that Apple actually did everything they could to make Java startup fast and the GC perform well under load.

G1GC is a fine collector, but if pause time is really important they should have used ZGC.

And if startup is a problem, recent versions of Java have introduced AppCDS which has gotten quite good throughout the releases.

And if that wasn't good enough, Graal has for a long time offered AOT compilation which gives you both fast startup and lower memory utilization.

None of these things are particularly hard to add into a build pipeline or deployment, they simply require Apple to use the latest version of Java.

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

#128

Post by staplers »

tialaramex wrote: post #124
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.

Sure, maybe you can get money to have some businesses try out rewriting their line-of-business software in the same language versus in a different language and get some results. My expectation is that if you put the work in you can get actual hard numbers, which will promptly be ignored by every future person asking the same "question" with the same implied answer. If the "just rewrite it and it'll be better" people…

  If the "just rewrite it and it'll be better" people were as right as they often seem to believe
Generally speaking, technological progress over thousands of years serves to validate this. Sure, in the short term we might see some slippage depending on talent/expertise, but with education and updated application of learnings, it's generally true.

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

#129

Post by username223 »

cogman10 wrote: post #119
username223 wrote: post #16

Earlier quoted context omitted.

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

That's the theory -- a compacting collector will reduce fragmentation and can put linked objects next to each other. On the other hand, a reference count lives in the object, so you're likely using that cache line already when you change it.

I don't know which of these is more important on a modern machine, and it probably depends upon the workload.

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

#130

Post by metaltyphoon »

fmorel wrote: post #61
misiek08 wrote: post #34

I would love to see such post from Microsoft about C#. "We looked into few alternatives and chose our own language, it fitted the task, worked great and came as best overall in terms of technology, devex and maintainability". Great read, thanks for sharing! This means to me you are mature, sharing stuff instead of making obscure secrets from basic stuff existing at many companies <3

They've done quite a few user stories on https://devblogs.microsoft.com/dotnet/category/developer-sto... and related blogs, especially about .NET Framework to .NET migrations.

Not quite the same but close. I assume OP was mentioning from one stack into a completely different one.
Post reply on HN