ISBoxer 2 - About CPU allocation estimates

[MiRai]

In addition to what is currently shown, I want to add in how much MHz each Slot can be expected to get from the CPU cores. For example in the screenshot Slot 5 gets 1/3 of CPU 3 and 5 and 1/2 of CPU 8, which on my 2.7GHz adds up to 900+900+1350 = 3150MHz. I might just list this in the Per-Slot settings next to "CPUs for this Slot".

I am slightly intoxicated at this current time, but I don't think it works like that and it'd probably be misleading to add that information in that manner. I don't think it's calculated like that since the core's clockspeed is what determines how fast it handles its set of instructions, and it doesn't split its current MHz between separate processes. Even if it did you still wouldn't be able to reliably give that number since you'd have to account for other programs running in the background like recording, streaming, AV, etc.

It's almost like saying that each core of an 8-core CPU running at 4GHz is getting 500MHz each, and by shutting off 7 of the cores the main core will now be running at its fully rated 4GHz, which just sounds really weird (and incorrect).

Sorry if I am reading that incorrectly, this drink is delicious.

[lax]

When you said you replied I assumed it was something nit picky about the GUI. I program CPUs go back to encoding your videos.

Look at the visualization, I'm just assigning a quantity to what you're seeing on the screen. It's not like each thread locks down the CPU for a whole second at a time, you get much smaller slices of time on your assigned CPU. Each core can run something different at any time, and that's threads not processes. Each core has 2.7GHz available and we can try to fill that up with the game instances. If only one instance is running on a core, it can theoretically expect 2.7GHz out of that core. If there's two, it can theoretically expect only half of that, or about 1.35GHz (again, per core). Whether it reaches it or not due to running shit in the background isn't really relevant. But 8 threads on an 8-core 2.7GHz CPU can theoretically get 21.6GHz of total CPU time.

If Joe Schmoe is running 20 game instances on his 4 core 4GHz CPU, he can assume that each of those game instances is only going to have the equivalent of about 200MHz per core available to it; potentially up to about 800MHz total between the 4. When he asks why it is running slower than when he ran 10 on the same hardware, the answer as far as CPU is concerned is because instead of a possible 1600MHz total between 4 he now has 800MHz available.

Obviously in the real world things are not all the same in every game instance, they will run at different rates (may yield CPU time), Windows uses some CPU time, DWM might use CPU time, etc. And on top of that, different games will operate differently because of different threading models, so even if I say 3150MHz possible for Slot 5, that will mean something different for WoW than for Rift or SWTOR.

So, do you have a better idea, or are you saying I should just put some finishing touches on the visualization (e.g. to see the blocks percentage-wise) so they don't have to think about numbers?

[bob]

In addition to what is currently shown, I want to add in how much MHz each Slot can be expected to get from the CPU cores. For example in the screenshot Slot 5 gets 1/3 of CPU 3 and 5 and 1/2 of CPU 8, which on my 2.7GHz adds up to 900+900+1350 = 3150MHz. I might just list this in the Per-Slot settings next to "CPUs for this Slot".

I am slightly intoxicated at this current time, but I don't think it works like that and it'd probably be misleading to add that information in that manner. I don't think it's calculated like that since the core's clockspeed is what determines how fast it handles its set of instructions, and it doesn't split its current MHz between separate processes. Even if it did you still wouldn't be able to reliably give that number since you'd have to account for other programs running in the background like recording, streaming, AV, etc.

It's almost like saying that each core of an 8-core CPU running at 4GHz is getting 500MHz each, and by shutting off 7 of the cores the main core will now be running at its fully rated 4GHz, which just sounds really weird (and incorrect).

I have to agree with MiRai on that one. It is a nice idea to try and illustrate the allocation to each slot, but with hyperthreading being approximately 30% of a real core on average (highly variable depending on what is running on it), and variable GHz on cpus depending on heat and number of cores in use, not to mention other background programs, the value is going to be all over the place.

Maybe just a bar graph estimating CPU allocation comparing to each other without putting numbers on it. You'll still have to calculate an HT factor, which will be different if the game is on the "real" core and the associated HT core, or just on an HT core on it's own. In fact that is probably something you should red flag is when an HT core is assigned but not the associated "real" core.

