Hacker News Reader

Comment by einr | Hacker News Reader

Not only that, but they also apparently recompiled Linpack with the Intel compiler -- which is notorious for favoring Intel chips -- before running the benchmarks. Some really shady stuff going on here.

View on HN

On the other hand, these shady practices are a testament to AMD's technical superiority, as the incumbent is showing himself to be very desperate to react although it has absolutely no answer to AMD's new line of products.

That's not something you can cite or point to when justifying a purchasing choice to $pointy_haired_boss

I like to hate on Intel as much as the next guy but as someone currently shopping for a new workstation, I still see Intel as having the better offerings across the board, at least if you're not taking price into consideration. Take for example their HEDT competitor, Threadripper. As much as I want to like it, the fact that two of the cores don't have direct memory access really is a problem. You can see the detrimental effects this can have: https://www.anandtech.com/show/13516/the-amd-threadripper-2-...

AMD does not have techinal superiority, as Intel cores have better single-thread performance. Look at the recent low-end i3-8100 - it is an amazing chip.

But Intel won't even give that to you. The i3-8100 doesn't have turbo boost, which means it's stuck at 3.6GHz and typically doesn't have faster single thread performance than AMD's faster chips. If you want Intel to sell you the one that hits 5GHz you have to pay for more cores which, if all you care about is single thread performance, you can't even use.

Single-threaded performance is a toss up and depends on work load. Overall AMD beats them on price/performance and multithreaded performance, which matter more for everything but some games and a few not easily parallelize-able tasks.

> Single-threaded performance is a toss up and depends on work load.

I would actually say the exact opposite is true. Single threaded performance is much more reliable and every single application can use it. Multithreaded performance is much more workload dependent, and there are many applications that can’t fully utilize it.

You might be surprised what is single-threaded bound in practice.

Such as Video Editors: Adobe Premier in particular.

https://www.pugetsystems.com/pic_disp.php?id=50616

Did they run the icc-generated binaries on the Epyc processors? That's... questionable.

Apart from that, I'm fine with seeing numbers from icc because, if I'm shopping for the highest possible performance, that's probably the compiler I'll use for my code.

from this [0]

Performance results are based on testing or projections as of 6/2017 to 10/3/2018 (Stream Triad), 7/31/2018 to 10/3/2018 (LINPACK) and 7/11/2017 to 10/7/2018 (DL Inference) and may not reflect all publicly available security updates.

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, microcode: 0x8001227, 16x32GB DDR4-2666, 1 SSD, Ubuntu 18.04.1 LTS (4.17.0-041700-generic Retpoline), High-Performance Linpack v2.2, compiled with Intel(R) Parallel Studio XE 2018 for Linux, Intel MPI version 18.0.0.128, AMD BLIS ver 0.4.0, Benchmark Config: Nb=232, N=168960, P=4, Q=4, Score = 1095GFs, tested by Intel as of July 31, 2018. compared to 1-node, 2-socket 48-core Cascade Lake Advanced Performance processor projections by Intel as of 10/3/2018.

Stream Triad: 1-node, 2-socket AMD EPYC 7601, tested by AMD as of June 2017 compared to 1-node, 2-socket 48-core Cascade Lake Advanced Performance processor projections by Intel as of 10/3/2018. DL Inference:

Platform: 2S Intel Xeon Platinum 8180 CPU 2.50GHz (28 cores), HT disabled, turbo disabled, scaling governor set to “performance” via intel_pstate driver, 384GB DDR4-2666 ECC RAM. CentOS Linux release 7.3.1611 (Core), Linux kernel 3.10.0-514.10.2.el7.x86_64. SSD: Intel SSD DC S3700 Series (800GB, 2.5in SATA 6Gb/s, 25nm, MLC).

https://wccftech.com/intel-cascade-lake-advanced-performance...

How bad is icc on EPYC compared to, say, gcc?

I really dislike Intel narketing practices. And their history on how they treat AMD. Intel is a reputable company, with strong products. Yet they sometimes act like kids.

I think they already repented multiple times to ever had licensed x86 designs to other companies.

Without AMD we would all be using some variation of Itanium.

Early on they had little choice. If they wanted to sell to the US government, they needed to allow other suppliers to compete.

Were the other suppliers required to compete with x86 clones?

They had to compete against Intel.

It's a quite sane policy: if you want to sell to me, make sure I'm not locked in with you.

They could compete with having better hardware instead of blank copies.

I remember our government had other computers besides PCs and none of them had CPU clones.

As far as I remember US government was a big consumer from DEC, Xerox and IBM hardware and they also did not have any CPU clones.

That didn't turn out well. Once the Wintel standard got established, other CPU architectures were relegated to roles outside the desktop. Desktop and all but the highest end and specialized niches of servers is x86-land.

And Intel implemented the AMD64 instruction set for its own CPUs.

True, but that is a complete different matter than having the Government requiring Intel to sponsor clones.

Itanium had a great potential as the next-gen CPU arch. Now we're stuck with the heavily emulated x86.

It even had an x86 emulator

Even with all the shade, AMD still beats them in price/performance. That and performance/watt matter the most if you're building a big data center.

Are they using the ICC compiled Linpack on the AMD chips too? I think its totally fair as long as they used GCC or other best in class compiler for AMD.

Reply on news.ycombinator.com