Low CPU utilization & Low FPS

[Alwarren 2767]

Myke;2699319']I'm well aware that i wont change the mind of those negative posters (haters gonna hate). But at least i try to point out the flaws so more objective readers can better make their own conclusions. And i think that's worth it.

Oh come on, can't you do better than that? Negative post equals hater?

[tonschuh 3]

No problem man.

Btw.: due to my 1FPS problem i did now all possible varaints without success. DarkDruid suggested me to Reinstall Arma3 after seeing my rpt.log, but did this twice already this year without success due the issue.

So now i have a fresh install of Windows 7 Ultimate 64bit, actually downloading Arma3 via Steam, i´m very excited if this will solve the problem ^^

Maybe go for 8.1 , as it gives you in many cases a better performance outcome or at least a smoother gameplay.

:)

[LSD_Timewarp82 21]

For now i am happy with 7Ultimate, no need to change to W8.

Rule: never change a running System ^^ ;)

[nikiforos 450]

^+111

[Furret 0]

My Rig:

Click

Latest Benchmark-Results (GeForce v337.88 WHQL | Dev.-Build: v1.21.124741):

:)

Could you try running your tests and seeing what using your CPU and GPU are getting?

[tonschuh 3]

Could you try running your tests and seeing what using your CPU and GPU are getting?

My Rig: Click

Latest Benchmark-Results (GeForce v337.88 | Dev.-Build: v1.21.124.754):

Tools used: MSI-Afterburner v3.0.0.2384 Final | HWiNFO64 v4.39-2215 Beta

Low + Disabled:

============

Stratis = 135fps

CPU-Load: max = 88.6% | 36.9% | 55.7% | 78.7% | 46.7% | 78.6% | 61.1% | 86.9%

GPU(s)-Load: ~50-55%

Altis = 107fps

CPU-Load: max = 86.9% | 32.1% | 53.6% | 73.5% | 56.1% | 40.5% | 68.8% | 37.4%

GPU(s)-Load: ~45-50%

Low:

====

Stratis = 116fps

CPU-Load: max = 86.4% | 65.1% | 51.5% | 52.4% | 49.1% | 32.0% | 71.2% | 37.1%

GPU(s)-Load: ~50-55%

Altis = 99fps

CPU-Load: max = 89.3% | 44.9% | 55.2% | 44.7% | 47.5% | 34.2% | 60.3% | 42.0%

GPU(s)-Load: ~45-55%

Standard:

=======

Stratis = 86fps

CPU-Load: max = 84.4% | 50.9% | 67.3% | 50.4% | 53.1% | 44.5% | 52.4% | 45.7%

GPU(s)-Load: ~50-60%

Altis = 76fps

CPU-Load: max = 81.4% | 43.4% | 54.4% | 44.0% | 90.8% | 35.9% | 64.4% | 42.0%

GPU(s)-Load: ~45-55%

High:

====

Stratis = 64fps

CPU-Load: max = 80.8% | 41.3% | 53.1% | 70.0% | 45.4% | 38.8% | 68.2% | 37.4%

GPU(s)-Load: ~60-70%

Altis = 61fps

CPU-Load: max = 81.3% | 32.8% | 80.0% | 32.5% | 44.2% | 43.3% | 89.9% | 40.3%

GPU(s)-Load: ~50-70%

Very-High:

========

Stratis = 50fps

CPU-Load: max = 80.4% | 37.8% | 52.0% | 40.1% | 72.5% | 41.9% | 48.6% | 67.5%

GPU(s)-Load: ~60-70%

Altis = 46fps

CPU-Load: max = 89.5% | 38.4% | 63.8% | 63.5% | 47.0% | 35.4% | 82.7% | 45.1%

GPU(s)-Load: ~50-70%

Ultra:

====

Stratis = 39fps

CPU-Load: max = 79.3% | 37.4% | 54.5% | 44.9% | 47.9% | 36.3% | 94.0% | 41.7%

GPU(s)-Load: ~50-80%

Altis = 37fps

CPU-Load: max = 82.1% | 56.8% | 51.8% | 41.7% | 91.4% | 33.9% | 82.7% | 40.9%

GPU(s)-Load: ~40-75%

Maxed-Out:

=========

Stratis = 29fps

CPU-Load: max = 77.2% | 48.1% | 52.9% | 47.7% | 45.9% | 43.2% | 55.2% | 92.2%

GPU(s)-Load: ~40-70%

Altis = 13fps

