prefetcher L2 HW มีประโยชน์จริง ๆ หรือไม่


10

ฉันอยู่ที่Whisky Lake i7-8565Uและวิเคราะห์เคาน์เตอร์ที่สมบูรณ์แบบและเวลาสำหรับการคัดลอกข้อมูลขนาด 512 KiB (ขนาดแคช L2 มากกว่าสองเท่า) และต้องเผชิญกับความเข้าใจผิดบางประการเกี่ยวกับการทำงานของ L2 HW prefetcher

ในIntel Manual Vol.4 MSRมี MSR 0x1A4บิต 0 เป็นสำหรับการควบคุมการใช้ prefetcher L2 HW (1 เพื่อปิดการใช้งาน)


พิจารณาเกณฑ์มาตรฐานดังต่อไปนี้:

memcopy.h:

void *avx_memcpy_forward_lsls(void *restrict, const void *restrict, size_t);

memcopy.S:

avx_memcpy_forward_lsls:
    shr rdx, 0x3
    xor rcx, rcx
avx_memcpy_forward_loop_lsls:
    vmovdqa ymm0, [rsi + 8*rcx]
    vmovdqa [rdi + rcx*8], ymm0
    vmovdqa ymm1, [rsi + 8*rcx + 0x20]
    vmovdqa [rdi + rcx*8 + 0x20], ymm1
    add rcx, 0x08
    cmp rdx, rcx
    ja avx_memcpy_forward_loop_lsls
    ret

main.c:

#include <string.h>
#include <stdlib.h>
#include <inttypes.h>
#include <x86intrin.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include "memcopy.h"

#define ITERATIONS 1000
#define BUF_SIZE 512 * 1024

_Alignas(64) char src[BUF_SIZE];
_Alignas(64) char dest[BUF_SIZE];

static void __run_benchmark(unsigned runs, unsigned run_iterations,
                    void *(*fn)(void *, const void*, size_t), void *dest, const void* src, size_t sz);

