Swift Resistance

http://owensd.io/2015/01/29/swift-resistance.html

by mpweiher • 11 years ago

134 85 11 years ago

unsigner• 11 years ago

"I cannot do it because the performance is so flipping terrible in debug mode. Trying to debug your app with optimized code is just a pain."

I've been shipping PC and console games in C++ since 2000. Debug builds have ALWAYS been utterly unusable for us - what we do is run in "release" mode with optimizations, ASSERTs, and debug prints enabled, then when the problem arises, turn off optimizations in a handful of related files and recompile. Then we ship another, "goldmaster" version which strips out the asserts and prints.

repsilat• 11 years ago

If this performance-critical part of the code is battle-tested, they could always compile this bit with optimisations and the rest in debug mode, too.

drewcrawford• 11 years ago

I wish this were true, but unfortunately you can't mix unoptimized and optimized code in Swift. File dupes of rdar://19527999.

GuiA• 11 years ago

Be a good citizen, file a bug report everytime you encounter problems with your tools.

chris_wot• 11 years ago

Are Apple responsive?

jackweirdy• 11 years ago

I filed a bug report for Mac mail about 3 months ago. From the bug tracker UI (which isn’t informative at all) I don’t think the ticket has even been touched.

jakobegger2• 11 years ago

In the last year I filed 7 bug reports to Apple.

One was closed as a duplicate. For another one they requested additional information.

The other 5 reports received no response at all.

DrJokepu• 11 years ago

I have filed 3 radars with Apple regarding Swift. All 3 bugs have been fixed.

josephlord7• 11 years ago

Mixed but the Swift team mostly yes.

orkoden• 11 years ago

It usually takes weeks or months for reactions to bug reports. I have three open bugs (one for Xcode, one for iOS, one for OS X). The iOS bug is a regression introduced in the beta and reported in August. It contains screen shots and sample code. No reaction yet.

forgottenpass• 11 years ago

Someone posted this to Hacker News a while ago about how submit bugs and interact with Apple. When I compare them to other software providers I have interacted with (development tools/platforms/libraries/etc), the only team looking worse than Apple is google. It's a coping guide for an abusive relationship.

http://blackpixel.com/blog/2012/02/radar-or-gtfo.html

bitserf• 11 years ago

Of the many bugs I reported at 8.0 release, not one has been fixed. Basic intern level stuff to do with messed up orientation bugs, broken locale APIs, text rendering and layout issues.

I honestly can't be fucked any more, they can hire some QA with the billions they're earning. They can build all the fancy APIs they want, I'm not touching it until they haven't decided to discard it after a year and some other poor suckers have suffered through their eternal September of shitty buggy newness while fighting with App Store review team every second version for the privilege to make burger flipping money.

DennisP• 11 years ago

Yeah, with $178 billion in cash, you'd think they'd beef up a bit.

gurkendoktor• 11 years ago

they can hire some QA with the billions they're earning

I don't see how that would help at all. Many of these bugs HAVE been discovered and reported on Radar. If Apple's deadline is September XY for iOS Z, and November XY for OS X 10.Z, then they will ship it, no matter what their QA team says, and no matter how big it is.

iOS 8.0.1 was a QA glitch, but I'd say it was an outlier.

mikeash5• 11 years ago

I strongly object to this notion that I have to give free work to Apple in order to "be a good citizen."

I understand that if I expect stuff to get fixed that my odds are improved if I file a bug report. But I don't owe Apple anything and I'm perfectly within my rights, and still a "good citizen" if I just do my best to work around the problems and let Apple figure stuff out on their own.

CmonDev• 11 years ago

A gentle introduction to Apple marketing: "Swift" doesn't mean "swift" - terms and conditions apply (not to mention the name was stolen from the original Swift language - modifications made to Wiki were swift indeed).

te_chris2• 11 years ago

My problem with swift is even more simple than this guy's.

I have a new client build and really wanted to use swift for the compile time safety features. Then I started looking at ios7 compatibility...total fucking joke. After isolating what is still a very popular device, especially by revenue in the case of my client, apple have basically made it impossible use this language as long as people have customers who use an iPhone 4. In this case, for my client, that's fucking heaps of them.

