3 ms·

"The proof of a CPU is in how it benchmarks across real workloads." Define 'real workload' here. Are we talking about a workload where the compiler specificall

"The proof of a CPU is in how it benchmarks across real workloads." Define 'real workload' here. Are we talking about a workload where the compiler specifically optimizes for Intel, or where the executable chooses unoptimized paths if it finds anything other than intel processors inside? Because I've found that when it comes to raw x86, no SSE anything or other nonsense; pure, unadulterated original x86, AMD simply owns.

matthewmacleod 10y ago
Because I've found that when it comes to raw x86, no SSE anything or other nonsense; pure, unadulterated original x86, AMD simply owns. Who cares, though? Is that something that matters?
- lightedman 10y ago
  It is something that matters for those of us that are more than competent and capable of programming without needing to use proprietary extensions to the underlying architecture.
i80and 10y ago
"Unadulterated original x86" doesn't really exist, and hasn't mattered for decades at least. Do you mean the 8086's instruction set? Many of those instructions are now implemented in microcode; sure, you can use them, but they're going to be dog slow. Turns out, nobody uses them. Do you mean the i586 instruction set? Your system calls are going to be slow, since you have to trigger an interrupt. Do you just mean 32-bit x86? That covers a large set of incompatible extensions among different vendors, and is of rapidly decreasing relevancy. Do you just mean scaler instructions? That's really just hamstringing yourself: a lot of performance-sensitive applications involve manipulating vectors, and SIMD is a fairly easy and effective win.
oliwarner 10y ago
Other nonsense? These additional instruction sets aren't just a gimmick, they exist to do more work faster. But my definition of two workload really just means a spectrum of different sorts of computation so we can see how various subsystems compare.
- lightedman 10y ago
  "These additional instruction sets aren't just a gimmick, they exist to do more work faster." They don't really work much faster when the basic stuff in the core architecture is gimped (low-count ADD/MULTIPLY units? In this day and age of cheap silicon? Really?)

matthewmacleod 10y ago

Because I've found that when it comes to raw x86, no SSE anything or other nonsense; pure, unadulterated original x86, AMD simply owns. Who cares, though? Is that something that matters?

lightedman 10y ago
It is something that matters for those of us that are more than competent and capable of programming without needing to use proprietary extensions to the underlying architecture.

i80and 10y ago

"Unadulterated original x86" doesn't really exist, and hasn't mattered for decades at least. Do you mean the 8086's instruction set? Many of those instructions are now implemented in microcode; sure, you can use them, but they're going to be dog slow. Turns out, nobody uses them. Do you mean the i586 instruction set? Your system calls are going to be slow, since you have to trigger an interrupt. Do you just mean 32-bit x86? That covers a large set of incompatible extensions among different vendors, and is of rapidly decreasing relevancy. Do you just mean scaler instructions? That's really just hamstringing yourself: a lot of performance-sensitive applications involve manipulating vectors, and SIMD is a fairly easy and effective win.

oliwarner 10y ago

Other nonsense? These additional instruction sets aren't just a gimmick, they exist to do more work faster. But my definition of two workload really just means a spectrum of different sorts of computation so we can see how various subsystems compare.

lightedman 10y ago
"These additional instruction sets aren't just a gimmick, they exist to do more work faster." They don't really work much faster when the basic stuff in the core architecture is gimped (low-count ADD/MULTIPLY units? In this day and age of cheap silicon? Really?)