BANANA Benchmark Results Comparison

4.4 GHz across all cores stable? If so you won the silicon lottery.

 

I don't know much about computer hardware or what this banana bench thing is, but I decided to give it a try and these were my results.
CPU: AMD Ryzen 5 2600X @3.6GHz

 

I've seen better numbers from the 3900X, but yeah looks like mine is doing good. I now have 4.4 to 4.5 Ghz from 1.35V (1.32 under load).
score is now 480.

Indeed, I remade the test after kicking all useless programs and I'm able to spawn 17 cars with 60 fps, using the above frequencies.

17 cars on Italy, all on screen 1440p with great graphics settings still at 60fps. Couldn't ask more of beamNG.

EDIT :

Tried to replicate your Norte single car test at 1080p, while at stock I'm getting 100ish fps.

 

EDIT: Lolz, I just realized that I had 120fps limiter on from riva tuner, oh well, 1 car real max fps is 142fps or something around there



I'm on 1080p 39" monitor (well it is actually a tv) so maybe that is also part of the reason why I got so different results, but would 1440p use more CPU then?

My results are indeed bit odd in comparison, with 10 cars or so, how much difference you get with 1440p vs 1080p?

My CPU was running at 4.4Ghz as I was curious about what would be difference with same clock speed:
Edit: Updated chart and numbers for 1-6 cars, running without FPS limiter of 120fps now.

Also noticed I had bit different camera angle (I failed at replicating it perfectly, sorry about that), which also might change results, only with chase view and running recorded path such differences might not happen, so there is going to be always little differences with these test.

I have 3 settings for water pump, 1080rpm, 21XXrpm and 2850rpm, I did run at highest setting, but lower setting would of been enough too I guess.

17 cars:

24 cars:


It took me about an hour to spawn cars, take screenshot and document FPS, did also wait 60 seconds in game and observed minimum fps during that time, then took screenshot from highest fps with 24 times. Room temp was around 17C I think, it's winter time so cooling is not taxed too much.

After testing this is what HWinfo says about Vcore and cpu temp (PECI is one that agrees with individual core temperatures mostly, that other CPU Idk what it is)


Full set of images captured can be found from zip, also all sensors that were recording with hwinfo etc.

Also I did run Banana bench 3 times prior to testing, got 3 whole different results, highest being 290Mbeams/s @ 4.4Ghz 8086k, I could run 4.8Ghz too, with this MB 5Ghz works too, but fries weak VRM and it would only bit more than 10% increase:


Graphics settings used:

Spoiler

BeamNG runs incredible well these days, hopefully this data is some use for people. Over 1 hour of time is something like 60 euros given free to all of you

 

Well well.. Here is the results at 1080p vs 1440p, with same graphics settings. I've highlighted the scenarios where I'm actually GPU limited at 1080p (red is 100%, yellow is 95-100% usage). For sure, I should have checked that for 1440p before but didn't even thought about that.
As we have the same GPU, you're most likely to have the same limits here. Mine is under water as well so it maybe clock a bit higher than yours, hence the small diff with a single car.

So yup, when CPU limited, there is still a diff between 1080p and 1440p.
Also redid a banana run, 482. Not worth a screen but still.

 

Yeah, it is surprising how different resolution affects CPU usage, I had read about that some time earlier and based on your Bananbench result I was sure your performance should be same or better.

Some frames can be CPU limited, some can be GPU limited, I think higher percentage of frames becomes CPU limited as more vehicles is added, higher FPS also increases CPU usage a lot. I think that with 4.4Ghz my CPU can't really keep up with GPU constantly, wait for GPU value is so low, but with one car for certain GPU was also limiting my fps.

Difference with our systems really is that if game gets even more optimizations so that one core load becomes less, you have more cores that game can use and then you get 'free' upgrade.

Although I'm quite surprised that game currently can do close to 20 cars with 6 cores before totally bogging down, with your CPU this bogging after 20 cars does not happen.

