IrishCoffe

Mine resource are in line with the statement. All uor "suggestions" ( not only in this thread ) are just non-sense.

Resource: http://download.intel.com/design/processor/applnots/320354.pdf ftp://ftp.cs.wisc.edu/sohi/papers/1996/micro.trace-cache.pdf http://en.wikipedia.org/wiki/CPU_cache http://en.wikipedia.org/wiki/Overshoot_%28signal%29 http://en.wikipedia.org/wiki/Microcode

As part of Nehaelm microarchitecture, SMT employ aggresive techiques to exploit the instruction-level parallelism to keep active the processing units. It is widely uncommon things to report: unless both's of uor processor have already been subject to some rapid voltage variation and/or a wrong microcode implementation.

U should notice a slightly difference using: language="English"; And by the way better u set too these param @ GPU_MaxFramesAhead=1; GPU_DetectedFramesAhead=1;

I m saying, that: ARMA make improper use of multi-threading technology. Source: Ninety-ninety rule http://www-inst.eecs.berkeley.edu/~n252/paper/Amdahl.pdf http://www.intel.com/cd/ids/developer/asmo-na/eng/219349.htm http://en.wikipedia.org/wiki/False_sharing http://en.wikipedia.org/wiki/Cache_thrashing

Are u serious?

HT doest damage any CPU. Improper use of threading methodology DOES.

Look, first off u cant switch OFF HTT while u are running uor system, mainly because u had to wirte a flag in the PCI SPACE and then sequentially reboot it for make the change effective. A simple restriction, which define and therefore simulate how many physical/logical core have the application at his disposal it's not enought for establish who wirte on the cache, because as we know if a thread wirte on the same cache line referenced by some other threads, the entry cache line is invalidated and as to be loaded again from the memory. Things happening ppl Ocing and the game is taxing, having rendundant code which saturate the memory bandwidth, not only make trashing more cache but as Bulldogs said it hammering too the internal memory processor.

Assuming Im not talking with a FAE engineer and/or a tech from a related R&D research departement "sure why, not". 2 word's: resource contention.

On i7 platform MAKE SURE to disable HT. ( and u Barso are in this parentheses )

Thanks for the suggestion, but.. as far I know the major issue is just the render method utilized by arma for drawing things on the traget area, in fact if u try grab a normal screen from the buffer u take only a black screenshoot rly :P By the way, for make it simple that indicate on this specific setup that QUAD SLI is not really working. I suggest to keep it for a little longer. See if u can wait for 2nd gen dx11 card instead seek for another one 9800 at really cheap price to put in SLI on a new monitor :P

Well. At this stage, october 2009 playing ARMA2 with HT on, will for sure permanently damage uor CPU ( if certain condition are meeted ). So.. Im pretty sure that Intel have some nice datasheet and/or technician which could explain how to implement such MULTI-ENTRY THREADING into the already existent app code. U know, optimization is the key for the future :D

Some of the post inside this section seems some old fary tale, how it be.. missing quad-core support in addition with no multi-gpu code optimization, really sucks and perhaps kill our expectation. I7 920 @4.00 (28k Vantage) Quad SLI 295 @Stock (31k Vantage) BloodRage OCZ 1600 6GB WD1550HLFS RAID (Read 231 MB/sec HD tune) SSD OCZ (Read 215 MB/sec HD tune) In term of performance, it's like u know, watching a blu-ray video on one old Athlon Thunderbird 800. Lot of stuttering, I mean really a lot. So, I've decided to leave a post for the posterns. Vanilla 1.04 - ARMA2_Build_59323 - PROPER - no matter what, the game as it is will just stutter, so please: chunk, serialize the texture or at least for the most used enable a cache folder. Thanks

wrong thread