(짧은쪽이 좋음)

2. 소스크기

스킴은 인터프리터마다 차이가 많고 리습계언어특성으로 저마다의 확장문법을 쓰기도해서 너무 혼돈스럽더군요. 그래서 앞으로 쓰기위한 근거로 언어스펙을 잘 지키면서도 동시에 속도가 괜찮다는 평을 받는것들만 대략 추려서 테스트해보기로 했습니다.  워낙 틈새언어인지라 누가 해놓은거도 없더군요. 후보군은 gauche racket ikarus chicken으로 좁혀졌는데 c로 컴파일이 되는 치킨은 자동으로 안깔려서 일단 젖혀놓았네요. (민트리눅스쓰니 점점 게을러지는듯..메이크화일 들여다봐야하는건 안쓰게되네요.)

벤치문제들은,

1.8퀸문제는 체스판에 8퀸을 서로 공격받지 않게 배치하는 해법을 모두 찾아내는 문제. (백트래킹기법)

2.피보나치수열문제는 30번째의 피보나치수 구하는 문제 (최적화사용없음)

3.1만개 정수 생성 후 퀵소트문제

4.1에서 1만까지중 소수를 걸러내는 문제(에라스토테네스의 체: 2의배수와 root이하의 수만 걸러내는 방식)

단위는 sec이고 소스는 로직상으로는 정확하게 맞췄지만 언어 특성상 실제구현은 크게납니다. 구현은 각 언어의 기본적으로 제공되는 형을 기준으로 썼고 로직은 mutable array를 사용한 c를 제외하고는 최적화같은거 고려안한 immutable기반의 순수 naive한 로직들입니다.

당연하지만 사기같은 c의 속도가 눈에 들어옵니다. 포트란이나 기계어수준으로 내려가지 않고서는 이 속도는 범접이 불가능할 듯 해요.

c#의 효율도 기대이상으로 좋네요. 자바도 절대 느리다곤 볼수없지만 자바보다 대체로 두배이상 빠르게 나옵니다. 

반면 요새 새로 뜨는 쥴리아는 효율적이라고 선전하는데 파이선같이 짜놓으니 타입추론같은게 개입되어서인지 파이선보다도 두배는 느리네요.  다시 해봤는데 구체적타입을 지정해도 거의 차이가 안납니다. 아직 최적화되지 않아 쥴리아 인터프리터자체가 느린것 같습니다.

하스켈의 경우 형지정한것과 안한것이 대략 4-50% 이상 차이나는군요. 위 자료는 형지정을 해준 데이터입니다.

(하스켈에서 8퀸문제는 구하는 방식이 모든permutation을 해서 거르는 방식으로 완전히 다르기때문에 지나치게 시간이 오래걸려서 제외했습니다.)

스킴계열로는 래킷을 많이쓰고 추천하기도 하지만 실제로 속도는 많이 떨어지고 일본분이 만든 고쉬가 매우 좋더군요. 직접 써보니 고쉬가 여기저기 최적화가 아주 잘되어있다는 느낌이 납니다. 파이선보다 2배까지 빨라요

파이선은 테일리커젼최적화가 안되기에 피보나치가 느리지만 스택을 비정상적으로 혹사하는 피보나치는 많이 예외적인거고 두루두루 쓰기에 역시 파이선이 참 괜찮다는 것도 새삼 느껴집니다. 

그런데 파이선과 비슷한 영역을 점유하는 루아가 상당히 소스코드도 간결하고 효율도 파이선보다 낫습니다. 가끔씩 파이선보다 루아를 선호하는 경우를 보는데 이해가 되네요.

물론 자료는 절대적인건 아니고 제가 언어마다 특성을 못살려서 짜서 그런게 있을것이고 인터프리터들이 제각기 로딩하는 방식이나 패키지가 다르므로 비교할수 없지만 그래도 참고삼아 올려봅니다.

환경: 커널 3.19.0-32-generic / i5-2310 ssd환경입니다