So, how EXACTLY does a Dual COre A64 decide what get's done?

[Zak33]

I've got my X3800 in, and it's gone straight to a rather happy 2500, so Zak's pleased with stage one very pleased.

But I don't understand how/what decides on the CPU core loadings.

Reason I ask.... IL-2 latest version, 1946, got loaded straight up and it was very much faster than on my Opteron, and tbh I've noticed this before when I borrowed a twin core from David.

So I ALT TAB'd out and looked at the CPU loads (Cntrl/Alt/Del) and both were working in a spiky frenzy

Dont mind...happy they're both doing their share: but how/ what decides?

Is it the BIOS on my AUS A8N-E or is it Windows XP?

[Agent]

Its done at the OS level. If it chooses, the OS could totally ignore one core (or on the flip-side, may not support multi CPU, but this shouldn't be an issue today).

Its a mixture between the Kernel and the application.
Most applications will be need to be dual-core (or however many) aware, and written in such a way that it uses both. Not every app will benefit from multiple cores, it depends on what type of data its processing.

Even though most games don't support using 2> cores, it helps as the OS will (in most cases) load balance the OS stuff on the other core.

As for the programming behind it, it can get pretty complex - way beyond what I can explain accurately.

[Zak33]

OK...so XP decides.

Now, I presumed that XP was taking up some resources, and therefore the game would get the other core for the majority of it's running.

So I booted IL-2 (which is running in the background now too ) and kep the Windows Task Manager on top for screenies.

This is the consistent pattern after over half an hour.



that screenies is shrunk from 1280x960

Apart from the huge FPS I'm getting now that I dont seem to be so CPU bound....look at the cores.

[Zak33]

OK...weirder.

I stop playing the looping tracks but leave the game menu on.

One core gets busier...the other backs off!



So, now I'm interested. What gets busier? What gets less busy?

Is the game awaiting a futher instruction, but now the 3d apps and sound are off the load is varying?

I'd love to see other people's core running

[Funkstar]

I don't know a lot about this, it's been a long time since i used to devour all the techy articles in Byte magazine (the dead tree version was the greatest magazine ever) and we SMP wasn't dealt with a lot at Uni.

But here's a theory anyway. Perhaps the menu coding is really in efficient and it hogs the CPU for no good reason. This would also be in one thread so it can quite happily cane one core and ignores the other. After all, why would the menu code need to be good? as long as it works it has no impact on the game itself.

When the game is running properly, the code is nice and streamlined. You have different threads running different parts of the game (sound, graphics, AI, etc.). XP is constantly in the background making sure all the threads are shared out and the processors, cache and memory are all being used as efficiently as reasonably practical.

Just a theory mind

[Zak33]

good theory....wonder if anyone else has any thoughts?

[TiG]

Games are pretty hard to make multicore capable, simply because there is a big unbalanced set of work.

Plus you then have all the branch loops of you doing something the system isn't planning for. Oh wait i don't need all that info, i need to load your normal runway with a new plane etc

AI, Sound are most likely less processor intensive than physics/graphics transit of textures etc.

Really if you want to understand multicore then you really need to look at why you originally have it, Databases, media processing.

Something you can break the tasks out and give to multiple cores to go away and crank the handle on. Multiprocessors on the desktop environment really just don't match out the real world requirements.

Just look at how hard you have to work outside of a game to get a Core2Duo working, let alone a quad.

I do wonder when we will actually come up with some applications that really need this and much much more processing, (Immersive Virtual reality etc)

Oh and most of the current processing situations have a master processor. Its complicated but you are talking neural nets if you want to make them all "equal"....

TiG

[directhex]

it's entirely up to the OS to decide where to schedule work. at its simplest level, it should be asking the question "which CPU do i have the most free time on, i'll put new things on there", whilst also keeping an eye on processor migration (an app moving between processors takes a significant speed hit, but at the same time being tied to an already loaded cpu is bad)

when you have more than one socket, things get more interesting, as you start to have issues of memory placement (with AMD, each CPU "owns" some sticks of memory, and you need to make sure an app runs on the same processor which owns the RAM containing its data).

think it's confusing now? try in this setup:

orac:~ # grep processor /proc/cpuinfo 
processor  : 0
processor  : 1
processor  : 2
processor  : 3
processor  : 4
processor  : 5
processor  : 6
processor  : 7
processor  : 8
processor  : 9
processor  : 10
processor  : 11
processor  : 12
processor  : 13
processor  : 14
processor  : 15
processor  : 16
processor  : 17
processor  : 18
processor  : 19
processor  : 20
processor  : 21
processor  : 22
processor  : 23
processor  : 24
processor  : 25
processor  : 26
processor  : 27
processor  : 28
processor  : 29
processor  : 30
processor  : 31
processor  : 32
processor  : 33
processor  : 34
processor  : 35
processor  : 36
processor  : 37
processor  : 38
processor  : 39
processor  : 40
processor  : 41
processor  : 42
processor  : 43
processor  : 44
processor  : 45
processor  : 46
processor  : 47
processor  : 48
processor  : 49
processor  : 50
processor  : 51
processor  : 52
processor  : 53
processor  : 54
processor  : 55
processor  : 56
processor  : 57
processor  : 58
processor  : 59
processor  : 60
processor  : 61
processor  : 62
processor  : 63
processor  : 64
processor  : 65
processor  : 66
processor  : 67
processor  : 68
processor  : 69
processor  : 70
processor  : 71
processor  : 72
processor  : 73
processor  : 74
processor  : 75
processor  : 76
processor  : 77
processor  : 78
processor  : 79
processor  : 80
processor  : 81
processor  : 82
processor  : 83
processor  : 84
processor  : 85
processor  : 86
processor  : 87
processor  : 88
processor  : 89
processor  : 90
processor  : 91
processor  : 92
processor  : 93
processor  : 94
processor  : 95
processor  : 96
processor  : 97
processor  : 98
processor  : 99
processor  : 100
processor  : 101
processor  : 102
processor  : 103
processor  : 104
processor  : 105
processor  : 106
processor  : 107
processor  : 108
processor  : 109
processor  : 110
processor  : 111
processor  : 112
processor  : 113
processor  : 114
processor  : 115
processor  : 116
processor  : 117
processor  : 118
processor  : 119
processor  : 120
processor  : 121
processor  : 122
processor  : 123
processor  : 124
processor  : 125
processor  : 126
processor  : 127
processor  : 128
processor  : 129
processor  : 130
processor  : 131
processor  : 132
processor  : 133
processor  : 134
processor  : 135
processor  : 136
processor  : 137
processor  : 138
processor  : 139
processor  : 140
processor  : 141
processor  : 142
processor  : 143
processor  : 144
processor  : 145
processor  : 146
processor  : 147
processor  : 148
processor  : 149
processor  : 150
processor  : 151

[awm]

What is that thing "orac"?

[kalniel]

it's entirely up to the OS to decide where to schedule work. at its simplest level, it should be asking the question "which CPU do i have the most free time on, i'll put new things on there", whilst also keeping an eye on processor migration (an app moving between processors takes a significant speed hit, but at the same time being tied to an already loaded cpu is bad)

when you have more than one socket, things get more interesting, as you start to have issues of memory placement (with AMD, each CPU "owns" some sticks of memory, and you need to make sure an app runs on the same processor which owns the RAM containing its data).

Pffft. Try Grid

Regarding AMD, each core *can* access the other cores cache, there's just a latency hit for doing so.

Where it really gets interesting is when you actually need all the threads to talk to each other. Games and so on generally don't involve many threads that have to do this - because it's darn hard to write and you want to do something that as much of your market as possible will be able to use.

Instead you typically have the main engine or render process being pretty single threaded so it doesn't have to worry about waiting for threads to finish to proceed, and you offload sound, AI, physics which each have their own descrete threads to other cores where possible (supreme commander is a great example).

Simulating molecular movements typically involves a fair amount of data moving across nodes, and this can be a huge factor in working out the compute resources needed (you don't want to have to track data between Manchester and Oxford!)

[directhex]

Pffft. Try Grid

clustering is another kettle of fish entirely.

Regarding AMD, each core *can* access the other cores cache, there's just a latency hit for doing so.

as with any NUMA architecture

[Zak33]

It's just weird, that IL-2, a game thats based on a very old engine, seems to thrive on my new CPU.

It did the same when I borrowed a 4800 dual core from David 6 months ago.

Eitherway....I'm pleased as punch

[directhex]

It's just weird, that IL-2, a game thats based on a very old engine, seems to thrive on my new CPU.

It did the same when I borrowed a 4800 dual core from David 6 months ago.

Eitherway....I'm pleased as punch

it's entirely down to how the game is written as to how much it'll like more than 1 CPU

typically, game code looks a bit like this:

start:
do audiostuff
do graphicsstuff
do inputstuff
go to start

the multi-cpu ideal looks a bit like this:

audio:
do audiostuff
go to audio

graphics:
do graphicsstuff
go to graphics

input:
do inputstuff
go to input

start:
start up independenet thread running "audio"
start up independenet thread running "graphics"
start up independenet thread running "input"

the latter example running fine on 1 cpu, but being best on 3. it's a gross simplification, but that's the ideal. some games are written with threading built in - but it's harder to code, so not many are. typically, what happens is the OS simply schedules all game-related stuff on one CPU, and OS-related stuff (like antivirus, and so on) on another