12 ms·

The implicit premise of the article seems to be that all software has to be heavily optimized. This is completely wrong. All the languages mentioned in the arti

by jupp0r 6y ago

The implicit premise of the article seems to be that all software has to be heavily optimized. This is completely wrong. All the languages mentioned in the article are still around because it doesn’t matter how performant 99% of code is. For the 1%, we can think about cache misses, SIMD and data parallel approaches. In my experience this is totally possible and not too hard, but has the enormous downside of making that code hard to reason about. You are also optimizing for today’s hardware, which means that it might not run that great on new hardware in 20 years. This means that somebody has to go in and rewrite that hard to understand optimized code. It’s really a tradeoff between the cost of that and the benefits from optimization. Some of the future costs can be mitigated by using a few techniques from the start. One good idea is to keep an vanilla unoptimized version of the part that you are optimizing around as a reference implementation. This will help understanding what the optimized code does and can be used as a stopgap to support new hardware. It can also be a nice baseline to compare optimizations against. The beauty of compilers is that they do a decent job of optimizing the 99% of code that would otherwise never be optimized, at 0 cost. This is a different sweet spot on the cost benefit curve.

esailija 6y ago
I disagree. Almost all software I use these days is absurdly slower than it should be and probably a massive drain on collective productivity. I have ssd, fast internet, 64gb ddr4 etc, almost everything I do should be impercetibly instant but instead takes seconds and even minutes. Yeah of course most of that slowness is not even because of ignorance of the low level stuff but complete disregard of performance aspect of software. If it's even slightly more convenient for a programmer to do something that is very stupid performance wise, they will do it. Sure developer time costs, but this cannot actually be the reason. Because tooling is also ridiculously slow in exactly same way and wastes countless of hours of that costly developer time.
- einpoklum 6y ago
  You're both right - but about different kinds of software. I believe the GP post was thinking an application which has some heavy computational kernel to it, where most of the processor time (and other resources) are spent - with a lot of other code for UI, configuration, some parsing etc. And you seem to be talking about everyday desktop applications: Browser, mail client, word processor, instant messaging client, and maybe even your IDE as a programmer. Those kind of apps don't have that kernel of hard computational work - their work is much more diffuse.
  - jupp0r 6y ago
    I spent years optimizing physics simulations from different domains (weather, fluid dynamics, all sorts of stuff). Even there you have to carefully pick the parts you want to optimize to get the best outcome for the resources you invest in optimization. It's completely infeasible to make everything crazy fast with a blanket approach.
    - klyrs 6y ago
      You're speaking directly past your parent's point. I've spent years optimizing physics simulations, more abstract discrete math stuff, etc. myself. There, especially there, it's usually pretty easy to identify what should be the hot loop, by eye. Easier with a profiler if the project gets big. In scientific computing, it's very common to find that 99% of the time is spent on a scant few lines of code. Unless somebody bungs up the I/O and you end up spending 99% of the time there instead, but I digress. But a whole OS, with a browser, network stack, dozens of applcations, etc., it's pretty common to find hundreds or thousands of things which are all more or less equally sucking performance. So on one hand, it's a much harder problem. On the other hand, front-end people have this attitude that performance doesn't matter because hardware is fast enough and it's better to write in the most abstract language possible because changing diapers makes your hands smell gross.
- 29athrowaway 6y ago
  Shit is slower than it was in the 90s. Spotify is slower than Winamp, Slack is slower than IRC, Webmail is slower than my e-mail client, VS Code is slower than Visual C++ 6.0.
  - corysama 6y ago
    People forget that Winamp was instant on a 60Mhz machine with a spinning rust drive. It’s difficult to buy a computer that slow these days. Modern CPUs modulate their speeds by far more than that as part of their moment by moment power management!
    - fiddlerwoaroof 6y ago
      Related: when MacBooks switched to SSDs, the performance of my old spinning-disk MBP dropped noticeably basically overnight.
      - Narishma 6y ago
        Same thing on Windows. It became incredibly slow on HDDs when SSDs started to become popular.
        cassepipe 6y ago
        Having an Hdd running at 100% on Windows 8, slowing everything down, is actually what made me switch to Linux Mint. Never looked back.
        selfhoster11 6y ago
        When I first bought an SSD and noticed the crazy speed-up, my next thought was that developers will get used to it as the "new normal" and stop caring about IOPS which would slow down SSDs (ruining my blink-of-an-eye super-speed fun) and make HDDs near-unusable. Two to four years later, here we were on Windows, and to some extent, on Linux too.
        jdsully 6y ago
