Python 3.15와 3.14 성능 비교 — 큰 폭의 인코딩 개선이 전체 평균을 끌어올렸습니다

AI 요약

Python 3.15.0과 Python 3.14.8의 성능을 Windows 11 64비트 환경에서 비교했습니다. 테스트 장비는 AMD Ryzen 9 7900 데스크톱과 Intel Core i3-1315U 미니 PC이며, 벤치마크에는 pyperformance 1.14.0과 측정 프레임워크 pyperf 2.10.0을 사용했습니다. 각 벤치마크는 반복 세션의 평균 실행 시간을 계산해 비교했습니다.

전체 결과와 해석

AMD에서는 122개, Intel에서는 118개 벤치마크를 짝지어 측정했습니다. 두 시스템 모두 Python 3.15의 전체 기하평균 속도 향상은 약 1.451배로 집계됐습니다. 정규화한 벤치마크 묶음의 실행 시간은 약 31.1% 줄어든 셈입니다. 다만 이 값은 각 벤치마크에 같은 가중치를 주어 계산한 요약입니다. 실제 애플리케이션이 같은 비율로 빨라진다고 볼 수는 없습니다.

중앙값 기준 속도 향상은 AMD에서 1.184배, Intel에서 1.166배입니다. 전체 평균을 크게 끌어올린 벤치마크가 일부 있다는 뜻입니다. 특히 Base32, Ascii85, Base85 인코딩에서 큰 차이가 났습니다. 이 여섯 가지 대형·소형 입력 벤치마크를 제외하면 AMD는 1.203배, Intel은 1.197배 향상으로 낮아집니다. 전체 평균만으로 성능 변화를 판단하기 어려운 이유입니다.

크게 개선된 작업과 느려진 작업

가장 큰 개선은 대용량 Base32 인코딩에서 나타났습니다. AMD에서는 약 135배, Intel에서는 약 142배 빨라졌습니다. 대용량 Ascii85는 약 57~69배, Base85는 약 63배 빨라졌습니다. 소용량 입력에서도 이 세 인코딩 작업은 큰 폭으로 개선됐습니다. 원문은 Python 3.15 릴리스 노트에 Base32와 Ascii85/Base85 구현을 C로 다시 작성하고 Base64도 최적화했다는 내용이 있어 측정 결과와 맞닿아 있다고 설명합니다. 다만 이번 측정만으로 각 코드 변경이 성능 향상에 얼마나 기여했는지는 분리해 확인하지 못했습니다.

반대로 Base16은 두 장비에서 모두 느려졌습니다. AMD에서는 대용량 입력이 약 22%, 소용량 입력이 약 22% 느려졌고 Intel에서는 각각 약 16%, 24% 느려졌습니다. 정규식 전체 묶음의 변화는 작았습니다. regex_effbot은 AMD에서 약 22%, Intel에서 약 13% 느려졌으며, regex_dna도 AMD에서 10% 느려졌습니다. 시작 시간은 대체로 비슷했습니다.

작업 유형별 결과와 측정 한계

애플리케이션 태그 벤치마크는 AMD에서 약 1.13배, Intel에서 약 1.11배 빨라졌습니다. 템플릿 렌더링은 양쪽 모두 약 1.20배 향상됐고, asyncio 묶음은 약 1.11배 개선됐습니다. 직렬화 태그 결과는 약 3배로 높지만, 이 묶음에도 큰 폭으로 개선된 인코딩 벤치마크가 포함돼 있습니다.

Intel 측정에서는 pathlib, sphinx, 일부 SciMark 벤치마크 등의 결과가 세션에 따라 달라졌습니다. 원문은 변동이 큰 측정치에 † 표시를 붙였으며, 이 평균이 통계적 유의성을 보장하지 않는다고 명시합니다. 두 시스템은 하드웨어뿐 아니라 비교에 포함된 벤치마크 수도 다릅니다. 따라서 같은 전체 평균이 나왔다고 해서 프로세서 제조사별 이점이 같다고 단정할 수 없습니다. 비교 대상은 Windows용 전체 인터프리터 빌드이며, 결과만으로 JIT나 컴파일러, 특정 인터프리터 변경 하나에 향상을 돌릴 수도 없습니다.

