5 ms·

software authors that don't care about performance annoy me (and I am an old man.) The amount of things a computer can do in a single thread are amazing, and c

software authors that don't care about performance annoy me (and I am an old man.) The amount of things a computer can do in a single thread are amazing, and computers now have a dozen or more threads to do work. If developers cared about performance, things would easily be 20x as performant as they are today. I'm not talking about "write in assembly, duh" I'm talking about just doing things intelligently instead of naively. The developers I support often simply are not thinking about the problem they're solving and they solve the problem in the simplest way (for them) and not the simplest way for a computer. Software is an inefficiency amplifier, because the number of developers for a piece of code is much smaller than the number of computers that run that code; how much coal has been burned solely because of shitty implementations? I'd wager that the answer is "a LOT!" Even if you don't care about coal usage, think about how much happier your users would be if your application was suddenly 5x faster than it was previously? now think of how many customers want their software to be slow (outside of TheDailyWTF): zero. languages like javascript and python remove you so much from the CPU and the cache that even if you were thinking of those things, you can't do anything about it. JS and Electron are great for developers, and horrible for users because of that amplification I described above. I am dead tired of seeing hustle culture overtake everything in this field, and important things, to me, like quality and performance and support all fall straight down the toilet simply because executives want to release features faster. things like copilot could help with this, i hope. presumably copilot will help introduce better code into applications than a daydreaming developer would, though the existence of vibe coding sort of nulls that out probably. one thing that AI will do quite soon is increase the amount of software that exists quite dramatically. and I am kinda concerned about the possibility that it's all going to suck horribly.

ralphc 1y ago
What's your proposal for a "compromise" language between programmer productivity and performance, especially for multiple threads and CPUs? Go, Rust, a BEAM language?
- t917910 1y ago
  [flagged]
- naikrovek 1y ago
  Jai seems to be an excellent start. Possibly Zig as well. Both are written/designed by people who care a lot about application performance and developer experience.
  - teg4n_ 1y ago
    This is an unserious take. Jai doesn’t even have official documentation and zig hasn’t reached a 1.0 release
    - naikrovek 1y ago
      I wasn't asked for examples of software that is congruent to whatever definition you want. I was asked for a proposal of a "compromise" language, and I answered that question.
- Voultapher 1y ago
  I don't think the tools are the issue here, they are tools you can do good and bad jobs with all of them. What is lacking are the right incentives. The tech market has never been as anti-competitive as it is today. Let's repeal DMCA 1201 and go from there.
colonial 1y ago
> presumably copilot will help introduce better code into applications than a daydreaming developer would Copilot is trained on Github (and probably other Git forges w/o permission, because OpenAI and Microsoft are run by greedy sociopaths.) I'd wager that the majority of fleshed out repositories on these sites contain projects written at the "too-high level" you describe. This certainly seems to be true based on how these models perform ("good" results for web development and scripting, awful results for C/++/Rust/assembly...) - so I wouldn't get your hopes up, unfortunately.
- tough 1y ago
  I dont know if its just the training data, or that CRUD and webapps are more inherently easy to parrot away. Low level programming means actual -thinking- about the system, resources, and language decisions etc Even humans struggle with it, Its much easier to build a website than say a compiler, for anyone, humans and llm's included
  - colonial 1y ago
    That probably plays into it as well. I have yet to see any convincing evidence that contradicts LLMs being mere pattern parrots. My personal benchmark for these models is writing a simple socket BPF in a Rust program. Even the latest and greatest hosted frontier models (with web search and reasoning enabled!) can only ape the structure. The substance is inevitably wanting, with invalid BPF instructions and hallucinated/missing imports.
    - tough 1y ago
      imho these tools are great i fyou know what you're doing, becasue you know how to smell test the output, but a footgun otherwise. It works great for me, but it is necessarily an aid learning tool more than a full on replacement, someone's still gotta do the thinking part, even if the llm's can cosplay -reasoning- now
