Comments

7 responses to “How to call methods more efficiently in dynamic language”

1. 

   이원구

   September 25, 2006

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

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

2. 

   MKSeo

   September 26, 2006

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

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

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

3. 

   CN

   October 13, 2006

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

4. 

   공성식

   October 13, 2006

   CN:

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

5. 

   MKSeo

   October 13, 2006

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

6. 

   CN

   October 13, 2006

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