why does this not exist?

[Ashleyyyy]

why can't you just combine cpu core's for programs that aren't coded for multi threaded cpu's?

 

like if you have 6 core's combining them into 2 virtual core's containing 3 real one's... 

[DocSwag]

Because getting ILP (instruction level parallelism) is not that easy... You can't always easily extract parallelism from instructions.

[porina]

If it were possible to do that and give a gain, it would have been. In short, the question is asking if software can't be made more parallel, why not do it in another layer externally? It's just not going to end well.

[AngryBeaver]

6 minutes ago, firelighter487 said:

why can't you just combine cpu core's for programs that aren't coded for multi threaded cpu's?

 

like if you have 6 core's combining them into 2 virtual core's containing 3 real one's... 

It comes down to many things. The order they need to be process, the timing of them being process, etc.

 

So in a multi-threaded app the work is broken up in to chunks or streams or threads or w/e you want to call it. Then windows can see those chunks and assign them based on priority or timing to different cores to have them processed. Now I am very much over simplifying this.

 

So for example in a game. You might have lots of items that require some computing. You have draw calls, physics, level loading, etc.   A game designer might decide he wants to run this game on say 4 cores. He might assign Draw calls and physics to one thread, level loading to anther, state tracking to a third, and the rest to a forth.

[Mira Yurizaki]

34 minutes ago, firelighter487 said:

why can't you just combine cpu core's for programs that aren't coded for multi threaded cpu's?

 

like if you have 6 core's combining them into 2 virtual core's containing 3 real one's... 

The cores would have to be synchronized, possibly needing to share the same data set as well. This constant need to synchronize would mean that the performance of the application may drop and since you have data duplication, you're sort of wasting resources. Even then, doing this only improves instruction level parallelism which may not be possible simply due to how things were designed. That can't really be fixed outside of speculative execution (which is becoming a real security problem lately).

[Sauron]

It's hard to explain if you have no idea of what multicore programming entails but...

 

Imagine two people. One is given a drill to make some holes. The other person can only watch. Your question is akin to asking "why can't they combine into a superperson and get the drilling done twice as fast?".

[Sauron]

29 minutes ago, VegetableStu said:

And thanks to memes I'm thinking of Dragonball Z without having watched it ._.

Still wouldn't help with a fixed speed drill 

[Mira Yurizaki]

56 minutes ago, Sauron said:

It's hard to explain if you have no idea of what multicore programming entails but...

 

Imagine two people. One is given a drill to make some holes. The other person can only watch. Your question is akin to asking "why can't they combine into a superperson and get the drilling done twice as fast?".

I think a scenario that would better fit what OP wants is you have a heavy object that needs to be pushed. One person can only apply so much force against the object, but two people can provide double the force. But then again, I think this would really be a vector operation in which case you'd feed it to a GPU or something.

[Sauron]

1 minute ago, M.Yurizaki said:

I think a scenario that would better fit what OP wants is you have a heavy object that needs to be pushed. One person can only apply so much force against the object, but two people can provide double the force. But then again, I think this would really be a vector operation in which case you'd feed it to a GPU or something.

That's the opposite scenario, where a workload CAN be parallelized well. The drill scenario on the other hand is a typical serial task that can't be worked on by two separate entities.

[Mira Yurizaki]

1 minute ago, Sauron said:

That's the opposite scenario, where a workload CAN be parallelized well. The drill scenario on the other hand is a typical serial task that can't be worked on by two separate entities.

In my mind I was thinking that the huge object is a single piece of data rather than multiple pieces of data. But data can often be broken down anyway whereas you can't do that to the physical object (not readily anyway)

[wasab]

Because of xyz and laws of physics, chemistry, mathematics, and the will of our omnipotent God , creator of the cosmos , time, space, and you so alas, it isnt possible.  

[HunterAP]

Look at any assembly instruction and you'll see that there's no room to multithread it.

If you look at addition, it's simply taking value X, summing it with value Y, and storing it in Z (which in this case would be the EAX register). There is no way to use more than one CPU thread in that instruction whatsoever. Even though addition is simple, all instructions within a given CPU instruction set boil down to this type of stuff.

Let's say a CPU had an exponent function, and you wanted X^Y. In a different form, you're basically doing X * X, but Y number of times. Theoretically, you could split this up, such as if X=2 and Y=4 you could have (2*2)*(2*2) and make one CPU thread handle the first parentheses set and another thread to handle the second set, but then you get into issues of sharing information. In the time it takes to send that second (2*2) instruction, calculate it, and the send it back to the first CPU thread (which calculated the first (2*2) instruction), that level of work could've already been done on that first CPU thread. tldr: it'd be quicker to keep that data and instructions on a single CPU.

Even if the dataset gets so large that one CPU thread could take a while to calculate it (say X=1000 and Y=4), the first thread still has to send the data over to another thread first before beginning it's own calculation, and that added delay is not worth doing because of that transfer overhead. Sure, you might possibly save time in the calculation, but you're using two threads for less than double the performance increase.

[Unimportant]

On 8/22/2018 at 3:34 PM, firelighter487 said:

why can't you just combine cpu core's for programs that aren't coded for multi threaded cpu's?

 

like if you have 6 core's combining them into 2 virtual core's containing 3 real one's... 

Some rather convoluted examples here trying to explain a simple concept. I'll give it a go:

 

Imagine you have a 1000 numbers that each need to be multiplied by 2. You could easily split this task into a 1000 threads, each thread running on it's own CPU core, and have each thread perform the calculation on 1 number.

 

Now imagine that each number has to be multiplied by 2, but then the result of this calculation has to be added to the next number before that is doubled and so on...

Since each calculation first needs the result of the previous calculation, each thread has to wait for the thread before it to finish it's calculation and pass it's result before being able to continue. In this case there will be no performance benefit from the extra threads and a single threaded application will probably even be faster (because "juggling" the data around between threads takes time as well).

 

Real life computer programs are full with these kinds of data dependencies - where one thing needs to be calculated first before the next calculation can begin.

 

As a more relatable example, imagine a graphics thread in a game that is responsible for drawing everything on the screen. It often has to wait for the game logic thread to first calculate where and in what state objects will be before they can be drawn.

[Beskamir]

Because scheduling is hard.

[Franck]

You have 2 people (cpu core), 2 object (data objects in memory) and a tasks to complete (a set instructions).

 

The task is to drill a hole in a wooden beam to install a bolt and fasten it.

You cannot have the 2 person work on the same thing at the same time.

The bolt cannot go in until the wooden beam has been drilled.

These 2 task will never be able to run in parallel. Each steps are delayed.

Fastener cannot be installed is there is no bolt and bolt cannot be installed without a hole.

Even if you have 6 millions people (6 million cores, you cannot complete all task at the same time. At most you can drill 6,000,000 holes but install no bolt and no fasteners. Unless that drill is limited access (like some computer resource are limited to 3-4 concurrent calls) then you can only have 3 or 4 of these people at the a time to drill holes.