It doesn't have to be this way though, they could prioritise adding support for static libs,then all developers will be able to switch over as we'll be able to use the existing libraries we rely on, but they just don't seem to give even half a shit about making it something people might actually use.

/end rant

sneak• 11 years ago

Or they could just wait a year for the iPhone 4 to go away, and focus their attentions on building a watch for people to firehose money at them for.

Seems pretty simple to me. Skate to where the puck is going.

jakobegger2• 11 years ago

I think the puck is going in the direction of an ever increasing number of people who buy used iPhones. So I don't think that the iPhone 4 is going away soon.

Looking around, I see that a lot of people who can't afford (or don't want to afford) new iPhones are starting to buy used iPhones instead of cheap new phones.

te_chris2• 11 years ago

Typical tech arrogance. In the real world not everyone wants to drop $1000 on a phone just because apple tell them to, so they don't.

dcarmo• 11 years ago

I don't get it, what's the problem with Swift, iOS 7 compatibility and iPhone 4? I've been working on an app for iOS 7+ devices for a few months and everything is working ok. The pains I'm facing with Swift are far from compatibility with iOS (debugging is hell compared to Objective-C).

SiVal• 11 years ago

I think Apple's only priority for Swift is to make sure future products using future versions of iOS and OSX are more attractive to buyers than other companies' future products using future versions of Android and Windows. I think Apple is fine with the idea that the best way to target their legacy devices is with their legacy language. They're probably even okay with losing people who don't upgrade quickly as customers altogether. "Let the slow upgraders switch to Android and further fragment their market instead of ours," I can imagine them saying.

I don't get the feeling that Apple is willing to sacrifice any future benefits (including simplicity) in order to improve legacy support. More than any other company I see, they want to encourage customers to abandon the past and buy something new. If Swift doesn't work very well on iOS 7, I can't imagine that ever changing except as a side effect of fixing something for iOS 8+. It's strategic focus, not incompetence.

josephlord7• 11 years ago

The only thing that doesn't work in iOS7 (except for the new iOS8 APIs obviously) is frameworks. This can cause an issue on larger projects because the Swift compile can take some time but there are workarounds for during development. Supporting iOS7 and iPhone 4S's is no real problem in Swift.

This frameworks issue is not Swift specific though, it also applies to Objective-C although that has support for incremental builds so it isn't such an issue.

oulu20062• 11 years ago

I can't help but feel like we continue to just go backwards; Swift doesn't look like they spent much time really thinking about what they wanted to solve and how to solve it. I thought this was an interesting read: http://owensd.io/2014/09/24/swift-experiences.html

I know saying this is a bit terse, but a native Clojure compiler for iOS would have been the best thing Apple could have done -- let someone else with far better language skills who has already done a lot of thinking about values, identity, state and time solve it and then just use the work.

b3tta2• 11 years ago

Somehow it seems that currently everything happening in the USA is "Dead on Arrival" - including Swift.

This time due to shipping an utterly broken compiler to an unfinished language, without being able to contribute to it. Because if we could contribute to it, Swift might still be soon something that people love to use. But I somehow really don't believe that this will ever truly happen.

coldtea• 11 years ago

Because if we could contribute to it, Swift might still be soon something that people love to use.

Yeah. Like D, Haskell, Hurd, LaTeX3e and all the other "open for contributions" stuff that people can't get enough off...

tommi• 11 years ago

How well do you see Clojure as a language fitting in the UIKit patterns?

oulu20062• 11 years ago

Don't really see it being a problem; I don't have a lot of experience with UIKit but Clojure interacts fine with Java UI toolkits like Swing. I've also dabbled with the OpenGL Clojure wrappers and found them easy to use.

klibertp4• 11 years ago

Clojure has some very nifty features for interacting with class libraries. It has a number of macros for easy access to methods and static methods, for calling a series of methods on an object and so on. There's also `proxy` macro which let's you create a subclass of any class you want, conforming to any number of interfaces, but providing sane defaults for methods you don't need or want to implement. There's also reify, which let's you easily create classes which implement some interfaces without any overhead. There are some features which correspond to interfaces, but are somewhat more flexible (defprotocol, extend-type, reify) and then you get multiple dispatch and more.

In short I found Clojure and ClojureScript to be very easy to fit into any OO framework. It's sometimes hard to convince yourself to use those features, because you know that idiomatic Clojure solution would be better, but other than that I saw no problems at all.

