코드 크기와 성능을 2차원으로 분석한 새로운 프로그래밍 언어 벤치마크 분석법

imyejin의 이미지

그 동안 프로그래밍 언어들을 비교하는 벤치마크의 대표적인 문제점 중 하나는 소스코드의 길이를 비교하지 않기 때문에 언어 구현체의 low level 기능이나 꼼수를 총동원해서 성능만 올려 놓는 코드가 과연 프로그래밍 언어를 비교하는 데 별로 의미가 없어지고 누가 그런 꼼수를 잘 부리냐에 좌우된다는 비판에서 자유롭지 못하다는 겁니다. (극단적인 비유로는 고급언어로 코딩했다고 하는데 사실은 인라인 어셈이 있어서 어셈으로 코딩한 거나 마찬가지다 ... 뭐 이런 거죠 ... 실제로 그런 코드를 제출하는 일은 없지만) 그런 문제점을 극복하기 위한 새로운 벤치마크 방법입니다.

http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html

이 벤치마크에서는 각 언어별로 여러 가지 벤치마크를에 대해 세로축을 소스코드의 길이 그리고 가로축을 성능으로 평가한 2차원에 배열해 놓고 그 무게중심(?)이 어디쯤에 위치하고 어떤 분포를 가지는가를 한눈에 알아볼 수 있도록 해서 현재 프로그래밍 언어들의 구현체에 대한 어느 정도 유의미한 직관을 얻을 수 있도록 정리하였습니다. 2차원 그래프의 사각형의 각 꼭지점이 의미하는 바는, 좌표축의 원점에 가깝다면 소스 코드도 짧고 성능도 좋다면 모든 용도에 이상적인 언어 혹은 언어 구현체, 세로축에 가깝지만 높이 있다면 소스 코드가 길어져도 성능을 얻을 수 있으면 시스템 프로그래밍에는 적합하지만 스크립팅에는 적합하지 않으며, 가로축에 가까이 있지만 원점에서 멀면 짧은 소스 코드로 문제를 해결하는 스크립팅에는 적합하지만 시스템 프로그래밍에는 적합하지 않고, 아예 원점에서 대각선으로 멀리 있는 넘은 언어나 언어 구현체에 문제가 있어 개선이 필요하다 이런 식으로 볼 수 있다고 하는군요. 소스코드의 크기를 측정하는 LOC나 바이트 수가 아니라 gzip으로 압축했을 때의 크기를 사용해서 정보이론적인 측정을 하려 노력한 거 같은데, 결과가 상식과 크게 다르지 않은 걸 보면 유의미한 방법인 것 같네요.

@ 출처는 haskell 메일링 리스트에서 퍼왔습니다.

aero의 이미지

위 분석과 관련 된 또 다른 관련 글
Fast, concise and reliable code? Try Perl!

imyejin의 이미지

이 벤치마크의 그래프상으로만 보자면 루아가 저 글에서 인용하는 다른 모든 스크립트 언어보다 좋은 모양을 보여주고 있는 거 같은데요, 왜 루아는 일부러 뺐는지 ㅎ

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

aero의 이미지

lua는 P(erl|HP|ython),Ruby과 겨루기에는 체급이 좀 딸리죠.

지리즈의 이미지

wow add-on도 lua로 되어 있지 않나요?

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

gurugio의 이미지


SBCL이 Lisp 툴이 맞겠지요? 제법 좋은 성능을 보여주네요.
CLISP가 없는게 아쉽지만 그래도 제가 시도해볼만한 언어중에서
SBCL의 결과가 좋아보여서 기분이 좋습니다.

C# 결과가 너무 좋은것 같아서 좀 의아합니다.
윈도우에서 실험해서 그런거겠지요?

----
섬기며 사랑하면 더 행복해집니다.
몸에 좋은 칼슘이 듬뿍담긴 OS 프로젝트 - 칼슘OS http://caoskernel.org

siabard의 이미지

스크립트 언어 정도의 성능을 보여줄 듯 합니다.. 공개 Common LISP 구현중에서는 역시 SBCL만한 것을 보기는 어렵죠..
예전에 CMUCL이 꽤 잘나갔는데.. 요즘은 SBCL이 더..

물론 상용제품을 쓸 수 있다면 Allegro CL을 쓰겠지만요..

--
새로움을 느끼기에 삶은 즐겁다..
모험가 아돌 크리스틴을 꿈꾸며..
Sia..

새로움을 느끼기에 삶은 즐겁다..
모험가 아돌 크리스틴을 꿈꾸며..
Sia..

chunsj의 이미지

저 그래프를 그릴 때 라이브러리와 그 라이브러리를 구현하기 위해서 사용된 코드의 길이도 포함한 걸까요?
아니라면 별로 의미가 없을 것 같은데...

imyejin의 이미지

얼마나 쓰기좋은 (de facto) 표준 라이브러리를 기본적으로 제공하느냐도 그 프로그래밍 언어의 유용성을 실용적으로 평가하는 데 의미가 있습니다. 프로그래밍 언어 매뉴얼에는 표준 라이브러리를 포함하는 것이 보통이고요. 그런 의미에선 당연히 라이브러리가 크기는 오히려 포함하지 않아야 의미가 있습니다. 벤치마크를 작성할 때 컴파일러와 함께 제공되는 라이브러리만 사용해야 하는 게 일반적인 규칙으로 알고 있습니다.

@ 라이브러리 줄 수를 따지기 시작하면 컴파일러를 코드 크기가 얼마나 되는지도 따져야 할까요?
@@ 특히 스크립트 언어들의 정규식 라이브러리 등 라이브러리의 상당 부분이 C등 다른 언어로 작성된 경우도 있는데 그럼 그런 경우는 라이브러리를 포함해서 줄 수를 잴 의미있는 방법조차 없습니다.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin