• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

Multiple CPU Cores Logic...

Soldato
Joined
25 Nov 2007
Posts
5,581
Location
London
so after all the Dual vs Quad Threads ive come up with a question...

Certain programs only use 1 core, 2 cores and some use 4 cores depending on if it is coded for it...

to me this is not logical, its like having 4 huge guys and a man tells them to move some stuff, the other 2 sit down and drink beer while the other 2 do the work..

Why doesnt the processor take the Task, and Split it between all available cores, therefore not needing anything to be coded for multi core, but the processor itself would break down the workload. Making multiple cores scale very well..

I hope the question isnt simple to answer... :D
 
I think it's because the code needs to be executed in a certain order - so unless it's coded to allow for the fact that there will be more than a single core, Windows just uses one.

Vague I know, but i'm not 100% sure myself.
 
Because programs need to be coded to allow that and most are still not coded that way.

the whole point i was saying is that the processor should take the work and split it between 4 or 8 or 500 cores regardless of all software..

why rely on software?

for example 1 "controller" that takes instructions and splits it between the 4 cores.. the OS can see only 1 core but the processor splits work between all by itself (all built into the chip)
 
I hear this "multithreaded code required" guff all the time.

Doesn't seem to bother the 128 cores on my 8800GTX, I don't have one SP glowing white hot while 127 pick their noses.

The real logic of it is that it's easier to scam us morons by flogging us two/four/eight/512 slow old CPU cores instead of spending £1 researching faster cores.

The future, at this rate will be a box with one working core and 1023 sitting eating power and generating heat.

The only current benefit of dual or quad is that windows incessant cpu spamming, it's obsession with doing that's none of your business cos it's bill's computer not yours, doesn't knacker your games so badly.



cynical old git or what?
 
The real logic of it is that it's easier to scam us morons by flogging us two/four/eight/512 slow old CPU cores instead of spending £1 researching faster cores.

The future, at this rate will be a box with one working core and 1023 sitting eating power and generating heat.

The only current benefit of dual or quad is that windows incessant cpu spamming, it's obsession with doing that's none of your business cos it's bill's computer not yours, doesn't knacker your games so badly.

I agree with you, the multi core technology is a scam at best to make us feel we are getting more for the money when theoretically speaking unless 100% of software supports multi-threading it is pointless. :rolleyes:
 
I agree with you, the multi core technology is a scam at best to make us feel we are getting more for the money when theoretically speaking unless 100% of software supports multi-threading it is pointless. :rolleyes:

Its not pointless, if you have an aplication you use on a regular basis which supports multicore already. The problem is some applications are a lot harder to break down into "tasks" or "threads" than others.

A bank could easily have a multithreaded computer software working on bank balances, as it would assign 1 thread to be dedicated to each bank account, ensuring that all transactions are completed in the correct order.

But if you had several threads all working together on a single bank account, all sorts of issues would crop up. What if 1 thread updates the balance after money is paid in, and another thread works out the interest. If they paying in thread is too slow, the interest thread wont know about it, and will add the interest to the current balance, so you could be short changed. Worse when the paying in thread completes, it wont realise interest was added at all, so it could set the balance to the original balance + paid in amount, completely wiping out the interest adjustment.

Some things simply MUST be calcuated in a fixed order, and no amount of clever programming will change that.

That said, there is a lot of things which can be done with multiple workers, AI threads which make multiple choises based on a players "future" decision for example. The more cores you have the more possibilities the computer can explore. After the player makes his move, all the incorrect choices are simply thrown away, and the AI continues.
 
It is pretty much all down to the software since a computer will only do whats its told. Improvising and even simple assumptions (cache logic for example) require a genius cpu design to fit every possibility

Its like a shopping list made by the programmer and it only works one way. You could be clever and go get the eggs early and put them at the bottom of the shopping trolley but they'll be crushed by your keg of beer so what really happens is you get the eggs early then have to wait anyway for everything else to be fetched before it can actually be placed in the trolley

Only if the programmer has been clever enough to previously allocate a special place and order to all the shopping can it all be got simultaneously without any other piece adversely affecting the other parts

Something like video encoding would be fairly easy to multitask the encoding, its like a wheelbarrow of sand and the order of each grain is not much bother but a computer game is like a 6 course fine cuisine dinner with a soufflé that will be ruined if not eaten at exactly the right time, making & serving the entire dinner at once on the same plate is a bad idea

Too many chefs spoil the broth
 
Last edited:
Yup, if I want to find all numbers divisible by something up to X then I can fire 2 workers (1: check up to X/2, 2: check from X/2 up to X)

When the problem is finite then it is easy, not the case with modern games were freedom of movement is considered the selling point :)
 
Having more cores will allow you to run more stuff, smoother at the same time in general and even without multi-thread capable software still a big benefit.

Even with programs that haven't been coded with multi-thread capabilities made use of - there still seems to be some benefits - the OS/drivers seems to load a lot of the rendering backend off to the next core and theres often small useage on core 3 as well its possible some of the sound or other processing is being directed to another core by the OS.

The problem with what the OP is asking is - its impossible for the OS/hardware itself to identify what parts of a program have to be run in strict sequential order - and which bits can be processed asynchronously.
 
Wow lots of people having a pop at something which they dont understand in the slightest quite clearly.

A processor is a processor garbage in garbage out its not going to do something that you dont tell it to do. If you write a program that's only one thread it will handle it as such.

With regards to the graphics processor comment that was made by someone, programs written for these are all hugely threaded, that's why they run insanly fast when god knows how many processing units are at hand.
 
im sure i read a while ago ( like earlier this year or late last year ) that someone was trying to do just this. make a single threaded app to run on multiple cpu/cores.

i'll try and see if i can find it again.

hmm seems it was from 2006 and was called reverse hyperthreading but never saw the light of day http://www.bit-tech.net/news/2006/04/17/amd_reverse_hyperthreading/
 
Last edited:
Wow lots of people having a pop at something which they dont understand in the slightest quite clearly.

Alternativly known as trying to explain something in a way a non programmer would have a fair chance at comprehending.

As for reverse hyperthreading, it was only ever a rumor, and it couldnt have been called hyperthreading, as thats an intel coined term.
 
The first program where I want a quad now is in Lightroom.

My next MBP will have a Quad in it.

How im lucky Lightroom can split it as it has many different things it has to process during a workflow..

Safari/IE/whatever are single core because they have to do things in order I guess.

And its not as simple as "splitting" it in hardware, what if one bit takes twice as long to process as the other 3 peices? Buggered then... how do you work out what takes how long? Do you split it in size? Time?

If it was feasible im sure they would have done it by now...
 
the whole point i was saying is that the processor should take the work and split it between 4 or 8 or 500 cores regardless of all software..

why rely on software?

for example 1 "controller" that takes instructions and splits it between the 4 cores.. the OS can see only 1 core but the processor splits work between all by itself (all built into the chip)

Simply because they are just a piece of silicon. You can't ask a robot to do anything without programming, right?
Maybe in the future, Intel could produce a driver (optimisation) for their processors just like the graphics cards. Then they could do the trick:)
 
GPUs kind of already do this - they have lots of execution units all running in parallel and a 'dispatch processor' which divides the process up between the logic units (at least it is in ATi's R600 architecture).The cpu equivalent of this is called 'EPIC', I believe, which is what Itanium was - although it was often slammed because it didn't run x86 applications very well.
 
GPUs kind of already do this - they have lots of execution units all running in parallel and a 'dispatch processor' which divides the process up between the logic units (at least it is in ATi's R600 architecture).The cpu equivalent of this is called 'EPIC', I believe, which is what Itanium was - although it was often slammed because it didn't run x86 applications very well.

Well X86 processors have kinda been doing this too, each core has several ALU's, an FPU, an SSE. Core 2 processors can process 4 different things in parallel in "ideal" circumstances, including a little out of order execution. But this is all at the micro'op level, scaling this up to multiple CPU cores is a much bigger task. Increasing the number of ALU/FPU/SSE units within a single core also has limited gain, as many programs are too linear to even make full use of the existing execution units. Thats why Hyperthreading works, it makes use of unused parts of the CPU and allows a second program/thread to make use of them.
 
Certain programs only use 1 core, 2 cores and some use 4 cores depending on if it is coded for it...

to me this is not logical, its like having 4 huge guys and a man tells them to move some stuff, the other 2 sit down and drink beer while the other 2 do the work..

Its more a case of the man saying "I was only expecting 2 of you so there's only 2 wheelbarrows - you 2 do the work while you 2 will have to sit around for a while"
 
Back
Top Bottom