在他们的arXiv论文中 ，Julia的原创作者提到以下内容：
2.14 Parallelism 。 并行执行由在标准库中的Julia实现的基于消息的多处理系统提供。 语言设计通过提供对称协同程序来支持这种库的实现，这也可以被认为是协同调度的线程。 此功能允许在库中隐藏异步通信，而不需要用户设置回调。 Julia目前不支持本机线程，这是一个限制，但具有避免同步使用共享内存的复杂性的优点。
说朱莉娅不支持本机线程 ，是什么意思？ 什么是本机线程？
其他解释语言（如Python或R）是否支持此类并行性？ 朱莉娅一个人在吗？
In their arXiv paper, the original authors of Julia mention the following:
2.14 Parallelism. Parallel execution is provided by a message-based multi-processing system implemented in Julia in the standard library. The language design supports the implementation of such libraries by providing symmetric coroutines, which can also be thought of as cooperatively scheduled threads. This feature allows asynchronous communication to be hidden inside libraries, rather than requiring the user to set up callbacks. Julia does not currently support native threads, which is a limitation, but has the advantage of avoiding the complexities of synchronized use of shared memory.
What do they mean by saying that Julia does not support native threads? What is a native thread?
Do other interpreted languages such as Python or R support this type of parallelism? Is Julia alone in this?
最满意答案
“本地线程”是执行的单独上下文，由操作系统内核管理，访问共享内存空间，并可能在单独的内核上并发执行。 将其与单独的进程进行比较，这些进程可以在多个内核并发执行，但具有单独的内存空间 确保进程交互良好很容易，因为它们只能通过内核相互通信。 确保线程不以不可预测的方式进行交互是非常困难的，因为它们可以以不受限制的方式读写同一个内存。
R的情况是相当简单的： R不是多线程的 。 Python有点复杂：Python确实支持线程，但是由于全局解释器锁（GIL） ，Python实现并行执行Python代码是不可能的。 其他流行的开源动态语言在本地线程（Ruby： no / kinda / yes ？; Node.js： no ）方面处于各种混合状态，但一般来说，答案是否定的，它们不支持完全并发本机线程所以朱莉娅并不孤单。
当我们向Julia添加共享内存并行性时， 由于我们计划 - 无论是使用本机线程还是使用共享内存的多个进程 - 这将是真正的并发性，并且不会有GIL阻止同时执行Julia代码。 然而，这是一个非常棘手的功能，添加到一种语言，由其他非常流行，成熟的动态语言中不存在或有限的支持证明。 添加共享内存并发模型在技术上是困难的，但真正的问题是设计一个编程模型，这将允许程序员以有效和安全的方式有效地利用硬件并发。 这个问题一般都没有解决，是一个非常活跃的研究和实验领域 - 没有“黄金标准”的复制。 我们可以只添加POSIX线程支持，但是这种编程模式被普遍认为是危险的，并且非常难以正确有效地使用。 Go有一个很好的并发故事，但它的目的是编写高度并发的服务器，而不是同时运行大数据，所以简单的复制Go的模型对于Julia来说是个好主意并不清楚。
"Native threads" are separate contexts of execution, managed by the operating system kernel, accessing a shared memory space and potentially executing concurrently on separate cores. Compare this with separate processes, which may execute concurrently on multiple cores but have separate memory spaces. Making sure that processes interact nicely is easy since they can only communicate with each other via the kernel. Ensuring that threads don't interact in unpredictable, buggy ways is very hard since they can read and write to the same memory in an unrestricted manner.
The R situation is fairly straightforward: R is not multithreaded. Python is a little more complicated: Python does support threading, but due to the global interpreter lock (GIL), no actual concurrent execution of Python code is possible. Other popular open source dynamic languages are in various mixed states with respect to native threading (Ruby: no/kinda/yes?; Node.js: no), but in general, the answer is no, they do not support fully concurrent native threading, so Julia is not alone in this.
When we do add shared-memory parallelism to Julia, as we plan to – whether using native threads or multiple processes with shared memory – it will be true concurrency and there will be no GIL preventing simultaneous execution of Julia code. However, this is an incredibly tricky feature to add to a language, as attested by the non-existent or limited support in other very popular, mature dynamic languages. Adding a shared-memory concurrency model is technically difficult, but the real problem is designing a programming model that will allow programmers to make effective use of hardware concurrency in a productive and safe way. This problem is generally unsolved and is a very active area of research and experimentation – there is no "gold standard" to copy. We could just add POSIX threads support, but that programming model is general considered to be dangerous and incredibly difficult to use correctly and effectively. Go has an excellent concurrency story, but it is designed for writing highly concurrent servers, not for concurrently operating on large data, so it's not at all clear that simply copying Go's model is a good idea for Julia.
更多推荐
发布评论