4 ms·

All of that configuration and it will always be less efficient than Rust, or even Golang. This is why lots of engineers waste time fiddling with options to tun

by rvz 7mo ago

All of that configuration and it will always be less efficient than Rust, or even Golang. This is why lots of engineers waste time fiddling with options to tune the JVM and still require hundreds of replicated micro-services to "scale" their backends and losing money on AWS and when they will never admit the issue is the technology they have chosen (Java) and why AWS loves their customers using inefficient and expensive technologies. Even after that, both Go and Rust continue to run rings around the JVM no matter the combination of options.

cleverfoo 7mo ago
Sure, for a very narrow definition of _efficiency_. There's plenty to complain in terms of the JVM and Java but performance, as in units of work per dollar spent, is not one of them - JITs just have too many opportunities for optimizing generated code.
deepsun 7mo ago
All of that tooling and Rust will always be less efficient than Assembler.
- metaltyphoon 7mo ago
  I… didn’t think this makes sense :)
  - msla 7mo ago
    It makes perfect sense: Rust compilers will never beat a human at scheduling every single opcode perfectly based on the deepest microarchitectural analysis short of decapping the chip and breaking out the ol' electron microscope. Whether it's worthwhile to be that efficient over a whole program, as opposed to a preternaturally tight compute kernel, is definitely questionable.
    - metaltyphoon 7mo ago
      > scheduling every single opcode perfectly based on the deepest microarchitectural Is that even possible knowing OOE+ branch execution and many other CPU tricks?
  - pjmlp 7mo ago
    Yes it does, that is why most serious games used to be written in Assembly, until BASIC, Pascal, C and C++ compilers got enough language extensions and compiler knobs to not having to do that all the time, and yet some Assembly is still required.
fHr 7mo ago
I was a diehard java fanboy but using Rust in the last 5 years more and more I have to agree, but sadly huge Java corporate codebases keep my bills paid still, so I have to deal with it. It is what it is. Also agree the pipeline etc. they love all the waste of the compute in their pocket.
- contraposit 7mo ago
  I hope AI will make automated translation of such legacy codebases into any favourite langauge possible in future. Fingers crossed.
- newsoftheday 7mo ago
  It sounds like you're not into Java. Perhaps consider switching languages to make room for people who are.
- deepsun 7mo ago
  I code on both and they are just for different purposes. E.g. I think it's madness to develop desktop apps in Rust. Development velocity is way greater in Java.
- pjmlp 7mo ago
  You mean like the waste of the compute in Rust compiler when compiling from source all the time, with the lenghty compilation times it has, multipled by every Rust user when starting a new project?
arein3 7mo ago
Yeah doubt that Recently I had a python friend use the most balls to the wall python backend, he couldnt beleive java was faster, but the numbers werent lying. We did 1 billion iterations of adding a float, took a few seconds in java.
well_ackshually 7mo ago
That's a nice source, from where up your ass did you find it ? Go's GC is absolutely awful and leads to nondeterministic pauses and catastrophic latency spikes, especially when the memory pressure and capacity is high. Throw the go GC against a 256GB heap, see how well it survives. Technologies have strong and weak points. Go's strong points are small, targeted pieces of software and having 66% of a binary basically be if err != nil return err. Rust's strong points are that you get to have the symbol<():soup<_, |_| of { c++ }>> while not saying you're writing c++ and feeling really smug when you say that you only needed to use 5 Arc<Mutex<T>> and rewrote your entire software three times but at least it runs almost as fast as some shitty C that does fgets() in the middle of a hot loop. Java lets you spawn spring boot and instantiate a string through reflection because why not. I promise you, I can write allocation heavy FizzBuzzEnterpriseFactoryFactories in Rust too.
jim33442 7mo ago
I still don't get why Java is the only language that needs the heap to be carefully tuned. Like it hogs some memory at start, crashes if you go above a certain amount, and doesn't return memory to the OS when GC'd. Even Python and JS don't have those problems.
- cogman10 7mo ago
  > I still don't get why Java is the only language that needs the heap to be carefully tuned. Only tuning you should be doing is setting the heap size and algorithm (Though, size is likely enough). > Like it hogs some memory at start, crashes if you go above a certain amount, and doesn't return memory to the OS when GC'd. Even Python and JS don't have those problems. Unlike Python and I believe most javascript engines, the JVM uses moving garbage collectors. That's the primary reason why it hogs memory. In these ready to return to OS languages, when something is freed or allocated they are literally calling "malloc" and "free" directly. That's why stuff tends to return back to the OS faster. The JVM doesn't do that. When a GC runs in the JVM, the JVM picks up and moves live data to a new location. That means the JVM needs a minimum amount of free space to operate. The benefit of this is the JVM can allocate really fast, it's just a single pointer bump and a check to ensure there's enough space. It's pretty close to the same performance as the stack is in C++. And if there's a lot of data that lives for a short period of time, the JVM frees that data very fast as well. There is little accounting that the JVM has to do to free stuff up because it's simply moving the live data. For even the fastest allocators that python/javascript engines use, this isn't true. They have to keep track of the various allocation locations and the gaps in allocation when something is freed. And a request for allocation needs to ultimately find a location in the heap with enough room. Java does have a memory issue, though, all objects in java are pretty bulky. This will hopefully be fixed in future versions when "value" types are added.
  - jim33442 7mo ago
    Thanks, that's a really good explanation. And makes sense, especially since Java objects are all constantly getting allocated/freed on the (virtual) heap rather than stack.

