4 ms·

> Unless you linearly scan the whole binary all the time, your CPU makes sure that only the stuff you're currently using is in the cache, so only the data your

by geocar 10y ago

> Unless you linearly scan the whole binary all the time, your CPU makes sure that only the stuff you're currently using is in the cache, so only the data your hot loop is touching. Cache fills optimize for linear scans, and have nothing to do with eviction. > You could easily see that your assumption is wrong by observing that a typical C application is not 1000 times faster than a typical Java application. What assumption are you talking about? Where do you find your typical applications? Spark is supposed to be one the fastest Java-implementations of a database system, and it's 1000x slower than the fastest C-implementation database systems, but this is clearly a problem limited by memory. What about problems that are just CPU-bound? C is at least 3x faster than Java for those[1], so just by being "a little bit faster" (if 3x is a "little" faster) then as soon as we introduce latency (like memory, or network, or disk, and so on) this problem magnifies quickly. [1]: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gcc&lang2=java https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

adrianN 10y ago
If your assumption that a 10MB JVM kills the cache were true, then the alioth benchmarks you have posted wouldn't show a speed difference of ~3. I suggest you learn a bit more about how CPUs work and what benchmarks mean before posting bold claims.
- geocar 10y ago
  Why not? Those problems fit into cache.
  - cbsmith 10y ago
    Because they are 333x slower than you'd expect.
