Hacker News Reader

Comment by bhauer | Hacker News Reader

As I wrote elsewhere in this thread (though I was downvoted), I suspect the reason is that this benchmark is measuring the total execution time of a single run of an executable. This would include any time spent by the executable to bootstrap its runtime environment, initiate a virtual machine, and whatever else it needs to do in addition to the relevant code at hand to process the string.

Such a test will favor implementations that have extremely svelte boostrapping, allowing them to immediately begin executing the relevant code and return a result.

I feel a more useful test would be for the relevant string processing code to be run tens to thousands of times within the process itself, so as to diminish the relative importance of boostrap/warmup code and/or runtime optimization performed by VMs. Unless, of course, part of the intent was specifically to measure the impact of the bootstrapping.

View on HN

In that case, it would change the Python result dramatically as well.

But I don't think it would be fair: I use Python a lot, and if it's for scripting, you are happy with the fact it's very easy to write. However, it's slow to start, and you pay that each time you run the script.

To me, it makes sense in this exercice, which is heavily leaning toward scripting, we see the price of the VM start in the overall profiling.

Otherwise, let's use pypy, warm it up, a few 1000 times, and you may get closer to Go times.

But we don't use pypy for scripting.

I agree that the benchmark should be run for much longer to get a useful result.

But why does Swift have a long startup time in the first place? Shouldn’t it start near instantly like the C and Rust programs?

I don't think Swift's performance is due to start up time at all. I actually cloned the repo, and ran the benchmark and found that Swift's execution time scales drastically with the size of the input. The Swift team actually boasts about its quick start up time on the official website [1]. I ran a simple hello world benchmark to gauge Swift's start up time and got an output of 13 milliseconds.

  echo 'print("hello world")' > hello.swift && swiftc hello.swift -O -o hello
  time ./hello

[1] https://www.swift.org/server/

Yeah the startup time for the Swift code is on the order of several milliseconds on my computer, the profiler running at 1000 Hz only gets four samples off of it

I was going to make a general comment about this too. It’s a huge penalty for Java too and has no correlation for how well it performs outside of toy benchmarks

… unless you’re using Java in the same way, such as an Azure Function or AWS Lambda. Or simply as a command-line tool.

IMHO, VM startup time should be included and the first few passes (before JIT kicks in) should also be included.

Java has supposedly “nearly C-like performance” until you read the fine print.

(This should apply to C# as well.)

> a huge penalty

Is that just your assumption or have you measured that penalty for this tiny tiny program?

Might "the JVM's slow start time" in this case be insignificant?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Reply on news.ycombinator.com