3 ms·

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

by oofabz 12y 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.

lerno 12y 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.
- mikeash 12y 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.
  - lerno 12y ago
    I'd have to check in detail, but just looking at the profiler, about half of the time is in the actual setter code and half in bounds checking. One would think that bounds checking is a faster operation than the set if copy-on-write is the culprit? But maybe it does some other magic as well. Something you notice though is that release/retains are everywhere.

by oofabz 12y ago

lerno 12y 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.

mikeash 12y 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.
- lerno 12y ago
  I'd have to check in detail, but just looking at the profiler, about half of the time is in the actual setter code and half in bounds checking. One would think that bounds checking is a faster operation than the set if copy-on-write is the culprit? But maybe it does some other magic as well. Something you notice though is that release/retains are everywhere.