Ranking the Performance of Compiled and Interpreted Languages in Genetic Algorithms

Abstract

Despite the existence and popularity of many new and classical computer languages, the evolutionary algorithm community has mostly exploited a few popular ones, avoiding them, especially if they are not compiled, under the asumption that compiled languages are always faster than interpreted languages. Wide-ranging performance analyses of implementation of evolutionary algorithms are usually focused on algorithmic implementation details and data structures, but these are usually limited to specific languages. In this paper we measure the execution speed of three common operations in genetic algorithms in many popular and emerging computer languages using different data structures and implementation alternatives, with several objectives: create a ranking for these operations, compare relative speeds taking into account different chromosome sizes and data structures, and dispel or show evidence for several hypotheses that underlie most popular evolutionary algorithm libraries and applications. We find that there is indeed basis to consider compiled languages, such as Java, faster in a general sense, but there are other languages, including interpreted ones, that can hold its ground against them.

There is no fast lunch: an examination of the running speed of evolutionary algorithms in several languages

“…In fact, the examination of the running time of an evolutionary algorithm has received some attention from early on. Implementation matters [5,6], which implies that paying attention to the particular way an algorithm is implemented might result in speed improvements that outclass that achieved by using the a priori fastest language available. In fact, careful coding led us to prove [7] that Perl, an interpreted and not optimized for speed language, could obtain times that were on the same order the magnitude as Java.…”

Accidental Choices—How JVM Choice and Associated Build Tools Affect Interpreter Performance

“…Tiered execution allows an application to start quickly in the interpreter, transition to the client C1 compiler, and then to the server C2 compiler for extremely hot code. Some recent performance benchmarking of the JVM indicates that, for a small number of application cases, performance has surpassed that offered by ahead-of-time compiled code or is relatively no worse [4,[32][33][34][35][36][37][38][39]. Regarding energy performance, Java has been listed as one of the top five languages [40,41].…”