X4 performance profiling

[EnderBeta]

So X4 is not the most computationally intensive thing I run, yet it makes my system choke up as if it's trying to run everything on top of Python.

What are your specs?

The game runs fine on my two aging higher end mainstream machines. My core specs are 10900K, 32GB DDR4-4200MHz CL16, RX 6950 XT handles the game just fine on a Samsung 970 EVO Plus 2 TB m.2 ssd. It also runs well on my i9-11900K, 32GB DDR4-3800MHz CL14 Gear 1, RX 6900 XT on the same type of ssd.

Both play at max settings 1440P with vsync enabled and no FSR although my 11900K has two auxiliary monitors that it is driving while playing the game.

The 10900K system does 75FPS and the 11900K does 60 FPS.

My suggestion if your machine is a few years old and you cannot afford to buy a full new machine is to consider upgrading the CPU to the best processor that it can be outfitted with.

[user1679]

This is all very interesting but might I suggest an update to the system requirements? The common response to any performance question is "it's cpu bound" or "it's simulating the whole universe" but the current recommended specs do not meet what people suggest you actually use. From steam:

https://store.steampowered.com/app/3921 ... undations/

Minimum:
Requires a 64-bit processor and operating system
OS: Windows 10 (64-bit), Windows 8.1 (64-bit), Windows 7 SP1 (64-bit)
Processor: Intel i5-4590 3.3GHz or AMD equivalent
Memory: 8 GB RAM
Graphics: Nvidia GTX 780/970 or AMD equivalent (Vulkan support required)
Storage: 15 GB available space



Recommended:
Requires a 64-bit processor and operating system
OS: Windows 10 (64-bit)
Processor: Intel Core i7-6700 or AMD equivalent
Memory: 16 GB RAM
Graphics: Nvidia GTX 1070 or AMD equivalent (Vulkan support required)
Storage: 20 GB available space

I have one machine with an i5-7500 with 24 GB RAM and an RTX 3060 with 12 GB VRAM and I can tell you that those "recommended" specs are not sufficient **. On that machine I get around 24 fps in space and anywhere from 12 to 20 at stations. But even the "recommended" settings are still well below what people here on the forums say you actually need. Perhaps if you updated the specs, people wouldn't post so many performance issues when they're running something less than a 10 series intel because they would know they don't even meet the minimum specs.


** According to benchmarks and benchmarks, the i5-7600 I have outperforms the i7-6700 in some aspects but the i5-7600 does not provide a fun X4 experience.

[Skeeter]

8gb ram min, i wonder how the performance would be like on that. Probs not great either.

[jlehtone]

There are many types of players.
Some get scared by specs that look high.
Some try to play even when they know that their spec is below minimum.
Some want the requirements to go up, so that the new hardware gets efficiently used.
Some ..., see: viewtopic.php?f=146&t=452905

[yerdna]

I got frame times of about 15ms on the main simulation thread, with 3.5ms being spent on render preparation, 4.5ms being spent on the UI, and an average of 7.5ms (but with quite a lot of variation) being spent on the "game logic" (everything from animation updates to AI script processing). I'm not sure what you mean specifically by "IO", but if you're referring to file access, it's irrelevant because it's not happening on the same thread as the above. Other things such as the actual rendering, the physics, pathfinding, and so on, also run on other threads. Note that this was a development build, with some overhead for the profiling environment.

Interesting!

The XML is loaded, mostly when you start the game, and turned into simple classes or structs. These tend to have a somewhat flatter layout than the XML itself because the internal formats are set up for performance (at least where that's relevant) while the XML is set up for readability. The internal format of the AI and MD scripts is obviously a bit more complex, but it's still basically just classes and structs. We're not translating it into any third party language or using third party APIs for the language-like features; it's all custom-built and under our direct control.

That's what I figured. I do wonder if you've considered embedding something like Mono and using the builtin Jitter or AoT, similarly to what Unity have done. I expect that 7.5ms would likely drop to <2ms.

As I'm poking around the XML and modding interface, I will admit that I have a hate relationship with the XML format of things...but at the same time, I can appreciate the extensibility/patching nature it gives the game.
My gut instinct for that would be to use the syntax tree produced by the patched XML and translate it to something that can be compiled or use an existing and performant VM, rather than writing my own.

[CBJ]

With respect, you are plucking numbers out of the air, based on assumptions that I've already explained are wrong. You still seem to be fixated on the XML, which is completely irrelevant to the performance; it's just a file format. The code that is running during that 7.5ms is C++ code, accessing sensible C++ data structures. It's not going to benefit from embedding Mono at all, let alone by the ridiculous margin you suggest, because it simply isn't relevant.

[yerdna]

@CBJ, I'm not fixated on the XML, I think something may be getting lost in translation, so I'll try asking a different way.

Whether it's XML or a different programming language doesn't really matter, game logic is game logic.
It's essentially an AST that needs to get processed somehow.
The how it gets processed is the question and argument here.

Say, something like this:

Code: Select all

<do_if value="(not this.ship.pilot.$st_sector?) or (this.ship.pilot.$st_sector != this.ship.sector)">

Does the game translate the above directly to bare metal machine code like:

Code: Select all

LDR R0, <this>
LDRi R0, R0, #[offset this.ship]
LDRi R1, R0, #[offset ship.pilot]
LDRi R1, R1, #[offset pilot.st_sector]
Bz #[if body]
LDRi R0, R0, #[offset ship.sector]
TST R0, R1
Bne #[if body]
B #[else body] 

Or, does it simply process the AST through a VM?

If the answer is that the game runs the AST through a VM, then I stand by my earlier statements that a lot more performance could be squeezed out of the game logic. Getting that 7.5ms to sub 1ms would be within reach.
Granted, there is a nuance here.
Given the architectural decision to stick with a VM, I'll take your word that the VM's C++ has been thoroughly optimized and is as good as it can get, so optimizing the VM further will produce diminishing returns.
However, that begs the question whether a VM is still the right architectural decision.
Maybe when the game was first started decades ago, it was absolutely the best decision.
However, times change.
With the advent of open compiler technologies like LLVM or Mono, it may worthwhile to look at ditching the current VM and directly generating CPU instructions from the game logic.
Considering that you've ditched your old physics engine for a new one, maybe this suggestion isn't that far fetched, and I know it will result in major performance gains.

I'm just planting an idea for X5 or version 7

To quote the Musk dude:

possibly the most common of a smart engineer is to optimize a thing that should not exist
https://www.youtube.com/watch?v=hhuaVsOAMFc

[jlehtone]

What is a "VM"? I thought that "C++" is compiled into binary, i.e. "machine code".

[CBJ]

I think something may be getting lost in translation, so I'll try asking a different way.

It is, but not in the direction you think.

If the answer is that the game runs the AST through a VM, then I stand by my earlier statements that a lot more performance could be squeezed out of the game logic. Getting that 7.5ms to sub 1ms would be within reach.

Again, no. You don't seem to have read my description of what is happening during that 7.5 ms. You asked for the timing for "game logic", and that's what I gave you. That's all the game logic, including animation, local character and ship movement, production calculations, and a whole range of other things that have nothing to do with the AI and MD scripts. Only a fraction of the "game logic" is defined by those scripts. Even within the logic that is defined by those scripts, the "execution" of the programming logic represented by the script is a very small subset; most of the time taken is back in the C++ code, calculating values or performing tasks requested by the logic.

[Mountain_Puncher]

What do we need as far as hardware to have the game maintain stable performance then? I built an i7 13700k with an rtx 4080 on an Asus Z790-E in addition to two rectangles of 16gb 6600Mhz CAS 32 ram. Oh, Also I'm utilizing a 2 TB Samsung 980 Pro SSD, not that it matters. Anyway, when a fresh game drops into the 30s around some npc L ships shooting each other by some asteroids, is that good? Also, walking around stations can drop my fps to 50-80.

I have seen some with obsolete hardware applauding the performance. I too can achieve 144fps, my monitor's refresh rate, in sparsely populated areas. I never had any trouble running, not playing, X-Rebirth with hardware new in 2013. What happened?

[magitsu]

I have seen some with obsolete hardware applauding the performance. I too can achieve 144fps, my monitor's refresh rate, in sparsely populated areas. I never had any trouble running, not playing, X-Rebirth with hardware new in 2013. What happened?

More and larger sectors, more stations and ships. Even XR chugs a bit in shipyard+civ boat factory sectors jump points due to crowding.
Ship models, effect and skyboxes at least don't seem much different.

Yeah, it's a bit annoying how much the fps can change from min to max, even if we discard the possible megastations.

[jlehtone]

Yeah, it's a bit annoying how much the fps can change from min to max, even if we discard the possible megastations.

I have never used any tool or option that would show "fps value" for X-games. No number to worry about.

I do admit that when I did build 1000+ station complex into Savage Spur of X3R, there were probably seconds per frame (and the unskippable "build" cut-scene ).

[magitsu]

I have never used any tool or option that would show "fps value" for X-games. No number to worry about.

Using one would be futile indeed, but unfortunately it's a bit too obvious even without. It's surprisingly good even at occasional sub 60fps. 30 is where it starts to become rough, but I don't know how often it happens outside of running map view with all orders shown... and in 6.0 probably nowhere.

[EnderBeta]

I suspect a lot of the cache misses are due to the frequently accessed data set being significantly larger than the CPU cache. Factorio suffers a similar problem with large bases and is one of the reasons that update time scales worse than linearly with SPM. This is also why large cache CPUs, such as the R7 5800X3D, perform so much better running this sort of workload than their lower cache counterparts.

Most high budget, console like, games try to keep the frequently accessed data set mostly inside the CPU cache. This imposes limits that might be hard limits (limited to X entities at any given time) or soft limits (level designer removes objects due to poor performance in a scene).

I thought the 3D cache on the 5800X3D existed because of the super high latency the Zen3 line has when accessing data from the system memory. My 5950X I had was 95 ns and compared to that my i9-10900K is 47ns. Not to mention the actual memory speeds on the 10900K are considerably faster then the 5950X. Where the 5950X was faster was reading from the cache. That was screaming fast. I figured that was why the 5800X3D had more added to it.

[Imperial Good]

I thought the 3D cache on the 5800X3D existed because of the super high latency the Zen3 line has when accessing data from the system memory. My 5950X I had was 95 ns and compared to that my i9-10900K is 47ns. Not to mention the actual memory speeds on the 10900K are considerably faster then the 5950X. Where the 5950X was faster was reading from the cache. That was screaming fast. I figured that was why the 5800X3D had more added to it.

Cache is always faster than even the fastest memory. This is even why Intel puts more cache on their newer CPUs than their older ones had. If intel were to overlay their CPU dies with additional cache there would also be a huge performance boost.

[Mountain_Puncher]

I have seen some with obsolete hardware applauding the performance. I too can achieve 144fps, my monitor's refresh rate, in sparsely populated areas. I never had any trouble running, not playing, X-Rebirth with hardware new in 2013. What happened?

More and larger sectors, more stations and ships. Even XR chugs a bit in shipyard+civ boat factory sectors jump points due to crowding.
Ship models, effect and skyboxes at least don't seem much different.

Yeah, it's a bit annoying how much the fps can change from min to max, even if we discard the possible megastations.

X Rebirth did look about as good as X4 does to me as well. I understand that the ships in XR were aptly described by some as window dressing since they had the command to "explore" which meant drive off somewhere and de-spawn. That's probably where some fps savings came into play too. Anyway, I suppose CBJ has already gotten the code perfected and we just need to wait for the hardware to catch up.

@jlehtone
You can set a key to toggle fps in-game in case you did want to use the option. I played X3R too as a kid and made gamma photon pulse cannon factories until I choked the President's end sector with them.

[CBJ]

Anyway, I suppose CBJ has already gotten the code perfected and we just need to wait for the hardware to catch up.

We never rest on our laurels as far as performance is concerned. We still have ideas for how to improve things further, but the gains are getting smaller and they are getting harder to achieve.

As for hardware catching up, if the hardware gets better then we'd be more likely to make use of that to include a deeper simulation in the game than just let it run the existing simulation faster.

[alt3rn1ty]

As for hardware catching up, if the hardware gets better then we'd be more likely to make use of that to include a deeper simulation in the game than just let it run the existing simulation faster.

In that case, I'll skip buying a new laptop in a few years and buy an even better one in 6 years time
One day I am determined to play this game having smooth dogfights in big battles, but no doubt by that time I will be playing / testing X5

[EnderBeta]

I thought the 3D cache on the 5800X3D existed because of the super high latency the Zen3 line has when accessing data from the system memory. My 5950X I had was 95 ns and compared to that my i9-10900K is 47ns. Not to mention the actual memory speeds on the 10900K are considerably faster then the 5950X. Where the 5950X was faster was reading from the cache. That was screaming fast. I figured that was why the 5800X3D had more added to it.

Cache is always faster than even the fastest memory. This is even why Intel puts more cache on their newer CPUs than their older ones had. If intel were to overlay their CPU dies with additional cache there would also be a huge performance boost.

*sigh* I realize that cache is faster than system memory.

In the case of the 5800X3D it is a crutch. It comes at the price of clock speed and when it runs out and it does in certain circumstances it is worse than a 5800X. When Zen3 needs to access the memory the latency to do so is double the time it takes for a tuned 10th gen i9 and further compounded by the limited system memory speeds that the chipset can handle because of the fabric linking the CCUs in the processor. While a 5800 class part has only one CCU it still goes through the same fabric and has the same limitations.

It seems pretty obvious that AMD added all the cache to mitigate the slow system memory and it is just the next buzz word now that the cores buzzword has run it's course. Personally, I think we would be better off stepping up from dual channel to quad channel system memory then trying to stack cache on top of a part that already is hard enough to cool as it is.

[Imperial Good]

It seems pretty obvious that AMD added all the cache to mitigate the slow system memory and it is just the next buzz word now that the cores buzzword has run it's course. Personally, I think we would be better off stepping up from dual channel to quad channel system memory then trying to stack cache on top of a part that already is hard enough to cool as it is.

The purpose of the cache is latency mitigation, not bandwidth mitigation. Even moving to quad channel memory will not improve latency as each channel will still have the same access time latency. This can be seen with server CPUs in gaming like workloads which despite having as many as 12 memory channels will still under perform consumer desktop CPUs due to the lower clock speed. Throwing large amounts of cache will allow a lower clock speed CPU to out perform a higher clock speed CPU in some tasks due to the resulting reduced latency.

Every time a cache miss occurs there is the potential of a memory access latency duration of stall inside the core execution pipeline. This results in a lot of wasted CPU cycles during with the processor cannot execute that thread. In single thread bottlenecked workloads this results in an overall reduction in performance. With AMD CPUs this can be seen as "effective clock", which running X4 or other big data set games will usually be much slower than the CPU boost clock despite the CPU reporting it is at boost speed. Intel CPUs with similar cache amounts generally handle such conditions better due to the significantly lower memory access latency from not using a separate IO chiplet design. Throwing enough cache to significantly reduce the cache miss rate will reduce the number of such stalls allowing significantly fewer wasted cycles, which is the approach AMD's X3D processors use and is why they can significantly out perform other AMD and Intel processors in the same workload despite a significantly lower boost clock. Increasing the number of memory channels will only improve memory access latency under memory bandwidth limited conditions (queued), which even with dual channel memory few games using discrete GPUs are, especially with DDR5 memory which already has a much higher transfer rate.