6 ms·

> Who said the 10MB is all used at once? The parent was suggesting that this was all that was actually needed out of the 100mb or so downloadable. If you think

by geocar 10y ago

> Who said the 10MB is all used at once? The parent was suggesting that this was all that was actually needed out of the 100mb or so downloadable. If you think the JVM is smaller, how small is it exactly? > If you were referring strictly to CPU cache, then I'm even more confused, because the entire existence of that stuff is predicated on it being faster than memory, so... (and even still, if your total CPU cache isn't 10MB, it likely isn't that much smaller). http://www.intel.co.uk/content/www/uk/en/processors/core/core-i7-processor.html http://www.intel.co.uk/content/www/uk/en/processors/core/cor... I don't have anything with 10MB cache. > It's not like the whole package would sit in RAM the whole time anyway. By your same assertion, I could say that one of my CPU registers is only 64-bits wide, so I imagine all programs larger than 64-bits can't run faster than L3 cache... If you get into L1, you get about 1000x faster. http://tech.marksblogg.com/benchmarks.html http://tech.marksblogg.com/benchmarks.html > I'm not sure why you'd say it is too big. Maybe I have a different perspective? If a 600kb runtime is 1000x faster, I want to know what I get by being 10x bigger. I'm quite surprised that there are so many responders defending it given that these benchmarks were just on Hacker News a few days ago.

adrianN 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. 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.
- 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...
cbsmith 10y ago
> I don't have anything with 10MB cache. The link you provided was to three distinct models of i7 processors... all with 8MB of L3 cache. I would argue that 8MB isn't much smaller than 10MB, but I will understand if you disagree. However, even the slowest of those processors also has 1MB of L2 cache and 256KB of L1 cache, not to mention other "cache-like" memory in the form of renamed registers, completion queues, etc. At most, we're talking <800KB shy of 10MB in cache. > If you get into L1, you get about 1000x faster. I think you are making my point for me. > Maybe I have a different perspective? If a 600kb runtime is 1000x faster, I want to know what I get by being 10x bigger. You are assuming that at all times all of that 10MB must be touched by the processor at once. You can have a 10MB runtime where most of the cycles are being spent on a hotspot <4KB of data.... Having a hot spot that is orders of magnitude smaller than the full runtime is totally unsurprising. It's particularly true when your runtime has a JIT in it. With a JIT, most of the time, the bytes that are being executed aren't part of that 10MB, but rather are generated by it. Are you going to penalize your 600KB runtime for the size of the source code? ;-)

by geocar 10y ago

adrianN 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. 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.

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...

cbsmith 10y ago

> I don't have anything with 10MB cache. The link you provided was to three distinct models of i7 processors... all with 8MB of L3 cache. I would argue that 8MB isn't much smaller than 10MB, but I will understand if you disagree. However, even the slowest of those processors also has 1MB of L2 cache and 256KB of L1 cache, not to mention other "cache-like" memory in the form of renamed registers, completion queues, etc. At most, we're talking <800KB shy of 10MB in cache. > If you get into L1, you get about 1000x faster. I think you are making my point for me. > Maybe I have a different perspective? If a 600kb runtime is 1000x faster, I want to know what I get by being 10x bigger. You are assuming that at all times all of that 10MB must be touched by the processor at once. You can have a 10MB runtime where most of the cycles are being spent on a hotspot <4KB of data.... Having a hot spot that is orders of magnitude smaller than the full runtime is totally unsurprising. It's particularly true when your runtime has a JIT in it. With a JIT, most of the time, the bytes that are being executed aren't part of that 10MB, but rather are generated by it. Are you going to penalize your 600KB runtime for the size of the source code? ;-)