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

141–150 of 329 posts

Re: The compiler will optimize that away

#141

Post by quadcore »

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…

I dont know if you've noticed, but most programmers actually do care about performances. They just are bad at it. Software are slow precisely because programmers dont get it: optimising all the code will make slow software. They spend their budget optimising 99% of the code and end up with no more money to make that last 1% fast. For real (game engine programmer speaking). Plus optimising all the code make all the code unreadable which drains even more money from budget. Just as OP said.

Re: The compiler will optimize that away

#142

Post by Narishma »

fiddlerwoaroof wrote: post #137
corysama wrote: post #133

Earlier quoted context omitted.

People forget that Winamp was instant on a 60Mhz machine with a spinning rust drive. It’s difficult to buy a computer that slow these days. Modern CPUs modulate their speeds by far more than that as part of their moment by moment power management!

Related: when MacBooks switched to SSDs, the performance of my old spinning-disk MBP dropped noticeably basically overnight.

Same thing on Windows. It became incredibly slow on HDDs when SSDs started to become popular.

Re: The compiler will optimize that away

#143

Post by Silhouette »

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.

And yet developers working on front-end code to run in those browsers are waiting seconds for their linter or test suite or transpiler to process a few thousand lines of JS code, on a modern PC. Not a few million lines, a few thousand. That is orders of magnitude slower than it should be, and it's a cost that hits huge numbers of developers many times every day. Quite often, that awful performance is because the slow tools are written in a certain language also used in those "fast" browsers, and far too many developers are still giving this a pass because they incorrectly assume some magical runtime and JIT will make up for using a language that was never designed for high performance work and writing large, complicated programs.

Re: The compiler will optimize that away

#144

Post by 29athrowaway »

corysama wrote: post #133
29athrowaway wrote: post #130

Earlier quoted context omitted.

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.

People forget that Winamp was instant on a 60Mhz machine with a spinning rust drive. It’s difficult to buy a computer that slow these days. Modern CPUs modulate their speeds by far more than that as part of their moment by moment power management!

Winamp 2 was instant. Winamp 3 and 5 were slow.

Re: The compiler will optimize that away

#145

Post by mmis1000 »

dragonwriter wrote: post #97
mmis1000 wrote: post #73

Earlier quoted context omitted.

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…

The same thing can apply to every other property I think? probably you can seperate the User::name into a PersonIdentityProperty something like that, and remove the type limit to allow it to contain any property. Then it is basically a ecs now. And that do actually has some pros. People can have multi name, you system at least works properly with it now(and for free).

Re: The compiler will optimize that away

#146

Post by CalChris »

bogdanoff_2 wrote: post #140
sudosysgen wrote: post #126

Earlier quoted context omitted.

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

Reminds me of the "paradox" that making technology more energy-efficient has the effect of increasing overall energy use.

Jevon’s paradox

https://en.m.wikipedia.org/wiki/Jevons_paradox#Khazzoom–Broo...

Re: The compiler will optimize that away

#148

Post by XorNot »

fiddlerwoaroof wrote: post #136
29athrowaway wrote: post #130

Earlier quoted context omitted.

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.

Yeah, this is the weirdest thing to me: Windows NT 3.51 on a Pentium was much snappier perceptibly than even my new M1 MBP (developers are already expanding to the new performance envelope).

Windows Server 2019 has a much snappier UI then Windows 10 I've found (I recently spent a ton of time automating installs for both and boy did that become noticeable).

Then you look at the Windows 10 list of crapware and it becomes a lot clearer.

Re: The compiler will optimize that away

#149

Post by XorNot »

divs1210 wrote: post #69
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…

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

I just...I really want to like Clojure, but I cannot get past the brackety notation of lisp-likes. Surely there's a way to do it where I'm not in bracket hell?

Re: The compiler will optimize that away

#150

Post by grzm »

XorNot wrote: post #149
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/

I just...I really want to like Clojure, but I cannot get past the brackety notation of lisp-likes. Surely there's a way to do it where I'm not in bracket hell?

Use tools like paredit that support structural editing. There are tools like this for all major editors.

https://calva.io/paredit/

Post reply on HN