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

101–110 of 329 posts

Re: The compiler will optimize that away

#101

Post by lordnacho »

dragonwriter wrote: post #98
lordnacho wrote: post #61

Earlier quoted context omitted.

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.

You could say that about anything you construct in your model though? Stops being OO if it's not somehow similar to an admittedly vague concept of what an object is, surely?

I could write the whole thing as an ECS and call all the objects systems or components, and then they are nouns in the domain?

Re: The compiler will optimize that away

#102

Post by fwip »

commandlinefan wrote: post #94

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).

"Anti-optimization" advocates doesn't say "optimized code is bad." It means "other things are more important than optimization."

One of those things is the amount of work required. For example, if it takes 30 minutes to get a "good-enough" solution, and 2 days to get a "very optimized" solution, most of the time you should go with the good-enough solution, because most of the code you're writing isn't performance-critical.

Re: The compiler will optimize that away

#103

Post by cozzyd »

grayclhn wrote: post #74
disgruntledphd2 wrote: post #21

Earlier quoted context omitted.

This approach is still used (conceptually, at least) in statistical computing. NumPy and R are good examples of this approach, and also have solutions for the indexing problems outlined in the article. That being said, statistical computing is at the mercy of the high cost of matrix multiplication. I think that you can alter the order of arrays in numpy, and examine the performance difference.

I think the desired functionality is closer to Pandas than Numpy — you want coordinated arrays of different data types, not higher-dimension arrays of the same data type. R and Pandas aren’t exactly known for their outstanding native performance (they’re generally fast after converting dataframes to arrays and outsourcing to C or Fortran) so they’re great demonstrations of the syntax for some of these indexing proble…

ROOT TTrees will "split" class members to effectively transform them into AoS although this is mostly for IO efficiency.

Re: The compiler will optimize that away

#104

Post by einpoklum »

esailija wrote: post #87
jupp0r wrote: post #79

The implicit premise of the article seems to be that all software has to be heavily optimized. This is completely wrong. All the languages mentioned in the article are still around because it doesn’t matter how performant 99% of code is. For the 1%, we can think about cache misses, SIMD and data parallel approaches. In my experience this is totally possible and not too hard, but has the enormous downside of making th…

I disagree. Almost all software I use these days is absurdly slower than it should be and probably a massive drain on collective productivity. I have ssd, fast internet, 64gb ddr4 etc, almost everything I do should be impercetibly instant but instead takes seconds and even minutes. Yeah of course most of that slowness is not even because of ignorance of the low level stuff but complete disregard of performance aspect…

You're both right - but about different kinds of software.

I believe the GP post was thinking an application which has some heavy computational kernel to it, where most of the processor time (and other resources) are spent - with a lot of other code for UI, configuration, some parsing etc.

And you seem to be talking about everyday desktop applications: Browser, mail client, word processor, instant messaging client, and maybe even your IDE as a programmer. Those kind of apps don't have that kernel of hard computational work - their work is much more diffuse.

Re: The compiler will optimize that away

#105

Post by einpoklum »

This article makes a bunch of invalid (sometimes implicit) assumptions or claims:

*A 20 yro language's design decisions don't make sense today because of the hardware perf situation change.*

1. Most languages were not designed for optimal utilization of the specific hardware situation during their conception.

2. Even languages designed with performance in mind somehow are still incredibly general and flexible things.

3. The article itself shows that CPU hardware has been changing along a mostly predictable path for decades. Everyone knew Dennard scaling would end, even if you couldn't predict it to within the single year. Everyone saw CPU latency was decreasing much much faster than memory latency, already in the 1980s.

--

* The main problem that we have today lies in utilizing the CPUs to their full potential.*

This is _a_ main problem, not _the_ main problem:

* There are other, specialized processing hardware (like GPUs).

* There's computation happening elsewhere on the system, e.g. on disk controllers and NICs.

* And actually, if you look at desktop environments and apps: They really don't need to utilize the CPU to its full potential; they're a mess of entanglement of things which get in each other's way and it's difficult to figure out why your system ends up being sluggish despite your brand-new shiny hardware.

--

*Another problem with the current programming languages is that they didn’t evolve beyond the C-style type of programming. *

* C-style type of programming is just fine for C-style kinds of programming tasks. Every language has strengths and weaknesses. Some pairs of languages have a more obvious "X is an evolved Y" or "X is a better Y" relationship, but not that many.

* Most languages do not evolve or change to exploit specific hardware capabilities. Or at least - few language changes are intended to achieve that.

--

etc.

