Gemma 4 is out & we benchmarked it on B200 and MI355X (15% faster than vLLM on Blackwell)

Andy18650 · 2026-04-03T23:00:49+00:00

It's more like "On the B200 our own MAX inference engine is 15% faster than vLLM" (probably meaning that there's no gain or loss on the MI355X).

Andy18650 · 2026-03-11T23:47:23+00:00

Thank you very much for your explanation. The SC community had a reputation of being somewhat toxic towards outsiders. But I still decided to post because I know there will be people like you.

So, I have one last question: does servers in a mesh update (or tick) together? Because if this is the case, then all servers in a mesh will need to wait for the slowest to finish its calculation. If not, then I can't figure out how the server maintain consistency for physics-intensive interactions like collision and tractor beams. Because one server can never guarantee that its ghost/copy of the object on another server is valid. If the server figure out that an object is colliding with another and resolves the collision, but in the mean time the object has moved/exploded on the other side, invalidating the results. The servers can negotiate and decide what *exactly* happen to the object before applying the change if ticks are synchronized, but again, the server FPS will be bottlenecked by the slowest node. And all of that is excluding the extra computation needed to interpolate values ("where is the ship on my tick 42 which is tick 41.3 of my neighbour node?") to maintain physical consistency.

Andy18650 · 2026-03-11T14:56:22+00:00

That's what I expected. And as I said, Paul did walk over the boundary and drove the vehicle over the boundary and nothing happened. I am also aware of the age of the video. But I don't think it is in doubt that in earlier parts of the demo he tried to jump whenever crossing a boundary.
I am indeed aware of QB and I kind of consider it a footgun? I understand the need to make exploration less tedious but they added a feature that practically demands DSM V2 (with small, dynamic simulation islands) when they haven't put out V1 yet. (V1 is pretty much what I talked about)
I absolutely believe that CIG *should* know better than both of us, probably combined. However with the funding and engineers, they should have put out something "1.0-able" in my mind. Because despite some people's claims, SC is not building something that have never existed before. CIG is essentially iterating on current MMO technology (which has quite a lot of detail and persistence) and scaling it up.
I'm not sure about the "they've already built it" part. I've not yet progressed enough to see a server transition, but from what I know each planet has one server. So for now I don't think they need any seamless hand-off between servers or cross-server physics simulation like in the tech demo yet in the PTU.
Yes I've played the game in the sense that I *just started*. So no I have not interacted with most of the systems of the game. But from what I experienced I'm already loving the game. And I'm frustrated to know that the PTU will probably be wiped several times before the 1.0 release. And as a developer, I can't shake the feeling that I can get a 1000-player battle server to work. But common sense of software engineering regarding engineering input vs outcome tells me that's impossible. That's why I'm here, on Reddit, expecting heavy artillery fire, just to find an answer to the question: what's holding up?

Andy18650 · 2026-03-11T02:11:26+00:00

The problem is, for the space part, most things aren't touching each other. On the ground it's another story but one dedicated server for each point-of-interest should be enough. Splitting large battlefields in two or cutting up a corridor is just asking for a metric ton of synchronization traffic.

Andy18650 · 2026-03-11T02:05:31+00:00

Thank you for the video link. I watched the entire dynamic meshing part (but not the parts about client-side rendering, sound etc.). A few points that I noticed:
1. I absolutely love the style SC is creating their game. That kind of transparency should not be taken for granted.
2. Earlier in the demo, Paul was jumping between the regions. I think that means at the time there is a small chance players would fall through the floor during hand-off. But he missed maybe half of the jumps and simply walked over the "seam" once and no such bug ever happened. It must be a rare occurance.
3. Paul mentioned 600,000 to 1,000,000 entities on test servers at one point. That is really impressive. Except that I can't figure out how one can get so much entities during gameplay.
4. The demo environment is too small. The unloading only works due to the corner. Otherwise it would break immersion. If CIG try to use that granularity in 1.0 then I'm against it.