CPU-Load: max = 79.4% | 35.6% | 66.2% | 75.5% | 41.2% | 36.8% | 78.9% | 33.0%

GPU(s)-Load: ~35-65%

The total CPU-Load / CPU-Usage never reached 50%.

:)

Edited May 30, 2014 by TONSCHUH

[jiltedjock 10]

Myke;2699237']It is optimized to do what it does' date=' not what you expect it to be.[/quote']

If it is optimized, why does:

Using Fred's malloc.dll improve FPS ?

Using Fred's registry tweak improve FPS ?

Running missions on a dedicated server instead of using the client improve FPS ?

If it was optimized, none of these things would make any difference. It is clear that the architecture of the application is not optimal - the AI could be running on a spare core, the application could be using large pages. These things do make an improvement.

Where is your evidence that the code is optimized? - do you have access to the source code?

[LSD_Timewarp82 21]

If it is optimized, why does:

Using Fred's malloc.dll improve FPS ?

Using Fred's registry tweak improve FPS ?

Running missions on a dedicated server instead of using the client improve FPS ?

If it was optimized, none of these things would make any difference. It is clear that the architecture of the application is not optimal - the AI could be running on a spare core, the application could be using large pages. These things do make an improvement.

Where is your evidence that the code is optimized? - do you have access to the source code?

Pics or it didnt happen...Some benchmarks which shows the "improvement" you mentioned? But spare me with 1-3 fps more or something like that, thats not an improvement then...

[[frl]myke 14]

Where is your evidence that the code is optimized? - do you have access to the source code?

Where is your evidence that the code is not optimized? - do you have access to the source code?

Using Fred's malloc.dll improve FPS ?

Hmm...different people report different outcome. Some have performance gains while others don't. The game is for everyone the saem so what differs? Right, the hardware.

Also Fred has all the time he wants to try around to squeeze one more frame out of it. BI programmers do have a deadline where it has to be done. They can't spend weeks, maybe increasing 1-2 FPS. It just doesn't pay.

Using Fred's registry tweak improve FPS ?

Hmm...different people report different outcome. Some have performance gains while others don't. The game is for everyone the saem so what differs? Right, the hardware.

Also Fred has all the time he wants to try around to squeeze one more frame out of it. BI programmers do have a deadline where it has to be done. They can't spend weeks, maybe increasing 1-2 FPS. It just doesn't pay.

Running missions on a dedicated server instead of using the client improve FPS ?

Wait, what? AFAIR everyone tried to convince me that the MP performance was the problem, not the SP (without server involved). Maybe time to define where the problem now is. SP or MP?

[St. Jimmy 272]

The fps problem is in both SP and MP. When I'm running alone in the editor my total CPU usage can be as high as 50-60%which is pretty high because I've hyper threading. When AI is added the CPU usage goes down around 20-30%. In MP the CPU usage is also that 20-30%. In SP and MP that 50-60% is needed for town objects alone but we need to draw those objects and simulate with the 20-30% usage. DayZ also has that 20-30% CPU usage problem and it doesn't get higher in towns.

If objects and simulation/scripts could be separated we would likely see big fps increase. Now the AI and all kind of syncing is in a way of object drawing. I've understood that they try to solve this in DayZ now.

[MavericK96 0]

Myke;2700433']Where is your evidence that the code is not optimized? - do you have access to the source code?

I think based on a LOT of evidence including benchmarks' date=' testing, etc. we can conclude that low resource utilization coupled with low performance indicates an optimization issue somewhere. If we were seeing high resource utilization and low performance, that could still indicate an issue (take a look at Watch_Dogs for example), but at least it would make more sense than what we are seeing here.

Myke;2700433']Wait, what? AFAIR everyone tried to convince me that the MP performance was the problem, not the SP (without server involved). Maybe time to define where the problem now is. SP or MP?

Neither the title of the thread nor the OP indicate that it's specific to MP or SP. However, some people find MP faster, some not. Personally, I see very little difference in performance between SP and MP, given the same mission. I'm not sure that quibbling about whether it's MP or SP is really that productive...it's the game in general.

[jiltedjock 10]

Myke;2700433']Where is your evidence that the code is not optimized? - do you have access to the source code?

