Python 与 Java——您会选择哪一个来进行并发编程,为什么?

发布于 2024-08-13 07:44:50 字数 1432 浏览 4 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(11

失而复得 2024-08-20 07:44:50

我会选择 JVM 而不是 Python,主要是因为 Python 中的多线程受到 全局解释器锁。然而,在 JVM 上运行时,Java 不太可能是最好的。 ClojureScala(使用参与者)可能都更适合多线程问题。

如果您确实选择 Java,则应该考虑使用 java.lang. util.concurrent 库并避免使用同步等多线程原语。

I would choose the JVM over python, primarily because multi-threading in Python is impeded by the Global Interpreter Lock. However, Java is unlikely to be your best when running on the JVM. Clojure or Scala (using actors) are both likely to be better suited to multi-threaded problems.

If you do choose Java you should consider making use of the java.util.concurrent libraries and avoid multi-threading primitives such as synchronized.

滿滿的愛 2024-08-20 07:44:50

对于并发性,我会使用 Java。通过使用 Java,我实际上指的是 Scala,它从 Erlang 的并发结构中借用了很多,但是(可能是) )对于以前从未使用过这两种语言的 Java 开发人员来说更容易使用。

Python 线程必须等待全局解释器锁,这使得 CPU 密集型程序无法实现真正​​的并发(在单个进程内)。据我了解,Stackless Python 解决了 CPython 的一些(虽然不是全部)并发缺陷,但由于我没有使用过它,所以我无法真正对此提出建议。

For concurrency, I would use Java. By use Java, I actually mean Scala, which borrows a lot from Erlang's concurrency constructs, but is (probably) more accessible to a Java developer who has never used either before.

Python threads suffer from having to wait for the Global Interpreter Lock, making true concurrency (within a single process) unachievable for CPU-bound programs. As I understand, Stackless Python solves some (though not all) of CPython's concurrency deficiencies, but as I have not used it, I can't really advise on it.

狠疯拽 2024-08-20 07:44:50

绝对是Stackless Python!这是专门为并发而设计的 Python 变体。

但最终这取决于您的目标平台以及您想要实现的目标。

Definetely Stackless Python! That a Python variant especially made for concurrency.

But in the end it depends on your target platform and what you are trying to achieve.

灼疼热情 2024-08-20 07:44:50

如果不是 Java/Python,我会选择函数式语言,因为考虑副作用是编写并发软件的复杂性之一。 (就你的问题而言:这个恰好是静态类型的,但编译器在大多数情况下都会推断)

我个人会选择 F#,因为我见过很多轻松使用它编写并发软件的好例子。

简介:这个人既有趣又鼓舞人心 ,如果您对 F# 不感兴趣的话,甚至必须看看。

If not Java/Python I would go for a functional language since taking side effects into account is one of the complexities of writing concurrent software. (As far as your question goes : this one happens to be statical typed, but compiler infered most of the time)

Personally I would pick F#, since I've seen lots of nice examples of writing concurrent software with ease using it.

As an introduction : this man is equally fun as inspiring, even a must have seen if you are not interested in F# what so ever.

如果没有你 2024-08-20 07:44:50

我不认为争论与语言选择或静态或动态类型有关 - 它是在两种并发模型之间 - 共享内存和消息传递。哪种模型对您的情况更有意义?您选择的语言是否允许您做出选择,或者您被迫采用一种模型而不是另一种模型?

为什么不看看 Erlang (它具有动态类型)和 消息传递演员模型,并阅读原因乔·阿姆斯特朗不喜欢共享内存这里还有一个关于使用锁和线程的 java 并发性的有趣讨论

我不了解Python,但是Java以及内置的锁和线程模型有一个名为Kilim

I don't think the argument is about language choice or static or dynamic typing - it's between two models of concurrency - shared memory and message passing. Which model makes more sense in your situation & does your chosen language allow you to make a choice or are you forced to adopt one model over the other?

Why not have a look at Erlang (which has dynamic typing) and message passing, the Actor model, and read why Joe Armstrong doesn't like shared memory. There's also a interesting discussion about java concurrency using locks and threads here on SO.

I don't know about Python, but Java, along with the inbuilt locks and threads model, has a mesasge passing framework called Kilim.

随心而道 2024-08-20 07:44:50

我会通过 Jython 使用 Java。 Java 具有强大的线程功能,并且可以使用 Python 语法和 Jython 来编写它,因此您可以两全其美。

Python 本身在并发方面并不是很好,而且比 Java 慢。

但如果你有并发问题并且可以腾出手来,我会看看 Erlang,因为它是为此类问题而设计的。当然,只有在以下情况下,您才必须考虑 Erlang: 有

  • 时间掌握
  • 对生产链合理部分的(非常)新技术控制,因为 Erland 需要在您的工具箱中进行一些调整以适应

I would use Java, via Jython. Java has strong thread capabilities, and it can be written using the Python syntax with Jython, so you got the best of the two worlds.

Python itself is not really good with concurrency, and is slower than Java anyway.

