7.09.2025 состоялся релизPithon 3.14!
На фоне хайпа про NoGIL всё позабыли про другие фичи. Особенно про Multiple Interpreters, который обещает изоляцию процессов но с эффективностью потоков! На сколько действительно это будет эффективно мы узнаем позже, потому что сейчас это лишь первый релиз с ограничениями и недоработками.
Но что там про NoGIL? Теперь этот режим не экспериментальный, а официально поддерживаемый, но опциональный.
Чтобы запустить без GIL нужна специальная сборка. И перед стартом нужно объявить переменную PYTHON_GIL=0
Для вас я собрал готовый репозиторий где достаточно запустить скрпит, который всё сделает:
▫️ соберет релизный Python 3.14 в новый Docker-образ
▫️ запустит тесты в контейнере (GIL, NoGIL, MultiInterpreter)
▫️ распечатает результаты
Тест очень простой, усложняйте сами)
Вот какие результаты у меня:
=== Running ThreadPoolExecutor GIL ON
TOTAL TIME: 45.48 seconds
=== Running ThreadPoolExecutor GIL OFF
TOTAL TIME: 6.14 seconds
=== Running basic Thread GIL ON
TOTAL TIME: 45.54 seconds
=== Running basic Thread GIL OFF
TOTAL TIME: 4.74 seconds
=== Running with Multi Interpreter
TOTAL TIME: 18.30 seconds
Если сравнивать GIL и NoGIL, то на мои 32 ядра прирост х7-x10 (почему не х32? 🤷). При этом нам обещают что скорости будут расти с новыми релизами.
Режим без GIL похож (визуально) на async, тоже параллельно, тоже не по порядку. Но это не IO! и от того некоторый диссонанс в голове 😵💫, нас учили не так!
Интересно, что чистый Thread работает быстрей чем ThreadPoolExecutor без GIL.
Ну и где-то плачет один адепт мульти-интерпретаторов😭 Теперь нужно искать где они могут пригодиться с такой-то скоростью. Скорее всего своя область применения найдется.
Отдельно я затестил память и вот что вышло на 32 потока:
ThreadPoolExecutor GIL ON
305.228 MB
ThreadPoolExecutor GIL OFF
500.176 MB
basic Thread GIL ON
90.668 MB
basic Thread GIL OFF
472.444 MB
with Multi Interpreter
1267.788 MB
Пока не знаю как к этому относиться)
В целом - радует направление развития!
#release
Q. 우주 데이터센터, 방사능 문제 괜찮나?
⇒우주 데이터센터에서 HBM이 방사능에 취약하지만, 추론은 문제 없다 (Google 썬캐쳐 논문)
구글은 V6e Trillium 클라우드 TPU와 AMD 호스트 서버를 67 MeV 양성자 빔에 노출시켜 태양 동기 저궤도(LEO)의 운영 환경 (저궤도 환경은 주로 양성자와 은하 우주선(GCR)으로 구성) 을 모사를 해보았음.
결론 ) 방사능 관련해서는 두 가지 한계점이 있음.
1. 총 이온화 선량(TID)
절연층에 전하가 누적되어 장치 성능이 서서히 저하되는 현상
1년에 150 rad(Si)를 견뎌야 함.
5년 임무를 수행하려면 약 750 rad(Si)를 견뎌야 함.
⇒ HBM에서 가장 민감함.
HBM은 연산 로직보다 방사능에 약 3.4배 더 민감하게 반응
⇒ 2000 rad(Si)부터 불규칙한 동작 발생
⇒ 위성의 수명은 5년이기에 2000rad(Si)까지 누적되지 않음. 따라서 HBM이 750rad(Si)까지는 버텨줌.
결론 ) HBM이 이건 버틴다
2. 단일 사건 효과(SEE)
고에너지 입자 하나가 충돌하여 즉각적인 오류 (비트 플립 등)를 일으키는 현상.
(비트 플립이란 방사선의 영향으로 메모리의 0이 1로, 1이 0으로 바뀌는 오류)
특히 감지되지 않는 비트 플립은 무소음 데이터 부패(SDC)를 유발하여 AI 모델 학습을 망칠 수 있음.
⇒ 역시나 HBM에서 가장 민감함.
⇒ 주로 수정 불가능한 ECC 오류로 발생
결론 ) HBM이 이걸 못 버팀. 비트 플립으로 비트가 0이었던게 1로 바뀌는 효과 발생해버려서 치명적
따라서 학습과 추론 시 영향이 차이가 나는데,
학습 ) 학습은 아직 추가 연구 필요
학습 중에는 감지되지 않는 비트 플립이 무소음 데이터 부패(SDC)를 일으켜 모델 전체를 망칠 위험이 있음. 따라서 학습 과정에 대한 영향과 이를 막기 위한 시스템 수준의 완화 기술은 추가 연구가 필요하다고 명시되어져 있음.
추론 ) 추론은 실질적으로 오류 발생 확률 낮아 사용 가능 수준
오류 발생 확률은 낮음. 실질적으로 사용 가능한 수준에 머뭄.
1년에 약 150 rad의 방사선이 내리쬐는 저궤도 환경을 가정하면, AI 추론 시 1,000만 건당 1번 정도의 오류가 발생하는 셈
#우주#SpaceX#구글#데이터센터#TPU#HBM