Live data from Hacker News

Apple is rewriting Foundation in Swift

github.com

261–263 of 263 posts

Re: Apple is rewriting Foundation in Swift

#261

Earlier quoted context omitted.

> without a big performance hit. You might be surprised (I was). Most of the benchmarks I’ve seen place it more in the neighborhood of golang and v8, rather than the C, C++, rust neighborhood you might expect. Another commenter in this thread highlighted that the ref-counting GC is what keeps it out of the C / Rust performance neighborhood.

Swift doesn't have a GC. The automatic reference counting is a feature that just inserts retain/release statements at compile time, so there is no additional process that handles that. I would suspect that the performance hits originate from other things.

ARC is a type of GC though.

Re: Apple is rewriting Foundation in Swift

#262
post #220

Earlier quoted context omitted.

Perhaps I articulated incorrectly. The bridge should have obviously existed (and should still exist for a very long foreseeable future if not forever). I was refering to having a benchmark with and without bridge and telling Swift is faster is a bit off, as that performance decrease was what Swift had to bring in the first place.

Do you mean as some kind of Swift vs. Objective-C argument? I don't think Apple is interested in having that argument in 2023. There's no point. Swift has won the "language war", politically within Apple and in developer mindshare outside Apple. (I say this as someone who continues to write Objective-C.)

Nope, Swift clearly won (which was created by Apple themselves to replace ObjC in most places if not all eventually).

I think the metrics in their current form don't really mean much if it's only measuring the performance "gain" by getting rid of the ObjC/Swift bridge.

Re: Apple is rewriting Foundation in Swift

#263

Earlier quoted context omitted.

Apple has always been preferential to reference counting (see Objective C) and it seems like they may have spent a fair bit of effort optimizing Apple Silicon for it.

> it seems like they may have spent a fair bit of effort optimizing Apple Silicon for it According to information released when the M1 came out: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1

It's good to reduce the cache hot best case time of course but isnt the more fundamental sin of RC in the extra read/write memory traffic, cache footprint and cross core cache line ping pong when incrementing object refcount fields.

(or if going with BRC, correspondingly there shouldn't be a advantages for this custom CPU feature)

Post reply on HN