INI options for threads don't seem to do anything.

[Kodiack]

One of the really popular pieces of advice I'd often see thrown around for Oblivion was to change the stuff that involves threading in the Oblivion.ini file to true and to increase the thread count where relevant. Changing the thread counts and toggling the thread options did nothing to Oblivion's thread count, though. With all the options enabled and the thread options changed to 24, Oblivion was still using thirty threads, just as it was with the options disabled and the count changed to 1 per.

 

I don't think the options that involve threading do anything at all. They're there as options, but the game engine likely doesn't acknowledge them or something of the sort. Has anyone run any benchmarking with this? For how common the advice is, it seems to serve more as snake oil than anything else.

[Striker879]

I'll lead off with a quote from Koroush Ghazi's Oblivion Tweak Guide (emphasis added):

 

Multithreading Tweaks:

 

bUseThreadedBlood=1

bUseThreadedMorpher=1

bUseThreadedTempEffects=1

bUseThreadedParticleSystem=1

bUseMultiThreadedTrees=1

bUseMultiThreadedFaceGen=1

iNumHavokThreads=5

iThreads=9

iOpenMPLevel=10

 

All of the above settings seem to relate to the use of the GameBryo engine's multithreading capability. Multithreading splits tasks into 'threads' where possible, and runs them in parallel across both cores of multi core or HyperThreading (virtual multi core) CPUs to improve performance. Note that raising the values of the iThreads, iNumHavokThreads and iOpenMPLevel settings very high doesn't automatically mean it uses that many threads - it all depends on how many threads are actually possible based on the information being processed. Experiment with these variables but if you experience problems reset them back to their defaults.

 

Update: In recent times many people have written to me and/or have also posted around the Internet that the tweaks in the [Memory, Loading & Multithreading Variables] section of this guide are either useless or harmful. I have clearly noted from day one that that these tweaks may have no impact, and having tested them myself to ensure that they aren't harmful, I mention that you can experiment with them if you wish, and reset them if you run into any problems. The reason they are still listed here is for the sake of completeness, so I don't receive hundreds of emails telling me that my guide is 'incomplete' because I don't cover these famous tweaks.

 

 

If you look at the names for the variables being tweaked you'll also gain a clue as to why you're not seeing more threads used (beyond what I've highlighted in the first section above). The game engine must process quickly and quickly to the CPU is a lot different than quickly to us. If for example it took 2/10ths of a second to process and generate the face data for everyone in the Market District when we walked through the door everybody here would be bemoaning how slow the game was (considering I've isolated one of many tasks the game engine needs to do when we walk through that door). I could argue that 2/10ths of a second is pretty fast ... try to start and stop a stopwatch in less than 2/10ths and you'll see what I'm talking about. To the CPU 2/10ths of a second is nearly a millenium. When you walk through that door to the Market District I'd be surprised to find out that generating the face data took more than a microsecond (in all likelyhood a mere fraction of that). When you're trying to determine how many threads are in use you're looking at a snapshot. You walk through the door and then try to note how many threads are in use. Heck whatever method you're using to display how many threads may not be able to gather the info and then display it in some manner you'd actually see it. The only plausible way I can see would be to have something that reports the maximum used during a particular session.

 

In my opinion the whole 'bench marking industry' is fraught with problems. I've done a little myself, to check where my builds line up to 'industry standards'. Even using recorded demo runs there's a bit of variability between runs, and it's a documented fact that video card manufacturers optimize their drivers for all the standard demos. If you use Fraps run-throughs you don't stand a chance of ever getting a true apples to apples comparison, unless you average a large number of runs. And then we get to the problem of subjectivity ... are you trying to give a true representation of real world performance, give your sponsors a good run for their money or maybe just show "My rig RULEZ". What you report is going to be flavoured by what you want to report.

 

And for the record, my best time on the stopwatch start/stop exercise is 0.09 seconds on an old watch that had a two button start stop system ... and I only managed that once, and it was years ago.

Edited November 20, 2011 by Striker879