4 ms·

Huh? What? Several points: * Who said the 10MB is all used at once? * I don't know your hardware, but there is very, very good chance you are actually quite

by cbsmith 10y ago

Huh? What? Several points: * Who said the 10MB is all used at once? * I don't know your hardware, but there is very, very good chance you are actually quite wrong about <10MB of cache. These days, most magnetic disks have more cache than that, and if you are using SSD's, there's a boatload more cache than that in there. * 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). * 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... I'm not sure why you'd say it is too big. The article page is 1.4 MB alone... and it still needs to leverage a general purpose runtime/JIT that is orders of magnitude larger to do its single fixed purpose.

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.

by cbsmith 10y ago

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.