Souvenez-vous de notre exemple de restaurant de burger asynchrone dans la premi\u00e8re partie de cette s\u00e9rie d’articles de blog<\/a> :<\/p>\n
import asyncio\n\nimport time\n\nasync def make_burger(order_num):\n\n print(f\"Preparing burger #{order_num}...\")\n\n await asyncio.sleep(5) # time for making the burger\n\n print(f\"Burger made #{order_num}\")\n\nasync def main():\n\n order_queue = []\n\n for i in range(3):\n\n order_queue.append(make_burger(i))\n\n await asyncio.gather(*(order_queue))\n\nif __name__ == \"__main__\":\n\n s = time.perf_counter()\n\n asyncio.run(main())\n\n elapsed = time.perf_counter() - s\n\n print(f\"Orders completed in {elapsed:0.2f} seconds.\")\n<\/pre>\nNous pouvons utiliser la biblioth\u00e8que multiprocessing pour faire la m\u00eame chose, par exemple :<\/p>\n
import multiprocessing\n\n\nimport time\n\n\ndef make_burger(order_num):\n\n\n print(f\"Preparing burger #{order_num}...\")\n\n\n time.sleep(5) # time for making the burger\n\n\n print(f\"Burger made #{order_num}\")\n\n\n\n\nif __name__ == \"__main__\":\n\n\n print(\"Number of available CPU:\", multiprocessing.cpu_count())\n\n\n\n\n s = time.perf_counter()\n\n\n all_processes = []\n\n\n for i in range(3):\n process = multiprocessing.Process(target=make_burger, args=(i,))\n process.start()\n all_processes.append(process)\n\n\n for process in all_processes:\n process.join()\n\n\n elapsed = time.perf_counter() - s\n\n\n print(f\"Orders completed in {elapsed:0.2f} seconds.\")\n<\/pre>\nComme vous vous en souvenez peut-\u00eatre, la plupart des m\u00e9thodes de multiprocessing sont tr\u00e8s proches de celles de threading. Pour voir la diff\u00e9rence avec multiprocessing, nous allons explorer un sc\u00e9nario plus complexe :<\/p>\n
import multiprocessing\nimport time\nimport queue\n\n\n\n\ndef make_burger(order_num, item_made):\n name = multiprocessing.current_process().name\n print(f\"{name} is preparing burger #{order_num}...\")\n time.sleep(5) # time for making burger\n item_made.put(f\"Burger #{order_num}\")\n print(f\"Burger #{order_num} made by {name}\")\n\n\n\n\ndef make_fries(order_num, item_made):\n name = multiprocessing.current_process().name\n print(f\"{name} is preparing fries #{order_num}...\")\n time.sleep(2) # time for making fries\n item_made.put(f\"Fries #{order_num}\")\n print(f\"Fries #{order_num} made by {name}\")\n\n\n\n\ndef working(task_queue, item_made, order_num, lock):\n break_count = 0\n name = multiprocessing.current_process().name\n while True:\n try:\n task = task_queue.get_nowait()\n except queue.Empty:\n print(f\"{name} has nothing to do...\")\n if break_count > 1:\n break # stop if idle for too long\n else:\n break_count += 1\n time.sleep(1)\n else:\n lock.acquire()\n try:\n current_num = order_num.value\n order_num.value = current_num + 1\n finally:\n lock.release()\n task(current_num, item_made)\n break_count = 0\n\n\n\n\nif __name__ == \"__main__\":\n\n\n print(\"Welcome to Pyburger! Please place your order.\")\n\n\n burger_num = input(\"Number of burgers:\")\n fries_num = input(\"Number of fries:\")\n\n\n s = time.perf_counter()\n\n\n task_queue = multiprocessing.Queue()\n item_made = multiprocessing.Queue()\n order_num = multiprocessing.Value(\"i\", 0)\n lock = multiprocessing.Lock()\n\n\n for i in range(int(burger_num)):\n task_queue.put(make_burger)\n for i in range(int(fries_num)):\n task_queue.put(make_fries)\n\n\n staff1 = multiprocessing.Process(\n target=working,\n name=\"John\",\n args=(\n task_queue,\n item_made,\n order_num,\n lock,\n ),\n )\n staff2 = multiprocessing.Process(\n target=working,\n name=\"Jane\",\n args=(\n task_queue,\n item_made,\n order_num,\n lock,\n ),\n )\n\n\n staff1.start()\n staff2.start()\n\n\n staff1.join()\n staff2.join()\n\n\n print(\"All tasks finished. Closing now.\")\n print(\"Items created are:\")\n\n\n while not item_made.empty():\n print(item_made.get())\n\n\n elapsed = time.perf_counter() - s\n\n\n print(f\"Orders completed in {elapsed:0.2f} seconds.\")\n<\/pre>\nVoici le r\u00e9sultat obtenu :<\/p>\n
Welcome to Pyburger! Please place your order.\nNumber of burgers:3\nNumber of fries:2\nJane has nothing to do...\nJohn is preparing burger #0...\nJane is preparing burger #1...\nBurger #0 made by John\nJohn is preparing burger #2...\nBurger #1 made by Jane\nJane is preparing fries #3...\nFries #3 made by Jane\nJane is preparing fries #4...\nBurger #2 made by John\nJohn has nothing to do...\nFries #4 made by Jane\nJane has nothing to do...\nJohn has nothing to do...\nJane has nothing to do...\nJohn has nothing to do...\nJane has nothing to do...\nAll tasks finished. Closing now.\nItems created are:\nBurger #0\nBurger #1\nFries #3\nBurger #2\nFries #4\nOrders completed in 12.21 seconds.\n<\/pre>\nNotez que multiprocessing pr\u00e9sente des limitations qui conditionnent le code ci-dessus. Examinons ces points un par un.<\/p>\n
D’abord, souvenez-vous que nous utilisions les fonctions make_burger et make_fries pour g\u00e9n\u00e9rer une fonction ayant la bonne valeur order_num\u00a0:<\/p>\n
def make_burger(order_num):\n def making_burger():\n logger.info(f\"Preparing burger #{order_num}...\")\n time.sleep(5) # time for making burger\n logger.info(f\"Burger made #{order_num}\")\n\n\n return making_burger\n\n\n\n\ndef make_fries(order_num):\n def making_fries():\n logger.info(f\"Preparing fries #{order_num}...\")\n time.sleep(2) # time for making fries\n logger.info(f\"Fries made #{order_num}\")\n\n\n return making_fries\n<\/pre>\nNous ne pouvons pas faire la m\u00eame chose avec multiprocessing. Sinon, cela cr\u00e9e une erreur comme celle-ci :<\/p>\n
AttributeError: Can't get local object 'make_burger..making_burger'<\/pre>\nCela s’explique par le fait que multiprocessing utilise pickle<\/a>, qui ne peut s\u00e9rialiser que les fonctions au niveau sup\u00e9rieur du module en g\u00e9n\u00e9ral. Il s’agit de l’une des limitations de multiprocessing.<\/p>\nEnsuite, comme vous pouvez le remarquer dans l’extrait de code ci-dessus, qui utilise multiprocessing, nous n’utilisons pas de variables globales pour les donn\u00e9es partag\u00e9es. Par exemple, nous ne pouvons pas utiliser de variables globales pour item_made et order_num. Pour partager les donn\u00e9es entre diff\u00e9rents processus, des objets de classe sp\u00e9ciaux, tels que Queue<\/em> et Value<\/em>, qui proviennent du module multiprocessing, sont utilis\u00e9s et transf\u00e9r\u00e9s aux processus en tant qu’arguments.
En g\u00e9n\u00e9ral, le partage des donn\u00e9es et des \u00e9tats entre diff\u00e9rents processus est d\u00e9conseill\u00e9, car cela peut cr\u00e9er de nombreux probl\u00e8mes. Dans notre exemple ci-dessus, nous devons utiliser un Lock pour nous assurer que la valeur de order_num ne peut \u00eatre accessible et incr\u00e9ment\u00e9e que par un seul processus \u00e0 la fois. Sans ce Lock, le num\u00e9ro d’ordre de l’\u00e9l\u00e9ment risque de ne pas \u00eatre correct, par exemple :<\/p>\nItems created are:\n\nBurger #0\nBurger #0\nFries #2\nBurger #1\nFries #3\n<\/pre>\nVoici comment utiliser un verrou pour \u00e9viter ce probl\u00e8me\u00a0:<\/p>\n
lock.acquire()\n try:\n current_num = order_num.value\n order_num.value = current_num + 1\n finally:\n lock.release()\n task(current_num, item_made)\n<\/pre>\nPour en savoir plus sur l’utilisation du module multiprocessing de la biblioth\u00e8que standard, vous pouvez consulter la documentation ici<\/a>.<\/p>\nSuppression du GIL<\/h2>\n
La suppression du GIL est en discussion depuis pr\u00e8s d’une d\u00e9cennie. En 2016, au Python Language Summit, Larry Hastings a pr\u00e9sent\u00e9 ses id\u00e9es sur la mani\u00e8re de pratiquer une \u00ab\u00a0GIL-ectomie\u00a0\u00bb sur l’interpr\u00e9teur CPython et les progr\u00e8s qu’il avait r\u00e9alis\u00e9s dans ce sens [1]. Ce fut l’une des premi\u00e8res tentatives de suppression du GIL de Python. En 2021, Sam Gross a relanc\u00e9 la discussion sur la suppression du GIL [2] et cela a conduit \u00e0 la publication du PEP 703 \u2013 Making the Global Interpreter Lock Optional in CPython<\/a> en 2023, qui vise \u00e0 rendre le GIL facultatif.<\/p>\nComme nous pouvons le voir, la suppression du GIL n’est pas une d\u00e9cision h\u00e2tive et a fait l’objet de nombreux d\u00e9bats au sein de la communaut\u00e9. Comme d\u00e9montr\u00e9 par les exemples ci-dessus de multitraitement (et PEP 703, en lien ci-dessus), lorsque la garantie fournie par le GIL est supprim\u00e9e, les choses se compliquent rapidement.<\/p>\n
[1] : https:\/\/lwn.net\/Articles\/689548\/<\/a><\/p>\n[2] : https:\/\/lwn.net\/ml\/python-dev\/CAGr09bSrMNyVNLTvFq-h6t38kTxqTXfgxJYApmbEWnT71L74-g@mail.gmail.com\/<\/p>\n
Comptage des r\u00e9f\u00e9rences<\/h3>\n
Lorsque le GIL est pr\u00e9sent, le comptage des r\u00e9f\u00e9rences et la collecte par le ramasse-miettes sont plus simples. Si l’acc\u00e8s aux objets Python est limit\u00e9 \u00e0 un seul thread, nous pouvons compter sur un comptage des r\u00e9f\u00e9rences<\/a> simple, non atomique, et supprimer l’objet d\u00e8s que le compteur de r\u00e9f\u00e9rences atteint z\u00e9ro.<\/p>\nLa suppression du GIL complique tout. Nous ne pouvons plus utiliser le comptage des r\u00e9f\u00e9rences non atomique, car cela ne garantit pas la s\u00e9curit\u00e9 des threads<\/a>. Les choses peuvent mal se passer si plusieurs threads augmentent ou r\u00e9duisent la valeur du compteur de r\u00e9f\u00e9rences sur l’objet Python en m\u00eame temps. Dans l’id\u00e9al, un comptage des r\u00e9f\u00e9rences atomique serait pr\u00e9f\u00e9rable pour garantir la s\u00e9curit\u00e9 des threads. Toutefois, cette m\u00e9thode impose une surcharge importante et peut se r\u00e9v\u00e9ler peu efficace en pr\u00e9sence d’un nombre important de threads.<\/p>\nLa solution consiste \u00e0 utiliser un comptage des r\u00e9f\u00e9rences biais\u00e9, qui garantit \u00e9galement la s\u00e9curit\u00e9 des threads. L’id\u00e9e consiste \u00e0 associer chaque objet \u00e0 un thread propri\u00e9taire, \u00e0 savoir celui qui y acc\u00e8de le plus fr\u00e9quemment. Les threads propri\u00e9taires peuvent ex\u00e9cuter le comptage des r\u00e9f\u00e9rences non atomique sur les objets qu’ils poss\u00e8dent, tandis que les autres threads doivent r\u00e9aliser un comptage des r\u00e9f\u00e9rences atomique sur ces objets. Cette m\u00e9thode est pr\u00e9f\u00e9rable au comptage des r\u00e9f\u00e9rences atomique simple, car la plupart des objets sont uniquement accessibles par un seul thread la plupart du temps. La surcharge d’ex\u00e9cution peut \u00eatre r\u00e9duite en autorisant le thread propri\u00e9taire \u00e0 ex\u00e9cuter un comptage des r\u00e9f\u00e9rences non atomique.<\/p>\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/07\/image-22.png\")
<\/figure>\nDe plus, certains objets Python tr\u00e8s utilis\u00e9s, tels que True, False<\/em>, les petits entiers et certaines cha\u00eenes intern\u00e9es, sont rendus immortels. Dans ce cas, \u00ab immortel \u00bb signifie seulement que les objets restent dans le programme pendant toute sa dur\u00e9e de vie, ce qui les dispense du comptage des r\u00e9f\u00e9rences.<\/p>\nRamasse-miettes<\/h3>\n
Nous devons \u00e9galement modifier le fonctionnement du ramasse-miettes<\/a>. Au lieu de r\u00e9duire le nombre de r\u00e9f\u00e9rences d\u00e8s qu’une r\u00e9f\u00e9rence est lib\u00e9r\u00e9e et de retirer l’objet imm\u00e9diatement lorsque le nombre de r\u00e9f\u00e9rences atteint z\u00e9ro, nous allons utiliser la technique de \u00ab\u00a0comptage des r\u00e9f\u00e9rences diff\u00e9r\u00e9\u00a0\u00bb.<\/p>\nLorsque le nombre de r\u00e9f\u00e9rences doit \u00eatre r\u00e9duit, l’objet est stock\u00e9 dans une table, qui sera rev\u00e9rifi\u00e9e pour s’assurer que la r\u00e9duction du nombre de r\u00e9f\u00e9rences est correcte. Cela \u00e9vite de retirer l’objet pr\u00e9matur\u00e9ment, alors qu’il est toujours r\u00e9f\u00e9renc\u00e9, ce qui risque de se produire sans le GIL, dans la mesure o\u00f9 le comptage des r\u00e9f\u00e9rences n’est pas aussi simple qu’avec le GIL. Cela complique le processus de collecte du ramasse-miettes, car il peut avoir \u00e0 traverser la pile<\/a> de chaque thread pour y ex\u00e9cuter un comptage des r\u00e9f\u00e9rences.<\/p>\nUn autre point important doit \u00eatre pris en compte : le nombre de r\u00e9f\u00e9rences doit rester stable pendant l’ex\u00e9cution du ramasse-miettes. Si un objet doit \u00eatre supprim\u00e9, mais devient soudain r\u00e9f\u00e9renc\u00e9, cela entra\u00eene des probl\u00e8mes graves. Pour cette raison, le ramasse-miettes devient bloquant (stop the world) pour assurer la s\u00e9curit\u00e9 des threads.<\/p>\n
Allocation de la m\u00e9moire<\/h3>\n
Lorsque le GIL assure la s\u00e9curit\u00e9 du thread, pymalloc, l’allocateur de m\u00e9moire interne de Python, est utilis\u00e9. Mais sans le GIL, il faut un nouvel allocateur. Sam Gross a propos\u00e9 mimalloc<\/a> dans son PEP. Il s’agit d’un allocateur g\u00e9n\u00e9raliste cr\u00e9\u00e9 par Daan Leijen et g\u00e9r\u00e9 par Microsoft. C’est un bon choix, car il n’affecte pas la s\u00e9curit\u00e9 des threads et a de bonnes performances sur les petits objets.<\/p>\nMimalloc remplit sa pile avec des pages et les pages avec des blocs. Chaque page contient des blocs, et les blocs de chaque page sont de la m\u00eame taille. En ajoutant quelques restrictions d’acc\u00e8s \u00e0 list et dict, le ramasse-miettes n’a pas \u00e0 g\u00e9rer une liste cha\u00een\u00e9e<\/a> pour trouver tous les objets et cela permet \u00e9galement d’acc\u00e9der en lecture aux list et dict sans acqu\u00e9rir le verrou.<\/p>\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/07\/image-23.png\")
<\/figure>\nIl faut prendre en compte d’autres d\u00e9tails concernant la suppression du GIL, mais il est impossible de les couvrir tous dans cet article. Vous pouvez consulter la page PEP 703 \u2013 Making the Global Interpreter Lock Optional in CPython<\/a> pour une pr\u00e9sentation compl\u00e8te.<\/p>\nDiff\u00e9rences de performances avec et sans le GIL<\/h2>\n
Dans la mesure o\u00f9 Python 3.13 comporte une option \u00e0 threads libres, il est possible de comparer les performances de la version standard de Python 3.13 \u00e0 celle \u00e0 threads libres.<\/p>\n
Installation de Python \u00e0 threads libres<\/h3>\n
Nous allons utiliser pyenv<\/a> pour installer les deux versions : la standard (3.13.5) et la version v\u00e9ritablement multithread (3.13.5t).<\/p>\nPar ailleurs, vous pouvez \u00e9galement utiliser les installateurs sur Python.org<\/a>. S\u00e9lectionnez l’option Customize<\/em> pendant l’installation et cochez la case de la version multithread de Python (voir l’exemple dans cet article de blog<\/a>).<\/p>\nUne fois les deux versions install\u00e9es, nous pouvons les ajouter en tant qu’interpr\u00e9teurs dans un projet PyCharm.<\/p>\n
Pour commencer, cliquez sur le nom de votre interpr\u00e9teur Python dans le coin inf\u00e9rieur droit.<\/p>\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/07\/image-24.png\")
<\/figure>\nS\u00e9lectionnez Add New Interpreter<\/em> dans le menu, puis Add Local Interpreter<\/em>.<\/p>\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/07\/image-25.png\")
<\/figure>\nChoisissez Select existing<\/em>, attendez le chargement du chemin de l’interpr\u00e9teur (ce qui peut prendre du temps si, comme moi, vous avez beaucoup d’interpr\u00e9teurs), puis s\u00e9lectionnez le nouvel interpr\u00e9teur que vous venez d’installer dans le menu d\u00e9roulant Python path<\/em>.<\/p>\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/07\/image-26.png\")
<\/figure>\nCliquez sur OK<\/em> pour l’ajouter. R\u00e9p\u00e9tez ces \u00e9tapes pour l’autre interpr\u00e9teur. D\u00e9sormais, lorsque vous cliquez \u00e0 nouveau sur le nom de l’interpr\u00e9teur dans le coin inf\u00e9rieur droit, vous verrez plusieurs interpr\u00e9teurs Python 3.13, comme dans l’illustration ci-dessus.<\/p>\nTest de processus li\u00e9 au processeur<\/h3>\n
Il faut maintenant cr\u00e9er un script pour tester les diff\u00e9rentes versions. Souvenez-vous, nous avons expliqu\u00e9 dans la premi\u00e8re partie de cette s\u00e9rie d’articles de blog<\/a> que pour acc\u00e9l\u00e9rer les processus li\u00e9s au processeur, nous devions recourir au multithreading sans restrictions. Pour voir si la suppression du GIL permettra un v\u00e9ritable multithreading et acc\u00e9l\u00e9rera Python, nous pouvons tester un processus li\u00e9 au processeur sur plusieurs threads. Voici le script que j’ai demand\u00e9 \u00e0 Junie<\/a> de g\u00e9n\u00e9rer (avec quelques retouches personnelles) :<\/p>\nimport time\nimport multiprocessing # Kept for CPU count\nfrom concurrent.futures import ThreadPoolExecutor\nimport sys\n\n\n\n\ndef is_prime(n):\n \"\"\"Check if a number is prime (CPU-intensive operation).\"\"\"\n if n <= 1:\n return False\n if n <= 3:\n return True\n if n % 2 == 0 or n % 3 == 0:\n return False\n i = 5\n while i * i <= n:\n if n % i == 0 or n % (i + 2) == 0:\n return False\n i += 6\n return True\n\n\n\n\ndef count_primes(start, end):\n \"\"\"Count prime numbers in a range.\"\"\"\n count = 0\n for num in range(start, end):\n if is_prime(num):\n count += 1\n return count\n\n\n\n\ndef run_single_thread(range_size, num_chunks):\n \"\"\"Run the prime counting task in a single thread.\"\"\"\n chunk_size = range_size \/\/ num_chunks\n total_count = 0\n\n\n start_time = time.time()\n\n\n for i in range(num_chunks):\n start = i * chunk_size + 1\n end = (i + 1) * chunk_size + 1 if i < num_chunks - 1 else range_size + 1\n total_count += count_primes(start, end)\n\n\n end_time = time.time()\n\n\n return total_count, end_time - start_time\n\n\n\n\ndef thread_task(start, end):\n \"\"\"Task function for threads.\"\"\"\n return count_primes(start, end)\n\n\n\n\ndef run_multi_thread(range_size, num_threads, num_chunks):\n \"\"\"Run the prime counting task using multiple threads.\"\"\"\n chunk_size = range_size \/\/ num_chunks\n total_count = 0\n\n\n start_time = time.time()\n\n\n with ThreadPoolExecutor(max_workers=num_threads) as executor:\n futures = []\n for i in range(num_chunks):\n start = i * chunk_size + 1\n end = (i + 1) * chunk_size + 1 if i < num_chunks - 1 else range_size + 1\n futures.append(executor.submit(thread_task, start, end))\n\n\n for future in futures:\n total_count += future.result()\n\n\n end_time = time.time()\n\n\n return total_count, end_time - start_time\n\n\n\n\ndef main():\n # Fixed parameters\n range_size = 1000000 # Range of numbers to check for primes\n num_chunks = 16 # Number of chunks to divide the work into\n num_threads = 4 # Fixed number of threads for multi-threading test\n\n\n print(f\"Python version: {sys.version}\")\n print(f\"CPU count: {multiprocessing.cpu_count()}\")\n print(f\"Range size: {range_size}\")\n print(f\"Number of chunks: {num_chunks}\")\n print(\"-\" * 60)\n\n\n # Run single-threaded version as baseline\n print(\"Running single-threaded version (baseline)...\")\n count, single_time = run_single_thread(range_size, num_chunks)\n print(f\"Found {count} primes in {single_time:.4f} seconds\")\n print(\"-\" * 60)\n\n\n # Run multi-threaded version with fixed number of threads\n print(f\"Running multi-threaded version with {num_threads} threads...\")\n count, thread_time = run_multi_thread(range_size, num_threads, num_chunks)\n speedup = single_time \/ thread_time\n print(f\"Found {count} primes in {thread_time:.4f} seconds (speedup: {speedup:.2f}x)\")\n print(\"-\" * 60)\n\n\n # Summary\n print(\"SUMMARY:\")\n print(f\"{'Threads':<10} {'Time (s)':<12} {'Speedup':<10}\")\n print(f\"{'1 (baseline)':<10} {single_time:<12.4f} {'1.00x':<10}\")\n print(f\"{num_threads:<10} {thread_time:<12.4f} {speedup:.2f}x\")\n\n\nif __name__ == \"__main__\":\n main()\n<\/pre>\nPour simplifier l’ex\u00e9cution du script avec diff\u00e9rents interpr\u00e9teurs Python, nous pouvons ajouter un script d’ex\u00e9cution personnalis\u00e9 \u00e0 notre projet PyCharm.<\/p>\n
En haut, s\u00e9lectionnez Edit Configurations\u2026<\/em> dans le menu d\u00e9roulant pr\u00e8s du bouton Run<\/em> (![](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/10\/AD_4nXcRz0HogcsseQcC85-vSwRJhBWhiZCysBUZjcuu1uQYusTx-hj6h-l4FAs_HUE1gcJV5kjSjPuUu1opfKgu6sH5G9epkDlMMw0fBRPyReunr-DgSpg5O_6QTIYROqOaiMHGAX42vg.png\")
).<\/p>\n![](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/10\/AD_4nXeLJtj8xjnN-WQM7UQAop3RCg1hSElHa9WqFMBgXWGyxaxg07kOEhYnBV2i1WOnw5fUB_LsN-QWXidRJ-WMUVAkjF9aSVws684Jbnnoc8P-t_EDD622RghKpL5LjckKoKf251If3A.png\")
<\/p>\n
Cliquez sur le bouton + dans le coin sup\u00e9rieur gauche, puis choisissez Python dans le menu d\u00e9roulant Add New Configuration<\/em>.<\/p>\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/07\/image-27.png\")
<\/figure>\nChoisissez un nom significatif permettant de savoir quel interpr\u00e9teur est utilis\u00e9, par exemple 3.13.5 et 3.15.3t. S\u00e9lectionnez le bon interpr\u00e9teur et ajoutez ajoutez le nom du script de test de la fa\u00e7on suivante :<\/p>\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/07\/image-28.png\")
<\/figure>\nAjoutez deux configurations, une pour chaque interpr\u00e9teur. Cliquez ensuite sur OK<\/em>.<\/p>\nMaintenant, nous pouvons facilement s\u00e9lectionner et ex\u00e9cuter le script de test avec ou sans le GIL en s\u00e9lectionnant la configuration et en cliquant sur le bouton Run<\/em> ()\u00a0 en haut.<\/p>\nComparaison des r\u00e9sultats<\/h3>\n
Voici le r\u00e9sultat que j’ai obtenu avec la version standard 3.13.5, incluant le GIL :<\/p>\n
Python version: 3.13.5 (main, Jul 10 2025, 20:33:15) [Clang 17.0.0 (clang-1700.0.13.5)]\nCPU count: 8\nRange size: 1000000\nNumber of chunks: 16\n------------------------------------------------------------\nRunning single-threaded version (baseline)...\nFound 78498 primes in 1.1930 seconds\n------------------------------------------------------------\nRunning multi-threaded version with 4 threads...\nFound 78498 primes in 1.2183 seconds (speedup: 0.98x)\n------------------------------------------------------------\nSUMMARY:\nThreads Time (s) Speedup \n1 (baseline) 1.1930 1.00x \n4 1.2183 0.98x\n<\/pre>\nComme vous pouvez le voir, il n’y a pas de changement significatif de la vitesse lorsque j’ex\u00e9cute la version \u00e0 4 threads par rapport \u00e0 la version standard monothread. Voyons maintenant ce qui se produit avec la version v\u00e9ritablement multithread, 3.13.5t :<\/p>\n
Python version: 3.13.5 experimental free-threading build (main, Jul 10 2025, 20:36:28) [Clang 17.0.0 (clang-1700.0.13.5)]\nCPU count: 8\nRange size: 1000000\nNumber of chunks: 16\n------------------------------------------------------------\nRunning single-threaded version (baseline)...\nFound 78498 primes in 1.5869 seconds\n------------------------------------------------------------\nRunning multi-threaded version with 4 threads...\nFound 78498 primes in 0.4662 seconds (speedup: 3.40x)\n------------------------------------------------------------\nSUMMARY:\nThreads Time (s) Speedup \n1 (baseline) 1.5869 1.00x \n4 0.4662 3.40x\n<\/pre>\nDans ce cas, la vitesse est plus de 3 fois sup\u00e9rieure. Notez que dans les deux cas le multithreading impose une surcharge. Par cons\u00e9quent, m\u00eame avec un v\u00e9ritable multithreading, la vitesse n’est pas 4 fois sup\u00e9rieure avec 4 threads.<\/p>\n
Conclusion<\/h2>\n
Dans la deuxi\u00e8me partie de la s\u00e9rie d’articles de blog \u00ab Acc\u00e9l\u00e9rer Python \u00bb, nous avons vu pourquoi il \u00e9tait important d’avoir le GIL dans Python, comment contourner la limitation du GIL avec le multitraitement, ainsi que comment supprimer le GIL et les effets de cette suppression.<\/p>\n
\u00c0 l’heure o\u00f9 j’\u00e9cris cet article, la version v\u00e9ritablement multithread de Python n’est toujours pas la version par d\u00e9faut. Cependant, avec l’adoption par la communaut\u00e9 et les biblioth\u00e8ques tierces, la version v\u00e9ritablement multithread de Python devrait devenir la norme \u00e0 l’avenir. Il a \u00e9t\u00e9 annonc\u00e9 que Python 3.14 inclurait une version v\u00e9ritablement multithread qui serait au-del\u00e0 du stade exp\u00e9rimental, mais resterait facultative.<\/p>\n
![\"Cheuk](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/01\/CheukTingHo-Kimono-e1738750639162-200x200.jpg\")
\n <\/div>\n