- jupp0r 6y ago
  Do you use browsers? Browser makers spend billions of dollars in engineering time making them "fast", with great results.
  - sudosysgen 6y ago
    Browsers are fast, but the content they render is very slow.
    - fiddlerwoaroof 6y ago
      These are related: the faster the browser and the typical internet connection is, the bigger sites will be (absent some force to prevent developers from spending the entirety of the new performance budget.)
    - bogdanoff_2 6y ago
      Reminds me of the "paradox" that making technology more energy-efficient has the effect of increasing overall energy use.
      - CalChris 6y ago
        Jevon’s paradox https://en.m.wikipedia.org/wiki/Jevons_paradox#Khazzoom–Brookes_postulate https://en.m.wikipedia.org/wiki/Jevons_paradox#Khazzoom–Broo...
  - klyrs 6y ago
    Do you use websites? Because developers unthinkingly pull in billions of dependencies, making them "features", with horrific results. And fast is one aspect of performance. What's the memory footprint?
  - Silhouette 6y ago
    And yet developers working on front-end code to run in those browsers are waiting seconds for their linter or test suite or transpiler to process a few thousand lines of JS code, on a modern PC. Not a few million lines, a few thousand. That is orders of magnitude slower than it should be, and it's a cost that hits huge numbers of developers many times every day. Quite often, that awful performance is because the slow tools are written in a certain language also used in those "fast" browsers, and far too many developers are still giving this a pass because they incorrectly assume some magical runtime and JIT will make up for using a language that was never designed for high performance work and writing large, complicated programs.
- quadcore 6y ago
  I dont know if you've noticed, but most programmers actually do care about performances. They just are bad at it. Software are slow precisely because programmers dont get it: optimising all the code will make slow software. They spend their budget optimising 99% of the code and end up with no more money to make that last 1% fast. For real (game engine programmer speaking). Plus optimising all the code make all the code unreadable which drains even more money from budget. Just as OP said.
  - astrange 6y ago
    Usually simpler code is better. I used to see a lot of mistaken "high performance" code where someone has unrolled all of the loops because they think unreadable code goes faster, though maybe people have gotten better about this? (OpenSSL is an example here.) Unfortunately not all kinds of slowness only happen in hotspots. This is true for CPU cycles, but if an occasional task uses all memory, it's going to mess up everything downstream as well.
    - Sohcahtoa82 6y ago
      I wonder where the trade-off is for loop unrolling. Like, unrolling a `for` loop that only has 5 iterations makes sense. But if you have 100 iterations, then the larger memory footprint of all the code might actually make it slower than just keeping the `for` loop. In some cases, you can use Duff's Device. https://en.wikipedia.org/wiki/Duff%27s_device https://en.wikipedia.org/wiki/Duff%27s_device
  - selfhoster11 6y ago
    > I dont know if you've noticed, but most programmers actually do care about performances. They just are bad at it. I disagree. Programmers may care about performance, but project managers certainly don't and they always have the final say.
    - tonyarkles 6y ago
      I’m with both of you and I don’t think what you two are saying is mutually exclusive. I’m kind of a performance nut (often working with teams, I’m the guy that introduces everyone to a profiler) and, in my N=small experience, PMs are opposed to spending time on performance optimization precisely because most people are bad at it and it takes an undefined amount of time for unknown performance gains. When I take an hour to profile and analyze some request and say “I think we can cut this thing’s response time by 80% by optimizing $X, which will result in an overall page load time reduction of 3s”, that’s way easier to sell than “I want to figure out why this page load is so slow” and then reporting back a week later with “shrug I optimized 5 things and it didn’t get faster. Dunno.”
- 8note 6y ago
  Most performance concerns that I run into are related to advertisements that need to load. The business model isn't right for performant experiences
  - GuB-42 6y ago
    Faster = more ad revenue. If your app/site is too slow, people will stop using it and won't see your ads. Also, search engines will detect that and downrank you, meaning even less ad impressions. It has been studied many times, and yet, developers don't do it. Simply, performance is expensive and for most businesses, the additional revenue is not worth the additional expense.
- toast0 6y ago
  > I disagree. Almost all software I use these days is absurdly slower than it should be and probably a massive drain on collective productivity. This is absolutely true, but the problem is usually a lack of due care about performance at higher levels, rather than low level optimization. Things are usually slow because they do entirely too much of the wrong things, than because nobody optimized the things, or the wrong registers were used or what not.
  - edenhyacinth 6y ago
    The article presents the case that writing code with a specific style - OOP compared to Data Oriented - is responsible for slowing down performance. That code architecture is primarily the cause, regardless of the actual implementation, because some architectures will never work well with the compiler. I get that like the major parts of picking algorithms that are N over N^2 is always going to be more important, but it doesn't seem like the article is disagreeing with you at all, just another area where people need to consider their decisions.
    - kaba0 6y ago
      But only a strict subset of problems are heavily data oriented. For your 3 button GUI app whether you use a tightly packed AoS, even SoA doesn’t matter over a slow linked list of pointers for that 3 element list implementation doesn’t matter. And OOP is simply not contradictory to DOD.
      - toast0 6y ago
        (Agreeing) The 3 button GUI app is much more likely to be/feel slow because the UI framework used makes it difficult to get the widgets on the screen quickly than because of data processing. Maybe it insists on a deep heirarchy of widget inheritence as many do. Maybe the framework wants to load and configure all the possible widgets, even though the application only uses a few. Maybe theres a bunch of images loaded from disk even though they're not used. Maybe it's just the fantastic default compositing system that puts everything a frame behind adding up with everything else. There certainly are applications where data structures matter, and time spent processing data is significant to user experience, but that's not why the whole computing experience feels slower (although maybe prettier) than 25 years ago, despite capability being so much more for most things (as pointed out in the article, ram is better than years ago, and we certainly have more of it, but ram access takes a lot more cpu cycles now)
