파이썬 : SWIG 대 CTYPES

https://stackoverflow.com/questions/135834

02-07-2019
|

문제

파이썬에서, 어떤 상황에서 공유 라이브러리에서 진입 점을 호출하기위한 CTypes보다 더 나은 선택이 있습니까? SWIG 인터페이스 파일이 아직 없다고 가정 해 봅시다.

이 둘의 성능 지표는 무엇입니까?

해결책

SWIG는 C 또는 C ++ 코드를 생성합니다. 간단한 기능 (직접 변환 할 수있는 것)에 사용하는 것이 간단하고보다 복잡한 기능 (예 : 파이썬에서 표현하기 위해 추가 번역 단계가 필요한 출력 매개 변수가 포함 된 기능)에 사용하기 쉽습니다. 인터페이스 파일의 일부로 C의 비트를 작성해야합니다. 간단한 용도 이외의 경우 CPYTHON에 대해 알아야 할 것입니다. CPYTHON과 그것이 어렵지 않고 염두에 두어야 할 물건을 나타내는 방법에 대해 알아야합니다.

CTypes를 사용하면 C 기능, 구조 및 기타 데이터에 직접 액세스하고 임의의 공유 라이브러리로드 할 수 있습니다. 이를 위해 C를 쓸 필요는 없지만 C의 작동 방식을 이해해야합니다. SWIG의 플립 측면을 논쟁 할 수 있습니다. 코드를 생성하지 않고 런타임에 컴파일러가 필요하지 않지만 간단한 사용을 위해서는 C 데이터 타입, 캐스팅, 캐스팅,와 같은 것들을 이해해야합니다. 메모리 관리 및 정렬 작업. 또한 올바른 메모리 레이아웃을 포함하여 동등한 CTYPES DATRASTRUCTURE로 C 스트루크, 유니온 및 어레이를 수동 또는 자동으로 번역해야합니다.

순수한 실행에서 SWIG는 CTYPES보다 빠를 가능성이 높습니다. 실제 작업 주변의 관리는 런타임의 파이썬이 아닌 컴파일 타임으로 C에서 수행되기 때문입니다. 그러나 많은 다른 C 함수를 인터페이스하지 않으면 각각 몇 번만 인터페이스하지 않으면 오버 헤드가 실제로 눈에 띄지 않을 것입니다.

개발 시간에 CTYPES는 시작 비용이 훨씬 낮습니다. 인터페이스 파일에 대해 배울 필요가 없으며 .C 파일을 생성하고 컴파일 할 필요가 없으므로 체크 아웃 및 침묵 경고가 필요하지 않습니다. 최소한의 노력으로 단일 C 함수를 사용하여 시작한 다음 더 많은 것으로 확장 할 수 있습니다. 그리고 당신은 Python 통역사에서 직접 테스트하고 시험해 볼 수 있습니다. CTYPES-CONFIGURE와 같이 더 간단하게 만드는 시도가 있지만 코드를 많이 마무리합니다.

반면에 SWIG는 여러 언어 (위에서 언급 한 사용자 정의 C 코드와 같이 필기가 필요한 언어 별 세부 사항을 제외하는 것을 제외하고)를 생성하는 데 사용될 수 있습니다. 도움말, 코드 생성은 또한 CTypes 동등한 것보다 설정하기에 훨씬 간단 할 수 있습니다.

다른 팁

SWIG를 사용한 풍부한 경험이 있습니다. SWIG는 그것이 물건을 포장하기위한 빠른 솔루션이라고 주장합니다. 하지만 실생활에서 ...

단점 :

SWIG는 모든 사람과 20 개 이상의 언어를 위해 일반적으로 개발되었습니다. 일반적으로 단점으로 이어집니다.
- 구성이 필요합니다 (swig .i 템플릿), 때로는 까다 롭습니다.
- 일부 특별한 경우 치료 부족 (Python Properties 추가 참조),
- 일부 언어의 성능 부족.

파이썬 단점 :

1) 코드 스타일 불일치. C ++와 Python은 코드 스타일이 매우 다릅니다 (확실히 명백합니다). 대상 코드를 더 많은 Pythonish로 만드는 SWIG의 가능성은 매우 제한적입니다. 예를 들어, getters와 setters에서 속성을 만드는 것은 엉덩이가 없습니다. 보다 이 Q & A

2) 광범위한 공동체의 부족. SWIG에는 좋은 문서가 있습니다. 그러나 문서에없는 것을 잡았다면 정보가 전혀 없습니다. 블로그 나 인터넷 검색도 도움이되지 않습니다. 그러므로 그러한 경우에 Swig 생성 코드를 크게 파야합니다 ... 끔찍합니다.

장점 :