This is really great data as even developers might not have this level of comparison done.

 

In BeamNG do lod distances increase with resolution? If they do, that could be a cause.

A lot of the game Lua updates on each frame rather than on a fixed time step like the physics. I'm not sure how big of an impact this makes on things like traction control, and engine management etc. If the game is running at a low fps does the traction control function worse than at a high fps? Since its latency will be increased at the least.
Maybe there is an argument for running beamng at a high refresh rate to make driving easier?

 

What I know is that putting several different cars gets lua and drawcall heavy, using K-Series instead of D15 would also provide different results.

FFB at least does get worse with less FPS, running at 118fps it is better, also I don't get tearing issues running at 118fps vs 60fps, but CPU works a lot harder, like almost twice as hard, maybe?
In a way that makes driving easier though.

For ABS, TC or ESC, I don't know if there really is difference because I don't think they run at refresh rate, but use different 'space', but don't quote me on this, all I have is faint memory of them running at physics engine rate, which may be totally wrong memory.
Different setup for ESC and TC does change driving much much more than running different fps I have seen doing. I did do ABS braking test with 118fps and 60fps and I could not see differences, even brake distance app seemed to agree with physical measuring of stopping distance in both cases.

There was some really low fps where game engine switched to fail safe mode to ensure physics are not exploding or something, but I think that was below 30fps.

Stuff is multiplied by deltatime quite often even on lua that runs in code tied to frames, that should to my understanding deal with different fps so that behavior remains same no matter how fps change.

Drawcalls though are the biggie, ssao and reflections multiply that, more frames and more often those drawcalls need to be processed and send to GPU, so CPU will work harder just because of that alone, but lua contributes to that.

LOD was then how many pixels wide a 'probe' is, so most definitely resolution could affect that, but I don't know how much those do, comparison of drawcalls, 1440p vs 1080p should give some idea of that I think.

One thing which I believe to have effect is to have fps locked, so that CPU or GPU is not working at maximum, then there is always spare computing time available for suddenly arising needs, but of course that increases latency, but haven't found that to be issue, might be though that my brain has more latency these days that I can observe from screen

 

It really depends, it certainly helps a lot, but it isn't a catch all solution.

Imagine throwing a projectile over a wall, if your dt isn't fast enough, a collision will be detected when no actual collisions occoured. (ofc, you can mitagate against this issue by calculating collisions along a curved line rather than a straight one, but that is much heavier to calculate and is only done in games where its really needed, from memory I think Braid does (beacuse infinite time travel gets RAM intensive at high update rates), but don't quote me on that one)


This example, while not directly applicable, is easy to visualise, but other issues do stem from it. For example, code running at 60fps may miss "stuff" that code running at 120fps would see. Equally, if you have a strong outlier at 60fps, that outlier will last 16.67ms vs 8.34ms, hence the outlier may cause an overreaction.

The logic that I am working on is as follows. With a higher resolution, things that are in the distance will be displayed more clearly due to pixel density within the FOV. So it would make sense for the game to increase its LOD distances to ensure that a 1440p player isn't simply looking at low resolution geometry in a higher resolution. If the game is doing that, draw calls would probably be increased for a 1440p player?


--- Post updated ---
Just to add an extra fun tidbit to this.

You know how in some physics puzzle games, you can run the exact same simulation twice, yet get different outcomes. Maybe one time you run it you pass the level, the next time you run it you fail, etc. This is known as determinism. If your game is deterministic, it will do the exact same thing every time if given the same parameters.

If your game runs at a fixed time-step, this is often quite easy to achieve. If your game runs at whatever refresh rate is being used, this makes it far more difficult. These small inaccuracies start to add up as a simulation runs. Hence in a bridge building game your bridge may have stood for one pass of the simulation, but fell down on the second, despite being identical. Obviously if your physics puzzle game has leader-boards, this isn't ideal.

 

Looks like it does. Couldn't catch the average difference, it's changing so fast.
Results on unlocked framerate were the same btw.

 

