28 ms·
This is so untrue I still don't know how anyone can even claim this. When I run tests in Rust, the biggest portion of the time is spent compiling the test (lets
by imtringued 5d ago
This is so untrue I still don't know how anyone can even claim this. When I run tests in Rust, the biggest portion of the time is spent compiling the test (lets say 3-4 seconds), then the tests conclude practically instantly, in less than half a second.
Meanwhile when I run tests on my JVM projects it can take 30 seconds just to start and the test execution is extremely slow too.
Even if you do manage to match the performance after warmup, you still have the issue that keeping the class files in RAM plus the JIT compilation state will cost more memory than simply running AOT compiled code. You simply cannot write processes that use a single digit MiB amount of memory on a JVM and getting down to 2 digits is theoretically possible but requires significant effort.
Once you get into the micro optimizations like the lack of mutable aliasing in Rust, there is significantly more potential for auto vectorization.
What you mean by "real world systems" is probably defined in such a narrow way that all the weaknesses of Java programs don't count anymore.
- xienze 5d ago> This is so untrue I still don't know how anyone can even claim this. Because it's referring to long running processes, AKA the kind of things where hot paths can be JITted into faster native code than is possible from static compilation because the JIT has information about the real-world usage patterns. > Meanwhile when I run tests on my JVM projects it can take 30 seconds just to start That strongly implies you're using some sort of framework that's doing a _lot_ of initialization. That's not JVM startup time, don't be intellectually dishonest here. > You simply cannot write processes that use a single digit MiB amount of memory on a JVM and getting down to 2 digits is theoretically possible but requires significant effort. Again, the main use case for Java is long running server processes. No one cares if the binary is 1, 10, or 100MB or if it consumes 2, 3, or 4x the memory as long as the throughput is there. And Java has a long track record of delivering very good performance in those contexts, coupled with an extremely rich and mature library/tooling ecosystem.
- captainbland 5d ago> or if it consumes 2, 3, or 4x the memory I think this used to be true more than it is now. Memory has been relatively expensive in cloud environments for a while (often 2x the price of an ec2 node for an equivalent with 2x RAM) and DRAM shortages aren't helping.
- xienze 5d agoYeah it's more of a concern but not "rewrite a ten year old application in Rust to save on the cost of several gigabytes of RAM" bad.
- captainbland 5d agoFor the most part yeah but does depend on scale. For Java there are lower cost migration pathways like native compilation anyway if that does become your concern
- za3faran 5d agoCPU is still more expensive than memory. Trading more memory to save CPU (and reduce the # of nodes required to run your service) can still hold.
- LtWorf 5d agoThey only consider programs that run for several hours. For short programs C is unbeatable.
- KaiserPro 5d ago> In real world systems A poet can beauty in any language.
- za3faran 5d agoIt's not untrue, there are people who have observed this, and for a long time now. AOT compilers assume a closed world system, whereas JIT are able to perform runtime optimizations that AOT can't. By real world systems, I mean long running real server-side systems that run things that you use day to day by large corporations serving millions of users. Are you able to share some of the tests you are running, and which frameworks are you using? Now with project leyden and similar efforts, start up time has been cut drastically.