[DavidWoof]

I honestly can't remember a time in my career when I've looked at a codebase and thought to myself "what this dev really needs is a more thorough understanding of CPU pipelines and virtual memory". Ed Yourdon once wrote something like "No project was ever cancelled because the developer couldn't address the serial bus". I'm much more concerned with bootcamp graduates not understanding good class design or appropriate unit testing than I am about any lack in low level mechanics.

I don't know if SWE is getting better or worse, but I do think that most SWE operates on a much higher level of abstraction than it used to, and I think that's good thing.

[pixelpoet]

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, ...)

[QuestionPixel]

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?

[fyp]

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.

[jfim]

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

[kamih]

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

[RhysU]

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.

[papermachete]

>demoscene

Honestly, who has time these days?

[overgard]

People that care about their craft?

[papermachete]

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.

[zozbot234]

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.

[overgard]

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.

[dang]

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

[papermachete]

I'm sorry it came off as shaming.

[grogenaut]

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.

[alrs]

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.

[quickthrower2]

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!”

[0x8BADF00D]

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.

[throwaway_45]

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.

[mrbonner]

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!