Apples to Apples, Part II | Hacker News Reader

Apples to Apples, Part II

jessesquires.com

90 pointspoolpool13 comments

Looking at the original article, it seems like he is comparing sorting an array of NSNumber objects in Objective-C with sorting an array of primitive integers in Swift.

The only really big surprise is that the latter actually used to be slower. Boggle.

It's worth noting that Swift Ints (and Arrays) aren't primitives; they're named types defined as structs in Swift code in the standard library, and have methods and can be extended like any other types in the library (see [1]). That's why the unoptimized case is slow, and why the author gets such a dramatic speedup from optimization-- the Swift optimizer (unlike the Objective C optimizer, which, thanks to ObjC's messaging system, has to keep method calls intact) can use techniques like method inlining to bring performance to a point close to that of a native int/plain C array.

Regardless, I'd still like to see a comparison with C++ (where method dispatch looks a lot like Swift and the optimizer should be able to do similar things) and plain C. Might have to try that this evening if I get bored.

1: https://developer.apple.com/library/prerelease/mac/documenta...

Likewise, it's also worth noting that since 10.7/iOS 5, NSNumbers can be tagged pointers rather than separately allocated objects.

Yeah, not to mention that NSMutableArray is not necessarily an array in Objective-C, see: http://ridiculousfish.com/blog/posts/array.html . It really seems like this benchmark is comparing different framework approaches more than any "core language speed" (similar to comparing stl::vector sort of ints in Objective-C++ to NSMutableArray sort of NSNumbers)

Just looking at the "std lib sort", what this might actually be testing off the top of my head is:

1. C-style-array access/write speed of "native arrays" vs. potentially hash-mappy access/write speed of array-like NSMutableArrays.

2. Direct integer comparison (a < b) vs -[NSNumber compare:] method dispatch speed.

3. I don't know how sorted() is implemented internally in Swift, but given that no comparison method is being passed in, you may also be comparing a fast internal int[] sort that directly compares ints to the speed of calling the NSComparisonResult lambda O(n lg n) times.

Can anyone explain the reasoning behind this difference? The article only mentions "In Objective-C, NSArray and NSNumber are used intentionally as the counterparts to Swift's Array and Int."

I can't think of a good reason other than "I don't want to compare C-style sort with Swift because I want to talk about Objective-C". This is an incredibly poor benchmark in my opinion, since if you were dealing with a ton of ints in an Objective-C program you'd probably be dropping down to C or (in the case of ObjC++), C++. Back when Swift was slower and losing, I suppose it was eye opening that despite all this ObjC was still winning.

That's not to say that there isn't any insight here, I just think the much more powerful argument would be "look, in Swift we can get C-like speed without having to use icky primitive arrays". Which is actually a pretty powerful selling point (if its true, which we don't know, since C-style sorts aren't compared here).

That's a little harsh. I for one think that it's a perfectly reasonable thing to do. The benchmark was how does Swift go compared to Objective-C, not C. That is, if you're using those nice data structures that make life easy in Cocoa, what sort of a speed hit can you expect. As an example, say I want to use an NSArray because I need to serialize the contents, or because some other module expects an NSArray, it's a pain in the neck and a source of bugs if I have to translate safely from a C array to an NSArray every timie I want to use it (and if that array is mutable?)

This benchmark shows how things perform when you're using the nice, safe array (because let's not forget that an NSArray is much safer than a C array). In Swift you get performance that absolutely trounces the equivalent functionality in Objective-C. That's a nice thing to know.

I think we agree, but let me explain.

> The benchmark was how does Swift go compared to Objective-C, not C

Objective-C is a strict superset of C, in other words, there's no such thing as "Objective-C, not C". This is not me being pedantic, its an incredibly important feature and selling point of the language. You are making ObjC perform with one arm tied behind its back, exposing all of the pitfalls with none of the benefits.

> In Swift you get performance that absolutely trounces the equivalent functionality in Objective-C. That's a nice thing to know.

Precisely. I think there is a great blog post about how you get certain things in Swift for free that would be time consuming/hard/whatever in Objective-C. But without making the actual comparison, we can't know or understand that tradeoff. If this also showed pure-C or ObjC++ perf, I would walk away thinking "damn, I can get 0.9x the speed of C AND have it be safe? Cool." Instead, here I'm just left thinking "ok, so Swift is faster than something I'd never do in Obj-C. Great." Then immediately I'd start asking "wait, isn't this maybe just because we're using an expensive -[NSNumber compare:] thousands of times? Maybe this can be trivially remedied by changing that call to compare to direct accesses to the internal ints?"

Edit: As an additional comment, I'd point out that you'd make an IntArray subclass to the NSArray class cluster to get both the perf and serialization of NSArray. Again, convoluted and unnecessary work, but ultimately what you'd actually do in ObjC.

Well, It is a comparison between Objective-C and Swift, after all. He is using the proper data structures in each language for this tests. It's true is not the most efficient way to go about it in an Objective-C app, because you can mix it with C and C++, but then you wouldn't be using Objective-C, and the title of the article probably wouldn't be "An analysis of sorts between Objective-C and Swift".

(See above response). Sure for C++, but certainly not C. When you use a double in Objective-C its not "no longer Objective-C and actually C now". C is a part of Objective-C. Not using c-style arrays is an arbitrary limitation, and forcing one to not use the proper data structures. No one recommends using an NSMutableArray for gigabytes of ints, it is well established that it is not the proper data structure for that. That being said, I totally agree that it is better in Swift. My point is simply that the demonstration should be one of the impressive ease of use/performance tradeoff vs. a questionable raw speed comparison where you don't actually see how fast it would go in a shipping Objective-C program that used every available tool at its disposal.

In other words, this blog post could be misinterpreted to give the impression that apps will now necessarily get faster thanks to Swift. But this is certainly not true if the C version is 1) faster and 2) in wide use. Instead the argument should be apps will be more reliable at negligible speed loss, and possibly even faster (again we don't know since that benchmark wasn't done).

Swift is slower in the debug mode and faster with full optimizations. I don't know either language, but I think NSArray cannot store primitive types, so he used NSNumber object wrapper.

Thats correct, you need wrap the primitive types when putting them in an array. Unless you use a C style array, but thats more hassle than it's worth generally.

Expected an Apple II; was disappointed.

Reply on news.ycombinator.com