Ruby3x3

저자

@wagurano 줄여서 와그, 루비니언, 평화를 사랑하며 코딩하는 프로그래머

시작하며

서울 펄 몽거스의 펄 크리스마스 달력을 참고하여 루비 크리스마스 달력(Advent Calendar)에 참여하는 글입니다.

지난 9월말쯤 트위터에 마츠모토 유키히로(이하 마츠)씨가 루비 3.0에 대해 발표하였습니다. 그리고 얼마전 11월 루비 컨퍼런스에서 Ruby3 challenges 라는 제목으로 루비 2.3.0과 루비3.0에 대해 소개하였습니다. 여기서는 11월 컨퍼런스 동영상, 모두발언 및 질의응답을 토대로 일부 재구성하여 요약 전달해드리겠습니다.

준비물

콘프릭스의 유투브 채널을 이용해주세요. http://www.confreaks.tv/events/rubyconf2015
9월의 트윗을 참고하세요.

마츠 소개

'마츠모토 유키히로'씨는 '마츠'로 줄여서 부릅니다. 루비 협회와 헤로쿠 소속입니다. 트위터 계정은 @yukihiro_matz (Yukihiro "Matz" Matsumoto) 입니다. 마츠는 영어를 쓰는 유럽쪽 외국인이 발음하기에 메이저리그의 뉴욕 '매츠'처럼 들리기도 합니다. 일본 오사카에서 1965년 4월에 태어나 2015년 현재 우리나이로 51세입니다. 그는 유쾌하며 친절합니다. 루비 세계의 창시자로 존경받고 있습니다. 우리나라의 비슷한 세대로 80년대 중반 학번인 대학교수님들을 떠올릴 수 있습니다.

참고 '루비'의 아빠, 마츠모토 유키히로(블로터)

Make something people want(X) => need!(O)

마츠는 사람들이 원하는 것보다 필요한 것을 만든다며 앨런 케이의 말을 인용하였습니다. 미래를 예측하기 어렵기에 무엇을 만들어야 할지 방향을 설계하는 것은 어렵다고 합니다. 시스템이 느리고 짜증날 때 갈아 엎고 새로 만들어 시스템을 좀 더 완벽하게 만들고 싶은 마음은 환영이라고 지적하며, 좀 더 잘해보겠다는 욕심에 사장님이나 관리자에게 갈아엎자고 설득한다고 합니다. 이에 앞서 프로그래머의 세가지 덕목을 제시하였는데 태만, 불만, 자만입니다. 사전에 실린 뜻과 달리 시스템을 개선하려고 솟구치는 마음을 강조하였습니다.

근황

루비는 2.0버전부터 매년 5~10% 속도를 개선하고 있으며, 마츠는 루비를 자신만의 언어가 아니라 커뮤니티 노력의 결실이라고 말합니다. 마츠는 현재 스트림(github.com/matz/streem)라는 실험 프로젝트를 진행하고 있다고 합니다.

프로그래밍 언어를 설계하는 것은 어렵다는 것을 보여주는 사례

펄5와 펄6: 펄6는 2000년에 시작하였으며 새로운 문법과 가상머신을 설계하여 발표하는데 15년이 걸렸습니다.
파이썬2와 파이썬3: 파이썬3000 프로젝트는 2006년에 시작하였고 2008년에 출시하였습니다. 이전 방식의 코드를 버리지 않았으며 파이썬3를 많이 쓰고 있지만 파이썬2도 여전히 많이 쓰고 있고, 호환성을 고려해야 한다고 합니다.
PHP는 PHP6를 건너뛰었습니다.
자바스크립트는 ES4를 두번 철회하였습니다.
루비1.8과 1.9:
- 루비속도와 다국어지원에 관한 문제를 2000년 검토하여 2004년에 착수하였습니다.
- 속도를 개선하기 위해 YARV(새로운 가상머신)을 도입하고 1.9는 2007년에 발표하였고. 호환성 문제가 있었습니다.
- 스트링 클래스와 가비지 콜렉터를 하나씩 점진적으로 개선하였습니다.
루비 버전
- 버전의 숫자와 프로그래밍 언어의 변화는 체감하는 것과 달랐습니다.
- 버전을 업그레이드할 때 그럴만한 혜택을 줘야 하며,
- 속도를 개선하면서 호환성을 유지해야 합니다.
- 1.9.3에서 2.0으로 넘어갈 때 대체로 호환성을 유지하려고 했습니다.

루비 3의 주요 특징

지향점
- 멀티 코어
- 코드 스케일러빌러티
- 데이타 스케일러빌러티
구상
- 병렬처리
- 사람과 기계의 협력
- 성능개선
업그레이드 원칙
1. 예전 것을 버리지 않는다.
2. 새로운 것을 강요하지 않는다.
3. 버전을 업그레이드할 만한 혜택을 제시한다.
4. 왠만하면 호환성을 유지한다.

