Post your FPS & CPU's scores - instructions how to measure included - 5950x + 12900k + now 5800x3D!!

[BigBANGtheory]

If you set the graphics on ultra, do you have lower fps in the dense empire? Because I made my tests all with ultra settings until I noticed that when I set them to low I got 25% more fps in dense empire. But I have only a 1070.
Edit: not speaking about aa or vsync

very little change if at all noticeable tbh

[BigBANGtheory]

Mind, I use a 3070, not a 3080. I think you have to chip the ice of a 3080 if you're not at Ultra in 4k!

To give you some idea at 1440p resolution the 3080 GPU utilisation is something like 60%, at 1080p its barely 30%.... You need 4k ultra to be GPU limited.

[Max Bain]

If you set the graphics on ultra, do you have lower fps in the dense empire? Because I made my tests all with ultra settings until I noticed that when I set them to low I got 25% more fps in dense empire. But I have only a 1070.
Edit: not speaking about aa or vsync

very little change if at all noticeable tbh

Would you be so kind to make a test for me with ultra vs low graphics settings?
The reason why I ask is that I have a 5600x with 32GB ram (low timings) and when I set my details on low I have 33-34 fps but on ultra I got 26-28 fps. So my question is, is this because of my old GPU or is it still the CPU that is limiting. The GPU load is not a clear reference because even my 1070 is never on maximum (while some CPU cores always are) but when you say that you have still about the same fps with ultra settings then it seems that a new GPU would help me improve my performance. Playing on WQHD here...

[BigBANGtheory]

If you set the graphics on ultra, do you have lower fps in the dense empire? Because I made my tests all with ultra settings until I noticed that when I set them to low I got 25% more fps in dense empire. But I have only a 1070.
Edit: not speaking about aa or vsync

very little change if at all noticeable tbh

Would you be so kind to make a test for me with ultra vs low graphics settings?
The reason why I ask is that I have a 5600x with 32GB ram (low timings) and when I set my details on low I have 33-34 fps but on ultra I got 26-28 fps. So my question is, is this because of my old GPU or is it still the CPU that is limiting. The GPU load is not a clear reference because even my 1070 is never on maximum (while some CPU cores always are) but when you say that you have still about the same fps with ultra settings then it seems that a new GPU would help me improve my performance. Playing on WQHD here...

I would suggest the difference is more likely to be between your 5600x and my 5800x with PBO boosting to 4.95GHz on the cores under load not to mention CL14 3600 RAM, basically its quite a small difference that feels CPU related

[Max Bain]

This would not explain the difference between low and ultra settings on my end if others dont have any difference depending on the low and ultra settings.
My 5600x goes up to 4.8 Ghz (precision boost) and my 3600Mhz Ram has a latency of CL 14 as well.

[SirNukes]

The reason why I ask is that I have a 5600x with 32GB ram (low timings) and when I set my details on low I have 33-34 fps but on ultra I got 26-28 fps. So my question is, is this because of my old GPU or is it still the CPU that is limiting.

Pause the game; if your fps goes up a bunch, then that indicates being cpu limited.

[BigBANGtheory]

My RAM is actually running at 3733MHz CL14 -15-15-35 1T with an Infinity Fabric 1866HMz

[Hoborific]

My RAM is actually running at 3733MHz CL14 -15-15-35 1T with an Infinity Fabric 1866HMz

damn nice ram, shame it's not intel where you could benefit from that latency

[Imperial Good]

damn nice ram, shame it's not intel where you could benefit from that latency

As far as I am aware both Intel and AMD benefit from lower latencies and higher memory speed. The exact amount depends on the workload as well as the architecture characteristics. In workloads that cause a lot of cache misses then Zen2/3 will benefit more than intel due to it having higher inherit access latency limiting its performance. In situations where the larger caches of Zen2/3 are giving an advantage over those of Intel then Intel would benefit the most due to it having to deal with more memory read/write operations stalling execution.

This would not explain the difference between low and ultra settings on my end if others dont have any difference depending on the low and ultra settings.

Most likely GPU related. X4 is quite visually demanding. For example my GTX 760 usually limits the frame rate, especially at higher settings.

Some visual settings do depend on CPU performance. This is because they make the CPU do more work preparing commands. An example being the draw distance slider where at higher settings the CPU must work harder to instruct the GPU to draw all the additional objects that are visible.

[hxsgame]

