Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

High Performance Numeric Programming with Swift: Explorations and Reflections

fast.ai

Post reply on HN
Print view View original

21–30 of 48 posts

Re: High Performance Numeric Programming with Swift: Explorations and Reflections

#21

Post by jph00 »

slowswift wrote: post #15
jph00 wrote: post #2

Hello folks! I wrote this article - so if you have any questions, feel free to shoot them my way. :)

Curious if you ever benchmarked your approach vs, say, going through `Array`/`ContiguousArray` (I think these are slated to converge eventually, FWIW) and using the [`withUnsafeMutableBufferPointer(_:)`]( https://developer.apple.com/documentation/swift/array/299477... calls? You've gotten into a place with a lot of unidiomatic designs--direct pointer access on COW types, etc.--and it's not clear how much is really ne…

What I'm doing is essentially the same as `withUnsafeMutableBufferPointer`. However I didn't find a way to get concise abstractions using that approach.

Re: High Performance Numeric Programming with Swift: Explorations and Reflections

#22

Post by stochastic_monk »

currymj wrote: post #20
xiaodai wrote: post #8

Earlier quoted context omitted.

Agree with everything you've said, it's hard to see why one would prefer Swift over Julia for numerical computing. I use Julia for it's regex too; it's just nicer. Hopefully, the data munging packages in Julia can catch up to dplyr and data.table, then we are talking!

I am a happy Julia user, but I can imagine if you had a use case where you wanted to compile a binary or shared library, Julia could be a pain. C++ of course works fine for this but I imagine Swift would be less terrifying to use.

I see a lot of great numerical code in Julia. As a C++ developer, I don’t want to deal with a runtime or various parts of the language, but I imagine I could be more easily brought to the table if Julia code could be exported to a shared object file and linked against, or if it could compile to a direct binary.

Re: High Performance Numeric Programming with Swift: Explorations and Reflections

#23

Post by byt143 »

currymj wrote: post #20
xiaodai wrote: post #8

Earlier quoted context omitted.

Agree with everything you've said, it's hard to see why one would prefer Swift over Julia for numerical computing. I use Julia for it's regex too; it's just nicer. Hopefully, the data munging packages in Julia can catch up to dplyr and data.table, then we are talking!

I am a happy Julia user, but I can imagine if you had a use case where you wanted to compile a binary or shared library, Julia could be a pain. C++ of course works fine for this but I imagine Swift would be less terrifying to use.

I think it will happen in the medium term future:

https://juliacomputing.com/blog/2016/02/09/static-julia.html https://github.com/JuliaComputing/static-julia https://github.com/JuliaComputing/llvm-cbe

Re: High Performance Numeric Programming with Swift: Explorations and Reflections

#24

Post by lgg »

jph00 wrote: post #2

Hello folks! I wrote this article - so if you have any questions, feel free to shoot them my way. :)

Interesting article, but I have one nit. I don't think your reasoning behind why Objective C does not support overloading is sound. Selectors are completely incompatible with C function names anyway. For example, they are only relevant in the context of classes (which do not exist in C), or example they allow characters that are illegal in C function names in symbols (like ':').

The bigger issue is that to overload a function in a manner similar to C++ you need to have accurate type information, which historically was not available in Objective C since it relies heavily on duck typing and casting objects back through id. If such strong type information was available then the type data could have simply been mangled into the selector by the compiler the same way it is mangled into the symbol name in C++. I suspect that duck typing allowed a lot of productivity and memory wins in the 90s, and that most compilers of the era were not capable of exploiting the strong typing information to optimize as aggressively as they do now, meaning that it was probably the right trade off for the time.

I suppose an alternative implementation of overloading could have been implemented by having objc_msgSend dynamically query the types of all parameters which are overloaded, but that would have resulted in a huge performance hit on every dynamic message dispatch.

Re: High Performance Numeric Programming with Swift: Explorations and Reflections

#25

Post by Someone »

One thing to look out for is that Swift Arrays aren’t really arrays. https://www.raywenderlich.com/1172-collection-data-structure...:

”1. Accessing any value at a particular index in an array is at worst O(log n), but should usually be O(1).

2. Searching for an object at an unknown index is at worst O(n (log n)), but will generally be O(n).

3. Inserting or deleting an object is at worst O(n (log n)) but will often be O(1). These guarantees subtly deviate from the simple “ideal” array that you might expect from a computer science textbook or the C language, where an array is always a sequence of items laid out contiguously in memory”

If you want a more traditional data structure, use ContiguousArray, which is an array. https://developer.apple.com/documentation/swift/contiguousar...:

”The ContiguousArray type is a specialized array that always stores its elements in a contiguous region of memory. This contrasts with Array, which can store its elements in either a contiguous region of memory or an NSArray instance if its Element type is a class or @objc protocol”

