| |||||||||||||
Quotes of the weekQuotes of the weekPosted Jun 28, 2012 15:00 UTC (Thu) by rriggs (subscriber, #11598)Parent article: Quotes of the week
I think Mr. Pike's surprise is because Go solves a problem with Google's use of C++ that the rest of the world, using modern C++ programming practices, just doesn't have. One need only read Google's C++ programming guidelines to know that coding C++ for the Googleplex is going to be "difficult".
Go does solve a couple important problems for Python programmers -- performance and concurrency. I don't know if attitudes in the Python development community have changed recently, but one of my biggest frustrations as a Python developer in the '00s was "the GIL doesn't matter" attitude that prevailed, and which prevented any forward movement on multi-threaded programming with CPython.
(Log in to post comments)
Quotes of the week Posted Jun 29, 2012 8:01 UTC (Fri) by mgedmin (subscriber, #34497) [Link]
I think that attitude was a result of multi-thread scalability being hard, not the reason. When people encounter problems they can't solve, they go into denial.
I still remember when people used to say "anti-aliased fonts are bad for your eyes, so it's good that Linux doesn't support them!" back in the early days of desktop Linux.
Threading and concurrency Posted Jul 2, 2012 15:39 UTC (Mon) by oak (subscriber, #2786) [Link]
> I think that attitude was a result of multi-thread scalability
> being hard, not the reason.
One part of "hard" is that threading support can slow down things for everybody, also people who don't use threads (who most likely are the majority of users of any programming language). And there are also other approaches for solving performance and concurrency issues than threading.
While there are some specific cases where threads fit nicely, people overuse them. I've understood that to be some kind of Windows legacy because on Windows process overhead (at least earlier) was too high and threads got marketed & popularized as a solution for performance issues although the issue they solved was mostly Windows specific?
> When people encounter problems they can't solve, they go into denial.
Or when they need to debug[1] somebody else's threaded code, they may decide that advantages of threading are much over marketed compared to its disadvantages, such as heisenbugs & problems in testing; 100% coverage not being able to flush out race conditions, performance issues from lock contention and additional overhead from locking in general, level of threading support in underlying libraries etc.
What kind of performance issues you have?
Besides using separate processes to implement concurrency, there's Stackless Python which provides micro threads & coroutines. Nowadays there's also PyPy which is supposed to provide many of the same features.
Then there's MP. Eclipse IDE even seems to have separate support for it (OpenMP):
Which might be useful if one wants to write a parallelizing Python module that's (hopefully) safer & easier to maintain than a threaded one.
[1] When people extol on advantages of some feature (like threading) they often forget than they need to be maintained too, and maintaining, for example debugging, requires *good* tools for that specific purpose. What tools there are for debugging threading issues?
I know Valgrind has two tools for detecting data races (Helgrind & DRD), there's mutrace to find out lock contention issues and Gdb naturally can give backtraces to all of the threads, but these are all run-time tools. Even in the best case they can find the problems only if your tests trigger them.
Are there any (good) open source static tools for analyzing threading issues in code?
|
|||||||||||||