4 ms·

> the performance of Java has to be the best-kept secret in the industry Is it, though? It's the first language of choice for a large number, if not most perfo

by pron 5mo ago

> the performance of Java has to be the best-kept secret in the industry Is it, though? It's the first language of choice for a large number, if not most performance-critical applications. > Because you are the only person I've ever heard making such claims seriously. Your sources must be very limited, then, because in serious compiler and runtime design and memory management circles this is quite common. There is a debate, but it is an empirical one over whether the circumstances that favour Java over C++ are more or less common in practice or vice-versa. And again, given that it's the first language of choice in most performance-critical applications (and even if you don't believe it's number one, surely you agree it's in the top two or three) one or two more people probably think its performance is at least competitive with C++. > But in more traditional performance-critical work, such as HPC or video game engines, there are usually only a limited number of distinct combinations of performance-critical tasks that can be active at the same time I wouldn't say HPC and video game engines are "traditional performance critical work". Not because they're not performance critical, but because the range of performance critical programs is far larger - think bank card transaction processing; think mobile phone routing, and there are many more examples (also, AAA video game engines are indeed very traditional in their design and tech choices, but their performance-sensitivity these days is not so much around CPU-related optimisations but about scheduling the GPU, and their tech choices are much more constrained by the consoles they need to support than by performance).

jltsiren 5mo ago
It sounds like we are not even talking about the same thing when we talk about performance. HPC and video game engines are examples of traditional performance-critical work. Performance-critical, because they typically run in a resource-constrained environment. (If they don't, the user is likely to request the system to do more work.) And traditional, because it's more about algorithmic performance than system performance. The kind of performance people cared about long before computers became capable enough to run complex software systems. I would not consider card transaction processing performance-critical. The total number of transactions is very low relative to the amount of resources available to process them. As for Java, it stopped being a general-purpose language a long time ago. Most people who care about the performance of the software they write don't consider it, because almost nobody in their field uses it or talks about it. If it's actually a good choice for performance-sensitive applications in those fields, the people who are using it have done a good job keeping it secret.
- pron 5mo ago
  You're right, because I certainly don't consider resource-constrained programs to be the only performance-sensitive applications. I consider an application performance-sensitive when it has severe performance requirements (either on throughput or latency or both) that aren't easily or sufficiently met with horizontal scaling. This typically involves situations where high volumes of data must flow and be processed on the same machine (my own journey with Java began when we ported a large C++ application that did distributed, soft-realtime sensor fusion, synchronised with atomic clocks, to Java, and it was very much performance-sensitive). If you are running in a resource-constrained environment, you might have no choice but to have complete control over hardware resources, in which case you may need to use a low-level language, but your optimisation budget is very high. A different and more common case is where the hardware isn't too resource-constrained, but the performance requirements aren't easily met, either. In these situations, the performance challenge isn't necessarily to optimise at all costs, but to find a way to meet the performance requirement while staying within budget. In these areas, Java has already displaced C++, and continues to be the first language of choice. Of course, the people who write such applications (in any language) don't often talk about their architecture, but here's one example when they do: https://www.infoq.com/presentations/java-robot-swarms/ https://www.infoq.com/presentations/java-robot-swarms/ In this case, as in many others, the performance requirements are strict (and aren't easily met with horizontal scaling), but the constraint under which they must be met isn't the hardware but the budget and speed of development/evolution. More often, the performance challenge is how to get the best performance per unit of effort (while meeting the performance requirements, of course) rather than how to get the last 1-5% of performance at any cost. Or sometimes I put this question as not "how fast can a program be?" but "how fast can I practically make my program?" The optimisations Java offers are precisely intended to maximise the latter, because that's exactly where low-level languages suffer performance shortcomings. They could get that performance or perhaps better with a lot more effort (that needs to be continuously spent throughout the software's lifetime), but many performance-sensitive applications don't have or would rather not spend the time, money, or expertise to do that, and are looking for the best performance per unit of effort.
imtringued 5mo ago
>I wouldn't say HPC and video game engines are "traditional performance critical work". Not because they're not performance critical, but because the range of performance critical programs is far larger - think bank card transaction processing; think mobile phone routing, and there are many more examples (also, AAA video game engines are indeed very traditional in their design and tech choices, but their performance-sensitivity these days is not so much around CPU-related optimisations but about scheduling the GPU, and their tech choices are much more constrained by the consoles they need to support than by performance). In "business oriented" contexts, the usual culprits are database access and serialization/communication overheads. If you use Rust with serdes, you get access to one of the fastest ways to turn JSON documents into struct accessible data on the entire planet. The same implementation effort could be spent on any industry specific data formats. I am struggling to think of any scenarios where Rust is supposed to be uniquely unsuited and Java would have an obvious win to make the broad and sweeping statements you've made. If everything you said is true, people would be building JVM backends for C++/Rust the same way LLVM has been used as a backend and there would be constant discussions about JVM vs clang vs gcc. It just doesn't add up.
- pron 5mo ago
  > If you use Rust with serdes, you get access to one of the fastest ways to turn JSON documents into struct accessible data on the entire planet. Yeah, because most people who choose Rust are those coming from JS, Python, or Ruby, and almost no one has written large systems in Rust yet, I see why you'd think that, because that's indeed the main challenge in the kind of programs normally written in JS, Python, or Ruby. In automation control, the bottleneck isn't the DB; in distributed sensor fusion the bottleneck isn't the DB; in telecom routing the bottleneck isn't the DB (I actually don't know what the bottleneck is in transaction processing, but I'm pretty sure it's not just the DB). These are just some areas where Java is the top choice. > I am struggling to think of any scenarios where Rust is supposed to be uniquely unsuited and Java would have an obvious win to make the broad and sweeping statements you've made. In all the same places where Java displaced C++ and continues to do so: large systems. I think few even consider Rust, TBH. > If everything you said is true, people would be building JVM backends for C++/Rust the same way LLVM has been used as a backend and there would be constant discussions about JVM vs clang vs gcc. It just doesn't add up. First, Java is far more popular than C++ (let alone Rust), so there would be little point (although there is an LLVM backend for the JVM, though I doubt many people use it). The people who want Java's benefits over C++'s benefits have been using Java for a long time now. Second, you can't have a JVM backend for C++ and Rust and fully enjoy the performance benefits of Java, because the JVM's optimisations are enabled by the language not having the constraints that low-level languages have. The people who just need the performance choose Java anyway, and the people who choose low-level language choose them because they need the control the JVM doesn't offer.

