Точна копія машинного коду працює на 50% повільніше, ніж оригінальна функція


11

Я трохи експериментував із виконанням оперативної пам’яті та флеш-пам’яті у вбудованих системах. Для швидкого прототипування та тестування в даний час я використовую Arduino Due (SAM3X8E ARM Cortex-M3). Наскільки я можу бачити, час виконання та завантажувач Arduino тут не мають значення.

Ось питання: у мене є функція ( calc ), яка написана в Асамблеї великого пальця ARM. calc обчислює число і повертає його. (> 1s час виконання для заданого вводу) Тепер я вручну витягнув зібраний машинний код цієї функції і поставив його як необроблений байт в іншу функцію. Обидві функції підтверджені у флеш-пам'яті (адреси 0x80149 та 0x8017D, безпосередньо поруч). Це було підтверджено як за допомогою демонтажу, так і для перевірки часу виконання.

void setup() {
  Serial.begin(115200);
  timeFnc(calc);
  timeFnc(calc2);
}

void timeFnc(int (*functionPtr)(void)) {
  unsigned long time1 = micros();

  int res = (*functionPtr)();

  unsigned long time2 = micros();
  Serial.print("Address: ");
  Serial.print((unsigned int)functionPtr);
  Serial.print(" Res: ");
  Serial.print(res);
  Serial.print(": ");
  Serial.print(time2-time1);
  Serial.println("us");

}

int calc() {
   asm volatile(
      "movs r1, #33 \n\t"
      "push {r1,r4,r5,lr} \n\t"
      "bl .in \n\t"
      "pop {r1,r4,r5,lr} \n\t"
      "bx lr \n\t"

      ".in: \n\t"
      "movs r5,#1 \n\t"
      "subs r1, r1, #1 \n\t"
      "cmp r1, #2 \n\t"
      "blo .lblb \n\t"
      "movs r5,#1 \n\t"

      ".lbla: \n\t"
      "push {r1, r5, lr} \n\t"
      "bl .in \n\t"
      "pop {r1, r5, lr} \n\t"
      "adds r5,r0 \n\t"
      "subs r1,#2 \n\t"
      "cmp r1,#1 \n\t"
      "bhi .lbla \n\t"
      ".lblb: \n\t"
      "movs r0,r5 \n\t"
      "bx lr \n\t"
      ::
   ); //redundant auto generated bx lr, aware of that
}

int calc2() {
  asm volatile(
    ".word  0xB5322121 \n\t"
    ".word  0xF803F000 \n\t"
    ".word  0x4032E8BD \n\t"
    ".word  0x25014770 \n\t"

    ".word  0x29023901 \n\t"
    ".word  0x800BF0C0 \n\t"
    ".word  0xB5222501 \n\t"
    ".word  0xFFF7F7FF \n\t"
    ".word  0x4022E8BD \n\t"
    ".word  0x3902182D \n\t"
    ".word  0xF63F2901 \n\t"
    ".word  0x0028AFF6 \n\t"
    ".word  0x47704770 \n\t"
  );
}

void loop() {

}

Вихід вищезгаданої програми для цілі Arduino Due:

Address: 524617 Res: 3524578: 1338254us
Address: 524669 Res: 3524578: 2058819us

Таким чином, ми підтверджуємо, що результати є рівними, а адреса під час виконання - такою, як очікувалося. Виконання введеної вручну функції машинного коду відбувається на 50% повільніше.

Розбирання за допомогою arm-none-eabi-objdump додатково підтверджує відповідні адреси, резистентність флеш-пам’яті та рівність машинного коду (Примітка.

00080148 <_Z4calcv>:
   80148:   2121        movs    r1, #33 ; 0x21
   8014a:   b532        push    {r1, r4, r5, lr}
   8014c:   f000 f803   bl  80156 <.in>
   80150:   e8bd 4032   ldmia.w sp!, {r1, r4, r5, lr}
   80154:   4770        bx  lr

00080156 <.in>:
   80156:   2501        movs    r5, #1
   80158:   3901        subs    r1, #1
   8015a:   2902        cmp r1, #2
   8015c:   f0c0 800b   bcc.w   80176 <.lblb>
   80160:   2501        movs    r5, #1

00080162 <.lbla>:
   80162:   b522        push    {r1, r5, lr}
   80164:   f7ff fff7   bl  80156 <.in>
   80168:   e8bd 4022   ldmia.w sp!, {r1, r5, lr}
   8016c:   182d        adds    r5, r5, r0
   8016e:   3902        subs    r1, #2
   80170:   2901        cmp r1, #1
   80172:   f63f aff6   bhi.w   80162 <.lbla>

00080176 <.lblb>:
   80176:   0028        movs    r0, r5
   80178:   4770        bx  lr
}
   8017a:   4770        bx  lr

0008017c <_Z5calc2v>:
   8017c:   b5322121    .word   0xb5322121
   80180:   f803f000    .word   0xf803f000
   80184:   4032e8bd    .word   0x4032e8bd
   80188:   25014770    .word   0x25014770
   8018c:   29023901    .word   0x29023901
   80190:   800bf0c0    .word   0x800bf0c0
   80194:   b5222501    .word   0xb5222501
   80198:   fff7f7ff    .word   0xfff7f7ff
   8019c:   4022e8bd    .word   0x4022e8bd
   801a0:   3902182d    .word   0x3902182d
   801a4:   f63f2901    .word   0xf63f2901
   801a8:   0028aff6    .word   0x0028aff6
   801ac:   47704770    .word   0x47704770
}
   801b0:   4770        bx  lr
    ...

Ми можемо додатково підтвердити аналогічно використаний режим виклику:

00080234 <setup>:
void setup() {
   80234:   b508        push    {r3, lr}
  Serial.begin(115200);
   80236:   4806        ldr r0, [pc, #24]   ; (80250 <setup+0x1c>)
   80238:   f44f 31e1   mov.w   r1, #115200 ; 0x1c200
   8023c:   f000 fcb4   bl  80ba8 <_ZN9UARTClass5beginEm>
  timeFnc(calc);
   80240:   4804        ldr r0, [pc, #16]   ; (80254 <setup+0x20>)
   80242:   f7ff ffb7   bl  801b4 <_Z7timeFncPFivE>
}
   80246:   e8bd 4008   ldmia.w sp!, {r3, lr}
  timeFnc(calc2);
   8024a:   4803        ldr r0, [pc, #12]   ; (80258 <setup+0x24>)
   8024c:   f7ff bfb2   b.w 801b4 <_Z7timeFncPFivE>
   80250:   200705cc    .word   0x200705cc
   80254:   00080149    .word   0x00080149
   80258:   0008017d    .word   0x0008017d

Я можу виключити це через певний спекулятивний збір (який, здавалося б, у Cortex-M3!) Або перериває його. (EDIT: NOPE, я не можу. Можливо, якийсь попередній вибір) Зміна порядку виконання або додавання викликів функцій між ними не змінює результат. Що може бути винуватцем тут?


EDIT: Після зміни вирівнювання функції машинного коду (вставте крапки як пролог) я отримую такі результати:

+ 16 біт для calc2:

Address: 524617 Res: 3524578: 1102257us
Address: 524669 Res: 3524578: 1846968us

+ 32 біт для calc2:

Address: 524617 Res: 3524578: 1102257us
Address: 524669 Res: 3524578: 1535424us

+ 48 біт для calc2:

Address: 524617 Res: 3524578: 1102155us
Address: 524669 Res: 3524578: 1413180us

+ 64 біт для calc2:

Address: 524617 Res: 3524578: 1102155us
Address: 524669 Res: 3524578: 1346606us

+ 80 біт для calc2:

Address: 524617 Res: 3524578: 1102145us
Address: 524669 Res: 3524578: 1180105us

EDIT2: Тільки запущений calc:

Address: 524617 Res: 3524578: 1102155us

Тільки працює calc2:

Address: 524617 Res: 3524578: 1102257us

Зміна порядку:

Address: 524669 Res: 3524578: 1554160us
Address: 524617 Res: 3524578: 1102211us

EDIT3: Додавання .p2align 4перед міткою .inлише для calc, окреме виконання:

Address: 524625 Res: 3524578: 1413185us

Як у оригінальному орієнтирі:

Address: 524625 Res: 3524578: 1413185us
Address: 524689 Res: 3524578: 1535424us

EDIT4: Повернення положення спалаху повністю змінює результат. -> Лінійний попередній вибір?


Коментарі не для розширеного обговорення; ця розмова була переміщена до чату .
Самуель Liew

Відповіді:


4

Швидкість виконання коду від спалаху залежить від кількості циклів очікування та вирівнювання коду для кожної цілі гілки. У цьому та подібних процесорах, як STM32F103, для спалаху потрібні 3 цикли очікування, коли ядро ​​працює з найвищою частотою. Це означає, що кожна взята гілка може зайняти від 2 до 5 циклів, що може вплинути на загальний час виконання.

Для компенсації повільності FLASH ці процесори мають широку шину FLASH та буфер завантаження. SAM3X має пару 128-розрядних буферів інструкцій, які, схоже, заповнюються за схемою попереднього вибору [1].

Щоб оптимізувати щільний цикл, спробуйте помістити його в 32-байтовий блок коду та вирівняти його на 16-байтовій межі (або краще 32, про всяк випадок). Крім того, може бути гарною ідеєю перевірити, чи параметри FLASH налаштовані правильно, тобто попередній вибір увімкнено, а ширина шини встановлена ​​на 128 біт. Копіювання коду в оперативну пам’ять може бути варіантом, але це біль і може насправді сповільнити роботу, порівняно з правильно працюючими буферами для отримання.

[1] http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11057-32-bit-Cortex-M3-Microcontroller-SAM3X-SAM3A_Datasheet.pdf , сторінка 294, рисунки 18-2, 18-3 .

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.