3 ms·

> Intel may never ship them before switching to MCM Fantastic claims require fantastic evidence.. history shows that there are many ways of fixing or designing

by rphlx 9y ago

> Intel may never ship them before switching to MCM Fantastic claims require fantastic evidence.. history shows that there are many ways of fixing or designing-around manufacturing yield problems. Do you have any actual evidence that their 10nm fabs will never yield a competitive monolithic server part in a financially-viable way? > MCM is as revolutionary as AMD64 I would disagree somewhat, as AMD64 clearly benefits every customer with very little downside, while it is fair to say that MCM CPUs can create or exacerbate irritating performance problems for the customer by being "much more NUMAed". [All else equal, most customers would prefer a monolithic part, or 2 NUMA domains instead of 8-16].

ianai 9y ago
Not quite. 64 bit ran behind 32 bit for a long time after introduction. The rule of thumb was to ask whether more ram or more speed was important. 64bit felt slower to people for a long time. (I swear I can still see the difference 10 years later.) 64 bit didn’t really pull away until 8 gig became common. Something similar may hold for MCM, I don’t know about mcm to speak to that.
- rphlx 9y ago
  To clarify my point: an AMD64 CPU could still run in 32-bit mode, if the customer preferred. Much later, the x86_32 ABI work also retained small pointer sizes while providing additional benefits. Whereas there is no way for a customer to fully "unNUMA" an MCM CPU.
- chaboud 9y ago
  We saw substantial performance improvements from the increased register count of AMD64 when I lead the porting effort of a video editing/compositing suite back in the early days. Because our engine took advantage of memory-mapped unnamed file handles to cache frames, we didn't really need the extra address space of larger pointers. I was able to exhaust system memory by manually managing whether or not buffers were mapped into our address space. Though it had been made for something else, I lucked into being able to use that same engine for interprocess legacy plug-in support. AMD64 support also wasn't necessary to get more physical memory support out of the chips of the era. Operating systems supported 36 and 40 bit physical address spaces, and applications could use higher (would-be negative) addresses by indicating support for it. Those wanting to really cut loose could turn to manual mapping. (See: PAE, LAA) In the end, we shipped AMD64 support because there were substantial performance wins. And, yes, I profiled every possible software/hardware combination to determine where gains and losses were coming from. I'm not saying that things were universally faster/better. RIP-relative addressing, though generally quicker than absolute 64-bit, is a headache, and the loss of 80-bit floating point intermediates broke some rare code (which would have broken in strict mode, anyway). I'd love to see some evidence of slow-down now, but, until then, I'm unconvinced. I had a dev bring me "evidence" of huge performance differences between ARMv7 and ARMv8 a couple of years ago (and there are some if you dig). I asked him if he had compiled with or without thumb in the linked modules. He let me know of his new results a few days later, a little red-faced. I'm not saying that your detection of slowness is the same thing, but many aspects of performance are measurable (and measured). If it's slower, we can probably measure just how much.
  - ianai 9y ago
    Yes, if someone said anything about video editing I would suggest a 64 bit system.

by rphlx 9y ago

ianai 9y ago

Not quite. 64 bit ran behind 32 bit for a long time after introduction. The rule of thumb was to ask whether more ram or more speed was important. 64bit felt slower to people for a long time. (I swear I can still see the difference 10 years later.) 64 bit didn’t really pull away until 8 gig became common. Something similar may hold for MCM, I don’t know about mcm to speak to that.

rphlx 9y ago
To clarify my point: an AMD64 CPU could still run in 32-bit mode, if the customer preferred. Much later, the x86_32 ABI work also retained small pointer sizes while providing additional benefits. Whereas there is no way for a customer to fully "unNUMA" an MCM CPU.
chaboud 9y ago
We saw substantial performance improvements from the increased register count of AMD64 when I lead the porting effort of a video editing/compositing suite back in the early days. Because our engine took advantage of memory-mapped unnamed file handles to cache frames, we didn't really need the extra address space of larger pointers. I was able to exhaust system memory by manually managing whether or not buffers were mapped into our address space. Though it had been made for something else, I lucked into being able to use that same engine for interprocess legacy plug-in support. AMD64 support also wasn't necessary to get more physical memory support out of the chips of the era. Operating systems supported 36 and 40 bit physical address spaces, and applications could use higher (would-be negative) addresses by indicating support for it. Those wanting to really cut loose could turn to manual mapping. (See: PAE, LAA) In the end, we shipped AMD64 support because there were substantial performance wins. And, yes, I profiled every possible software/hardware combination to determine where gains and losses were coming from. I'm not saying that things were universally faster/better. RIP-relative addressing, though generally quicker than absolute 64-bit, is a headache, and the loss of 80-bit floating point intermediates broke some rare code (which would have broken in strict mode, anyway). I'd love to see some evidence of slow-down now, but, until then, I'm unconvinced. I had a dev bring me "evidence" of huge performance differences between ARMv7 and ARMv8 a couple of years ago (and there are some if you dig). I asked him if he had compiled with or without thumb in the linked modules. He let me know of his new results a few days later, a little red-faced. I'm not saying that your detection of slowness is the same thing, but many aspects of performance are measurable (and measured). If it's slower, we can probably measure just how much.
- ianai 9y ago
  Yes, if someone said anything about video editing I would suggest a 64 bit system.