wallnuss

Julia has an interesting split here, it does the lowering into SSA from in pure Julia and then has a codegen steps that translates the SSA from into LLVM IR, but for that second step we do use the C++ API. We have very robust bindings to the C-API, but it forever feels just a bit incomplete and less cared for. The C-API is very stable, whereas the C++ API does change quite a bit.

Arcanist is a but of a bother, but please do submit the patch.

Having recently had the pleasure of having to debug JIT-compiled code with an ABI mismatch, I can't overstate how useful `rr` (https://github.com/mozilla/rr) can be to debug assembly. The ability to `rsi` e.g. reverse step instruction is very powerful.

One tool that I started exploring is https://pernos.co/, the ability to do dataflow analysis is super cool. Let's you easily answer the question "How did this value get into this register".

Julia is particularly sensitive to LLVM compile times. LLVM 11 did improve those over LLVM 10 (which had noticeable regressions versus LLVM 9). As an example see https://github.com/JuliaLang/julia/issues/37915#issuecomment...

I don't disagree with the sentiment, but using the moon as an example is a bit far-fetched, as well as the metric being time. I thinkl it would be fair to say: Using the same amount of resources, how hard is it to reach a given point?

There is always someone who will fly a helicopter into the remote outback...

is very possible to be trapped by weather for days, weeks, even months. That is more remote than any island.

Except those islands that you can't reach due to weather for days, weeks or, even months...

It all depends on which optimizations you enable and LLVM is very flexible, albeit sometimes you still spend 20% of your time in ISel (Instruction Selection)...

It's being worked on. I am rather excited for the upcoming work that makes the parser replaceable and allows us to actually give good syntax errors! There is some discussion about making error printing more configurable so that one can skip stack-frames that are unlikely to be the cause (albeit that's a double-edged sword).

I recently spend two weeks on and off hunting down a bug on a platform that didn't support `rr`. I am fairly confident to say that if I had `rr` available it would have taken me a couple of hours at most.

Being able to run backwards from the point of failure and understand where a value is coming from is very powerful.

Having this available in Julia directly is great, and will make it much easier to get bug-reports from users.

We are indeed interested in targeting AMD GPUs. There is a prototype backend available at https://github.com/JuliaGPU/AMDGPUnative.jl and we are closely following the status of SPIR-V and Intel GPUs in LLVM.

The focus on CUDA comes from the fact that most HPC systems for scientific computing are using Nvidia GPUs. That is finally slowly changing.

Über just means above. So "über dir" is "above you". Urban dictionary has uber in english to mean superior, but that is not the original German meaning.

It's not about Upwork intentionally skewing the results as you pointed out, but that there is a potentially sampling bias. Upwork might only attract certain kinds of programming jobs and those are less likely to use Go and Rust.

As far as I know he bought that license for one of his student at the time, Alan Edelman, who then ended up co-creating the Julia language.

I especially use rr as an exploration tool. It allows me to ask not the question "Where does the program go from here", but rather "Where did it come from".

I couldn't do my daily work without rr, since often I work with systems that are large and complex and I didn't write myself.

It does by default so you can use gdb/lldb and perf on Julia code.

If Intel had one, they would have further consolidated their hold on the HPC/Supercomputer market. Summit is an interesting supercomputer because it's NVidia/Mellanox/IBM instead of the Intel hegemony that Cori II was, iirc the interconnect for Cori was from Cray.

Now NVidia only needs to buy Xilinx...

I particularly enjoy that Flux.jl is an AD framework and a couple lines of Julia code defining convenience functions for ML, and it is all written in Julia so it invites exploration.

Tim Besard gave a talk at a Tensorflow meetup recently that walked through the Julia stack (GPU&ML) that I would highly recommend: https://docs.google.com/presentation/d/1y93Kg8ZizvabKAGs-zmA...

You can revoke OAuth tokens at https://accounts.google.com/b/0/IssuedAuthSubTokens?hl=en

Take a look at CUDAnative.jl (https://github.com/JuliaGPU/CUDAnative.jl) which uses the NVPTX LLVM backend to compile Julia code to the GPU. What you described sounds very similar to that and could definitely made to work.

One of the author here. Working on this paper was fun, one of the most interesting lessons I learned was that divergence on GPUs has dramatically fallen in cost on modern architectures.

There is also llvm-mca, which is kinda neat since it uses the I formation that LLVM has about the op cost. Contrasting that to IACA or OACA is valuable as well.

Julia has `widemul` which takes two `Int64` and produces an `Int128`. It is also not to hard to actually add your own primitive type for `Int256` (with the caveat that it needs support from LLVM, which I haven't checked)

Also the report (in German) [1] that the original release deadline was May 7th, but Intel has asked for another 14 days of leniency.

[1] https://www.heise.de/security/meldung/Spectre-NG-Intel-versc...

One of the things that Nvidia quite successfully did (and Intel to some extent) is a ridiculously good academic outreach program. Making it easy (and cheap) for students and researchers to use you hardware leads to long-term buy-in.

IACA is awesome to understand the behaviour of your own hot loops. Sadly it only works on Intel. Luckily LLVM has recently merged llvm-mca [1] (machine-code analyser) which hopefully will in time bring all the features of IACA and more to other platforms as well.

I am working on making these tools easily accessible from Julia [2] and one of the things missing from llvm-mca is the ability to mark a region of assembly code to be analysed instead of analysing the entire provided assembly.

[1] https://llvm.org/docs/CommandGuide/llvm-mca.html [2] https://github.com/vchuravy/IACA.jl

Working on it :) I will probably announce it on twitter (@vchuravy) once I managed to find time to finish it.

I still don't quite see why you wouldn't just use a named struct, but you can create a alias for the NamedTuple type

    const MyAlias = NamedTuple{(:a, :b),Tuple{Int64,Int64}}
    MyAlias((2, 3)) # (a = 2, b = 3)

Threads.@threads is still consider a bit experimental and there are a few performance pitfalls that one can stumble into. I talked about this for a bit in http://slides.com/valentinchuravy/julia-parallelism, but if you still have issues after reading that feel free to reach out on https://discourse.julialang.org and we will figure out what is going on.

Important to note that the 0.7 release is not quite done yet and we are polishing it. So there is no official release candidate yet.

My favourite sentence is: Note: I've never actually tried this, so we'll just assume it works.

The blog is fun introduction into JIT compiler, but the big thing that is missing and that makes Python a hard problem for JIT is supporting Objects. From http://blog.kevmod.com/2017/02/personal-thoughts-about-pysto...

    I'll try to just talk about what makes Python hard to run quickly (especially as compared to less-dynamic languages like JS or Lua).

    The thing I wish people understood about Python performance is that the difficulties come from Python's extremely rich object model, not from anything about its dynamic scopes or dynamic types.  The problem is that every 
    operation in Python will typically have multiple points at which the user can override the behavior, and these features are used, often very extensively.  Some examples are inspecting the locals of a frame after the frame 
    has exited, mutating functions in-place, or even something as banal as overriding isinstance.  These are all things that we had to support, and are used enough that we have to support efficiently, and don't have analogs in 
    less-dynamic languages like JS or Lua.