Okay, but if you take a dice and throw it in real world, is it determanistic?

Even 2000Hz physics rate is not quite enough, if you calculate node distance per physics tick at 200kph it starts to become an issue, but also real world physical forces don't happen equally each time, there is always some variation.

You know those dice roller things, just simple box that you drop dice and it falls trough a chute, you could try to build dice dropper to that and see if dice can be dropped so that it constantly falls to same side, if hypothesis about framerate is correct, wouldn't dice then be possible to drop to same side if you minimize variables in dropping method to such dice rolling chute thing?

 

I think conventional physics would say that the world is deterministic, I don't know quantum physics, so I have no idea
But we are getting dangerously close to "Are our actions and thoughts our own, or is the outcome of our universe ultimately predetermined?" territory.

BeamNG's physics engine is probably deterministic, because its fixed at 2000fps. But its Lua probably isn't. I have no idea if it actually makes a difference to gameplay in BeamNG's case. But lets say you have one person running at 40fps, and another at 120fps, that could potentially be enough that you start to get genuinely different results. Since the traction control may hold back your throttle by an extra 10% for a short period due to insufficient/different data.

I believe that engine management, input handling, differential control, basically anything dynamic outside of the core simulation is ran at your framerate.
My vehicle mods do their digital dashboard cruise control by essentially overriding the player inputs. This wouldn't work if the inputs were updated more frequently than my mods Lua code.

What I am trying to say is, that on my old processor, it was most certainly the games fault when the car suddenly understeered into a hedge when turning into a computationally demanding direction xD
[/s]

 

Bananbench is simple piece of software, but you get constantly different results out from it, because there are variablities, OS does things, other software does things, even hardware is not precisely constantly running at same level, you get slightly different amount of work done in 1 second no matter if clock speed is locked, modern CPUs are very variable in how much work they do each second, stability reasons there is some changes constantly.

Like with dice example, there are always something, we could ponder if earth's gravity really is a constant or if it's in fact a variable, but might not bring us any closer to root of the dilemma. I think that one of the key points of physics is that you don't get same result twice, like in reality you do test few times and get variance because of tiny differences in forces etc.

For an experiment, you could do few runs with your car at vsync on, so get constant 60fps and 30fps (nvidia control panel, half refreshrate vsync), then you could do fps limited 30fps 60fps and fps limited 120fps to see if you find differences in car control, you could also do unlimited fps test drive too.

For me personally, it's not the fps, it's the smoothness and predictability, my inputs vary because of what I see which leads different outcomes.

You might need to ask Diamondback if TC, ESC, ABS etc. is ran physics rate or tied to fps, but I remember thinking it was fps tied and I remember being surprised that it would be at physics rate, however my memory is so insanely broken that often times I get perfect memory image of something and it turns out to be completely wrong, it is like reading from corrupted hard drive, so even doing my very best I fail because of that constantly and it sucks.

