5 ms·

I don't know. 10MB still sounds really too big. Why is it so big? What do we gain? I don't have a system with 10MB of cache, so I imagine Java can't run faste

by geocar 10y ago

I don't know. 10MB still sounds really too big. Why is it so big? What do we gain? I don't have a system with 10MB of cache, so I imagine Java can't run faster than memory...

guard-of-terra 10y ago
Locales? Timezones? Unicode? There's a lot of stuff that is there to be used from time to time, does not mean it hits your processor cache often. BTW, libruby-2.3 is 2,5M, just the shared object file, and it tries to use all aforementioned stuff from the underlying UNIX.
gregschlom 10y ago
10MB for a platform that allows you to run code on all three major operating systems without too much trouble and in a performant way is a huge win, in my opinion. Not many alternatives come close to that.
- pjmlp 10y ago
  Actually all languages with a rich runtime and standard library that isn't just a thin POSIX layer like C or C++ (although C++ has been improving their library story). Still your point holds.
- geocar 10y ago
  Q/KDB is 600kb, also runs code on all three major operating systems (and a few minor ones). It's also about 1000x faster than Java/Spark[1]. 1000x slower doesn't sound like a huge win to me; it sounds like a huge cost, so my question is what do we gain by making our programs 1000x slower? [1]: http://tech.marksblogg.com/benchmarks.html http://tech.marksblogg.com/benchmarks.html
  - adrianN 10y ago
    That benchmark is literally comparing Apples to Oranges. It's not even the same hardware.
taneq 10y ago
You don't need the entire executable file in cache in order to run the program. For comparison, a C++ wxWidgets 3.0 application isn't going to be much smaller than 10MB in release mode if you statically link it. Much as I hate to admit it, 10MB just isn't that big in an age of terabyte SSDs and systems with 32GB of RAM.
- nv-vn 10y ago
  Not that the majority of users have that. Even eschewing those outside of wealthy countries, most users are on mobile devices (laptops, tablets, cell phones). Of those who have desktop PCs, very few have terabyte SSDs and even fewer have 32gb of RAM. For most people, RAM is probably somewhere between 4-8GB.
  - krallja 10y ago
    10MB fits comfortably within 4GB of RAM.
    - geocar 10y ago
      I don't think it's healthy to think of that 4GB module as "RAM". It's connected to your CPU by a serial communications interface so access is not uniform or timely, and if the CPU needs any of it, it stops what it's doing while it waits. The "cache ram" (L1 and to a lesser extent L2) actually acts like the RAM that we learn about in Knuth, so that when we discuss algorithms in terms of memory/time costs, this is the number we should be thinking about. Algorithms that are performant on disk/drum are modern solutions for what you're calling "RAM".
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
hota_mazi 10y ago
> I don't know. 10MB still sounds really too big. Can't tell if sarcastic or... o_O. In the unlikely case you're actually serious, you really need to rethink your perception of memory costs in 2017.
- geocar 10y ago
  No, I'm really quite serious. KDB[1] is about 1000x faster than Spark[2], and is only about 600kb (and most of that is shared library dynamic linker stuff that makes interfacing with the rest of the OS easier). A big part of why it's fast is because it's small -- once you're inside cache memory everything gets faster. That's the real cost of memory in 2017. So what did we gain for paying it? [1]: https://news.ycombinator.com/item?id=13481824 https://news.ycombinator.com/item?id=13481824 [2]: http://tech.marksblogg.com/billion-nyc-taxi-rides-spark-2-1-0-emr.html http://tech.marksblogg.com/billion-nyc-taxi-rides-spark-2-1-...
  - ipsi 10y ago
    You're comparing completely, utterly different results here, and it's really hurting any point you're trying to make. You're comparing KDB running on 4x Intel Xeon Phi 7210 CPUs, totaling 256 physical CPUs. Compared to the best result for Java/Spark, which was running on 11x m3.xlarge instances on AWS. That's only 44 CPUs, plus it's running on AWS, not 100% dedicated hardware, so it's tough to tell what sort of an impact the virtualization + EBS has on performance. Plus, from the AWS page: "Each vCPU is a hyperthread of an Intel Xeon core except for T2 and m3.medium", which does not do anything good for the results. Yes, technically, KDB was 199.80x faster (not 1000!) than Java/Spark, when it was given vastly superior, dedicated hardware without virtualization, and when tackling a problem that the hardware setup is optimized for. Note that the author calls this out by saying "This isn't dissimilar to using graphics cards" when talking about the setup he was using for the KDB benchmarks. To get a sensible idea of the relative difference in performance, you would have to compare KDB and Java/Spark both running on the Xeon Phis, and/or running both on 11x m3.xlarge AWS instances - and even then, if Java/Spark does poorly on the Xeon Phi test, that might just mean that the Java/Spark developers haven't optimized for that particular setup.