Reddit 반응

• @u/frostbaka — 엄청난 차이입니다. 1.15배 향상은 오랫동안 보지 못했습니다.
  • @u/who_am_i_to_say_so — 맞습니다. 두 자릿수 향상은 전부 큰 차이입니다. 일부 작업, 특히 큰 정수를 다루는 경우에는 효과가 누적돼 상당한 속도 향상으로 이어질 수 있습니다. 수치 계산을 하는 사람들은 기뻐하겠네요.
  • @u/frostbaka — Python 앱을 서버 200대에서 돌린다고 생각해 보세요. 서버 30대를 공짜로 얻는 셈입니다.
  • @u/PJBthefirst — Python 앱을 서버 200대에서 돌린다고요? 진지하게 묻는데, 실제로 그렇게 하나요?
  • @u/breadcodes — 진지하게 답하면, 그렇습니다. Python은 백엔드에 쓰이는 유효한 언어이고, 실제 서비스에 쓸 프레임워크와 라이브러리도 있으며 수평 확장도 잘 됩니다. 설명하신 것과 정확히 같은 앱에서 일한 적이 있습니다. 다만 Flask나 Django 같은 HTTP 프레임워크는 C 연동 라이브러리를 많이 쓰고 요청 처리 자체에서 순수 Python이 차지하는 시간은 적습니다. 데이터베이스 왕복이 더 큰 병목일 수도 있어서 서버 200대가 반드시 이득을 보는 건 아닙니다. 제가 지금 하는 데이터 과학 작업에서는 더 큰 효과가 있을 수 있습니다. 이 분야도 대부분 C 연동을 쓰지만 프로세스 안에 순수 Python 코드가 꽤 있습니다.
• @u/boat-la-fds — Python 코드 대부분은 서버에서 Linux로 실행되니, 이 비교에서 Windows를 고른 건 다소 의아합니다. Linux와 Mac을 쓰는 Python 개발자의 합산 비중이 Windows보다 클 것 같습니다. Databricks 같은 관리형 서비스나 Windows의 WSL을 쓰는 사람도 실제 Python 코드는 Linux에서 돌리는 경우가 있습니다.
  • @u/HrHagen — 이 개발자 설문에서는 Windows와 Linux에서 개발하는 비율이 비슷합니다. 서버 시장은 Linux가 우세하겠지만 Windows 사용자를 과소평가하는 것 같습니다. 기업용 소프트웨어는 대부분 Windows 환경에서 씁니다.
  • @u/CrowdGoesWildWoooo — Windows에서 개발하더라도 Linux 서버에 배포한다는 지적은 맞습니다. 그러면 프로덕션 환경과 달라서 이 벤치마크의 실용성이 떨어집니다.
• @u/ApokatastasisPanton — 성능 향상은 무엇으로 설명할 수 있나요?
  • @u/amroamroamro — 아마 JIT 작업의 영향일 겁니다.
  • @u/fatoms — 릴리스 변경 사항을 보세요. 공식 Windows 64비트 바이너리는 이제 tail-calling interpreter를 사용합니다. MSVC 18.1.1 결과에서는 AMD Ryzen 7 5800X에서 switch-case 인터프리터보다 pyperformance 기하평균이 15~20% 향상됐습니다. Windows 64비트 바이너리가 MSVC 18의 새 기능을 사용하면서 가능해진 변화입니다. 제가 알기로 JIT는 여전히 실험적이고 직접 활성화해야 합니다. 더 가능성 높은 원인은 tail-calling interpreter입니다.
• @u/HAK_HAK_HAK — Python은 버전 간 업그레이드가 덜 번거로웠으면 좋겠습니다. .NET은 대개 그냥 잘 동작하고, 성능 향상도 따라옵니다.

원문: lewoniewski.info / 번역·요약: Trawling