간단한 경우에는 정말 빠르고 쉽고 간단합니다.
SWIG 인터페이스 파일을 한 번 제작 한 경우이 C ++ 코드를 다른 20 개 이상의 언어 (!!!)로 랩핑 할 수 있습니다.
SWIG에 대한 큰 관심사는 성능입니다. 버전 2.04 SWIG에는 '-Builtin'플래그가 포함되어있어 다른 자동 래핑 방법보다 SWIG가 훨씬 빠릅니다. 적어도 일부 벤치 마크 이것을 보여줍니다.

언제 swig를 사용합니까?

그래서 나는 SWIG가 사용하기에 좋은 경우 두 가지 사례에 대해 결론을 내 렸습니다.

2) C ++ 코드를 래프 해야하는 경우 여러 언어의 경우. 또는 잠재적으로 여러 언어에 대한 코드를 배포해야 할 때가있을 수 있습니다. 이 경우 SWIG 사용은 신뢰할 수 있습니다.

1) 필요한 경우 급속히 포장하다 몇 가지만 최종 사용을위한 일부 C ++ 라이브러리의 기능.

라이브 경험

업데이트 :
SWIG를 사용하여 라이브러리를 전환하면서 1 년 반이 지났습니다.

먼저 파이썬 버전을 만들었습니다. 우리가 SWIG로 어려움을 겪는 순간이 몇 차례있었습니다. 사실입니다. 그러나 지금 우리는 라이브러리를 Java와 .NET으로 확장했습니다. 그래서 우리는 1 개의 SWIG가있는 3 개의 언어를 가지고 있습니다. 그리고 나는 그렇게 말할 수있었습니다 바위 많은 시간을 절약하는 측면에서.

업데이트 2:
이 라이브러리에 SWIG를 사용하는 것은 2 년입니다. SWIG는 빌드 시스템에 통합되어 있습니다. 최근에 우리는 C ++ 라이브러리의 주요 API 변경이있었습니다. Swig는 완벽하게 일했습니다. 우리가해야 할 유일한 것은 .i 파일에 몇 %변경 사항을 추가하는 것입니다. CppCamelStyleFunctions() 지금 looks_more_pythonish 파이썬에서. 먼저 나는 발생할 수있는 몇 가지 문제에 대해 걱정했지만 아무 문제가 없었습니다. 그것은 훌륭했다. 단지 몇 가지 편집과 모든 것이 3 개 언어로 배포됩니다. 이제 우리의 경우 SWIG를 사용하는 것이 좋은 해결책이라고 확신합니다.

업데이트 3:
우리는 3 년 이상 도서관에 SWIG를 사용합니다. 큰 변화: 파이썬 부분은 순수한 파이썬에서 완전히 다시 작성되었습니다. 그 이유는 파이썬이 현재 라이브러리의 대부분의 응용 프로그램에 사용되기 때문입니다. 순수한 Python 버전이 C ++ 랩핑보다 느리게 작동하더라도 사용자가 기본 라이브러리로 어려움을 겪지 않고 순수한 파이썬으로 작업하는 것이 더 편리합니다.

SWIG는 여전히 .NET 및 Java 버전에 사용됩니다.

여기서 주요 질문은 "처음부터 프로젝트를 시작하면 Python에 Swig를 사용합니까?" 우리는 할거에요! SWIG를 통해 제품을 많은 언어에 신속하게 배포 할 수있었습니다. 그것은 우리에게 사용자 요구 사항을 더 잘 이해할 수있는 기회를 제공 한 시간 동안 일했습니다.

CTYPES는 SWIG보다 매우 시원하고 훨씬 쉽지만, 불량하거나 악의적으로 작성된 파이썬 코드가 실제로 파이썬 프로세스에 충돌 할 수있는 단점이 있습니다. 당신은 또한 고려해야합니다 후원 파이썬. IMHO 최종 Python 인터페이스를 더 많이 제어하면서 실제로 SWIG보다 쉽습니다. 어쨌든 C ++를 사용하는 경우 믹스에 다른 언어를 추가하지 않습니다.

내 경험에 따르면, CTypes는 큰 단점이 있습니다. 무언가 잘못되면 (그리고 복잡한 인터페이스가 항상 복잡한 인터페이스에 대해서는) 디버그하는 것은 지옥입니다.

문제는 스택의 큰 부분이 CTypes/FFI Magic에 의해 가려져 특정 지점에 어떻게 도달했는지, 왜 매개 변수 값이 그들이 ..

당신은 또한 사용할 수 있습니다 파이렉스, 높은 수준의 파이썬 코드와 저수준 C 코드 사이의 접착제 역할을 할 수 있습니다. LXML 예를 들어 Pyrex로 작성되었습니다.

나는 반대 할 것이고, 가능하다면, 당신은 당신이 표준 파이썬 API. 그것은 C와 Python 관점에서 실제로 잘 통합되어 있습니다 ... Perl API에 대한 경험이 있다면, 당신은 그것을 찾을 수 있습니다. 매우 기쁜 놀람.