by rvz 7mo ago

cleverfoo 7mo ago

Sure, for a very narrow definition of _efficiency_. There's plenty to complain in terms of the JVM and Java but performance, as in units of work per dollar spent, is not one of them - JITs just have too many opportunities for optimizing generated code.

deepsun 7mo ago

All of that tooling and Rust will always be less efficient than Assembler.

metaltyphoon 7mo ago
I… didn’t think this makes sense :)
- msla 7mo ago
  It makes perfect sense: Rust compilers will never beat a human at scheduling every single opcode perfectly based on the deepest microarchitectural analysis short of decapping the chip and breaking out the ol' electron microscope. Whether it's worthwhile to be that efficient over a whole program, as opposed to a preternaturally tight compute kernel, is definitely questionable.
  - metaltyphoon 7mo ago
    > scheduling every single opcode perfectly based on the deepest microarchitectural Is that even possible knowing OOE+ branch execution and many other CPU tricks?
- pjmlp 7mo ago
  Yes it does, that is why most serious games used to be written in Assembly, until BASIC, Pascal, C and C++ compilers got enough language extensions and compiler knobs to not having to do that all the time, and yet some Assembly is still required.

fHr 7mo ago

I was a diehard java fanboy but using Rust in the last 5 years more and more I have to agree, but sadly huge Java corporate codebases keep my bills paid still, so I have to deal with it. It is what it is. Also agree the pipeline etc. they love all the waste of the compute in their pocket.

contraposit 7mo ago
I hope AI will make automated translation of such legacy codebases into any favourite langauge possible in future. Fingers crossed.
newsoftheday 7mo ago
It sounds like you're not into Java. Perhaps consider switching languages to make room for people who are.
deepsun 7mo ago
I code on both and they are just for different purposes. E.g. I think it's madness to develop desktop apps in Rust. Development velocity is way greater in Java.
pjmlp 7mo ago
You mean like the waste of the compute in Rust compiler when compiling from source all the time, with the lenghty compilation times it has, multipled by every Rust user when starting a new project?

arein3 7mo ago

Yeah doubt that Recently I had a python friend use the most balls to the wall python backend, he couldnt beleive java was faster, but the numbers werent lying. We did 1 billion iterations of adding a float, took a few seconds in java.

well_ackshually 7mo ago

That's a nice source, from where up your ass did you find it ? Go's GC is absolutely awful and leads to nondeterministic pauses and catastrophic latency spikes, especially when the memory pressure and capacity is high. Throw the go GC against a 256GB heap, see how well it survives. Technologies have strong and weak points. Go's strong points are small, targeted pieces of software and having 66% of a binary basically be if err != nil return err. Rust's strong points are that you get to have the symbol<():soup<_, |_| of { c++ }>> while not saying you're writing c++ and feeling really smug when you say that you only needed to use 5 Arc<Mutex<T>> and rewrote your entire software three times but at least it runs almost as fast as some shitty C that does fgets() in the middle of a hot loop. Java lets you spawn spring boot and instantiate a string through reflection because why not. I promise you, I can write allocation heavy FizzBuzzEnterpriseFactoryFactories in Rust too.

jim33442 7mo ago

I still don't get why Java is the only language that needs the heap to be carefully tuned. Like it hogs some memory at start, crashes if you go above a certain amount, and doesn't return memory to the OS when GC'd. Even Python and JS don't have those problems.

cogman10 7mo ago
> I still don't get why Java is the only language that needs the heap to be carefully tuned. Only tuning you should be doing is setting the heap size and algorithm (Though, size is likely enough). > Like it hogs some memory at start, crashes if you go above a certain amount, and doesn't return memory to the OS when GC'd. Even Python and JS don't have those problems. Unlike Python and I believe most javascript engines, the JVM uses moving garbage collectors. That's the primary reason why it hogs memory. In these ready to return to OS languages, when something is freed or allocated they are literally calling "malloc" and "free" directly. That's why stuff tends to return back to the OS faster. The JVM doesn't do that. When a GC runs in the JVM, the JVM picks up and moves live data to a new location. That means the JVM needs a minimum amount of free space to operate. The benefit of this is the JVM can allocate really fast, it's just a single pointer bump and a check to ensure there's enough space. It's pretty close to the same performance as the stack is in C++. And if there's a lot of data that lives for a short period of time, the JVM frees that data very fast as well. There is little accounting that the JVM has to do to free stuff up because it's simply moving the live data. For even the fastest allocators that python/javascript engines use, this isn't true. They have to keep track of the various allocation locations and the gaps in allocation when something is freed. And a request for allocation needs to ultimately find a location in the heap with enough room. Java does have a memory issue, though, all objects in java are pretty bulky. This will hopefully be fixed in future versions when "value" types are added.
- jim33442 7mo ago
  Thanks, that's a really good explanation. And makes sense, especially since Java objects are all constantly getting allocated/freed on the (virtual) heap rather than stack.