njarboe 1y ago
My standard is that software should appear to work instantly to me, a human. Then it is fast enough. No pressing a button and waiting. That would be great.
- naikrovek 1y ago
  That is probably the correct measure. If “The Promise of Computing” is ever to come true, people must never wait on computers when interacting with them. Waiting is ok when it comes to sending batches of data to be transformed or rendered or processed or whatever. I’m talking about synchronous stuff; when I push a key on my keyboard the computer should be done with what I told it to do before I finish pushing the button all the way down. Anything less is me waiting on the computer and that slows the user down. Businesses should be foaming at the mouth about performance; every second spent by a user waiting on a computer to do work locally, multiplied by the number of users who wait, multiplied by the number of times this happens per day, multiplied by the number of work days in a year… it’s not a small amount of money lost. Every more efficient piece of code means lighter devices are needed by users. Lambda is billed by CPU and RAM usage, and inefficient code there directly translates into higher bills. But everyone still writes code which stores a Boolean value as a 32-bit integer, and where all numbers are always 8-bytes wide. What. The. Fuck. People already go on smoke breaks and long lunches and come in late and leave early; do we want them waiting on their computers all of the time, too? Apparently so, because I’ve never once heard anyone complain to a vendor that their software is so slow that it’s costing money, but almost all of those vendor products are that slow. I’m old enough that I’m almost completely sick of the industry I once loved. Software developers used to be people who really wanted to write software, and wanted to write it well. Now, it’s just a stepping stone on the way to a few VP positions at a dozen failed startups and thousands of needlessly optimistic posts on LinkedIn. There’s almost no craft here anymore. Businessmen have taken everything good about this career and flushed it down the toilet and turned teams into very unhappy machines. And if you don’t pretend you’re happy, you’re “not a good fit” anymore and you’re fired. All because you want to do your job well and it’s been made too difficult to reliably do anything well.
p_ing 1y ago
> The amount of things a computer can do in a single thread are amazing, and computers now have a dozen or more threads to do work. If developers cared about performance, things would easily be 20x as performant as they are today. Why? A good portion of programs are still single-threaded, and often that's the correct choice. Even in games a single-threaded main thread or logic thread may be the only choice. Where multi-threading makes sense it should be employed, but it's difficult to do well. Otherwise, it's up to the OS to balance threads appropriately. All major OSes do this well today.
- naikrovek 1y ago
  It’s not about programs being multithreaded. It’s about computers running multiple programs at once on different threads and they all perform well. One can write software that uses the CPU cache in non-dumb ways no matter how many threads your program has. You can craft your structs so that they take less space in RAM, meaning you can fit more in cache at once. You can have structs of arrays instead of arrays of structs if that helps your application. Few people think of things like this today, they just go for the most naive implementation possible so that the branch predictor can’t work well and everything needs to be fetched from RAM every time instead of building things so that the branch predictor and the cache are helping you instead of impeding you. People just do the bare minimum so that the PM says the card is complete and they never think of it again. It’s depressing. The tools to write fast software are at our fingertips, already installed on our computers. And I have had zero success in getting people to believe that they should develop with performance in mind.
  - p_ing 1y ago
    So your assertion is that developers should get in a big huddle to decide how they’re going to consume L1 between applications? Which of course no dev has control over since the OS determines what runs and when.
    - naikrovek 1y ago
      You can make your time in the CPU more efficient by thinking of the cache and the branch predictor, or you can say “nothing I do matters because the OS schedules things how it wants.” Up to you I guess, but I know which of those approaches performs significantly better.
autoexec 1y ago
> languages like javascript and python remove you so much from the CPU and the cache that even if you were thinking of those things, you can't do anything about it. Even operating systems don't get direct access to the hardware these days. Instead a bunch of SoC middlemen handle everything however they like.
- nativeit 1y ago
  Wait…those dastardly systems architecture engineers with their decadent trusted platform modules, each with an outrageous number of kilobytes of ROM. They are the true villains of software performance?
- naikrovek 1y ago
  that doesn't matter; if you make your cache usage smart and your branches predictable, the CPU will take advantage of that and your program will run faster. It is in the interests of the system and CPU designers to make sure this is the case, and it is. If you do the things which make your code friendly to the CPU cache and the branch predictor, when it comes time for your code to run on the CPU, it will run faster than it would if you did not do those things.
ppenenko 1y ago
I commiserate with your frustration with developers writing things suboptimally all too often. However, I disagree with the assumption that it's a JS/Python vs C issue. Example: when VS Code came out, it was much, much faster, more responsive and stable than Visual Studio at the time. Despite being based on Electron, it apparently was much better on architecture, algorithms and multithreading than VS with its C++ and .NET legacy codebase. That really impressed me, as a C++ programmer. Overall, it feels like folks who idealize bygone eras of computing didn't witness or have forgotten how slow Windows, VS, Office etc. used to feel in the 90s.
- Nevermark 1y ago
  > Overall, it feels like folks who idealize bygone eras of computing didn't witness or have forgotten how slow Windows, VS, Office etc. used to feel in the 90s. Let’s normalize speed over time like we do dollars, so we are talking about the same thing. Given the enormous multiplier in CPU and storage hardware speeds and parallelism today vs. say 1995, any “slow” application then should be indistinguishable from instant today. “Slow” in the 90’s vs. “Slow” in 2025 are essentially different words. Given unclarified co-use pushes several orders magnitude of either speed or inefficiency difference under the rug.
  - wonnage 1y ago
    Counterpoint: single threaded performance hasn't improved much in the past 20 years. Maybe 5x at best. And virtually every UI programming environment still has problems with work done on the main thread.
    - DrillShopper 1y ago
      Single thread performance increased every processor generation, and is still doing so today.
      - Nevermark 1y ago
        Too true! RAM parallel bandwidth, increased caching levels and size, and better caching rules, instruction re-ordering, predictive branching, register optimization, vector instructions, ... there have been many advances in single thread execution since the 90's. Beyond any clock speed advances.

