Live data from Hacker News

High Performance Numeric Programming with Swift: Explorations and Reflections

fast.ai

31–40 of 48 posts

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

#31
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.

Presumably Objective-C/Cocoa compatibility. Although I'm wouldn't be able to tell you why that would require non-contiguous storage... surely @NSArray is contiguous?

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

#32

Earlier quoted context omitted.

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.

Presumably Objective-C/Cocoa compatibility. Although I'm wouldn't be able to tell you why that would require non-contiguous storage... surely @NSArray is contiguous?

https://ciechanow.ski/exposing-nsmutablearray/

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

#33
post #7

Thanks for writing up your thoughts! I find Julia's core design to be excellent for general purpose programming, better than python in fact since it essentially solves the expression problem with it's type system and multiple dispatch. It's external program interop is also more pleasant than Python's : https://docs.julialang.org/en/v1/manual/running-external-pro... Sure, it doesn't have the same general library ecosy…

Oh my, the Julia brigade again...

Geez, it's impossible to read a numeric programming article in HN without the Julia brigade jumping in with their heavy proselitism. The worst part is that by bad-mouthing R and Python they think they will achieve widespread acceptance... so sad

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

#35
post #7

Thanks for writing up your thoughts! I find Julia's core design to be excellent for general purpose programming, better than python in fact since it essentially solves the expression problem with it's type system and multiple dispatch. It's external program interop is also more pleasant than Python's : https://docs.julialang.org/en/v1/manual/running-external-pro... Sure, it doesn't have the same general library ecosy…

I am betting Julia will finally make Python community take JIT as standard feature seriously.

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

#36
post #35
post #7

Thanks for writing up your thoughts! I find Julia's core design to be excellent for general purpose programming, better than python in fact since it essentially solves the expression problem with it's type system and multiple dispatch. It's external program interop is also more pleasant than Python's : https://docs.julialang.org/en/v1/manual/running-external-pro... Sure, it doesn't have the same general library ecosy…

I am betting Julia will finally make Python community take JIT as standard feature seriously.

They do, there have been several high profile projects to make a JIT for python... The problem isn't, that JITs aren't taken seriously - the problem is, that python isn't designed for a JIT, so it's very hard to get the advantages of using one

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

#37
post #20

Earlier quoted context omitted.

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.

I think Julia is the dark horse to eventually take over a wide swath of computing - possibly wider than Java or C++. As others have pointed out there's an effort to produce static Julia executables, and I think it's already possible to produce libraries. One interesting datapoint is that Julia's C FFI is faster than that of C++...

https://github.com/dyu/ffi-overhead

(For those interested, the order of the first few languages is: lua-jit, julia, c(!), c++, zig, nim, d in order of decreasing speed.)

It's extremely well thought out, concise, powerful, and readable. I think Julia's approach to types and multiple dispatch is a better alternative to traditional OO programming.

One thing the author didn't point out is that C++ (clang), Swift, Rust and Julia all use the LLVM infrastructure, resulting in extremely similar if not identical code generation. If datacenter efficiency truly becomes a priority, highly efficient languages like Julia, Rust and Swift will see increasing use for general purpose programming.

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

#38
post #35

Earlier quoted context omitted.

I am betting Julia will finally make Python community take JIT as standard feature seriously.

They do, there have been several high profile projects to make a JIT for python... The problem isn't, that JITs aren't taken seriously - the problem is, that python isn't designed for a JIT, so it's very hard to get the advantages of using one

I am well aware of PyPY and friends.

My point is about making JIT a standard feature of CPython.

JavaScript, Dylan, Smalltalk, SELF, Common Lisp aren't less dynamic than Python.

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

#39
post #38

Earlier quoted context omitted.

They do, there have been several high profile projects to make a JIT for python... The problem isn't, that JITs aren't taken seriously - the problem is, that python isn't designed for a JIT, so it's very hard to get the advantages of using one

I am well aware of PyPY and friends. My point is about making JIT a standard feature of CPython. JavaScript, Dylan, Smalltalk, SELF, Common Lisp aren't less dynamic than Python.

Yeah, I'm just trying to point out, that not much would be won by that.

You either need to change the semantic of the language (CPython) or live with a slow JIT for some of the most used features of the language... And changing the semantic of the language is pretty terrible - it fragments your libraries introduces unbreakable borders prohibiting cross package optimizations and extensability, and much worse, CPython is now basically a language that combines the bad stuff of python and C ;) I know, that's a bit too cynical, but coming from a well designed language for JIT (Julia), that's how CPython starts looking to me. You will simply never reach the elegance of a language that was designed from scratch for this.

What I want to point out is, that the whole topic is bigger than "JIT my one slow function and make it fast"! A good read about this topic is: http://www.stochasticlifestyle.com/why-numba-and-cython-are-...

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

#40
post #38

Earlier quoted context omitted.

They do, there have been several high profile projects to make a JIT for python... The problem isn't, that JITs aren't taken seriously - the problem is, that python isn't designed for a JIT, so it's very hard to get the advantages of using one

I am well aware of PyPY and friends. My point is about making JIT a standard feature of CPython. JavaScript, Dylan, Smalltalk, SELF, Common Lisp aren't less dynamic than Python.

And sorry for hijacking your perfectly fine comment - of course it would help python to embrace modern compiler technologies! ;) It's just always a bit maddening to see how much effort and money is spent on creating imense projects for python, just to catch up with Julia - while turning python pretty much into a jitted frankenstein monster, to cover use cases it was never designed for ;)
Post reply on HN