Dramatic slowdown with random.random on free-threading build.

This slowdown was found with one of my favorite benchmarks, which is calculating the pi value with the Monte Carlo method.

import os
import random
import time
from threading import Thread

def monte_carlo_pi_part(n: int, idx: int, results: list[int]) -> None:
    count = 0
    for i in range(n):
        x = random.random()
        y = random.random()

        if x*x + y*y <= 1:
            count += 1
    results[idx] = count


n = 10000
threads = []
num_threads = 100
results = [0] * num_threads
a = time.time()
for i in range(num_threads):
    t = Thread(target=monte_carlo_pi_part, args=(n, i, results))
    t.start()
    threads.append(t)

while threads:
    t = threads.pop()
    t.join()

b = time.time()
print(sum(results) / (n * num_threads) * 4)
print(b-a)

Acquiring critical sections for random methods causes this slowdown.
Removing @critical_section from the method, which uses genrand_uint32 and then updating genrand_uint32 to use atomic operation makes the performance acceptable.

Linked PRs

• gh-118393
• gh-118396

まず random.random の実装と genrand_uint32 の経路を読み、issue で説明されている @critical_section の使用方法も確認します。次に、提供されているマルチスレッドの Monte Carlo ベンチマークを再現し、その後、リンクされている PR 118393 と 118396 を確認します。free-threading による性能低下が、乱数の正しさを変更せずに軽減されれば完了です。