I've seen mixed messages in MIC articles on the web. Some tout the MIC as a coprocessor, and some call it a processor. Which is it?
MIC is neither.
Intel Many Integrated Core (MIC) Architecture refers to a method of designing a device to be highly parallel, power efficient, highly programmable and compatible. Architecture are more of a concept, a promise, and not a product.
The first product to be based on Intel MIC Architecture is know as Knights Corner. Knights Corner is a coprocessor. Knights Corner was recently give the "Intel Xeon Phi" brand. Future devices using the Intel MIC Architecture could be either a processor or a coprocessor.
The difference between a processor and coprocessor is this: a processor does not require another compute device to be present in a working system. A coprocessor requires a processor be in the system in addition to the coprocessor.
Thanks for the clarification. The DOE ASCI Red machine could be set-up such that within each dual-processor node, one processor would be in charge of I/O and one would be in charge of compute. I heard rumors that ASCI Red worked well in that mode. Since the MIC ISA is x86-ish, I'm guessing that something similar could be done with a MIC coprocessor?I'm also glad to hear there may be room in the MIC roadmap to also support stand-alone processor parts in the future.Thanks again for the clarification.
>> something similar could be done with a MIC coprocessor?
When the MIC processor is places on an add-in card in the co-processor configuration, the host processor (on motherboard inwhich the MIC co-processor card is inserted)would generally be used for I/O. That said, PCIx... cards can do card-to-card transfers so the I/O could potentially be controlled by the MIC processor on the add-in card.... However, this would require cooperation with the host O/S as far as interrupts and interleaving I/O requests with the host.
Back in the 1980's I help design the processor add-in cards, and wrote the operating system whereby multiple processor cards were inserted into the same bus. The console terminal was attached to any one of these cards via serial port. The POST would initiate, on all processor cards, a wait loop for console input for boot instructions (e.g. which drive to boot). The first (only) processor card to receive the boot instruction claimed responsibility for the I/O bus. The controlling processor card's O/S would perform the I/O to all the processor cards on the system. The I/O DMA could be directed to/from any of the processor card's local memory. A secondary bus (to the I/O bus) connected all processor cards to a shared global memory. This shared memory was used for messaging between processor cards, such as requesting the designated I/O processor card to perform I/O on its behalf (terminal, disk, printer,network, ...).
There is no reason why the Kinght's Corner cards could not be placed into a large-ish PCIx16 bus without a host processor. Some tweaks may be required of the existing Knights Corner card to permit this type of configuration. IOW one of the cards elects itself to be I/O master with shared file system, or all of the cards elect to operate in a round-robin order each with independent file system (or combination thereof).
If any of you wish to attempt to do this, I would be eager, and available, to help you do this. My past experience in this area may be of some use to you.