Intel Talks Up Xeon Cascade Lake Performance - Up To 48 Cores, 12 DDR4 Channels

[phoronix]

Phoronix: Intel Talks Up Xeon Cascade Lake Performance - Up To 48 Cores, 12 DDR4 Channels

Intel has reaffirmed shipping their next-gen Xeon "Cascade Lake" processors in the first half of 2019 while revealing today some initial performance details...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-Cascade-Lake-48-Cores

[L_A_G]

3.4 times the performance of an Epyc 7601? Oh wait, it's in linpak and not something actually relevant...

For those who don't know, Intel has put in some really heavy compiler optimizations for linpac specifically, meaning that it's more or less meaningless as a benchmark.

[DrYak]

For those who don't know, Intel has put in some really heavy optimizations for linpac specifically, meaning that it's more or less meaningless as a benchmark.

Basically Intel will put tons of efforts to shave a few cycles of in order to make the benchmarks look good, even if these are completely stupid and utterly wreck any security and basically turn your machine into an open-bar. See CPU vulnerabilities.

As for benchmarking, what's always the most relevant is to test your typical workload, instead of relying on easy-to-fool synthetic benchs.

[oibaf]

From the linked page:

LINPACK: AMD EPYC 7601: Supermicro AS-2023US-TR4 with 2 AMD EPYC 7601 (2.2GHz, 32 core) processors, SMT OFF, Turbo ON, BIOS ver 1.1a, 4/26/2018, ...

Any reason for SMT OFF? CPU vulnerabilities? Does this impacts the benchmark a lot?

[xiando]

>Intel’s compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors.

This confirms that Intel's compiler is still broken and favoring Intel's CPUs even though AMDs CPUs has the same instructions available.

It also states that they ran EPIC with SMT off for some reason.. but it does appear they tested those. As for Intel's performance:
>Results have been estimated or simulated using internal Intel analysis or architecture simulation or modeling, and provided to you for informational purposes.

Gee, that's some level of desperation, they just "estimated" that their CPUs are faster. This is just pathetic. It's over, Intel is about to be bankrupt and finished.

[xiando]

From the linked page:
Any reason for SMT OFF? CPU vulnerabilities? Does this impacts the benchmark a lot?

It's probably to make it perform slower, SMT OFF combined with compiling it with Intel's own crippling compiler instead of gcc shows some desperation. Not that it really matters at all when Intel's product were (not actually) tested like this:
>compared to 1-node, 2-socket 48-core Cascade Lake Advanced Performance processor projections by Intel as of 10/3/2018

It doesn't really matter how you test EPIC if you're just going to project that yours will be faster. I do, in fact, project that the new XiandoCPU will be 20 times faster than Intel's 48-core Cascade Lake. It's not production ready or even on the drawing board but I still project it will be the best thing since sliced bread.

[rene]

so how many side channel vulnerabilities are still included in Intel's latest silicon? :-/

[vegabook]

That LINPACK thing may be wildly overstated, but there is no doubt that Intel crushes AMD on anything that uses AVX.

[Weasel]

Basically Intel will put tons of efforts to shave a few cycles of in order to make the benchmarks look good, even if these are completely stupid and utterly wreck any security and basically turn your machine into an open-bar. See CPU vulnerabilities.

As for benchmarking, what's always the most relevant is to test your typical workload, instead of relying on easy-to-fool synthetic benchs.

I completely disagree. It's like saying you should benchmark a raytracing GPU on "typical workloads" that don't utilize it, and then judge the performance of the GPU for raytracing.

"Typical workloads" don't always optimize for the CPU properly, in fact most the time they aren't even optimized much at all. It's not the job of a CPU to cater to badly optimized software.

[schmidtbag]

If SMT really is off, Intel is already off to a rough start. Do they not realize AMD is already in the process of making 64c/128t CPUs? Of which, I'm sure will be significantly cheaper. Even if you disable SMT on those Epycs, they're still going to have a distinct edge in a lot of cases.