2 ms·

Whilst they may have thought of concurrency problems in the 80s as you outline, the problem of concurrency (and subsequently performance) appears to be a bit mo

by muhit2002 13y ago

Whilst they may have thought of concurrency problems in the 80s as you outline, the problem of concurrency (and subsequently performance) appears to be a bit more genuine now. Processing power has peaked...fact. Now with most PC's being shipped with multi-processors the need for concurrent software is a real one. I do appreciate that there is an enormous list of things that are important right now, that software engineers have to worry about such as good user experience, proper abstraction, security, encryption, privacy, reusability, reliable data storage, good recovery etc etc However to dismiss concurrency issues in a world with peaked processing powers on a single CPU as something of a fashion-fad! Doesn’t sound to me as in synch with what i've been observing. Would be nice to hear from others on this1

gaius 13y ago
Ask yourself this: why is removing the GIL a very low priority for the Python community? Or why has the GIL not slowed the adoption of Python, esp. in financial services?
- muhit2002 13y ago
  A. Because it’s not easy to remove GIL according to Guido van van Rossumn. It’s an issue and the fact the python community are talking about it means concurrency is an issue. B. Your last comment points to one language and the complexity of adapting it vs ignoring wider argument that there is a greater need for concurrency to add performance than what there was in the 80’s when CPU’s got faster ever year. c. You almost indicate that despite the GIL banks are using python and therefore must be less concerned with concurrency. This is not the case because GIL in no way stops concurrent programming from happening in a single Python process. The only constraint the GIL places on multi-threaded applications is that a single Python process cannot execute multiple threads simultaneously. You can still run multiple threads.
  - gaius 13y ago
    a) it's a nice to have, but the lack of it hadn't hurt the adoption rate of Python. So that's not it. b) computers nowadays are insanely fast - so fast that we use high level languages like Python instead of assembly. So that's not it. c) that makes no sense. There is no point in threading without concurrency! So that's not it either. There is no multi core crisis now, just as there was no transputer crisis back then. Only people trying to sell stuff.

gaius 13y ago

Ask yourself this: why is removing the GIL a very low priority for the Python community? Or why has the GIL not slowed the adoption of Python, esp. in financial services?

muhit2002 13y ago
A. Because it’s not easy to remove GIL according to Guido van van Rossumn. It’s an issue and the fact the python community are talking about it means concurrency is an issue. B. Your last comment points to one language and the complexity of adapting it vs ignoring wider argument that there is a greater need for concurrency to add performance than what there was in the 80’s when CPU’s got faster ever year. c. You almost indicate that despite the GIL banks are using python and therefore must be less concerned with concurrency. This is not the case because GIL in no way stops concurrent programming from happening in a single Python process. The only constraint the GIL places on multi-threaded applications is that a single Python process cannot execute multiple threads simultaneously. You can still run multiple threads.
- gaius 13y ago
  a) it's a nice to have, but the lack of it hadn't hurt the adoption rate of Python. So that's not it. b) computers nowadays are insanely fast - so fast that we use high level languages like Python instead of assembly. So that's not it. c) that makes no sense. There is no point in threading without concurrency! So that's not it either. There is no multi core crisis now, just as there was no transputer crisis back then. Only people trying to sell stuff.