3 ms·

Is he being serious when he says he only has one test case? That really doesn't seem like a reasonable thing to do. Furthermore, would a recursive implementatio

Is he being serious when he says he only has one test case? That really doesn't seem like a reasonable thing to do. Furthermore, would a recursive implementation of Fibonacci even benefit from multithreading?

m_mueller 9y ago
Basically, his point at the moment is not to construct some benchmarks that show some multithread benefits and then call victory. Instead he wants to reduce its overhead so it won't make existing (thus unoptimised for Gilectomy) programs much slower - which is probably necessary for main line adoption. As such I find his approach really refreshing, interesting and honest: Basically start with the worst case first, get everyone's expectation down and then at the end show that the situation is actually not as hopeless as you might think.
wulfjack 9y ago
The goal should be, and is kind of what Larry Hastings is looking for, is that any program should run 8 times faster on a 8-core CPU compared to a 1-core. And as said above Python can basically only use one core b/c of GIL. Actually Python 2.7 multithreading runs much slower on a multicore CPU than on a single core due to locking congestion on the GIL.
- marvy 9y ago
  What? No! Multithreaded programs should run faster on 8 cores than on one core. That's not very realistic for single-threaded programs, in any language. I could be wrong, but I think Py2.7 is about the same speed on multicore vs 1 core. Where did you get that idea?
  - diek 9y ago
    Python 2.7 has terrible thrashing in the way the GIL is acquired that is exacerbated as more threads are used. Dave Beazley has given great talks with the technical details: http://www.dabeaz.com/GIL/ http://www.dabeaz.com/GIL/
  - alfanerd 9y ago
    Some years ago I wrote pyworks (www.github.com/pylots/pyworks), a proposal for async objects (inspired by ABCL and cooC (Concurrent Object Oriented-C, https://www.researchgate.net/publication/220178380_Concurrent_Object_Oriented_%27C%27_cooC https://www.researchgate.net/publication/220178380_Concurren...) The testcase is 100 threads sending 1000 messages in to each other in a ring. On a 8-core Mac Jython and IronPython performs better than on 1-core, but Python 2.7 performs so badly that it never finishes. The ideal scenario is probably that the CPython interpreter starts one thread per core running as many coroutines in parallel as possible, but that looks like a long way away for Python
- thomaslee 9y ago
  > The goal should be, and is kind of what Larry Hastings is looking for, is that any program should run 8 times faster on a 8-core CPU compared to a 1-core. A program that's inherently single-threaded it's unlikely to benefit from more CPUs. When you say "any program" here, you mean "any program with >=8 threads", right?
  - alfanerd 9y ago
    I mean the developer (using a highlevel language as Python) ideally should get more performance on an 8-core than on a 1-core CPU. Erlang, which btw. is older than Python, will perform better the more cores you have due to its message oriented nature. Python (2.7) on the other hand performed worse with multithreading on multicore. I was hoping that Python would take the same direction in the future, but unfortunately we are getting the async/await mess, instead of a simple async object model (sorry, my pet peeve)

m_mueller 9y ago

Basically, his point at the moment is not to construct some benchmarks that show some multithread benefits and then call victory. Instead he wants to reduce its overhead so it won't make existing (thus unoptimised for Gilectomy) programs much slower - which is probably necessary for main line adoption. As such I find his approach really refreshing, interesting and honest: Basically start with the worst case first, get everyone's expectation down and then at the end show that the situation is actually not as hopeless as you might think.

wulfjack 9y ago

The goal should be, and is kind of what Larry Hastings is looking for, is that any program should run 8 times faster on a 8-core CPU compared to a 1-core. And as said above Python can basically only use one core b/c of GIL. Actually Python 2.7 multithreading runs much slower on a multicore CPU than on a single core due to locking congestion on the GIL.

marvy 9y ago
What? No! Multithreaded programs should run faster on 8 cores than on one core. That's not very realistic for single-threaded programs, in any language. I could be wrong, but I think Py2.7 is about the same speed on multicore vs 1 core. Where did you get that idea?
- diek 9y ago
  Python 2.7 has terrible thrashing in the way the GIL is acquired that is exacerbated as more threads are used. Dave Beazley has given great talks with the technical details: http://www.dabeaz.com/GIL/ http://www.dabeaz.com/GIL/
- alfanerd 9y ago
  Some years ago I wrote pyworks (www.github.com/pylots/pyworks), a proposal for async objects (inspired by ABCL and cooC (Concurrent Object Oriented-C, https://www.researchgate.net/publication/220178380_Concurrent_Object_Oriented_%27C%27_cooC https://www.researchgate.net/publication/220178380_Concurren...) The testcase is 100 threads sending 1000 messages in to each other in a ring. On a 8-core Mac Jython and IronPython performs better than on 1-core, but Python 2.7 performs so badly that it never finishes. The ideal scenario is probably that the CPython interpreter starts one thread per core running as many coroutines in parallel as possible, but that looks like a long way away for Python
thomaslee 9y ago
> The goal should be, and is kind of what Larry Hastings is looking for, is that any program should run 8 times faster on a 8-core CPU compared to a 1-core. A program that's inherently single-threaded it's unlikely to benefit from more CPUs. When you say "any program" here, you mean "any program with >=8 threads", right?
- alfanerd 9y ago
  I mean the developer (using a highlevel language as Python) ideally should get more performance on an 8-core than on a 1-core CPU. Erlang, which btw. is older than Python, will perform better the more cores you have due to its message oriented nature. Python (2.7) on the other hand performed worse with multithreading on multicore. I was hoping that Python would take the same direction in the future, but unfortunately we are getting the async/await mess, instead of a simple async object model (sorry, my pet peeve)