wallnuss

Yeah I know and the DWARF info special cases are even worse for ptxas. I never had enough time, but Nvidia has surprisingly a lot information on it out there.

The big difference is that Julia can handle user defined structs and handle higher-level functions, e.g. you pass a Julia function to you GPU kernel and that function will get compile for the GPU without you having to declare it GPU-compatible.

ROCm will make similar things possible! I prefer native codegen, CLArrays.jl is an excellent solution in the meantime.

I spend a while looking at debug information for NVPTX last year and came to the conclusion that it luckily dwarf, with some weird serialisation for the assembler.

The NVPTX backend would benefit imo to move towards the more general LLVM infrastructure so that emitting the dwarf info is not another special case.

You are absolutely right, an optimised C Programn would be as fast or faster than the Numpy implementation.

If you have a particular algorithm that is better expressed using 0-based indexing use https://github.com/JuliaArrays/OffsetArrays.jl

In my opinion that is the wrong question to ask. The right question is: How fast will my code be. Numpy has been heavily optimised and is written in C and not Python.

Take a look at the link below, comparing a simple sum in different languages (among them Python and Numpy). The power of Julia is that there is no privileged code. Your code will be as fast as the base library.

http://nbviewer.jupyter.org/github/alanedelman/18.337_2017/b...

* My entire codebase

Julia has great interoperability between Python (checkout PyCall.jl) and many other languages. You don't need to abandon your old codebase.

With regards to your other points, a lot of that is subjective and hard to argue about, but for me Julia has drastically changed the way I approach writing scientific code and is not just an incremental improvement upon the status quo.

how??! In what context does a clear-text password end up anywhere, except as the input for a hash function.

I am slowly preparing to depart my lovely xmonad setup for gnome due to issues with HiDPI..., but I still love the multi-screen support in xmonad.

Given that CUDAnative.jl is beating CUDA c in some benchmarks and in others it is a bit slower, I would suspect that NUMBA is similar in performance.

The thing where the Julia CUDA support really shines is that it is supporting arbitrary Julia structs and not just a blessed few datatypes like Float32.

You are right that the current adoption rate of Python makes it seem like Julia is in a losing position, but on the other hand it took Python a long time to get in to the position it is right now and systemic changes take time.

The two arguments that speak for Julia from a user perspective (there exist much stronger arguments for package developers).

a; Low overhead interoperability with Python, R, C and Fortran (and C++); You don't need to rewrite your code and you can start using Julia and slowly transition.

b; User code as fast as package/base library code. You are not stuck with what already exists.

The only sad part of this story is the design was meant to celebrate John Conway and his Game of Life [1] (Conway actually was a lecturer at Cambridge, when he introduced GoL).

[1] From 2014: http://www.railwaygazette.com/news/infrastructure/single-vie...

I see that there is a llvm backend at https://github.com/adapteva/epiphany-llvm, but it hasn't been updated in a while. Are there any plans on upstreaming/contributing and maintaining a backend for llvm?

You cannot do Pkg.update("MyPackage", but you are able to do Pkg.build("MyPackage") and Pkg.test("MyPackage").

Pkg.update() is currently designed to update the local METADATA snapshot and then update all packages. You can also update one package at a time manually with Pkg.checkout.