3 ms·

> 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, b

by 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.
  - geocar 10y ago
    > The only taxi problem that comes to mind It's the problem that I linked to previously. http://tech.marksblogg.com/benchmarks.html http://tech.marksblogg.com/benchmarks.html Finding good benchmarks is hard: Business problems are a good one because these are the ways experts will solve problems using these tools, and we can discuss the choice of tooling, whether this is the right way to solve the problem, and even what the best tools for this problem is -- in this case, GPU beats CPU, but what's amazing is just how close a CPU-powered solution gets by turning it into a memory-streaming problem (which the GPU needs to do anyway). > If you came to the conclusion that your business problem runs 1000x faster because of differences in the runtime... I haven't come to any conclusion. There are a lot of differences between a JVM-powered business solution and a KDB-powered business solution, however one striking difference is the cache-effect. However the question remains: What exactly do we get by having a big runtime? That we get to write loops?

by cbsmith 10y ago

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.
- geocar 10y ago
  > The only taxi problem that comes to mind It's the problem that I linked to previously. http://tech.marksblogg.com/benchmarks.html http://tech.marksblogg.com/benchmarks.html Finding good benchmarks is hard: Business problems are a good one because these are the ways experts will solve problems using these tools, and we can discuss the choice of tooling, whether this is the right way to solve the problem, and even what the best tools for this problem is -- in this case, GPU beats CPU, but what's amazing is just how close a CPU-powered solution gets by turning it into a memory-streaming problem (which the GPU needs to do anyway). > If you came to the conclusion that your business problem runs 1000x faster because of differences in the runtime... I haven't come to any conclusion. There are a lot of differences between a JVM-powered business solution and a KDB-powered business solution, however one striking difference is the cache-effect. However the question remains: What exactly do we get by having a big runtime? That we get to write loops?