I tried it again just now, and one of the cores looks like it hasn't been used at all. Supcomm affinity is definitely set to use both cores. It was a 20 minute game, evidently not too stressful, since core 0 looks like it never actually hit 100% usage, but obviously the workload is definitely not evenly distributed.

Programs I had running while I was testing:

Supcomm
Rivatuner hardware monitor (for gpu temps)
Process explorer->system information (for cpu usage)
fraps (I usually just leave this on 24/7)

Here's the graph of cpu usage

Thc Psytek, it is definitely not working for you on that graph.

Did you actually here it beep?
Did you enable it manually with SHIFT-ALT-A or did you check the checkbox for autostart?
Currently the checkbox has to be checked each time the program is started, it defaults to off every time it is started.

Let me know for sure that you actually enabled it and heard it ding twice.

Edit: Please post your CPU type and OS

Thx

I always use the auto start after 25 seconds thing.

I'm running windows xp media centre edition, and I've got a core 2 duo E6400 running at 2.66GHz.

I just played another game, and it appears to have worked a bit better:

That time it worked as expected, obviously not a stressful game by that pic.

Those other times, did you hear it ding 25 seconds into the game?

Let me know if you see that happen again.

Thank you.

Most times I notice the 'ding' but I usually have the sound low because Supcomm doesn't really rely on the sound.

So what would be the effect of this on multiplayer games? Desync? I've been playing with this thing on for the past week and not noticed any problems at all.

No desynchs. For anyone to really quantify the real effects (sim numbers aside), would take several players getting together in a FFA test game. Running a test game, building up a big force without *real fighting*(no idiots allowed) just throwing units into the middle of the map. During a large fight, one by one enable the tool with a Shift-ALT-A and see the real world results before the next person does it, in the group. Infact just setting up factories to crank out units with a move order to the center of the map would guarantee a consistent good workload.

If anyone is interested in trying to get together over a weekend or evening and try this with me, I will make time. PM me if you wish.

Sim time slows the actual simulation of the game down. To what degree this would effect a scenario as I mentioned above is hard to say at this stage. Also, game unit load may play a part here as well. How intrinsically tied the actual net code is also something I don't know for sure. Again, seeing is believing and having a 4 person game online all with fast dual cores or above would tell alot from a good test.

Until some real world testing takes place like that, I am fine with not recommending it for online play.

But as for skirmish, it's definitely the bomb.

Boris - my clan-mates and I routinely do 3v3 matchups with Sorian AIs and I can tell you that this is a god-send.

Previously, we'd always get to a point where the game was so slow it was pathetic. It would take 2 hours for 30 min of game time.

Now each of us has this installed and whenever the game appears to be slowing down, we'll shout out "time to do a shift-alt-A" on vent and it speeds back up again.

I can't tell you how nice it is to finish a 30 min game in 30-35 minutes instead of 2 hours! We can get many games in during a night.

No, the effect is that even though it gives you a hell of a lot more FPS it also reduces the simulation speed at which the game runs.
There are basically two speeds that are important, one is the speed at which your machine can calculate for example the movement of units, their interactions etc., so this is the simulation speed. The other is the speed at which the game gets actually displayed on your end, the render speed, your FramesPerSecond. The first is dependent on CPU speed, RAM speed, while the latter is more dependent on GPU speed (i.e. your video card).
Now for online games, the player with the lowest simulation speed sets the pace for the entire group of players. No matter if you have a dual core or a quad core with a zillion Gigahertz, if there is a player in your game that has a slower sim speed than you, then he will slow down the game for ALL players.
So for example, you have player A with a slow CPU but a medium GPU, and player B with a fast CPU and a fast GPU. Let's say 20 minutes into the game player A can run the game only at max speed -2, and he gets 20fps with his current settings. Player B's machine could run the game at max speed +5 and 50fps, but because the game always syncronizes at the slowest player's sim speed he gets slowed down to max speed -2 as well. He would still have his 50fps, but that doesn't affect the simulation speed.
Now player A uses the optimizer tool. As a result, he might be able to increase his render speed from 20 to 30 fps, but the cost for that would be a ~10-15% decrease in simulation speed. And since he is already the slowest player and his sim speed is setting the pace for all other players he would in fact slow down every other player as well ...

That is obvious to what most of us learned during beta. You make a good explanation for those that don't know this, I am just saying I have of course known that for a long time. But I still have reservations when I consider alot more variables, which is why I really want to do a test. I still rather people do not use that in the general gpgnet because their are enough online mixed hardware performance issues as it is.

My invitation is still open to anyone that wants to do the real world test I mentioned above, but the test has to be done correctly to be conclusive.

