Live data from Hacker News

The compiler will optimize that away

blog.royalsloth.eu

231–240 of 329 posts

Re: The compiler will optimize that away

#231

Disagree about garbage collected runtimes. A lot of widely used software is written in C or C++ and uses malloc/free extensively (C++ new/delete is mostly a wrapper around it). This results in memory layout worse than an equivalent managed heap would be. Happens because the memory allocated on C heap is immovable, while garbage collectors may move data around to defragment the heap.

Actually... https://arxiv.org/pdf/1902.04738.pdf On a more serious note, most c programs I see don't do very much of that, preferring to allocate fixed-size buffers on the stack. Additionally, most GC'd languages that aren't java have crappy GCs, and those GC'd languages that are java lack value types. This harms spatial locality quite a bit, and compaction can't fully compensate for that. They are working on adding…

Doesn't D have value types via structs since by default they're stack allocated and copied? Though I'm not sure how well it's GC performs when you do allocate on the heap.

Re: The compiler will optimize that away

#232

Earlier quoted context omitted.

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

> I dont know if you've noticed, but most programmers actually do care about performances. They just are bad at it. I disagree. Programmers may care about performance, but project managers certainly don't and they always have the final say.

I’m with both of you and I don’t think what you two are saying is mutually exclusive. I’m kind of a performance nut (often working with teams, I’m the guy that introduces everyone to a profiler) and, in my N=small experience, PMs are opposed to spending time on performance optimization precisely because most people are bad at it and it takes an undefined amount of time for unknown performance gains.

When I take an hour to profile and analyze some request and say “I think we can cut this thing’s response time by 80% by optimizing $X, which will result in an overall page load time reduction of 3s”, that’s way easier to sell than “I want to figure out why this page load is so slow” and then reporting back a week later with “shrug I optimized 5 things and it didn’t get faster. Dunno.”

Re: The compiler will optimize that away

#233
post #27

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…

To elaborate on Bevy: the data-oriented approach used is called an Entity Component System.

And super importantly an ECS is not necessarily data-oriented.

Re: The compiler will optimize that away

#234
post #125

Earlier quoted context omitted.

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

The problem with the NPM ecosystem is really dire because know-nothing programmers who write JS plug in to that ecosystem and write bad code, and then the know-nothing programmers who don't write JS come along, too, and say look how bad JS is.

JS is plenty fast and can be used for "large, complicated programs"[1] just fine. The problem with most JS written today is in programmer practices—the way that the community associated with NodeJS pushes one other to write code (which is, ironically, not even a good fit for the JavaScript language). It turns out that how you write code actually matters (which is the central point of the article here to begin with...)

1. https://web.archive.org/web/20070127104743/http://www.spread...

Re: The compiler will optimize that away

#235
post #183

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!

Winamp didn't stream all music in existence over the internet. How is it really comparable?

Lol arguably Winamp + Napster did :D

But really, 99% of the value-add of Spotify over Winamp is stuff that happens server-side. Your Spotify client doesn’t have a database of all the songs, nor the ML models for computing recommendations. As far as playing streaming music goes, Winamp would happily play an m3u (mmmm soma.fm).

Don’t get me wrong, the discovery and search features in Spotify have brought me a ton of value. But wow is the client resource usage dramatically disproportionate for the added functionality

Re: The compiler will optimize that away

#236
The data-oriented design approach is and has been standard practice for doing numerical simulations on High Performance Computing (HPC) environments. Still the problem of language support and syntactic sugar to make this style less error-prone and easier to do needs more work.

Re: The compiler will optimize that away

#237

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…

Almost all software I use these days is absurdly slower than it should be and probably a massive drain on collective productivity Productivity, energy usage, e-waste in landfill as people are forced to upgrade in order to do simple tasks with the current software... The world is paying a high price for programmer laziness.

Is it programmer laziness, or insane demand for software due to many factors, mostly profit?

Re: The compiler will optimize that away

#238
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…

This attitude is very common and has clearly degraded software development particularly for users, and like most issues afflicting modern software it's not perceived by developers so it "doesn't exist" to them. As the top reply to this mentioned, anyone can easily tell how much slower software is today even when computers and devices are so fast now! All in the name of "making code easy to reason about." I have news…

>As the top reply to this mentioned, anyone can easily tell how much slower software is today even when computers and devices are so fast now! All in the name of "making code easy to reason about."

Yeah - it also doesn't crash my PC when an app segfaults, hell even video driver failing these days won't bring my system down. I don't need to restart my PC when I plug in a device. That's not really compatible with your childhood DOS games that enter kernel mode and talk to HW directly - you pay for abstractions - and it's a good tradeoff.

I can also have files with more than 5 character file names, and my FS can revert file changes and create snapshots.

These "good old days" people are just unrealistic, VIM is fast even today - but I prefer having a graphical representation of file tree with fancy icons and search. But that's just me and 99% of people out there.

Performance is a feature - and it's not a feature most people rank high untill it becomes an issue. As much as a minority of people here are crying about electron and HTML - a huge number of developers use VSCode daily and enjoy the approachability of a JS/DOM plugin ecosystem. VIM is free and available for decades now, and it has such amazing UX that the one of the most upvoted questions on SO was how to exit from it...

Slack is dog slow - and IRC has been freely available for decades, most people here use Slack daily. Who uses IRC anymore ?

So keep using your Emacs integrated window manager and stop bothering the rest of us :D

Re: The compiler will optimize that away

#239

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…

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.

Spotify runs on all of my devices. In the morning I can ask my smart speaker to play songs that Spotify presumes I like, continue from my car with a voice command, see what my friends are playing or play their playlists. I'll gladly wait for the ~5 seconds it takes for an app to start if it delivers all this.

Of course IRC is much faster, it's also few orders of magnitude simpler than Slack. For work related communications I prefer Slack to IRC, but for chatting with friends IRC does just fine. One simple protocol vs hundreds of APIs that provide extremely rich content. Once again, Slack takes few seconds to launch on a modern machine, it's not that bad considering it does so much.

Yeah shit is slower, shit is also way more connected and complex than in the 90s.

Re: The compiler will optimize that away

#240
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…

D approach: https://maikklein.github.io/soa-d/
Post reply on HN