Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple Code, High Performance [video]

youtube.com

Post reply on HN
Print view View original

71–80 of 86 posts

Re: Simple Code, High Performance [video]

#71

Post by andrepd »

nuerow wrote: post #34
cryo wrote: post #32

I love these videos, it's the kind of no BS programming to press performance on modern computers. Also recommend the Handmade Hero series of him. We have computers which are ridiculous fast, but tend to write code which is freaking slow. It's sad that most programs could be 100x faster.

> We have computers which are ridiculous fast, but tend to write code which is freaking slow. It's sad that most programs could be 100x faster. I feel this sort of comment misses the whole point of going with code which is patently slower than alternatives. The main reason is that performance is a constraint but not a goal, and once it is good enough then there is absolutely nothing to be gained by wasting time on se…

> once it is good enough then there is absolutely nothing to be gained by wasting time on seeking performance gains.

Energy consumption, loading time, performance for anyone who does not have the latest computer/phone + fast and reliable internet.

In fact, every dev coding a user-facing application on a kitted-out laptop should be forced to test it with the shittiest machine + internet connection their users might have (or, say, 10% percentile or something). Sometimes it feels people live in a bubble where they assume the latest processors, 32GB of RAM, and stable 100Mbps+ internet is available everywhere.

> It matters nothing if your browser wastes 1GB of RAM even though it could just use 100MB because practically everyone already has 8GB to begin with

Yep, a bubble indeed x)

Re: Simple Code, High Performance [video]

#72

Post by ratww »

Zababa wrote: post #64
kjksf wrote: post #63

Earlier quoted context omitted.

In this case: nothing. The fast renderer was written by one person in a few days. It's clearly a "few thousand loc" codebase, not "millions loc". The 100x slower renderer was also written by one person (or at most few). It really is the difference between programmers. It's also a good example that 10x programmers do exist, at least in certain situations. The Microsoft programmers are not dumb. They certainly are not…

I don't think that's exactly true. It's not the same thing to write a piece of code as part of a whole system, vs rewriting that piece of code as an isolated part. > The 100x slower renderer was also written by one person (or at most few). The difference between one person and a few is massive in my experience. > It really is the difference between programmers. > It's also a good example that 10x programmers do exist…

> It's not the same thing to write a piece of code as part of a whole system, vs rewriting that piece of code as an isolated part.

But, AFAIK, the new Terminal was new. Sure, it's 3 years old already, but Microsoft still didn't have the hypothetical "this is part of an old system" constraint when they started writing it.

> Microsoft programmers are not here to optimize for performance, but to push features, performance being one of them in some cases

Microsoft's marketing copy for the new Terminal cites "fast, efficient" in the first paragraph. It also cites GPU optimisation. Clearly performance was a goal.

Also, as been discussed ad-nauseam in other HN threads, Casey also added some extra features that didn't exist in MS's New Terminal. The "busy doing features" excuse also doesn't apply.

Re: Simple Code, High Performance [video]

#73

Post by ncmncm »

stagger87 wrote: post #56
nuerow wrote: post #40

Earlier quoted context omitted.

> Good enough” is defined by the inability of stakeholders to conceive of transitive benefits. The whole point is that there are absolutely no benefits, at least relevant ones, once the performance is acceptable. It's a diminishing returns game. There is always a tradeoff between performance and cost, and once performance is acceptable then it's hard to justify wasting more resources to get nothing of value in return…

