Swift Resistance
owensd.io
owensd.io
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.
UnsafeMutablePointer<UInt8>
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.
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.
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.
Judging from what the compiler team at Apple regularly write in forums and on twitter, it seems that they consider the performance issues for arrays (actually, this happens in other circumstances as well) to be a very real issue.
When you say "swap for a C array", then I suppose that you mean we allocate a chunk of memory like in C, then access it using unsafe methods (as there is no "C array" in Swift). Unfortunately, working with UnsafeMutablePointer and friends is extremely verbose and clumsy, which makes it an extremely bad experience.
Yeah and swapping to a C array isn't that simple in Swift. It seems easier to just have objective c code and call that from Swift when needed.
Conversely, treating any NSArray as an Array is always just a call to -copyWithZone (which is O(n) for mutable arrays and O(1) for immutable arrays), although the docs say that upon the first element access it type-checks the elements of the array (though presumably converting to [AnyObject] is always free).
An example of what I'm talking about would be something like
let dict = self.someDictionary // dict is a copy, not a reference
let x = dict["foo"] // this would then convert
let y = dict["bar"] // but this wouldn't
In the debug trace, it appeared that the Swift hash map got bridged over and over again every time it was to be read. Since this was a set of attributes for CoreGraphics graphics rendering, the dict/array conversion ended up costing magnitudes more than what the rendering itself did.
From what I remember, Lattner (might have been someone else on the compiler team) said that such conversion should only have needed to happen once, and not at every access to an element. Something like that.
This issue started to occur when it was no longer possible to directly create NSDictionary/NSArray from Swift.
I may also misremember things. Best would be to ask on the Apple developer forums.
Huh? You can still create NSDictionary / NSArray in Swift using the exact same API you would in Obj-C. That's always been possible. And in fact Swift even extends NSArray / NSDictionary to support the Swift literal syntax.
The current "solution" is to keep the array a Swift array, then in any performance critical code simply cast that into an unsafe pointer and work with that directly as if it was C array.
That's simply untrue (unless meant as a pointless tautology :)). There are plenty off free features and abstractions. From syntactic sugar things, to really advanced stuff like Rust's borrow checker. Even using lambdas in Rust can be cost free. (It almost seems like Rust and LLVM have created the sufficiently smart compiler.)
And even really high level languages like Haskell can do surprisingly great optimizations, so that, say, a pipeline of projections and filters costs the same as just writing the loop by hand.
For a safe array, the usually acceptable overhead is one bounds check per loop/sequence, right?
(Anyways, the article discusses non optimized builds, at which point nothing's guaranteed to be cheap, so he's really asking for more developer support tools.)
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.
In any case, the issue here with debug builds does not seem to be due to memory access nor copy-on-write, but simply because of ARC sprinkling the accesses to the array with release/retain pairs.
The reason it works ok with optimizations turned on, is because Swift will not remove unnecessary release-retain in -Onone.
This was not a great problem in ObjC, since it only affected ObjC method dispatch - which you were unlikely to do in a tight loop. Plus, ObjC ARC actually emits retain/release pairs differently.
The issue with ARC emits was discovered with the very first beta, but as of yet there has been no fix.
The problem here is probably this:
1. In order to perform a local optimization on ARC retain/release, even at -Onone, you need to change the retain/release emits to the style used by ObjC.
2. But that retain/release often incurs an unnecessary autorelease, which would prevent even an optimized Swift build from eliminating certain retain/releases.
In other words, they either get significantly better -Onone performance, or slightly worse -O/-Ounchecked performance.
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.
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.
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.
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.
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.
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)
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.
One was closed as a duplicate. For another one they requested additional information.
The other 5 reports received no response at all.
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.
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.
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.
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
}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.
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.
Yeah. Like D, Haskell, Hurd, LaTeX3e and all the other "open for contributions" stuff that people can't get enough off...
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.
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).
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
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.
I try to stay away from memes and the likes, so unless it is pretty obvious, they usually go over my head :)
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.
The fact that objectively some of those languages come from '50s and '60s (like Lisp in '56 and ML in '63 IIRC), which makes them ancient by today's standards, doesn't matter. It's really sad. I devoted a couple of years to learning about and trying to use such languages (see here[1] if you want) but I'm in a very small minority; most young programmers never use anything other than 1-3 core languages they learned; the number of known languages increases with years of experience, but it's still biased towards currently mainstream languages. Which are mostly crap.
Anyway, that's how it is: most programmers are very conservative in their choice of tools they use and feel no need to look for alternative tools to use.
I don't want to spend too much time discussing this, but I read Swift guide[1] and even played with it in Playground, and I'm 97% sure that every single Swift feature is borrowed from currently mainstream languages.
There's a difference between "oh, it's like feature X in C#" and "well, didn't Common Lisp implement Y 30 years ago?". Feature X will be perceived as nothing new, merely catching up; Y will be seen as new, dangerous, cryptic and best avoided. I think Swift designers intentionally packed their language with Xes and added almost no Ys, exactly because they didn't want it to seem as "too new, esoteric, unproven" and so on so forth. This is a sane business decision, by the way, I just happen to dislike 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.
[1] http://www.jessesquires.com/apples-to-apples-part-two [2] http://www.jessesquires.com/apples-to-apples-part-three/
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-...
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
Seems pretty simple to me. Skate to where the puck is going.
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.
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.
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.