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

41–48 of 48 posts

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

#41

Post by renox »

omaranto wrote: post #11
adamnemecek wrote: post #10

Earlier quoted context omitted.

> 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. Julia's secret sauce is LLVM. Considering the guy behind Swift also made LLVM, I'm inclined to think that Swift will come out ahead.

I'd say LLVM is an important part of Julia's success but not the whole story: it is also a very well designed language.

Really? The 1-based array is really a mistake.. They should have followed Ada: allow any starting index and provide keywords to access the first/last element of the array. All this by default, otherwise it doesn't matter.

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

#42

Post by omaranto »

renox wrote: post #41
omaranto wrote: post #11

Earlier quoted context omitted.

I'd say LLVM is an important part of Julia's success but not the whole story: it is also a very well designed language.

Really? The 1-based array is really a mistake.. They should have followed Ada: allow any starting index and provide keywords to access the first/last element of the array. All this by default , otherwise it doesn't matter.

I don't pretend to understand the feelings of people who care about this issue strongly, so I won't defend the choice vigorously. But I would guess they did that because their target demographic were Fortran and Matlab users, all of whom use 1-based indices, as is usual in math books. At any rate, in Julia you rarely need to write the start index explicitly (because of functions like eachindex) and can easily start your indices anywhere you like if you feel strongly about it.

(I know that to you specifically the fact that the ability to choose the starting index is not builtin means it doesn't matter, but I point it out for others who might not know that it's easy to do in Julia.)

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

#43

Post by xiaodai »

pjmlp wrote: post #35
byt143 wrote: 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.

Reminds me of this post https://hackernoon.com/why-is-python-so-slow-e5074b6fe55b I can't say I understood everything but I also recall that Python is hard to optimise because it has such a rich object model

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

#44

Post by xiaodai »

byt143 wrote: post #14
xiaodai wrote: post #13

Earlier quoted context omitted.

Given Julia has macros, so it will definitely catch up to R and data.table in terms of syntax (if it's not already there). I am more thinking about performance, e.g see https://h2oai.github.io/db-benchmark/ . It shows that Julia is lagging behind on group-by (and from my experience many other operations) when compared to R's data.table. Although I have done some work to make thing fast see: https://github.com/xiaodai…

Ah yes, that is true. However Julia is tackling a harder problem in that the speed lag is presumably due to optimizing for custom element and table types.

"for custom element and table types" that is highly likely to be true, but unless an equally fast Julia program exists I remained scientifically skeptical. But my prior believe is that Julia can be as fast.

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

#45

Post by ChrisRackauckas »

xiaodai wrote: post #44
byt143 wrote: post #14

Earlier quoted context omitted.

Ah yes, that is true. However Julia is tackling a harder problem in that the speed lag is presumably due to optimizing for custom element and table types.

"for custom element and table types" that is highly likely to be true, but unless an equally fast Julia program exists I remained scientifically skeptical. But my prior believe is that Julia can be as fast.

DataFrames.jl doesn't parameterize on its types and tries to rely on function barriers to be fast enough. That's what gives it the speed issue. IMO this isn't the best idea. It's not difficult to write a data table that's easier to optimize than that, but you would have to give up some of the flexibility.

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

#46

Post by pjmlp »

xiaodai wrote: post #43
pjmlp wrote: post #35

Earlier quoted context omitted.

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

Reminds me of this post https://hackernoon.com/why-is-python-so-slow-e5074b6fe55b I can't say I understood everything but I also recall that Python is hard to optimise because it has such a rich object model

The same rich object model that Common Lisp, Dylan, SELF, JavaScript, Smalltalk enjoy while having JIT support.

For example in Smalltalk, you can destroy all JIT assumptions about a given object by sending a become: message.

https://gbracha.blogspot.com/2009/07/miracle-of-become.html

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

#47

Post by stochastic_monk »

Recurecur wrote: post #37
stochastic_monk wrote: post #22

Earlier quoted context omitted.

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 l…

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

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

#48

Post by KenoFischer »

stochastic_monk wrote: post #47
Recurecur wrote: post #37

Earlier quoted context omitted.

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 l…

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

It's a bit of a JIT party trick by emitting the target address directly rather than going through the PLT.
Post reply on HN