스택리스 파이썬의 단점은 무엇입니까?
최근에 스택리스 파이썬에 대해 읽었는데 바닐라 cPython과 비교하면 장점이 많은 것 같습니다.무한 재귀, 마이크로스레드, 연속성 등과 같은 모든 멋진 기능을 갖추고 있으며 동시에 cPython(파이썬 위키가 믿어지는 경우 약 10%)보다 빠르고 호환됩니다(최소한 버전 2.5, 2.6 및 3.0).
이 모든 것이 사실이라고 하기에는 너무 좋아 보입니다.하지만 TANSTAFL, 저는 Python 커뮤니티에서 Stackless에 대한 열정이 별로 보이지 않으며, PEP 219는 실현된 적이 없습니다.왜 그런 것일까요?스택리스의 단점은 무엇입니까?스택리스의 옷장에는 어떤 해골이 숨겨져 있습니까?
(Stackless는 실제 동시성을 제공하지 않으며, 동시성 방식으로 프로그래밍하는 더 쉬운 방법일 뿐입니다.별로 신경 쓰이지 않습니다.)
Wiki의 "스택리스가 10% 더 빠름"이 어디서 왔는지는 모르겠지만, 다시 말하지만 저는 그 성능 수치를 측정하려고 시도한 적이 없습니다.저는 Stackless가 그렇게 큰 차이를 만들기 위해 무엇을 하는지 생각할 수 없습니다.
스택리스는 몇 가지 조직적/정치적 문제가 있는 놀라운 도구입니다.
첫 번째는 역사에서 나옵니다.크리스찬 티스머는 약 10년 전에 결국 스택리스가 된 것에 대해 이야기하기 시작했습니다.그는 자신이 무엇을 원하는지에 대한 아이디어를 가지고 있었지만, 자신이 무엇을 하고 있고 왜 사람들이 그것을 사용해야 하는지 설명하는 데 어려움을 겪었습니다.이것은 부분적으로 그의 배경이 코루틴과 같은 아이디어에 대한 CS 교육을 받지 못했기 때문이고 그의 프레젠테이션과 토론이 매우 구현 지향적이기 때문인데, 이는 아직 지속적인 작업에 익숙하지 않은 사람들이 문제 해결책으로 사용하는 방법을 이해하기 어렵기 때문입니다.
그러한 이유로, 초기 문서는 부실했습니다.사용 방법에 대한 몇 가지 설명이 있었고, 타사 기여자들이 가장 잘 설명했습니다.PyCon 2007에서 저는 "스택리스 사용"에 대해 PyCon 설문 조사 수치에 따라 상당히 잘 설명했습니다.Richard Tew는 이것들을 수집하고, stackless.com 을 업데이트하고, 새로운 Python 릴리스가 출시될 때 배포를 유지하는 데 많은 노력을 기울였습니다.그는 게임 시스템의 필수적인 부분으로 스택리스를 사용하는 EVE Online의 개발자인 CCP Games의 직원입니다.
CCP 게임은 또한 사람들이 스택리스에 대해 말할 때 사용하는 가장 큰 실제 사례입니다.스택리스의 주요 튜토리얼은 그랜트 올슨의 "스택리스 파이썬과의 동시 프로그래밍 소개"로, 게임 지향적이기도 합니다.저는 이것이 사람들에게 Stackless가 게임 지향적이라는 왜곡된 생각을 제공한다고 생각합니다. 게임은 더 쉽게 계속 지향적입니다.
또 다른 어려움은 소스 코드였습니다.원래 형태에서는 파이썬의 많은 부분에 대한 변경이 필요했으며, 이는 파이썬의 리더인 Guido van Rossum을 경계하게 만들었습니다.그 이유의 일부는 나중에 "더 나은 상위 수준의 양식이 있을 때 goto를 지원하는 것과 너무 유사하다"는 이유로 제거된 call/cc에 대한 지원이었다고 생각합니다.이 기록에 대해서는 잘 모르니, 이 단락을 "Stackless used to required to too more changes."라고 읽으십시오.
이후 릴리스에서는 변경이 필요하지 않았으며, Tismer는 계속해서 Python에 포함되도록 추진했습니다.고려 사항이 있었지만 (제가 알기로는) 공식 입장은 Cython은 Python 구현일 뿐만 아니라 참조 구현으로 의미가 있으며, Jython이나 Iron Python에서 구현할 수 없기 때문에 Stackless 기능을 포함하지 않을 것입니다.
"코드 기반에 대한 중요한 변경"에 대한 계획은 전혀 없습니다.Arafangion의 인용문과 참조 하이퍼링크(댓글 참조)는 대략 2000/2001년의 것입니다.구조적인 변화는 오래전부터 이루어졌고, 이것이 바로 위에서 언급한 것입니다.현재와 같은 스택리스는 안정적이고 성숙하며, 지난 몇 년간 코드 기반에 약간의 수정만 있을 뿐입니다.
Stackless의 마지막 한계 - Stackless에 대한 강력한 옹호자는 없습니다.Tismer는 현재 Python for Python의 구현체인 PyPy에 깊이 관여하고 있습니다.그는 PyPy에 Stackless 기능을 구현했으며 Stackless 자체보다 훨씬 우수하다고 생각하며 PyPy가 미래의 방식이라고 생각합니다.튜는 스택리스를 유지하지만 옹호에는 관심이 없습니다.저는 그 역할을 맡을 것을 고려했지만, 그것으로 어떻게 수입을 올릴 수 있을지 알 수 없었습니다.
Stackless에서 교육을 받고 싶으시면 언제든지 연락주세요! :)
이 토론을 찾는 데 꽤 오랜 시간이 걸렸습니다.그 당시 저는 파이파이를 사용하지 않았지만 건강이 이 모든 것을 갑자기 멈출 때까지 싸이코와 2년간 연애를 했습니다.저는 이제 다시 활동적이고 대안적인 접근법을 설계합니다. 2012년 유로파이썬에서 발표할 것입니다.
앤드류스의 진술은 대부분 정확합니다.몇 가지 사소한 추가 사항:
Stackless는 통역 루프를 최적화했기 때문에 10년 전 CPython보다 훨씬 빨랐습니다.그 당시, Guido는 그것에 대한 준비가 되어있지 않았습니다.몇 년 후, 사람들은 유사한 최적화와 훨씬 더 나은 최적화를 수행했고, 이것은 예상대로 스택리스를 약간 느리게 만듭니다.
포함: 글쎄요, 처음에 저는 매우 강압적이었고 스택리스가 가야 할 길이라고 확신했습니다.나중에, 포함되는 것이 거의 가능해졌을 때, 저는 그것에 흥미를 잃었고 부분적으로는 좌절감에서, 부분적으로는 스택리스를 통제하기 위해 이 방식을 유지하는 것을 선호했습니다.
"다른 구현으로는 할 수 없다"와 같은 주장은 항상 시시하게 느껴졌습니다. 이 주장이 사용될 수 있는 다른 예도 있기 때문입니다.나는 그것을 잊고 귀도와 좋은 우정을 유지하고 나만의 디스트리뷰터를 갖는 것이 좋겠다고 생각했습니다.
한편, 상황은 다시 변하고 있습니다.나는 PyPy와 Stackless를 확장으로 작업하고 있습니다. 나중에 그것에 대해 이야기하겠습니다.
건배 -- 크리스
내 기억이 맞다면, 스택리스는 공식 CPython에 포함될 예정이었지만, 스택리스의 저자는 코드 베이스에 몇 가지 중요한 변경을 할 계획이었기 때문에, Cython 사람들에게 그렇게 하지 말라고 말했습니다. 아마도 그는 프로젝트가 더 성숙해질 때 통합이 완료되기를 원했을 것입니다.
저는 여기에 있는 답에도 관심이 있습니다.Stackless로 조금 해봤는데 표준 Python에 견고하게 추가하는 것이 좋을 것 같습니다.
PEP 219는 Python이 다른 스택으로 변경하기를 원할 경우 C 코드에서 Python 코드를 호출할 때 발생할 수 있는 잠재적인 어려움을 참조하십시오.C 스택을 손상시키지 않으려면 이를 탐지하고 방지하는 방법이 필요합니다.하지만 저는 이것이 다루기 쉽다고 생각하는데, 왜 스택리스가 스스로 서야 하는지도 궁금합니다.
언급URL : https://stackoverflow.com/questions/588958/what-are-the-drawbacks-of-stackless-python
'programing' 카테고리의 다른 글
| MariaDb를 사용하여 json(긴 텍스트) 열을 쿼리하여 키 아래에 지정된 값이 있는지 확인하려면 어떻게 해야 합니까? (0) | 2023.08.19 |
|---|---|
| bitnami mariadb의 Python 업데이트 쿼리 (0) | 2023.08.19 |
| 다른 Cmdlet을 호출하는 Cmdlet에서 PowerShell의 -WhatIf & -Confirm 매개 변수를 어떻게 지원합니까? (0) | 2023.08.19 |
| TSLint 오류 "최대 줄 길이 120을 초과함" (0) | 2023.08.19 |
| 독립 실행형 응용 프로그램에서 스프링 사용 (0) | 2023.08.14 |