잠재적 프로젝트 목록

잠재적 프로젝트 목록¶

참여하기¶
PyPy 생태계와 관련된 아이디어라면 언제든 함께 논의하고 싶습니다. RPython이나 PyPy를 가지고 놀아보는 데 관심이 있으시거나, 여기 언급되지 않은 새로운 아이디어가 있으시다면 irc의 #pypy 채널(irc.libera.chat)에서 저희와 함께해 주십시오. 확신이 서지 않지만 그래도 PyPy에 가치 있는 기여를 할 수 있다고 생각하신다면, 주저하지 마시고 #pypy나 저희 메일링 리스트로 연락해 주십시오. 생각해 볼 만한 아이디어 몇 가지를 소개합니다:

PyPy 메모리 사용량 최적화: 때때로 PyPy는 CPython보다 더 많은 메모리를 소비합니다. 두 가지 예시: 1) PyPy는 큰 Python 모듈을 임포트할 때 더 많은 문자열을 할당하고 계속 유지하는 것으로 보입니다. 2) PyPy의 기본 인터프리터 크기(콘솔에서 시작된 콜드 VM)는 CPython의 것보다 더 큽니다. 이 프로젝트의 일반적인 절차는 다음과 같습니다: 동일한 Python 버전의 CPython과 PyPy를 모두 실행하고 (Massif나 다른 도구를 사용하여) 메모리 사용량을 비교합니다. PyPy가 훨씬 더 많은 메모리를 사용한다면 문제를 찾아서 해결합니다.
VMProf + memory profiler: vmprof는 통계적 메모리 프로파일러입니다. 새로운 기능으로 확장하고 현재의 몇 가지 제한 사항을 해결하고자 합니다.
VMProf 시각화: vmprof는 통계적 프로파일의 플레임 그래프와 특정 호출 지점에 대한 몇 가지 추가 정보를 보여줍니다. 메모리 정보, 혹은 우리의 JIT 컴파일러가 생성하는 정보와 같은 다양한 정보로 실험해보는 것은 매우 흥미로울 것입니다.
RPython에서의 명시적 타이핑: PyPy는 RPython에서 시그니처와 클래스 속성 타입을 지정하는 더 나은 방법을 원합니다. 이 주제에 대한 자세한 내용은 이 페이지 아래쪽을 참고하십시오.
vmprof를 위한 가상 현실(VR) 시각화: 이는 프로파일에 대한 데이터 시각화를 탐구할 수 있는 매우 개방적이고 자유로운 주제입니다. 이 프로젝트에는 VR 하드웨어가 필요하지 않습니다. 대학교에서 그러한 하드웨어를 제공하거나, 그렇지 않은 경우에는 저희가 VR 하드웨어 설정을 대여해 드릴 수도 있습니다.

초보자를 위한 간단한 작업¶

random 최적화: https://github.com/pypy/pypy/issues/1901
소켓의 AF_XXX 패킷 타입 구현: https://github.com/pypy/pypy/issues/1942
문서화 작업을 도와주십시오. 한 가지 작업은 현재 이 사이트에만 나열되어 있는 rpython 설정 옵션들을 RPython 문서 사이트에도 문서화하는 것입니다.

중대형 작업¶
아래는 PyPy 프로젝트에 진지하게 관심 있는 잠재적 기여자들에게 흥미로울 만한 프로젝트 목록입니다. 이들은 대체로 공통된 패턴을 공유합니다 - 규모가 중간에서 큰 편이고, 보통 독립적인 프로젝트로 잘 정의되어 있으며, 현재 활발히 진행되고 있지는 않습니다. 작업하고 싶으신 소규모 프로젝트가 있다면 위쪽을 살펴보시거나, issue tracker를 확인하시거나, irc.libera.chat의 #pypy 채널에 들어오시거나, mailing list로 문의해 주십시오. 이는 단순히 가능한 작은 프로젝트들이 매우 빠르게 변하는 경향이 있기 때문입니다.
이 목록은 주로 잠재적인 프로젝트들을 개괄적으로 살펴보기 위한 것입니다. 이 목록은 본질적으로 완전하지 않으며, 사람들이 스스로 개선 아이디어를 떠올려 주신다면 기쁠 것입니다. 어떤 경우든, 이러한 프로젝트 중 하나 또는 PyPy의 다른 무언가에 대해 작업하고 싶으시다면, IRC에 들어오시거나 mailing list에 저희에게 글을 남겨 주십시오.