You are full of it. Where did I say the code is not optimized? I said the application architecture is not optimal' date=' and offered the example of moving the AI processing to a spare core, which [b']does[/b] improve the client performance. And with Fred's changes, I have not seen anyone report worse performance whereas some users are seeing 10 or 15% more FPS.

You are saying, definitively, that the code is optimized. With what evidence do you say this? Are you a programmer? Do you have access to the source code?

To be frank, I don't even know what you think you mean by optimized. Do you mean you don't think the code can get any better? On what evidence?

Throughout this thread you have not accepted anyone offering the opinion that the code is not optimized, unless they have access to the source code. Well the reverse is true too - how can you say it is optimized, without access to the source code?

Wouldn't it, in fact, be better if you just stuck to saying that you are satisfied with performance on your PC and leave it at that?

Edited May 30, 2014 by jiltedjock

[[frl]myke 14]

stuff

whatever...

[Viking2121 10]

The game is unoptimized. No if and or buts, its why we are here correct? If the game ran great, I would not be here. I pay all this money on a decent rig and to find the more AI or players, the lower the CPU and GPU usage? Should be the other way around. Why would I spend $300 on a GPU to find out a $100 GPU can run it just as well on the same settings? Its un optimized thats for sure, maybe its because BIS don't want to make a new engine? I mean it is from 2001 and shows its age, been showing its age where even a dual core could out pace a $1000 quad. Thats my version of unoptimized.

I tested 6 different GPU's and they all showed a sort of weakness in this game which is AI or more players, AMD mostly. Leads me to thing that my 8320 at 4.8ghz is a bottleneck in this game. But even a 3770k with a powerful GPU is having issues at the same or better overclock. The 3770k should out pace my CPU in this game but fails to beat some i3's.

I find this game does run better then arma 2 or dayz, but its still not at an acceptable level. For example I ran a 64 AI mission, after so long where the AI was close to my area the game would start to dip in FPS on single player, not to bad, but the moment when you add say 30 players online, the game tanks like if there were over 100 AI in a singleplayer mission and the CPU goes from 50% down to 20% and the GPU goes from 60 - 70% to 15% with less then 20FPS.

Im no programmer, I repair PC's for a living, I know enough that low resource usage with low FPS means its not optimized worth a damn. Game can't be fixed, its just the engine. Just hope its fixed later or in Arma 4.

[jumpinghubert 49]

....... and to find the more AI or players, the lower the CPU usage?

First I noticed this not logical unique correlation 2007 in arma2.

arma2 anno 2007 (Q6600 Quadcore):

empty editor: 55% average cpu usage

200ai: down to 25% av. cpu usage

arma3 (3570k Quadcore):

empty editor: 65% average cpu usage

200ai: 45% av. cpu usage

The negative correlation between ai and cpu-usage stays but the overall cpu-usage got´s better in arma3.

[Th4d 10]

Myke;2700433']Where is your evidence that the code is not optimized? - do you have access to the source code?

Could you read back to me the second word on the second vertical bar on this recent roadmap and tell me why it´s there or needed at all?

To any sane person this entire thread is riddled with evidence, but this official one should end this discussion about optimizations being needed.

[ruhtraeel 1]

So first off, complaining to a forum moderator won't do anything. They just regulate the forums; it doesn't mean they know anything about how the game is written itself, or that they have any special power over BI's business decisions to continue releasing content rather than creating a new engine.

Trying to dig at moderators for answers or venting at them isn't going to work well; it'll just leave both parties frustrated.

That being said... I don't think this engine can last another full game without a significant overhaul. ARMA 2 was the first foray into modern gaming, and ARMA 3 refined it, but it seems like there isn't much else that can be fixed. At this point, I don't think adding more content will be able to hold the playerbase for another game. ARMA 3 already has so much gameplay content; giant maps, numerous weapons and many drivable vehicles. I think it's reached a point of diminishing returns here, where adding more content won't do as much as rewriting the game engine. I know for me personally, the frustrations/suggestions with the game that come to my mind are purely technical.

Furthermore, in making the new engine:

-Please run big O analysis. Don't have cubed loops, etc.

-Please don't constantly access memory; page faults are expensive. Don't have redundant code and billions of pointers (is this one of the culprits?); take advantage of the cache, especially when a game's scale is as large as ARMA's.

-Don't constantly refresh/calculate things that aren't necessary. Activate listeners only when necessary.

-I don't expect the engine to reach Amdahl's law or anything, but delegating less important functionality to different threads and having another core help would be nice.

BRB, writing super unoptimized code for an oil and gas company LOL

Edited June 3, 2014 by ruhtraeel

[Polymath820 11]

Lets step back and review this subject from a "realistic" point of view. Optimisation does not necessarily mean "more performance" Watch_Dogs is top of it's range. But as stated by multiple Bohemia developers "improving performance is a complex issue" multi-threading is not some "miraculous" solution to all problems relating to performance. Gamasutra makes very clear the top 10 optimisation myths one of them "games don't do multi-threading" and "Using more cores is equal to better performance" Lets face it we've seen this type of problem in the past repeating. Mario 64 had bad frames, there are so many games I can recall having a poor frame-rate it is not funny.

Lets stop simplifying everything to the degree it becomes too simple resulting in us not looking at the "actual" issues an encompassing generalisation of "It's the game engine" is not exactly fair thats similar to saying computers that have a higher clock speed are faster which is not necessarily the case.

Myth 4: Every Optimization Yields Some Performance Gain

Lets look at multi-threading from a different perspective you have an operation going on in the game lets say it's ArmA 3's AI running on the FSM files now when that begins to execute because the FSM-execution VM is multi-threaded creates a thread for that process. Now if this thread is then talking to internal sub-engine threads and the engine threads or the process are running slower the CPU's cores will run to the slowest core. Because multi-threading and parallelism still comes down to data-serialisation by which even if you have multiple programs executing on different cores after the threads execution processes are done they are again converted to a serial data form rather than parallel.

"Thread 1" -> One piece of instructions

"Thread 2" -> Two pieces of instructions

"Thread 3" -> Three pieces of instrictions

Finished instruction "Thread 1" AND "Thread 2" AND "Thread 3"

Re-writing an engine can potentially yield more problems. Watchdogs for example Disrupt engine based off nothing but itself. Scales poorly across GPU and fails to run at more than 30 frames the quote from a games review site "The game is in a wretched state" Sure it uses Nvidias awesome things like Nvidia GI, and Nvidia HBAO+ etc. But large amounts of graphical fidelity at the cost of performance. Not a great trade off.

Edited June 4, 2014 by Polymath820
Additional

[tonschuh 3]

Re-writing an engine can potentially yield more problems. Watchdogs for example Disrupt engine based off nothing but itself. Scales poorly across GPU and fails to run at more than 30 frames the quote from a games review site "The game is in a wretched state" Sure it uses Nvidias awesome things like Nvidia GI, and Nvidia HBAO+ etc. But large amounts of graphical fidelity at the cost of performance. Not a great trade off.

I get with my quite average Rig 50-60fps on average with high-settings which are the maximum for 2gb-GPU's.

:butbut:

PS: I didn't even bother to use my max OC. Ran only my CPU @4200MHz and GPU's @Stock-Clocks.

Edited June 4, 2014 by TONSCHUH

[ruhtraeel 1]

Lets stop simplifying everything to the degree it becomes too simple resulting in us not looking at the "actual" issues an encompassing generalisation of "It's the game engine" is not exactly fair thats similar to saying computers that have a higher clock speed are faster which is not necessarily the case.

Can you pose an alternative reason behind this? The way I see it is, unless Windows' context switching algorithm sucks or something (which obviously isn't the case), the CPU/GPU are both constantly waiting for something to finish. Because the usage is so low, my best guess would be that they're constantly waiting for memory operations to finish, such as mallocing for buffers and such. Each one of these requires the translation from virtual (or logical) to physical addresses of RAM, which ends up taking a long time.

