I think a lot of the actual issues they're encountering are that the underlying POSIX APIs have a lot of sharp edges which the older versions of the tools have had enough time to work around, while the newer ones are generally running into the same rakes that have been there for decades. It takes a fair amount of time for those to be found and dealt with (though it also takes use, so it's a bit chicken-and-egg).
Probably the largest part is that this kind of code quality is not that important to a lot of devs and applications. Personally I would not describe the majority of code I work on as particularly hard, the challenge was always in getting what I needed done efficiently as opposed to getting it done at all, and LLMs are extremely helpful for that. Though I think I'm more at 90% LLM-generated code, I still do spend a fair bit of time tidying up layout (and any user-visible prose).
The basic idea is that a lock should be something the OS is aware of, so that while a thread is blocked on a lock, the scheduler never tries to wake it at all, and when it is unlocked, the scheduler can wake up the thread that's waiting on it immediately. If the scheduler isn't aware of the lock, it'll just try to wake up the thread periodically, often just wasting CPU when it's still blocked or kept asleep when it could be running.
> Artificial neural networks are already many orders of magnitude more energy intensive than natural neural networks.
What metric are you using to compare? By most counts, the energy budget of an instance of an LLM in a datacenter is lower than the energy a person uses. Of course, if you count energy per neuron connections vs weights then you'll likely get a quite different number. But then again LLMs do a lot of things with far fewer weights than the brain does neuron connections, even if you only count neurons in some parts of the brain. And of course you can point to capabilities that the brain has but LLMs lack, but on the whole it feels like it's pretty difficult to make a useful like-for-like comparison here.
I can't make sense of your comment. Firstly because of the obvious massive over-build of GPU infrastructure the AI companies are engaging in. Secondly because the instance of the LLM in the data centre that users interact with is only a small part of the story. The training phase is clearly prohibitively expensive, thus the fact that these things have no way to learn from experience except by smoke and mirrors.
Also your comment feels like the classic climate denial discourse - say something a bit complicated and a bit difficult to follow that looks at a very small out of context part of the story to cast doubt.
Maybe I shouldn't have been pissed of by your commient. In which case - the excess costs of the training, output, feedback, and training cycle of artificial neural networks seem to prohibit the nightly training consolidation cycle (i.e. sleep) that is an important part of natural neural networks.
There's two sides to efficiency: one of them is how much you put in and the other is how much you get out. I was asking the question because the answer of the relative efficiency of a human vs an LLM strongly depends on what you put on either side of the equation. It's a really easy pitfall to look at one side of one version of that equation and presume a really high inefficiency when that's not necessarily the case. It doesn't help that the data necessary to fully answer any version of this isn't publicly available. That's why I was asking for something more concrete in terms of how you were making the comparison.
If you're looking at training costs, there is definitely one aspect in which LLMs are obviously significantly less efficient: the amount of information needed for the initial training. This does translate into some pretty high costs but it only needs to be paid once for the amount of work that any given LLM does. In terms of fine-tuning LLMs can get significantly more data-efficient than the initial model, which also means energy-efficient, and it's not obvious to me that it would be drastically worse than a human (though again, only thinking in terms of doing the energy input for the kind of work that an LLM is good at).
(The increased efficiency in comparison to humans is part of the reason why you see Jevon's paradox mentioned a lot whenever concerns about the resources used by LLMs are mentioned: more efficiency can easily mean more resource use in total)
Do you have any citation for thermal cycling through the range of an AC inside a house affecting the failure rate of any household goods? Based on my experience this does not seem likely to be the case: thermal effects tend to be exponential or high powers of temperature, and most thermal cycling that people worry about is on the order of 100C or more. 10/20C of variation seems unlikely to be relevant.
(There is a case where if your house is well insulated enough, then it can be worth avoiding cycling your AC during the day, because it is both less efficient and will wear more while pulling the temperature down and this can be worse than just leaving it running in a sufficiently insulated house. It still is probably worth turning it off if you're away for a week, though)
> because it is both less efficient and will wear more while pulling the temperature down
That's just not true. Aircon is a heat pump. It pumps heat more efficiently when more heat is available to be pumped.
Warmer indoor air increases evaporator temperature. A higher evaporator temperature means that the system operates with less temperature lift. This means that the system does less work (per BTU pumped) to cool a house that is hot inside, than one that is already conditioned inside.
Equipment longevity also tends to be increased with less-frequent, longer runtimes than with more-frequent, shorter runtimes. There's less temperature cycling, fewer in-rush current events, and the lubricating oil in a running compressor is actively circulated to the parts that need lubricated. Reducing the number of compressor start-ups is a good thing; these machines like to run.
So even if same number of BTUs enter the home and need pumped out whether the aircon is running or not, then: Letting things warm up inside when there's nobody home to care about that constitutes an improvement in a broad number of ways.
Reality is even better: On a hot day, a house that is hot inside takes in fewer BTUs than one that is cool inside, due to the reduced temperature delta between indoors and out. When we have fewer BTUs coming in, then we have fewer BTUs that we must ultimately pay to pump back out.
But with most houses, the AC will cycle on and off throughout the day anyway - raising the temp while you're gone will often result in less cycling. Especially if you also increase the hysteresis range while out. So you get a triple efficiency win, from better AC efficiency, less AC motor wear, and less heat loss to the outside.
Eh, areas where there was and is still plenty of scope to just charge for a product have also been heavily enshittified, so I don't think you can lay much blame at open source for this.
The freedoms that the GPL gives to users in effect means giving your software away for free (because any single one of them is allowed to republish it openly). I do think there is a possible alternative model which gives most of the user freedom Stallman cared about but which doesn't produce this (something along the lines of being able to view the source code of software you buy, as well as modify it, but only being allowed to share the modifications with others who have bought the software, or only being allowed to distribute the patches as opposed to republishing the full software), but this hasn't really been tried as far as I know.
In rust it's a lot closer to optional: you can in principle compile rust without doing any borrow checking at all (and I believe in practice mrustc does not bother to implement it, because it's primarily used for bootstrapping and so assumes it is already being passed code that compiles with regular rustc).
reply