OR fps taking a dive Oh no, not again...
#41
Posted 30 May 2013 - 07:39 PM
Some performance figures on two systems,
System 1
MB ASUS P658D Premium
CPU i7 960
memory 3x2 gig (3 channels)
GPU Nvidia GTX 570 1.28 gbytes OC
System 2
MB Gigabyte GA X79 UD5
CPU i7 3930
memory 4x4gig (4 channels)
GPU Radeon 7870 2 gbytes
Monitor on both systems was an HPZR30w at 2560x1600.
The second system is a fast system will compile my Linux kernel in around 2/3rds of the time of the first system.
From memory compile time of the kernel and the modules was around 2m 30sec, compiler running with 6 threads.
Route Bernina Bahn, starting from Tirano.
OR is on an SSD on both systems.
OR setup viewing distance 3000 metres, Maximum LOD's set to viewing distance.
Frames rates on both systems essential identical range being 32 or so to at least 200fps.
Average frame rate would be in the range 80 to 150fps.
OR general had smooth animation, no complaints really.
Render thread 99% up sometimes to at least 108%.
Updater around 60%.
Sound 30%.
It appears from this that OR frame rate is limited by CPU running the render thread. The memory bandwidth and GPU processing power not really being in issue (on these two systems anyway).
Lindsay
System 1
MB ASUS P658D Premium
CPU i7 960
memory 3x2 gig (3 channels)
GPU Nvidia GTX 570 1.28 gbytes OC
System 2
MB Gigabyte GA X79 UD5
CPU i7 3930
memory 4x4gig (4 channels)
GPU Radeon 7870 2 gbytes
Monitor on both systems was an HPZR30w at 2560x1600.
The second system is a fast system will compile my Linux kernel in around 2/3rds of the time of the first system.
From memory compile time of the kernel and the modules was around 2m 30sec, compiler running with 6 threads.
Route Bernina Bahn, starting from Tirano.
OR is on an SSD on both systems.
OR setup viewing distance 3000 metres, Maximum LOD's set to viewing distance.
Frames rates on both systems essential identical range being 32 or so to at least 200fps.
Average frame rate would be in the range 80 to 150fps.
OR general had smooth animation, no complaints really.
Render thread 99% up sometimes to at least 108%.
Updater around 60%.
Sound 30%.
It appears from this that OR frame rate is limited by CPU running the render thread. The memory bandwidth and GPU processing power not really being in issue (on these two systems anyway).
Lindsay
#43
Posted 31 May 2013 - 03:28 AM
gpz, on 30 May 2013 - 01:07 PM, said:
Disc, what do you mean of "it is too much"? In your previous post you wrote you didn't notice performance drop.
I did, because as i wrote, quad core cpu have plenty of headroom, one core for each threads. But those who have dual core cpu, probably having problems.
#44
Posted 31 May 2013 - 03:35 AM
#45
Posted 31 May 2013 - 03:37 AM
Mine is a dual core, but I see no problems with either FPS or thread % loads.
#46
Posted 31 May 2013 - 03:01 PM
engmod, on 31 May 2013 - 12:08 AM, said:
Hi Lindsay,
Have you tested with HT off?
cheers
Have you tested with HT off?
cheers
I assume you mean Hyperthreading here, yes I have tried it with both HT on and off, did not __appear__ make a major difference. Although I believe for a desktop system hyperthreading is a complete waste of time.
I have tried compling a kernel for my Linux systems using all avaible CPU's including HT's and while there was an improvement. I judged it was not really worth the effort. From memory compile time went down from 3m 30s (4 cpus) to 3m 15s (8 cpus) or something like that. Going from 4 to 6 real cpu's dropped the compile time to nearly exactly 66% as one would expect.
To get a definitive answer though I believe much more testing would be required.
Bye the way, In the previous post update thread varied between 40 to around 65% sound thread from 20 to around 45%. Highest overall CPU usage seen was around 295%.
Lindsay
#47
Posted 31 May 2013 - 05:55 PM
Hi Lindsay,
I have an Intel 930 with an ATI 5850 /1GB.
I didn't expect any more processing power with HT on, as the hardware for HT is just another register set, so that another context can run with the same CPU.
One of the things that I noticed was that with HT on, I saw a total of 130% cpu with Horseshoe, whereas with HT off I get 260% cpu use AT the same frame rate.
I don't know how to quantify this difference other that smarts in the CPU?
cheers
I have an Intel 930 with an ATI 5850 /1GB.
I didn't expect any more processing power with HT on, as the hardware for HT is just another register set, so that another context can run with the same CPU.
One of the things that I noticed was that with HT on, I saw a total of 130% cpu with Horseshoe, whereas with HT off I get 260% cpu use AT the same frame rate.
I don't know how to quantify this difference other that smarts in the CPU?
cheers
#48
Posted 31 May 2013 - 06:35 PM
#49
Posted 02 June 2013 - 03:32 PM
gpz, on 31 May 2013 - 03:35 AM, said:
But not sure? Never mind, we Hungarians all have a bit of a habit of a freedom fighter in our soul.
I'm just saying, that the sounds using more than a half cpu core alone, is not usual in games :birthday-cake2: (maybe the high cpu usage is caused by the compatibility overhead of MSTS?)
#50
Posted 02 June 2013 - 10:13 PM
I am really getting tired of this argument. And don't understand why you generalize that "more than a half cpu core" you have seen at a time, suggesting it is always "more than a half cpu core", while it is normally between 10-20%.
I think I clarified the reasons why this is needed. But again: Most games are just playing sound effects at occasional events, while here the dozens of sounds need continuous pitch adjustment and immediate round release. When we adjust them less frequently, they sound ugly. Analogous to graphics: less cpu power lower fps.
While I still have ideas to reduce load (a bit), I have less and less intention to actually implement them with such endless and pointless discussions. If you have ideas what to modify on code, please don't hold it back!
I think I clarified the reasons why this is needed. But again: Most games are just playing sound effects at occasional events, while here the dozens of sounds need continuous pitch adjustment and immediate round release. When we adjust them less frequently, they sound ugly. Analogous to graphics: less cpu power lower fps.
While I still have ideas to reduce load (a bit), I have less and less intention to actually implement them with such endless and pointless discussions. If you have ideas what to modify on code, please don't hold it back!