Every Byte Matters
fzakaria.com
Every Byte Matters
1–10 of 159 posts
Re: Every Byte Matters
#2I love to see stuff like this. And an active Vectrex gamedev and PC/Amiga sizecoder I strongly agree with the sentiment!
Re: Every Byte Matters
#3So if you need speed, you just have to swallow your OO programmer's pride and put your data in arrays.
Re: Every Byte Matters
#4So if you need speed, you just have to swallow your OO programmer's pride and put your data in arrays.
Maybe someone can write an OO language where arrays of structs are automatically stored as structs of arrays.
mild /s
Re: Every Byte Matters
#5The JVM is currently pretty bad for memory allocation. 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, and Project Valhalla will give the tools to do away with headers entirely in some cases. Project Valhalla also has tools to manage off-heap memory, which is important in many cases.
The JVM is an odd place where it requires too much heap to compete with the AOT compiled languages, but its startup time is too slow compared to interpreted languages. I think these enhancements are essential to keep the platform relevant.
Re: Every Byte Matters
#6Slight tangent, but every ms, μs, and ns counts too. We've gotten awfully carefree with response times and wasted compute cycles.
Re: Every Byte Matters
#7Re: Every Byte Matters
#8Out of course: I had thought about reading an article about Iran war or some geo political news when I read fzakaria :-)
Re: Every Byte Matters
#9> The cost of each new field is rarely considered
Most developers, in Java and in most other languages, do not consider the cost of every field, but I can tell you that people who need micro-optimisations certainly do care, and in Java's standard library, a layout is very much a concern (except, as always, you want to optimise what really matters; there's no point in optimising something that is unlikely to be a hot spot in a real program). Sometimes, though, you want to intentionally spread out the layout to avoid cache line sharing when concurrency is involved. You will find such examples in the standard library, too.
Re: Every Byte Matters
#10The JVM is currently pretty bad for memory allocation. 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, and Project Valhalla will give the tools to do away with headers entirely in some cases. Project Valhalla also has tools to manage off-heap memory, which is important in many cases. The JVM is an odd…
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.