LTO 只能算 object code level 的 whole program optimization，別的编程语言如 SML 可以在高級表示上做，和 LTO 可以分开。
1 个赞
LLVM是在IL的级别上做的
其实我根本没看他贴的链接，只是想当然觉得是在抬杠在编译期可以完成多少工作。理论上讲只要输入是确定的，那100%的工作都可以在编译期完成。但实际上在要求性能的场合基本上都是用C/C++在做，最近也有一些用Rust做的。但是动态语言基本都没戏。
看来你对前沿 PL 研究一无所知。编译器是在进步的。更何況 partial evaluation 理论早在 70 年代 AI 熱潮就提出了，应用上不说早到 Lisp 1.5，也不说目前比较先进的 PyTorch，PyPy 的 tracing 就是 partial evaluation 的应用。
1 个赞
你说得对。我是个工程师，不是研究者。
我倒是知道PyPy，可是这玩意只能拿来欺负CPython，没人真打算用来跟静态编译强类型语言较劲啊
所以你想要高性能的应用案例有 PyTorch 啊。PyPy 说白了只是个 trivial 例子，说明解釋动态语言有極大提升空间，性能都沒压榨出来。
我去PyTorch的github页面看了下 C++ 51.7% Python 31.8% Cuda 7.6% C 5.0% 然后去torch的github看了下 C 65.0% Lua 29.3%
真要玩性能鄙视链的还得看Fortran，C都得往后稍稍 
Fortran 也經不住并行化计算吊打。
Fortran早几年确实是，这几年LLVM GCC发展太快
然后就看到了这些最底层的基本向量操作函数，清一色的用编译器intrinsics写的
其实我同意高层优化很重要很有用，但是如果一种语言不提供给你直接控制CPU的能力，那么结果永远差着一个常数因子，这个因子有可能是4X，有可能是8X。不差钱的话这个常数因子可以靠堆硬件堆并行堆出来，但并不是所有的情况都可以。譬如你给PS4写个游戏，就这个CPU，看你能做成什么样，你不可能让用户去堆上8个CPU来跑你的游戏。
据我所知 PyTorch 的 pe 还在实驗室里，连 paper 都才出你现在能看出什么東西倒是奇怪了。不过这得怪我沒说清楚，我只是恰好知道在做这个的人。至于代码写了多少，吹的有多少是靠譜的我一概不知。
Relay is designed to replace the user-visible graph with a higher level abstraction and make it possible for users to write frameworks like TensorFlow and PyTorch inpure Python.
arXiv:1810.00952v1
游戏和数值计算不能一概而论。数值计算多快都沒关系，而比如 6502 用现在的电腦写了模擬器反而太快了，要靠時鐘同步才能正常运行 NES 遊戲。又比如，CPU 的 sequential 模型和 GPU 的 simd 模型用的算法干脆就是不一样的，并行化以后可以直接“降维打击”，量子计算也是同理。
我简单看了下，这个也是让你用python写高层代码，跟numpy是一个意思。最底层依然是C++。不然就像上面说的，效能永远差一个常数因子。当然我知道搞理论的大都看不上常数因子，只要BigO对了就可以了。
Although the core of Relay is written in C++, we are ableto expose the internals of the system to Python by reusingTVM ’s node system, which allows low-effort interoperabilitybetween the two languages.
那不是很好么，前人用 C++ 写了高性能的代码又沒什么理由不用，只要不是麻烦我自已就可以了。毕竟代码写了又不是只能用一次。这就是为什么 CFFI 被 Python, Lisp, Haskell, Rust 这些语言看重了。以后 GPU 乃至 quantum computing 更为流行，low level programming 和 high level 估计都会分成不同行業了，比如现在高层一点的 ArrayFire, 底層一点的 CUDA 就是这种模式了。。
据说Fortran的优势就是并行化计算方便，现在我吊打我自己？
天河的用户一半以上都是用来解算流体力学，就是用Fortran写的软件（祖传代码.jpg）
还有ECWMF，每天能进行两次15天内25公里分辨率的天气预报，地表单个任务运算量之巅。同样也是fortran干的呀
你那是超算用好多（至少上万了吧）个 CPU 堆的，我指的是在一般工作站的条件下上用 GPGPU 吊打 32 核至强这样子
而且 FORTRAN 方便并行是和不用手动管理线程那种原始时代标准比，还是要调用库 （OpenMP），并不是现在純函數式那样代码改都不用改就可以并行化。
1 个赞
不要被搞研究的忽悠了。基本上搞研究的吹爆就完事了，实用化他们不管的。
4 个赞
给个参考连接？