I'd be curious to see a test result from someone else with an 5800X or 5600X.

Yes, I'd be curious to see a test result from someone else with an 5800X or 5600X too .

[Perkel]

CPU - Ryzen 3600 (non-X)
MEM - 16GB 2600Mhz

Young Gun - 125FPS

I also noticed that when i went from 8GB to 16GB that my FPS went up about 20fps.

[Max Bain]

I'd be curious to see a test result from someone else with an 5800X or 5600X.

Yes, I'd be curious to see a test result from someone else with an 5800X or 5600X too .

I posted my result with a 5600x (and my result from my 3600x before I upgraded).

[snwboardn21]

CPU: 10900K (no overclock) Version: 4.0 Beta 4
Mem: VENGEANCE® LPX 32GB (2 x 16GB) DDR4 DRAM 3200MHz (XMP enabled)
GPU: EVGA GeForce RTX 3080 FTW3 ULTRA (High Default, no anti aliasing, 5120x1440)
Young Gun : 136 - 139 fps
Dense Emp : 38 - 51 fps
Dense Emp / Empty : Appears to crash beta 4

Could I bother you for some additional information about your RAM, RAM System latency and how you ran the tests? you're the only one who got above 35 fps on dense and I'm wondering how good your system latency is as that's clearly the big factor

Sorry been away for a minute. I use default timings for my ram with XMP enabled
DDR4 3200 (PC4 25600)
Timing 16-18-18-36
CAS Latency 16
Voltage 1.35V

From what I've seen I am the only one with a 3080 that has posted here, so I am guessing you can chock it up to pushing a few more triangles per second? I flew around for a second, when I was looking at the station is when I was at 38 and when I looked away that is when I was in the 50's.

[Roeleveld]

CPU: 10900K (no overclock) Version: 4.0 Beta 4
Mem: VENGEANCE® LPX 32GB (2 x 16GB) DDR4 DRAM 3200MHz (XMP enabled)
GPU: EVGA GeForce RTX 3080 FTW3 ULTRA (High Default, no anti aliasing, 5120x1440)
Young Gun : 136 - 139 fps
Dense Emp : 38 - 51 fps
Dense Emp / Empty : Appears to crash beta 4

Could I bother you for some additional information about your RAM, RAM System latency and how you ran the tests? you're the only one who got above 35 fps on dense and I'm wondering how good your system latency is as that's clearly the big factor

Sorry been away for a minute. I use default timings for my ram with XMP enabled
DDR4 3200 (PC4 25600)
Timing 16-18-18-36
CAS Latency 16
Voltage 1.35V

From what I've seen I am the only one with a 3080 that has posted here, so I am guessing you can chock it up to pushing a few more triangles per second? I flew around for a second, when I was looking at the station is when I was at 38 and when I looked away that is when I was in the 50's.

I'm still waiting for a decent 3080 to come available.
They do show up more regularly here now, but not the models I am actually interested in.

[MSterling]

As far as I am aware X4 does not fork the application process and uses conventional multi-threading on all platforms. Data is only synchronized between cores implicitly by executing specific instruction sequences. Without running these instruction sequences it is possible for the same area of memory to be modified inconsistently by 2 cores due to the local caching that occurs, a race condition that usually has bad results. Examples that use such instruction sequences are implementations of mutex, barrier and atomic operations.

