레이블이 Python인 게시물을 표시합니다. 모든 게시물 표시
레이블이 Python인 게시물을 표시합니다. 모든 게시물 표시

2018-05-13

2018년 19번째 주

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.


C Primer

Primer를 입문서라고 번역하는 게 맞는지 모르겠지만, 어쨌든 C 입문서라고 이름 붙인 문서 중에서 가장 마음에 든다. 다른 언어는 잘 추상화된 모델을 다루는 것이 중요하지만 C는 아니라고 생각한다. C는 내가 사용한 코드가 어떻게 변환되어 실행되는지 기계 단위로 이해하고 있어야 한다. 그럴 필요가 없는 상황에서는 C가 아닌 다른 언어를 써야 한다.

C Is Not a Low-level Language

C가 low-level 언어는 아니라는 글이다. 전통적으로 low-level 언어는 머신에 대한 추상화 없이 기계어와 일대일 대응되는 언어를 의미한다. 당연히 이런 의미에서 C는 low-level 언어가 아니다. C는 나름의 abstract machine을 가지고 있다. 특히 C11 이후로는 멀티 쓰레드에 대한 개념도 abstract machine에 들어갔기 때문에 전통적인 의미에서 low-level 언어는 아니다.

그렇다고 해서 C가 다른 high-level 언어와 같다는 의미는 아니다. 다른 high-level 언어들은 실제 기계어로 어떻게 번역되는지 몰라도 될 정도로 abstract machine을 정의한다. 하지만 C는 아니다. 사실 나는 C의 abstract machine도 기계를 몰라도 사용할 수 있을 정도로 잘 정의돼있다고 생각한다. 문제는 C를 사용하는 사람들이 실제 기계에서 어떻게 돌아가는지 고려하면서 코드를 작성한다. 이건 C언어 커뮤니티의 문제는 아니다. 사실 기계 레벨에서 어떻게 돌아가는지 고려하지 않아도 되는 프로젝트에서 C를 사용하는 것은 얻는 것에 비해서 비용이 크기 때문이다.

카카오스토리 웹팀의 코드리뷰 경험

코드리뷰 없는 프로젝트는 있을 수 없다고 생각한다. 하지만 발표자가 말하듯이 시스템적으로 반드시 리뷰해야 머지할 수 있는 시스템은 별로라고 생각한다. 경험적으로 이런 시스템은 반드시 문제가 생긴다. 간단한 예로 휴가철에 급하기 hotfix를 넣어야 하는데 휴가 안 간 사람이 한 명밖에 없을 때, 휴가 간 사람이 강제로 업무를 하게 되는 경우가 있다. 굳이 휴가철이 아니더라도 급한 버그를 위해 야근이나 주말 근무를 하는 경우도 마찬가지다. 시스템적으로 머지에 리뷰를 강제하게 되면, 버그를 잡고 머지 하기 위해서 버그 잡는 사람 외에 누군가가 남아있어야 한다. 결코 바람직하지 않은 상황이다.

리뷰를 받을지 말지 패치를 만든 사람의 판단으로 선택해야 한다. 그 패치가 리뷰를 받아야 할지 안 받아도 되는지는 패치를 작성한 사람이 가장 잘 안다. 이건 패치 만드는 사람의 판단을 따라야 한다. 만약 이 정도 판단을 믿지 못한다면, 그 사람에게는 코딩을 맡기면 안 된다. 바람직한 개발 프로세스는 상호 신뢰에서 나온다고 생각한다. 기본적인 신뢰 관계가 없는 팀에서는 아무리 좋은 프로세스를 선택하더라도 유지될 수 없다.

개발 스타일은 툴로 체크해야 한다는 것에도 동의한다. 툴로 체크할 수 있는 걸 사람이 보고 있는 건 시간 낭비다. 다만 윗글에서 나온 대로 수정한 코드에 대해서만 체크할 수 있는 툴은 찾기 어렵다. 그래서 나는 한 번 대대적으로 프로젝트의 스타일을 수정하고 시작하는 것을 더 선호한다. 이렇게 되면 작업하고 있던 사람들과 컨플릭이 나거나 blame으로 찾을 수 있는 이력이 더럽혀진다는 문제가 있다. 하지만 이런 문제가 통일되지 않은 스타일로 프로젝트가 계속 진행되거나, 리뷰마다 스타일을 눈으로 체크하는 것보다는 더 싸게 먹힌다고 생각한다.

