Hacker News Reader

Comment by jackmott42 | Hacker News Reader

The website seems to have gone down under load, if this is a snarky response to Casey's pro performance take previously, then the irony level is high!

I really wish people would stop pushing back on people who are interested or curious about how to make code perform better. Of course you don't want people scattering weird SIMD intrinsics all over mundane parts of your web backend in an unhinged attempt to shave microseconds off a response. But in my career I've never really seen people do this anyway.

What you do want though is programmers who have spent some time understanding how to structure code to perform well on modern hardware. Because often times that structure is NOT a mess, it may even be easier to work with that the usual idioms in your industry or language. Grouping data into adjacent chunks with arrays or array backed data structures has more benefits than just leveraging the L1 cache. It is sometimes also convenient.

View on HN

I'd say it's orthogonal to Casey's take, which was about trading abstraction for (arguable) simplicity + performance. This was an article about aggressively optimizing a simple loop, thus trading simplicity for performance.

Given that it was from a consultancy advertising its optimization services, the irony of it going down is still pretty high, though.

What I didn't like about the "Clean code, horrible performance" video is that he talked about "clean" code as though it was this unjustified, useless way of thinking about programming. This is maybe something you have to think about if you want the most performant code possible, but I don't think it's a good mantra in all situations the way it's presented in the video. Number one priority should always be "understandable code". If you aren't always thinking about the best way to get your point across to future programmers (including yourself) you're going to have a bad time.

> he talked about "clean" code as though it was this unjustified, useless way of thinking about programming.

That was kind of the point. There is no empirical evidence showing that the "clean code" way of programming is any better in terms of cognitive load, but there is empirical evidence that it makes your program perform very poorly.

The video also did not aim to produce "the most performance code possible", which would certainly become a tangled web of arcane bit tricks and CPU minutiae. It was demonstrating what reasonable performance might look like, if you wrote simple code that the compiler can do a good job at optimizing.

In addition, he demonstrated very clearly that doing it the "clean" way was significantly worse in terms of being able to see that the optimizations he did were even possible, so, that observation argues that the "clean" principals not only make your code slow as shit, but ALSO harder to reason about.

I program in a similar style to Casey all day, every day, and I typically have no trouble going to code I wrote years ago and figuring out what's going on.

If that doesn't convince you that it's an unjustified and useless way of thinking about programming, I'm not sure what would.

We put a 'does this person understand assembly output' into our interview process. They don't have to get it 100% right, but not knowing anything is a hard No.

Interesting! What kind of company and technology domain is it? Assuming you don’t want to get too specific.

My first reaction is that I like this idea, but maybe I’m biased because I feel I’d “pass the test” myself (and thus have one additional small way to differentiate myself from pure Leetcoders :)

In most of the environments I’ve worked (except maybe the games companies) I feel this would not have been widely considered an acceptable thing to ask in a generalist interview.

adtech exchange

Reply on news.ycombinator.com