My evidence behind this is that the more there is on the screen, the less the CPU/GPU are being used. This might possibly be everything being loaded from memory? This is also consistent with someone else's finding (I don't remember the exact thread name), where they discovered that overclocking your RAM had some performance boost. I know that for me, I get solid framerates looking at nothing but grass and trees, but the moment I look at a town, my CPU/GPU usage drops, as does my framerate.

(Blame Intel's memory based architecture for this; having a crapton of registers like SPARC would make computers a lot more efficient but (possibly?) a lot less affordable. SPARC assembly was 10x less a pain in the ass to program. Want optimization? Get rid of more NOPs!)

Now if this thread is then talking to internal sub-engine threads and the engine threads or the process are running slower the CPU's cores will run to the slowest core. Because multi-threading and parallelism still comes down to data-serialisation by which even if you have multiple programs executing on different cores after the threads execution processes are done they are again converted to a serial data form rather than parallel.

See Amdahl's law, and what I said above about the degree of which you can do this.

Again, like I stated above, see above for which tasks get delegated to what thread/core.

Re-writing an engine can potentially yield more problems. Watchdogs for example Disrupt engine based off nothing but itself. Scales poorly across GPU and fails to run at more than 30 frames the quote from a games review site "The game is in a wretched state" Sure it uses Nvidias awesome things like Nvidia GI, and Nvidia HBAO+ etc. But large amounts of graphical fidelity at the cost of performance. Not a great trade off.

I'm not sure what you're trying to say here. Obviously, when you try to make an engine, you try to make it well, and not poorly. If you're saying that the game engine doesn't need to be rewritten because of this, you're proving by example, which isn't correct. If you're just saying that's something to keep in mind, then it's obvious that when you try to make an engine, you try to make it well, and not poorly.

I do understand that writing a game engine is time consuming, and takes up a lot of a company's resources (Using Unity in my game design course was a lifesaver, whereas some other groups had to struggle with Gameboy Classic/Atari 2600 assembly and such to get to less than half of what we did), but there's a point where you might realize that this might be the thing holding you back.

Also, if anyone is interested, these are some good general principles as well as tips and tricks to squeeze out performance from your game:

http://gamedev.stackexchange.com/questions/853/c-low-level-optimization-tips

Edited June 4, 2014 by ruhtraeel

[fred41 42]

@ruhtrael, very helpful reading about low level optimization you linked here. Thanks :)