CTYPES도 좋지만 다른 사람들이 말했듯이 C ++를 수행하지 않습니다.

당신이 포장하려는 도서관은 얼마나 큰가요? 코드베이스는 얼마나 빨리 변경됩니까? 다른 유지 보수 문제가 있습니까? 이것들은 아마도 파이썬 바인딩을 작성하는 가장 좋은 방법의 선택에 영향을 줄 것입니다.

CTypes는 훌륭하지만 C ++ 클래스를 처리하지 않습니다. 또한 CTypes가 직접 C 바인딩보다 약 10% 느리지만 이는 귀하가 부르는 것에 크게 달려 있음을 발견했습니다.

CTYPES와 함께 가려면 CTYPE 바인딩의 대규모 사례가있는 Pyglet 및 Pyopengl 프로젝트를 확실히 확인하십시오.

아직 언급하지 않은 몇 가지 고려 사항을 추가하고 싶었습니다. [편집 : Ooops, Mike Steder의 답변을 보지 못했습니다

비 Cpython 구현 (Pypy, Ironpython 또는 Jython)을 사용하려면 CTypes가 유일한 방법입니다. Pypy는 C- 텍스트를 작성하는 것을 허용하지 않으므로 Pyrex/Cython 및 Boost.python을 배제합니다. 마찬가지로, CTypes는 Ironpython과 (결국 일단 그들이 일단 작동하게되면) Jython에서 작동하는 유일한 메커니즘입니다.

다른 사람이 언급했듯이 편집이 필요하지 않습니다. 즉, 새 버전의 .dll 또는. 인터페이스가 변경되지 않는 한 교체가 줄어 듭니다.

명심해야 할 것은 SWIG가 CPYTHON 구현 만 목표로한다는 것입니다. CTYPES는 PYPY 및 IronpyThon 구현에 의해 지원되므로 더 넓은 Python 생태계와의 호환성을 위해 CTYPES로 모듈을 작성하는 것이 좋습니다.

나는 SWIG가 접근 방식 (일반적으로 Python뿐만 아니라)에 약간 부풀어 오르는 것으로 나타 났으며, 깨끗한 글을 쓰는 대신 Swig 친화적 인 사고 방식으로 Python 코드를 쓸 필요가 없으면 구현하기가 어렵습니다. -파이썬 코드를 작성합니다. C ++에 C 바인딩 (C ++를 사용하는 경우)에 C 바인딩을 작성한 다음 CTypes를 사용하여 C 층에 대한 인터페이스를 사용하는 것이 훨씬 간단한 프로세스입니다.

인터페이스하는 라이브러리에 라이브러리의 일부로 C 인터페이스가있는 경우 CTypes의 또 다른 장점은 별도의 Python-Binding Library를 컴파일하여 타사 라이브러리에 액세스 할 필요가 없다는 것입니다. 이는 교차 플랫폼 컴파일 문제를 피하는 순수한 파이썬 솔루션을 공식화하는 데 특히 좋습니다 (이질적인 플랫폼에서 제공되는 제 3 자 LIB의 경우). 컴파일 된 코드를 패키지에 포함시켜야한다는 것은 PYPI와 같은 제품에 배치하려는 것이 통증입니다. SWIG 또는 기본 명시 적 C 코드를 사용하는 Python 패키지에 대한 가장 자극적 인 포인트 중 하나는 일반적인 부주의 교차 플랫폼입니다. 따라서 크로스 플랫폼 사용 가능한 타사 라이브러리로 작업하고 주변의 파이썬 솔루션을 개발하는 경우이 문제를 고려하십시오.

실제 예로 Pygtk를 고려하십시오. 이것은 SWIG를 사용하여 GTK C 호출을 인터페이스하기 위해 C 코드를 생성합니다. 설정 및 사용이 실제로 고통 스러웠습니다. 설정시, 일반적으로 올바른 순서로 일을하지 않았다면 기발한 홀수 오류가 있습니다. 그것은 매우 실망스러운 경험이었고, 웹에서 GTK가 제공 한 Interace 정의를 살펴 보았을 때, 나는 그 인터페이스의 해당 인터페이스의 번역기를 Python CTypes 인터페이스에 작성하는 것이 얼마나 간단한 운동이라는 것을 깨달았습니다. Pyggi라는 프로젝트가 태어 났으며, 어느 날 Pygtk를 GTK C-Object-Oriented Interfaces와 깨끗하게 일치하는 훨씬 더 많은 기능 및 유용한 제품으로 재 작성할 수있었습니다. 그리고 C- 코드의 편집이 필요하지 않아서 교차 플랫폼 친화적 인 경우. (실제로는 webkitgtk와 인터페이스 한 후에는 그다지 크로스 플랫폼이 아닙니다). GTK를 지원하는 모든 플랫폼에 Pyggi를 쉽게 배포 할 수도 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow