3 ms·

> Unless you're using order of magnitude to mean 2x, it's not the case that Java/Go/Haskell are an order of magnitude slower than C/C++/Rust. It depends, in so

> Unless you're using order of magnitude to mean 2x, it's not the case that Java/Go/Haskell are an order of magnitude slower than C/C++/Rust. It depends, in some benchmarks they are 10 times slower.

hyperpape 9y ago
And you can construct cases where the JVM is infinitely faster than C/C++/Rust, because the JIT optimizes through a virtual call and detects dead code. Should we say that "it depends, in some cases, Java is infinitely faster than C/C++/Rust"? Not unless we want to deliberately obscure the issue (or we want to warn someone about strange results). Benchmarks are about finding representative results across a variety of tasks. If you think there are good benchmarks that show these languages are 10x slower in realistic cases, then you should share them, rather than just asserting that they're out there.
- weberc2 9y ago
  This is kind of my point; the variance and error margin are pretty wide. Specifying "2x" implies a precision I can't vouch for, so I settled for "an order of magnitude" as the general ballpark. If the 2x figure is important to you, I'm happy to make that concession.
  - hyperpape 9y ago
    I get the concern, but I'd say "a few times slower", which suggests 2x/3x/4x, not "an order of magnitude", which suggests something like 8x or 20x or whatever.
    - Can_Not 9y ago
      Orders of magnitude actually suggest the data would be best measured in exponents such as 10^3, 10^4, 10^5, etc because of it's range and distribution.
- whyever 9y ago
  > Benchmarks are about finding representative results across a variety of tasks. > And you can construct cases where the JVM is infinitely faster than C/C++/Rust, because the JIT optimizes through a virtual call and detects dead code. How would that be a "representative result across a variety of tasks" according to your own definition of a benchmark? What do you mean by "across a variety of tasks"? That sounds like taking the average of some metric for different benchmarks, I'm not sure that is a good idea. I think it makes more sense to benchmark your specific use case, which is what I meant by "it depends". > If you think there are good benchmarks that show these languages are 10x slower in realistic cases, then you should share them, rather than just asserting that they're out there. I never said anything about "realistic" and "good", but they are really not unthinkably hard to find: http://benchmarksgame.alioth.debian.org/u64q/binarytrees.html http://benchmarksgame.alioth.debian.org/u64q/binarytrees.htm...

> Unless you're using order of magnitude to mean 2x, it's not the case that Java/Go/Haskell are an order of magnitude slower than C/C++/Rust. It depends, in some benchmarks they are 10 times slower.

hyperpape 9y ago

And you can construct cases where the JVM is infinitely faster than C/C++/Rust, because the JIT optimizes through a virtual call and detects dead code. Should we say that "it depends, in some cases, Java is infinitely faster than C/C++/Rust"? Not unless we want to deliberately obscure the issue (or we want to warn someone about strange results). Benchmarks are about finding representative results across a variety of tasks. If you think there are good benchmarks that show these languages are 10x slower in realistic cases, then you should share them, rather than just asserting that they're out there.

weberc2 9y ago
This is kind of my point; the variance and error margin are pretty wide. Specifying "2x" implies a precision I can't vouch for, so I settled for "an order of magnitude" as the general ballpark. If the 2x figure is important to you, I'm happy to make that concession.
- hyperpape 9y ago
  I get the concern, but I'd say "a few times slower", which suggests 2x/3x/4x, not "an order of magnitude", which suggests something like 8x or 20x or whatever.
  - Can_Not 9y ago
    Orders of magnitude actually suggest the data would be best measured in exponents such as 10^3, 10^4, 10^5, etc because of it's range and distribution.
whyever 9y ago
> Benchmarks are about finding representative results across a variety of tasks. > And you can construct cases where the JVM is infinitely faster than C/C++/Rust, because the JIT optimizes through a virtual call and detects dead code. How would that be a "representative result across a variety of tasks" according to your own definition of a benchmark? What do you mean by "across a variety of tasks"? That sounds like taking the average of some metric for different benchmarks, I'm not sure that is a good idea. I think it makes more sense to benchmark your specific use case, which is what I meant by "it depends". > If you think there are good benchmarks that show these languages are 10x slower in realistic cases, then you should share them, rather than just asserting that they're out there. I never said anything about "realistic" and "good", but they are really not unthinkably hard to find: http://benchmarksgame.alioth.debian.org/u64q/binarytrees.html http://benchmarksgame.alioth.debian.org/u64q/binarytrees.htm...