5 ms·

Avoiding allocations is the key part: "...we avoid all the garbage". I found the same is true when trying to write high performance Java UI code for Android. If

by sxp 6y ago

Avoiding allocations is the key part: "...we avoid all the garbage". I found the same is true when trying to write high performance Java UI code for Android. If you have to do something complex each frame, make sure to pre allocate or pool your objects. If the hot parts of the code are written in a C-like style, then the JIT and other optimizations can give you C-like performance. You'll still need to write C code if you want vector operations or other processor-specific functionality, but writing in C-like Java can give you C performance while still letting you interact with Java libraries & APIs.

FpUser 6y ago
>"but writing in C-like Java can give you C performance while still letting you interact with Java libraries & APIs." Assuming those libraries do not do allocations of their own negating all the efforts.
- coliveira 6y ago
  I imagine that the other libraries would be used only on the non-critical parts of the application.
- hawk_ 6y ago
  That's right. Java libraries even within JDK are notorious for unnecessary allocations and locks (which also do allocations for queues) putting GC pressure. C-like java means the need to roll out your own or using libraries like Chronicle.
Cojen 6y ago
I've found that coding in a "C-like style" offers great performance too. Are there any languages that target the JVM and are designed for higher speed? If it enforced the "C-like style" at the language level, perhaps it would be easier to follow? Of course at this point the usual answer is just use Rust, but is there a language that meets in the middle? Sometimes I just want the GC to do the work and I'm okay with that.
- m_mueller 6y ago
  I find Java itself works quite well for this. Especially newer Java versions with functional interfaces. You keep your data in data centric classes (e.g. something akin to struct-of-arrays in C) and have some functional interfaces to access this data, the only place where you loop over it, maybe in batches if it's really large (test it though, up to 10s or 100s of millions of elements is still fast to loop through in memory). Then you got some algorithm centric classes that you can plug into these interfaces. And finally, after reducing the data you may have some classic objects, e.g. to represent results. edit, to give you an example. Let's say you have double precision X/Y coordinates. Put that into a class with two double arrays for X and Y. In order to e.g. run an Euclidean distance computation against it, provide a (double, double) -> double interface against it. Then you have either an Euclidean distance class providing that function or just an inline lambda that you can plug into that interface, giving you a distance array. Let's now say you just want to have a list of 10 closes points - instead of sorting you're fastest to brute force it. Only after you reduced it down to the 10 points, you put them into Point objects because there's probably a consumer expecting it that way.
  - deleted 6y ago
    [deleted]
- jjav 6y ago
  > Are there any languages that target the JVM and are designed for higher speed? Yes: Java Performant Java looks mostly like C, just with no manual malloc() calls. Sure you could write Java in a J2EE way but.. that not a good choice.
  - killtimeatwork 6y ago
    In Java, every object stored on heap (and they can't be stored on stack) has a JVM-induced space overhead. Also, the allocator is free to spread the objects across the heap in a chaotic manner, which will make for less than optimal utilization of cache lines.
    - 6y ago
loopz 6y ago
This is Go and sync.Pool, essentially. He may have better luck finding good Gophers.
marta_morena_28 6y ago
> "but writing in C-like Java can give you C performance while still letting you interact with Java libraries & APIs." It really can't. Quite the opposite. Writing C-like Java is already doomed from the start. Java is faster than C when it comes to OOP. Unless you product is a highly complex OOP nightmare, C will always beat Java to the curb. GC is not free. The problem with GC is that you pay asynchronously, while allocations are essentially free. But this asynchronous cost is very very hard to measure and to control. Java does not offer the mechanism C/C++ offer for native resource management. It also doesn't do complex optimizations, most notably vectorization. Number crunching performance will always suck in Java. Even if they add all the optimizations in the world, the simple fact remains: Java as a language simply does not allow you to express code in a performant way. That leave the compiler at a double disadvantage. It needs to essentially "convert Java to C++ and guess the most performant interpretation" (we are decades away from this), and it needs to do that within milliseconds (because its a JIT). It just makes no sense to talk about this. Use Java for the 99% of your product that is not a hotpath, use C for the remaining 1% where you need pure performance. Simple as that.

by sxp 6y ago

FpUser 6y ago

>"but writing in C-like Java can give you C performance while still letting you interact with Java libraries & APIs." Assuming those libraries do not do allocations of their own negating all the efforts.

coliveira 6y ago
I imagine that the other libraries would be used only on the non-critical parts of the application.
hawk_ 6y ago
That's right. Java libraries even within JDK are notorious for unnecessary allocations and locks (which also do allocations for queues) putting GC pressure. C-like java means the need to roll out your own or using libraries like Chronicle.

Cojen 6y ago

I've found that coding in a "C-like style" offers great performance too. Are there any languages that target the JVM and are designed for higher speed? If it enforced the "C-like style" at the language level, perhaps it would be easier to follow? Of course at this point the usual answer is just use Rust, but is there a language that meets in the middle? Sometimes I just want the GC to do the work and I'm okay with that.

m_mueller 6y ago
I find Java itself works quite well for this. Especially newer Java versions with functional interfaces. You keep your data in data centric classes (e.g. something akin to struct-of-arrays in C) and have some functional interfaces to access this data, the only place where you loop over it, maybe in batches if it's really large (test it though, up to 10s or 100s of millions of elements is still fast to loop through in memory). Then you got some algorithm centric classes that you can plug into these interfaces. And finally, after reducing the data you may have some classic objects, e.g. to represent results. edit, to give you an example. Let's say you have double precision X/Y coordinates. Put that into a class with two double arrays for X and Y. In order to e.g. run an Euclidean distance computation against it, provide a (double, double) -> double interface against it. Then you have either an Euclidean distance class providing that function or just an inline lambda that you can plug into that interface, giving you a distance array. Let's now say you just want to have a list of 10 closes points - instead of sorting you're fastest to brute force it. Only after you reduced it down to the 10 points, you put them into Point objects because there's probably a consumer expecting it that way.
- deleted 6y ago
  [deleted]
jjav 6y ago
> Are there any languages that target the JVM and are designed for higher speed? Yes: Java Performant Java looks mostly like C, just with no manual malloc() calls. Sure you could write Java in a J2EE way but.. that not a good choice.
- killtimeatwork 6y ago
  In Java, every object stored on heap (and they can't be stored on stack) has a JVM-induced space overhead. Also, the allocator is free to spread the objects across the heap in a chaotic manner, which will make for less than optimal utilization of cache lines.
  - 6y ago

loopz 6y ago

This is Go and sync.Pool, essentially. He may have better luck finding good Gophers.

marta_morena_28 6y ago

> "but writing in C-like Java can give you C performance while still letting you interact with Java libraries & APIs." It really can't. Quite the opposite. Writing C-like Java is already doomed from the start. Java is faster than C when it comes to OOP. Unless you product is a highly complex OOP nightmare, C will always beat Java to the curb. GC is not free. The problem with GC is that you pay asynchronously, while allocations are essentially free. But this asynchronous cost is very very hard to measure and to control. Java does not offer the mechanism C/C++ offer for native resource management. It also doesn't do complex optimizations, most notably vectorization. Number crunching performance will always suck in Java. Even if they add all the optimizations in the world, the simple fact remains: Java as a language simply does not allow you to express code in a performant way. That leave the compiler at a double disadvantage. It needs to essentially "convert Java to C++ and guess the most performant interpretation" (we are decades away from this), and it needs to do that within milliseconds (because its a JIT). It just makes no sense to talk about this. Use Java for the 99% of your product that is not a hotpath, use C for the remaining 1% where you need pure performance. Simple as that.