No doubt that it will be really helpful under large load conditions. No one will convince me that everyone playing at 8 fps compared to 25 online will be better with a higher sim number under those types of conditions. You are one of the ones who falls under the "If your testing showed different...feel free to use your own judgement." You proved it for yourselves.

I know enough not to make judgements without empirical evidence so hopefully someday someone will take me up on my testing invitiation. I like many, need to see it for myself. There is more than meets the eye.

As of right now, I just say the overall general audience should stay on the safe side and "not use it online" in general population until atleast a proper test is done and shows it's impact under varying load conditions. There is definite reason to believe it can slow things down more online, especially in ranked games with low end PC's mixed with high end PC's.

Ok so if I understand this correctly, so long as my system isn't the slowest in the bunch, I won't be dragging the game speed down for the group and so long as the game speed isn't being dragged down below 1 ... nobody would care.

I have it set to auto start. It actually usually kicks in during the lobby screen unless we're quick =)

In the name of furthering your research, if your application had an option to gather game and system data for games played - I would be happy to turn on such an option. If it would be of any help.

Hopefully what your doing here could some day lead to an official solution built into the exe.

Finally got some numbers. I was going to make this a seperate epic post covering all kinds of tests but too much time to organize my 40 or so graphs, so here is a summary.

The Systems:
XP & Vista tests with...
C2D 6300 at 3GHz
Nvidia 8800 GTS
2GB RAM
Latest available video drivers as of this date
Audigy 2

XP tests...
C2D 6300 at 1.8GHZ
Nvidia 8800 GTS
2GB RAM
Latest available video drivers as of this date
Audigy 2

XP Tests...
Pentium 4 3GHZ
Nvidia 6800GT
1GB RAM (very lacking)
Latest available video drivers as of this date
Onboard Creative sound

Game Settings:
For the C2D with 8800 GTS...
High fidelity preset(everything on high, shadows on medium)
Nvidia driver stg - High Quality

For the P4 and 6800...
Medium fidelity preset
Nvidia driver stg - Performance

The Test:
I have a CPU Stress test I built on the perftest as a foundation. Only top down zooms, many more units, several grueling simultaneous battles, many more air units and raids and much shorter. It's a definite stress test focusing on CPU primarily.
See a picture here of the map in the middle of a test split screen ( I removed the UI for the pic). Any test scores that seemed strange in results were rerun up to three times to make sure results were valid. All these tests were run with vsynch off and no minimap enabled.

The Graphs:
I decided to show min/avg/max fps. I personally like watching fps over time, but they are messy to look at and people wouldn't take the time to analyze them.

Before we start, I can only say that the effect of this tool is even beyond what these numbers show, because there is no way to show the impact of 10 fps jumping up to 25 while in game when lots of units are in a game.

Core 2 Duo at 3GHZ, 2GB RAM, 8800GTS



Maximizer doing it's thing!
One thing that is always evident is minimum fps goes up and this is huge when considering this particular test because it has some really grueling points.

4xAA and AF including Split Screen tests.



There is no greater benefit with the Core maximizer than to dual monitors and split screens. This is because as I have said all along, the rendering pipeline is on CPU 0 and and by default it was too congested. Here we are seeing more than double min frames (think grueling fights) and an average of almost 50% better avg. performance for free! Every split screen and dual monitor test shows the same great performance increase like that. Ofcourse that is in reason, dual moniors can be very taxing.

The almighty war between Vista64 and XP using same hardware:



Maximized means maximizer enabled, the other is a normal run.
The line graphs, plotted over time every second, do best to show the grueling match in the middle of the test. XP wins the day.

Here is Vista64 vs XP in Split Screen



I should take this time to make the point that 1280 is quite problematic for SupCom. Such a common resolution, but all tests on all suites consistently showed 1280 to show uncommonly bad performance at that resolution in particular. 1680 and even 1920 can be preferrable at times, especially when the battles get grueling. Unknown if this is due to the game or drivers somehow.

Vista is always slower than XP, the maximizer really takes the day here with the XP and split screen. This kind of benefit is seen when running the 3D minimap as well with another render in operation. The other thing to note is Vista showed overall less improvements than XP in each and every test, but that is likely due to just the overall inefficiency of Vista to feed the CPU properly in my experience. But Vista users will needed benefit with Maximizer as well.


Core 2 Duo 1.8GHZ, 2GB RAM, 8800GTS



These tests on same hardware showing a default clocked C2D 6300. Here is that 1280 problem showing up again. When I first saw it I reran tests, then got used to seeing it in various tests. One thing about the CPU at this speed is it really cannot feed the GPU enough. Min fps again is showing killer increase. Maximizer does it's thing again across the board.

