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

The compiler will optimize that away

blog.royalsloth.eu

Post reply on HN
Print view View original

91–100 of 329 posts

Re: The compiler will optimize that away

#91

Post by tom_mellior »

beagle3 wrote: post #86
tom_mellior wrote: post #84

Earlier quoted context omitted.

> That you have to write them over and over again for every single class. You offer to do that with Python. Or with some other code generator. A mythical language with SoA/AoS transformation "built in" will do exactly the same under the covers. But it might not offer other features you are used to, or (your argument) a sufficiently rich library ecosystem. You might as well do it yourself and use a language you are ot…

> You might as well do it yourself and use a language you are otherwise familiar and happy with. Nim, Rust, D, Lisp support this already as compiled languages, without sacrificing anything - perhaps also Zig - at the macro level. Jai offers it as a language feature, but I don't think that's a particularly good idea - it's just that Jai tries to stay simple in such a way that doesn't let it be a user-level thing. > Is…

> Not exactly, no, but you can with "X-macros",

I only gave this a passing thought before and was too quick to dismiss it. Yes, I see how it can be done. Which is just another argument that the whole thing is a non-issue, no? Languages with macro systems can do it. Languages with other build time code generation systems can do it as well.

> what's the name of the feature I need to look up?

Annotation processors. Here's the first thing I found with an example of code generation: https://cloudogu.com/en/blog/Java-Annotation-Processors_3-Ge.... Yes, it's considerably more verbose than a macro system. But it's still a tiny, write-once (or completely off-the-shelf) part of your overall project.

> And now, you try to use the standard library "Sort" or "Find", it doesn't work without adapters

OK, but the same is true for all the macro based systems you mentioned above, isn't it? And if it isn't: whatever you can generate with macros you can also generate some other way.

Edit: You won't like this, but looking at the docs for Java's Collections.sort method (https://docs.oracle.com/javase/7/docs/api/java/util/Collecti...: "This implementation dumps the specified list into an array, sorts the array, and iterates over the list resetting each element from the corresponding position in the array." So you can use it just fine if the SoA implements the List interface. But yes, at the cost of temporarily materializing an array of structs.

Re: The compiler will optimize that away

#92

Post by tom_mellior »

CyberDildonics wrote: post #85
jamesbrock wrote: post #82

> What if a programming language would provide us with a structure that would act like an array of structs, but internally it would really behave like a struct of arrays? We could program in the typical object oriented way that is convenient for humans, while still enjoying in great performance due to playing nice with the hardware. > So far, the only programming language I know of that supports this type of crazy da…

Haskell uses linked lists everywhere, so any transformation like this likely does nothing for speed.

The given link describes unboxed vectors. This is Haskell-speak for "actual array of actual machine numbers".

Re: The compiler will optimize that away

#93

Post by gpderetta »

Blikkentrekker wrote: post #90
gpderetta wrote: post #50

Earlier quoted context omitted.

It is technically also possible in C as long as the program can't tell the difference (thanks to the as-if rule). This is hard to prove though and in practice requires whole program compilation.

The C standard provides guarantees about data layout even if the compiler can prove it will never be used internally, for the sake of, say, external debugging.

And C compilers routinely optimize structures in such a way that they are impossible to inspect in a debugger. Because of SRA, non escaping aggregates might even not be allocated on a memory location at all.

Re: The compiler will optimize that away

#94

Post by commandlinefan »

I’ve never been able to get my head around the “anti-optimization” mindset. Like... what else should we be doing? If you’re going to be writing code anyway, you might as well take optimal advantage of the hardware while you’re at it. Now, some people point out that attempts to optimize sometimes backfire, but that’s a different problem - that’s something you should work on improving though practice (and measurement).

Re: The compiler will optimize that away

#95

Post by dragonwriter »

slifin wrote: post #58
beagle3 wrote: post #45

Earlier quoted context omitted.

> Somehow over the years I've found that the animals/cars analogies given in OO tutorials are one of the few places that fit well with the model. Yes, and I've never actually needed to implement a cat or a cow in any project :) The other thing for which OO works much better than plain data is GUIs - and I think it is not a coincidence that OO popularity exploded together with the the coming-of-age of GUIs. The other…

OO is a tree and html (UI) on a page is a tree The problem is when you want to go to page two and want to display the same data as page 1 but in a different configuration OO is suddenly terrible because the data is the wrong shape, you should hold your data as a graph then derive trees out of it to satisfy views OO is not good for UIs unless you have one page and the contents on that page is static and doesn't change…

> OO is a tree

Inheritance heirarchies in single-inheritance languages are trees. In MI they are DAGs. But neither of those constrains data representations, OO can support arbitrary data graphs.

> OO is suddenly terrible because the data is the wrong shape, you should hold your data as a graph then derive trees out of it to satisfy views

How does this make OO terrible? What you describe is exactly standard OO GUI practice (specifically, in MV architecture, the model layer is an arbitrary graph representing the data, from which the view is derived.)

