| > Ah yes, the swapping induced by IntelliJ overflowing my system RAM is supposed to reduce the inefficiencies of using too little memory. Great... That's like me saying, oh great, so the swapping introduced by MS Word or Outlook shows just how efficient C++ is... > Thanks pron, you've fully bought into all the JVM kool-aid talking points without ever trying to question them. Oh I didn't just "buy" them. As a low-level programmer who's suffered for a long time from intrinsic inefficiencies and C++, I became a compiler and runtime engineer working on the JVM to solve the problems I had in C++. > This is the "wasted RAM is unused RAM" mentality and it doesn't work, because you usually have multiple competing programs and when you run out of RAM, your system will start swapping No, it's actually more involved and interesting than that, but you'll have to wait for my talk. > Ok, now you're just writing nonsense. Nowadays people have CPUs with multiple cores and use an OS with a scheduler. If you have two programs taking up 100% of the CPU, the OS will give each process some of the hardware resources. You can't just assume some 100% CPU blockage here just because it is convenient for your argument I didn't. I specifically said it was just an example to demonstrate the inter-relatedness of RAM and CPU since accessing RAM requires CPU. To understand why every single language that can isn't limited by other constraints and has the engineering resources to do so uses the same basic memory management algorithm as Java I guess you'll have to watch my talk when it's published. > Again, this is completely incorrect in so many ways that you're bragging you know nothing about how modern computers work. Wow. I guess it doesn't take much to be an engineer working on safety critical realtime applications and then on one of the worlds most advanced optimising compilers and you can get pretty far without knowing how computers work. > CPU cores have their own local memory resources called caches. Depending on how your code is written, you may tile your data so it fits entirely in cache and operate within the local memory. The data you need to access at any one time and the overall memory consumption of your program are two very different things. Maybe you don't know this, but CPU caches don't work by caching a large contiguous portion of the address space. > When performing inter thread communication, there are often situations where the data often doesn't even get written and then loaded to main memory, since atomic operations can make use of the MESI cache coherency protocol to pull the data directly from another cores' cache. I find it hilarious that you're trying to teach me about MESI, given that designing algorithms and data structures that are efficient on top of MESI was one of my jobs [1], and I advised Intel on architecture, but okay, maybe I know nothing about computers, as you concluded from a paragraph where I tried to give people who may not be compiler or memory management experts some intution about modern memory management design. FYI, modern malloc/free allocators are also intentionally less footprint-optimised than older ones to get better performance (although they can't offer all the optimisations of moving collectors because they're not allowed to move pointers), but maybe none of the people writing the compilers or memory management mechanisms you use know computers as much as you do, and you know all there is to know. [1]: I later even wrote, for a general audience, about data structures over distributed MESI (well, MOESI to be precise) protocols: https://highscalability.com/the-performance-of-distributed-d... |
The common discourse is that "XYZ language is close to the metal and therefore Blazing Fast (tm)" people become tribalistic and forgot that this there are engineering considerations and trade-offs all the way down. I appreciate you making the argument for the JVM delivering performant code when a budget matters.