by pron 5mo ago

jltsiren 5mo ago

It sounds like we are not even talking about the same thing when we talk about performance. HPC and video game engines are examples of traditional performance-critical work. Performance-critical, because they typically run in a resource-constrained environment. (If they don't, the user is likely to request the system to do more work.) And traditional, because it's more about algorithmic performance than system performance. The kind of performance people cared about long before computers became capable enough to run complex software systems. I would not consider card transaction processing performance-critical. The total number of transactions is very low relative to the amount of resources available to process them. As for Java, it stopped being a general-purpose language a long time ago. Most people who care about the performance of the software they write don't consider it, because almost nobody in their field uses it or talks about it. If it's actually a good choice for performance-sensitive applications in those fields, the people who are using it have done a good job keeping it secret.

pron 5mo ago
You're right, because I certainly don't consider resource-constrained programs to be the only performance-sensitive applications. I consider an application performance-sensitive when it has severe performance requirements (either on throughput or latency or both) that aren't easily or sufficiently met with horizontal scaling. This typically involves situations where high volumes of data must flow and be processed on the same machine (my own journey with Java began when we ported a large C++ application that did distributed, soft-realtime sensor fusion, synchronised with atomic clocks, to Java, and it was very much performance-sensitive). If you are running in a resource-constrained environment, you might have no choice but to have complete control over hardware resources, in which case you may need to use a low-level language, but your optimisation budget is very high. A different and more common case is where the hardware isn't too resource-constrained, but the performance requirements aren't easily met, either. In these situations, the performance challenge isn't necessarily to optimise at all costs, but to find a way to meet the performance requirement while staying within budget. In these areas, Java has already displaced C++, and continues to be the first language of choice. Of course, the people who write such applications (in any language) don't often talk about their architecture, but here's one example when they do: https://www.infoq.com/presentations/java-robot-swarms/ https://www.infoq.com/presentations/java-robot-swarms/ In this case, as in many others, the performance requirements are strict (and aren't easily met with horizontal scaling), but the constraint under which they must be met isn't the hardware but the budget and speed of development/evolution. More often, the performance challenge is how to get the best performance per unit of effort (while meeting the performance requirements, of course) rather than how to get the last 1-5% of performance at any cost. Or sometimes I put this question as not "how fast can a program be?" but "how fast can I practically make my program?" The optimisations Java offers are precisely intended to maximise the latter, because that's exactly where low-level languages suffer performance shortcomings. They could get that performance or perhaps better with a lot more effort (that needs to be continuously spent throughout the software's lifetime), but many performance-sensitive applications don't have or would rather not spend the time, money, or expertise to do that, and are looking for the best performance per unit of effort.

imtringued 5mo ago

>I wouldn't say HPC and video game engines are "traditional performance critical work". Not because they're not performance critical, but because the range of performance critical programs is far larger - think bank card transaction processing; think mobile phone routing, and there are many more examples (also, AAA video game engines are indeed very traditional in their design and tech choices, but their performance-sensitivity these days is not so much around CPU-related optimisations but about scheduling the GPU, and their tech choices are much more constrained by the consoles they need to support than by performance). In "business oriented" contexts, the usual culprits are database access and serialization/communication overheads. If you use Rust with serdes, you get access to one of the fastest ways to turn JSON documents into struct accessible data on the entire planet. The same implementation effort could be spent on any industry specific data formats. I am struggling to think of any scenarios where Rust is supposed to be uniquely unsuited and Java would have an obvious win to make the broad and sweeping statements you've made. If everything you said is true, people would be building JVM backends for C++/Rust the same way LLVM has been used as a backend and there would be constant discussions about JVM vs clang vs gcc. It just doesn't add up.

pron 5mo ago
> If you use Rust with serdes, you get access to one of the fastest ways to turn JSON documents into struct accessible data on the entire planet. Yeah, because most people who choose Rust are those coming from JS, Python, or Ruby, and almost no one has written large systems in Rust yet, I see why you'd think that, because that's indeed the main challenge in the kind of programs normally written in JS, Python, or Ruby. In automation control, the bottleneck isn't the DB; in distributed sensor fusion the bottleneck isn't the DB; in telecom routing the bottleneck isn't the DB (I actually don't know what the bottleneck is in transaction processing, but I'm pretty sure it's not just the DB). These are just some areas where Java is the top choice. > I am struggling to think of any scenarios where Rust is supposed to be uniquely unsuited and Java would have an obvious win to make the broad and sweeping statements you've made. In all the same places where Java displaced C++ and continues to do so: large systems. I think few even consider Rust, TBH. > If everything you said is true, people would be building JVM backends for C++/Rust the same way LLVM has been used as a backend and there would be constant discussions about JVM vs clang vs gcc. It just doesn't add up. First, Java is far more popular than C++ (let alone Rust), so there would be little point (although there is an LLVM backend for the JVM, though I doubt many people use it). The people who want Java's benefits over C++'s benefits have been using Java for a long time now. Second, you can't have a JVM backend for C++ and Rust and fully enjoy the performance benefits of Java, because the JVM's optimisations are enabled by the language not having the constraints that low-level languages have. The people who just need the performance choose Java anyway, and the people who choose low-level language choose them because they need the control the JVM doesn't offer.