So this guy has had a t-shirt printed with a mirrored logo just to be able to use it with the transparent whiteboard.
Simple Code, High Performance [video]
41–50 of 86 posts
Re: Simple Code, High Performance [video]
#42I 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…
Meanwhile, the main resource in software development is manhours. 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 about both claims.
Yes, developer time is important. Developer compensation is probably the largest single cost in most software development organisations and you want a good return on that investment.
Yes, the goal is acceptable performance rather than perfect optimality every time. The best is often the enemy of the good here.
And yes, that means it is foolish to invest weeks of developer time to implement an O(n) algorithm when you had an O(n²) algorithm that ran fast enough in practice.
However, what if you have a data processing job running on some cloud infrastructure that is charged according to usage, and carelessly using an O(n²) algorithm when you could have spent an extra day to write an O(n log n) one increased your AWS bill for that system by a factor of 10?
Performance can be important in other areas that sometimes get overlooked, too. In communities like HN, most of us probably enjoy the use of modern devices with relatively high specifications, but not everyone is so lucky. A classic “works for me” problem is developers running on high-spec equipment who don’t experience frustrations that their users with more modest equipment will run into, when maybe that “acceptable performance” shouldn’t be considered so acceptable after all.
And what about other types of software, such as embedded systems, where there are often tighter resource constraints and being able to use less powerful hardware components can have a significant impact on the overall cost to produce a device?
Meanwhile, I see little evidence that the relentless push to push changes around every five minutes is an automatic win. Yes, deploying changes like security updates and critical bug fixes quickly is important, but are users really happier — or, from a business perspective, willing to pay more for our software — because of the modern culture of continuous deployment and frequent updates of everything? That’s less clear.
It is undeniable that a lot of customers will still pay for poor quality software, which means shipping poor quality software can be an attractive and lucrative business model, which means paying lots of money to developers who will only produce poor quality software can work, which reduces the incentives for developers to do better. This is unfortunately the world we live in. But it doesn’t mean some of us running software businesses or working in software development can’t try!
Re: Simple Code, High Performance [video]
#43Earlier quoted context omitted.
Right it’s a communication problem because calling code simple conjures different ideas in people heads. Code that is simple for computers (principle of least work) is not necessarily simple (principle of comprehension?) for humans.
There is a high overlap though, it's often harder to understand how highly abstracted code actually works than 'unrolled' verbose code composed from simple operations (which is closer to machine code - thus the 'overlap'). It might be easier to understand the 'intent' of highly abstracted code, but this doesn't mean the code behaves as intended, and IMHO 'readability' is about understanding what the code actually doe…
I think all these things are aspects that are interrelated. A principle of abstraction is another good one. Others I can think of are principle of least surprise and principle of least work done by the compiler (lol “zero cost” abstractions).
Re: Simple Code, High Performance [video]
#44I 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…
This has been the prevailing mentality in the industry for a long time, being essentially a business dogma in IT since the 90s (for a good reasons, as you explained). I think Java is the personification of this concept (more specifically idiomatic corporate Java from the 00s).
But there is a recent small change of winds, where management is realising that being faster than the competition can have some business merit, being worth spending some man*hours. The lecturer explains it well in the beginning of the lecture. It is not a 180° turn, performance is not the priority (as it shouldn't be), but a relevance "differentiator". That is one of the drivers of the recent growth in compiled languages (Rust, Go, ...), Not the only one but it helped.
Re: Simple Code, High Performance [video]
#45Re: Simple Code, High Performance [video]
#46Earlier quoted context omitted.
> 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…
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 yourself. However you need to write far more code than one-liners to reimplements those features, not to mention the time it you'd take your team to test, validate, and maintain it.
Therefore, contrary to your initial assumption, there is indeed a tradeoff between reusing someone else's general-purpose but battle-hardened code with your specialized, lean, but untested code, and the cost to go with rolling our own implementation hardly justifies the potential performance gains.
Re: Simple Code, High Performance [video]
#47I wonder how much performance is gained by having the code written by just one person. At work we have a reasonably large (16 MLOC) codebase. At this point I don't think it's possible for one person to do everything, especially while adding new features. So what we do is that we create relatively clean interfaces, and have people code mostly inside those interfaces. But every time we go through one of those interfaces, there's a performance hit.
Re: Simple Code, High Performance [video]
#48Earlier quoted context omitted.
> 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…
This has been the prevailing mentality in the industry for a long time, being essentially a business dogma in IT since the 90s (for a good reasons, as you explained). I think Java is the personification of this concept (more specifically idiomatic corporate Java from the 00s). But there is a recent small change of winds, where management is realising that being faster than the competition can have some business merit…
> That is one of the drivers of the recent growth in compiled languages (Rust, Go, ...), Not the only one but it helped.
No, not really. In either case (rust, Go) perfomance is at best a nice-to-have, while their main value proposition is, and has always been, turnaround time and consequently man*hours. Rust is marketed primarily due to their first-class support for safe programming constructs, and providing a far better developer experience over C and C++ at the expense of a small but negligible performance impact. Go is marketed primarily for it's first-class support for concurrency, and provide a far better developer experience than Java, C#, and C++ with little to no performance gains at all.
What matters is how long it takes developers to add value. That's it. Most of the times there is simply no value to be gained by shaving a megabyte or millisecond here or there, but undoubtedly there is value in shipping features, not having downtime, and eliminating bugs.
Re: Simple Code, High Performance [video]
#49That's exactly how i managed to enhance the performance of my site. https://vashishthakapoor.com/
Keeping the features along with performance is a big challenge. Video is really explainatory to fix performance issues.
Re: Simple Code, High Performance [video]
#50I 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…
> Performance is meaningless once it's good enough.
There is no level of performance that is "good enough". One person's "good enough" is another person's "pain to use" and it's someone else's "I can't buy that computer that I would like because it will not run this software well". Faster software means more options for the consumer, less energy usage and it will be easier to make computers because they don't have to be crazy fast.
I have a computer that is not one of the fastest in the world. I love this computer. It's tiny, beautiful and silent (no fans). When using this computer I can clearly see how slow a lot of software is. It's not the computer that is slow because it's definitely possible to write software that runs really fast on this computer.
One thing that programmers can do to make the situation better is to underclock your CPU when testing your software. On Linux this is very easy; just write the value "800000" to the files that match "/sys/bus/cpu/devices/cpu*/cpufreq/scaling_max_freq". Now your CPU will run no faster than 800Mhz. This will help you to notice when your program gets slow much earlier. And if you then think the performance is "good enough", it's very likely that your users will think so too because most people have a CPU that runs faster than 800MHz.