- WrtCdEvrydy 6y ago
  > Sure developer time costs, but this cannot actually be the reason. It totally is because we've abstracted the cost of software engineering unto the hardware. Back in the 90s, people had to basically beg for memory when writing software while modern development is built on the theory of getting the fastest delivery speed at the cost of performance. We outsource the cost of software unto millions of customer's hardware and it's never coming back because going to market quick makes you money.
  - Olreich 6y ago
    The point stands anyway. Why are all my dev tools super slow? If my time is important, shouldn’t those be fast and heavily optimized? And don’t try to tell me that 4 billion cycles a second across 16 cores operating on in-memory contiguous values isn’t enough to update a watch window more than 1 time per second.
    - WrtCdEvrydy 6y ago
      > Why are all my dev tools super slow? If my time is important, Quantify important into how much you spend on your tooling. Aside from some key bits of development software at the IC / board layout, almost everything a software developer needs is free, open source or cheap. Noone pays $1000 for an IDE anymore.
      - harry8 6y ago
        > Noone pays $1000 for an IDE anymore. How many minutes per developer per day before that level of expenditure pays for itself inside 2-3 months? Who cares? The premise is false, you can't buy it. There is no "fast tools" you pay for. Every decent shop got their devs an SSD at the first available opportunity because it paid for itself really quickly, cost you money _not_ to buy them. The very definition of a false economy was "no the devs aren't getting new shiny sportsmode SSDs for their boxes." We all use gcc and clang (for relevant languages), for example because everything else you might pay for sucks a lot harder. Whatever the ideology you claim or deny. Intel literally damaged their customers' products to try to make themselves look better than AMD with theirs! They're a non-starter after showing themselves willing to do that but if you must, yes, their compilers still suck exclusively on intel more than gcc. How is microsoft's compilers standards chasing going? In the 21st century yet or /still/ not? (Oh come one, we're mostly there but for ... yeah). Compiling template heavy C++? Does developer time matter? (But just quietly, terminals & cmdline tools feel a lot more productive than IDEs to me and I use both in differing circumstances).
- jayd16 6y ago
  I think you missed the point. Parent is saying that without compiler optimization everything would be even slower.
- goatinaboat 6y ago
  Almost all software I use these days is absurdly slower than it should be and probably a massive drain on collective productivity Productivity, energy usage, e-waste in landfill as people are forced to upgrade in order to do simple tasks with the current software... The world is paying a high price for programmer laziness.
  - city41 6y ago
    Is it programmer laziness, or insane demand for software due to many factors, mostly profit?
    - goatinaboat 6y ago
      Is it programmer laziness, or insane demand for software due to many factors, mostly profit? There's insane demand for games, and those programmers are able to optimise their code, insane demand for trading software and those programmers are able to optimise their code. But webdevs just don't care. I look at pages now that do nothing more in functionality than the same app would have done 20 years ago, yet they are slower now, and I have literally 1000x more CPU power. It's insane.
      - city41 6y ago
        Optimized games have a well known impact on sales. I'd assume the same with trading software. Putting out a blanket statement that web devs are lazy is just silly. Developers rarely have much say in how much time they can dedicate to features and the app as a whole, that usually boils down to PMs and management. If the org as a whole doesn't value performance or doesn't think it matters, then that will get reflected in the product regardless of what the developers actually want.
- kaba0 6y ago
  I disagree that everything would be slow. Yeah, there are websites with so many JS bloat that they can make the fans start up in my laptop, but otherwise, your computer does a shitton of things, most of which is essential complexity. To-the-point software is actually really fast, like gcc/clang does tons of optimizations compared to what compilers did a few decades ago, and I doubt you could realistically optimize it by a significant percentage in the general case. Same for databases. Browsers themselves are also pushing the boundaries of hardware, they can display static HTML/CSS ridiculously fast even though it is not ideal for layouting. Pretty much only the top of the abstractions “suck” sometimes, but there are really fast JS apps as well.