Like I said, I am practically CERTAIN (in the level of "the sun will rise tomorrow" certainty) it isn't forking. As I said, window sux at it. But it does help make a stable mutli-cpu architecture that is robust and more scalable. And easier to debug. A BIIIIG problem with threaded processes is side effect (not even non-thread-safe routines, any state machine requires side effects, otherwise it isn't a state machine) causing bugs at "random" places, because some value changed which was not thought to be changing between two instructions in THIS thread.
Multi-threading is lightweight for the OS, and is cheap to work into the OS, but it really hurts the programmers. Microsoft pushed multithreading. UNIXes worked on making forking work too. Because they have REAL big programs running on them, ones that you can be at fault to the tune of millions, even billions, for a software bug (worked for a company that had just that). Data synch, however, that you describe is an OS call. The TLBs, cache coherency, and memory signally all contribute to how data synch happens in the microarchitecture of the CPU. The Zen3 got something like 20% of its IPC uplift from unifying the cache and helping the dirty cache clearance. Sony did that even more aggressively for their AMD-based CPU, hence its technical superiority for FLOP per FLOP against PC and XBox builds.
The point of multiforking is that you need to explicitly state sharing some code, via some form of interprocess communication (IPC), which means you will be either building a client-server system, like transactional database entries, or mutexing areas and using shared memory to share memory segments and control access (potentially using asynchronous read and write commands). The copying of instruction cache entries and shuffling of data cache for the binary that is part of the "forked process" can be left, then, up to the CPU to handle, all YOUR program needs to do in the latter case of shared memory regions, is deal with what would be shared AS shared memory. You can ignore state changes because they never propagate.
Note, though, that there are still cache dirtying problems with, say, the 5600 and 5800 AMD chips because each core has its own L2 and L1 cache. Their main advantage is that the 32MB L3 can hold a fairly large program in p-code AND the interpreter of it.
Rocks back in rocking chair, puffing on my pipe... I remember when you could fit an entire FORTH interpreter and a very usable library into 16kB, then Microsoft (hawk...spit...pting) brought out the intellimouse driver that needed 72MB of free space IN RAM to install. Kids today...
Thing is, Microsoft ARE improving its performance, and forking under MS's OS could be vastly improved, at least insofar as a forked interpreter with 10 copies may hold one copy of the interpreter in main memory, and it is only the interpreted program that is unnecessarily copied when forking, so pre-forking would still be a huge advantage, since a lot of stutter will happen when you start that copy operation. Same reason why Java puts garbage collection on a thread with low priority. Forking helps with datacenter like tasks, and Microsoft aren't daft, they have smart people, just lazy executives in charge of them, so they will optimise for those places. And maybe stick it in their Enterprise version

The POINT of this long winded blowhardiness is that there may be a requirement to reconfigure how things are done if you have a high-core-count CPU, because forking is trivially scalable, and threading lighter, but complexity grows as you increase thread counts. So it might have to run one program that is threaded if it detects 8 cores or less, and a different program that is forked for 10 cores or more.

But I've not had to bother with Windows programming since Win98, and not bothered keeping relatively up to date since WinXP. It could be Windows does forking processes sanely. And you use the same synch techniques, but you explicitly denote what is part of the shared state machine (or put that in a server or primary thread, cf DirectX multithreading), so debugging is a LOT easier and therefore scaling happens easier. If a forked process runs out of stack space, it dies. The others keep going. If it were threaded, you'll Oops out all of them.

It could be worth Egosoft's time getting someone who has worked on embedded systems to help out in design, not for the embedded work, but on the knowledge of what can be done to minimise memory use, and then use a more efficient interpreter design to massively multifork and let the OS unhome from a CPU any interpreter that is dealing with an object whose script is paused and has nothing to do now, but will potentially come into life at an indeterminate point in the future.

Scalable computing is hard. Microsoft, for all the spitoon use I pretend when naming it, are good at their job, and they didn't implement multithreading in DirectX for a reason.

[Imperial Good]

Sony did that even more aggressively for their AMD-based CPU, hence its technical superiority for FLOP per FLOP against PC and XBox builds.

If referring to the PS4/Xbox One then the CPU was quite bad to begin with as it was based on their Bulldozer architecture and so practically anything from Intel at the time was a huge amount faster. If referring to the PS5/Xbox Series then the CPU is based on Zen2, which was already surpassed in the PC space by Zen3 at the time of release with Zen2 CPUs having been out for over a year. I doubt there is anything Sony could do to make the cores faster than Zen3.

Same reason why Java puts garbage collection on a thread with low priority.

I am unsure what this has to do with your statement. The actual background garbage collection threads are lightweight as they are not moving/copying anything, only marking and sweeping. For logical reasons when they are copying objects they need to be run at the highest priority since a large part of the JVM may be stalled until they are done.

Some recently added GCs do try to do even more in parallel without pausing the VM, but these come with their own additional overhead.

The POINT of this long winded blowhardiness is that there may be a requirement to reconfigure how things are done if you have a high-core-count CPU, because forking is trivially scalable, and threading lighter, but complexity grows as you increase thread counts. So it might have to run one program that is threaded if it detects 8 cores or less, and a different program that is forked for 10 cores or more.

As far as I am aware these is no situation where separate applications will perform better than a single application that is correctly using threading. Yes it is harder to debug, but as you pointed out there are significant savings due to how complicated applications are compared with threads. If you know of a game that does this I would like to look it up, but so far the only time I know that games spawn (fork) separate processes is for either interoperability with other applications or for anti-cheat monitoring.