Re: High Performance Numeric Programming with Swift: Explorations and Reflections

#26

Post by slowswift »

jph00 wrote: post #21
slowswift wrote: post #15

Earlier quoted context omitted.

Curious if you ever benchmarked your approach vs, say, going through `Array`/`ContiguousArray` (I think these are slated to converge eventually, FWIW) and using the [`withUnsafeMutableBufferPointer(_:)`]( https://developer.apple.com/documentation/swift/array/299477... calls? You've gotten into a place with a lot of unidiomatic designs--direct pointer access on COW types, etc.--and it's not clear how much is really ne…

What I'm doing is essentially the same as `withUnsafeMutableBufferPointer`. However I didn't find a way to get concise abstractions using that approach.

It is essentially the same, sure. We have some specialized in-house structs-of-arrays things for doing bulk geometry operations that (behind the scenes) go through `withUnsafeMutableBufferPointer` (etc.) for everything; we keep the code idiomatic, mutation only happens in methods that are marked as mutating, COW still works, and so on.

Thus we hadn't even considered just exposing the pointer and doing it C-style, whence the question as to whether you'd benchmarked the difference between the two.

The abstractions thing is hard, here, the key seems to be defining the bulk operations in terms of pointers (or Swift's "buffer pointers"), essentially what you have in your methods like `SupportsBasicMath.add` and so on. Abstraction is possible here by moving each "type signature"--destination & 1 source? destination & 2 sources? etc.--into "operation protocols", and then having fewer methods but a ton of "operation protocol implementations". Perhaps "more abstraction", definitely not concise. Very dependent on the compiler and inlining, too.

It's a good writeup nonetheless, was just asking a narrow question.

Re: High Performance Numeric Programming with Swift: Explorations and Reflections

#27

Post by jph00 »

slowswift wrote: post #26
jph00 wrote: post #21

Earlier quoted context omitted.

What I'm doing is essentially the same as `withUnsafeMutableBufferPointer`. However I didn't find a way to get concise abstractions using that approach.

It is essentially the same, sure. We have some specialized in-house structs-of-arrays things for doing bulk geometry operations that (behind the scenes) go through `withUnsafeMutableBufferPointer` (etc.) for everything; we keep the code idiomatic, mutation only happens in methods that are marked as mutating, COW still works, and so on. Thus we hadn't even considered just exposing the pointer and doing it C-style, whe…

The pointer approach allows for brevity and idiomatic swift at the place of use. The verbosity behind the scenes need not bother the user.

Because I couldn't find anything that provides that using the approach you are discussing, I didn't investigate its performance characteristics. For me, dev UX comes first, and I wouldn't personally be interested in reading or writing in a language that requires the "with" construct wrapping every calculation.

Re: High Performance Numeric Programming with Swift: Explorations and Reflections

#28

Post by jph00 »

lgg wrote: post #24
jph00 wrote: post #2

Hello folks! I wrote this article - so if you have any questions, feel free to shoot them my way. :)

Interesting article, but I have one nit. I don't think your reasoning behind why Objective C does not support overloading is sound. Selectors are completely incompatible with C function names anyway. For example, they are only relevant in the context of classes (which do not exist in C), or example they allow characters that are illegal in C function names in symbols (like ':'). The bigger issue is that to overload a…

Very interesting perspective - many thanks for sharing.

Re: High Performance Numeric Programming with Swift: Explorations and Reflections

#29

Post by jph00 »

Someone wrote: post #25

One thing to look out for is that Swift Arrays aren’t really arrays. https://www.raywenderlich.com/1172-collection-data-structure... : ”1. Accessing any value at a particular index in an array is at worst O(log n), but should usually be O(1). 2. Searching for an object at an unknown index is at worst O(n (log n)), but will generally be O(n). 3. Inserting or deleting an object is at worst O(n (log n)) but will often b…

"If the array’s Element type is a struct or enumeration, Array and ContiguousArray should have similar efficiency."

Re: High Performance Numeric Programming with Swift: Explorations and Reflections

#30

Post by gameswithgo »

Someone wrote: post #25

One thing to look out for is that Swift Arrays aren’t really arrays. https://www.raywenderlich.com/1172-collection-data-structure... : ”1. Accessing any value at a particular index in an array is at worst O(log n), but should usually be O(1). 2. Searching for an object at an unknown index is at worst O(n (log n)), but will generally be O(n). 3. Inserting or deleting an object is at worst O(n (log n)) but will often b…

My instinct is to find this horrifying. Is there a good reason for this?

If I have an array of ints, is it contiguous?

Especially with modern computers and how importance data locality is the name "array" is kind of sacred. If you want a fancy weird-non array give THAT the longer, annoying name.

Post reply on HN