I also think you should make the All Slots use All Cores the default, as that way Windows is left to manage it, just like "if I launch them all outside of ISBoxer...."

[lax]

I know, right? And then there's the new generation of AMD CPUs. They might as well not call them cores or count in MHz anymore.

[MiRai]

Look at the visualization, I'm just assigning a quantity to what you're seeing on the screen. It's not like each thread locks down the CPU for a whole second at a time, you get much smaller slices of time on your assigned CPU. Each core can run something different at any time, and that's threads not processes. Each core has 2.7GHz available and we can try to fill that up with the game instances. If only one instance is running on a core, it can theoretically expect 2.7GHz out of that core. If there's two, it can theoretically expect only half of that, or about 1.35GHz (again, per core). Whether it reaches it or not due to running shit in the background isn't really relevant. But 8 threads on an 8-core 2.7GHz CPU can theoretically get 21.6GHz of total CPU time.

If Joe Schmoe is running 20 game instances on his 4 core 4GHz CPU, he can assume that each of those game instances is only going to have the equivalent of about 200MHz per core available to it; potentially up to about 800MHz total between the 4. When he asks why it is running slower than when he ran 10 on the same hardware, the answer as far as CPU is concerned is because instead of a possible 1600MHz total between 4 he now has 800MHz available.

Obviously in the real world things are not all the same in every game instance, they will run at different rates (may yield CPU time), Windows uses some CPU time, DWM might use CPU time, etc. And on top of that, different games will operate differently because of different threading models, so even if I say 3150MHz possible for Slot 5, that will mean something different for WoW than for Rift or SWTOR.

Disclaimer: This is a long post, but I want to show how confusing this is to me which will hopefully give you insight to some potentially ridiculous claims that users might make (or assume) if you break up CPU time by MHz.


What I was getting at yesterday was that I have never seen CPU time broken up by MHz before, and as you say, there are way too many other factors that affect the performance of a game client which cannot be realistically accounted for (or even calculated). I think showing how much theoretical MHz someone can expect out of a core for a specific client is just going to lead to confusion, and people might end up trying to then "calculate" how much performance they should be getting with just that number alone, or they might be afraid that they have "idle" MHz or something crazy like that.

This kind of falls under your example above about Joe Schmoe because if he just turned down his background framerates and didn't sync his resolutions, then he could easily increase the performance of his main client using the same CPU core setup, but... I highly doubt you could actually play the game with a CPU which only had 200MHz at its disposal.