It could be worth Egosoft's time getting someone who has worked on embedded systems to help out in design, not for the embedded work, but on the knowledge of what can be done to minimise memory use, and then use a more efficient interpreter design to massively multifork and let the OS unhome from a CPU any interpreter that is dealing with an object whose script is paused and has nothing to do now, but will potentially come into life at an indeterminate point in the future.

This makes the assumption that Egosoft has not already minimised the memory usage as much as they can and have not already optimized their script engine as much as possible. Although there is likely room for improvement, the returns are almost certainly not cost effective, especially for a small developer working on a niche game.

The main issue limiting multi-threading are data dependencies. Everything in game has to happen in a reasonably reliable order. Due to the nature of the game, interactions have a very large scope so it is not really possible to split the updating across multiple threads while also maintaining a reliable order. Even different sectors still depend on each other due to logic being run in those sectors looking at objects in nearby sectors. Some tasks are multi-threaded, but the scope of these tasks is quite limited and hence the performance gains from high core count CPUs is quite limited.

[MSterling]

Same reason why Java puts garbage collection on a thread with low priority.

I am unsure what this has to do with your statement.

Garbage collection is done scheduled, asynchronously, collected so as to remove the waste of starting up a thread that will only operate a few thousand cycles. For garbage collection specifically, the clearing up requires informing any processing CPU that had an interest that their cache may be dirty now.

The POINT of this long winded blowhardiness is that there may be a requirement to reconfigure how things are done if you have a high-core-count CPU, because forking is trivially scalable, and threading lighter, but complexity grows as you increase thread counts. So it might have to run one program that is threaded if it detects 8 cores or less, and a different program that is forked for 10 cores or more.

As far as I am aware these is no situation where separate applications will perform better than a single application that is correctly using threading.

It is that properly multiforking will run as fast as a threaded application. The benefits of this are in debugging and process separation.

It could be worth Egosoft's time getting someone who has worked on embedded systems to help out in design, not for the embedded work, but on the knowledge of what can be done to minimise memory use, and then use a more efficient interpreter design to massively multifork and let the OS unhome from a CPU any interpreter that is dealing with an object whose script is paused and has nothing to do now, but will potentially come into life at an indeterminate point in the future.

This makes the assumption that Egosoft has not already minimised the memory usage as much as they can

That would be relevant rebuttal if you were thinking that Egosoft had minimised memory usage as much as possible. I haven't done much on embedded systems, other than look over someone else's work and kept up to date with the paradigms and news for a few years, and the problems they solve (because they HAVE to) really put a big question mark to THAT claim.

[MSterling]

The main issue limiting multi-threading are data dependencies. Everything in game has to happen in a reasonably reliable order. Due to the nature of the game, interactions have a very large scope so it is not really possible to split the updating across multiple threads while also maintaining a reliable order. Even different sectors still depend on each other due to logic being run in those sectors looking at objects in nearby sectors. Some tasks are multi-threaded, but the scope of these tasks is quite limited and hence the performance gains from high core count CPUs is quite limited.

The main problem is data dependencies that do not actually depend on each other, but are shared by threads by default, meaning you have to invalidate more memory than you ACTUALLY have to.
You don't run a VM process then create threads from it to run windows. You scale to 1000 windows boxen by forking off the VM.

[Panos]

I'm really interested in CPU performance (as this game is severely cpu bottle necked). Thinking about upgrades (intel 10 series and ryzen 4000)

The best method to test CPU bottleneck on X4, is to have a mature game with 200+ hours, a lot of stations and fleets.

I found the game using 10 cores on the 3900X.

[Gavrushka]

I'm really interested in CPU performance (as this game is severely cpu bottle necked). Thinking about upgrades (intel 10 series and ryzen 4000)

The best method to test CPU bottleneck on X4, is to have a mature game with 200+ hours, a lot of stations and fleets.

I think performance has taken a quantum leap forward with the latest few betas, especially around stations, but I can report my 10700 (stock) doesn't ever feel taxed in a reasonably mature game now. I recently upgraded from an I7 8700 with mechanical drive, and it was the HDD that hit performance hardest. - My graphic card now no longer goes above 50 Celsius at Ultra settings too, so the game is growing more PC friendly, I feel.