noobermin 6y ago
This attitude is very common and has clearly degraded software development particularly for users, and like most issues afflicting modern software it's not perceived by developers so it "doesn't exist" to them. As the top reply to this mentioned, anyone can easily tell how much slower software is today even when computers and devices are so fast now! All in the name of "making code easy to reason about." I have news for you, all code is difficult to reason about at some level. Sure, certain abstracts can be easier to reason about than others if you take certain examples that I can generally argue are reductionist, but any reasonably well developed piece of code (read, actual useful code) will require a certain level of sophistication and complexity that will eventually make it difficult to reason about. I know this is a reach and a bit of a red-herring, but developers really really need to remember the allergy to "code being difficult to reason about" is a sometimes a useful intuition or heuristic to use, the heuristic being "easier to reason about is better," but it really is a heuristic at the end of the day. Abuse of this heuristic is often a motive behind all sorts of detrimental behaviors in tech, reinventing the wheel and NIH (I didn't write, it, so it's difficult to reason about!), rewrites from scratch (our "technical debt" is now hard to reason about, let's rewrite from scratch!) and the problem OP refers to (a solution that maps to the machine better is hard to reason about, let's use this less efficient solution instead!). And a big problem here is that these issues are often not issues to hackers because it just means more programming for them which they love! It just hurts users and customers.
- 8fGTBjZxBcHq 6y ago
  I think other users in here are more on the right track about where the blame for this lies. As you alluded to, a lot of programmers are happy to tweak and refine for ages so it's probably not that. Is it just that programmers are lazy or need to care more or be better educated about optimization? Honestly I really doubt it. I fully agree with the other takes that companies have incentives to ship working software quickly. Features sell subscriptions not performance. If it comes down to choosing between functionality and performance leaders will ship the slow feature every time. I'm not even sure they're necessarily wrong most of the time. If you know where to look the internet is a graveyard of carefully engineered products that were beat to market and obliterated by three people with a shitty electron app.
bobcostas55 6y ago
This is exactly how we ended up with someone charging you $50/month to run a browser on a supercomputer.
dahart 6y ago
> All the languages mentioned in the article are still around because it doesn’t matter how performant 99% of code is. It’s worth challenging this assumption and asking whether it’s really true, or whether this belief is old and outdated like the old languages. I’m certain that providers of compute infrastructure like Amazon, Microsoft, Google and others completely disagree that performance doesn’t matter. Letting slow code run literally costs them money because it prevents multiple people from being able to use the same hardware resource. Even on your own machine, slow processes hog resources that other processes could use. The reason my laptop fans keep spinning up in Windows while my machine is basically idle is due to hundreds of processes written by people who erroneously believe the performance of 99% of the code doesn’t matter. We’re also at a point where we’ve started to measure the energy efficiency and environmental impact of wasting compute cycles. So, performance always matters. > For the 1%, we can think about cache misses [...] but that has the enormous downside of making code hard to reason about. You’re agreeing with the author here. Maybe you missed the explicit point in the in the article that is calling for a language that makes basic cache awareness a first class citizen, precisely so that it’s easier to reason about? “This is exactly the type of problem that should be solved via the features of our programming languages, since writing these custom sorting functions is very tedious. What if a programming language would provide us with a structure that would act like an array of structs, but internally it would really behave like a struct of arrays? We could program in the typical object oriented way that is convenient for humans, while still enjoying in great performance due to playing nice with the hardware.” > You are also optimizing for today’s hardware, which means that it might not run that great on new hardware in 20 years. For the last 20 years, the need to be cache-aware has increased in importance. For the next 20 years, the gap between memory and compute will get larger still. There’s no scenario on the horizon where we don’t have to become more memory conscious as programmers or use more memory conscious languages and tools. There aren’t many performance tricks and concepts that worked 20 years ago and don’t work today. Using a structure of arrays (SoA) instead of an array of structures (AoS) has long been and will continue to be a good idea.
- kaba0 6y ago
  Feel free to profile a high-profile application. It is almost always a few hotspots that “suck”. There are rare cases where there is no one point that is slow, that’s a bad situation to find oneself in — it usually means that the base architecture/abstraction sucks and needs a big refactor. But even in so low-level code as the linux kernel, you see the use of linked lists all the time. Because it simply doesn’t matter if you are not in a hot loop and iterate slowly over 3 elements.
