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

121–130 of 329 posts

Re: The compiler will optimize that away

#121

Post by [deleted] »

jolux wrote: post #117
jmull wrote: post #77

There’s a nice introduction to a data-oriented approach in here, but it’s buried in some junk. E.g., I don’t think a lot of developers believe compilers are magic optimizers. And programming languages, including the ones referenced, have changed quite a bit over the last 20 years. A strong enough case for general data-oriented features would cause at least some of them to support it. Also, a great amount of code shou…

To me, the goal of language implementations should be to make the most maintainable code also the fastest code. I shouldn't have to worry much about the performance characteristics of my software outside of general concerns about algorithmic complexity.

[deleted]

Re: The compiler will optimize that away

#122

Post by dragonwriter »

lordnacho wrote: post #101
dragonwriter wrote: post #98

Earlier quoted context omitted.

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

> You could say that about anything you construct in your model though?

That’s kind of the point, yes, model -> nouns -> objects.

> Stops being OO if it's not somehow similar to an admittedly vague concept of what an object is, surely?

There’s nothing particularly vague about “noun in the domain”; linguistic-based modelling certainly isn’t the be-all and end-all of OOP modelling, but its one of the traditional approaches dating back to the early 80s and its more sophisticated than thr kind of naive tangible-item approach that seems to be set up as a strawman here.

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

A relationship is a real thing in the domain being modelled, “systems” and “components” are (in the sense you are using them) not, unless the thing you are modelling is a an ECS implementation of a domain. There might be some utility for such a second-order model in OOP (if the OOP is for a code generator, for instance), but it wouldn’t be a model of the domain addressed by the ECS system, but of the ECS system itself.

Re: The compiler will optimize that away

#123

Post by secondcoming »

jolux wrote: post #117
jmull wrote: post #77

There’s a nice introduction to a data-oriented approach in here, but it’s buried in some junk. E.g., I don’t think a lot of developers believe compilers are magic optimizers. And programming languages, including the ones referenced, have changed quite a bit over the last 20 years. A strong enough case for general data-oriented features would cause at least some of them to support it. Also, a great amount of code shou…

To me, the goal of language implementations should be to make the most maintainable code also the fastest code. I shouldn't have to worry much about the performance characteristics of my software outside of general concerns about algorithmic complexity.

That all depends on what type of software you write. I don't think there'll ever be a language that ticks every requirement box.

Re: The compiler will optimize that away

#124

Post by jupp0r »

einpoklum wrote: post #104
esailija wrote: post #87

Earlier quoted context omitted.

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, a…

I spent years optimizing physics simulations from different domains (weather, fluid dynamics, all sorts of stuff). Even there you have to carefully pick the parts you want to optimize to get the best outcome for the resources you invest in optimization. It's completely infeasible to make everything crazy fast with a blanket approach.

Re: The compiler will optimize that away

#125

Post by jupp0r »

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…

Do you use browsers? Browser makers spend billions of dollars in engineering time making them "fast", with great results.

Re: The compiler will optimize that away

#126

Post by sudosysgen »

jupp0r wrote: post #125
esailija wrote: post #87

Earlier quoted context omitted.

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…

Do you use browsers? Browser makers spend billions of dollars in engineering time making them "fast", with great results.

Browsers are fast, but the content they render is very slow.

Re: The compiler will optimize that away

#127

Post by jolux »

secondcoming wrote: post #123
jolux wrote: post #117

Earlier quoted context omitted.

To me, the goal of language implementations should be to make the most maintainable code also the fastest code. I shouldn't have to worry much about the performance characteristics of my software outside of general concerns about algorithmic complexity.

That all depends on what type of software you write. I don't think there'll ever be a language that ticks every requirement box.

You can’t get all the way there but it’s a North Star, I think.

Re: The compiler will optimize that away

#128

Post by tialaramex »

einpoklum wrote: post #105

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

Another example:

> “Use const and the compiler will optimize that away!” Nobody knows what the compiler will do, if nobody checked what the compiler did.

Rust (in the Rustonomicon if nowhere else) specifically promises that const gives you the same results you'd get by calculating and manually inlining the constant itself everywhere. It even spells out all the things you thus can, and can't do in a constant so that your compiler can definitely correctly evaluate the constant from the point of view of the target architecture despite potentially different hardware.

e.g. if you tell Rust

  const BAR :isize = isize::from_be(0x1234);
You've conjured a constant BAR whose size and data layout depends on the target architecture, but the language promises that figuring this out incurs no runtime cost, the work will be done at compile time.

Indeed Rust will refuse to compile your program if it can't figure out how to do this, explaining what went wrong, e.g. that same above snippet would not have worked years ago, because isize::from_be() was not yet marked as suitable for such endeavours and so the compiler wouldn't attempt it.

If you mark a function the compiler can't evaluate as being suitable, the compiler will reject that too, even if you don't use the function, somebody else might and it won't disappoint them.

Re: The compiler will optimize that away

#129

Post by klyrs »

jupp0r wrote: post #125
esailija wrote: post #87

Earlier quoted context omitted.

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…

Do you use browsers? Browser makers spend billions of dollars in engineering time making them "fast", with great results.

Do you use websites? Because developers unthinkingly pull in billions of dependencies, making them "features", with horrific results.

And fast is one aspect of performance. What's the memory footprint?

Re: The compiler will optimize that away

#130

Post by 29athrowaway »

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…

Shit is slower than it was in the 90s.

Spotify is slower than Winamp, Slack is slower than IRC, Webmail is slower than my e-mail client, VS Code is slower than Visual C++ 6.0.

Post reply on HN