It's not a junk article though. The data orientation of program design is a useful notion, in many programming languages. It's just that, instead of reading this blog post, which quotes Mike Acton, you can just watch Acton's talk on this principle:

https://www.youtube.com/watch?v=rX0ItVEVjHc

Re: The compiler will optimize that away

#106

Post by throwaway17_17 »

Blikkentrekker wrote: post #99
gpderetta wrote: post #93

Earlier quoted context omitted.

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?

GP’s comment is referring to Scalar Replacement of Aggregates on the one hand. This is an optimization where by the compiler will, for a function with a Struct argument, only pass in a pointer to / copy of the actual element of the struct used inside a function. Hence the name, the compiler is replacing the aggregate struct by one or more of the individual values it contains.

The reference to non-escaping aggregates, describes the compiler optimizing a local only struct by keeping the individual elements in registers during usage, and because the struct as a whole does not leave the local scope, these elements are just discarded when that scope closes.

Both of these transformations/optimizations are performed by all three industrial C and C++ compilers (gcc/llvm/msvc).

Re: The compiler will optimize that away

#107

Post by tom_mellior »

beagle3 wrote: post #100
tom_mellior wrote: post #91

Earlier quoted context omitted.

> 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.

I appreciate the discussion, but I believe you're arguing in bad faith.

> Yes, you can definitely do all of those. But almost no one does

That's what you say. What is this based on, considering that until a few hours ago you didn't even know that Java has this built-in code generation facility?

When I search for "entity component sytem java", the first hit is this project: https://github.com/Rubentxu/Entitas-Java which uses a "code generator [that] generates classes and methods for you, so you can focus on getting the job done. Radically reduce the amount of code you have to write and improve readability. It makes more of a sea code less prone to errors to ensure the best performance."

Sure, it's probably not as widely used as other frameworks in other languages. Java isn't necessarily the first thing on people's mind when it comes to implementing AAA games.

> and those that do, usually silo themselves from the ecosystem.

You have not shown this. And if you mean that your C macro implementations do this -- fine. But you still seem to find them useful enough to keep using them?

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

That is a Turing equivalence argument. But using a very simple code generator for a very simple problem is not the same thing. Given that Java syntax is very similar to C, I wouldn't be surprised if your existing macros could be used 1:1, with the hardest part being getting a Java build system to call the C preprocessor on a Java file. Not quite the same thing as implementing an interpreter.

(Also, as far as I'm concerned this was never about Java per se.)

Re: The compiler will optimize that away

#108

Post by celrod »

beagle3 wrote: post #42

> So far, the only programming language I know of that supports this type of crazy data transformations is JAI, As far as I know JAI is indeed the only language that explicitly lets you switch between AoS and SoA with one bit, but the APL family of languages - (APL, J, K, Shakti, and a couple more) has basically - for 60 years no - taken the "data oriented" SoA approach for storage, and provides the language support…

ISPC also has first class support for "(array of) structure of arrays", see: https://ispc.github.io/ispc.html#structure-of-array-types

For example:

  soa Point pts[...];
declares an array of struct of arrays, where each inner struct array contains 8 elements. This would have the advantage of playing well with the streaming prefetcher if you're working with all fields of the `Point` type, and allowing the compiler to use and increment a single pointer for loading/storing, accessing each field with a small compile time offset (that can get folded into addressing calculations, making them essentially free).

Julia's StructArrays package is also very convenient: https://github.com/JuliaArrays/StructArrays.jl

Re: The compiler will optimize that away

#109

Post by adgjlsfhk1 »

TazeTSchnitzel wrote: post #33

The metaprogramming available in languages like Rust and C++ could maybe be leveraged to make the struct-of-arrays model easier. Wouldn't be the same as native support, though.

Julia has a package that provides incredibility easy to use SoA. https://github.com/JuliaArrays/StructArrays.jl Julia's metaprogramming and multiple dispatch mean that it can use user structs fully transparently. Everything just works.

Re: The compiler will optimize that away

#110

Post by MaxBarraclough »

iforgotpassword wrote: post #72
divs1210 wrote: post #69

Earlier quoted context omitted.

> The other thing for which OO works much better than plain data is GUIs This cannot be further from my experience. Switching from Java/AWT/Swing to ClojureScript/Reagent/Re-frame has been suoer liberating. Every GUI programmer must fiddle with reagent once: https://reagent-project.github.io/

Well, you really picked the worst representative with awt/swing. I'd say Qt or even classic VB6/Delphi are great examples for OOP gui development.

How about JavaFX? Swing has been old hat for years now.
Post reply on HN