All streams
Search
Write a publication
Pull to refresh
100
0
Ермолаев Игорь @ErmIg

Пользователь

Send message

Как раскрутить астероид для создания искусственной гравитации и не разрушить его, с учетом того, что они по большей части представляют собой слабосвязанную кучу камней?

Красивая математика, но в реальных алгоритмах не взлетит, как и алгоритм Штрассена впрочем.

Как мне кажется задача упирается прежде всего в пропускную способнось памяти, а не в вычислительные возможности процессора. Intel Core i7-9700K имеет теоретическую производительность 50 GFLOPS на ядро (FP64) для FMA. В вашем цикле порядка 10 операций умножения и сложения. Значит теоретически он может выполняться раз в 10 быстрее (~500 мс). Все упирается в пропускную способность памяти, а не в векторизацию и т.п. Это к стати ответ, почему Эльбрус почти догнал гораздо более высокочастоный Intel и Power.

Посмотрел. У них все выглядит гораздо продуманней: аппарат и легче и безопаснее (для пилота).

Зависит от задачи. Но если суммировать порядка 10^6 чисел, то легко получить погрешность во 2-3 знаке. Причем результат будет различасться в зависимости от того, что используешь: Scalar/SSE/AVX/AVX-512 (см подробнее здесь). Впрочем чем больше длина вектора, тем погрешность меньше.

Ну таких опций компилятора наверное еще не придумали. Я лично этот метод руками писал для нахождения суммы разностей квадратов на fp32 (вот пример на SSE см SquaredDifferenceKahanSum32f ).

Код на x87 скалярный, 80-bit регистры загружаются по невыровненному адресу за несколько тактов. Единственное возможное преимущество - повышенная точность, но ее можно достичь другими методами (например см метод Кэхена). Если оставаться в рамках стандартных 64-bit, то можно задействовать SSE, AVX, AVX-512. Это легко перекроет выгоду от x87 даже с учетом более медленного алгоритма.

Касательно оптимизации загрузки NEON векторов, я бы еще посмотрел в сторону выровненной загрузки и использования префетча:

#define PREFECH_SIZE 384

        template <bool align> inline uint8x16_t Load(const uint8_t * p);

        template <> inline uint8x16_t Load<false>(const uint8_t * p)
        {
#if defined(__GNUC__) && PREFECH_SIZE
            __builtin_prefetch(p + PREFECH_SIZE);
#endif
            return vld1q_u8(p);
        }

        template <> inline uint8x16_t Load<true>(const uint8_t * p)
        {
#if defined(__GNUC__)
#if PREFECH_SIZE
            __builtin_prefetch(p + PREFECH_SIZE);
#endif
            uint8_t * _p = (uint8_t *)__builtin_assume_aligned(p, 16);
            return vld1q_u8(_p);
#elif defined(_MSC_VER)
            return vld1q_u8_ex(p, 128);
#else
            return vld1q_u8(p);
#endif
        }

В некоторых случаях помогает (величиной PREFECH_SIZE лучше поиграться).
Чтобы что-то отправить из архива, нужно его прежде туда сохранить. Если интересуют редко встречающиеся ситуации, которые плохо распознаются, то боюсь придется сохранять очень много — т.к. порог на срабатывание нужно будет сильно занижать.
Небольшое замечание по поводу AVX2 версии:
Есть такая замечательная инструкция VPSHUFB (_mm256_shuffle_epi8, Avx2.Shuffle), которая может использоваться в качестве lookup таблицы из 16 одно байтовых значений.
Этой операцией можно заменить почти все битовые операции во втором цикле.
Ну как не упирается? Для суммирования изображения это обычно так. Смотрите: Ваш процессор с AVX имеет производительность порядка 50 GFLOPS на ядро, а для такого быстродействия потребуется загрузить 50 * 2 * 4 = 400 GB данных в секунду, тогда как пропускная способность памяти на канал порядка 10 GB в секунду. Т.е. в 40 раз меньше.
Дополнительные потоки позволяют задействовать второй канал памяти. Кроме того, если размеры изображения не велики — все данные могут вмещаться в кеш процессора. Но даже для кеша L1 — 400 GB данных в секунду — это многовато. А ведь результаты нужно еще сохранять.

Операция свертки, или медианная фильтрация теоретически могут задействовать все вычислительные ресурсы процессора. Но там паритета вроде нет?
Вы не проверяли: там где наблюдается паритет скорости, не упирается ли все в пропускную способность памяти?
Круто! Я честно говоря сам думал о похожей оптимизации, но все руки не доходили. Я добавлю ваш код в основную ветку.
Не все AVX512 юниты одинаково полезны. Во втором юните дублируются только наиболее востребованные операции. В документации в описании конкретной операции есть параметр Throughput (CPI), который по сути обратная величина от максимального количества таких операций за такт.
P.S. Возникает вопрос: почему ускорение от AVX-512 не в два раза, а только на 30-35%? Дело в том, что в SkylakeX только 1 AVX-512 модуль, который выполняет операции вычисления целочисленных min/max, в тоже время у него 2 AVX-256 таких модуля, которые могут быть задействованы параллельно.
В статье сравнивалась медианная фильтрация с окном 3x3. В ней сравнительно мало операций. Изображение сравнительно большое ~2MB (входное и выходное влезает в L3, но не влезает в L2). Потому уже начиная с AVX2 узким местом становится именно загрузка данных, а не сами операции с ними.
Если увеличить размер фильтра (хотя бы до 5x5), то ускорение от AVX2 и AVX-512BW значительно увеличиться.
Собственно в Simd есть реализация медианного фильтра с окном 3х3 и 5х5, с которыми там можно поиграться во встроенных тестах.
Для окна 5x5 AVX2 дает ускорение практически в 100 раз, AVX-512BW почти в 130 раз.
Теоретически проводники можно включить в матрицу, например, то же алмаз, который будет поддерживать нужное давление.
Новость интересная, но перевод желательно делать не с помощью translate.google — от перевода буквально режет глаза.
Есть русский (Россия) и русский (Беларусь) — и это разные по правилам написания языки. Так же как есть Британский и Американский английский язык.
Да. Трекинг объектов без ярко выраженного идентификатора (лица, автомобильные номера) — очень нетривиальная задача. Но есть более сложная — многокамерный трекинг объектов… :)

Information

Rating
4,853-rd
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity