Microsoft Posts In-Depth AMD EPYC Milan-X Benchmarks

AMD 3D V-Cache
AMD 3D V-Cache (Image credit: AMD)

AMD officially announced the company's latest EPYC Milan-X processors with 3D V-Cache, among other interesting things, such as the Instinct MI200 and a roadmap for Zen 4. The chipmaker didn't list the specifications for the cache-stacked chips, though, but Microsoft has shared Milan-X benchmarks to show the performance uplift that 3D V-Cache brings to the table.

Microsoft will tap into Milan-X to power its new Azure HBv3 Series VMs, which are based on a pair of EPYC 7V73X processors. Each processor delivers up to 64 Zen 3 cores for a total of 128 cores per server. However, eight cores from each server are reserved to feed the Azure hypervisor and other orchestration routines. As a result, Microsoft offers its customers up to five configurations with different core counts: 120 cores, 96 cores, 64 cores, 32 cores, and 16 cores. The EPYC 7V73X sports a peak clock speed up to 3.5 GHz.

Zhiye Liu
News Editor, RAM Reviewer & SSD Technician

Zhiye Liu is a news editor, memory reviewer, and SSD tester at Tom’s Hardware. Although he loves everything that’s hardware, he has a soft spot for CPUs, GPUs, and RAM.

  • popatim
    Makes me wonder how much lag is introduced if the cache needs to be flushed.
    Reply
  • Alex/AT
    popatim said:
    Makes me wonder how much lag is introduced if the cache needs to be flushed.
    For 1P systems these are very rare cases like suspend/resume where latency does not matter already.
    Would probably be on a scale of one to few seconds for completely dirty L3 cache (which is rare as well).
    For xP SMP systems, cross node memory access will prevent need to flush L3 as well.
    Memory shared with devices and accessible by devices is usually set up as writethrough or uncached and flushed manually/in ranges as required.
    All in all I don't see any reasonable use cases where flushing whole L3 is a necessity, or would be of any concern actually :)
    Reply
  • helper800
    Alex/AT said:
    For 1P systems these are very rare cases like suspend/resume where latency does not matter already.
    Would probably be on a scale of one to few seconds for completely dirty L3 cache (which is rare as well).
    For xP SMP systems, cross node memory access will prevent need to flush L3 as well.
    Memory shared with devices and accessible by devices is usually set up as writethrough or uncached and flushed manually/in ranges as required.
    All in all I don't see any reasonable use cases where flushing whole L3 is a necessity, or would be of any concern actually :)
    Just curious what is your background with tech? Are you an engineer or computer science guy?
    Reply
  • Alex/AT
    helper800 said:
    Just curious what is your background with tech? Are you an engineer or computer science guy?
    Well, not a hardware person per se, meaning not involved in any hardware development. Do understand how hardware works though, not on electrical level though, but on logical level.
    But 20+ years of ISP/TSP/CSP systems and services background, including PC and server building/assessment/experience, virtualization, Linux/OSS, kernel tuning, software development and debugging, heavy networking, heavy VoIP, SQL, bits of x86 & ARM assembly programming, etc. :)
    So just a broad range systems engineer in short.
    Reply
  • waltc3
    AMD will roll over everyone next year, it seems clear. Shows the benefits of having aggressive roadmaps over a multi-year period that you can actually keep! I don't see much daylight for Intel next year at this time.
    Reply