Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every Byte Matters

fzakaria.com

Post reply on HN
Print view View original

61–70 of 159 posts

Re: Every Byte Matters

#61

Post by fp64 »

the__alchemist wrote: post #58
fp64 wrote: post #15

Earlier quoted context omitted.

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!

A sibling comment also mentioned Jai. Not sure what I am missing that the original post was explicitly referring to Jai, some inside joke maybe?

I am sorry, I only know Odin. Jai is this cult on reddit/discord, right? You get access if you socialize enough or something? Not my thing. Not for a language.

Re: Every Byte Matters

#62

Post by gf000 »

re-thc wrote: post #47
pron wrote: post #45

Earlier quoted context omitted.

I'm saying that most developers aren't writing code where layout is a primary contributor to the program's performance. Even in performance-sensitive applications, only a minority of the team are working on the hot spots. And speaking about costs, knowing what to optimise is the key to software performance. Improving the performance of an operation by 10000x will improve the performance of your program by less than 1…

> I'm saying that most developers aren't writing code where layout is a primary contributor to the program's performance. I've heard this theory before. This isn't just about performance and I don't buy it. I've seen too many examples of this is just a temporary solution so it doesn't matter. >3 years later that "temporary solution" was still there and at the heart of many operations yet it's now to hard and too cost…

Then what is it that you are saying? That I should use JMH to determine the best layout for my helper class that will be initialized 3 times? Like most of the software (by line of code) is boring plumbing from one service to another with some dumb business logic sprinkled in. Something like a single config option for your database driver matters orderS of magnitude more in many types of applications.

It's much more niche to work on stuff where such changes actually matter, like much much more people write boring CRUD backends than those who write physics simulators and audio processing pipelines combined.

Re: Every Byte Matters

#63

Post by pron »

AlotOfReading wrote: post #56
pron wrote: post #39

Earlier quoted context omitted.

> 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. The point of bringing up Rust is that it also gives the compiler much more information to optimize on than C++, but actual performance is comparable or slightly worse in most benchmarks because the quality…

> Some of those Rust advantages are exactly the same things that have been touted as major advantages for Java over C++, like escape analysis and lifetimes.

These aren't the biggest advantages. I would say that the biggest ones are aggressive speculative optimisations that allow inlining of virtual calls (by default, up to a depth of 15 calls) and the ability to freely move pointers, which allows alternatives to free-list-based memory management. Low-level languages can't afford pervasive speculative optimisation (as they're focused on the worst case) and can't allow most of their pointers to be moved (because they often share them directly with the hardware and/or device drivers).

> and the wiki page on Java performance [0] is repeating what I understood.

That may be because the information on that page seems to be up to date to 2011-2. Java is now on version 26, BTW.

Re: Every Byte Matters

#64

Post by tealpod »

pron wrote: post #39
AlotOfReading wrote: post #27

Earlier 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…

We compiled one of our Java app to native binary using GraalVM (for encyption and secret managment needs). Side effect is the Java native binary performance is excellent, app startup time also significantly less compared to JVM version.

I am not sure how it compares with C++, Rust and Zig, but we made a benchmark with a similar Go binary, Java native version performance (load tests) is similar to Go binary. Only RAM usage of Java native binary is 3 times to Go binary (and JVM app took almost 10 times more RAM than Go version).

Re: Every Byte Matters

#65

Post by gryn »

theandrewbailey wrote: post #4
forinti wrote: post #3

So 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

something like this https://crates.io/crates/columnar ?

Re: Every Byte Matters

#67

Post by Altern4tiveAcc »

notatyrannosaur wrote: post #46
jayd16 wrote: post #31

Earlier quoted context omitted.

Even more so, it shows that SoA data structure means you can add fields to your 1M monsters with little impact.

> you can add fields to your 1M monsters with little impact. Great for this access pattern, but I wouldn't make a general statement like that. This is the same thing as row-oriented vs column-oriented databases, OLTP vs OLAP. SoA is weak if you are adding/removing monsters more often than accessing a single "hot" field.

> SoA is weak if you are adding/removing monsters more often than accessing a single "hot" field.

Why is that? Genuinely curious. Does "weak" mean that it performs worse than AoS, or that the gains aren't as significant versus AoS?

Re: Every Byte Matters

#68

Post by keynha »

notatyrannosaur wrote: post #46
jayd16 wrote: post #31

Earlier quoted context omitted.

Even more so, it shows that SoA data structure means you can add fields to your 1M monsters with little impact.

> you can add fields to your 1M monsters with little impact. Great for this access pattern, but I wouldn't make a general statement like that. This is the same thing as row-oriented vs column-oriented databases, OLTP vs OLAP. SoA is weak if you are adding/removing monsters more often than accessing a single "hot" field.

[dead]

Re: Every Byte Matters

#69

Post by gf000 »

AlotOfReading wrote: post #56
pron wrote: post #39

Earlier quoted context omitted.

> 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. The point of bringing up Rust is that it also gives the compiler much more information to optimize on than C++, but actual performance is comparable or slightly worse in most benchmarks because the quality…

Slightly off topic -- java-related wiki pages are notoriously bad and possibly biased for some reason. They are laughably outdated and have a bunch of non-objective sentences that paint a much worse picture of the language than deserved.

I have even tried removing/rewriting some of the questionable sentences but my edits weren't accepted.

Re: Every Byte Matters

#70

Post by jayd16 »

Altern4tiveAcc wrote: post #67
notatyrannosaur wrote: post #46

Earlier quoted context omitted.

> you can add fields to your 1M monsters with little impact. Great for this access pattern, but I wouldn't make a general statement like that. This is the same thing as row-oriented vs column-oriented databases, OLTP vs OLAP. SoA is weak if you are adding/removing monsters more often than accessing a single "hot" field.

> SoA is weak if you are adding/removing monsters more often than accessing a single "hot" field. Why is that? Genuinely curious. Does "weak" mean that it performs worse than AoS, or that the gains aren't as significant versus AoS?

Presumably they're referring to resizing the arrays.
Post reply on HN