Re: The compiler will optimize that away

#96

Post by dragonwriter »

lordnacho wrote: post #13

Good article. My own thinking when coding performance is also towards data oriented approaches. For example Bevy in Rust. If stuff needs to be fast, it needs to be in cache. To do that, have everything nicely packed so you only ask for a chunk as often as you need. Then when you need it, it's already there. Thing about old fashioned OO is it's often fine enough for your run-of-the-mill CRUD app. If you look at the la…

> If you imagine a game that has characters, relationships, items, spells, and so on, it's often not that easy to model as encapsulated objects.

I...disagree. ECS definitely has efficiency advantages for games in terms of support performant implementations, which for games is often overwhelmingly critical, but there’s well understand OO ways to address the modelling issue tou raise.

> Does each character have a list of other characters that they have a relationship with?

It probably acts like it does, but it probably doesn’t maintain it, instead deferring to a separate object that acts as a repository of relationships, which are themselves objects, which allows you to modify relationships without touching the characters at each side (which may be more than two for multilateral relationships).

> What happens when you want to change the relationship, or a character casts a spell that temporarily changes the relationship?

You retrieve and act on the relationship object, which knows how to handle modifications.

Re: The compiler will optimize that away

#97

Post by dragonwriter »

mmis1000 wrote: post #73
tgaj wrote: post #44

Earlier quoted context omitted.

> If you imagine a game that has characters, relationships, items, spells, and so on, it's often not that easy to model as encapsulated objects. Does each character have a list of other characters that they have a relationship with? What happens when you want to change the relationship, or a character casts a spell that temporarily changes the relationship? Can easily end up a mess, because it's not obvious where suc…

That sounds like a poor man's component if you already separated it into another class...? And that data is no longer belonging to the instance now.

> And that data is no longer belonging to the instance now.

It belongs to the correct instance. The noun in the domain to which the information logically uniquely belongs is a relationship, not a character (of which there is typically more than one with different roles in a relationship, the number and roles varying by type of relationship.)

One problem that textbook OOP examples produce is that they tend to favor a heirarchy of physical entities as examples, which has the virtue of familiarity but really obscures the analysis of nouns in the domain, the most important of which in most real domains are the nouns describing relationships, activities, and events.

Re: The compiler will optimize that away

#98

Post by dragonwriter »

lordnacho wrote: post #61
tgaj wrote: post #44

Earlier quoted context omitted.

> If you imagine a game that has characters, relationships, items, spells, and so on, it's often not that easy to model as encapsulated objects. Does each character have a list of other characters that they have a relationship with? What happens when you want to change the relationship, or a character casts a spell that temporarily changes the relationship? Can easily end up a mess, because it's not obvious where suc…

But splitting it out into another class is halfway there already, no? The relations object doesn't correspond to a real domain object anymore. Next step is just to split out all the other components.

> The relations object doesn't correspond to a real domain object anymore.

“relationship” is a noun describing a real feature of the domain, and thus is a real domain object.

Re: The compiler will optimize that away

#99

Post by Blikkentrekker »

gpderetta wrote: post #93
Blikkentrekker wrote: post #90

Earlier quoted context omitted.

The C standard provides guarantees about data layout even if the compiler can prove it will never be used internally, for the sake of, say, external debugging.

And C compilers routinely optimize structures in such a way that they are impossible to inspect in a debugger. Because of SRA, non escaping aggregates might even not be allocated on a memory location at all.

What is an "escaping aggregate"?; this term has 80 hits on Google, none of which seem to be related to programming.

Looking it up “aggregate” is a C++ term for which the standard indeed does explicitly allow various optimizations and guarantees about data layout are weakened; this is not the case with C arrays.

Do you have any practical evidence to C compilers altering the data layout of an array in any way?

Re: The compiler will optimize that away

#100

Post by beagle3 »

tom_mellior wrote: post #91
beagle3 wrote: post #86

Earlier quoted context omitted.

> You might as well do it yourself and use a language you are otherwise familiar and happy with. Nim, Rust, D, Lisp support this already as compiled languages, without sacrificing anything - perhaps also Zig - at the macro level. Jai offers it as a language feature, but I don't think that's a particularly good idea - it's just that Jai tries to stay simple in such a way that doesn't let it be a user-level thing. > Is…

> Not exactly, no, but you can with "X-macros", I only gave this a passing thought before and was too quick to dismiss it. Yes, I see how it can be done. Which is just another argument that the whole thing is a non-issue, no? Languages with macro systems can do it. Languages with other build time code generation systems can do it as well. > what's the name of the feature I need to look up? Annotation processors. Here…

That what I refer to as the "Turing complete" argument. Yes, you can definitely do all of those. But almost no one does - and those that do, usually silo themselves from the ecosystem.

Yes, if you like Java, you can definitely implement a Java compiler/interpreter in C and get everything you like about Java using C. But no one does.

Thanks for the reference, I'll read about annotation processors later tonight.

Post reply on HN