[논문 리뷰] There is no fast lunch: an examination of the running speed of evolutionary algorithms in several languages

J. J. Merelo, Pablo García‐Sánchez외 2명|arXiv (Cornell University)|2015. 11. 03.

Evolutionary Algorithms and Applications참고 문헌 9인용 수 3

한 줄 요약

이 논문은 Lua, JavaScript(Node.js), Python, Scala의 네 가지 인기 있는 프로그래밍 언어를 대상으로 비트 반전 돌연변이 연산의 실행 속도를 벤치마킹한다. 이는 비트열과 벡터 표현 방식을 모두 사용한다. 연구 결과, 컴파일된 언어인 Scala와는 달리 인터프리터 기반 언어인 Python과 JavaScript가 다양한 문제 크기에서 더 빠른 성능을 보이며, 과학 계산 작업에서 컴파일된 언어가 항상 빠르다는 가정을 뒤집는다.

ABSTRACT

It is quite usual when an evolutionary algorithm tool or library uses a language other than C, C++, Java or Matlab that a reviewer or the audience questions its usefulness based on the speed of those other languages, purportedly slower than the aforementioned ones. Despite speed being not everything needed to design a useful evolutionary algorithm application, in this paper we will measure the speed for several very basic evolutionary algorithm operations in several languages which use different virtual machines and approaches, and prove that, in fact, there is no big difference in speed between interpreted and compiled languages, and that in some cases, interpreted languages such as JavaScript or Python can be faster than compiled languages such as Scala, making them worthy of use for evolutionary algorithm experimentation.

연구 동기 및 목표

• 진화 알고리즘(EA) 구현에서 컴파일된 언어(C++, Java, Scala 등)가 인터프리터 기반 언어(Python, JavaScript, Perl 등)보다 본질적으로 빠르다는 일반적인 가정을 도전하기 위해.
• 진화 알고리즘에서 자주 호출되지만 자주 간과되는 핵심 돌연변이 연산자 실행 성능을 널리 사용되는 프로그래밍 언어들에 대해 평가하기 위해.
• 유전자의 크기와 데이터 표현 방식(비트열 대 비트 벡터)에 따라 언어 선택이 런타임 성능에 미치는 영향을 평가하기 위해.
• 특히 과학 계산 환경에서 성능과 개발 효율성 양측을 고려한 연구자들이 언어를 선택할 수 있도록 실증적 근거를 제공하기 위해.

제안 방법

• 8비트에서 65,536비트까지 다양한 길이의 이진 문자열에서 비트 반전 돌연변이 연산의 성능을 Lua, JavaScript(Node.js), Python, Scala 네 언어로 벤치마킹한다.
• 비트열(문자열 형태의 '0'과 '1')과 벡터 기반 표현 방식(Scala에서는 Vector[Boolean], 다른 언어에서는 배열 등)을 사용하여 두 가지 데이터 표현 방식을 구현한다.
• 언어와 런타임 특성에 의한 성능 차이를 유일하게 고려하기 위해 알고리즘적 최적화나 라이브러리 수준 최적화를 피한 간결하고 일관된 구현을 사용한다.
• 각 테스트 케이스에서 10,000번의 돌연변이 연산 실행 시간을 측정하고, 통계 분석을 위해 CSV 형식으로 결과를 기록한다.
• R과 ggplot2를 사용해 성능 추세를 시각화하여 크기 변화에 따른 패턴, 정점, 성능 저하 여부를 식별한다.
• 다양한 문제 크기에서 결과를 분석하여 확장성 평가 및 언어별 성능 특성 파악

실험 결과

연구 질문

• RQ1 진화 알고리즘의 돌연변이 연산 런타임에 프로그래밍 언어 선택이 유의미하게 영향을 미치는가?
• RQ2 Python, JavaScript, Lua와 같은 인터프리터 기반 언어가 C++이나 Java, Scala와 같은 컴파일된 언어보다 기본 EA 연산에서 느리게 작동하는가?
• RQ3 비트열 대 비트 벡터와 같은 서로 다른 데이터 표현 방식이 언어 간 성능에 영향을 미치는가?
• RQ4 유전자의 크기 증가에 따라 성능이 비선형적으로 변화하는가? 실행 시간에 크기 기반 정점 또는 전환점이 존재하는가?
• RQ5 개발 속도와 생태계 지원을 고려할 때, 실세계의 EA 워크로드에서 인터프리터 기반 언어가 컴파일된 언어를 초월할 수 있는가?

주요 결과

• 작은 유전자의 크기(128비트 이하)에서는 Lua가 가장 빠른 성능을 보이며, 이 범위에서 모든 다른 언어를 앞서나갔다.
• Python과 JavaScript(Node.js)는 넓은 크기 범위에서 놀랍도록 일관된 성능을 보였으며, 1,024비트 이하에서는 문자열 크기에 관계없이 실행 시간이 거의 일정했다.
• 더 큰 유전자의 크기(1,024비트 초과)에서는 Python과 JavaScript가 강력한 성능을 유지했으며, 특히 가장 큰 크기 범위에서는 Python이 전체적으로 가장 빠른 성능을 보였다.
• Scala는 JVM를 대상으로 하는 컴파일된 언어임에도 불구하고, 대부분의 문제 크기에서 특히 128비트를 초월하면 Python과 JavaScript와 같은 인터프리터 기반 언어에 뒤지게 되었다.
• 언어 간 성능 격차는 크기 변화에 따라 일관되지 않았으며, 일부 언어(Lua 등)는 정점에 도달하는 경향을 보이며 런타임 환경에서의 효율적인 문자열 처리를 시사했다.
• 데이터 표현 방식(비트열 대 비트 벡터)의 영향은 측정 가능했지만 크기가 커질수록 점점 감소했으며, 인터프리터 기반 언어에서는 일반적으로 비트열 표현이 더 빠른 성능을 보였다.