aspaceman 6y ago
High performing code doesn’t have to be hard to reason about. You wouldn’t say the plan for a safer building is harder to read. People excusing their poorly written code as “highly-optimized” is the oldest cop-out we’ve got as programmers.
lumost 6y ago
I generally only observe value in application code optimizing for correct data structures/batching/data parallelism. Once you're getting into fine tuning the batch size/SimD ops for a particular platform you are quickly into the realm of diminished ROI due to fragility against changing hardware, application usage patterns, and diminished returns where dropping an op from 1 microsecond to 10 nanoseconds just doesn't matter as much. There are cases at the tail where this will make or break a project, but those are pretty rare.
desperate 6y ago
Slightly off topic but I just realized that not only does optimized code = less processor cycles but less cycles = less power used. This brings two rhetorical questions, How much more effective compute would we have if all code running today were perfectly optimized, and how much less energy would be needed under the same circumstances? The computer gains could only be used in networks where unused compute can be scheduled / sold to other tasks. The energy gains could only be reaped if processors had proper low power modes they could fall into or some other method of conservation.

by jupp0r 6y ago

esailija 6y ago

I disagree. Almost all software I use these days is absurdly slower than it should be and probably a massive drain on collective productivity. I have ssd, fast internet, 64gb ddr4 etc, almost everything I do should be impercetibly instant but instead takes seconds and even minutes. Yeah of course most of that slowness is not even because of ignorance of the low level stuff but complete disregard of performance aspect of software. If it's even slightly more convenient for a programmer to do something that is very stupid performance wise, they will do it. Sure developer time costs, but this cannot actually be the reason. Because tooling is also ridiculously slow in exactly same way and wastes countless of hours of that costly developer time.

einpoklum 6y ago
You're both right - but about different kinds of software. I believe the GP post was thinking an application which has some heavy computational kernel to it, where most of the processor time (and other resources) are spent - with a lot of other code for UI, configuration, some parsing etc. And you seem to be talking about everyday desktop applications: Browser, mail client, word processor, instant messaging client, and maybe even your IDE as a programmer. Those kind of apps don't have that kernel of hard computational work - their work is much more diffuse.
- jupp0r 6y ago
  I spent years optimizing physics simulations from different domains (weather, fluid dynamics, all sorts of stuff). Even there you have to carefully pick the parts you want to optimize to get the best outcome for the resources you invest in optimization. It's completely infeasible to make everything crazy fast with a blanket approach.
  - klyrs 6y ago
    You're speaking directly past your parent's point. I've spent years optimizing physics simulations, more abstract discrete math stuff, etc. myself. There, especially there, it's usually pretty easy to identify what should be the hot loop, by eye. Easier with a profiler if the project gets big. In scientific computing, it's very common to find that 99% of the time is spent on a scant few lines of code. Unless somebody bungs up the I/O and you end up spending 99% of the time there instead, but I digress. But a whole OS, with a browser, network stack, dozens of applcations, etc., it's pretty common to find hundreds or thousands of things which are all more or less equally sucking performance. So on one hand, it's a much harder problem. On the other hand, front-end people have this attitude that performance doesn't matter because hardware is fast enough and it's better to write in the most abstract language possible because changing diapers makes your hands smell gross.
29athrowaway 6y ago
Shit is slower than it was in the 90s. Spotify is slower than Winamp, Slack is slower than IRC, Webmail is slower than my e-mail client, VS Code is slower than Visual C++ 6.0.
- corysama 6y ago
  People forget that Winamp was instant on a 60Mhz machine with a spinning rust drive. It’s difficult to buy a computer that slow these days. Modern CPUs modulate their speeds by far more than that as part of their moment by moment power management!
  - fiddlerwoaroof 6y ago
    Related: when MacBooks switched to SSDs, the performance of my old spinning-disk MBP dropped noticeably basically overnight.
    - Narishma 6y ago
      Same thing on Windows. It became incredibly slow on HDDs when SSDs started to become popular.
      - cassepipe 6y ago
        Having an Hdd running at 100% on Windows 8, slowing everything down, is actually what made me switch to Linux Mint. Never looked back.
      - selfhoster11 6y ago
        When I first bought an SSD and noticed the crazy speed-up, my next thought was that developers will get used to it as the "new normal" and stop caring about IOPS which would slow down SSDs (ruining my blink-of-an-eye super-speed fun) and make HDDs near-unusable. Two to four years later, here we were on Windows, and to some extent, on Linux too.
      - jdsully 6y ago
jupp0r 6y ago
Do you use browsers? Browser makers spend billions of dollars in engineering time making them "fast", with great results.
- sudosysgen 6y ago
  Browsers are fast, but the content they render is very slow.
  - fiddlerwoaroof 6y ago
    These are related: the faster the browser and the typical internet connection is, the bigger sites will be (absent some force to prevent developers from spending the entirety of the new performance budget.)
  - bogdanoff_2 6y ago
    Reminds me of the "paradox" that making technology more energy-efficient has the effect of increasing overall energy use.
    - CalChris 6y ago
      Jevon’s paradox https://en.m.wikipedia.org/wiki/Jevons_paradox#Khazzoom–Brookes_postulate https://en.m.wikipedia.org/wiki/Jevons_paradox#Khazzoom–Broo...