cbsmith 10y ago
> Spark is supposed to be one the fastest Java-implementations of a database system, and it's 1000x slower than the fastest C-implementation database systems, but this is clearly a problem limited by memory. Wow.. so much wrong, I'm not sure how to unpack it all. a) Spark is Scala, not Java, though both do use the JVM, so I'll give you that. b) Spark is not a database system, though it is a framework for manipulating data c) Spark is generally considered to be much faster than Hadoop, and does it's job well, but I'm not sure it qualifies as the fastest anything. d) By any reasonable interpretation, the fastest Java database system is definitely not Spark. You will find that benchmarks of Java database systems generally don't even include Spark (as an example https://github.com/lmdbjava/benchmarks/blob/master/results/20160710/README.md https://github.com/lmdbjava/benchmarks/blob/master/results/2...) e) Fast is an ambiguous term... usually you are looking at things like latency, throughput, efficiency, etc. I'm not sure which you mean here. f) If you know anything at all about runtimes, you'd know that if you've found a Java based system that is 1000x slower than a C based system, either your benchmark is extremely specialized, broken, or you are comparing apples & oranges. Look, Java certainly has some overhead to it, and sometimes it significantly impacts performance. Before you get too excited about attributing it to runtime size, you might want to look at the size of glibc...
- geocar 10y ago
  > By any reasonable interpretation, the fastest Java database system is definitely not Spark What database would you recommend for solving the taxi problem using the JVM? > Spark is Scala, not Java, though both do use the JVM, so I'll give you that. What does JVM stand for? I was under the impression that we were talking about it's size (10mb v. 100mb). > You will find that benchmarks of Java database systems generally don't even include Spark And? What are we talking about here? > If you know anything at all about runtimes, you'd know that if you've found a Java based system that is 1000x slower than a C based system, either your benchmark is extremely specialized, broken, or you are comparing apples & oranges. Why? We're talking about business problems, not about microbenchmarks. If this is a business problem, and I solve it in 1/1000th the time, for roughly the same cost, then what exactly is your complaint? > Fast is an ambiguous term... usually you are looking at things like latency, throughput, efficiency, etc. I'm not sure which you mean here. It's not ambiguous. I'm pointing to the timings for a specific, and realistic business problem. > Look, Java certainly has some overhead to it, and sometimes it significantly impacts performance. Before you get too excited about attributing it to runtime size, you might want to look at the size of glibc... Does Java include glibc? What exactly is your point here?
  - cbsmith 10y ago
    > What database would you recommend for solving the taxi problem using the JVM? You have me at a disadvantage here... The only taxi problem that comes to mind is a probability problem that I'd not likely use a database for at all... > If this is a business problem, and I solve it in 1/1000th the time, for roughly the same cost, then what exactly is your complaint? If you came to the conclusion that your business problem runs 1000x faster because of differences in the runtime... you've made a mistake. It is far more likely your benchmark is flawed, or there are significant differences in the compared solutions beyond just the runtimes. Seriously, I've spent a career dealing with situations exactly like that: "hey, this is 1000x slower than what we are doing before... can you fix that?". Once you are dealing with optimized runtimes, while there can be important differences between them, there just isn't that much room left for improvement. > It's not ambiguous. I'm pointing to the timings for a specific, and realistic business problem. The problem is perhaps not ambiguous to you, but you haven't described it in terribly specific terms. More importantly though, you haven't described what you mean by "faster"? That's the ambiguity. > Does Java include glibc? > What exactly is your point here? C programs do. Lots of very efficient, high performance C programs.

by geocar 10y ago

adrianN 10y ago

If your assumption that a 10MB JVM kills the cache were true, then the alioth benchmarks you have posted wouldn't show a speed difference of ~3. I suggest you learn a bit more about how CPUs work and what benchmarks mean before posting bold claims.

geocar 10y ago
Why not? Those problems fit into cache.
- cbsmith 10y ago
  Because they are 333x slower than you'd expect.

cbsmith 10y ago

> Spark is supposed to be one the fastest Java-implementations of a database system, and it's 1000x slower than the fastest C-implementation database systems, but this is clearly a problem limited by memory. Wow.. so much wrong, I'm not sure how to unpack it all. a) Spark is Scala, not Java, though both do use the JVM, so I'll give you that. b) Spark is not a database system, though it is a framework for manipulating data c) Spark is generally considered to be much faster than Hadoop, and does it's job well, but I'm not sure it qualifies as the fastest anything. d) By any reasonable interpretation, the fastest Java database system is definitely not Spark. You will find that benchmarks of Java database systems generally don't even include Spark (as an example https://github.com/lmdbjava/benchmarks/blob/master/results/20160710/README.md https://github.com/lmdbjava/benchmarks/blob/master/results/2...) e) Fast is an ambiguous term... usually you are looking at things like latency, throughput, efficiency, etc. I'm not sure which you mean here. f) If you know anything at all about runtimes, you'd know that if you've found a Java based system that is 1000x slower than a C based system, either your benchmark is extremely specialized, broken, or you are comparing apples & oranges. Look, Java certainly has some overhead to it, and sometimes it significantly impacts performance. Before you get too excited about attributing it to runtime size, you might want to look at the size of glibc...

geocar 10y ago
> By any reasonable interpretation, the fastest Java database system is definitely not Spark What database would you recommend for solving the taxi problem using the JVM? > Spark is Scala, not Java, though both do use the JVM, so I'll give you that. What does JVM stand for? I was under the impression that we were talking about it's size (10mb v. 100mb). > You will find that benchmarks of Java database systems generally don't even include Spark And? What are we talking about here? > If you know anything at all about runtimes, you'd know that if you've found a Java based system that is 1000x slower than a C based system, either your benchmark is extremely specialized, broken, or you are comparing apples & oranges. Why? We're talking about business problems, not about microbenchmarks. If this is a business problem, and I solve it in 1/1000th the time, for roughly the same cost, then what exactly is your complaint? > Fast is an ambiguous term... usually you are looking at things like latency, throughput, efficiency, etc. I'm not sure which you mean here. It's not ambiguous. I'm pointing to the timings for a specific, and realistic business problem. > Look, Java certainly has some overhead to it, and sometimes it significantly impacts performance. Before you get too excited about attributing it to runtime size, you might want to look at the size of glibc... Does Java include glibc? What exactly is your point here?
- cbsmith 10y ago
  > What database would you recommend for solving the taxi problem using the JVM? You have me at a disadvantage here... The only taxi problem that comes to mind is a probability problem that I'd not likely use a database for at all... > If this is a business problem, and I solve it in 1/1000th the time, for roughly the same cost, then what exactly is your complaint? If you came to the conclusion that your business problem runs 1000x faster because of differences in the runtime... you've made a mistake. It is far more likely your benchmark is flawed, or there are significant differences in the compared solutions beyond just the runtimes. Seriously, I've spent a career dealing with situations exactly like that: "hey, this is 1000x slower than what we are doing before... can you fix that?". Once you are dealing with optimized runtimes, while there can be important differences between them, there just isn't that much room left for improvement. > It's not ambiguous. I'm pointing to the timings for a specific, and realistic business problem. The problem is perhaps not ambiguous to you, but you haven't described it in terribly specific terms. More importantly though, you haven't described what you mean by "faster"? That's the ambiguity. > Does Java include glibc? > What exactly is your point here? C programs do. Lots of very efficient, high performance C programs.