To piggyback on this example, if you take a look at a game like WoW it lists an Intel E6600 as one of its minimum requirements under Processor, but that CPU runs at 2.4GHz. While I imagine that Blizzard is just playing it safe with its minimum spec, they're playing it safe by 2,200 Mhz (and an extra core) if we're assuming that WoW can run on 200MHz alone (which it couldn't).

I'm not trying to be a jackass and ride this topic, but saying that you can assign each client to a set amount of MHz almost sounds the same as telling someone that if they have two 4-core CPUs in a dual-CPU system, each running at 4GHz, that they somehow now have 8GHz at their disposal. This is, of course, untrue and they just have 8 cores running at 4GHz each.

Or, another example that I thought of while writing this reply, was that if you were driving an 8-cylinder vehicle and doing 160MPH, that each cylinder would be accounting for 20MPH. This example sounds crazy to me, but this is where I'm coming from and how I'm viewing this CPU MHz topic.

So, do you have a better idea, or are you saying I should just put some finishing touches on the visualization (e.g. to see the blocks percentage-wise) so they don't have to think about numbers?

If you're going to show something, then I think maybe showing a percentage rather than a specific amount of MHz would make more sense. This way people have some sort of visual showing them that they're going to get shitty performance if they keep cramming Slots onto a specific core (the percentage would keep dropping lower and lower), but even then it's still misleading to someone like me because I know that CPU time and MHz alone do not fully account for overall performance.

I also like bob's idea about warning a user if they've set up hyper-threading incorrectly and using all slots > all cores as the default.

DIDN'T HAVE A LOT OF TIME TO PROOFREAD SINCE IT'S TIME TO WORK OUT!

[lax]

I'm not disagreeing with you that the user might be confused by seeing the number in MHz. Clearly, you and Bob are

You're also right that there are many ways to achieve a specific MHz number by adding those up, and not all of those ways are equal. Maybe I can just hide the numbers when there's not enough game instances to really tax the CPU, or when they're trying custom CPU Strategies, so they don't try wonky things to try to meet some minimum number of MHz or think one instance of WoW is going to go many times faster by adding more cores that have no other load.

if they have two 4-core CPUs in a dual-CPU system, each running at 4GHz, that they somehow now have 8GHz at their disposal. This is, of course, untrue and they just have 8 cores running at 4GHz each.

Hz is defined as "cycles per second". If you have 2 4-core CPUs and all of those CPUs are running 4GHz, they literally have 8x4000MHz of processing time (assuming these are all real cores etc etc, yes guys), which is way more than 8GHz. This is why they add CPUs and cores, because they add to the amount of processing you can do in a second (which again can be counted in Hz; if I get 25% of a 4GHz core you can say I get about 1GHz of processing power, and this means that I am getting about 1,000,000,000 cycles per second from the CPU core). They don't just cram as much power onto one core as possible anymore because simultaneous multi-thread execution is f'ing awesome.

I think what you mean to say is that if you put one instance of WoW on this 2x4 4GHz, which REALLY DOES have 32,000MHz at its disposal (you know those supercomputers they count in petaflops? floating point operations per second. they add the numbers from many cores together, this is absolutely the same concept as Hz), that WoW is not going to go 8 times faster than it would on 1 core running 4GHz. This is absolutely true! ... but not for the reason I think you're trying to describe. The game is just not designed to take full advantage of that; it will be heavily dependent on one or perhaps two threads, and it will yield the CPU to wait on other things -- the CPU in question is not going to be taxed by this 1 instance of WoW, and pretty much only for these reasons. But for example if you were to look at a CPU bitcoin miner instead (just for the sake of example, not because you actually want to run a CPU bitcoin miner when you have these sweet GPUs), it can use each core to process hashes at roughly the same rate. It can do about 4 times faster with 4 cores than with 1 core, and about 8 times faster with 8 cores than 1 core. WoW would need a redesign of its threading model in order to achieve the same benefit, and even then the GPU is still an issue. Likewise, if the bitcoin miner were to put 2 mining threads on 1 core, now each of those threads can only reasonably expect 2GHz of a 4GHz core.

I highly doubt you could actually play the game with a CPU which only had 200MHz at its disposal.

There is nothing magic about the MHz that is going to prevent you from trying, or begin to allow you to try, to play the game, it's just going to go slower, because it has less processing power per second. They SHOULD be making a minimum CPU speed recommendation based on the number of cycles their product is expected to use, but the reality these days is that the minimum is usually architecture rather than speed. I mean, purely speed-wise you could still play this shit on an Athlon XP, but then you don't even have SSE2. The game might not be playable on that architecture because it may be compiled to require SSE2 (pretty reasonable). So they end up picking a real chip for people to compare to. Otherwise the only reason your statement is probably true is because if you find a 200MHz CPU these days it's probably not x86 or x64, and WoW is built for x86 and x64.

The more instances of WoW (or another game) you're running, the more similar it becomes to the simple bitcoin miner example, simply because the CPU should be completely taxed... If you're running 100 instances of WoW, what percentage of CPU time do you think each one is likely to get? Probably about 1%. Which means that if you take an average second, 1% of the cycles is probably applied to each instance. On a 1-core 4GHz CPU, that is 40MHz. That is super slow, and each instance is very likely to get less than 1 FPS. I'm not using any crazy math there...

Or, another example that I thought of while writing this reply, was that if you were driving an 8-cylinder vehicle and doing 160MPH, that each cylinder would be accounting for 20MPH. This example sounds crazy to me, but this is where I'm coming from and how I'm viewing this CPU MHz topic.

You don't count engine output in MPH, you would count it in HP and/or torque, and each cylinder accounts for some portion of the power output due to accounting for a portion of the displacement. If you shut off half of your cylinders you're going to lose that half of your power output, but this isn't the same as saying you could only go 80MPH instead of 160MPH (noting that in the bitcoin mining example, this is almost exactly what would happen by shutting off half the cores). Here on Earth, pushing a vehicle faster and faster requires more and more power output, which is why getting into space is hard. But in terms of this CPU conversation, we're talking HP and not MPH. I'm trying to show how much horsepower is available (MHz), and you're talking about how fast the car happens to be going at that time (FPS). Related numbers, but not the same thing...

Anyway, this is really a lot of reading and typing and I just spent forever on this instead of working. Clearly I should only show numbers like this idea when performance is expected to be poor.

[MiRai]

Okay, that was a lot to read, and while I could continue to argue from my, apparently clueless, point of view... Ultimately, what I'm saying is you've got two people here who kinda know their stuff when it comes to hardware and configuring things, and we're both completely confused by the idea of spreading MHz across multiple game clients. So, my questions are... Given what you've learned from the years of supporting probably thousands of users, how do you expect the normal, everyday user to feel when they see those numbers? What will they gain by seeing those numbers?

Besides that, I will say one last thing because I would like to be educated more in this area...

If MHz can be added together, as well as get spread out in the same manner as you're describing and are about to show in the Wizard of ISB2, can you point me to somewhere else that shows MHz being added together or spread out? Documentation of some sort? Stats on some website? I mean, I brought up the Supercomputer Top 500 before you actually mentioned it in your post to see if they added MHz together, but even with all the e-peen stroking stats that they give, they don't add MHz together. I realize that they show the "horsepower" of the computer as FLOPS, and that's exactly what I'm used to seeing, and even when Microsoft and Sony show off their new consoles they talk about the FLOPs as if anyone cares, but they still don't add the MHz together. Now, if you want to calculate the FLOPS of someone's CPU and then show them how many estimated FLOPS they can expect a game instance to receive, well I guess I'd be okay with that, but I still think it'd be weird.

I'm honestly saying this because I've never heard of this before and I do not understand this concept, and I currently feel like a religious fanatic who is being told that their god does not exist.

[lax]

how do you expect the normal, everyday user to feel when they see those numbers? What will they gain by seeing those numbers?

When I show the user that I expect their game instances to each have 50MHz of power available, I expect them to understand it will probably run like shit and not because I'm making up "this is probably going to run like shit" but because there is actual numbers.

If MHz can be added together, as well as get spread out in the same manner as you're describing and are about to show in the Wizard of ISB2, can you point me to somewhere else that shows MHz being added together or spread out? Documentation of some sort? Stats on some website? I mean, I brought up the Supercomputer Top 500 before you actually mentioned it in your post to see if they added MHz together, but even with all the e-peen stroking stats that they give, they don't add MHz together. I realize that they show the "horsepower" of the computer as FLOPS, and that's exactly what I'm used to seeing, and even when Microsoft and Sony show off their new consoles they talk about the FLOPs as if anyone cares, but they still don't add the MHz together. Now, if you want to calculate the FLOPS of someone's CPU and then show them how many estimated FLOPS they can expect a game instance to receive, well I guess I'd be okay with that, but I still think it'd be weird.

FLOPS and MHz are pretty directly related; FLOPS can be calculated by MHz if you know the approximate number of FLOPS per cycle on your hardware. But it's less useful here as a unit of measure because we're less heavily dependent on floating point operations than calculations that will typically run through supercomputers. It would be more effective for us to use IPS -- [generic] Instructions per Second -- instead of the specialized FLOPS measurement.

Adding FLOPS or IPS together is pretty much the same thing as adding MHz together. The only difference is that different chips process a different number of instructions per cycle, and I'm not interested in maintaining a table like this for ISBoxer to convert MHz to IPS.

Here is a chart that should probably help you: http://en.wikipedia.org/wiki/Instructions_per_second#Timeline_of_instructions_per_second; it gives both "D IPS / clock cycles per second" and "D IPS / clock cycles per second / Cores per die". It INCLUDES the #1 supercomputer from your list, along with desktop CPUs and such. Note the correlation between the two columns; the number on the left is the number on the right times the number of cores (except in a couple of cases, but the point remains).

Also while I'm at it, http://en.wikipedia.org/wiki/FLOPS shows an equation used to calculate FLOPS. It multiplies by cores.

[bob]

Okay, that was a lot to read, and while I could continue to argue from my, apparently clueless, point of view... Ultimately, what I'm saying is you've got two people here who kinda know their stuff when it comes to hardware and configuring things, and we're both completely confused by the idea of spreading MHz across multiple game clients.

Speak for yourself . I understand the idea, and even why, and even the how of the Mhz Madness; I just don't think it is the right one, but, it is not my product.

If MHz can be added together, as well as get spread out in the same manner as you're describing and are about to show in the Wizard of ISB2, can you point me to somewhere else that shows MHz being added together or spread out? Documentation of some sort? Stats on some website? I mean, I brought up the Supercomputer Top 500 before you actually mentioned it in your post to see if they added MHz together, but even with all the e-peen stroking stats that they give, they don't add MHz together. I realize that they show the "horsepower" of the computer as FLOPS, and that's exactly what I'm used to seeing, and even when Microsoft and Sony show off their new consoles they talk about the FLOPs as if anyone cares, but they still don't add the MHz together. Now, if you want to calculate the FLOPS of someone's CPU and then show them how many estimated FLOPS they can expect a game instance to receive, well I guess I'd be okay with that, but I still think it'd be weird.

I'm honestly saying this because I've never heard of this before and I do not understand this concept, and I currently feel like a religious fanatic who is being told that their god does not exist.

A supercomputer can be measured in Petaflops (Floating Point Operations Per Second). Quadrillions (a thousand trillion) of them, although most are still in TeraFlops or trillions of FLOPS. This number is not pulled out of thin air, but is the measured rate of each CPU/Core and how many FP operations it can do per cycle, multiplied by the number of cycles per second, and these results are all summed together. They get to the really big numbers by throwing more cores at it!.
e.g. Intel have developed a multi core chip which can perform 1 TeraFlops per core. And it has 80 cores, so it can perform 80 TeraFlops. The core itself runs at 3.13Ghz, so FLOPS and Ghz aren't 1 for 1 matches and in this case it appears that multiple FP instructions can be processed per core per second. Likely due to each core having multiple FP Units. Of course the FLOPS rating only stands true if that is all that the core is doing. If it does other stuff like memory reads/integer/context switch etc, then the FLOPs are reduced.


The reason why I disagree with the MHz numbers is probably more a puristic one that anything else. Mainly, it is because of how Windows does the thread scheduling and allocates Quantums to each thread.

The idea behind showing an estimated CPU allocation to each instance is good. MHz is just the wrong representation. It also would mean nothing if your game is GPU bound, or you happen to be running a single threaded process in the background (ITunes, I'm looking at you), and it just happens to have aligned on the same Core as your main slot.
This is why I think the best you can do is show some relative allocation compared to the other slots, and what will be will be, because people run all sorts of other shit on their computers, and if one of those shit things happens to be crappy ITunes, any representation you did show is now completely wrong.


p.s. IPS is just as fraught, as some instructions take multiple cycles, so you can only use an average IPS, and then it all depends on what you're doing.

[lax]

Relative allocation is easy for me to show (and the first idea I had), but I don't think it really gets the weight of the situation across to the user without providing a number. If you've got 20 game instances and you've got it set to put all of them on all CPUs, you already knew that each is going to be able to use about 1/20th. You're like yeah sweet, I've got 20 game instances running. But when I point out that this only allows about 200MHz (or whatever) per game instance now you're like "holy shit, that's terrible, no wonder it's slow when I'm running 20 game instances".

Whether this number is shown in the end or not, it is helpful to calculate things like this in order to provide recommendations to the user, and it is useful in estimating performance changes when adding x number of game instances. I can warn the user about expected poor performance, and save some support time of having to say "you've got 6 game instances on your i3, what did you expect to happen?" The number would come with added clarification.

It also would mean nothing if your game is GPU bound, or you happen to be running a single threaded process in the background (ITunes, I'm looking at you), and it just happens to have aligned on the same Core as your main slot.

The visualization would be equally inaccurate without numbers shown as with numbers shown... it's incorrect because it does not take into account that you have some process pegged to one of the cores, or sometimes you run bittorrent and assign it to cores 5 through 8, or you're encoding videos, or playing 2 other games outside of ISBoxer, etc. Numbers shown or not it's still the same data, I'm just taking into account the processor's speed rating.



Glad we all got all of that out of our systems. I'm working on the Party Module next.