For ABS though, there is this kind of part in jbeam:
"engine": {
"ABSrate":40

Searching absrate on wiki or forums does not bring anything, but would think that is how many times ABS can change pressure of brakes in second, or then it is completely different, but if you play with that, you might be able to figure out something.

 

Assuming BananaBench is good benchmark software, you should always get the same result state after it has been ran, all vehicles should end up in the same place. If you don't get the same result state, that would mean that a different set of maths calculations has been ran. For benchmark software this may be a bad thing unless you can guarantee that the variation hasn't caused one run to require more processing power to get the same score.
Of course, we can't control what the CPU or OS is doing, but for a benchmark, that's fine, its the available processing power that is being measured, not some hypothetical maximum.

To summarise, you will get run to run variance in benchmark results. However, this variance should have nothing to do with the benchmark, instead it should be because the benchmark has accurately measured the available processing power that it had access to at the given time.

I disagree with that completely. In real physics you do get the same outputs, providing you have control over the inputs. I think its fair to argue whether it matters or not from a gameplay perspective, but given the same inputs, a simulation should always get the same outputs.

Yeah, I would agree with that, since when driving I am not responding to what I have seen, I am responding to what I predict will happen.

That is my understanding of how ABSrate works too. However, I can't find any Lua files for ABS, which may suggest that it runs within the core physics loop at 2000fps.

Looking at the ESC lua code however, it would appear to run at the games frame rate:


I did ask the devs in the past if it was possible to run Lua scripts faster than the fps, since I wanted a quicker polling rate for my off-road cruise control system (to maximise traction etc). I was told that it wasn't possible.

 

BeamNG physics is 2000 times a second, so the curved arc over the wall doesn't really apply here as the game can only slow the physics engine down if the CPU is too poor performing. You can't make it frame skip, it's just not able to be done (I've asked about that for traffic a while back and recently).
Also, geometry LOD's are based on pixel fill level on the screen. Obviously if you have a 40" monitor and run at ugly 720p, and have a house one block away, there would be less pixels filled by the house than if you have it on 1440p (2x each direction so = 4x as much). Naturally, on the approach to an object, if something changes to one-higher LOD at a block away on 720p, then you'd see that from 2.5~3 blocks away at 1440p. Knocking the resolution up isn't just about more pixel fill, after-all. That being said here, unless I go out and buy a fancier screen, I'm going to be on 1080p for a while yet.
"code running at 60fps may miss stuff that 120fps would catch", I get what you're saying but BeamNG runs at 2000hz, 2000fps internally in the physics engine. otherwise every time you tapped some level object or another vehicle you'd have nodes and beams extending through the thin steel of the vehicle - even at parking lot speeds. What you SEE is just visual feedback from the engine and is generally limited by your CPU, GPU, or memory setup... and that's generally non-withstanding to the physics engine altogether, unless your PC cannot display 20fps at a minimum. Below 20fps and the physics will fall below real time to allow the game to use 'slow motion' to keep from having a buffer overflow condition (where the cpu would become drowned in data it could not keep up with, eventually filling up caches and then memory... and when it runs out of memory, poof). So whether the game is running 10fps or 200fps, the values interpreted by your arced curve over the wall would be the same, it would just be 'how fast it would be processing and hence displaying this' is the only difference.
There is one fundamental difference though. The lag time between frames (frame time), is much less on higher FPS (just like competitive multiplayer shooter games), so you can react quicker and correct the vehicle steering or accelerator (or brake) inputs quicker - preventing total loss of control. The time between keyboard/controller/mouse input>processing>output is really the only difference. At 30fps I can't drive with a keyboard too well and tend to mangle the car quite often. With 100fps I can drive like a boss, in an 88 Pessima, with a KEYBOARD in this game. Enough years/thousands of hours at it and you can too, if you don't already.

On intel or capable systems, make sure you turn HPET off in BIOS and Windows (if applicable). It will enable faster processing as you don't have to wait for the slowest timer increment of the bunch (in hardware, there's several), though performance may be a little more varied, it can help a few fps when running A LOT of vehicles. Some PC's do not have a HPET setting in BIOS, as it's up to the motherboard vendor to provide that, though you may be able to special-request a BIOS with it from the vendor for special use cases or needs.

That's all I have to add. Oh and one more thing. The graphics on my 7850 2GB stink! They're MUD. 30FPS and MUD. The new card can't get here (likely shipped from MARS) fast enough.

 

Yeah, but thing is you can't have exact same inputs and even tiniest change in input is going to affect outcome. Only in theory you can have same inputs to physical object.

To have exact same inputs, you would need to do something like this, set up metal box up in air using map editor and then unpause physics and see if you can get it act random or same.

Dice will always land on same face, each throw if your inputs are same, but if you have a dice, try to find a way to drop it on it's corner so that it lands on same face each time. With above tests I'm always seeing exactly same behavior, no matter how many times I drop the box, in real world it is nearly impossible to achieve that, imo.