By the numbers: Python community trends in 2017/2018

2017, 2018년도 python community를 분석한 글이다. 개인적으로는 Types of Python development 파트에 나오는 파이썬 사용자를 분야별로 나눈 파트다. 보면 파이썬 사용자는 크게 data scientist와 웹 개발자로 나눠진다는 것을 알 수 있다. 특히 data scientist를 다 합치면 웹 개발자보다 많은 비중을 차지한다. 이는 파이썬이 사용하기 편하다는 점도 있지만, numpy, PyTorch, TensorFlow 등 다른 언어에서는 찾기 힘든 좋은 툴들이 많이 있기 때문이라고 생각한다. 당장 나만 해도 개발할 때는 정적 타입 언어를 선호하지만, 자료 분석이나 수치 분석을 할 때 파이썬 외에 다른 언어를 사용하지 않는다.

그 다음으로 눈에 보이는 것은 파이썬과 함께 사용하는 언어로 JavaScript가 1위를 차지했다는 것이다. 개인적으로는 파이썬의 반대되는 컴파일된느 언어나 정적 타입 언어들과 함께 사용할 것이라고 생각했고, 언어적 특성이 비슷한 JavaScript와 함께 사용할 것이라고 생각하지 않았다. 2위가 HTML/CSS인 것을 보면 이는 파이썬 사용자의 절반 정도가 웹 개발을 하기 때문으로 보인다.

다음으로 인상적인 것은 Python 3의 사용자가 Python 2의 3배쯤 사용된다는 것이다. 몇 년 전만해도 많은 Python 2 사용자들이 Python 3로 넘어가지 않고 버티고 있었고, 많은 라이브러리가 Python 2만 지원했었던 것을 생각하면 시대가 많이 좋아진 것 같다.

가장 놀라운 것은 VCS를 안 쓰는 사람이 38%나 된다는 것이다. VCS를 안 쓰고 개발이 관리가 되나 싶은데 안 쓰는 사람이 38%나 된다. 심지어 테스트를 안 짜는 사람(19%)보다 많다.

Quantum resource estimates for computing elliptic curve discrete logarithms

일반적으로 현대 컴퓨터에서 elliptic-curve cryptography(a.k.a. ECC)는 같은 길이의 키를 가지는 RSA 방식보다 더 풀기 어렵다고 말한다. 예를 들어 키 크기가 256 bit인 ECC와 같은 보안 레벨을 가지려면 RSA는 3072 bit 키를 사용해야 한다고 한다. 하지만 양자 컴퓨터가 도입되면 이야기가 달라진다. 양자 컴퓨터로 쇼어 알고리즘을 사용하면 비대칭키 암호화 방식을 깰 수 있는데, 3072 bit RSA를 깨는데 6146 qubit이 필요하지만, 256 bit ECC를 깨는 데는 2330 qubit밖에 필요하지 않다. 여전히 같은 키 크기에서 RSA보다 ECC가 안전하지만, 기존에 안전하다고 여겨지던 것보다는 차이가 많이 줄어든다. 다행이도 아직은 양자컴퓨터가 수십 qubit 수준에서 연구 중이기 때문에 최소한 십 년 운 좋으면 몇십 년 내에서는 별문제 없을 것이라고 생각한다.

Announcing Rust 1.26

Rust 1.26이 나왔다. 일단 눈에 띄는 변화는 다음이 있다.

함수의 인자와 리턴 타입으로 impl Trait 허용

Rust의 trait은 크기가 없기 때문에, 함수의 인자로 받거나 리턴할 수 없었다. 이런 경우 Box로 싸거나, generic을 써야 했다. 이를 impl Trait라는 문법을 추가해서 간단하게 사용할 수 있도록 했다.

레퍼런스 타입 match 할 때, 자동으로 dereference

기존에는 레퍼런스 타입을 매칭하면 패턴 부분에도 전부 레퍼런스라는 것을 명시해야 했다. 이제는 레퍼런스를 자동으로 dereference하기 때문에 &ref를 쓸 필요가 없다.

main 함수가 Result 리턴할 수 있도록 허용

ErrDebug를 구현해야 한다는 제약이 있지만, 이제는 main 함수가 Result를 리턴할 수 있다. 리턴한 값이 Err라면 리턴한 Err를 출력하고 종료한다.