by geocar 10y ago

I don't know. 10MB still sounds really too big. Why is it so big? What do we gain? I don't have a system with 10MB of cache, so I imagine Java can't run faster than memory...

guard-of-terra 10y ago

Locales? Timezones? Unicode? There's a lot of stuff that is there to be used from time to time, does not mean it hits your processor cache often. BTW, libruby-2.3 is 2,5M, just the shared object file, and it tries to use all aforementioned stuff from the underlying UNIX.

gregschlom 10y ago

10MB for a platform that allows you to run code on all three major operating systems without too much trouble and in a performant way is a huge win, in my opinion. Not many alternatives come close to that.

pjmlp 10y ago
Actually all languages with a rich runtime and standard library that isn't just a thin POSIX layer like C or C++ (although C++ has been improving their library story). Still your point holds.
geocar 10y ago
Q/KDB is 600kb, also runs code on all three major operating systems (and a few minor ones). It's also about 1000x faster than Java/Spark[1]. 1000x slower doesn't sound like a huge win to me; it sounds like a huge cost, so my question is what do we gain by making our programs 1000x slower? [1]: http://tech.marksblogg.com/benchmarks.html http://tech.marksblogg.com/benchmarks.html
- adrianN 10y ago
  That benchmark is literally comparing Apples to Oranges. It's not even the same hardware.

taneq 10y ago

You don't need the entire executable file in cache in order to run the program. For comparison, a C++ wxWidgets 3.0 application isn't going to be much smaller than 10MB in release mode if you statically link it. Much as I hate to admit it, 10MB just isn't that big in an age of terabyte SSDs and systems with 32GB of RAM.

nv-vn 10y ago
Not that the majority of users have that. Even eschewing those outside of wealthy countries, most users are on mobile devices (laptops, tablets, cell phones). Of those who have desktop PCs, very few have terabyte SSDs and even fewer have 32gb of RAM. For most people, RAM is probably somewhere between 4-8GB.
- krallja 10y ago
  10MB fits comfortably within 4GB of RAM.
  - geocar 10y ago
    I don't think it's healthy to think of that 4GB module as "RAM". It's connected to your CPU by a serial communications interface so access is not uniform or timely, and if the CPU needs any of it, it stops what it's doing while it waits. The "cache ram" (L1 and to a lesser extent L2) actually acts like the RAM that we learn about in Knuth, so that when we discuss algorithms in terms of memory/time costs, this is the number we should be thinking about. Algorithms that are performant on disk/drum are modern solutions for what you're calling "RAM".

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

hota_mazi 10y ago

> I don't know. 10MB still sounds really too big. Can't tell if sarcastic or... o_O. In the unlikely case you're actually serious, you really need to rethink your perception of memory costs in 2017.

geocar 10y ago
No, I'm really quite serious. KDB[1] is about 1000x faster than Spark[2], and is only about 600kb (and most of that is shared library dynamic linker stuff that makes interfacing with the rest of the OS easier). A big part of why it's fast is because it's small -- once you're inside cache memory everything gets faster. That's the real cost of memory in 2017. So what did we gain for paying it? [1]: https://news.ycombinator.com/item?id=13481824 https://news.ycombinator.com/item?id=13481824 [2]: http://tech.marksblogg.com/billion-nyc-taxi-rides-spark-2-1-0-emr.html http://tech.marksblogg.com/billion-nyc-taxi-rides-spark-2-1-...
- ipsi 10y ago
  You're comparing completely, utterly different results here, and it's really hurting any point you're trying to make. You're comparing KDB running on 4x Intel Xeon Phi 7210 CPUs, totaling 256 physical CPUs. Compared to the best result for Java/Spark, which was running on 11x m3.xlarge instances on AWS. That's only 44 CPUs, plus it's running on AWS, not 100% dedicated hardware, so it's tough to tell what sort of an impact the virtualization + EBS has on performance. Plus, from the AWS page: "Each vCPU is a hyperthread of an Intel Xeon core except for T2 and m3.medium", which does not do anything good for the results. Yes, technically, KDB was 199.80x faster (not 1000!) than Java/Spark, when it was given vastly superior, dedicated hardware without virtualization, and when tackling a problem that the hardware setup is optimized for. Note that the author calls this out by saying "This isn't dissimilar to using graphics cards" when talking about the setup he was using for the KDB benchmarks. To get a sensible idea of the relative difference in performance, you would have to compare KDB and Java/Spark both running on the Xeon Phis, and/or running both on 11x m3.xlarge AWS instances - and even then, if Java/Spark does poorly on the Xeon Phi test, that might just mean that the Java/Spark developers haven't optimized for that particular setup.