Live data from Hacker News

Swift Resistance Explored

owensd.io

11–14 of 14 posts

Re: Swift Resistance Explored

#11
post #9

One thing that i want to add is that this whole exercise is actually a straw man. You yourself start your post with "Problem Statement : Design an algorithm that fills in a buffer of pixel data" If that is the problem, then do that. Do not fill an array with Pixel object references. It is not the same problem. I am not denying that Swift has performance issues. I do think your test and proof is artificial: nobody wou…

First off, a struct is not an object. Structs in Swift, like many languages, are value types. They have the same packing structure in Swift as in C, especially in the example that I gave.

You can read more about them here: https://developer.apple.com/library/ios/documentation/Swift/...

I can write the same problem with components of the array as bytes if you prefer, but then performance will be even worse. The root cause of the performance issues is the array access and set. The more the do, the worse the performance.

So what you are saying, is that no person would ever create an array of data and expect to do anything with that data? And they would never do that in a processing loop? Ok...

If you actually read the blog post, you can see that I already gave an example using raw buffers (the UnsafeMutablePointer). Which means that every index into the pointer moves 4 bytes. Again, using UnsafeMutablePointer is not doing anything other than creating a harder API surface to work with.

Also, the UnsafePointer types exist because without them, there would be no way to interact with C code. And if I need to use the UnsafePointer types everywhere I have arrays so that I can have reasonable performance in debug and release builds, then there is a bigger problem that needs to be addressed.

Re: Swift Resistance Explored

#12
post #11
post #9

One thing that i want to add is that this whole exercise is actually a straw man. You yourself start your post with "Problem Statement : Design an algorithm that fills in a buffer of pixel data" If that is the problem, then do that. Do not fill an array with Pixel object references. It is not the same problem. I am not denying that Swift has performance issues. I do think your test and proof is artificial: nobody wou…

First off, a struct is not an object. Structs in Swift, like many languages, are value types. They have the same packing structure in Swift as in C, especially in the example that I gave. You can read more about them here: https://developer.apple.com/library/ios/documentation/Swift/... I can write the same problem with components of the array as bytes if you prefer, but then performance will be even worse. The root c…

> So what you are saying, is that no person would ever create an array of data and expect to do anything with that data? And they would never do that in a processing loop? Ok...

No. I'm saying the memory layout of Array is undefined. You cannot assume that it is a contiguous chunk of memory for example.

Therefore it is the wrong solution for a render buffer.

After reading https://developer.apple.com/swift/blog/?id=6 I am not entirely sure about this. Can you find a more clear definition?

Re: Swift Resistance Explored

#13
I wonder if creating a wrapper struct (let's call it Buffer) which combines an UnsafeMutablePointer and an UnsafeMutableBufferPointer would improve the language ergonomics while keeping the performance of the 'Swift*' version.

Buffer would have a constructor taking the number of items to store, and would upon creation create a buffer using UnsafeMutablePointer.alloc(). It would then use the UnsafeMutablePointer to build an UnsafeMutableBufferPointer. The latter type allows subscript indexing (e.g. myBuffer[10]) and iteration using for-in, which we could support by implementing a pass-through subscript() and generate() function.

Then, when using the struct, we'd pass it using inout parameters to ensure that it doesn't get copied.

This wouldn't fix the problem of Arrays being ludicrously unperformant, but it would at least make using the C-style buffer less painful.

Re: Swift Resistance Explored

#14
The Swift safe version has the benefit of not corrupting memory if you run off the end of the array. In release builds that might account for the small perf difference.

It is not accurate to claim this is comparing the Objective-C version to Swift. It's comparing the C version.

Post reply on HN