- klyrs 6y ago
  Do you use websites? Because developers unthinkingly pull in billions of dependencies, making them "features", with horrific results. And fast is one aspect of performance. What's the memory footprint?
- Silhouette 6y ago
  And yet developers working on front-end code to run in those browsers are waiting seconds for their linter or test suite or transpiler to process a few thousand lines of JS code, on a modern PC. Not a few million lines, a few thousand. That is orders of magnitude slower than it should be, and it's a cost that hits huge numbers of developers many times every day. Quite often, that awful performance is because the slow tools are written in a certain language also used in those "fast" browsers, and far too many developers are still giving this a pass because they incorrectly assume some magical runtime and JIT will make up for using a language that was never designed for high performance work and writing large, complicated programs.
quadcore 6y ago
I dont know if you've noticed, but most programmers actually do care about performances. They just are bad at it. Software are slow precisely because programmers dont get it: optimising all the code will make slow software. They spend their budget optimising 99% of the code and end up with no more money to make that last 1% fast. For real (game engine programmer speaking). Plus optimising all the code make all the code unreadable which drains even more money from budget. Just as OP said.
- astrange 6y ago
  Usually simpler code is better. I used to see a lot of mistaken "high performance" code where someone has unrolled all of the loops because they think unreadable code goes faster, though maybe people have gotten better about this? (OpenSSL is an example here.) Unfortunately not all kinds of slowness only happen in hotspots. This is true for CPU cycles, but if an occasional task uses all memory, it's going to mess up everything downstream as well.
  - Sohcahtoa82 6y ago
    I wonder where the trade-off is for loop unrolling. Like, unrolling a `for` loop that only has 5 iterations makes sense. But if you have 100 iterations, then the larger memory footprint of all the code might actually make it slower than just keeping the `for` loop. In some cases, you can use Duff's Device. https://en.wikipedia.org/wiki/Duff%27s_device https://en.wikipedia.org/wiki/Duff%27s_device
- selfhoster11 6y ago
  > I dont know if you've noticed, but most programmers actually do care about performances. They just are bad at it. I disagree. Programmers may care about performance, but project managers certainly don't and they always have the final say.
  - tonyarkles 6y ago
    I’m with both of you and I don’t think what you two are saying is mutually exclusive. I’m kind of a performance nut (often working with teams, I’m the guy that introduces everyone to a profiler) and, in my N=small experience, PMs are opposed to spending time on performance optimization precisely because most people are bad at it and it takes an undefined amount of time for unknown performance gains. When I take an hour to profile and analyze some request and say “I think we can cut this thing’s response time by 80% by optimizing $X, which will result in an overall page load time reduction of 3s”, that’s way easier to sell than “I want to figure out why this page load is so slow” and then reporting back a week later with “shrug I optimized 5 things and it didn’t get faster. Dunno.”
8note 6y ago
Most performance concerns that I run into are related to advertisements that need to load. The business model isn't right for performant experiences
- GuB-42 6y ago
  Faster = more ad revenue. If your app/site is too slow, people will stop using it and won't see your ads. Also, search engines will detect that and downrank you, meaning even less ad impressions. It has been studied many times, and yet, developers don't do it. Simply, performance is expensive and for most businesses, the additional revenue is not worth the additional expense.
toast0 6y ago
> I disagree. Almost all software I use these days is absurdly slower than it should be and probably a massive drain on collective productivity. This is absolutely true, but the problem is usually a lack of due care about performance at higher levels, rather than low level optimization. Things are usually slow because they do entirely too much of the wrong things, than because nobody optimized the things, or the wrong registers were used or what not.
- edenhyacinth 6y ago
  The article presents the case that writing code with a specific style - OOP compared to Data Oriented - is responsible for slowing down performance. That code architecture is primarily the cause, regardless of the actual implementation, because some architectures will never work well with the compiler. I get that like the major parts of picking algorithms that are N over N^2 is always going to be more important, but it doesn't seem like the article is disagreeing with you at all, just another area where people need to consider their decisions.
  - kaba0 6y ago
    But only a strict subset of problems are heavily data oriented. For your 3 button GUI app whether you use a tightly packed AoS, even SoA doesn’t matter over a slow linked list of pointers for that 3 element list implementation doesn’t matter. And OOP is simply not contradictory to DOD.
    - toast0 6y ago
      (Agreeing) The 3 button GUI app is much more likely to be/feel slow because the UI framework used makes it difficult to get the widgets on the screen quickly than because of data processing. Maybe it insists on a deep heirarchy of widget inheritence as many do. Maybe the framework wants to load and configure all the possible widgets, even though the application only uses a few. Maybe theres a bunch of images loaded from disk even though they're not used. Maybe it's just the fantastic default compositing system that puts everything a frame behind adding up with everything else. There certainly are applications where data structures matter, and time spent processing data is significant to user experience, but that's not why the whole computing experience feels slower (although maybe prettier) than 25 years ago, despite capability being so much more for most things (as pointed out in the article, ram is better than years ago, and we certainly have more of it, but ram access takes a lot more cpu cycles now)
