> Faster GC by skipping image objects during marking
This one in particular I feel like we are inching towards in Python land. I had some really interesting convos from people who really want forking to "just work" and get actual memory savings, because a lot of code is really going to be in memory forever and if we can opt out of refcount work that'd be great
I'll take the opposite here. If someone put in frontier AI models from like .... last june I guess? in a box and let me run it with "decent" token throughput I would be happy.
I think it's worth acknowledging that the power of LLMs at this point is not really so much in the smarts, but in the coordination and the surrounding harness tech. "Written english" turning into sequences of commands[0]. The whole agentic "stuff" in general. Tools + coordination is the superpower. The reasoning... it doesn't have to be _that_ good for the rest of the stuff to work. On good codebases and infra, at least.
And I say this as someone who really would rather most of this stuff disappear!
[0]: programming is obviously text to commands, but there's a loooooooot of futziness that LLM reasoning has let us remove in some flows
> If someone put in frontier AI models from like .... last june I guess? in a box and let me run it with "decent" token throughput I would be happy.
You can have that! Qwen 3.8 Flash-Next is ~Opus 4.6 and runs nicely on a DGX Spark. And that’s just an architecture preview. The Qwen 4 family is expected to arrive this fall.
Do you know what kinda throughput you’re getting on that kinda setup?
(I have a secondary problem of being “locked into” Claude Code by it being good enough for me, I’d probably need to investigate the other harnesses… my impression is other harnesses are a bit more aggressively OK with nuking your setup from orbit)
It is costly, especially right now. I don’t think you can make a case for it on cost savings!
The throughput in a single stream is about 50 tokens/sec (a bit less for prose, a bit more for code due to speculative draft acceptance rates) and about 2,000 tokens/sec for prefill. Both numbers are flat and stable as context accumulates. That’s what finally tilted me away from the Mac Studio despite its much superior memory bandwidth.
I think these numbers may improve because the model is pretty new and optimizations aren’t done.
I don't think you can ever make a case for it on cost savings in general. Inference is very obviously the kind of problem where things are cheaper at scale, and this is still true for smaller models.
Right now the "subsidies" etc I think make the calculus really tough, but for general compute.... for example running CI just on a Mac Mini can get you real cost effective throughput compared to running CI on GH runners and whatnot.
Things get cheaper at scale but that's where the provider's margins come in!
I do think there's also an interesting idea: you buy a box like this and run it at a fixed-ish cost (well, electricity). Your demand goes up but your supply is fixed... and that back pressure means that you still have good cost control.
With cloud providers it's a _biiiiit_ too easy to just increase spend.
Privacy is a great reason, but independence is another. It’s very nice knowing that you’re going to get the same reliable product every time you call the model. Nothing is going to change unless you decide to change it.
That is not a counterargument to cloud inference though. You can also run open weight models in the cloud, and it's still cheaper. So privacy really is the only motivation to run on local hardware.
Ah, no, that’s not cheaper. Renting GPUs adds up quickly and leaves you with nothing in the end.
Renting tokens from open model providers is cheaper but it incurs the same issues: unexpected changes in model quality, inconsistent speeds, service outages.
> GTA 5 in its credits had 150 software engineers. Surprising even to me who has had many an experience of being in a bloated FAANG team, this 150 includes GTA Online!
Just so it is said: my understanding is it's really easy to not end up on the credits list for games despite having worked on it. I don't know if contractors end up on there for example, at least beyond some team leads or the like. I don't know R*'s policies though, I've heard stories of people not being in credits because they, for example, changed jobs near the end of the development.
They have updated their policies a bit. You may not be in the game credits but you'll show up here.
FWIW the social club team which handled a lot of the online components was small around the time GTA5 released. They built the APIs to handle user generated content, telemetry, accounts, etc. But, there were other team members that made it so the game would call said APIs.
I remember hearing in an old podcast (Dad & Sons), one of the guys there worked at Rockstar in QA in 2012 and he's still listed in the credits for Red Dead Redemption 2 (2018), so the policies are unclear to say the least.
Is there a good forum stack that is as moddable as phpbb was back in the day? Every Discourse instance I see seems _very_ similar so I've assumed there's not much of an interesting plugin ecosystem
Simplemachinesforum is a BSD licensed php bulletin board software that is very amenable to modification by a smart LLM. You can add just about anything you want into it.
Most of it is divided up into a large number of medium-sized discrete php files.
It run on just about the most boring apache2 (or nginx), mariadb, PHP stuff...
10 years ago it was at very slow pace of development (don't know how it is now). but the blocker for me back then was the need for SSH access (which greatly limited choice of suitable shared hosting providers) to run composer for installation and upgrades. while with phpBB you could just upload it via FTP, open installation url and you are done.
This seems to be a bit of "we're throwing a _bunch_ of inputs into this machine learning set and then pulling out outputs". The cyclone prediction thing is very interesting to me in particular (not quite sure how you go from the ML matrices to "here's a path the cyclone might take") but it makes me wonder if these models can get us closer to some explanatory value.
I imagine a lot of predictive sciences are ultimately about mixing together a bunch of inputs to attempt to decipher some output. Do we end up being able to take stuff from here and figure out some new ideas about modelling the climate as a whole?
> The cyclone prediction thing is very interesting to me in particular (not quite sure how you go from the ML matrices to "here's a path the cyclone might take")
In a high-level view, it's the result of specialized decoding heads.
Traditionally one would take gridded forecast outputs, then process those with comprehensible actions like "find all local pressure minima in the ocean, then filter to ones which correspond to warm cores, etc." to infer (diagnose) the presence of a cyclone.
One problem with this is that gridded forecasts suffer from known biases and tradeoffs. For example, a forecast on a ~25km grid is just on the edge of being able to represent the eye of a hurricane (50km scales), and it certainly can't accurately represent the sharp transition of wind in the eyewall. That means that the forecast winds are almost certainly a smoothed (and therefore less intense) version of what observers would see.
It's kind of like a post-processing or bias correction (see for example https://www.ecmwf.int/en/about/media-centre/aifs-blog/2026/a..., which applies in physical space), but by having access to the model latent space and by being included in model training it is (probably!) higher-quality than a pure, after-the-fact approach.
Sure we do, you can follow the weights so to say, to see which data turns out to be more important vs less important for predictions of a higher quality
This isn't a super serious comment (and an opportunity for someone to speak up on this) but...
I've heard some commentary in the past that 5G interferes with data measurements heavily used for weather forecasts (something about satellite measurements?)
I remember being _very_ impressed like 15 years ago about how I would have _hourly_ weather forecasts (in particular around the rain) that seemed like magic! And then things... seemed to slowly get worse (at least in Tokyo)
a couple years ago I was chatting with a friend in Kyoto. They used to live in Tokyo and had made the _exactly_ aligned comment like: "I was used to the rain forecasts being not so accurate anymore. After moving to Kyoto they seemed to be quite good! And now they're also bad here. Am I cursed?"
I looked at some 5G rollout maps and you could see Kyoto rollout happened a bit around the time frame they were complaining about....
Anyways I think for most people (at least for myself) weather forecasting seems like this odd dark magic that can't work at all, but there was a window in which it _felt_ like it was super accurate. At least in my personal experience
> I've heard some commentary in the past that 5G interferes with data measurements heavily used for weather forecasts (something about satellite measurements?)
The short version of the "spectrum" issue is that 5G is being allocated in bands very close to the microwave spectra where atmospheric water vapor emits. A bevy of public and commercial satellites in low-Earth orbit passively monitor these microwave spectra and produce extremely important information that is assimilated into numerical weather models.
The federal government sets limits on "out-of-band emissions" for operators emitting in the allocated 5G spectra. These emissions can bleed over into the microwave water vapor bands, creating noise that masks the natural presence of water vapor. The limits for this out-of-band emission is on the order of ~10-20 dB, and there's some work in the atmospheric science literature suggesting that this is enough to confound certain water vapor retrievals. That basically means we lose these observations that help constrain the forecast.
There isn't much indication that this is a serious issue in day-to-day meteorology at the moment. But it's an issue which will be significantly more difficult to unroll and claw back than to simply protect key spectra in the first place.
A couple of years in Tokyo gave me great trust in certain weather apps for eerily precise minute-by-minute rainfall predictions. After a few years back in Sydney, my trust in them has dropped back down to the usual uncertain baseline, and my reliance on them has been mostly replaced with my own rough assessment of the air and sky.
On recent visits to Tokyo, with my current habits, the general crowd (who presumably check some app) has been the more reliable forecast. Either everyone has an umbrella in their hand or they don't. And I discover whether I should have brought my umbrella or if I'll be lugging it around pointlessly, just far enough from my hotel to be stuck with my choice
Maybe a decade ago there was chatter in the Purescript land about FRP in an applicative context.
There's ways you can write your code such that you _know_ that certain blocks of code are going to be unaffected by input changes, and you can then use that information to reduce the scope of changes that need to be done, with only minimal costs to expressivity.
I think with a decently smart compiler (and of course the compiler simply treating a lot of stuff in a black box way) you can totally shrink down the amount of work a client needs to do to render React components, all without changing the semantics.
Of course any performance trick might change the actual sequence of events that happen, and in particular for libs doing fancy DOM manipulation, it's easy for those to rely on React's incidental behavior in a non-spec-confirming way.
But the main point her is that you can totally get to useful improvements on a subset of your React, while still leaving the rest of your components intact
Sure, but trying to strip React of its virtual DOM is just a fundamental architectural mismatch; you can't have your cake and eat it (coarse-grained vs. fine-grained reactivity, fully dynamic arbitrary JSX vs. a templating language etc.). The point I'm trying to make with SolidJS is that it manages to keep JSX by intentionally swapping to signals and introducing primitives and control flow components to scope the compiler, whereas this forces the developer to hold all of this complexity in their heads and write in a specific convoluted way. It's like shipping TypeScript without type declarations and pitching knowing your types in your head as a feature lol.
In the first place, I imagine the subset of React code that’s static enough to compile into direct DOM mutations is so trivial that it’s not a useful optimization target.
> Classical music has been institutionalized, sent to the conservatory as a relic. A small segment of society has decided the ability to perform it is worth preserving, and devotes a sliver of capital to that end: training young people, and paying a few of the best players in the biggest cities to do it professionally.
I had a whole discussion with a German friend whose husband works in opera (this was after Chalomet's "opera as a dead art" comments) and their view was mostly that this view of the world does not hold for at least chunks of Europe. To their mind, there is still both active input into this space, support in this space, and there's societal support to some degree or another.
I don't know the realities on the ground, but that annecdote did make me wonder if I simply assumed that the world of classical music wasn't as dire if you leave the States, at least in terms of job stability.
The comparison to popular music is kinda funy too... plenty of pop musicians that don't live off of their music, right? Maybe we're not generating "Taylor Swifts of Oboe"s but I feel like the measure is more about the median (or even the 90th/95th percentile?) when it comes to art, rather than the top of the top.
I think he agrees it is popular, but in comparison to contemporary styles of music it’s tiny (in skilled performers, listeners, funding and revenue). Right? Even in Europe.
Europe is actually worse, or at least Germany, because the government pays for opera, so it doesn't have to stand on its own two feet. So they don't (have to) care about listeners as much.
Except it runs into an excess problem. As an example, Berlin - just one city - has 7 professional orchestras. They are supported by the government financially to the tune of 200 million EUR per year. There is a very real opportunity cost here and quite a bit of a wealth transfer to old people at the same time (since the audiences for classical music tend to be on the older side).
You could pump a large part of those resources into supporting other kinds of music and arguably the outcome would be more interesting.
It's a wealth transfer to the middle class. Poor people by and large don't go to the orchestra or opera.
Of course, some poor people do enjoy these kinds of things! But if you gave them a choice between the subsidised ticket or the embedded subsidy as cash in hand, I'm sure most poor people would take the cash.
> You could pump a large part of those resources into supporting other kinds of music and arguably the outcome would be more interesting.
Or give the money to poor people, or leave the money with tax payers, etc.
The job stability in classical music is great. It's getting a job in the first place that's a problem. My partner, in an earlier life, was one of the best young flautists in Canada. There were about eight jobs in the entire country for orchestral flautists, and about a year before graduating, a few of them turned over, meaning it would probably be another five years before any more jobs opened up. Good time for a career change...
I think a lot of people just don't get how much of classical music was foundational for pop music. McCartney said blackbird was a twist on some Bach intro. Billy Joel said similar things. A lot of of good music was cooked in classical knowledge.
This one in particular I feel like we are inching towards in Python land. I had some really interesting convos from people who really want forking to "just work" and get actual memory savings, because a lot of code is really going to be in memory forever and if we can opt out of refcount work that'd be great
reply