But if you have concurrency issues and free hands, I'd have a look at Erlang because it has been design for such problems. Of course, you must consider Erlang only if you have:

  • time to master a (very) new technology
  • control on a reasonable part of the production chain, since Erland need some adaptations in your toolbox to fit
凡尘雨 2024-08-20 07:44:50

两者都不。众所周知,并发编程很难正确。可以选择使用面向过程的编程语言,例如 occam-pi它基于通信顺序进程pi 演算。这允许编译时检查并发系统开发过程中出现的死锁和许多其他问题。如果你不喜欢 occam-pi,如果你不喜欢我也不能怪你,你可以尝试 Go 来自 google 的新语言,它也实现了 CSP 版本。

Neither. Concurrent programming is notoriously hard to get correct. There is the option of using a process oriented programming language like occam-pi which is based of the idea of communicating sequential processes and the pi calculus. This allows compile time checking for deadlock and many other problems that arise during concurrent systems development. If you do not like occam-pi, which I cant blame you if you dont, you could try Go the new language from google which also implements a version of CSP.

少女情怀诗 2024-08-20 07:44:50

对于某些任务,Python 太慢了。您的单线程 Java 程序可能比多核计算机上的 Python 并发版本更快...

我想使用 Java 或 Scala、F# 或干脆使用 C++(MPI 和 OpenMPI)。

For some tasks, Python is too slow. Your single thread Java program could be faster than the concurrent version of Python on a multi-core computer...

I'd like to use Java or Scala, F# or simply go to C++(MPI and OpenMPI).

坦然微笑 2024-08-20 07:44:50

Java 环境(JVM + 库)的并发性比 (C)Python 更好,但 Java 语言很糟糕。我可能会选择 JVM 上的另一种语言 - 已经提到了 Jython,并且 Clojure 和 Scala 都对并发提供了出色的支持。

Clojure 特别好——它支持高性能持久数据结构、代理和软件事务内存。它是一种动态语言,但您可以给它类型提示以获得与 Java 一样好的性能。

观看 InfoQ 上 Richard Hickey(Clojure 的创建者)的此视频 )关于传统并发方法的问题以及 Clojure 如何处理它。

The Java environment (JVM + libraries) is better for concurrency than (C)Python, but Java the language sucks. I would probably go with another language on the JVM - Jython has already been mentioned, and Clojure and Scala both have excellent support for concurrency.

Clojure is particularly good - it has support for high performance persistent data structures, agents and software transactional memory. It is a dynamic language but you can give it type hints to get performance as good as Java.

Watch this video on InfoQ by Richard Hickey (creator of Clojure) on the problems with traditional approaches to concurrency, and how Clojure handles it.

溺ぐ爱和你が 2024-08-20 07:44:50

我会研究 Objective-C 和基础框架。异步、并发编程得到了很好的支持。

这当然取决于您对 Apple 开发工具或 GnuStep 的访问权限,但如果您可以访问其中任何一个,那么这就是并发编程的一个好方法。

I'd look at Objective-C and the Foundation Framework. Asynchronous, concurrent programming is well provided for.

This of course depends on your access to Apple's Developer Tools or GnuStep, but if you have access to either one it's a good route to take with concurrent programming.

战皆罪 2024-08-20 07:44:50

答案是,这取决于情况。例如,您是否正在尝试利用单台计算机上的多个核心或 cpu,或者您是否希望将任务分布在多台计算机上?速度与实施的难易程度有多重要?

如前所述,Python 具有全局解释器锁,但您可以使用 multiprocessing 模块。请注意,虽然 Stackless 非常酷,但它 本身不会利用多个核心。人们通常认为 Python 比 Java 更容易使用。如果速度是优先考虑的,Java 通常会更快。

Java 中的 java.util.concurrent 库使在单台计算机上编写并发应用程序变得更加简单,但您仍然需要围绕任何共享状态进行同步。虽然 Java 不一定是并发性的最佳语言,但有很多工具、库、文档和最佳实践可以提供帮助。

使用消息传递和不变性而不是线程和共享状态被认为是编程并发应用程序的更好方法。因此,阻止可变性和副作用的函数式语言通常是首选。如果需要在多台计算机上分发并发应用程序,则值得查看为此设计的运行时,例如 ErlangScala Actor

The answer is that it depends. For example are you trying to take advantage of multiple cores or cpus on a single machine or are you wanting to distribute your task across many machines? How important is speed vs. ease of implementation?

As mentioned before, Python has the Global Interpreter Lock but you could use the multiprocessing module. Note that while Stackless is very cool, it won't utilise multiple cores on its own. Python is usually considered easier to work with than Java. If speed is a priority Java is usually faster.

The java.util.concurrent library in Java makes writing concurrent applications on a single machine simpler but you'll still need to synchronise around any shared state. While Java isn't necessarily the best language for concurrency, there are a lot of tools, libraries, documentation and best practices out there to help.

Using message passing and immutability instead of threads and shared state is considered the better approach to programming concurrent applications. Functional languages that discourage mutability and side effects are often preferred as a result. If distributing your concurrent applications across multiple machines is a requirement, it is worth looking at runtimes designed for this e.g. Erlang or Scala Actors.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文