WrtCdEvrydy 6y ago
> Sure developer time costs, but this cannot actually be the reason. It totally is because we've abstracted the cost of software engineering unto the hardware. Back in the 90s, people had to basically beg for memory when writing software while modern development is built on the theory of getting the fastest delivery speed at the cost of performance. We outsource the cost of software unto millions of customer's hardware and it's never coming back because going to market quick makes you money.
- Olreich 6y ago
  The point stands anyway. Why are all my dev tools super slow? If my time is important, shouldn’t those be fast and heavily optimized? And don’t try to tell me that 4 billion cycles a second across 16 cores operating on in-memory contiguous values isn’t enough to update a watch window more than 1 time per second.
  - WrtCdEvrydy 6y ago
    > Why are all my dev tools super slow? If my time is important, Quantify important into how much you spend on your tooling. Aside from some key bits of development software at the IC / board layout, almost everything a software developer needs is free, open source or cheap. Noone pays $1000 for an IDE anymore.
    - harry8 6y ago
      > Noone pays $1000 for an IDE anymore. How many minutes per developer per day before that level of expenditure pays for itself inside 2-3 months? Who cares? The premise is false, you can't buy it. There is no "fast tools" you pay for. Every decent shop got their devs an SSD at the first available opportunity because it paid for itself really quickly, cost you money _not_ to buy them. The very definition of a false economy was "no the devs aren't getting new shiny sportsmode SSDs for their boxes." We all use gcc and clang (for relevant languages), for example because everything else you might pay for sucks a lot harder. Whatever the ideology you claim or deny. Intel literally damaged their customers' products to try to make themselves look better than AMD with theirs! They're a non-starter after showing themselves willing to do that but if you must, yes, their compilers still suck exclusively on intel more than gcc. How is microsoft's compilers standards chasing going? In the 21st century yet or /still/ not? (Oh come one, we're mostly there but for ... yeah). Compiling template heavy C++? Does developer time matter? (But just quietly, terminals & cmdline tools feel a lot more productive than IDEs to me and I use both in differing circumstances).
jayd16 6y ago
I think you missed the point. Parent is saying that without compiler optimization everything would be even slower.
goatinaboat 6y ago
Almost all software I use these days is absurdly slower than it should be and probably a massive drain on collective productivity Productivity, energy usage, e-waste in landfill as people are forced to upgrade in order to do simple tasks with the current software... The world is paying a high price for programmer laziness.
- city41 6y ago
  Is it programmer laziness, or insane demand for software due to many factors, mostly profit?
  - goatinaboat 6y ago
    Is it programmer laziness, or insane demand for software due to many factors, mostly profit? There's insane demand for games, and those programmers are able to optimise their code, insane demand for trading software and those programmers are able to optimise their code. But webdevs just don't care. I look at pages now that do nothing more in functionality than the same app would have done 20 years ago, yet they are slower now, and I have literally 1000x more CPU power. It's insane.
    - city41 6y ago
      Optimized games have a well known impact on sales. I'd assume the same with trading software. Putting out a blanket statement that web devs are lazy is just silly. Developers rarely have much say in how much time they can dedicate to features and the app as a whole, that usually boils down to PMs and management. If the org as a whole doesn't value performance or doesn't think it matters, then that will get reflected in the product regardless of what the developers actually want.
kaba0 6y ago
I disagree that everything would be slow. Yeah, there are websites with so many JS bloat that they can make the fans start up in my laptop, but otherwise, your computer does a shitton of things, most of which is essential complexity. To-the-point software is actually really fast, like gcc/clang does tons of optimizations compared to what compilers did a few decades ago, and I doubt you could realistically optimize it by a significant percentage in the general case. Same for databases. Browsers themselves are also pushing the boundaries of hardware, they can display static HTML/CSS ridiculously fast even though it is not ideal for layouting. Pretty much only the top of the abstractions “suck” sometimes, but there are really fast JS apps as well.

noobermin 6y ago