#define run_benchmark(runs, run_iterations, fn, dest, src, sz) \
    do{\
        printf("Benchmarking " #fn "\n");\
        __run_benchmark(runs, run_iterations, fn, dest, src, sz);\
    }while(0)

int main(void){
    int fd = open("/dev/urandom", O_RDONLY);
    read(fd, src, sizeof src);
    run_benchmark(20, ITERATIONS, avx_memcpy_forward_lsls, dest, src, BUF_SIZE);
}

static inline void benchmark_copy_function(unsigned iterations, void *(*fn)(void *, const void *, size_t),
                                               void *restrict dest, const void *restrict src, size_t sz){
    while(iterations --> 0){
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
        fn(dest, src, sz);
    }
}

static void __run_benchmark(unsigned runs, unsigned run_iterations,
                    void *(*fn)(void *, const void*, size_t), void *dest, const void* src, size_t sz){
    unsigned current_run = 1;
    while(current_run <= runs){
        benchmark_copy_function(run_iterations, fn, dest, src, sz);
        printf("Run %d finished\n", current_run);
        current_run++;
    }
}

พิจารณาการรวบรวม 2 รัน main.c

ผม

MSR:

$ sudo rdmsr -p 0 0x1A4
0

Run:

$ taskset -c 0 sudo ../profile.sh ./bin 

 Performance counter stats for './bin':

    10486164071      L1-dcache-loads                                               (12,13%)
    10461354384      L1-dcache-load-misses     #   99,76% of all L1-dcache hits    (12,05%)
    10481930413      L1-dcache-stores                                              (12,05%)
    10461136686      l1d.replacement                                               (12,12%)
    31466394422      l1d_pend_miss.fb_full                                         (12,11%)
   211853643294      l1d_pend_miss.pending                                         (12,09%)
     1759204317      LLC-loads                                                     (12,16%)
            31007      LLC-load-misses           #    0,00% of all LL-cache hits     (12,16%)
     3154901630      LLC-stores                                                    (6,19%)
    15867315545      l2_rqsts.all_pf                                               (9,22%)
                 0      sw_prefetch_access.t1_t2                                      (12,22%)
         1393306      l2_lines_out.useless_hwpf                                     (12,16%)
     3549170919      l2_rqsts.pf_hit                                               (12,09%)
    12356247643      l2_rqsts.pf_miss                                              (12,06%)
                 0      load_hit_pre.sw_pf                                            (12,09%)
     3159712695      l2_rqsts.rfo_hit                                              (12,06%)
     1207642335      l2_rqsts.rfo_miss                                             (12,02%)
     4366526618      l2_rqsts.all_rfo                                              (12,06%)
     5240013774      offcore_requests.all_data_rd                                     (12,06%)
    19936657118      offcore_requests.all_requests                                     (12,09%)
     1761660763      offcore_response.demand_data_rd.any_response                                     (12,12%)
       287044397      bus-cycles                                                    (12,15%)
    36816767779      resource_stalls.any                                           (12,15%)
    36553997653      resource_stalls.sb                                            (12,15%)
    38035066210      uops_retired.stall_cycles                                     (12,12%)
    24766225119      uops_executed.stall_cycles                                     (12,09%)
    40478455041      uops_issued.stall_cycles                                      (12,05%)
    24497256548      cycle_activity.stalls_l1d_miss                                     (12,02%)
    12611038018      cycle_activity.stalls_l2_miss                                     (12,09%)
        10228869      cycle_activity.stalls_l3_miss                                     (12,12%)
    24707614483      cycle_activity.stalls_mem_any                                     (12,22%)
    24776110104      cycle_activity.stalls_total                                     (12,22%)
    48914478241      cycles                                                        (12,19%)

      12,155774555 seconds time elapsed

      11,984577000 seconds user
       0,015984000 seconds sys

ครั้งที่สอง

MSR:

$ sudo rdmsr -p 0 0x1A4
1

Run:

$ taskset -c 0 sudo ../profile.sh ./bin

 Performance counter stats for './bin':

    10508027832      L1-dcache-loads                                               (12,05%)
    10463643206      L1-dcache-load-misses     #   99,58% of all L1-dcache hits    (12,09%)
    10481296605      L1-dcache-stores                                              (12,12%)
    10444854468      l1d.replacement                                               (12,15%)
    29287445744      l1d_pend_miss.fb_full                                         (12,17%)
   205569630707      l1d_pend_miss.pending                                         (12,17%)
     5103444329      LLC-loads                                                     (12,17%)
            33406      LLC-load-misses           #    0,00% of all LL-cache hits     (12,17%)
     9567917742      LLC-stores                                                    (6,08%)
     1157237980      l2_rqsts.all_pf                                               (9,12%)
                 0      sw_prefetch_access.t1_t2                                      (12,17%)
           301471      l2_lines_out.useless_hwpf                                     (12,17%)
       218528985      l2_rqsts.pf_hit                                               (12,17%)
       938735722      l2_rqsts.pf_miss                                              (12,17%)
                 0      load_hit_pre.sw_pf                                            (12,17%)
         4096281      l2_rqsts.rfo_hit                                              (12,17%)
     4972640931      l2_rqsts.rfo_miss                                             (12,17%)
     4976006805      l2_rqsts.all_rfo                                              (12,17%)
     5175544191      offcore_requests.all_data_rd                                     (12,17%)
    15772124082      offcore_requests.all_requests                                     (12,17%)
     5120635892      offcore_response.demand_data_rd.any_response                                     (12,17%)
       292980395      bus-cycles                                                    (12,17%)
    37592020151      resource_stalls.any                                           (12,14%)
    37317091982      resource_stalls.sb                                            (12,11%)
    38121826730      uops_retired.stall_cycles                                     (12,08%)
    25430699605      uops_executed.stall_cycles                                     (12,04%)
    41416190037      uops_issued.stall_cycles                                      (12,04%)
    25326579070      cycle_activity.stalls_l1d_miss                                     (12,04%)
    25019148253      cycle_activity.stalls_l2_miss                                     (12,03%)
         7384770      cycle_activity.stalls_l3_miss                                     (12,03%)
    25442709033      cycle_activity.stalls_mem_any                                     (12,03%)
    25406897956      cycle_activity.stalls_total                                     (12,03%)
    49877044086      cycles                                                        (12,03%)

      12,231406658 seconds time elapsed

      12,226386000 seconds user
       0,004000000 seconds sys

ฉันสังเกตเห็นเคาน์เตอร์:

12 611 038 018 cycle_activity.stalls_l2_miss v / s
25 019 148 253 cycle_activity.stalls_l2_miss

การแนะนำว่า MSR กำลังปิดใช้งาน prefetcher L2 HW จะถูกนำไปใช้ สิ่งอื่น ๆ ที่เกี่ยวข้องกับ l2 / LLC ก็แตกต่างกันอย่างมาก ความแตกต่างคือทำซ้ำข้ามวิ่งที่แตกต่างกัน ปัญหาคือเกือบจะไม่มีความแตกต่างในtotal timeและรอบ:

48 914 478 241 cycles v / s
49 877 044 086 cycles

12,155774555 seconds time elapsed v / s
12,231406658 seconds time elapsed

คำถาม:
L2 คิดถึงการซ่อนตัว จำกัด ประสิทธิภาพอื่นหรือไม่
ถ้าเป็นเช่นนั้นคุณสามารถแนะนำเคาน์เตอร์ที่ควรมองดูเพื่อทำความเข้าใจได้หรือไม่


4
ตามกฎของหัวแม่มือ: สำเนาหน่วยความจำที่ไม่ใช้งานแบบ abysmally ใด ๆ จะถูกผูกไว้กับหน่วยความจำ แม้ว่าจะเป็นเพียงแคช L1 เท่านั้น ค่าโสหุ้ยของการเข้าถึงหน่วยความจำใด ๆ นั้นสูงกว่าการใช้ CPU เพื่อรวมสองและสองเข้าด้วยกัน ในกรณีของคุณคุณกำลังใช้คำแนะนำ AVX เพื่อลดจำนวนคำสั่งต่อไบต์ที่คัดลอก เมื่อใดก็ตามที่ข้อมูลของคุณถูกค้นพบ (L1, L2, LLC, หน่วยความจำ) ปริมาณงานขององค์ประกอบหน่วยความจำที่เกี่ยวข้องจะเป็นคอขวดของคุณ
cmaster - คืนสถานะโมนิก้า

คำตอบ:


5

ใช่ลำแสง L2 คือจริงๆเป็นจำนวนมากที่เป็นประโยชน์ของเวลา

memcpy ไม่มีเวลาแฝงการคำนวณใด ๆ ที่ซ่อนดังนั้นฉันคิดว่ามันสามารถให้ OoO exec ทรัพยากร (ขนาด ROB) จัดการ latency โหลดพิเศษที่คุณได้รับจากการพลาด L2 เพิ่มเติมอย่างน้อยในกรณีนี้คุณได้รับ L3 ทั้งหมดจาก การใช้ชุดการทำงานขนาดกลาง (1MiB) ที่เหมาะกับ L3 ไม่จำเป็นต้องทำการดึงข้อมูลล่วงหน้าเพื่อให้ L3 Hit เกิดขึ้น

และคำแนะนำเดียวคือ load / store (และลูปโอเวอร์เฮด) ดังนั้นหน้าต่าง OoO จะรวมโหลดความต้องการไว้ล่วงหน้า

IDK ถ้า L2 ของ prefetcher เชิงพื้นที่และ L1d prefetcher กำลังช่วยอะไรอยู่ที่นี่


การทำนายเพื่อทดสอบสมมติฐานนี้ : ทำให้อาร์เรย์ของคุณใหญ่ขึ้นเพื่อให้คุณพลาด L3 และคุณอาจเห็นความแตกต่างในเวลาโดยรวมเมื่อ OoO exec ไม่เพียงพอที่จะซ่อนเวลาแฝงของการโหลดไปจนถึง DRAM HW prefetch การเรียกใช้ไกลออกไปข้างหน้าสามารถช่วยบางอย่าง

ประโยชน์ใหญ่อื่น ๆ ของการดึงข้อมูลล่วงหน้า HW มาเมื่อทำได้ติดตามการคำนวณของคุณได้ดังนั้นคุณจะได้รับความนิยม L2 (ในลูปที่มีการคำนวณที่มีความยาวปานกลาง แต่ไม่ได้ขึ้นอยู่กับห่วงโซ่พึ่งพา)

โหลดความต้องการและ OoO exec สามารถทำได้มากเท่าที่ใช้แบนด์วิดท์หน่วยความจำที่มีอยู่ (เธรดเดียว) เมื่อไม่มีความกดดันอื่น ๆ เกี่ยวกับความจุ ROB


นอกจากนี้โปรดทราบว่าใน CPU ของ Intel ทุกแคชที่พลาดสามารถเสียค่าใช้จ่ายการเล่นซ้ำส่วนหลัง (จาก RS / scheduler) ของuops ที่ขึ้นต่อกันแต่ละอันสำหรับ L1d และ L2 จะพลาดเมื่อข้อมูลคาดว่าจะมาถึง และหลังจากนั้นเห็นได้ชัดว่าแกนหลักในแง่ดี spams uops ในขณะที่รอข้อมูลที่จะมาจาก L3

(ดูhttps://chat.stackoverflow.com/rooms/206639/discussion-on-question-by-beeonrope-are-load-ops-deallocated-from-the-rs-when-thและโหลด ops deallocated จาก อาร์เอสเมื่อพวกเขาส่งสมบูรณ์หรือเวลาอื่น ๆ ? )

ไม่ใช่โหลดแคชตัวเอง; ในกรณีนี้มันจะเป็นคำแนะนำร้านค้า โดยเฉพาะอย่างยิ่ง store-data uop สำหรับพอร์ต 4 ที่ไม่สำคัญ การใช้ร้านค้าขนาด 32 ไบต์และคอขวดบนแบนด์วิดธ์ L3 หมายความว่าเราไม่ได้ใกล้กับ 1 พอร์ต 4 uop ต่อนาฬิกา


2
@ St.Antario: เหรอ? ไม่สมเหตุสมผลเลย คุณเป็นหน่วยความจำที่ถูกผูกไว้ดังนั้นคุณจึงไม่มีคอขวดส่วนหน้าดังนั้น LSD จึงไม่เกี่ยวข้อง (หลีกเลี่ยงการดึงข้อมูลซ้ำจากแคช uop ประหยัดพลังงาน) พวกเขายังคงใช้พื้นที่ใน ROB จนกว่าพวกเขาจะสามารถออก พวกเขาไม่ได้ว่ามีนัยสำคัญ แต่ไม่เล็กน้อยอย่างใดอย่างหนึ่ง
Peter Cordes

2
ทำให้อาร์เรย์ของคุณใหญ่ขึ้นเพื่อที่คุณจะได้พลาด L3 และคุณอาจเห็นความแตกต่างที่ฉันทดสอบจำนวนมากด้วย16MiBบัฟเฟอร์และ10การวนซ้ำและแน่นอนได้รับ14,186868883 secondsvs 43,731360909 secondsและ46,76% of all LL-cache hitsvs 99,32% of all LL-cache hits; VS1 028 664 372 LLC-loads 1 587 454 298 LLC-loads
St.Antario

4
@ St.Antario: โดยการเปลี่ยนชื่อรีจิสเตอร์! นี่เป็นหนึ่งในส่วนที่สำคัญที่สุดของ OoO exec โดยเฉพาะอย่างยิ่งใน ISA ที่ลงทะเบียนไม่ดีเช่น x86 ดูเหตุใด mulss ใช้เวลาเพียง 3 รอบใน Haswell แตกต่างจากตารางคำแนะนำของ Agner (คลี่ FP ลูปที่มีสะสมหลาย) และ BTW โดยปกติคุณต้องการโหลด 2 ครั้งจากนั้น 2 สาขาไม่ใช่โหลด / เก็บโหลด / เก็บ โอกาสที่ดีกว่าในการหลีกเลี่ยงหรือลดขนาดแผงขายแทน 4k เนื่องจากการโหลดในภายหลัง
Peter Cordes

2
@ St.Antario: ใช่แน่นอน คู่มือการเพิ่มประสิทธิภาพของ Agner Fog ยังอธิบาย OoO exec ด้วยการเปลี่ยนชื่อรีจิสเตอร์เช่นเดียวกับวิกิพีเดีย BTW การเปลี่ยนชื่อรีจิสเตอร์ยังหลีกเลี่ยงอันตรายจาก WAW ทำให้เหลือการพึ่งพาที่แท้จริง (RAW) ดังนั้นการโหลดสามารถทำได้จนเสร็จสมบูรณ์โดยไม่ต้องรอให้โหลดก่อนหน้าเสร็จสิ้นเพื่อเขียนการลงทะเบียนสถาปัตยกรรมเดียวกัน และใช่แล้ว dep-chain-dep dep ที่ดำเนินการโดยลูปคือผ่าน RCX เพื่อให้เชนนั้นสามารถทำงานต่อไปได้ นั่นเป็นสาเหตุที่ทำให้แอดเดรสพร้อมใช้งานก่อนเวลาในขณะที่ load / store uops ยังมีปัญหาคอขวดในปริมาณพอร์ต 2/3
Peter Cordes

3
ฉันประหลาดใจที่การดึงข้อมูลล่วงหน้าไม่ได้ช่วย memcpy ใน L3 ฉันเดาว่า 10/12 LFB นั้น "เพียงพอ" ในกรณีนั้น ดูเหมือนว่าแปลก: อะไรคือปัจจัย จำกัด ที่นั่น? เวลาแกน -> L2 ควรน้อยกว่าเวลา L2 -> L3 ดังนั้นในแบบจำลองทางจิตของฉันที่มีบัฟเฟอร์มากขึ้น (จำนวนผู้ใช้ทั้งหมด) สำหรับขาที่สองน่าจะช่วยได้
BeeOnRope

3

ใช่ prefetcher L2 HW มีประโยชน์มาก!

ยกตัวอย่างเช่นสินค้าผลในเครื่องของฉัน (i7-6700HQ) ที่ทำงานtinymembench tinymembenchคอลัมน์แรกของผลลัพธ์คือเปิดใช้ prefetchers ทั้งหมดคอลัมน์ผลลัพธ์ที่สองอยู่ที่ L2 streamer off (แต่ prefetchers อื่น ๆ ยังคงเปิดอยู่)

การทดสอบนี้ใช้แหล่งข้อมูลและบัฟเฟอร์ปลายทาง 32 MiB ซึ่งมีขนาดใหญ่กว่า L3 ในเครื่องของฉันดังนั้นมันจึงเป็นการทดสอบที่พลาดไปยัง DRAM เป็นส่วนใหญ่

==========================================================================
== Memory bandwidth tests                                               ==
==                                                                      ==
== Note 1: 1MB = 1000000 bytes                                          ==
== Note 2: Results for 'copy' tests show how many bytes can be          ==
==         copied per second (adding together read and writen           ==
==         bytes would have provided twice higher numbers)              ==
== Note 3: 2-pass copy means that we are using a small temporary buffer ==
==         to first fetch data into it, and only then write it to the   ==
==         destination (source -> L1 cache, L1 cache -> destination)    ==
== Note 4: If sample standard deviation exceeds 0.1%, it is shown in    ==
==         brackets                                                     ==
==========================================================================

                                                       L2 streamer ON            OFF
 C copy backwards                                     :   7962.4 MB/s    4430.5 MB/s
 C copy backwards (32 byte blocks)                    :   7993.5 MB/s    4467.0 MB/s
 C copy backwards (64 byte blocks)                    :   7989.9 MB/s    4438.0 MB/s
 C copy                                               :   8503.1 MB/s    4466.6 MB/s
 C copy prefetched (32 bytes step)                    :   8729.2 MB/s    4958.4 MB/s
 C copy prefetched (64 bytes step)                    :   8730.7 MB/s    4958.4 MB/s
 C 2-pass copy                                        :   6171.2 MB/s    3368.7 MB/s
 C 2-pass copy prefetched (32 bytes step)             :   6193.1 MB/s    4104.2 MB/s
 C 2-pass copy prefetched (64 bytes step)             :   6198.8 MB/s    4101.6 MB/s
 C fill                                               :  13372.4 MB/s   10610.5 MB/s
 C fill (shuffle within 16 byte blocks)               :  13379.4 MB/s   10547.5 MB/s
 C fill (shuffle within 32 byte blocks)               :  13365.8 MB/s   10636.9 MB/s
 C fill (shuffle within 64 byte blocks)               :  13588.7 MB/s   10588.3 MB/s
 -
 standard memcpy                                      :  11550.7 MB/s    8216.3 MB/s
 standard memset                                      :  23188.7 MB/s   22686.8 MB/s
 -
 MOVSB copy                                           :   9458.4 MB/s    6523.7 MB/s
 MOVSD copy                                           :   9474.5 MB/s    6510.7 MB/s
 STOSB fill                                           :  23329.0 MB/s   22901.5 MB/s
 SSE2 copy                                            :   9073.1 MB/s    4970.3 MB/s
 SSE2 nontemporal copy                                :  12647.1 MB/s    7492.5 MB/s
 SSE2 copy prefetched (32 bytes step)                 :   9106.0 MB/s    5069.8 MB/s
 SSE2 copy prefetched (64 bytes step)                 :   9113.5 MB/s    5063.1 MB/s
 SSE2 nontemporal copy prefetched (32 bytes step)     :  11770.8 MB/s    7453.4 MB/s
 SSE2 nontemporal copy prefetched (64 bytes step)     :  11937.1 MB/s    7712.1 MB/s
 SSE2 2-pass copy                                     :   7092.8 MB/s    4355.2 MB/s
 SSE2 2-pass copy prefetched (32 bytes step)          :   7001.4 MB/s    4585.1 MB/s
 SSE2 2-pass copy prefetched (64 bytes step)          :   7055.1 MB/s    4557.9 MB/s
 SSE2 2-pass nontemporal copy                         :   5043.2 MB/s    3263.3 MB/s
 SSE2 fill                                            :  14087.3 MB/s   10947.1 MB/s
 SSE2 nontemporal fill                                :  33134.5 MB/s   32774.3 MB/s

ในการทดสอบเหล่านี้ที่มีลำแสง L2 นั้นไม่เคยช้าลงและมักจะเร็วเป็นสองเท่า

โดยทั่วไปคุณอาจสังเกตเห็นรูปแบบต่อไปนี้ในผลลัพธ์:

  • โดยทั่วไปสำเนาจะได้รับผลกระทบมากกว่าการเติม
  • standard memsetและSTOSB fill(เหล่านี้ต้มลงไปในสิ่งเดียวกันบนแพลตฟอร์มนี้) จะได้รับผลกระทบน้อยกับผลการดึงข้อมูลล่วงหน้าเป็นเพียงไม่กี่% เร็วกว่าโดยไม่ต้อง
  • มาตรฐานmemcpyน่าจะเป็นสำเนาเดียวที่ใช้คำสั่ง AVX ขนาด 32 ไบต์และเป็นหนึ่งในจำนวนที่ได้รับผลกระทบน้อยที่สุดจากการคัดลอก - แต่การดึงข้อมูลล่วงหน้านั้นยังเร็วกว่า ~ 40%

ฉันยังลองเปิดและปิดสาม prefetchers อื่น ๆ แต่โดยทั่วไปพวกเขาแทบจะไม่มีผลกระทบที่วัดได้สำหรับมาตรฐานนี้


(ความจริงแล้วสนุก: vmovdqaAVX1 แม้จะเป็น "จำนวนเต็ม") คุณคิดว่าวงของ OP นั้นให้แบนด์วิดธ์ต่ำกว่า glibc memcpy หรือไม่? และนั่นเป็นสาเหตุที่ 12 LFB เพียงพอที่จะรองรับปริมาณความต้องการที่เพิ่มขึ้นถึง L3 โดยไม่ต้องใช้ประโยชน์จาก MLP พิเศษจาก L2 <-> L3 superqueue ที่ L2 streamer สามารถครอบครองได้? นั่นคือความแตกต่างในการทดสอบของคุณ L3 ควรวิ่งด้วยความเร็วเท่ากับคอร์ คุณทั้งสองมีสถาปัตยกรรมแบบไมโครสโคป - ไคลเอนต์เทียบเท่า Skylake ดังนั้นจึงอาจมีเวลาแฝง L3 ที่คล้ายกัน
Peter Cordes

@PeterCordes - ขอโทษฉันอาจจะชัดเจน: การทดสอบนี้อยู่ระหว่าง 32 MiB บัฟเฟอร์ดังนั้นจึงเป็นการทดสอบ DRAM ที่นิยมไม่ใช่ L3 hits ฉันแม้ว่า tmb จะเอาท์พุทขนาดบัฟเฟอร์ แต่ฉันเห็นมันไม่ได้ - อ๊ะ! นั่นเป็นความตั้งใจ: ฉันไม่ได้พยายามอธิบายสถานการณ์ 512 KB ของ OP แต่เพียงแค่ตอบคำถามพาดหัวว่า L2 streamer มีประโยชน์กับสถานการณ์ที่แสดงให้เห็นหรือไม่ ฉันเดาว่าฉันใช้ขนาดบัฟเฟอร์เล็กลงฉันสามารถสร้างผลลัพธ์ได้มากขึ้นหรือน้อยลง (ฉันเห็นผลลัพธ์ที่คล้ายกันuarch-benchดังที่กล่าวไว้ในความคิดเห็น)
BeeOnRope

1
ฉันเพิ่มขนาดบัฟเฟอร์ลงในคำตอบ
BeeOnRope

1
@ St.Antario: ไม่มันไม่ใช่ปัญหา ไม่มีความคิดว่าทำไมคุณคิดว่ามันอาจจะเป็นปัญหา มันไม่เหมือนว่าจะมีบทลงโทษสำหรับการผสมคำแนะนำ AVX1 และ AVX2 ประเด็นของความคิดเห็นของฉันคือวงนี้ต้องการ AVX1 เท่านั้น แต่คำตอบนี้กล่าวถึงโดยใช้คำแนะนำ AVX2 Intel เกิดขึ้นเพื่อขยายเส้นทางข้อมูลการโหลด / เก็บ L1d เป็น 32 ไบต์ในเวลาเดียวกันกับการแนะนำ AVX2 ดังนั้นคุณอาจใช้ความพร้อมใช้งานของ AVX2 เป็นส่วนหนึ่งของวิธีที่คุณเลือกการใช้งาน memcpy หากคุณกำลังทำการแจกจ่าย runtime ...
Peter Cordes

1
คุณปิด prefetcher ได้อย่างไรและอันไหน มันเป็นsoftware.intel.com/th-th/articles/หรือไม่? ฟอรัมsoftware.intel.com/th-th/forums/intel-isa-extensions/topic/ ...... บอกว่าบางบิตมีความหมายแตกต่างกัน
osgx
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.