Live data from Hacker News

The compiler will optimize that away

blog.royalsloth.eu

241–250 of 329 posts

Re: The compiler will optimize that away

#241

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.

I think this approach applies even more so for GPU compute as it’s the only sensible way to code these devices.

Re: The compiler will optimize that away

#242

Earlier quoted context omitted.

> linked lists are a bad data structure Why is that? They're perfectly fine for most purposes, and have the advantage that when you pass one across a function boundary the callee can play with it or modify it or do whatever the hell they want and when the callee returns, the caller's linked list is untouched. That's an incredibly valuable feature for correctness and safety.

They have poor cache performance when you want to iterate over them, and more size overhead, because there's one pointer lookup per item. Also, the common definition of a linked list has the list responsible for allocating each item, meaning it can't be a member of more than one list at once. The actual useful version of this is called instrusive linked lists, which isn't the one taught. > That's an incredibly valuab…

> Are you thinking of something else? That's an effect of call by value, but linked lists actually aren't good at that and you have to copy them to pass them around.

Are you thinking of something else? Haskell (and all other ML-family languages, and Lisps) lists are passed around by copying a single pointer to the head element. Different lists can share tail elements, i.e., elements can be members of more than one list.

All this is in contrast to Java-style linked lists, where there is a list object that controls its elements.

Re: The compiler will optimize that away

#243

Earlier quoted context omitted.

> Sure developer time costs, but this cannot actually be the reason. It totally is because we've abstracted the cost of software engineering unto the hardware. Back in the 90s, people had to basically beg for memory when writing software while modern development is built on the theory of getting the fastest delivery speed at the cost of performance. We outsource the cost of software unto millions of customer's hardwa…

The point stands anyway. Why are all my dev tools super slow? If my time is important, shouldn’t those be fast and heavily optimized? And don’t try to tell me that 4 billion cycles a second across 16 cores operating on in-memory contiguous values isn’t enough to update a watch window more than 1 time per second.

If my tools are faster than me, there’s no point in making them even faster. In fact, I’d trade some of that speed for a smaller memory footprint.

In your example of the watch window, updating it at more than 30 fps is probably overkill.

One very common mistake is optimising the wrong thing. My advice is always the same: first run a profiler with a real workload (absent that, eu it over your automated tests), then look at what you need to optimise for speed. All the rest should be optimised for readability.

In the article’s case, if counting warriors is so important, keeping a counter at the AntColony class that’s updated every time you write to an Ant would be the obvious solution.

Re: The compiler will optimize that away

#244
post #237

Earlier quoted context omitted.

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?

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

There's insane demand for games, and those programmers are able to optimise their code, insane demand for trading software and those programmers are able to optimise their code. But webdevs just don't care. I look at pages now that do nothing more in functionality than the same app would have done 20 years ago, yet they are slower now, and I have literally 1000x more CPU power. It's insane.

Re: The compiler will optimize that away

#245

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.

Programmers may care about performance, but project managers certainly don't and they always have the final say

LOL no. Offer a dev choice between a framework that is trending on Twitter, vs one that is 100x faster but "legacy" (meaning more than a year old) and she'll choose the first one every time, and the project manager won't know the difference, or care if he did.

Re: The compiler will optimize that away

#246
post #237

Earlier quoted context omitted.

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

Is it programmer laziness, or insane demand for software due to many factors, mostly profit? There's insane demand for games, and those programmers are able to optimise their code, insane demand for trading software and those programmers are able to optimise their code. But webdevs just don't care. I look at pages now that do nothing more in functionality than the same app would have done 20 years ago, yet they are s…

Optimized games have a well known impact on sales. I'd assume the same with trading software. Putting out a blanket statement that web devs are lazy is just silly. Developers rarely have much say in how much time they can dedicate to features and the app as a whole, that usually boils down to PMs and management. If the org as a whole doesn't value performance or doesn't think it matters, then that will get reflected in the product regardless of what the developers actually want.

Re: The compiler will optimize that away

#247

Something I genuinely don't understand "buttery smooth 3D game"s are created with C++ too but why isn't C++ an issue for games? Seems to contradict the premise which is that programming languages were designed in the past and hence not efficient for modern computers.

C++ is an issue for games. Most game engines implement a garbage collected script language (e.g. Lua, CLR, JavaScript...) to implement huge parts of game logic.

Re: The compiler will optimize that away

#248

Earlier quoted context omitted.

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.

The amount of effort involved in making sure reads were sequential back in the HDD days was immense. It’s not surprising people dropped that as soon as possible.

Re: The compiler will optimize that away

#249

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.

The subjectively fastest, which is to say the most responsive or lowest input latency, computer I've ever used was a Macintosh 512ke upgraded to 2.5 megabytes of memory, running the system software and apps off of a 1.5 megabyte RAM-disk. When you double-clicked, say, MacPaint in the Finder, it was loaded before you finished the physical mouseup. This was when that hardware and software was still current.

Re: The compiler will optimize that away

#250

Earlier quoted context omitted.

The point stands anyway. Why are all my dev tools super slow? If my time is important, shouldn’t those be fast and heavily optimized? And don’t try to tell me that 4 billion cycles a second across 16 cores operating on in-memory contiguous values isn’t enough to update a watch window more than 1 time per second.

> Why are all my dev tools super slow? If my time is important, Quantify important into how much you spend on your tooling. Aside from some key bits of development software at the IC / board layout, almost everything a software developer needs is free, open source or cheap. Noone pays $1000 for an IDE anymore.

> Noone pays $1000 for an IDE anymore.

How many minutes per developer per day before that level of expenditure pays for itself inside 2-3 months?

Who cares? The premise is false, you can't buy it. There is no "fast tools" you pay for. Every decent shop got their devs an SSD at the first available opportunity because it paid for itself really quickly, cost you money _not_ to buy them. The very definition of a false economy was "no the devs aren't getting new shiny sportsmode SSDs for their boxes."

We all use gcc and clang (for relevant languages), for example because everything else you might pay for sucks a lot harder. Whatever the ideology you claim or deny. Intel literally damaged their customers' products to try to make themselves look better than AMD with theirs! They're a non-starter after showing themselves willing to do that but if you must, yes, their compilers still suck exclusively on intel more than gcc. How is microsoft's compilers standards chasing going? In the 21st century yet or /still/ not? (Oh come one, we're mostly there but for ... yeah). Compiling template heavy C++? Does developer time matter?

(But just quietly, terminals & cmdline tools feel a lot more productive than IDEs to me and I use both in differing circumstances).

Post reply on HN