How to call methods more efficiently in dynamic language

Joel이 Ruby성능에 대해 Ruby Performance Revisited를 통해 약간의 혹평(?)을 했습니다. 특히 Joel은 유니코드 등에 대한 루비의 입장에 대해서도 비판적입니다. 실제로 루비는 Joel글의 링크에 있듯이 자바에 비해 50x 느리다는 자료도 있습니다.

음 그래서 루비가 나쁘다는 것이 주제는 아니고.. Avi Bryant가 Ruby and Strongtalk에 duck typing을 쓰는 언어가 어떻게 성능을 개선하는가에 대해 설명을 잘 해두어서 그에대한 글을 올립니다. 커멘트 중에 보면 Digging into interface calls in the .NET Framework: Stub-based dispatch라는 글에 대한 링크가 있는데 역시 한번 볼만한 듯합니다.

한마디로 요약하면, ‘메소드가 몇번만 불려도 어떤 메소드에 대한 call인지 정보를 알 수 있고, 따라서 indirection없이 정확한 주소로 한번에 점프가 가능하다’란 것입니다. Avi Bryant는 따라서 vtable을 사용하는 C++ virtual method보다 더 빠르게 수행이 가능하다고까지 주장합니다. 그런데 지금의 Ruby가 느린이유는? 물론 구현이 Naive하기 때문입니다.

이런 방법들이 JIT등의 근간이 되는 건가 보군요..

Similar Posts:

Comments 6

  1. 이원구 wrote:

    정말 글에 써 있는데로 runtime profiling이 잘 되고 코드들이 협조해(?) 준다면 ruby의 dynamic method call의 성능이 평균적으로 C++보다 좋을 수도 있겠네요.

    하지만 C++의 dynamic method call의 비용은 예측 가능하지만 runtime profiling의 방법으론 예측이 불가능하거나 worst cast시의 비용이 지나치게 높아진다는 차이점이 특정 domain(real-time application과 같은)에서는 크게 작용할 것 같네요. :-)

    Posted 25 Sep 2006 at 8:48 am
  2. MKSeo wrote:

    네. 리얼타임에선 힘들겠죠. GC때문에라도 – GC는 예측불가능하게 발생하니까 – 리얼타임은 어려운문제인데, 그래서 GC시점을 적절히 조정하는 방법들도 많지만, 뭐 어쨌든 한계는 있는듯. 하지만 메모리를 다루는 걸 보면, 프로파일링을 사용함으로써 자바의 경우엔 오히려 C++보다 더 빠르게 메모리를 해제할 수 있습니다. 왜냐하면 메모리를 배치로 할당/해제할 수 있을 뿐더러, JVM이 프로그래머보다 메모리에 대해서는 더 잘 알 수 있기 때문이죠. (우리는 전체 시스템의 복잡한 메모리 할당 상황에 대한 통계나 모델을 갖고 코딩하지는 않으니까요.)

    현재까지는 인터프리팅 되는 언어가 컴파일된 언어보다 빠르게 동작하는건 힘들어보입니다. 특히나 헤비하게 메모리를 쓰는 apps에선 자바가 완전 꽝이죠. 대충알기로는 GC가 virtual memory와 잘 협조를 안한다네요. 그래서 메모리를 마구쓰기작하면 thrashing나버립니다. 루비야 compact gc 도 안하는 초보적인 단계지만, 자바와 비슷한 길을 갈 것으로 예측되고 언젠가는 자바만큼의 성능을 낼 것입니다.

    문젠 그래서 루비의 앞날을, 자바가 C++을 따라잡는가를 통해서도 생각해 볼 수 있는데, 현재로서는 요원해보이고, 무스탕은 기대해볼만 하다고 생각중입니다. 옵티마이제이션 기술들이 날이 갈수록 발전해가는듯해요.

    Posted 26 Sep 2006 at 9:52 pm
  3. CN wrote:

    루비의 가장 큰 문제는 EBNF로 표기가 불가능한게 아닌가 싶습니다. 이론적인 근거가 있어야 더 빨리 개발할 수 있을텐데요. 그 날이 언제올지…

    Posted 13 Oct 2006 at 10:19 am
  4. 공성식 wrote:

    CN:

    CN님 안녕하세요?
    루비를 EBNF로 표기할 수가 없다는 말씀이신가요?
    랭귀지를 만드는 쪽과는 별로 친숙하지 않아서 잘 모르겠습니다만
    루비가 EBNF로 표기할 수 없다는 사실은 처음 접해서 놀랐습니다.
    혹시 좀더 부연설명 해주실 수 있을까요?
    루비도 어차피 lex와 yacc으로 만들 텐데 EBNF로 표기할 수 없다는 게 무슨 뜻인지 좀 궁금합니다.

    Posted 13 Oct 2006 at 12:53 pm
  5. MKSeo wrote:

    @공성식: MS에서 .NET기반으로 옮기는데 EBNF를 그리다보니 EBNF만 수천장에 이르러 도무지 감당이 불가능했다고 하는 발표자료를 본 기억이 있습니다.

    Posted 13 Oct 2006 at 2:53 pm
  6. CN wrote:

    공성식,
    lex/yacc로는 가능하지만 순수 BNF으로는 곤란한 부분이 약간 있습니다. 그 부분들의 구현이 ad hoc이라는 비판도 있더군요.

    Posted 13 Oct 2006 at 9:27 pm

Post a Comment

Your email is never published nor shared.