История изменений

Читал читал, а также ещё и аналогичную растовскую поучительную историю https://ipthomas.com/blog/2023/07/n-times-faster-than-c-where-n-128/ :

поначалу, вроде-бы тоже упёрлись в вполне себе си-подобную замешанную на макросах ансейфную портянку на интринсиках с n =128, но в самом конце есть ссылка на умельца который просто чуток подсказал компилятору и … в 2 с лихером раза обошел эту портянку https://github.com/tommyip/n_times_faster_than_c/blob/4a1ec26c53a228daf3d14a61290129a69bc33c09/README.md вот такой вот красотой:

pub fn opt6_chunk_exact_count(input: &str) -> i64 {
    let iter = input.as_bytes().chunks_exact(192);
    let rest = iter.remainder();
    let mut n_s = iter
        .map(|chunk| chunk.iter().map(|&b| b & 1).sum::<u8>())
        .map(|chunk_total| chunk_total as i64)
        .sum::<i64>();
    n_s += rest.iter().map(|&b| b & 1).sum::<u8>() as i64;
    (2 * n_s) - input.len() as i64
}

при этом чистый сэйф(привет monk у), и сохранило читабельную связь с исходной задачей; и вот это будущее (и уже настоящее) оптимизации, а ассемблерный дроч, хоть и имеет местами значение, это тупиковая ветка из времён когда процессоры были простыми а компиляторы глупыми

Читал читал, а также ещё и аналогичную растовскую поучительную историю https://ipthomas.com/blog/2023/07/n-times-faster-than-c-where-n-128/ :

поначалу, вроде-бы тоже упёрлись в вполне себе си-подобную замешанную на макросах ансейфную портянку на интринсиках с n =127, но в самом конце есть ссылка на умельца который просто чуток подсказал компилятору и … в 2 с лихером раза обошел эту портянку https://github.com/tommyip/n_times_faster_than_c/blob/4a1ec26c53a228daf3d14a61290129a69bc33c09/README.md вот такой вот красотой:

pub fn opt6_chunk_exact_count(input: &str) -> i64 {
    let iter = input.as_bytes().chunks_exact(192);
    let rest = iter.remainder();
    let mut n_s = iter
        .map(|chunk| chunk.iter().map(|&b| b & 1).sum::<u8>())
        .map(|chunk_total| chunk_total as i64)
        .sum::<i64>();
    n_s += rest.iter().map(|&b| b & 1).sum::<u8>() as i64;
    (2 * n_s) - input.len() as i64
}

при этом чистый сэйф(привет monk у), и сохранило читабельную связь с исходной задачей; и вот это будущее (и уже настоящее) оптимизации, а ассемблерный дроч, хоть и имеет местами значение, это тупиковая ветка из времён когда процессоры были простыми а компиляторы глупыми

Читал читал, а также ещё и аналогичную растовскую поучительную историю https://ipthomas.com/blog/2023/07/n-times-faster-than-c-where-n-128/ :

поначалу, вроде-бы тоже упёрлись в вполне себе си-подобную замешанную на макросах ансейфную портянку на интринсиках с n =127, но в самом конце есть ссылка на умельца который просто чуток подсказал компилятору и … в 2 с лихером раза обошел эту портянку https://github.com/tommyip/n_times_faster_than_c/blob/4a1ec26c53a228daf3d14a61290129a69bc33c09/README.md вот такой вот красотой:

pub fn opt6_chunk_exact_count(input: &str) -> i64 {
    let iter = input.as_bytes().chunks_exact(192);
    let rest = iter.remainder();
    let mut n_s = iter
        .map(|chunk| chunk.iter().map(|&b| b & 1).sum::<u8>())
        .map(|chunk_total| chunk_total as i64)
        .sum::<i64>();
    n_s += rest.iter().map(|&b| b & 1).sum::<u8>() as i64;
    (2 * n_s) - input.len() as i64
}

при этом чистый сэйф, и сохранило читабельную связь с исходной задачей; и вот это будущее (и уже настоящее) оптимизации, а ассемблерный дроч, хоть и имеет местами значение, это тупиковая ветка из времён когда процессоры были простыми а компиляторы глупыми