2017-01-28

[Python] negative index를 사용하자

 일반적으로 random access 가능한 자료 구조에서 뒤에서 k번째 원소를 가져오는 방법은 다음과 같다.

  1. 자료구조의 크기를 가져온다.
  2. 크기를 기반으로 접근할 인덱스를 구한다.
  3. 원하는 자료를 가져온다.

 이를 코드로 표현하면 다음과 같다.
 파이썬에서는 이를 보다 간결하게 표현하기 위해 negative indexing을 지원한다. negative indexing은 말 그대로 음수를 이용해서 뒤에서부터 자료에 접근하는 것이다. negative indexing을 이용하면 위의 코드는 아래와 같이 표현된다.

 파이썬에서는 뒤에서부터 접근할 때 negative indexing을 사용하는 것이 권장되지만 다른 언어로 코딩을 처음 배운 사람들은 파이썬에서도 길이를 가져와 인덱스를 계산하는 방식을 사용하는 경우가 종종 있다. 이런 사람들은 negative indexing이 단순한 syntactic sugar라고 생각하는 것 같다. 하지만 negative indexing은 syntactic sugar가 아니다.
 negative indexing이 syntactic sugar라면 negative indexing을 쓴 것과 같은 바이트 코드가 생성돼야 한다. 하지만 둘은 서로 다른 바이트 코드가 생성된다. 위의 각 코드가 실제로 생성하는 바이트 코드는 다음과 같다.
 첫 번째 코드는 global memory에서 len 함수를 찾아 호출하여 그 결과에 k를 뺀 값을 인덱스로 사용하는 코드를 생성하고, 두 번째 코드는 k를 음수로 만들어 바로 인덱스로 사용한다. 인덱싱을 통해 값을 가지고 오는 바이트 코드는 BINARY_SUBSCR인데, 물론 인터프리터가 BINARY_SUBSCR 를 실행할 때 주어진 인덱스가 음수이면 내부적으로 리스트의 길이를 가져와 인덱스를 다시 계산하는 과정을 거친다. 하지만 Global Interpreter Lock(a.k.a. GIL) 때문에 이 둘의 동작은 같지 않다.
 파이썬의 GIL은 바이트 코드 단위의 atomic만을 보장한다. LOAD_FAST 같은 몇몇 바이트 코드는 GIL을 릴리즈하지 않지만, CALL_FUNCTION을 포함한 대부분의 바이트 코드는 실행 후 GIL을 릴리즈 할 수도 있다.

 또한, 두 코드는 생성되는 바이트 코드가 다르므로 수행 시간도 다르다. 첫 번째 코드는 global memory에서 len 함수를 가지고 와 호출하는 비용이 더 든다.
 게다가 negative indexing을 사용할 때 BINARY_SUBSCR가 내부적으로 계산한 인덱스와 다르게 첫 번째 코드에서 직접 계산한 인덱스는 단순한 정수가 아니라 정수를 들고 있는 PyObject이다. 따라서 값을 할당하고 해제하는 비용이 더 들기 때문에 negative indexing을 사용하는 것이 더 빠르다.

2017-01-10

