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 造成的效能下降獲得改善，且不改變亂數的正確性時，即表示完成。