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
Every Byte Matters
51–60 of 159 posts
Re: Every Byte Matters
#52I started off with Machine Code, on a device with 256 bytes (not KB) of RAM. That was 256 bytes, to install the executable, reserve the stack, and set up the heap.
We often used bit (not byte) fields, to convey information.
Made life challenging.
However, being able to be sloppy has its definite advantages. It takes a long time to design highly-optimized stuff. If just declaring a couple of new properties takes thirty seconds, and designing a bitfield takes an hour, then we have some real cost-savings, there.
That said, it's easy to get crazy, these days. I just spent a couple of days, chasing down greedy memory hogs. These were operations that ate gigabytes of memory. I determined that the real culprit was actually Apple MapKit, and figured out a simple workaround, but it took a long time to get there. If I suspect the OS, then it's usually my fault, and trying everything before going back to the OS takes time.
Re: Every Byte Matters
#53Earlier quoted context omitted.
> Every object (i.e. not a primitive) has a header that IIRC is 12 bytes. But there is good news in JVM land: this will be reduced to 8 bytes in the next JVM release Since JDK 25 it's already 64 bits with the `-XX:+UseCompactObjectHeaders` flag [1], but in JDK 27 it will be the default [2]. > where it requires too much heap to compete with the AOT compiled languages Not to compete but to beat, and not too much, but t…
Your Project Leyden's "AOT cache" Youtube link is broken, did you mean to link to https://www.youtube.com/watch?v=fiBNDT9r_4I ?
Oops, thank you, but I actually meant to link to this one about how Netflix uses it: https://youtu.be/4kEh8hxAP4U. But your link is good, too.
Re: Every Byte Matters
#54The article shows nicely how "every byte matters" is false. First, it starts off by talking about the cost of a new field, when the actual topic is array-of-structs vs. struct-of-arrays. Then, this: > How much of an impact can this have? > Reading is:alive (1 byte) Across 1M Monsters You aren't reading one byte here, you are reading 1M bytes! Of course, optimizing the access to 1M bytes is something to consider. Opti…
Every Struct Matters
Re: Every Byte Matters
#55I started off with Machine Code, on a device with 256 bytes (not KB) of RAM. That was 256 bytes, to install the executable, reserve the stack, and set up the heap. We often used bit (not byte) fields, to convey information. Made life challenging. However, being able to be sloppy has its definite advantages. It takes a long time to design highly-optimized stuff. If just declaring a couple of new properties takes thirt…
How do you deal with all the daemons and automatic crap that does this on Mac? Isnt it all reinforced by SIP?
Re: Every Byte Matters
#56Earlier quoted context omitted.
In general, the tradeoff is between optimisations that help large programs vs optimisations that help small programs. Do you have concrete examples of large scale Java programs that are significantly more performant than comparable programs in native languages like C++? My understanding was that this dynamic hadn't fundamentally changed much since the 2010s, when Java was able to occasionally edge out a win in 1-2 be…
> Do you have concrete examples of large scale Java programs that are significantly more performant than comparable programs in native languages like C++? Yes. I was working in a place that made large sensor-fusion applications, air-traffic control applications, and logistical planning, each in the 2-8MLOC range. Over time, we ported all of them from C++ to Java because C++'s performance overheads were too annoying t…
I don't know what it is that Rust demonstrates given that few large scale projects have chosen it, but I've seen nothing to indicate that it doesn't suffer from the same performance issues as C++ compared to Java.
Of course, in principle it's always possible to match and perhaps even exceed Java's performance in a low-level language, but in practice it becomes ever more difficult as the program grows (and the cost remains with maintenance forever).
Re: Every Byte Matters
#57Anyways 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 store it both ways at all times and also keep both representations in sync, which also defeats the purpose, somewhat.
I feel like if you're trying to do this pattern then it doesn't make sense to also keep the objects.
Re: Every Byte Matters
#58Earlier quoted context omitted.
Maybe someone can write an OO language where arrays of structs are automatically stored as structs of arrays. mild /s
Odin has some helpers, was one of the more interesting features I found, but never tried. Not sure if you want to consider Odin OO, but well https://odin-lang.org/docs/overview/#soa-struct-arrays
Odin is heavily inspired by the lang he or she is referring to!
Re: Every Byte Matters
#59Earlier quoted context omitted.
Most of real world use of Java platform has next to 0 concerns like those. Some more niche use case may benefit, good, but overall success map isn't changing anytime soon. Reasons for its long term success lie elsewhere.
Android Java apps' memory consumption is definitely a relevant concern.
It doesn't even run "JavaTM", but some bastard child that is in like ~5 years delay compared to OpenJDK.
Re: Every Byte Matters
#60Earlier quoted context omitted.
Most of real world use of Java platform has next to 0 concerns like those. Some more niche use case may benefit, good, but overall success map isn't changing anytime soon. Reasons for its long term success lie elsewhere.
Not true. Lots of large Java deployments with millions to billions in cloud spend. The Java part of it isn’t 0. Memory isn’t free. CPU isn’t free.
And java uses very little CPU compared to most other languages. It's right after manual memory managed languages like C/C++, and is the first managed language according to a paper about how "green" each language is.
But there is a semi-fundamental tradeoff here, you either use more CPU to use less memory or the reverse. Java can be dynamically configured for either end (though defaults to less CPU by not running the GC unnecessarily).