I rewrote the benchmark in perl and julia as well. Kept it to its origins, and including startup interpreter time.
Original python:
#!/usr/bin/env python3
def main():
for j in range(20):
for i in range(1000000):
str(i)
main()
/usr/bin/time ./st.py
3.16user 0.02system 0:03.19elapsed 99%CPU
Perl port
#!/usr/bin/env perl
use strict;
sub main {
my ($i,$j);
foreach $j (0 .. 20) {
foreach $i (1 .. 1000000) {
sprintf "%i",$i;
}
}
}
/usr/bin/time ./st.pl
2.31user 0.00system 0:02.31elapsed 99%CPU
And julia
#!/usr/bin/env julia
function main()
for j in 0:20
for i in 1:1000000
string(i)
end
end
end
main()
/usr/bin/time ./st.jl
1.43user 0.52system 0:01.30elapsed 149%CPU
This isn't a very useful test of anything. The optimizations ceased being python after the use of the map with list. Then it delved into C. Which is precisely the point that Julia is attempting to solve by providing the power and performance, without the multi-language costs/overhead.
Note: This is Julia 1.4.1, Perl 5.30.2, and Python 3.8.2 running on my 2 year old linux laptop with a kaby lake processor.
FYI, the Perl equivalent is probably "$i" (which in my benchmarks results in ~41% of the runtime. It doesn't appear to be optimized away either, as an empty loop and one with a simple incrementing variable that's printed at the end result in 19% of the running time.
In Perl the appropriate way to convert a number to a string is to interpolate it or use a string based operator ("." for concatenation, etc) on it and let it convert the type itself. sprintf is very heavy and does quite a bit more than simply convert a number to a string.
Neat, the way I benchmarked was through BenchmarkTools.jl, which runs the functions sufficiently many times to get a statistically relevant result. It will not measure compilation time, but I did not include that for gcc / clang either.
Original python:
Perl port And julia This isn't a very useful test of anything. The optimizations ceased being python after the use of the map with list. Then it delved into C. Which is precisely the point that Julia is attempting to solve by providing the power and performance, without the multi-language costs/overhead.Note: This is Julia 1.4.1, Perl 5.30.2, and Python 3.8.2 running on my 2 year old linux laptop with a kaby lake processor.
[Edited to fix formatting]