
High Performance Numeric Programming with Swift: Explorations and Reflections - parrt
https://www.fast.ai/2019/01/10/swift-numerics/
======
Someone
One thing to look out for is that Swift Arrays aren’t really arrays.
[https://www.raywenderlich.com/1172-collection-data-
structure...](https://www.raywenderlich.com/1172-collection-data-structures-
in-swift):

 _”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...](https://developer.apple.com/documentation/swift/contiguousarray):

 _”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”_

~~~
gameswithgo
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.

~~~
nicoburns
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?

~~~
superlopuh
[https://ciechanow.ski/exposing-
nsmutablearray/](https://ciechanow.ski/exposing-nsmutablearray/)

------
byt143
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...](https://docs.julialang.org/en/v1/manual/running-external-
programs/#Running-External-Programs-1)

Sure, it doesn't have the same general library ecosystem, but even that is
being remedied for core areas like web programming:
[http://genieframework.com/](http://genieframework.com/) (a full MVC
framework),
[https://github.com/JuliaGizmos/WebIO.jl](https://github.com/JuliaGizmos/WebIO.jl)
(write front end code without javascript) and I'm particularly excited for
[https://github.com/Keno/julia-wasm](https://github.com/Keno/julia-wasm),
which will allow Julia programs to be compiled for the browser.

For any packages than are python only, it has excellent python interop using
the pycall.jl package, which even allows users to write custom python classes
in Julia.

With regards to numerical programming, it's obviously already far ahead of
swift, and IMO much better placed to beat it in the long run. For example the
WIP zyogte package is able to hook into Julia's compiler to zero overhead diff
arbitrary code. Using Cassette.jl, package authors can write custom compiler
passes outside the main repo and in pure Julia:
[https://julialang.org/blog/2018/12/ml-language-
compiler](https://julialang.org/blog/2018/12/ml-language-compiler)

In addition, it's macro system, introspection, dynamic typing and value types
through abstract typing approach allows for natural development of advanced
probabilistic programming languages:
[https://github.com/TuringLang/Turing.jl](https://github.com/TuringLang/Turing.jl),
[https://github.com/probcomp/Gen](https://github.com/probcomp/Gen),
[https://github.com/zenna/Omega.jl/pulse](https://github.com/zenna/Omega.jl/pulse)

~~~
xiaodai
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!

~~~
currymj
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.

~~~
stochastic_monk
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.

~~~
Recurecur
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](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.

~~~
stochastic_monk
Do you know how Julia gets such great ffi performance? Is it inlining, for
instance?

~~~
KenoFischer
It's a bit of a JIT party trick by emitting the target address directly rather
than going through the PLT.

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

~~~
claytonjy
Jeremy, if you're up for it, could you talk any more about your explorations
of Julia?

I see (and agree with) your point about worse non-numeric stuff, but if you
stand back and squint I get the impression Julia does most of what you applaud
here, with the added benefits of a more transparent compiler and a more
numeric-focused community (no need for BasicMath there!).

In particular, Flux.jl seems like a fairly direct competitor of S4TF, and this
blogpost [0] really blew me away.

[0] [https://www.julialang.org/blog/2018/12/ml-language-
compiler](https://www.julialang.org/blog/2018/12/ml-language-compiler)

~~~
xiaodai
The post says Julia is not good for general purpose programming. I think it is
good for that, it's just that it does not have as many packages as Python,
that's all. I will offer one reason, Julia syntax is actually very much like
Python's in many respects. So how can Python be good for general purpose
programming but Julia not? So if the sentence is more like, Julia doesn't have
as many packages for general programming then I think it's more precise

~~~
jph00
That sounds totally fair. I haven't used Julia for a couple of years so my
comments on it are dated and not well informed. Everyone I know that uses
Julia nowadays loves it.

------
abalone
Key point here is Chris Lattner is working on this stuff. He’s the creator of
Swift and LLVM and one of the smartest minds in the industry. Pay atttention.

