Is there anything that could convince you that actually-bad things are actually-happening? How can you possibly think that these people are somehow working for OpenAI? Is it impossible for you to imagine that there exist people who actually oppose the actions of these companies?
No, they're not getting close. Top performing Wasm runtimes (like those in V8 and JSC) are generally between 10% (for pure math workloads) and 2x (conservatively, for ef allocation heavy ones) the speed of equivalent native implementations. But that's including the JIT compilation tiers; the performance of interpreters alone lags by an order of magnitude.
Those are two very different things, and the former should be a serious concern. If AI does indeed become a double-digit percentage of electricity usage as the AI labs themselves predict, then it becomes a significant contributor to emissions, full stop.
One unintuitive thing I noticed about these curves, at least from the demo on the page, is that they have both areas where their behavior quickly 'snaps' from one configuration to another, and areas where they saturate such that changes to the control handles no longer produce any movement. Standard Bezier curves don't have either of these; I wonder if that's essentially coupled to the higher expressivity they offer?
It'd be really interesting to see whether the winning (losing?) instructions/strategies would be different on other architectures. At least right now the top spot (`fxrstor64` on MMIO, starve PCIe) seems relatively architecture-independent, but maybe something about MMIO ordering rules on e.g. POWER would be different enough to change that -- or perhaps open up new avenues?
I wonder what the actual limit on this `fxrstor64` is right now. If you can stall the PCIe bus for that long, then why not indefinitely? Certainly there's no forward progress guarantee here.
Desktop operating systems != phone operating systems. You need to have a lot of support for things like "sleep apps you're not using right now" or you'll burn through battery. Not to mention that we tend to expect a lot of functionality which only works when the OS enables it, e.g. the sort of app-to-app coordination enabled by Android's App Intents. You certainly could build something like that on top of DBus, but, well, you'd have to build it.
The 'special treatment' isn't technical, it's procedural -- insofar as if, during development for a new release, MSVC were to land some changes that broke GSL, Microsoft's testing would catch that and ensure that the changes were reverted or fixed to support the latter, prior to shipping. Since they're built as part of the same operating system, they can make sure not to step on one another's toes -- which is not a guarantee that they can make to third-party applications.
But we still try to stop people from doing so, and we punish people who do. Many good honest people, when confronted with the end of their business, accept it and file for bankruptcy. Those that choose to instead commit fraud don't get a pass because they were "under pressure", they get jail time.
Man, it's not an argument. Nobody is paying us to read this. If your argument sucks to read, people aren't going to read it - this has always been true, it's nothing new.
Sorry, but most of us need to work to eat. This idea that our "value" is has nothing to do with the economy is an idea rooted in deep privilege, in the ability to say -- if I don't like my job, if I'm not employable, I can just retire, and the only problem will be figuring out how to live life afterwards.
Many devices are indeed locked down. But given that it's an OS company and hardware vendor, many employees have access to hardware with e.g. SoC fusing that allows them to install custom-signed firmware. It's very difficult to make an OS lock out the people whose job it is to build the platform that OS depends on.
> We would still sometimes treat for varroa, but making it easier for the bees to handle varroa how they had evolved to was the first line of defence
I thought this was very dependent on the species -- European honeybees did not evolve to deal with varroa mites, because the mites originated in Asia. Asian honeybees, and honeybees bred with them, do have better ways of dealing with the mite; you said regular Italian bees, were they really not hybridized?
I don't have any actual field experience here, just curious!
I've always had mixed feelings about Cognition. Obviously they have some very, very smart people working there (I even know a few), and they do make real products. But at the same time, they've made suspicious marketing claims more than once and even been caught making outright fabricated ones; and while they certainly seem to have shaped up from that, I still find their claims to be in a sort of grey area where they seem to avoid unfavorable comparisons and lean on their own benchmarks. Certainly when I've tried their models they have not been nearly as useful as comparable versions of Claude, GLM, etc. -- though I haven't had a chance to try SWE-1.7 yet.
If you keep studying econ you will learn that these failures are actually the norm, and thus why the only "capitalist" states to really succeed have been the ones where the state was strong enough to reign in the market.
Of course, such a state of affairs is temporary at best -- since the alternative is so lucrative!
> while the large slowdown is justified because it allows people to use existing C applications unchanged instead of rewriting in a safe language (never mind that these two claims contradict each other)
Those two claims don't contradict eachother. Many, many people use C code not because their application needs to be blazing fast, but simply because the programs are already written in C. Rewriting a program from C into another language is likely to introduce a lot of bugs, even if the rewrite does manage to achieve 'full memory safety' (which most don't, instead liberally utilizing unsafe blocks or the equivalent). So what are such users to do, simply accept that there are going to be bugs? Fil-C seems to address a reasonable need.
I want to put this charitably, but you come out swinging by saying this is "over hyped"... You clearly don't work in a role dealing with attacks from these models. They've changed the game, and for the worse. Capabilities that used to be available only to nation-state attackers are legitimately commodified, or nearly so.
No, that's not the point. This isn't a situation where you need to "guess"; bloom filters should be sized according to their capacity. This is akin to having a fixed 10-arg buffer for your program, getting a crash when someone passes 11, and saying "this is the kind of bug you only find by building the thing and measuring it". Yeah it happens and we all make silly mistakes, but it's just not true that this couldn't have been foreseen.
ML compilers in particular go beyond even the level of stability you would expect from numerical programs. Due to how the SIMT model of thread/warp divergence works, the hardware heavily punishes unstable branches. E.g. if you have 32 threads taking a branch then recoalescing on a barrier -- if they all go the same direction then they can go down the execution pipe as a single bundle, but if 1 takes it while 31 don't, then that's 2x the ex-pipe usage by default (and if you have e.g. a computed-branch, performance goes out the window). Consequently, the whole stack is built around the expectation of stable control flow, even to the detriment of performance (from a local perspective).
ML frameworks even take advantage of this to compute, ahead-of-time, how much memory will be used at different points in the program graph, and thereafter schedule memcpy's to make space as necessary. Of course this only works for well-behaved program classes, but e.g. most LLM architectures fit into that category. Interestingly MoE models don't, since they require data-dependent control flow, thus the recent push towards accommodating dynamism in frameworks (like JAX, which until ~recently couldn't handle it at all).