You may actually get this in some way, as the naming scheme for the Xeons is a little misleading. Unlike the clear differentiation in the consumer world the Xeon CPU's are not as distinct "Sandy Bridge" as their i5/i7 cousins.
The Core i7 are not simply marked by they name either.
The Core i7 39xx is a derivative of the Xeon E5 implementation with certain components turn on/off.
The Core i7 37xx is a variant of the other desktop implementations and also used as the basis for the Xeon E3 (with certain components .. additional PCI-e lanes , ECC support ) turned on.
- We don't know anything about their individual discounts for the respective components, so judging by simply comparing end-user prices does not help imho.
Apple's volume discounts are likely to be the same for similarly priced components at similar pricing. If there is a Core i7 that is $369 and a Xeon E5 1600 that is $369 and Apple is going to buy 120,000 of either why would there be a significant discount difference.
So in Part A versus Part B discussion as long as price and volume are about the same it is reasonable to use the publicly quoted prices as a baseline. Where that goes off the road is trying to figure Apples "real" costs for parts. On that yes, folks are guessing.
Common understanding is that due to the lack of a 2nd QPI channel the core i7 CPU's would not allow for multi-CPU configurations.
That's a dated understanding. There is no QPI link to the high speed PCI-e and I/O controller. That is inside the CPU package now. For example the E5 1600 series are zero QPI links active.
The E5 2600 needs 2 QPI links now because both RAM and PCI-e traffic and traverse between the CPU packages. There is alot more data to move.
The E5 2400 series will only have 1 QPI link so they will be kneecapped to get to get slightly lower pricing for some
In short, this is more than just about CPU cores. The CPU packages are absorbing GPUs , PCI-e lane controllers , etc. with each iteration. The differences are much more than simply core count. It is about what and how much is integrated into each package.
Apple could design a custom motherboard with a second (or third/fourth) CPU running separately (perhaps with a barebone OSX or even iOS), only being available for calculation operations. Something like XGrid set up in hardware on the same motherboard and (e.g. via Grand Central Dispatch) being transparently available as system resource for any multithreaded program able to make use of more cores.
This are several fundamental technical problems (all generally experimented with and studied in the late 80's and 90's )
1. QPI has substantially higher bandwidth and much lower latencies than PCI-e. much less any "cheap" system interconnect ( Thunderbolt, Ethernet, etc. ). The link between these multiple independent computers will be substantially slower. You can do it, but it will throw performance down the toilet.
2. Xgrid and clusters in general are great when you don't have to much that much data around. In the NUMA (non-uniform memory access) set up with the Xeons, a program can easily be moved by the OS from one set of cores in one Package to another set of cores in another Package without moving the data in RAM. For clusters, you have to rigidly segment the data to get maximal performance. ( there are ways around that with APIs like MPI to access remote memory but that requires custom programming and typically requires tweaks for a specific hardware config to get max performance.)
3. It is substantially cheaper implementation for Intel just to turn off QPI on some models (and offer lower price) and turn on other models than for Apple to go through all of those gyrations. You made a point about economy of scale.
4. Grand Central Dispatch only makes more threads. Those threads implicitly share memory. They don't map to processes in separate RAM storage pools.
That way they could not only span the range from entry-level tower (using a "normal" iMac CPU and inexpensive helper processors like e.g. ARM CPU's, which they would be able to purchase at a very low price due to the sheer number of iOS devices)
And it is even more scale and cheaper for Intel to put these helper ARM cores in the chipset sold with just about all of their offerings ( e.g., RAID 5-10 support. The microcontroller cores in high end Ethernet chipsets , etc. ). In short, ARM cores can be useful on I/O channels but they are typically way less powerful and significantly cheaper than what Apple uses in iOS devices.
Starting from a "discount" entry level workload mini-tower and then trying to get performance is backwards approach if trying to get to a competitive Workstation level performance.
If Apple wanted to build a distinct much lower cost mini-tower it would be far more straightforward and cost effective to just build it. They don't. Primarily because they don't want to go to "war" with the iMac. There is no upside to that. That is exactly what all of this xMac discussions go out of their way to avoid because there is nothing but hand waving justification as to why it wouldn't exist or be significant.
If glossy iMacs and hard go change HDD iMacs are a significant problem then the most cost effective solution to those issues for customers and Apple would be to fix those problems ( make option with non glossy screen or enclosure where could access HDD without engaging suction cups). Not introduce an entire new product line. That is the substantially more costly solution.