ralphc 1y ago

What's your proposal for a "compromise" language between programmer productivity and performance, especially for multiple threads and CPUs? Go, Rust, a BEAM language?

t917910 1y ago
[flagged]
naikrovek 1y ago
Jai seems to be an excellent start. Possibly Zig as well. Both are written/designed by people who care a lot about application performance and developer experience.
- teg4n_ 1y ago
  This is an unserious take. Jai doesn’t even have official documentation and zig hasn’t reached a 1.0 release
  - naikrovek 1y ago
    I wasn't asked for examples of software that is congruent to whatever definition you want. I was asked for a proposal of a "compromise" language, and I answered that question.
Voultapher 1y ago
I don't think the tools are the issue here, they are tools you can do good and bad jobs with all of them. What is lacking are the right incentives. The tech market has never been as anti-competitive as it is today. Let's repeal DMCA 1201 and go from there.

colonial 1y ago

> presumably copilot will help introduce better code into applications than a daydreaming developer would Copilot is trained on Github (and probably other Git forges w/o permission, because OpenAI and Microsoft are run by greedy sociopaths.) I'd wager that the majority of fleshed out repositories on these sites contain projects written at the "too-high level" you describe. This certainly seems to be true based on how these models perform ("good" results for web development and scripting, awful results for C/++/Rust/assembly...) - so I wouldn't get your hopes up, unfortunately.

tough 1y ago
I dont know if its just the training data, or that CRUD and webapps are more inherently easy to parrot away. Low level programming means actual -thinking- about the system, resources, and language decisions etc Even humans struggle with it, Its much easier to build a website than say a compiler, for anyone, humans and llm's included
- colonial 1y ago
  That probably plays into it as well. I have yet to see any convincing evidence that contradicts LLMs being mere pattern parrots. My personal benchmark for these models is writing a simple socket BPF in a Rust program. Even the latest and greatest hosted frontier models (with web search and reasoning enabled!) can only ape the structure. The substance is inevitably wanting, with invalid BPF instructions and hallucinated/missing imports.
  - tough 1y ago
    imho these tools are great i fyou know what you're doing, becasue you know how to smell test the output, but a footgun otherwise. It works great for me, but it is necessarily an aid learning tool more than a full on replacement, someone's still gotta do the thinking part, even if the llm's can cosplay -reasoning- now

njarboe 1y ago

My standard is that software should appear to work instantly to me, a human. Then it is fast enough. No pressing a button and waiting. That would be great.

naikrovek 1y ago
That is probably the correct measure. If “The Promise of Computing” is ever to come true, people must never wait on computers when interacting with them. Waiting is ok when it comes to sending batches of data to be transformed or rendered or processed or whatever. I’m talking about synchronous stuff; when I push a key on my keyboard the computer should be done with what I told it to do before I finish pushing the button all the way down. Anything less is me waiting on the computer and that slows the user down. Businesses should be foaming at the mouth about performance; every second spent by a user waiting on a computer to do work locally, multiplied by the number of users who wait, multiplied by the number of times this happens per day, multiplied by the number of work days in a year… it’s not a small amount of money lost. Every more efficient piece of code means lighter devices are needed by users. Lambda is billed by CPU and RAM usage, and inefficient code there directly translates into higher bills. But everyone still writes code which stores a Boolean value as a 32-bit integer, and where all numbers are always 8-bytes wide. What. The. Fuck. People already go on smoke breaks and long lunches and come in late and leave early; do we want them waiting on their computers all of the time, too? Apparently so, because I’ve never once heard anyone complain to a vendor that their software is so slow that it’s costing money, but almost all of those vendor products are that slow. I’m old enough that I’m almost completely sick of the industry I once loved. Software developers used to be people who really wanted to write software, and wanted to write it well. Now, it’s just a stepping stone on the way to a few VP positions at a dozen failed startups and thousands of needlessly optimistic posts on LinkedIn. There’s almost no craft here anymore. Businessmen have taken everything good about this career and flushed it down the toilet and turned teams into very unhappy machines. And if you don’t pretend you’re happy, you’re “not a good fit” anymore and you’re fired. All because you want to do your job well and it’s been made too difficult to reliably do anything well.