But I'm not a heavy Clojure user, so it could be that I somehow lucked out and not encountered any problems which more experienced users face sometimes.

lmm• 11 years ago

Would the problems outlined there be any better in Clojure?

Type inference: at least in Swift you have types; the author dismisses "click on it in XCode", but that's still better than you get with Clojure.

nils in the Objective C bridging APIs - you're going to have to solve that somehow, even in Clojure. I don't know how Clojure invokes Java code, but you have two choices, neither of them good: either you treat every "FFI" call as returning Option, in which case all your code that calls libraries is littered with Options and you better have a syntax for easily "casting" out of Option (like the one the article complains about), or you allow nils to cross the divide into your nice language and anything that calls the "FFI" has to worry about them.

I don't have a lot of Swift experience, but it looks like a decent incremental improvement, applying some of the lessons of modern language design in a conservative Algol-style syntax that many programmers are happy to use. (I'd've been happier to see Scala support, but I can see why Apple would want their own language). Clojure isn't that (and from Apple's PoV, anyone dedicated enough to use Clojure is probably also dedicated enough to use a non-first-party language).

adrusi• 11 years ago

Remember that clojure is dynamically typed. `nil` is its own type, but in a dynamically typed language, it can still be used anywhere.

I have a slight preference for statically typed languages, but FWIW I find I make a lot fewer type errors in Clojure (and other lisps) than in, say, Javascript.

And for users who can't stand dynamic typing, there's core.typed

I don't think Clojure would have been a sane choice for Apple though. It's too memory hungry for mobile and developers would avoid it because of how different it is from objective c

stickfigure3• 11 years ago

From that article:

I’m not one that gets excited about enforcing that every item in your collection is of type String. Why? Because it does not actually matter. If an Int gets in my array, it’s because I screwed up and likely had very poor testing around the scenario to begin with.

I wish I could paste in the citizen kane slow clap gif.

mhaymo• 11 years ago

Except static typing does matter. http://evanfarrer.blogspot.ca/2012/06/unit-testing-isnt-enou...

klibertp4• 11 years ago

Considering that Apple created Dylan I'd argue that they have all the "language skills" needed. But Dylan was a failure, in part because of politics, but also because most programmers are conservative (I'd say dumb code monkeys, but this isn't exactly true) and don't like their "new" languages and tools to be "too new".

Clojure is a really great language, solving real problems in a nice way. But in language popularity charts I just checked it's far beyond first 20 entries and close to Forth(!) on one side and Erlang in the other in popularity. Clojure (and Erlang, and Forth of course, but also Haskell, OCaml, F#, Smalltalk and Io and many more) is just too new, too unfamiliar, too intimidating for our conservative programmers to consider using. And for Apple that was probably the reason for rolling out a somewhat "normal" language instead of something really good.

tempodox• 11 years ago

How can you say that languages that have been around since the 1970s are too new???

jimbokun• 11 years ago

So to avoid using a "too new" language, they invented something even newer?

wukix• 11 years ago

Not Clojure, but Lisp for iOS/Android/OSX: https://wukix.com/mocl

smackfu• 11 years ago

really thinking about what they wanted to solve and how to solve it.

What they wanted to solve was how to introduce a new more modern language that worked seamlessly with existing Objective-C libraries. People suggesting alternatives tend to forget the ObjC part of that.

austinz5• 11 years ago

The article discusses two Swift versions of the same program, one that uses UnsafeMutablePointer (which is basically direct C-style memory access), and one that uses Swift's built-in Array type. The former runs well, the latter is slow.

If you look at the Objective-C code, BackingBuffer is a C struct containing a C array of Pixels (themselves each a 32-bit C struct).

The problem is that the best analogy to Swift's Array type is not the C array in Objective-C - it's the Foundation class NSArray. For the given use case, most Objective-C developers would eschew NSArrays and classes serving as data bags in favor of fixed-length C arrays containing C structs. C arrays don't perform bounds checking, they require you to manually decide when to allocate, copy, and free the backing memory, they require you to know how much space each piece of data requires and work with the data accordingly, and so forth.

The fact that NSArrays can't hold value types, only references to classes, complicates things a bit, but I doubt the Objective-C code would be anywhere as fast if the backing store was an NSArray holding NSValues or something similar. Comparing the Swift implementation using Arrays to the Objective-C implementation using C arrays is not really fair.

mpweiher2• 11 years ago

So what should he use instead?

austinz5• 11 years ago

UnsafeMutablePointer (which is basically direct C-style memory access)

kybernetyk• 11 years ago

    UnsafeMutablePointer<UInt8>

Which he somehow dismisses but is the corresponding thing to an unsafe C array.

I'm not a big fan of Swift but this rant is rather unfounded. Sometimes you have to give up high level abstraction for performance. In Obj-C he was willing to do so by using an C array. In Swift on the other hand he insists on using the high level array implementation.

lerno8• 11 years ago

We've essentially been told to use Swift arrays as we would C arrays, so your analogy is flawed. Another premise for Swift is that it should be usable for low level, high performance programming but "safer than C". This is something we don't see in practice.

Furthermore, using UnsafeMutablePointers in Swift makes the program a magnitude larger than the corresponding C program, with no additional gain in perf, readability or safety. It is a last resort, not something you should use all of the time.

Consequently I find it hard to agree with you.

jlarocco• 11 years ago

It's odd that you said "We've essentially been told ...". Will Apple reject apps using C arrays or something?

In any case, I don't really see the problem here. Every feature of every language has some kind of performance trade off. And it's natural to expect higher level abstractions in higher level languages will have some amount of performance overhead versus lower level abstractions.

In this case, there's no shortage of alternatives, so pick one and get on with it. If it ends up being too slow, go back and look at the alternatives and swap out Swift arrays for C arrays or NSArray or whatever.

austinz5• 11 years ago

told to use Swift arrays as we would C arrays

Until you can declare a fixed-length Swift array, or a Swift array that isn't copy-on-write by default, or a fixed-length Swift array that doesn't live on the heap, this can't possibly be true, no matter what you think you've been told.

it should be usable for low level, high performance programming but "safer than C".

With optimizations turned on, the 'Swift []' code comes within 3x of the performance of the ObjC code. Lots of room for improvement, but not abysmal either.

Furthermore, using UnsafeMutablePointers in Swift makes the program a magnitude larger than the corresponding C program...It is a last resort, not something you should use all of the time.

I agree.

mikeash5• 11 years ago

I disagree. Swift arrays are analogous to both NSArray and C arrays. If they're so extremely slow then I'd consider that a bug in the compiler to hopefully be fixed as Apple improves things. There's no reason this code should be this slow.

The fact that NSArrays can't hold value types doesn't complicate things "a bit," it destroys the analogy entirely. Swift arrays can hold a bunch of references, like NSArray, or it can hold a contiguous chunk of values, like C arrays. The second option may be slow in some circumstances now, but there's no fundamental reason it has to be.

austinz5• 11 years ago

The code isn't quite as terrible if compiled with optimizations on. I like your hypothesis elsewhere in the thread, that the optimization pass is probably removing unneeded array copying that hinder the performance of the debug build.

Semantically, an Array is an automatically resizing, reference-counted, copy-on-write, bounds-checking sequence of elements, none of which I want if I'm building a buffer for pixel values. So there is a significant mismatch between my desired use case and the characteristics of Array. I really do think there should be a fixed-size non-copy-on-write collection type at some point added to the language.

From an operational perspective, you're right, the analogy is quite leaky if you examine it closely.

oofabz• 11 years ago

He has the solution to his own problem. He just needs to use the unsafe array.

People have been writing quality games for decades using unmanaged memory access. It is not some ticking time bomb that will inevitably blow up your app. It just requires a little more care to get right. Considering this guy is manipulating pixels directly and writing his own blitter, I believe he has the skills to pull it off.

I can understand why he would prefer to use managed code but it's not compatible with his goals and he has a clear alternative. His issue is not Swift's fault, it's his refusal to use the tools that Swift gives him.

lerno8• 11 years ago

In theory Swift's arrays are little more that a c array + length, and this is how we have been encouraged to use them.

The issue here is nothing about "managed code", but about how the Swift compiler behaves without any optimization passes. Currently (and it should be noted that this is a recognized issue), the unoptimized builds are orders of magnitude slower than ObjC because Swift will auto refcount code that in ObjC is either not ref counted at all, or uses manual RC. After optimization, Swift can eliminate many uses and put things on the stack etc, but we are at the mercy of the optimizer for that.

Compare this to the (compararively) predictable behaviour you have in C.

Yes we can in theory use UnsafeMutablePointer everywhere, but in that case it's much more efficient to write the function in C instead.

mikeash5• 11 years ago

I would wager that the problem is that Swift arrays aren't just a pointer plus a length, but rather a pointer plus a length plus copy-on-write semantics. You probably need some smart optimizations to eliminate the copies, and I'd put good odds on the performance problems here coming from lots of unnecessary array copies.

zelos• 11 years ago

The last benchmarks[1] I saw for Swift showed it's generally pretty slow without optimisations on, but various differences in the language from Objective C mean the compiler can optimise it much more, so generally it's faster than Objective C (and actually comparable to pure C at times[2]).

[1] http://www.jessesquires.com/apples-to-apples-part-two [2] http://www.jessesquires.com/apples-to-apples-part-three/

mpweiher2• 11 years ago

Those benchmarks (part 2) were ludicrously flawed, comparing native integers in Swift with NSNumber objects in Objective-C.

The fact that the standard library qsort() routine, which uses function pointers and pointers to the objects to be sorted in the array has overhead is also obvious, a truly native implementation is still much better[1]

[1] http://blog.metaobject.com/2014/09/no-virginia-swift-is-not-...

josephlord7• 11 years ago

One significant thing slowing this down is all the access to the the shared mutable buffer. I'm confident it would go quicker if renderWeirdGradient was changed to be a pure function that either returned a new populated buffer or had the buffer as an argument and returned the result.

An even quick fix that would have some improvement would be to make the buffer final so that less indirections are required to read and write from it.

As others have already said the unsafeMutableBuffer may be appropriate for performance critical inner loops.

josephlord7• 11 years ago

I've just tried making the buffer final and it results in a speedup of 8 times (not rigourously measured). From ~0.02 to between 0.0045 and 0.0025 on my computer.

josephlord7• 11 years ago

Pull requests sent with both suggested changes. Both have a similar speedup effect (making the buffer final is if anything the bigger effect).

josephlord7• 11 years ago

This PR puts the Swift array on terms I think:

https://github.com/owensd/handmade-swift/pull/1

The final keyword means that at least one indirection is avoided for each access to the buffer. The speedup is significant. I do wonder if there is a way that the lookup could be cached though if the compiler was a bit smarter.

There is also the option of using a pure function rather than accessing the instance buffer for fairly similar performance (see: https://github.com/owensd/handmade-swift/pull/2)

zghst• 11 years ago

Instead of wholly claiming Swift is slow (with your limited expertise in the language, as well as running no optimizations), why don't you reach out to see what you can do to improve performance? Sid you reach out to anyone to see what you can do to improve performance / if you are doing things the Swift way?

lstamour• 11 years ago

This blog post is a reaching out, and the article clearly points out that with optimizations it runs fine, but that you can't always run with optimizations enabled, e.g. when debugging or stepping through sections.

LeoNatan25• 11 years ago

I guess you couldn't be bothered to read beyond the title, could you?

geoelectric• 11 years ago

I like how he blew past the suggestion to turn off bounds checking in the comments (which I assume otherwise shouldn't affect the ability to debug), when that looks like almost certainly the reason why the array version is a couple orders of magnitude slower when unoptimized.

josephlord7• 11 years ago

I've posted this response: http://blog.human-friendly.com/the-importance-of-being-final

Separately I got excellent optimised performance with a final class and this renderWeirdGraphics method which outperforms the Objective-C version by 40% in optimised builds:

    func renderWeirdGradient(blueOffset: Int, _ greenOffset: Int) {
        let height = buffer.height
        let width = buffer.width
        buffer.pixels.withUnsafeMutableBufferPointer { pixels->() in
            for y in 0..<height {
                let row = y * width
                for x in 0..<width {
                    let i = row + x
                    pixels[i].green = Byte((y + greenOffset) & 0xFF)
                    pixels[i].blue = Byte((x + blueOffset) & 0xFF)
                }
            }
        }
        self.needsDisplay = true
    }

Swift Resistance

Related Stories