111–120 of 159 posts
Ideally you'd want to go further and actually store the is_alive as a bit mask and use SIMD instructions to filter out zeroes for example.
Anyways find it odd that major languages don’t have a built in way of asking for an array of objects to be optimized as SoA or AoS
It doesn't quite make sense to keep object identity at the language level. Inherently the data in the arrays cannot be the same memory of the data in the objects fields. To get the speed up, you can't just abstract it as an access pattern because it's tied to the specific way the memory is laid out. If you were trying to make some kind of collection type that could be queried by both row and column, you would need to…
I'm curious if anyone has had to write a JNI extension for a hot (CPU, GPU, RAM) section the JVM was unable to effectively JIT and/or optimize enough.
I'm curious if anyone has had to write a JNI extension for a hot (CPU, GPU, RAM) section the JVM was unable to effectively JIT and/or optimize enough.
I think that's generally a pessimization because JNI has fairly high overhead.
Earlier quoted context omitted.
This has absolutely nothing to do with what I said. I wasn't referring to people who think that program performance doesn't matter (although I'm sure there are many of those) but to people working on code that either doesn't impact the overall program's performance much or it does but not due to layout. The number of developers working on code where layout is a major contributor to performance is relatively low, and…
> but to people working on code that either doesn't impact the overall program's performance much or it does but not due to layout And that's the problem. Who decides that? How do you know and that's my problem with it. Things always change. It's always temporary, not in the hot path, doesn't matter etc until it does. So what is considered "doesn't impact" often comes back to bite.
Earlier quoted context omitted.
I’ve done performance-engineering for decades in Java, C++, and C for both data analytics and supercomputing/HPC. Java performs significantly worse than C++ in all cases without exception. This is the result you should expect from first principles; something has gone horribly wrong with your software optimization if Java is faster than C++ or even Rust. There are good reasons to use Java in environments that care abo…
> I’ve done performance-engineering for decades in Java, C++, and C for both data analytics and supercomputing/HPC. Java performs significantly worse than C++ in all cases without exception. I've done similar work (not supercomputing/HPC, but yes for soft and hard realtime software, including safety-critical software) and I couldn't disagree more. Of course, we didn't get to write every program in both Java and C++,…
But this looks more like an apples-to-oranges comparison. You might be talking more about performance in complex business logic, while others are talking about performance in computation.
I can imagine that Java could be faster than C++ or Rust (for the same effort) when the number distinct active tasks is large. 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. Even if the codebase itself is huge, the performance-critical subset is simple, and the performance advantages from increased control over the execution are cheap.
That’s a great read. I wish more people wrote like that.
Earlier quoted context omitted.
How do you deal with all the daemons and automatic crap that does this on Mac? Isnt it all reinforced by SIP?
I think all operating systems have these. In this one case, allocating a MapView via storyboard, caused some kind of cascading strong reference stuff. Simply allocating it programmatically, fixed it. Took awhile to get there, though.
Earlier quoted context omitted.
> I’ve done performance-engineering for decades in Java, C++, and C for both data analytics and supercomputing/HPC. Java performs significantly worse than C++ in all cases without exception. I've done similar work (not supercomputing/HPC, but yes for soft and hard realtime software, including safety-critical software) and I couldn't disagree more. Of course, we didn't get to write every program in both Java and C++,…
If what you are saying is correct, the performance of Java has to be the best-kept secret in the industry. Because you are the only person I've ever heard making such claims seriously. But this looks more like an apples-to-oranges comparison. You might be talking more about performance in complex business logic, while others are talking about performance in computation. I can imagine that Java could be faster than C+…
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).
Earlier quoted context omitted.
If what you are saying is correct, the performance of Java has to be the best-kept secret in the industry. Because you are the only person I've ever heard making such claims seriously. But this looks more like an apples-to-oranges comparison. You might be talking more about performance in complex business logic, while others are talking about performance in computation. I can imagine that Java could be faster than C+…
> 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…
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.