5 ms·
I think all kinds of components and applications are going to hit the wall. The python interpreter doesn't even support multiple real threads let alone multipl
by russell 18y ago
I think all kinds of components and applications are going to hit the wall. The python interpreter doesn't even support multiple real threads let alone multiple cores. Programmers don't know how to write the code. Here is an article musing about the problems in Java: http://www.devwebsphere.com/devwebsphere/2006/11/multicore_may_b.html http://www.devwebsphere.com/devwebsphere/2006/11/multicore_m... Do we all need to learn erlang?
- ramchip 18y agoClojure has put a major emphasis on fixing multithreading for Java - I don't know about garbage collection and problems with the JVM itself, though.
- deleted 18y ago[deleted]
- stcredzero 18y agoI'd rather have some sort of support for multiple cores without real threads. Stackless seems like a good alternative to Erlang. Take the two statements above as standalone.
- russell 18y agoI agree that Stackless is better. Threads are very heavyweight. The problem is that the underlying C interpreter works on only one core. If Stackless can work with multiple interpreters then it may be the greatest thing since sliced bread. I haven't been following it closely enough to say for sure.
- stcredzero 18y agoAll you have to do is build a mechanism that distributes threads between interpreter processes then just spawn an interpreter for each core. For many applications, that's all you need.
- likpok 18y agoI seem to recall a benchmark that showed Erlang as much faster than Stackless (for an admittedly relatively arbitrary problem).
- Retric 18y agoOne of the few things I liked about Java was how easy it was to do multi-threaded programming. Granted it's clunky but Java network apps are much simpler than doing the same thing in C / C++.
- timf 18y agoJava has a very nice available tool for scaling out a webapp: terracotta.org
- eru 18y agoLanguages (e.g. Haskell) which support transactional software memory can also be useful.
- d0mine 18y ago`multiprocessing` module is in the Python's stdlib.
- deleted 18y ago[deleted]
- timf 18y agoThe parent's statement is still technically right: "python interpreter doesn't even support multiple real threads let alone multiple cores" multiprocessing allows you to have the interpreter start another entire OS process (another interpreter). It mimics the threading API. It's useful and it does allow you to take advantage of multiple cores without unfamiliar APIs which I take it is your point... You can see in the PEP that for many situations the overhead of processes is not a big concern: http://www.python.org/dev/peps/pep-0371/ http://www.python.org/dev/peps/pep-0371/
- d0mine 18y agomultiprocessing module supports multiple "concurrent" programming paradigms. It greatly depends on the task but my usage of the module is in disagreement with the PEP i.e., I don't use its threading-like API preferring its "distributed" capabilities. The main point is there are multiple "concurrent" approaches and Java-like "threading" approach is the worst for many tasks i.e., It would be nice if GIL had been gone but for many "concurrent" approaches It doesn't matter. http://wiki.python.org/moin/ParallelProcessing http://wiki.python.org/moin/ParallelProcessing
- rbanffy 18y agoI would love to have parallel list comprehensions, for instance.
- timf 18y agoI'm in agreement (note that I could not really tell what you were saying in your original comment). If I need to do some tightly coupled thing with threads and shared data etc. I'm not going to be looking at Python anyhow.
- samuel 18y agoPython uses native threads which can be scheduled by the OS to multiple cores. It's just that can't run the interpreter at the same time (C-coded extensions can, and most of them release the lock). Yeah, not a big difference really.