Julia_for_Pythonistas.ipynb

https://colab.research.google.com/github/ageron/julia_notebooks/blob/master/Julia_for_Pythonistas.ipynb

分享一个教程,看起来还不错的样子

1 个赞

google doc浏览感觉好慢啊,体验很差。感觉Jupyter用ipython实现注定了速度效率特别慢。很多时候得用https://nbviewer.jupyter.org/,但google doc是不行json格式不一样。
其次这个turorial也是不错的。Julia GPU的问题是要查看当前的CUDA version要和环境里面的Lib版本匹配。我写了Nix 的Julia_Install_CUDA 来解决环境问题。但是Pycall我还没配置。Rcall配置了。

可能我没理解清楚你尝试解决的问题,但这个不是 CUDA.jl 利用Julia 1.3 的Artifacts功能已经做好了么?

我做的是类似docker的版本。解决的是完全类似sandboxing 模式下的julia.所有的依赖配置和本机global的是不相干的。你可以理解为docker吧。Julia本身和包没有问题。只是我这边高场景需求版本依赖等等要全部控制的。所以做了一个Nix化的Julia。解决了CUDA flux 包的问题,然后就是Rcall 和Pycall依赖的我而你它。解决是docker julia所存在的问题

其次,我想提供一个Jupyter-lab Julia的机器地址给维护者。解决JuliaTutorial为大家测试。算是公共的测试系统,不管是嵌入R 还是Python 我都可以解决掉。


机器还是24核的,但是目前我没像公司申请GPU。其他们也可以一直系统的。
因为Julia我是源码编译的,像openblas和MKL都可以控制。

我觉得问题被你搞复杂了,为什么不直接建一个docker呢。这样构造多个jupyter kernel并没有把问题变得更简单。

Python或者R可能确实需要这样做,但是在Julia下,除了 IJulia 需要提前封装好以外,其他的Julia包管理应该都交给用户用 Pkg 来做。

JULIA_DEPOT_PATH 设置成一个公共读写的目录,很大程度上可以解决所谓缓存共享的问题。

我懂你的意思,但这并非我的目的。docker很多程度的虚拟化是封装好的,不能进一步修改包。
你可以提前阅读这篇Blog,理解一下啥是Nix-Jupyterwith。我目前完善了Julia的Nix化的问题。公共读写其实不是好事情。它并非能做到高版本控制的,我有期望去写个Julia Pkg manager to Nix (这依然需要robot和CI不停的测试最新的REV,然后prcompiling JuliaPkg.完全 sha256+rev控制。但目前我并没有太好的思路去写。所以只是单纯构建了一个nix 的Julia 包含各种依赖问题,DEPOT_PATH 到当前的目录。按理来讲,我只需要Nix 构建的Julia(可以理解为Docker)+当前目录现在precomiling的这个Julia_Pkg目录CI里 测试后,其他机器copy这个目录也是可以复现环境的。(我没测试过)。

嗯,确实不太理解你这边在做的事情,这可能和我不了解Nix能解决什么问题有关。有机会的话会去了解一下。

nix门槛还是稍微有点高,问题不大目前Julia相关我都解决了。我到手写个systemd自动化授权user就可以开放出来几个端口给大家测试了。google doc这种东西就不用了,虽然Jupyter 性能体验不是很好,但没办法的选择。我一般是emacs+org+ein写的。R有rmd还好点+rstudio.