This could be helpful for interested people too: http://www.agner.org/optimize/

[Th4d 10]

stuff

Check out this old article on multithreading on how Valve used different ways of doing multithreading and claimed near linear scalabe results (that we can find in others engines/games today that scale very well with more cores):

http://techreport.com/review/11237/valve-source-engine-goes-multi-core

About watchdogs, i get 50-60fps with everything on high using mhbo and temporal smaa on an amd x8 and gtx760 2gb 256ssd and fullhd. (my guess is that if i had a 3gb video card i could push it to ultra without adding stutter)

Also, today both opengl and mantle pretty much eliminated driver overhead if implemented well enough, dx11 has already made some improvements that can wield up to 10% performance gains when that is the bottleneck.

Edited June 4, 2014 by Th4d

[Peter5on 10]

Newest nvidia drivers (337.88) gives me 4 FPS!!! Normaly i have 38 FPS at my testing spot (4.2ghz) now i have 42 FPS and before patch i had 44FPS with 4,9ghz OC.

FX-8350 + GTX660

[Polymath820 11]

Can you pose an alternative reason behind this? The way I see it is, unless Windows' context switching algorithm sucks or something (which obviously isn't the case), the CPU/GPU are both constantly waiting for something to finish. Because the usage is so low, my best guess would be that they're constantly waiting for memory operations to finish, such as mallocing for buffers and such. Each one of these requires the translation from virtual (or logical) to physical addresses of RAM, which ends up taking a long time.

My evidence behind this is that the more there is on the screen, the less the CPU/GPU are being used. This might possibly be everything being loaded from memory? This is also consistent with someone else's finding (I don't remember the exact thread name), where they discovered that overclocking your RAM had some performance boost. I know that for me, I get solid framerates looking at nothing but grass and trees, but the moment I look at a town, my CPU/GPU usage drops, as does my framerate.

