Great book and very easy to understand!

Very useful information. Could be better written, not suitable for parallel programming neophytes.

Python’s roots go so far back in time that, despite the prevalence of today’s multicore CPU computers, the most popular, “official” version of the language CPython) is limited by the GIL, or Global Interpreter Lock. The GIL restricts thread processing so that only one thread at a time for each interpreter process executing on the system.Among other things, the GIL prevents the sharing of code that’s not thread-safe with other threads, such as the code often found in the many C libraries that are often called upon by Python programmers, and it allows for simplified memory management.The GIL certainly puts the kibosh on anyone attempting to implement concurrency or pure parallelism on a multiprocessing machine running Python. What one gets instead is a sort of cooperative multitasking of sections of threads that run in spurts and stretches between moments of I/O (read, write, send, etc.) when the GIL is briefly released (CPU-bound threads that never deal with I/O are handled as a special case).Running a Python program on a multiple core PC is therefore asking for trouble, since each core “wants” to schedule its own runnable thread, and all the scheduling of threads is simultaneous. But the GIL only allows one thread at a time to run, so a Python programmer who divvies his algorithm into multiple threads will get quite a surprise when he discovers that his software is running slower than it should, since threads are competing for exclusive access to the GIL. Indeed, running such a multi-thread program on a multicore system can slow things down even more!The limitations imposed by GIL is probably the principal reason why some Python programmers have switched to working in Google’s Go language, which is built from the ground up to harness to power of multiple cores and processors via what its originators call “goroutines;” these vaguely resemble Unix pipes and can all run in the same memory address space via multiplexing onto multiple, parallel OS threads.But all is not lost for those Python programmers longing to delve into the realm of parallel and concurrent programming.For those completely clueless about how to thumb one’s nose at the GIL and tackle concurrency and parallelism in Python, such as using the open source and cross-platform “PP” or Parallel Python module, a good place to start is this book.That being the case, I won’t burden the reader with the quality of the author’s coverage in specific areas, since a beginner will have no idea of what I’m talking about. (Besides, others have commented on that elsewhere on this site.) Suffice it to say that, provided you can jump through enough coding hoops, you can bring a performance boost to your software, particularly if it has a sufficiently “granular” structure.

Parallel Programming is an increasingly hot topic in today's IT circles. For those who ponder why I can tell in short it is because of the CPU clock speeds stagnation. We, software engineers, are dealing with ever increasing volumes of data and are asked to deliver even faster, more robust applications and websites. This is tough. Parallel Programming is the answer. I hope I whet your appetite for exploring the Parallel Programming so now I can switch the focus to the book.It is not terribly long. Not costly either. In fact if you care I managed to read it whole in 3 hours plus (stats are from my ebook reader app) and managed to run a few examples that worked on my laptop with Windows 7. I am planning on running more examples later on a POSIX machine. Thing with the examples is they are classic ones: the Fibonacci series which is boring to me and far from what anybody would be dealing with at work and web crawling which is better done using say Nutch. The same code examples go through the entire book, just different techniques applied. What I wish Jan had done is explaining at least what technique helps in what case in real life. My other pet peeves are that there was no mention on how to leverage the GPU, how to eliminate the For Loops - this is actually a must in my opinion, and there was no coverage on how to debug parralel processes. Let me stop at debugging a tad longer: since Python allows mutability it becomes critical to exterminate nasty mutation bugs!In terms of closing, I have an advice to the author: it is hard to write a technical book, but I wish it could be longer and covered more ground, another advice is to the publisher, this book qualifies for the "Instant" moniker type of the books from Packt. By the way I like your website redesign!Three stars out of five.

For a long time, programmers have been relying exclusively on Moore's law to resolve their performance issues. In other words, they trusted the fact that the CPU frequency would increase, making their program faster without changing one single line. Today however, "the free lunch is over", as already argued by Herb Sutter in 2004. The frequency of CPUs tends to stagnate, while the number of cores in even the cheapest laptop has increased. For Sutter, the immediate consequence is: "applications will increasingly need to be concurrent if they want to fully exploit CPU throughput gains".Python is no exception to this paradigm change and this book introduces several ways to go parallel with Python using the standard library modules threading, multiprocessing and asyncio, and the third-party modules Parallel Python and Celery. This is quite an impressive list for such a short book, but I personally think that IPython.parallel and mpi4py (both quite popular in scientific computing) should have made it into this book.Parallel programming in Python is no trivial task because of the Global Interpreter Lock (GIL) which "prevents multiple native threads from executing Python bytecodes at once". While this issue is briefly mentioned in this book (in a section called "Taking Care of Python GIL"), I think that the author should have made it clearer which modules suffer from this limitation, and which don't. For example, the following statement (which can be found page 30) is far too vague: "Within the Python programming language, the use of CPU-bound threads may harm performance of the application due to GIL.""may harm performance"? Could you be more precise, please? The answer can be found in the module's official documentation: "CPython implementation detail: In CPython, due to the Global Interpreter Lock, only one thread can execute Python code at once (even though certain performance-oriented libraries might overcome this limitation). If you want your application to make better use of the computational resources of multi-core machines, you are advised to use multiprocessing or concurrent.futures.ProcessPoolExecutor. However, threading is still an appropriate model if you want to run multiple I/O-bound tasks simultaneously."So the truth is that "may harm" should really read "does harm". To be fair, a much more clear-cut statement can be found page 94: "A way to solve this problem is delegating a blocking task to ThreadPoolExecutor (remember this works well if the processing is I/O bound; if it is CPU-bound, use ProcessPoolExecutor)".The book starts with two introductory chapters, in which the reader will find useful material. Chapter 1 presents a historical background, defines various forms of parallelization as well as the most common pitfalls of parallel programming (deadlock, starvation, race condition). Chapter 2 reviews a few parallelization strategies.In chapter 3, the author presents two simple problems which will be used in the remainder of the book to illustrate the use of the various modules I mentioned above. I find the idea of reusing the same two examples over and over again quite interesting, as it makes it easier to the reader to understand the differences and similarities between these modules. Besides, the two examples are simple, and so is their parallel implementation. Maybe these two problems are too simple, though. Indeed, both are embarrasingly parallel problems, for which very little communication is required (besides scattering the data at the beginning and gathering the results at the end). In such a favorable situation, the potential "parallel programming problems" listed in chapter 1 are simply swept under the rug, which is probably better for an introductory book on parallel programming.In Chapters 4, 5, 6, 7 and 8, these two problems are implemented using the following modules in turn: threading, multiprocessing, pp, celery and asyncio. Of course, the API of these modules is not (cannot be) described in detail in such a short book: only the most elementary classes and functions are described. So be ready to dive into the API documentations after reading this book! It should be mentioned that the chapters on celery and asyncio (new in Python 3.4) provide more details, and are very enjoyable. I do think that a closing comparison between all these modules is clearly missing.To conclude, I would recommend this book to those of you who are willing to go parallel in Python, but do not know where to start. This book usefully lists various options and provides the keys to each of those. Happy reading!