I'm in computer graphics, and find myself thinking "this dev really needs to better understand memory layout and computer architecture" all the time when I look at even basic code.

A perfect example of this is looping over some range of pixels, and many will just go ahead and do for (x) for (y) setPixel(x, y, f(x, y)). There's no logic error here but it's still terrible when dealing with images in the usual memory order idx = y * width + x.

It seems like many people have no idea how even basic abstractions (such as the aforementioned pixel indexing example) work, and have no performance expectations because they don't code in any systems languages.

People who are aware of such issues and still can structure large codebases well seem to be getting more rare to me, at least. In the 90s there were so many incredible demoscene programmers, and now... hmm...

(A related thing I wonder about is, where is the von Neumann or Newton of our times? There are more people around than ever, nutrition and medicine and poverty is globally better than ever, ...)

I'm currently studying EE and would like to get into embedded programming/semiconductor design, could you explain the optimal way to loop over the pixels if not with two nested for loops? Would it be something related to how in memory it's effectively a 1-D array?

It's a really deep problem actually! Doing y then x is better but it's far from "optimal".

These parallel programming course notes have an example of using z-order curves which is slightly better yet: http://ppc.cs.aalto.fi/ch2/v7/

And the best solution requires something like Halide https://halide-lang.org/ to find the best traversal order.

The loops should be inverted. It should be for y, then for x, which accesses the memory in a linear fashion instead of in stride.

This presentation (PDF) explains why: https://www.aristeia.com/TalkNotes/ACCU2011_CPUCaches.pdf

At the very least, the inner loop should be over X, since that is how the pixels are packed.

It is precisely the linear ordering in memory. Whether X-then-Y or Y-then-X is best depends upon if the data is stored row- or column-major.

>demoscene

Honestly, who has time these days?

People that care about their craft?

Yeah buddy I get home tired from work and the commute, crack open a cold one, and surf late 2000s forum posts on installing gentoo on a PS3.

There are many healthy activities to take up rather than play with deprecated/obscure tech. Not to be judgemental of course, I draw my line at home repairs.

When it comes to computer graphics, "deprecated/obscure" tech is the tech that is comprehensively documented from the ground up. There is some documentation about internals of the Raspberry Pi SoC and GPU, but sadly not enough to make it a compelling demoscene target.

I'm not saying you should. Enjoy your free time. I just think it's weird to shame people that care more by implying they have too much time on their hands. Everyone has a level of caring that's appropriate for them.

There's a lot of things you can learn from writing demos that is still incredibly valuable. I wouldn't expect 99.9% of developers to know those things, but if I saw it on a resume? That'd totally jump off the charts to me and I'd definitely want to interview that person.

Don't shame expertise just because you choose to spend your time differently.

I appreciate what you're writing about demoscene programming, but the GP comment does not seem to me to be shaming. It most likely was just about the commenter not having time themselves. HN has a guideline for cases like this:

"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

https://news.ycombinator.com/newsguidelines.html

I agree with the rule, but I only accused him of shaming after he drew a broad insulting caracature of a community I'm involved in and actually understand (the demoscene) by suggesting that it just involves people "browsing early 2000 forums and installing gentoo on PS3s". I think if you said that to any demo coder they'd tell you to eat sand. It's not even remotely close to what that scene is about. If there's a criticism to be made here, perhaps it's about not making assumptions about groups you know nothing about?

I made no assumptions other than what he explicitly said, which was insulting and displayed ignorance of a community he clearly does not understand. My original comment was also only "People who care about their craft?", which was simply saying that people get into demo coding because they care about doing something worthwhile (getting the most out of their machines in an artistically satisfying and interesting way).

There's a common social anti-pattern in most tech forums of hand-waving away any complex domain knowledge that the person doesn't personally use as "useless". I have no regrets about stating the contrary.

I am amused that I am the one getting a warning about this though. I'm not the one that made a drive-by ambiguous comment that could easily be read as singling out a fun community as being a waste of time. I just pointed out that that's what he just did.

I see now that the problem was that you pointed it out in a way that made sense to you, but not to the rest of us who lack all that background information. If you had responded in the first place with the explanation you've posted here, it would have been much easier to understand what the issue was. Now that I read this, I get your point, and I also see how the problem started with the GP comment, not yours. But this was not at all clear to me before! and I'm sure not to many readers.

HN has been super impressed and favorable to the feats of demoscene programming for over a decade now, so hopefully there's a lot more of that than this.

I'm sorry it came off as shaming.

I don't know of any project that was ever cancelled because of poor class design or lack of unit tests either. Sure they were hack jobs but if they met the needs of the customer then they were successful. Likely successful enough to be worth hiring you to fix those shortcuts. And allow you the free time to complain about craftsmanship on a public forum.

I absolutely have. A bonkers class hierarchy and no unit tests means that velocity will bog down to a crawl or even start running in reverse.

Absolutely. But to management it can look like another reason.

For example it could look like “Not enough revenue to pay all the devs”. But you only need a big team because it’s basically spaghetti code and there’s a lot of fires to put out.

I’ve seen this.

It’s also really hard to convince managers even technical ones who are not in the code that there is complexity to deal with. “But it’s just a [something that prima facie sounds easy] should be easy!”

It depends on the industry vertical. If you have heisenbugs in your software, let alone poor design / lack of unit and functional tests in one industry, it may not matter. But it may end up killing someone in another industry.

A bootcamp person can learn most of these things. It just seems with some of our recent hires they don't seem to want to learn this stuff or maybe it doesn't really matter for react devs.

And these things do make a difference. L1 cache is faster than L2 cache which is faster than L3 which is faster than memory which is faster than hard disk etc. You want your code to keep things within those limits to make things faster.

Or for example if you start using virtual memory and paging to disk you might want to switch algorithms. For example you might want to use merge sort instead of quick sort if you don't have a lot of ram and you have to go to disk. However if you have 128GB of memory and mostly randomized data you want to use quicksort.

This is kind of trivial example, but I think this stuff is somewhat important.

Yes I do think about this occasionally at work for math heavy (LA and in house built convex optimization) problems. I cringe when I see tight loop with stream/functional java API. It’s not zero cost abstraction you know!