Yes, by not executing them in Python, the universal trick to make anything fast in Python.
Julia's whole shtick is avoiding having to drop down into C.
I find D's better-C dialect to be a definite improvement across the board, but there is a lot of institutional inertia behind C.
Again, I'm left wondering if this is proportional, or simply an X megabyte overhead of the runtime. Maybe it's even shared among all running programs, as some runtimes are. Or it looks like maybe stdio could be just particularly bad in Julia, and in practice I've never written a program for any environment where that was my performance bottleneck.
Performance is not easy to measure, and not easy to report. A single number makes a good headline but it's really not enough information.
Which is why the benchmarks game measures at more than one workload —
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> If you ignore startup time, Julia might have good performance for simple array/matrix operations and loops, but we already know how to make them fast in Python and other languages.
> And it’s not just scripts, Julia’s REPL which should ideally be optimized for responsiveness takes long to start and has noticeable JIT (?) lags. What’s even more worrying is that there doesn’t seem to be much progress there. The REPL was a pain to use a year ago and it still is.
> In addition to that, Julia programs have excessive memory consumption. The above hello world example in Julia uses 18x more memory than Python and 92x more memory than the C version.