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.
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".
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.
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.
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.
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.
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.