프로그래밍 환경이 싱글 프로세서에서 멀티 코어 프로세서로 바뀌었습니다. YARV를 도입한 2004년의 개인용 컴퓨터는 대부분 멀티 코어 프로세서가 없었지만, 멀티 코어 프로세서가 등장함에 따라 병렬처리가 주목받고 있습니다. 병렬처리는 속도개선면에서도 중요합니다. 그리고 스크립트 언어로 만든 프로젝트 규모(예, 레일스)가 커짐에 따라 코드 규모를 넓힐 수 있는 기능이 필요하게 되었습니다. 루비 차세대 버전이 필요합니다.

병렬처리

루비3에 대한 구상을 구체적으로 하지 못하였고 실험적인 개념만 있다고 합니다. 병렬처리는 멀티 코어를 위해 필요하며 쓰레드가 떠오르는데, 쓰레드는 개념이 간단, 명료하면서도 사용하기 쉬워야 합니다. 병렬처리하기 위해 액터 모델, 오너쉽 모델, STM, 스트림 모델을 검토하고 있습니다.

액터 모델은 공유하지 않고 메시지를 넘겨줍니다. (예. 얼랭, 엘릭서, 스칼라, 고) 기본 액터 모델은 간단하며 쓰레드와 메일박스를 생각할 수 있습니다. 그러나 공유하지 않는 것이 어렵습니다.
오너쉽 모델은 러스트의 메모리 모델과 유사합니다. 다른 쓰레드에게 메시지를 건내줄 때 오너쉽도 함께 넘겨줘야 하며 오너쉽을 함께 넘겨줘야 수정할 수 있습니다.
STM(Software Transactional Memory) (예. 클로저) 서로 공유하고 수정할 수 있지만 충돌이 생기면 롤백하는데, 구현하기 어렵다고 합니다.
스트리밍 모델은 파이프라인으로 데이타를 이동합니다. 이에 따라 새로운 연산자로 "|>"를 도입합니다. 쉘에서 cat 명령어와 파이프를 쓰듯이 STDIN |> STDOUT 합니다.
- 에코 서버 사례

    TCPServer.new(8007) |> Stream.map{|sock| sock |> sock }

네트워크 cat 명령어 사례

    sock = TCPSocket.new("localhost", 8007)`
    STDIN |> sock
    sock |> STDOUT

새로운 연산자 "|>"의 이름은 아직 없고 이벤트-드리븐 루프를 만듭니다. 마츠는 루브 골드버그 프로그래밍이라고 말하였습니다.

참고. 루브 골드버그 장치: "간단히 행해질 수 있는 일을 매우 복잡한 방식으로 처리하는” 무언가

이벤트-드리븐 루프를 만들어서 쓰레드 세이프티를 보장하고 객체가 변하지 않도록 합니다. 이벤트 루프는 두번째 가상머신에서 돌아가며 GIL(Global Interpreter Lock)이 없고 이뮤터블(불변)하고 100% 병렬처리하지 못합니다.

실험 프로젝트

개념을 실증하기 위해 Streem 이라는 프로젝트를 시작하였습니다. 가비지 콜렉터와 가상머신을 개선하여 속도를 향상하고 있으며 루비3의 목표를 3배 빠르게 개선하도록 정하였습니다. Ruby3x3으로 루비2보다 3배 빠르도록 성능을 향상시킨다고 할 때 사람들이 갈채를 보냈습니다.

앞으로 할 일

병령처리, 자료구조와 알고리즘 개선, JIT 컴파일, AOT 컴파일 등을 나열하며 존 F 케네디의 달탐사에 관한 휴트턴 연설을 인용합니다. 그것이 쉽기때문이 아니라 어렵기 때문이다라고 말하며, 앞으로 도쿄 올림픽이 열리는 2020년을 목표로 개발한다고 합니다.

협력 회사

앱폴리오(부동산 관리 소프트웨어 회사)
헤로쿠
IBM

커뮤니티 도움이 필요한 일

마츠는 자신이 루비 프로그래밍 언어를 만들었지만 커뮤니티의 노력이 결실을 맺어서 루비를 만들었다고 강조하였습니다. 루비 프로그래밍 언어에 기여하는데 벤치마크를 하거나, 병렬처리에 관한 지식을 알려주거나, 루비 3에 대한 독특한 아이디어를 제시하면 좋겠다고 말하였습니다.

정리하며

속도를 개선하며 병렬프로그래밍하기위해 엘릭서, 고, 러스트 등으로 눈길을 돌리고 있습니다. 언젠가 루비 세계는 멈출지 모릅니다. 마츠는 루비가 도태되지 않도록 꾸준히 개선하고 있습니다. 루비는 파고 들수록 뭔가 빠져들게 하는 매력이 있습니다. 펄처럼 차세대 버전이 나오는데 생각보다 시간이 더 걸릴지도 모르고 앞으로 루비3가 어떻게 바뀔지 예측하기 어렵지만 그 변화는 열려있습니다. 깃헙으로 가서 소스 저장소를 내려받아보세요. 루비를 공부하다가 간만에 C언어와 컴파일러 책을 다시 봐야겠습니다.

Ruby: A Programmer's Best Friend

EOT

wagurano/ruby3x3.md