Another Graph over time with the 1.86 GHZ C2D:



These graphs showing fps per second through the test really show the gritty details, which I like most. In the middle of the test when all units are fighting on multiple fronts is where you really see the benefit. Here is where you also see normal SupCom tank.

P4 3GHz, 1GB RAM, Nvidia 6800GT

When I first ran the CPU stress test on the P4 3GHZ I was laughing because it was hovering around 2 fps in the middle of the test. I thought i was going to have to use perftest instead for this box because the test was too grueling, but imagine my suprise...



If someone told me that hyperthreading technology can get this kind of boost I would have called them confused. But wow! Double and almost triple avg fps on a very grueling CPU test. I was flabbergasted.

Thanks to Glowie for reporting this hyperthreading increase earlier in the thread it made me look at the P4. There are alot of people with hyperthreaded CPU's that can get some good benefits from this. 1GB of RAM with XP here was really horrible in this test. I really believe over 1GB is required for anything but the smallest of games or performance will really choke due to disk thrashing.

That's it for the graphs, I have too many of them really, so I just showed the highlights so I can move on to other things. In over 50 some tests it never performed worse but always better, showing best performance increases with tons of units and grueling battles. Where units start to hitch in Supcom, they become smooth as butter when maximized. When sound starts to crackle, you can instead start hearing every little tiny machine noise in the bases.

The other night I was giving Sorians new AI a spin and my game was really started tanking to like 10 fps and I was like duh, I hit the hotkeys and it is just hard to describe how it weent up to the upper 20's. It's like you got a new hardware upgrade in a seconds time.

Hope you guys enjoyed the benchmarks it was alot of work to compile it, but I had to see the improvements for myself and I thought it would be valuable to many of you who wanted to see them too. Some of the Vista and split screen tests are not that common so I wanted to get them in there as well.

Keep tuned to this thread so I can tell you when to throw away the current testing Core Maximizer for a newer one. It's been found that it doesn't always work 100% reliably.

Enjoy!

BTW: I am still looking for testers to set aside an hour some evening or weekend for online play. PM me if interested in testing and seeing where the tool may help or if it hinders as workload changes. If you are semi computer literate and have dual cores or a hyperthreaded CPU, PM me if you can try and set aside an hour some evening or weekend.

wow, great work
i guess i should switch from 1024.768 to higher res?
if u need e6600 with 9800 pro i can be a tester but only if it runs by itself and i dont have to babysit (not home for long periods of time )
also is it possible that maximizer is less efficient in vista coz of better workload spread? (i think devs said that)

I think I actually just finished mentioning how inefficient Vista was in another topic. Yeah vista doesn't use as much CPU time on the cores, some strange overhead apparently, maybe on the API level.

As for testing, thanks but I would need people engaged for the entire test.

What timezone are you in MadBoris?

This is amazing, Great Job!

We know have a script/mod master for Supcom!