> The whole point is that there are absolutely no benefits, at least relevant ones, once the performance is acceptable. Define acceptable. (Hint: you can't)

"Acceptable: Somebody accepts it."

Once you are talking about tradeoffs, it's game over. The question is, do you want to have spent your programming career writing crap code? Or do you want to make each thing you do be something you can be proud of, that is better than you would have done last week?

There is always something that could be done to make code faster, or shorter, more parallel, or line up columns better. What matters is whether you are pushing yourself to improve every day. If you improve yourself by discovering ways to make code fast, you will always find new ways to improve, and your improvements will also often make life better for other people.

If the quality of your code has no effect on anybody's life, it is time to find something else to code.

Re: Simple Code, High Performance [video]

#74

Post by matiasmolinari »

MikeDelta wrote: post #33
matiasmolinari wrote: post #24

Earlier quoted context omitted.

This is a good question to ask, if not rhetorical. When practicing rigorous measuring, quantities need to be quantifiable aspects of the world. For example, you can quantify how much physical space your code or compiled output takes up in memory, and use these quantities as base units to derive others. By branching from a quantifiable root, you can derive metrics such as lines of code or number of CPU instructions, a…

Readability can be quantified and it done by static code analyzers into a metric known as cognitive complexity [0], which measures things like amount of branches in your function. The thing is, you can make code of low complexity but still hard to read. [0] https://tomasvotruba.com/blog/2018/05/21/is-your-code-readab...

Sure. You can trace branches to quantifiable roots, but you can’t trace readability. To me, readability means something different than what it means to the author of that article.

Re: Simple Code, High Performance [video]

#75

Post by ratww »

Zababa wrote: post #69
Attummm wrote: post #65

Earlier quoted context omitted.

Looks like you dont now the full story behind it. But there is quite a back story to this. The guy in video called what your doing now "the excuse parade". Instead of finding solutions, your time and energy goes into making excuses. Watch the full video.

> The guy in video called what your doing now "the excuse parade". > Instead of finding solutions, your time and energy goes into making excuses. Excuses for what exactly? I don't remember writing that code. I'm explaining incentives that leads to slow code. I usually try to write the best code I can in the time I have, but if one day the problem is that my code is too slow, I won't be making excuses. I chose at the…

The "excuse parade" mentioned by the grandparent poster is another name for what psychology calls "rationalisation".

Microsoft fucked up about performance, period. The reason for that is not because the Terminal provided too many features, or because they wanted the code to be "readable". The manager didn't even claim the team didn't have time to do it, he flat out said it would be impossible without taking a few years to research.

Time and time again we see this kinda thing happening in software and people jump into made-up rationalisations because they're in denial about the root cause of issues.

Re: Simple Code, High Performance [video]

#76

Post by Chris_Newton »

_vvhw wrote: post #61
Chris_Newton wrote: post #42

Earlier quoted context omitted.

Meanwhile, the main resource in software development is man hours. The faster you write software (add features, fix bugs, etc) the cheaper it is.* People have argued that developer time is the most precious resource since forever. In more recent times, people have also argued that pushing new features needs to happen as quickly as possible, particularly in the context of web and mobile apps. I am rather sceptical abo…

I agree with you in general, but O(n²) is always dangerous. Perhaps this example you give is a little to the extreme. Writing slow software is also a form of waste. Then it becomes a question of ranking waste and getting rid of the most wasteful, according to a cost/benefit ratio, but waste is never a good thing to tolerate in any cultural sense.

O(n²) is only dangerous if you’re scaling past the point where the n² behaviour outweighs any constant factors and lower order terms. When n is small, a fancy algorithm with lower big-O complexity could still be outperformed by a brute force O(n²) one in practical situations.

On the other hand, a poor choice for a critical algorithm working with a large data set could easily increase your costs by orders of magnitude, so if anything I’d say the example I gave (assuming you meant the AWS costs one) was conservative.

I agree that we shouldn’t be careless about being wasteful, but big-O complexity rarely tells the whole story when it comes to performance.

Re: Simple Code, High Performance [video]

#77

Post by Zababa »

ratww wrote: post #75
Zababa wrote: post #69

Earlier quoted context omitted.

> The guy in video called what your doing now "the excuse parade". > Instead of finding solutions, your time and energy goes into making excuses. Excuses for what exactly? I don't remember writing that code. I'm explaining incentives that leads to slow code. I usually try to write the best code I can in the time I have, but if one day the problem is that my code is too slow, I won't be making excuses. I chose at the…

The "excuse parade" mentioned by the grandparent poster is another name for what psychology calls "rationalisation". Microsoft fucked up about performance, period. The reason for that is not because the Terminal provided too many features, or because they wanted the code to be "readable". The manager didn't even claim the team didn't have time to do it, he flat out said it would be impossible without taking a few yea…

I think there's a difference between most software being slow because it's not a priority, and some specific parts like that terminal being slow because people have absolutely no clue and are in denial.

Re: Simple Code, High Performance [video]

#78

Post by ratww »

Zababa wrote: post #77
ratww wrote: post #75

Earlier quoted context omitted.

The "excuse parade" mentioned by the grandparent poster is another name for what psychology calls "rationalisation". Microsoft fucked up about performance, period. The reason for that is not because the Terminal provided too many features, or because they wanted the code to be "readable". The manager didn't even claim the team didn't have time to do it, he flat out said it would be impossible without taking a few yea…

I think there's a difference between most software being slow because it's not a priority, and some specific parts like that terminal being slow because people have absolutely no clue and are in denial.

But the fact that higher performance is not a priority is something that is held together by those excuses and rationalisations.

People complain about performance all the time, both users and people inside their teams, but the thinking you're espousing is so widespread that developers clamouring for optimisations are just shut down.

End-users not having to wait 5 or 10 seconds unnecessarily can be a boon in productivity in some industries that use Enterprise Software. But we can't rely on having Casey Muratori going to a supermarket whose POS is slow and rewriting the software on a weekend and publicly shaming the supermarket chain on Twitter. Change has to come from within. Even accepting reports that the software is slow would be a good start.

The problem is not that the inefficiency exists or that they can take too long to fix. The problem is that no team ever really cares to stop and say "ok is this inefficient, how long will it take to optimise? Will we get gains from that?".

Instead of asking and researching, people just do as you do: they rationalise by saying "I can't prove that it can't be faster and I can't prove that it's not costing us or our users money, but it is my belief and no proof will make me change it".

This is a industry wide problem. It's anti-scientific posturing that's leading to widespread software slowness, programmed obsolescence and excessive spending of hardware.

Re: Simple Code, High Performance [video]

#79

Post by ratww »

nuerow wrote: post #46
yakubin wrote: post #35

Earlier quoted context omitted.

In my experience, people waste performance and manhours at the same time. Many abstractions create more code instead of reducing it, at the same time making the code slower, harder to read and maintain. Would you rather maintain a couple hundred lines of straightforward code or thousands of lines of class hierarchies with delegates and whatnot? See John Carmack on Inlined Code : http://number-none.com/blow/blog/progr…

> Would you rather maintain a couple hundred lines of straightforward code or thousands of lines of class hierarchies with delegates and whatnot? I feel this is a gross misrepresentation of the problem. With higher-level frameworks, you can add complex features with one-liners, which by their very nature (generic, extendable, and general purpose) are bloated and underperform when compared with the code you could roll…

I also feel like your post is another gross misrepresentation of the problem.

The issue with slow software is rarely the framework itself. Even frameworks like Rails and Django are more than fast enough for most things. If you need absurd performance (for, I don't know, HFT?), then there are other frameworks in other languages. There is no need for bespoke code! Fast frameworks do exist. Also, when frameworks are slow in some parts, someone can just go there and optimise for everyone!

However the issues we normally encounter regarding speed are often caused by convoluted bespoke architectures.

It's always because Database access has to go trough ten, twenty classes, and not only it's slow, it's also hard to maintain, as you lost control over what the SQL looks like. It's always because serialisation requires some crazy Reflection that is several orders of magnitude slower and more complex than a simple "to json" call. It's always because the hot-loops of your sorting algorithms have to go trough some unnecessary only-used-once abstraction that makes the whole hot loop slow.

Java is fast as heck but got a reputation of being slow among users. Also Enterprise Java projects had a reputation of being difficult to navigate and therefore more expensive. The issue wasn't Java: it was the convoluted bespoke architectures that plague it.

It is widely acknowledged by its proponents that those difficult architectures take more time to build. However there is zero evidence that such things help with maintainability. In fact I'd argue that those arcane architectures make it worse for the general-case scenarios of: bug fixing (because more classes mean more bugs and more places for bugs to hide), optimisation (because measurement is harder in complex programs, and optimising often requires dismantling and rebuilding things), adding features (because it was hard to build the first features, it's gonna be hard for future brand new features too) and even refactoring (if the problem is the complex architecture itself, refactoring in parts will lead to a messier program).

So there you go: waste of man-hours and of processors.

So no, the parent poster's complain has nothing to do with the reuse of frameworks or libraries.

Post reply on HN