Dice in real world prefers side that was on top, they are not perfectly random, but it's pretty difficult to setup their drop so that result would be same each time, because conditions would need to be so incredibly precisely same that it does not happen:
https://www.insidescience.org/news/dice-rolls-are-not-completely-random

 

Only the physics does. All of the Lua code runs at your fps. The Lua does a lot of stuff (engines, gearboxes, esc), you shouldn't overlook it. Input handling seems to be at your fps too.

If you had read my comment, you would have seen that I was only using that as a simple example of why dt doesn't solve all problems. It had nothing to do with the games physics code.

---

I'm gonna throw a link to my website in here for reference: https://www.alwyn.tech/
Don't get me wrong, I don't know everything, I do make plenty of mistakes; but I have some experience when it comes to games programming, not to mention a degree in it.
--- Post updated ---

https://www.whatgamesare.com/determinism.html

Read the "Determinism in Programming" bit

Using their example of Quake. If it is deterministic, you could record the players inputs, save them to a file, load that file on a computer in another continent and replay it. Exactly the same thing will happen, every time.

To be clear, not all games need to be fully deterministic (I would argue that most don't), you can add random elements if you like for gameplay purposes. But the simulation aspect of a game should aim to be as close as it can reasonably be.

In theory you could record the dt values too, and achieve determinism that way. But that's neither here nor there as far as the player is concerned.

---

TLDR of everything that I have said:
Of course people who play the game at 40fps are going to have a worse experience than those playing at 120fps. That's just how things are. But if the games "player assistance" code such as ESC is tied to the physical framerate, that means people who play at different frame-rates may get different or inaccurate "player assistance" that may lead to unrealistic behaviour in game. Will people be able to spot the exact differences mid gameplay? No, not at all. But it may affect their experience within the game by making driving more difficult, or more easy.
This is not a statement to say that there is a problem. Its possible that the differences really are so small to not matter at all. But if not, then it is something that would be useful for players to be aware of, especially regarding the use of frame limiting.

 

Pretty sure this is wrong, some parts of the powertrain, wheels, hydros/ffb, controllers and beamstate run at the physics step - hence you have a lot of update() and updateGFX() functions.

 

If so then I stand corrected.

However, the Hydros.lua file would suggest that some quantity of it is tied to the framerate.



I have also found this in Hydros.lua too

This looks like it could run at the simulations frame rate.


So I think its quite likely that you are correct in that.

 

Also one should keep in mind, when doing physics that use the FPU, or other calculations that use said FPU, these numbers are FLOAT numbers. ALU (Arithmetic Logic Unit - the core of the processor - it's numbers by comparison are fixed. FPU or, floating point unit numbers are float / rounded numbers). With each time you run a physics calculation, the float could round it by 0.0000001 different. This could magnify over thousands of times making a just-slightly-different outcome (a bumper crinkled slightly more or less for example, but the vehicle would end up somewhat in the same shape it would have otherwise, in close to the same place). When using FPU to do math we take nothing for granted. Expecting nothing and getting something in return is always the best method.
@aljowen I was just merely explaining how the physics engine works. I've been into game modding and (hardware) hacking stuff (ethically!) for 25 years, though I am far from a script or code expert in games. Here, most everything I know of stays with the physics engine timing. In most games (especially not those physics-centric), there could be many (and often are at-least some) exceptions to this rule that will run at the frame rate, or failing that (like day/night cycle) may tie to the system timer itself. Bethesda's Fallout 4 physics being tied to frame rate first comes to mind, oh the follies of 200fps in that game (not that this junk VGA card will do it, might as well have a Matrox Millenium II AGP board in here!!!). You'll want certain things tied to frame rate and some things not. Consoles time more things to frame rate generally than PC, too (this can help not overload the CPU draw calls routine and VGA card shaders, if you have a ton of graphics stuff going on like volumetric smoke/fire and lighting effects from it) this CAN help keep things more consistent but slowdown can still be seen by the user.
At-least we don't have to time our code to fit in V-blank and H-blank time slots like had to be done on old consoles.