This attitude is very common and has clearly degraded software development particularly for users, and like most issues afflicting modern software it's not perceived by developers so it "doesn't exist" to them. As the top reply to this mentioned, anyone can easily tell how much slower software is today even when computers and devices are so fast now! All in the name of "making code easy to reason about." I have news for you, all code is difficult to reason about at some level. Sure, certain abstracts can be easier to reason about than others if you take certain examples that I can generally argue are reductionist, but any reasonably well developed piece of code (read, actual useful code) will require a certain level of sophistication and complexity that will eventually make it difficult to reason about. I know this is a reach and a bit of a red-herring, but developers really really need to remember the allergy to "code being difficult to reason about" is a sometimes a useful intuition or heuristic to use, the heuristic being "easier to reason about is better," but it really is a heuristic at the end of the day. Abuse of this heuristic is often a motive behind all sorts of detrimental behaviors in tech, reinventing the wheel and NIH (I didn't write, it, so it's difficult to reason about!), rewrites from scratch (our "technical debt" is now hard to reason about, let's rewrite from scratch!) and the problem OP refers to (a solution that maps to the machine better is hard to reason about, let's use this less efficient solution instead!). And a big problem here is that these issues are often not issues to hackers because it just means more programming for them which they love! It just hurts users and customers.

8fGTBjZxBcHq 6y ago
I think other users in here are more on the right track about where the blame for this lies. As you alluded to, a lot of programmers are happy to tweak and refine for ages so it's probably not that. Is it just that programmers are lazy or need to care more or be better educated about optimization? Honestly I really doubt it. I fully agree with the other takes that companies have incentives to ship working software quickly. Features sell subscriptions not performance. If it comes down to choosing between functionality and performance leaders will ship the slow feature every time. I'm not even sure they're necessarily wrong most of the time. If you know where to look the internet is a graveyard of carefully engineered products that were beat to market and obliterated by three people with a shitty electron app.

bobcostas55 6y ago

This is exactly how we ended up with someone charging you $50/month to run a browser on a supercomputer.

dahart 6y ago

> All the languages mentioned in the article are still around because it doesn’t matter how performant 99% of code is. It’s worth challenging this assumption and asking whether it’s really true, or whether this belief is old and outdated like the old languages. I’m certain that providers of compute infrastructure like Amazon, Microsoft, Google and others completely disagree that performance doesn’t matter. Letting slow code run literally costs them money because it prevents multiple people from being able to use the same hardware resource. Even on your own machine, slow processes hog resources that other processes could use. The reason my laptop fans keep spinning up in Windows while my machine is basically idle is due to hundreds of processes written by people who erroneously believe the performance of 99% of the code doesn’t matter. We’re also at a point where we’ve started to measure the energy efficiency and environmental impact of wasting compute cycles. So, performance always matters. > For the 1%, we can think about cache misses [...] but that has the enormous downside of making code hard to reason about. You’re agreeing with the author here. Maybe you missed the explicit point in the in the article that is calling for a language that makes basic cache awareness a first class citizen, precisely so that it’s easier to reason about? “This is exactly the type of problem that should be solved via the features of our programming languages, since writing these custom sorting functions is very tedious. What if a programming language would provide us with a structure that would act like an array of structs, but internally it would really behave like a struct of arrays? We could program in the typical object oriented way that is convenient for humans, while still enjoying in great performance due to playing nice with the hardware.” > You are also optimizing for today’s hardware, which means that it might not run that great on new hardware in 20 years. For the last 20 years, the need to be cache-aware has increased in importance. For the next 20 years, the gap between memory and compute will get larger still. There’s no scenario on the horizon where we don’t have to become more memory conscious as programmers or use more memory conscious languages and tools. There aren’t many performance tricks and concepts that worked 20 years ago and don’t work today. Using a structure of arrays (SoA) instead of an array of structures (AoS) has long been and will continue to be a good idea.

kaba0 6y ago
Feel free to profile a high-profile application. It is almost always a few hotspots that “suck”. There are rare cases where there is no one point that is slow, that’s a bad situation to find oneself in — it usually means that the base architecture/abstraction sucks and needs a big refactor. But even in so low-level code as the linux kernel, you see the use of linked lists all the time. Because it simply doesn’t matter if you are not in a hot loop and iterate slowly over 3 elements.

aspaceman 6y ago

High performing code doesn’t have to be hard to reason about. You wouldn’t say the plan for a safer building is harder to read. People excusing their poorly written code as “highly-optimized” is the oldest cop-out we’ve got as programmers.

lumost 6y ago

I generally only observe value in application code optimizing for correct data structures/batching/data parallelism. Once you're getting into fine tuning the batch size/SimD ops for a particular platform you are quickly into the realm of diminished ROI due to fragility against changing hardware, application usage patterns, and diminished returns where dropping an op from 1 microsecond to 10 nanoseconds just doesn't matter as much. There are cases at the tail where this will make or break a project, but those are pretty rare.

desperate 6y ago

Slightly off topic but I just realized that not only does optimized code = less processor cycles but less cycles = less power used. This brings two rhetorical questions, How much more effective compute would we have if all code running today were perfectly optimized, and how much less energy would be needed under the same circumstances? The computer gains could only be used in networks where unused compute can be scheduled / sold to other tasks. The energy gains could only be reaped if processors had proper low power modes they could fall into or some other method of conservation.