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