We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Programming in Parallel with Threads

Formale Metadaten

Titel
Programming in Parallel with Threads
Serientitel
Anzahl der Teile
160
Autor
Lizenz
CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Programming in Parallel with Threads [EuroPython 2017 - Talk - 2017-07-11 - PyCharm Room] [Rimini, Italy] Threads are typically not the way to take advantage of multiple CPUs for CPU-bound problems. The Global Interpreter Lock (GIL) allows the use of only one CPU at the time when using threads. However, the GIL is released for IO task The use case is a scientific simulation model that has to run 18,000 different simulations. The input data for these simulations need to be extracted from a common database, re-assembled and translated into several input files per simulation. After each simulation that is run with an external, standalone executable, the output data needs to be gathered and rearranged in a output database. The implementation scaled up to 50 threads. On a eight-core machine more than 90 % usage of all CPUs could be achieved, bringing the total run time down to about two hours from about 15 hours. Depending on the use case, threading can help to speedup a program and even take advantage of multiple CPUs. This talk presents such a use case. The approach can be translated to problems from other domains if the sub-tasks can be turned into IO tasks. Asynchronous programming could have been used here. However using a thread per task and using class that represents a task, is likely conceptually simpler for programmers not used to asynchronous programming