Earlier quoted context omitted.
Yeah, I edited it out because after I took a breath I figured you didn't mean it that way. =) Hugs all around. But I really don't think it's a major thing, because there's no meaningful difference, in terms of performance, between "struct { int x; int y; } A" and "int Ax; int Ay;". I'm suspicious of claims that Go, as fundamentally a not that different language to a JVM language, is going to yield significant perform…
If it is not a major thing JVM architects would not deliberating on this issue in such details. http://cr.openjdk.java.net/~jrose/values/values-0.html Java value types are going to be in Java 10 i.e. years away. So may be it is not big deal for you but JVM developers think it is going to be big deal for lot of performance sensitive code. This is despite the fact that most advanced GC available in Java. See overhead f…
Or they're using arrays. And here's the one difference that I have acknowledged since my first post, but there's a but to it: there is one material performance-relevant difference between parallel arrays-of-members and arrays-of-structs, and that's locality of reference. But any multithreaded (or cooperative, for that matter) system of nontrivial size is already chucking cache coherency out the window to the point where I'm very, very skeptical of the claims of magicfastness because two int members are next to one another. If you can prove that cache coherency is killing you and you need to run more consistently to avoid eviction, then you can push the problem into a minimal process without much going on and `nice` it to keep your cache lines for longer, but you're still in the land of Things That Are Not Made Easier In Go, Either.
Those JVM architects are considering structs--using the CLR term for "stack allocated aggregate types" because they're already there and I've done this side-by-side comparison in that environment, which is as close a one to the JVM as exists that supports them--as a convenience and, in rare cases and in extremity, a legitimate performance improvement. A good idea to have. But it's such a corner case that even they feel comfortable pushing it, and its ramifications, to Java 10. (If you want to see why it's a corner case: again, go look at the CLR and how rarely structs are used. I'm almost as comfortable on the CLR as the JVM, and I make video games. I use structs. I've never, ever seen them in the wild in somebody else's non-library code, where you can encapsulate your perf grossness anyway.)
Go still has the heaviest performance overhead of all: having a garbage collector in the first place. The same things that cause memory pressure in Java cause memory pressure in Go. Which is what I am saying and getting downvoted for my troubles--that there is so very little daylight between the Go VM (yes, it's compiled to native code, it still has a frigging VM, go look at its bogus ART with ALWAYS CAPITALIZED INSTRUCTIONS because Rob Pike and company think not-actually-assembly programming is a "fraught endeavor" and you can see it yourself) and the JVM that claims about performance are real, real sketchy.
I've been down this road. I've looked. I don't see it. Linking to corner-case proposals (again: good ones, but marginal) from Java architects who are in the unenviable boat of trying to create bullet-point equivalence between the JVM and the CLR--that's not actually an argument.