Multithread Option in ini file

[digitalray]

Multithread Option in ini file

i changed the multithread option in the ini file from 1 to 8 for my i7 quadcofre 8 thread cpu,
i am not quite sure if it really makes a difference though or if it slows down the game when using physx on cpu.

does anyone KNOW for sure how changing the "threads" setting influences the game for fps and stutter (together with physx) ?

or is the game using all 8 threads anyway when the setting is at the default value of 1 ?

 

[ktron]

I think you will find the 1 is for on whilst 0 is off. I will be glad to be proved incorrect.

 

[SigilFey]

I would not play with this. Threading is not really optimized well on the default setting (which is obviously quite low). Raising this could result in all sorts of corruption. Definitely at your own risk.

 

[prince_of_nothing]

What multithreaded option are you talking about? The game is already very multithreaded, and takes advantage of quad cores plus hyperthreading..

 

[Black_Iris]

What multithreaded option are you talking about? The game is already very multithreaded, and takes advantage of quad cores plus hyperthreading..

He is talking about the garbage collector. He is exchanging it for some "hidden setting to enforce multithreading capability" in a 64 bit game made appositely for multithreaded tasks

Sorta like if changing hairworks AA to 16x in the same ini files thinking you are forcing 16x AA in game.

 

[digitalray]

config/base/gc.ini

; Number of threads the GC should be running on
NumThreads = 1

yeah, i read about this "tweak" somewhere on the net but i doubt it really does anything for the fps.
but well.. it says NUM threads, not multithread, so it could really be how many threads the game runs, maybe not CPU threads like we know but number of tasks.

when setting this to 8 i get slight corruption, people pop up for a frame or so.

has anyone tested this setting properly so far ?

 

[ZZantal]

Garbage Collector doesn't benefit much or nearly at all from being multithreaded. this if GC really is the garbage collector which is tasked only with freeing up resources by checking if they are still referenced. Memory access is not parallel even though the memory controller can optimize for multiple requests.

Setting this any higher than 1 will result in one of the two threads constantly waiting for the other to have finished.

This said, I don't really know how the engine works internally, but generally speaking what I said above can be considered true.

 

[brutlern]

The multi-threading system is excelent by default. It even makes use of HT, and uses all available cores to their full potential. No point in messing with it.