朱莉娅(Julia)为什么不能超设置python? [英] Why couldn't Julia superset python?

问题描述

Julia Language语法看起来与python非常相似，而类的概念(如果应该这样处理的话)更多地是在C语言中使用的.创建者决定与尊重OOP.仍然很难找到一种比较规范的方法(相对于首先创建Julia来说，这是令人印象深刻的)，从而找到将Python解释为Julia的规范方法，从而掌握所有python库吗?

The Julia Language syntax looks very similar to python, while the concept of a class (if one should address it as such a thing) is more what you use in C. There were many reasons why the creators decided on the difference with respect to the OOP. Still would it have been so hard (in comparison to create Julia in first place which is impressive) to find some canonical way to interpret python to Julia and thus get a hold of all the python libraries?

推荐答案

是.Python的设计从根本上来说很难在编译时(即在运行代码之前)进行优化.朱莉娅之所以快是因为它的准时性，这是完全错误的.相反，Julia在设计时考虑了其类型系统和多个分派，以便编译器可以了解所有必要的详细信息，以编译您将用C编写的相同代码".这就是快速的原因:类型系统.它进行了一些权衡取舍，使它可以在类型稳定"功能中完全推断出每个变量的类型，知道类型应为哪种内存布局(包括参数类型，因此 Vector{Float64} 的内存布局由类型和其参数确定，该类型及其参数像NumPy数组一样内联 Float64 值，除非以您自己的 struct类型获得相同的效率)，并针对看到的类型专门编译代码版本.

Yes. The design of Python makes it fundamentally difficult to optimize at compile-time (i.e. before you run the code). It is simply false that Julia is fast BECAUSE of its JIT. Rather, Julia is designed with its type system and multiple dispatch in mind so that way the compiler can know all of the necessary details to compile "the same code you would have written in C". That's what makes it fast: the type system. It makes a few trade-offs that allow it to, in "type-stable" functions, fully deduce what the types of every variable is, know what the memory layout of the type should be (including parametric types, so Vector{Float64} has a memory layout which is determined by the type and its parameter which inlines Float64 values like a NumPy array, except this is generalized in a way that your own struct types get the same efficiency), and compile a version of the code specifically for the types which are seen.

在很多方面，这与Python不符.例如，如果结构中字段的数量可以更改，则无法确定内存布局，因此这些优化不能在编译时"发生.Julia精心设计以确保其具有类型可推断性，并使用它来生成完全类型化的代码并删除所有运行时检查(在类型稳定的函数中.当函数不是类型稳定的时，变量变为动态而不是静态，并且减慢到类似Python的速度).从这个意义上说，Julia实际上甚至还没有优化:考虑到其类型系统的设计，它的所有性能都是免费的".Python/MATLAB/R必须尽力在运行时进行优化，因为它没有能力进行这些推论.实际上，就运行时优化而言，这些语言现在已经更好地优化"，但是还没有人真正在Julia中进行运行时优化，因为在大多数对性能敏感的情况下，您都可以在编译时获得全部.

There are many ways where this is at odds with Python. For example, if the number of fields in a struct could change, then the memory layout could not be determined and thus these optimizations cannot occur at "compile-time". Julia was painstakingly designed to make sure that it would have type inferrability, and it uses that to generate code which is fully typed and remove all runtime checks (in type-stable functions. When a function is not type-stable, the types of the variables become dynamic rather than static and it slows down to Python-like speeds). In this sense, Julia actually isn't even optimized yet: all of its performance comes "for free" given the design of its type system. Python/MATLAB/R has to try really hard to optimize at runtime because it doesn't have the capability to do these deductions. In fact, those languages are "better optimized" right now in terms of runtime optimizations, but no one has really worked on runtime optimizations in Julia yet because in most performance sensitive cases you can get it all at compile time.

那Numba呢?Numba尝试通过限制可完成的工作来采取Julia使用但使用Python代码的方法，以便它可以获取类型稳定的代码并有效地进行编译.但是，这意味着一些事情.首先，它与所有Python代码或库都不兼容.但更重要的是，由于Python不是围绕其类型系统构建的语言，因此大大减少了在类型级别上控制代码的工具.因此Numba没有参数向量和通用代码，它们无法通过多次调度自动进行专业化，因为它们不是语言的功能.但这也意味着它不能充分利用设计，从而限制了它可以做的事情.它可以很好地处理仅使用浮点数组"的东西，但是如果您希望一个代码为任何数字类型，甚至我不知道的数字类型"生成有效的代码，就可以看到它的局限性.但是，根据设计，Julia会自动执行此操作.

So then, what about Numba? Numba tries to take the route that Julia takes but with Python code by limiting what can be done so that way it can get type-stable code and compile that efficiently. However, this means a few things. First of all, it's not compatible with all Python codes or libraries. But more importantly, since Python is not a language built around its type system, the tools for controlling the code at the level of types is much reduced. So Numba doesn't have parametric vectors and generic codes which auto-specialize via multiple dispatch because these aren't features of the language. But that also means that it cannot make full use of the design, which limits how much it can do. It can handle the "use only floating point array" stuff just fine, but you can see it gets limited if you want one code to produce efficient code for "any number type, even ones I don't know about". However, by design, Julia does this automatically.

因此，从本质上讲，Julia和Python是极为不同的语言.很难看到，因为Julia的语法接近Python的语法，但是它们根本不一样.

So at the core, Julia and Python are extremely different languages. It can be hard to see because Julia's syntax is close to Python's syntax, but they do not work the same at all.

这是我在一些博客文章中所描述内容的简短摘要.这些将更详细地介绍给您，朱莉娅实际上是如何生成有效的代码的，它如何为您提供通用的"Python风格"，但始终具有完全不可推论的含义，以及权衡取舍.

This is a short summary of what I have described in a few blog posts. These go into more detail and show you how Julia is actually generating efficient code, how it gives you a generic "Python looking style" but doing so with full inferrability all the way down, and what the tradeoffs are.

类型稳定性加多重调度如何提高性能:

How type-stability plus multiple dispatch gives performance:

http://ucidatascienceinitiative.github.io/IntroToJulia/Html/WhyJulia http://www.stochasticlifestyle.com/7-julia-gotchas-handle/

类型系统如何实现高性能的通用设计

How the type system allows for highly performant generic designs

http://www.stochasticlifestyle.com/type-dispatch-design-post-object-programming-julia/

这篇关于朱莉娅(Julia)为什么不能超设置python?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！