vchuravy

Arrested is not the same as convicted. I lived in Japan for a few years, and I have heard of similar situations to what the article describes.

In Japan you can be arrested while an investigation is in process, only afterwards you will be indicted. Additionally, Japan does not permit defendants to post bail prior to an indictment.

Yes Japan has a really high conviction rate, but that is because they indict only cases were a conviction is likely.

Arrests don't need to lead to the person being indicted.

My point is if you set JULIA_CPU_TARGET during the docker build process, you will get relocatable binaries that are multi-versioned and will work on other micro-architecture? It's not just for PackageCompiler, but also for Julia's native code cache.

I am very interested in improving the user-experience around precompilation and performance, may I ask why you are creating a sysimage from scratch?

> I would opt into prebuilt x86_64 generic binaries if Julia had them

The environment varial JULIA_CPU_TARGET [1] is what you are looking for, it controls what micro-architecture Julia emits for and supports multi-versioning.

As an example Julia is built with [2]: generic;sandybridge,-xsaveopt,clone_all;haswell,-rdrnd,base(1)

[1] https://docs.julialang.org/en/v1/manual/environment-variable...

[2] https://github.com/JuliaCI/julia-buildkite/blob/9c9f7d324c94...

Very cool. Does the dynamic instrumentation handle JIT emitted code?

We use RR a lot with Julia. It only gives you a GDB view of the system, but it can work with any interpreted or compiled language.

Things that don't work are drivers that update mapped addresses directly. An example of this is CUDA in order to replay one would need to model the driver interactions (and that's even before you get to UVM)

Another great thing is that RR records the process tree and so you can easily look at different processes spawned by your executable.

Ah but what defines madness? For me it's innocuous functions that have surprising/wild behavior due to type inference disagreeing with me.

Most of the time I am the one wrong.

Yeah in the end this the difference between dynamical and static typing.

I enjoy https://tratt.net/laurie/research/pubs/html/tratt__dynamical... as a discussion of dynamic typing.

One of the authors here, happy to answer questions.

> And dealing with bugs in LLVM is basically a no-go, I've seen this happen in the Julia ecosystem as well.

As one of the folks dealing with LLVM bugs in the Julia ecosystem.

Yes it requires a distinct skillet different from working on the higher-level Julia compiler and yes it can sometimes take ages to merge bugfixes upstream, but we actually have a rather good and productive relationship with upstream and the project would get a lot less done if we decided to get rid of LLVM.

In particular GPU support and HPC support (hello PPC) depends on it.

But this is also why we maintain the stance that people need to build Julia against our patchset/fork and will not invest time in bugs filled against Julia builds that didn't use those patches. This happens in particular with distro builds.

Yeah I often describe Julia as a Lisp in sheep's clothing.

Or as the m-Lisp promised to us :) I chuckled when I read:

> The way that common Lisp systems produce executable binaries to be used as application deliverables is by literally dumping the contents of memory into a file with a little header to start things back up again.

Which is pretty much of Julia's sys-/pkgimages work. Pkgimages are an incremental variation on this idea.

One of the novelties in Julia is the world-age system and the limits on dynamisim it introduces on eval.

Yes that is precisely what was fixed, essentially the thread local storage that Julia was expecting were not setup and thus calling the runtime from a foreign thread would cause a crash.

This now enables to dynamically add and remove threads.

How closely tied is this to Python? The need for reactivity is what drove the development for Pluto.jl, but it would be nice to have something like this for IJulia.jl as well.

How closely tied is this to Python? The need for reactivity is what drove the development for Pluto.jl, but it would be nice to have something like this for IJulia.jl as well.

Don't ask me about GNU_UNIQUE...

Due to some wonderful C++ features the dynamic linker is forced to unify symbols across shared libraries, even if those symbols have different versions.

This utterly breaks loading multiple libLLVM's except if you build the copy you care about with -no-gnu-unique (or whatever the flag was called)

I have seen wonderful things like the initializers of an already loaded libLLVM being rerun when a new one is loaded.

Also Be-sharper would have been a great pronouciation.

- Jupiter: Yes, Julia was one of the first non-python IPython/Jupiter kernel - Pandas: DataFrames.jl - Numpy: Basically the available as part of the stdlibs/language - Scipy: Yes, but not as one meta package - Matplotlib: Yes directly as Pyplot.jl or in alternatives such as Plots.jl or Makie.jl

- Pytorch/Tensorflow: There are several ML Frameworks written in Julia (as well as Julia bindings to ML Frameworks) the biggest Julia native one is likely Flux.jl

Regarding HF Transformers a quick Google points to https://github.com/chengchingwen/Transformers.jl but I have not had any personal experience with.

All of this is build by the community and your mileage may vary.

In my rather biased opinion the strengths of Julia are that the various ML libraries can share implementations, e.g. Pytorch and Tensorflow contain separate Numpy derivatives. One could say that you can write an ML framework in Julia, instead of writting a DSL in Python as part of your C++ ML library. As an example Julia has a GPU compiler so you can write your own layer directly in Julia and integrate it into your pipeline.

Take a look at `juliaup`. It's allows you to manage multiple Julia versions and makes you independent of the distribution.

I did the manual setup the other day since I wanted to try using my steam deck as a Road-Warrior build server.

The whole systemd-sysext seems like a good way to make that happen.

> A better calculator language

Especially with reactive programming as an ask there, I would recommend Julia with Pluto.jl (Pluto is a reactive notebook).

> A really dynamically-typed language

Julia ;) It is really dynamic, has meta-programming (macros + staged functions), solid semantics around eval/invokelatest that still allow for optimizations and you can add types at runtime (not modify them though).

Yes because Microsoft got a special license from Apple that allows for the virtualization of Mac OS on non Apple hardware...

The rest of us is still running on racks of Mac Minis

If you look at the contribution activity it dropped off after acquisition of GitHub by Microsoft and it seems that development was redirected to VSCode.

The writing was on the wall for a long while now, and was one of the reasons why the JuliaCommunity stopped advocating Juno/Atom as a platform and instead switched to VSCode

I think https://github.com/rr-debugger/rr/issues/2034#issuecomment-6... is the right synopsis.

If you are using Julia I would recommend looking at AMDGPU.jl and (pluging my own project here) KernelAbstractions.jl

"Just godbolt it" has indeed become a phrase in my circle. Compiler explorer is a great reminder that sometimes it is indeed about the UX for system tools that allows you to make a huge impact

In Julia

``` using Dates julia> lastdayofmonth(today()) 2022-02-28 ```

But that's function oriented programming for you.

They are the same binary and on on Linux they are just soft-links.

One important note is that the blog is quite old. CUDAnative and CUDAdriver got folded into https://github.com/JuliaGPU/CUDA.jl

Especially the fact that loading a library compiled with GCC and fast math on, can modify the global state of the program... It's one of the most baffling decisions made in the name of performance.

I would really like for someone to take fast math seriously, and to provide well scoped and granular options to programmers. The Julia `@fastmath` macro gets close, but it is two broad. I want to control the flags individually.

Also the question how that interacts with IPO/inlining...

Probably more this talk about CUDA 3.0 https://live.juliacon.org/talk/UGX8YR or the workshop https://www.youtube.com/watch?v=Hz9IMJuW5hU

> Julia is also behind on the version of LLVM that is being used,

Julia 1.6 (LLVM 11) and Julia 1.7 (LLVM 12) use the LLVM versions that were current, when the release branch was cut. LLVM 13 was finalized a fes days ago and will be released this week.

So I am not sure where the notion comes from that Julia is lagging behind.