segv при элементарном обходе массива

вызывает segv по непонятной причине

Абсолютная адресация в 64битном режиме может вычислять некорректный арес, так как компоновщик размещает дату в произвеольном мете витуальной памяти. Что если использовать относительную?

.equ QLEN, 8

.equ SYS_EXIT, 60
.equ EXIT_FAILURE, 0
.equ EXIT_SUCCESS, 1

.section .data
.align 8
val: .quad 9
len: .quad 5
arr: .quad 4, 9, 3, 8, 4

.section .text
.globl _start
.align 16

_start:
  movq val(%rip), %rax
  movq $EXIT_FAILURE, %rdi
  movq len(%rip), %rcx
  cmpq $0, %rcx
  je exit

  leaq arr(%rip), %rsi

loop:
  movq -QLEN(%rsi,%rcx,QLEN), %rdx
  cmpq %rdx, %rax
  movq $EXIT_SUCCESS, %rdx
  cmoveq %rdx, %rdi
  loop loop

exit:
  movq $SYS_EXIT, %rax
  syscall

а да, точно, спс

Из забавного, я сделал такой же код на си - он в 0.4 раза быстрее ассемблерного. Хм, может я криво написал, оченьм мало с ним работаю. Примерно такой же кд на луа всего в 2 раза медленнее, что вообще поражает.

А теперь самое интересное: я сделал такой же код на раст и сишный медленнее в полтора раза.

Ладно, надо больше спать. Что я вообще творю.

надо смотреть на дисассембл, мож там другие инструкции. если as и gcc имеют разный уровень оптимизации (например, c может заменить весь цикл на exit(1) :)). насчёт rust и lua хз, но подобное возможно и там (или пляски с линкером в рантайм). спать то да. не спать не получится

Гланый тормоз - loopne. Я сейчас попробовал dec/jnz - в 4.6 раз быстрее. Все еще медленнее раста вдвое. Но я хз как глянуть во что превращает код раст. Там какие то еще оптимизации свои.

в 4.6 раз быстрее. Все еще медленнее

а теперь разверни цикл простой копипастой интсрукций по количеству итераций и замерь еще раз.

в гцц, например, есть -funroll-loops для этого

objdump -S

Круто, в полтора раза быстрее раста. Но универсльности ноль, читабельность в жопе, размер кода линейно растет.

Ну да, раст полностью разворачивает цикл, как выше вон предложили. Нет проверок границ, константы зашивает, работает через временное хранилще, оптимизирует выход. Интересное. Вот только использует стек для хранения загрузки, а это медленее чуть чуть, чем напрмую.

Может немного удивлю, хотя врядли. Попробуй такой «бенчарк».

use std::process::exit;

const ITERS: usize = 1_000_000_000;
const ARR: [i64; 5] = [4, 9, 3, 8, 4];
const VAL: i64 = 9;
const LEN: usize = 5;
const EXIT_FAILURE: i32 = 0;
const EXIT_SUCCESS: i32 = 1;

fn main() {
    let mut found = EXIT_FAILURE;
    
    for _ in 0..ITERS {
        found = EXIT_FAILURE;
        let mut i = LEN;
        while i > 0 {
            i -= 1;
            if ARR[i] == VAL {
                found = EXIT_SUCCESS;
                break;
            }
        }
    }
    
    exit(found);
}

Godbolt показывает какую-то дичь. Ну или результат вычисленный во время компиляции, если указать -O

https://godbolt.org/z/GocoraT6r

Без -O нет смысла смотреть, а чтобы результат не вычислял во время компиляции добавь std::hint::black_box вокруг доступа к массиву.

А ты выполни сразу как код и посмотри результат.

Чисто формально код тот же по сути. Ну почти.

Ну вот, взял всю интригу испортил.

Он там все равно какую-то дичь делает. Казалось бы, хочешь развернуть цикл, так разверни. К чему он этих sse пересылок навтыкал? Есть подозрение что это баг и он лишнего захватил когда тело цикла разворачивал. К тому же он использует сложную адресацию в cmp, на которую нужен +1 такт

Ну результат то верный? Верный. Чего тебе еще надо? Причем мгновенно.

Вернёмся к оп посту. Как думаешь автор озадачился вопросом потому что у него не мгновенно ищется элемент в массиве из 5 элементов?

Атор на 64битной системе пытался искать в 32битном смещении. В итоге данные попадали за пределы поиска и вылезала ошибка.

Просто мне интересно стало сравнить скорость между языками и вылезло неожиданное. По крайней мере для меня.