RPython에서의 명시적 타입 지정¶
RPython은 대부분 타입 추론에 기반하지만, 타입을 명시적으로 지정하는 것이 유용한 경우도 많습니다. 어떤 함수든 인자의 정확한 타입을 선택적으로 지정할 수 있기를 바랍니다. 이 분야에 대한 해결책으로 @rpython.rlib.objectmodel.enforceargs와 @rpython.rlib.signature.signature가 이미 있지만, 불편하고 제한적입니다. 예를 들어, “정수를 키로, Foo 인스턴스의 리스트를 값으로 갖는 dict”와 같은 타입은 쉽게 표현할 수 없습니다.
추가로, 인스턴스 속성의 타입을 지정할 수 있기를 원합니다. 함수의 경우와 달리, 이는 애노테이터의 일부 리팩터링을 필요로 할 가능성이 높습니다.

bytearray 타입을 빠르게 만들기¶
PyPy의 bytearray 타입은 매우 비효율적입니다. 이에 대한 가능한 최적화를 살펴보는 것은 흥미로운 작업이 될 것입니다. (XXX 현재 상태는 알 수 없습니다. 최신 정보는 #pypy에 문의하세요.)

복사 시 쓰기(copy-on-write) 리스트 슬라이싱 구현¶
이는 myslice = mylist[a:b]를 실행할 때 사용되는 리스트 객체의 특수한 구현을 갖는다는 아이디어입니다: 새 리스트는 즉시 생성되지 않고, myslice나 mylist가 변경될 때(그리고 변경되는 경우에만) 생성됩니다.

NumPy 재시동¶
우리의 cpyext C-API 호환성 레이어는 이제 업스트림 NumPy를 수정 없이 실행할 수 있습니다. 우리는 NumPy adds docstrings방식을 리팩터링해야 합니다.
또한 내부 _numpypy 모듈을 사용하여 NumPy의 dtype 변환과 ufunc 호출을 가로채(hijack) JIT이 이를 빠르게 처리할 수 있도록 만드는 방법에 대한 도움도 구하고 있습니다.

jitviewer 개선하기¶
애플리케이션의 성능을 분석하는 것은 언제나 까다롭습니다. 저희는 성능 분석에 도움이 되는 다양한 도구를 가지고 있는데, 예를 들어 jitviewer가 있습니다.
이전 도구는 일부가 다시 작성되어 vmprof와 결합되었습니다. 이 서비스는 vmprof.com에서 호스팅됩니다.
다음은 jitviewer의 예전 이미지를 보여줍니다. PyPy JIT가 계층적인 방식으로 생성한 코드:

최하위 수준에서는 컴파일된 루프의 Python 소스 코드를 보여줍니다.
각 소스 코드 줄에 대해, 해당하는 Python 바이트코드를 보여줍니다.
각 옵코드에 대해, 실제로 컴파일을 위해 백엔드로 전송되는 해당 JIT 연산을 보여줍니다(예제의 경우 i15 = i10 < 2000).

jitviewer는 django와 angularjs 기반의 웹 애플리케이션입니다: 뛰어난 웹 개발 능력을 갖추고 있고 PyPy를 돕고 싶다면, 내부 구조에 대한 깊은 지식이 필요하지 않기 때문에 시작하기에 이상적인 작업입니다. 미해결 이슈와 문서를 찾으려면 vmprof-python, vmprof-server, vmprof-integration을 참고하십시오.

RPython을 Python3로 변환하기¶
세상은 계속 나아가고 있으며, 우리도 그래야 합니다. 이 방향으로의 작업은 rpython3 브랜치에서 시작되었으며, 주로 Python3로 문서를 빌드할 수 있도록 하기 위한 것입니다. 신중한 리팩토링이 필요하다고 알려진 것들이 있습니다:

파이썬3에서 단일 문자는 바이트가 아니라 정수(int)입니다.
make_win32_traits에서 Windows의 서로 다른 작동 모드를 구분하기 위해 str/unicode를 사용합니다.

아마 더 있을 것입니다. 이 브랜치는 현재 RPython 테스트를 통과하지 못하므로, 일부 변경 사항을 되돌리고 제대로 다시 작업할 필요가 있습니다.

성능 개선¶

인라인화되지 않은 Python 레벨 호출을 더 빠르게 만들기
sea-of-nodes IR로 전환하거나, sea-of-nodes 방식을 반복적으로 발전시킨 Lua-Jit와 유사한 IR로 전환합니다.
실제 레지스터 할당(register-allocation)을 사용합니다
명령어 선택/스케줄링 개선
하이브리드 트레이싱/메서드 JIT 만들기

워밍업 개선¶

인터프리터 속도 향상
트레이싱 중 최적화
실행 간 정보 캐싱

변환 도구 체인¶
(XXX 이는 실현 가능성이 낮습니다.)

점진적 또는 분산된 변환.
확장 모듈의 개별 컴파일을 허용합니다.

다양한 가비지 컬렉터¶
PyPy는 교체 가능한 가비지 컬렉션 정책을 가지고 있습니다. 이는 특수한 목적을 위해 다양한 가비지 컬렉터를 작성할 수 있으며, 심지어 범용적인 목적을 위한 다양한 실험도 할 수 있음을 의미합니다. 예시:

모바일 기기를 위해 메모리를 더 잘 압축하는 가비지 컬렉터
동시(concurrent) 가비지 컬렉터(많은 작업이 필요함)
여러 fork()된 프로세스 간에 모든 페이지의 공유가 해제되는 것을 방지하기 위해 객체 플래그를 별도의 메모리 페이지에 보관하는 가비지 컬렉터

STM (Software Transactional Memory, 소프트웨어 트랜잭셔널 메모리)¶
이것은 저희가 개발을 중단한 실험이었습니다. 주요 개발 경로(목표는 STM을 포함하는 비교적 빠른 버전의 pypy를 만드는 것입니다) 외에도, 이미 존재하는 JIT가 없는 pypy-stm 버전에서 실험해볼 수 있는 독립적인 주제들이 있습니다:

실제 사용 사례에서는 어떤 종류의 충돌이 발생할까요? 그리고 때로는 어떤 자료구조가 더 적합할까요? 예를 들어, 해시 테이블로 구현된 dict는 한 스레드가 무언가를 쓸 때마다 모든 스레드에서 “stm 충돌”을 겪게 되지만, 다른 구현 방식도 있을 수 있습니다. 아마도 대안 전략은 파이썬 인터프리터 수준에서 구현할 수 있을 것입니다(list/dict strategies와 pypy/objspace/std/{list,dict}object.py 참고).
더 일반적으로 말하면, 버그가 아니라 STM 충돌인 것들을 “디버깅”하기 위한 일종의 “디버거” 같은 도구가 필요하다는 아이디어가 있습니다. 이 도구는 최종 사용자인 Python 프로그래머에게 어떻게 보일까요? 프로파일러처럼일까요? 아니면 중단된 트랜잭션에 중단점을 거는 디버거처럼일까요? 아마도 트랜잭션 충돌 등을 위한 몇 가지 훅과 함께 전부 앱 레벨일 것입니다.
내부적으로 스레드와 원자적 연산을 사용하지만 사용자에게는 스레드를 노출하지 않는 라이브러리를 만드는 좋은 방법을 찾습니다. 현재 lib_pypy/transaction.py에 초안이 있지만, 훨씬 더 나은 방법이 가능합니다. 예를 들어 각 루프 반복을 병렬로 실행할 수 있게 하는 반복자와 유사한 개념을 가질 수 있을 것입니다.

새로운 벤치마크 도입¶
우리 벤치마크 runner는 노후화되고 있습니다. CPython site와 병합해야 합니다.
또한, 저희는 보통 새로운 벤치마크를 추가하는 것을 환영합니다. 사전에 저희와 상의해 주시기 바라며, 일반적으로 실제 Python 코드이면서 아직 다루어지지 않은 것이라면 환영합니다. 최소한 매개변수 없이 실행할 수 있는 독립 실행형 스크립트가 필요합니다. 예시 아이디어(여기서 벤치마크를 추출해야 합니다!):

hg

C와의 인터페이싱¶
cpyext를 더 faster하게 만들 수도 있지만, 다른 아이디어들도 살펴보고 싶습니다. cffi는 소규모부터 중간 규모까지의 확장에는 적합하지만, HPy가 Python C 확장이 나아갈 길인 것으로 보입니다. 다음은 몇 가지 아이디어입니다:
* HPy를 돕고 프로젝트를 그쪽으로 이식하십시오
* JIT가 이해할 수 있는 백엔드를 갖도록 Cython을 확장
* C 확장 작성자와 협력하여 PyPy를 완전히 지원하도록 합니다 (아래 참조)
* PyPy 호환 패키지를 PyPI와 conda에 등록하기

더 많은 파이썬 모듈을 PyPy친화적으로 만들기¶
지난 몇 년간 CPython의 C-API 구현체인 cpyext가 실질적인 수준의 호환성에 도달하도록 많은 작업이 이루어져, CPython용 C 확장이 대규모 재작성 없이 PyPy에서 동작할 수 있게 되었습니다. 하지만 여전히 잘못 동작하는 여러 경계 사례와 예외 상황이 남아 있습니다.
PyPy와의 완전한 호환성을 아직 표방하지 않는 인기 있는 확장 기능이 있다면, 이를 자세히 살펴보고 PyPy와 완전히 호환되도록 만드는 것이 유용할 것입니다. 일반적인 과정은 다음과 같습니다:

PyPy에서 확장 모듈의 테스트를 실행하고 테스트 실패를 살펴보십시오.
실패 중 일부는 확장이 CPython의 문서화되지 않은 내부 세부 사항에 의존하는 경우를 파악하고, 해당 코드를 문서화된 모범 사례를 따르도록 다시 작성함으로써 해결할 수 있습니다. 확장의 개발 프로세스에 맞게 이슈를 등록하고 풀 리퀘스트를 보내주십시오.
다른 실패는 cpyext와 CPython 간의 비호환성을 드러낼 수 있습니다. 이를 저희에게 보고하고 수정해 보시기 바랍니다.
확장 개발자가 제공했거나 여러분이 직접 만든 벤치마크를 실행합니다. PyPy가 CPython보다 현저히 느린 경우는 모두 버그로 간주하고 위와 같은 방법으로 해결합니다.

대안으로, 저희가 예전에 권장하던 방법은 C 확장을 cffi와 같은 pypy 친화적인 기술을 사용해 다시 작성하는 것이었습니다. 아직 마무리가 필요한 좋은 작업들의 일부 목록은 다음과 같습니다:
wxPython-cffi archived copy of the bitbucket repo

상태: Phoenix sip 빌드 시스템을 cffi에 맞게 조정하려는 PyPy 개발자의 프로젝트
이 프로젝트는 2013년 GSOC https://waedt.blogspot.com/ 의 후속 프로젝트입니다.
TODO: 아카이브를 되살리고, 최신 버전의 래퍼(wrapper)를 병합하여 sip 변환을 완료할 것

pygame https://github.com/CTPUG/pygame_cffi

상태: 마지막 릴리스는 2017년이었습니다