(Blame Intel's memory based architecture for this; having a crapton of registers like SPARC would make computers a lot more efficient but (possibly?) a lot less affordable. SPARC assembly was 10x less a pain in the ass to program. Want optimization? Get rid of more NOPs!)

See Amdahl's law, and what I said above about the degree of which you can do this.

Again, like I stated above, see above for which tasks get delegated to what thread/core.

I'm not sure what you're trying to say here. Obviously, when you try to make an engine, you try to make it well, and not poorly. If you're saying that the game engine doesn't need to be rewritten because of this, you're proving by example, which isn't correct. If you're just saying that's something to keep in mind, then it's obvious that when you try to make an engine, you try to make it well, and not poorly.

I do understand that writing a game engine is time consuming, and takes up a lot of a company's resources (Using Unity in my game design course was a lifesaver, whereas some other groups had to struggle with Gameboy Classic/Atari 2600 assembly and such to get to less than half of what we did), but there's a point where you might realize that this might be the thing holding you back.

Also, if anyone is interested, these are some good general principles as well as tips and tricks to squeeze out performance from your game:

http://gamedev.stackexchange.com/questions/853/c-low-level-optimization-tips

If optimisation was an issue at the memory operations level then why do some people experience problems and others do not? Although I do agree a histogram trace of memory operations I notice a lot of peaks on re-write related to ArmA 3. Although I do wish I could find a cache analysis program. But lets not forget things interesting tidbit I have brought up numerous times if you look at the general compute architecture of video-cards namely my GTX 650 OC 2GB consists of 348Unified shader cores 99% of the time the game is using compute engine number 0 the other what? 11 are sitting idle doing nothing? When compared on metro-lastlight on someone else with a GTX 780 he noticed only Compute Engines 0 - 3 were doing any work. I am starting to think A LOT and I mean A LOT of computing power is going to complete waste.

See the image below to see just how much is going to waste.

http://imgur.com/dVtacIN

@ruhtrael I think we should stop speculating whats going on under the engine...and actually work out the real problem. As stated by a lot of the Bohemia mods we don't have access to the source code and we don't know what issues the game-engine suffers. Just keep providing feedback thats all we can do.

Very useful tools for performance Analysis (Beware A LOT of information to take in):http://technet.microsoft.com/en-us/sysinternals/bb842062

PS: Mantle is wretched.

Also Bohemias excuse is the map is big... Unigine Valley is big... 64,000,0000 Sqaure meters? Sure it's a benchmark but it makes you wonder.... look at Unigine being used in flight simulators definitely rivals Bohemias engine. Independent polygonal movement is the impressive part watching grass behave like real grass.

Edited June 5, 2014 by Polymath820

[ruhtraeel 1]

If optimisation was an issue at the memory operations level then why do some people experience problems and others do not? Although I do agree a histogram trace of memory operations I notice a lot of peaks on re-write related to ArmA 3. Although I do wish I could find a cache analysis program. But lets not forget things interesting tidbit I have brought up numerous times if you look at the general compute architecture of video-cards namely my GTX 650 OC 2GB consists of 348Unified shader cores 99% of the time the game is using compute engine number 0 the other what? 11 are sitting idle doing nothing? When compared on metro-lastlight on someone else with a GTX 780 he noticed only Compute Engines 0 - 3 were doing any work. I am starting to think A LOT and I mean A LOT of computing power is going to complete waste.

See the image below to see just how much is going to waste.

http://imgur.com/dVtacIN

@ruhtrael I think we should stop speculating whats going on under the engine...and actually work out the real problem. As stated by a lot of the Bohemia mods we don't have access to the source code and we don't know what issues the game-engine suffers. Just keep providing feedback thats all we can do.

Very useful tools for performance Analysis (Beware A LOT of information to take in):http://technet.microsoft.com/en-us/sysinternals/bb842062

PS: Mantle is wretched.

Also Bohemias excuse is the map is big... Unigine Valley is big... 64,000,0000 Sqaure meters? Sure it's a benchmark but it makes you wonder.... look at Unigine being used in flight simulators definitely rivals Bohemias engine. Independent polygonal movement is the impressive part watching grass behave like real grass.

Your issue with the GPU engine might also be explained by the constant memory addressing. This would cause the other hardware such as your GPU to sit idly, possibly explaining your results.

When compared on metro-lastlight on someone else with a GTX 780 he noticed only Compute Engines 0 - 3 were doing any work. I am starting to think A LOT and I mean A LOT of computing power is going to complete waste.

I don't understand your point here. Are you saying that every game wastes GPU compute power? I don't know why you are comparing Metro Last Light saying that someone else's GTX 780 "only" uses 0-3 while your's uses #0 in ARMA 3. I also don't really know how Mantle fits into this, could you elaborate please?

@ruhtrael, very helpful reading about low level optimization you linked here. Thanks :)

This could be helpful for interested people too: http://www.agner.org/optimize/

That's a very comprehensive manual, I'm going to bookmark that for reference when making some intensive low-level programs. It would be interesting if a game was profiled to see the degree of change between each of these optimization tweaks, without getting into the hard calculations of theoretical performance.

I do agree that it's difficult to exactly pinpoint the issues, but from my experiences with programs in the past (including seeing my friend write a game engine from scratch, even though I wasn't in the course), as well as the evidence from people's results, my best guess would be that everything is constantly loaded into buffers from memory rather than from arrays/vectors. This would cause a lot of CPU/GPU overhead. Obviously it would be illegal to do a hexdump of the program while it's running, but all we can do is speculate.

Unless a BI developer comments on whether or not we're on the right track of understanding the engine? ;-)

It would be nice to have BI community representative for the general game itself as well as a developer representative for some of the technical aspects of it.

Edited June 6, 2014 by ruhtraeel