(except it either doesn't work for me or my cores are already pretty balanced)

MadBoris,

I read this entire thread (every word and every graph) with intense interest. I have two dual core CPUs in my machine (the 2.0GHz Woodcrest/C2D Xeon 5130 with 4MB cache and 1333MHz FSB). I also have quad channel RAM (four 1GB DIMMs of DDR2-667). I don't overclock because I use this for things that can't tolerate a crash or broken hardware. The last time I overclocked anything was an AMD 486DX133 to 160MHz, but I only did that because I knew it was inexpensive to replace and looking long in the tooth in the days of the early Pentiums.

My graphics are my bottleneck, for sure. I'm currently running Nvidia Quadro NVS 285 business graphics card (hey, I bought it with the system and the system is for work first, play second). I'm itching to get a different video card now that I'm playing SupCom, but I keep eyeballing those dollars that I would spend on a video card and dumping them into my investment accounts instead. Right now, I just have to live with my 4 pixel pipelines until I can justify taking away from my investments to improve playtime.

Please take what I'm about to say with a grain of salt. I do some statistics and probabilities modeling with PERL, some user space ANSI C programming, some Visual Basic, and I've done rather extensive kernel debugging with FreeBSD 4.4 to 4.8 (ducked out since then for lack of time) grappling with some SMP issues on large memory systems. I also do web server and database optimizations on an almost daily basis. I am not familiar with thread programming or other low level programming, but I do have a high level understanding.

As I was reading, my mind wandered a bit and I began thinking that maybe part of what is going on is that you're taking some cache contention out of the picture for your graphics driver. Put another way, the graphics driver requires the CPU to feed it data and the CPU can feed the graphics driver faster when the graphics driver code can sit in CPU cache without getting blown out by a bigger/hoggier process.

I was unable to tell from your graphs which threads were running on which processors (I might have missed something). I know from my SMP kernel debugging days that some processes (at least with FreeBSD) were not allowed to roam off of CPU0. Often times, they were low level drivers that were sensitive to timing issues or were responsible for managing processes that were allowed to roam.

Is there a way you can determine what CPU affinity your graphics driver has (assuming that is msvcr80.dll) versus other threads during your tests?

The reason that the AMD CPUs wouldn't benefit as much from this (I recall a few posts in this thread stating that), if you buy into my theory, is that both cores have a separate dedicated L2 cache. With the C2D, you have shared L2 cache and code dynamics in one core can blow out the cache for the other. Maybe all that is going on is you're allowing the more cache sensitive processes to get more CPU time on the CPU they're forced to use and thus sit in cache more than other processes which are not as sensitive to CPU cache dynamics. In such a manner, you could have a net performance increase, even accounting for the slightly poorer sim score. I suppose it's even possible that the way the threads contend for cache changes based on which cores are shared by which threads.

Hopefully I'm making sense.

I just thought I'd toss that out there for you to chew on. If I'm out in left field, let me know. I don't have a problem with that.

I've noticed that under the most extreme circumstances (without your fix from this forum thread), I can only get up to 59% total CPU utilization which is 100% on core 0 (25% of the max total), 80% on one of the other cores (20% of the max total), 40% on another core (10% of the max total), and like 16% on the last core (4% of the max total). It varies which core gets which load, but it is pretty consistent that core 0 is maxed out.

I am willing to run some tests on my machine if you send me the details on how to duplicate your tests. It's not a true quad core in the sense that there are two cpu sockets for the four cores versus one socket with four cores, but it operates the same way from the perspective of the OS. Hey, at least I get quad channel memory this way with two distinct FSB paths to memory. Granted, when true quad core CPUs finally come down the pipeline with unified cache for all four cores and/or all four cores on one die, that will be a different scenario, but for now all consumer quad core chips are two dual core dies on one socket.

Andrew Kinney

Cool .... very cool.

Thanks to you the preftest runs at my opteron 175 about 80% both CPUs

without your amazing programm I got 99% and 19% Usage of CPU 1 and CPU 2.


Difference from 14188 (Maximized) and 13230

single core 4000+ I got 12047

All at 1400x1050 Med Fid,Text,Det, Render Bloom render Sky, no shadows. no AA.

(1950GT + 2GB RAM DUAL channel)



Hey does it work only for SC or also for some other Games ?
And why can't I leaf it on at Windows startup? Are there any bad aspacts?


btw.... GREAT GREAT WORK !

Does this work with hyper threading too? Because my proc. isn't dual core but supports hyper threading which is almost the same i think.

See the post 7 replies up.

Thx, now i don't have to get a new processor for this game

Andrew,

I just lost my post after I was done, arghhh. Fortunately, I make incremental saves by habit in big posts but I lost alot. Let me try again.

I value your input, thanks for reading.

You are right there is no chart showing actual threads CPU affinity before or after, only on a module usage level in the first topic, which do show the actual modules getting spread across cores.

I already had the data, so here is a graph showing thread CPU affinity changes:

Before (normal SupCom)



After (tool used)



Threads are sorted in order of CPU 0 usage. In the Before pic the supremecommander.exe thread lives completely on CPU 0. It's dependant modules in order of cpu usage are mohoengine.dll (multi purpose), hal.dll, d3d9.dll, gpggal, d3dx_931.dll, etc. Primarily rendering control and yet the largest user of CPU. The second thread is the actual mohoengine.dll which has dependencies in the following order of cpu usage LUAPlus1080.dll (big margin), shsmp.dll, msvcr80.dll, msvcp80.dll, gpgcore.dll, etc. Apparently the sim thread.

The After pic shows all threads getting more CPU time, except xactengine because it always got what it wanted at priority 15, so now the threads are not starved and having to contend with the CPU 0 wall, while all having a smaller slice of pie and supremecommander.exe suffereing at a consistent normal priority. This is where the primary boost is coming from, giving these threads room to breathe.

As to sim number going down, I have noticed there is an interrelationship with sim and render always. This seems to be a higher level code relationship rather than hardware where if one improves the other goes down. I've come to a mental roadblock on this actual cause because I don't have enough info but it does not look hardware based in my testing, or atleast their is a much larger higher level bottleneck or relationship in the code in my opinion. I've even inquired about it, but for right now I'll have to just go by my observations. I hope I am wrong on the cache because I too want to get a quad with large independent caches and am hoping for more. But I think the cache hit is a small one compared to something larger and higher level.

I'll preface all of this with I don't know for sure on the real effects of cache because I stopped digging too deep because digging any deeper would take alot of investment of time and thought to come to accurate conclusions, along with some needed insight to the code and engine itself. There are some low level things on the CPU's themselves that can be measured, but again, it takes too much time to do all this for free with the only end result is a satisfied curiosity on my part. Not worth it.

I have thought about the effects on cache quite a bit early on in my testing. I alluded to the shared cache on C2D's possibly becoming a new bottleneck actually. If you think about it, now that the threads are more spread out and the modules themselves are performing their functions across both cores, their is an elevated contention for that shared cache as each core needs to be fed. Also each is now likely making many more cache hits which are asynchronous. It's one of the reasons I called this a not so elegant solution and inefficient for the longterm. But those inefficiencies, are more than made up for with the immediate benefit of offloading CPU 0. So I believe the overall cache hits have increased, or at the very least in having to more often switch from core to core, which with a shared cache probably isn't pretty at all.

Your overall CPU load, as you mentioned later on, is something you will see grow with the tool because the threads that are running on Core0 are starved and in contention (this is apparent in my earlier graphs of overall cpu time before and after the split). When the tool gets enabled, overall CPU usage increases as the threads are able to now get fed with what they can take. I just checked some data and it showed about 78% overall unhalted CPU cycles before the spread(default supcom), then 88% after the thread spread, this is for the overall 2 cores. Test polling began after a 15 second delay of the process starting to load a script, so it doesn't reflect loading time of the game and map.

As a side note, there is something I was learning about SupCom's handling of threads in my recent round of testing just by observation. As I'm sure you know, as you train yourself to see patterns, you become more sensitive to the finer changes and nuances. I was seeing different behaviour with the way normal SupCom would startup with a CD2 clocked at 1.86Ghz instead of 3GHz. I'm not sure if they have somehow built in some throttling mechanisms on their own (this was somewhat alluded to once), but core usage affinity 'seemed' to be affected (by looking at taskmgr, I went no deeper). I also saw those strange performance issues that I mentioned crop up even more often with the slower clocked core. I had to rerun SupCom control tests more often because in some tests SupCom would start up with units just stuttering with slight pauses and actually cut fps in half (like 5 fps) during the part of the benchmark where multiple battles are at their peak. I invalidated those tests but the fact is, that is happening day to day for people and I didn't hunt down the cause but I am making it known now. So just some strange things are definitely apparent there (these are the things I couldn't account for months ago when the same tests would perform differently and take different lengths of time to run). My point also is that this may account for the some different behaviour of AMD CPU's as the scheduler or SupCom is apparently doing things differently,maybe for slower functioning CPU's or even possibly the AMD timer has a part to play. I'm really not too sure of how much difference there really is between AMD and Intel here to be honest, not enough feedback and no public common methodology for testing in order to compare results. Besides, not everyones AMD CPU load is the same with normal SupCom so there are some local platform differences. As you say, even cache may have a part to play here, but the rabbit hole goes a bit too deep for me to guess at this point beyond what I have said, atleast of which I'm pretty sure on.

It's always good to have more heads than one look into this stuff, fresh perspectives and all. It is quite an ordeal to dig through, I did because things didn't add up by looking at the surface. I will PM you at some point and share some of my methods if you desire to look into it yourself.

/me wants!

Please?

My dinky little Opteron 165 arrived today (finally found somewhere that sold them cheap-ish, hurrah), and one of the first things I wanted to try out after upgrading was SupCom.

Unsurprisingly, it runs a lot better than it used to on my 3000+

After I'd dazzled myself with the much-improved performance, I figured I'd give your Maximizer program a go. I ran one perftest without the maximizer, and then another one with it. Somewhat surprisingly, my composite score didn't change at all... but that doesn't really tell the whole story, as my average frame rate went up from 45 to 53ish - it was visibly running far smoother when there was lots going on.

As an added and somewhat surprising bonus, the sounds seemed to glitch out much, much less than they did beforehand. I'm not quite sure why (I could guess, but you probably have a better idea than I do!), but this is a godsend as far as I'm concerned, as occassional random bursts of noise, pops, clicks and screeches are a bit annoying.

So... yeah, basically I'd just like to say that it seems to work like a charm so far (okay, I only tried it once... I'll post again if I notice anything weird going on), and please keep up the awesome work