p_ing 1y ago

> The amount of things a computer can do in a single thread are amazing, and computers now have a dozen or more threads to do work. If developers cared about performance, things would easily be 20x as performant as they are today. Why? A good portion of programs are still single-threaded, and often that's the correct choice. Even in games a single-threaded main thread or logic thread may be the only choice. Where multi-threading makes sense it should be employed, but it's difficult to do well. Otherwise, it's up to the OS to balance threads appropriately. All major OSes do this well today.

naikrovek 1y ago
It’s not about programs being multithreaded. It’s about computers running multiple programs at once on different threads and they all perform well. One can write software that uses the CPU cache in non-dumb ways no matter how many threads your program has. You can craft your structs so that they take less space in RAM, meaning you can fit more in cache at once. You can have structs of arrays instead of arrays of structs if that helps your application. Few people think of things like this today, they just go for the most naive implementation possible so that the branch predictor can’t work well and everything needs to be fetched from RAM every time instead of building things so that the branch predictor and the cache are helping you instead of impeding you. People just do the bare minimum so that the PM says the card is complete and they never think of it again. It’s depressing. The tools to write fast software are at our fingertips, already installed on our computers. And I have had zero success in getting people to believe that they should develop with performance in mind.
- p_ing 1y ago
  So your assertion is that developers should get in a big huddle to decide how they’re going to consume L1 between applications? Which of course no dev has control over since the OS determines what runs and when.
  - naikrovek 1y ago
    You can make your time in the CPU more efficient by thinking of the cache and the branch predictor, or you can say “nothing I do matters because the OS schedules things how it wants.” Up to you I guess, but I know which of those approaches performs significantly better.

autoexec 1y ago

> languages like javascript and python remove you so much from the CPU and the cache that even if you were thinking of those things, you can't do anything about it. Even operating systems don't get direct access to the hardware these days. Instead a bunch of SoC middlemen handle everything however they like.

nativeit 1y ago
Wait…those dastardly systems architecture engineers with their decadent trusted platform modules, each with an outrageous number of kilobytes of ROM. They are the true villains of software performance?
naikrovek 1y ago
that doesn't matter; if you make your cache usage smart and your branches predictable, the CPU will take advantage of that and your program will run faster. It is in the interests of the system and CPU designers to make sure this is the case, and it is. If you do the things which make your code friendly to the CPU cache and the branch predictor, when it comes time for your code to run on the CPU, it will run faster than it would if you did not do those things.

ppenenko 1y ago

I commiserate with your frustration with developers writing things suboptimally all too often. However, I disagree with the assumption that it's a JS/Python vs C issue. Example: when VS Code came out, it was much, much faster, more responsive and stable than Visual Studio at the time. Despite being based on Electron, it apparently was much better on architecture, algorithms and multithreading than VS with its C++ and .NET legacy codebase. That really impressed me, as a C++ programmer. Overall, it feels like folks who idealize bygone eras of computing didn't witness or have forgotten how slow Windows, VS, Office etc. used to feel in the 90s.

Nevermark 1y ago
> Overall, it feels like folks who idealize bygone eras of computing didn't witness or have forgotten how slow Windows, VS, Office etc. used to feel in the 90s. Let’s normalize speed over time like we do dollars, so we are talking about the same thing. Given the enormous multiplier in CPU and storage hardware speeds and parallelism today vs. say 1995, any “slow” application then should be indistinguishable from instant today. “Slow” in the 90’s vs. “Slow” in 2025 are essentially different words. Given unclarified co-use pushes several orders magnitude of either speed or inefficiency difference under the rug.
- wonnage 1y ago
  Counterpoint: single threaded performance hasn't improved much in the past 20 years. Maybe 5x at best. And virtually every UI programming environment still has problems with work done on the main thread.
  - DrillShopper 1y ago
    Single thread performance increased every processor generation, and is still doing so today.
    - Nevermark 1y ago
      Too true! RAM parallel bandwidth, increased caching levels and size, and better caching rules, instruction re-ordering, predictive branching, register optimization, vector instructions, ... there have been many advances in single thread execution since the 90's. Beyond any clock speed advances.