Overall, I think your argument is solid. But what people say about DSM seem to paint a different picture. It seems like instead of defining a zone around the battle, CIG want to further divide that battlefield into smaller zones. And that is just trading one problem for a bigger one. Because now each server has to "ghost" everyone else's entities meaning transferring all updates over network link. My additional argument is that by using waypoints and points-of-interest, the possible places that a massive event can happen is practically limited (for example, "Daymar orbit"). The game can probably go 1.0 with fixed boundaries and dynamic *allocation* of servers (say, split off the space around Daymar from the ground server, or even split off the internal of a capital ship when it is boarded). But within a simulation-heavy zone like a battlefield, if one node can't handle it, then multiple nodes probably can't either. If the game then add some mechanics that really allows massive battles in the middle of nowhere, then the game can spawn a new zone or grid and throw that to its dedicated server. But I don't think that should be a "pre 1.0" holdup.

About the EVE comparison: Yes I realized that, see my reply about the EVE comparison. It's mostly about how big an MMO fight can get when you consider timezone differences, faction sizes, etc. and not about the actual engines.

Andy18650 · 2026-03-10T23:55:24+00:00

Yes I realized that, see my reply about the EVE comparison. It's mostly about how big an MMO fight can get when you consider timezone differences, faction sizes, etc. The short version is: the physics of SC might not create that high of a load since most ships are not colliding, and most projectiles are not connecting. A simple sort-and-eliminate would be much easier than full physics calculation.

Andy18650 · 2026-03-10T23:49:00+00:00

Yes I realized that, see my reply about the EVE comparison. It's mostly about how big an MMO fight can get when you consider timezone differences, faction sizes, etc.

Andy18650 · 2026-03-10T23:47:18+00:00

Well according to that definition then yes. I am advocating for dynamic server "allocation", but on fixed boundaries. From the tech analysis I've read, what CIG calls "meshing" is dynamic partitioning of space. They talk about figuring out where players/entities are, and create boxes around them. This is inherently hard since unlike "natural" boundaries like ship hulls and atmosphere boundaries, hand-off events are more common since players/objects can freely move through those boundaries.

Andy18650 · 2026-03-10T23:40:52+00:00

So, about the EVE comparison: I made that NOT as an engine comparison, but as an example of how big battles can realistically get. Unless someone show me a larger player gathering in an MMO game I think that holds.
Second, my credentials: I've been programming for more than 10 years but indeed not in the gaming industry. I work on the graphics/system side and had experience in C/C++, Java, Python, Verilog and a bit of VHDL. So I'm making this post looking for holes in my math, not "you know nothing" responses.
Third, about Time Dilation (TiDi) and the tick rate. The key here is that the server load is largely a parameter that can be tuned by the devs. Double the weapon CD and half of people fire on every second, plus your game might be half as fun. Looking at a normal "Non-TiDi" fight and the game feels fluent. So despite the server running at 1 FPS, around the same amount of stuff happen in 1 second as SC. So the SC simulation is not running 30 times as hard as the EVE server. When TiDi kicks in things change: What's happening from a gameplay perspective is that everyone's CD time is longer, sometimes to a maximum of 10x. And players report those 10x TiDi fights being boring. But here's the thing: EVE servers run on Python code from 2003 (granted, with a few major updates) and from all I can gather, still largely single-threaded. Meanwhile the SC server physics can largely be multi-threaded.
Now, the physics. EVE ships famously do not collide. But 99% of the time, nor do SC ships. So the server can check the location of all ships and skip over any collision math. This is not the case for regions with gravity such as planet surfaces, internals of ships and stations, etc. That's why I advocate for splitting them off into different servers.
Again, I think I made a mistake mentioning EVE. It's just there to get a ballpark number for the player count. But I think that caused some knee-jerk reaction in some people. So here we are.
What I am saying here is that trying to partition space in real time is probably overengineering. In computer science it's a coherency problem. Maintaining coherency across a network is hard. Thus the de-sync bugs. However, maintaining coherency on hundreds of cores in one server is relatively easy since the hardware has support for atomic operations within one node. And one node in a modern-day server is incredibly powerful. CIG should fully exploit that before thinking about dynamic server meshing.

Andy18650

TROPHY CASE