There is calculations going at the same time, also out of order execution at the same time, however the sum is reduced to one output at a time. That is why 2 computers with 2 cores, the output is twice as fast as one computer with 4 cores.
No, it has to do with bottlenecks. Modern PCs (Let's use Skylake as an example), have dual-channel RAM / memory controllers. Each memory controller is 72 bits wide. However, 8 of of those bits is only used for ECC is servers. So the effective net data width is 64-bits, per channel, or 128-bits total.
Now, due to pre-fetching and whatnot, generally, the CPU reads a cache line at a time. I don't know how wide a cache line is for Skylake's L3, but I could look up that info. But generally, it's larger than 128-bits at a time.
Now, as for CPU core multi-processing, each core can be reading or writing data. There are arbiters for each core, and the memory controller / uncore / L3 cache, that control access.
Generally, though, modern quad-cores are going to be bottle-necked if they are reading / writing main memory with all four cores, and not hitting the cache instead. You won't see a simple 2x to 4x speedup, just by reading and writing main memory with two versus four cores. That's way too simplistic a model.
Each component connected to the CPU including memory sends and receives data in a sequential order to the CPU round-robin, PCI sends data parallel, PCI-E sends data Serial.
Now you explain how a PCI and PCI-E bus works and the difference, just explain it simply, (Einstein quote) If you can't explain it simply, you don't understand it well enough.
Yes, PCI-E uses a serial PHY, rather than parallel, for greater bandwidth per pin. But the differences don't stop there. They allow peer-to-peer transfers, async DMA essentially between PCI-E devices, at full speed. Instead of a purely host-driven model. They have a switching fabric between the PCI-E root ports and the CPU, much in the same way a networking switch operates. Your simplistic model doesn't address the new concurrency possible with PCI-E.
Edit: For an analogy, consider the evolution of ethernet networks. Originally (OK, there was "thick ethernet", that was before my time) there was coax ThinNet (10base2?), that was a shared medium, between network nodes, and required terminators on each ethernet segment. That's how PCI worked, effectively - it was a shared bus, with each slot having bus request / grant lines, and a bus arbiter in the system chipset that would act like a traffic cop, and allow whichever bus slot to control the bus. (Edit: In ethernet, access to the shared medium is via the CSMA/CD mechanism. You can Google that for more info.)
But ethernet evolved, and now we have (faster) point-to-point links, rather than a shared medium, and they are switched, connected by a device with a switching fabric, that allows concurrency between nodes.
PCI-E is like that, it's a bunch of faster point-to-point links, connected by a switching fabric, that allows node-to-node (or device-to-device) concurrency.
For an example of this concurrency, look at how AMD implements PCI-E based XDMA Crossfire.
Or do you believe that every byte crossing the PCI-E root ports goes through the CPU, caches, registers, whatever?
A CPU just finishes one task at a time know mater how many cores it has, put simply there is only one input and output on x86 CPU.
I guess it would blow your mind, to find out that Xeon CPUs have MULTIPLE QPI bus connections, for 2S and 4S and even 8S configurations. There is NOT "only one input and output" on an x86 CPU.
Of course, when you look under the hood, you discover that a processor can only execute one thing at a time. Everything that goes beyond this simple technical fact is “smoke and mirrors.”
It's not just "smoke and mirrors". You just don't understand it, and hand-wave that additional complexity and concurrency away.
Edit: You're confusing the Von Neumann-like architectural model, with the actual hardware implementations. According to the architectural model, opcodes in the binary execute and retire in serial fashion. What I've been trying to tell you is, the real-world model is FAR more complex, in what it actually does.
For an operating system to support multithreading (or multitasking for that matter), it must implement some mechanism that allows one task or thread to do a little bit of work, and then quickly switch to the next thread or task. Once that thread has been given some processing time, the OS moves on to the next thread, and so on. This switching happens so frequently and so quickly that the illusion of things happening at the same time works quite well.
http://www.codemag.com/article/060033
Yes. Time-slicing of CPU architectural "cores", in software. Which, has nothing to do with hardware concurrency.
I'm trying to explain simply for you, because folks need to grasp the basics of how a processor works,
computers are simple to understand how they work.
Here is some help.
HAHA. Funny. Thanks, though, for the effort.
Edit: My analogy is this: Computer CPUs are like little factories. Your argument seems to be, because the factory only has one driveway leading to the road, that there's really only one person working inside the factory. Which, in my mind, couldn't be more wrong.
Then, there are the questions, would two small factories or one big factory be better? How many assembly lines per factory? How many loading docks do you need? Etc.
Edit: I just noticed. You're confusing IRQ signals with bus-request / grant signals. They are not the same thing.
Edit: You are correct about one thing though - the prior PCI bus, generally did have a "round-robin" mode for the bus arbiter (among possible others), and PCI was primarily host-driven (though devices also could do bus-master DMA, I think in PCI 2.1 or 2.2).
Facebook
Twitter