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.
High Performance Numeric Programming with Swift: Explorations and Reflections
31–40 of 48 posts
Re: High Performance Numeric Programming with Swift: Explorations and Reflections
#32Earlier 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?
Re: High Performance Numeric Programming with Swift: Explorations and Reflections
#33Thanks 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…
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
#34Re: High Performance Numeric Programming with Swift: Explorations and Reflections
#35Thanks 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…
Re: High Performance Numeric Programming with Swift: Explorations and Reflections
#36Thanks 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
#37Earlier 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.
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
#38Earlier 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
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
#39Earlier 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.
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
#40Earlier 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.