Python은 어떻게 swap하는가

 지난번 글에서 Lua의 multiple assignment를 이용한 swap이 내부적으로 어떻게 돌아가는지 설명했었다. 그렇다면 파이선은 어떨까?

 자신의 버추얼 머신의 구현까지 제공하는 루아와 다르게 파이선은 공식적으로 어떤 버추얼 머신을 사용해야 하는지 제공하지 않는다. dis 라이브러리를 통해서 어떤 바이트 코드가 나오는지 알 수 있지만, 구체적인 버추얼 머신의 스펙을 정의하거나 바이트 코드의 구현을 정의하지 않는다. 덕분에 PyPy, IronPython, Jython 등 다양한 구현체가 존재한다. 이번에는 우선 그중에서 사실상 표준 구현체라고 할 수 있는 CPython의 구현에 대해서 살펴보겠다.
 CPython의 버추얼 머신이 어떻게 구현돼야 하는가는 명확히 기술되지 않았지만, CPython의 바이트 코드를 보면, CPython은 Lua가 레지스터 머신을 사용하는 것과 다르게 스택 머신을 사용한다는 것을 쉽게 알 수 있다. CPython의 버추얼 머신은 스택과 글로벌/로컬 메모리를 가지고 있다. 글로벌 메모리와 로컬 메모리는 객체의 레퍼런스를 저장하는 데 사용되고 계산을 하기 위해서는 스택으로 레퍼런스를 복사해온 뒤 사용해야 한다.

 이제 swap이 CPython에서 어떤 바이트 코드로 컴파일되는지 살펴보자.  위와 같은 코드는 아래와 같은 바이트 코드로 컴파일된다.  여기서 ROT_TWO는 스택의 가장 위의 두 아이템의 위치를 바꿔주는 바이트 코드다. 즉, 위의 바이트 코드는 스택에 a를 올리고 b를 올린 뒤, 스택의 가장 위의 두 아이템의 위치를 바꾸고, 스택 가장 위의 아이템을 b에 다음 아이템을 a에 저장하는 것이다.

 그렇다면 ROT_TWO는 어떻게 구현됐을까? 현재 CPython에서 ROT_TWO는 임시 변수 2개를 사용하여 스택의 두 값의 위치를 바꾸는 것으로 돼 있다. 즉, CPython에서는 변수 2개를 스왑하기 위해서 스택의 두 자리, ROT_TWO에서 사용하는 임시 변수 두 자리까지 총 6개의 의자가 필요하다.

 로컬 메모리를 바로 복사하지 않고 스택에 올린 뒤 다시 로컬 메모리로 아이템을 옮기도록 하는 이유는 CPython이 로컬 메모리 사이의 연산을 허용하지 않는 stack-based 머신이기 때문이다. 하지만 이 점을 고려해도 CPython의 swap 구현은 비효율적이다. 왜냐하면, 이미 스택을 다른 의자로 사용하고 있는데, ROT_TWO의 내부 구현이 다시 임시변수를 의자로 사용하기 때문이다. 그래서 조금 더 효율적인 바이트 코드를 생성하는 PyPy의 경우 이는 아래와 같은 바이트 코드를 생성한다.  이는 단순히 스택에 a를 올리고, b를 올린 뒤 스택의 가장 위에 있는 아이템을 a로 다음 아이템을 b로 내리는 코드이다. 하지만 여전히 스택에 ab를 둘 다 올릴 자리가 필요하므로 총 4개의 의자가 필요하다.

 그렇다면 파이선에서도 전통적인 방법으로 3번째 변수를 사용해서 스왑하는 것이 좋을까? 아쉽게도 그렇지 않다. 이는 파이선이 스택 머신이기 때문이다. 전통적인 스왑 코드를 컴파일하면 CPython이나 PyPy 양쪽 모두 다음과 같은 바이트 코드가 나온다.  전통적인 방법을 사용하면 우선 a의 아이템을 스택에 올린 뒤 스택에 있는 아이템을 temp에 내린다. 같은 방식으로 ba로 옮기고, tempb로 옮긴다. 즉, temp 변수를 사용하더라도 스택을 한 칸 사용하기 때문에 역시나 총 4개의 의자가 필요하다. 또한, PyPy를 사용하면 LOAD_FASTSTORE_FAST를 각각 한 번씩 적게 사용하고, CPython을 사용하더라도 LOAD_FASTSTORE_FAST를 하는 것보다 ROT_TWO를 하는 것이 더 빠르므로 성능 면에서도 multiple assignment를 이용해 스왑하는 것이 더 빠르다.

2015-07-06

[Python] Gil과 Python

 지난번에 언급했듯이 CPython이나 PyPy는 Global interpreter lock(a.k.a. GIL)을 이용해서 동시에 2개 이상의 스레드가 실행되지 못하게 함으로써 스레드 간 동기화를 보장한다.

 하지만 이는 CPython과 PyPy가 thread를 구현하는 방법일 뿐, Python 스펙에는 동시에 2개 이상의 스레드를 실행시키지 말라거나, GIL을 사용하라거나 하는 말은 없다. 그저 CPython과 PyPy가 효율성을 떨어뜨리더라도 GIL을 사용하는 것이 이득이 되는 것이 많다고 생각해서 GIL을 사용하도록 구현한 것뿐이다.

 그래서 Python 구현체 중에서 .net framework 위에서 돌아가는 Iron Python이나 JVM 위에서 올라가는 Jython의 경우 GIL을 사용하지 않는다.