• Обновление до Windows 1809 (иногда) уничтожает все файлы в профиле
    0

    Думал вы скажете, почему будет меньший износ ячеек от внутреннего сжатия по сравнению с внешним. Тут опять же, сжатие на уровне ОС ничем не хуже. Все еще не понятно, за что TonyLorencio и Googlist его так не любят.

  • Обновление до Windows 1809 (иногда) уничтожает все файлы в профиле
    0

    За счет чего?

  • Обновление до Windows 1809 (иногда) уничтожает все файлы в профиле
    0

    Как вы себе представляете сжатие в дисках? Даже если бы это было так, допустим, на диск записали два гигабайта, он сжал это в два раза, записал только один. Как он сообщит системе, что еще один гигабайт остался свободен? А если не сообщит, то какая разница, что он там внутри себя делает, пусть хоть в интернет пишет, какая разница, если с точки зрения пользователя это ничего не меняет?


    двойное сжатие не даст єффекта.

    Верно, как и одинарное на стороне диска не дает никакого эффекта, разве что возможно чуть более быстрая записи. Так этот эффект будет и при сжатии на стороне операционной системы. При таком раскладе разумно выключить именно сжатие на стороне диска, а не на стороне операционной системы.

  • Обновление до Windows 1809 (иногда) уничтожает все файлы в профиле
    0

    Так как тут много пользователей виндуса, не могу придумать лучшего места, чтобы спросить.


    Несколько дней назад объявили или не объявили о выходе Edge 18. Я не могу найти информации ни как на него обновиться, ни когда он точно выходит. Гугл подсовывает лендинги майкрософта и статьи без конкретики. Уже достало, четно говоря, искать хоть какую-то инормацию. Кто-то может объяснить, как можно сейчас поставить Edge 18 на виртуалку или когда это будет возможно?

  • Обновление до Windows 1809 (иногда) уничтожает все файлы в профиле
    0
    а затем включают сжатие, чтобы места больше было

    Какие у вас проблемы со сжатием? Почему выделили курсивом, считаете это странным, использовать сжатие чтобы сжимать?

  • Ускорение кода на Python средствами самого языка
    0

    img это объект изображения в библиотеке Pillow. img.load() возвращает объект доступа к пикселям. Странно, конечно, что автор об этом ничего не сказал.

  • Ускорение кода на Python средствами самого языка
    0
    Просто если pix = [[1, 2], [3, 4]]

    Так pix это не список, это то что возвращает img.load().

  • Быстрый ресайз джипегов на видеокарте
    0

    Я ничего не продаю. Pillow-SIMD и libjpeg-turbo совершенно бесплатны в том числе для коммерческого использования.

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0

    Да, приводит, потому что есть такая штука как дисктовый кеш в оперативной памяти. Даже при достаточной сильной загруженности памяти, ОС все равно старается держать его в районе 20%. Например сейчас у меня на маке он 1,3 Гб из 8, хотя запущено много чего и свободной памяти явно нет. А на винде он сейчас вообще 4,5 Гб из 8, потому что не особо много что запущено.


    И вот винда имеет свойство иногда решить (если процессами давно никто не пользуется), что приложения можно бы уже скинуть в своп, а освободившее место занять дисковым кешем.

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0

    Не могу пояснить, не понимаю, что вы спросили.

  • Быстрый ресайз джипегов на видеокарте
    +2
    Так сделайте измерения на 72 виртуальных CPU и покажите результат.

    А вы мне что? )


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


    Во-первых я сделал в репозитории pillow-perf ветку fastvideo-competition, в которой переписан тест full_cycle, чтобы максимально соответствовать тому, что делаете вы. Там 4 тесткейса:


    • Load+save — только загрузка и сохранение jpeg.
    • +resize — добавляется ресайз посередине. По большей части два этих кейса просто прогревают CPU, чтобы успел выключиться TurboBoost, про который вы упоминали
    • +sharp — добавляется шарп. Это основной тесткейс, результаты которого нас интересуют
    • +sharp — еще один тест, который дублирует предыдущий, чтобы когда какой-то процесс заканчивал работу, нагрузка на CPU не падала и результат не искажался

    Тесты запускаются командой ./pillow-perf/testsuite/run.py full_cycle -s 1920x1080 -n 1024 и никак иначе, без параметра -s во-первых будут неправильно считаться мегапиксели в секунду, во-вторых я поставил там assert ) Результаты будут выводиться для медианного запуска из 1024 попыток.


    Теперь, где будем запускать. Ваше предложение запускать «на 72 виртуальных CPU» очень заманчиво, но не выглядит разумным. Запуская кучу инстансов помельче вы получаете отказоустойчивость и лучшую гранулярность (очень маловероятно, что вам нужно обрабатывать ровно 1500 картинок в секунду, ни больше, ни меньше). Впрочем, жестить и запускать 36 машин тоже не стоит. Я остановился на одном инстансе c5.2xlarge с 8 виртуальными и 4 физическими ядрами. Думаю, не нужно доказывать, что два запущенных рядом одинаковых инстанса будут работать ровно в два раза быстрее, чем один. А 9 ровно в 9 раз быстрее, что по цене и производительности в точности равно одному c5.18xlarge инстансу.


    Всего будет 6 тестов: один поток, 4 потока, 8 потоков и всё еще раз, но с libjpeg-turbo 2.0.


    Многопоток будет запускаться такой командой:


    time (./run.py full_cycle -s 1920x1080 -n 1024 &\
          ./run.py full_cycle -s 1920x1080 -n 1024 &\
          ./run.py full_cycle -s 1920x1080 -n 1024 &\
          ./run.py full_cycle -s 1920x1080 -n 1024 &\
          wait)

    Ладно, поехали.


    Один поток, libjpeg-turbo 1.4.2


    $ time ./run.py full_cycle -s 1920x1080 -n 1024
    
    Full cycle 1920×1080 RGB image
        Load+save           0.02544 s    81.51 Mpx/s
        +resize             0.02222 s    93.33 Mpx/s
        +sharp              0.02335 s    88.81 Mpx/s
        +sharp              0.02335 s    88.80 Mpx/s
    
    real    1m36.680s
    user    1m36.228s
    sys     0m1.004s

    Получается 0.02335 s на процессинг одной картинки. Моя оценка была, напомню, 0.0224 s. Дальше в секундах измерять не имеет смысла, буду писать фрупут в мегапикселях и в операциях в секунду. Ну и не буду писать результаты остальных тестов, чтобы экономить место.


    4 потока, libjpeg-turbo 1.4.2


        +sharp              0.02317 s    89.49 Mpx/s
        +sharp              0.02352 s    88.16 Mpx/s
        +sharp              0.02354 s    88.09 Mpx/s
        +sharp              0.02356 s    88.00 Mpx/s
    real    1m37.357s
    user    6m25.228s
    sys     0m2.800s

    1/0.02317 + 1/0.02352 + 1/0.02354 + 1/0.02356 = 171 операция в секунду
    89.49 + 88.16 + 88.09 + 88.00 = 353 Mpx/s


    Проверяем: 353/1920/1080*10**6 = 171. Сходится, как ни странно )


    8 потоков, libjpeg-turbo 1.4.2


        +sharp              0.03690 s    56.19 Mpx/s
        +sharp              0.03690 s    56.19 Mpx/s
        +sharp              0.03805 s    54.50 Mpx/s
        +sharp              0.03803 s    54.53 Mpx/s
        +sharp              0.03806 s    54.48 Mpx/s
        +sharp              0.03802 s    54.53 Mpx/s
        +sharp              0.03810 s    54.43 Mpx/s
        +sharp              0.03811 s    54.42 Mpx/s
    real    2m36.108s
    user   20m31.172s
    sys     0m6.672s

    439 Mpx/s, 212 запусков в секунду.


    Один поток, libjpeg-turbo 2.0


    $ time ./run.py full_cycle -s 1920x1080 -n 1024
    
    Full cycle 1920×1080 RGB image
        Load+save           0.02120 s    97.81 Mpx/s
        +resize             0.01968 s   105.37 Mpx/s
        +sharp              0.02063 s   100.53 Mpx/s
        +sharp              0.02057 s   100.79 Mpx/s
    
    real    1m24.265s
    user    1m23.808s
    sys     0m0.912s

    Полный вывод, чтобы просто сравнить с libjpeg-turbo 1.4.2.


    4 потока, libjpeg-turbo 2.0


        +sharp              0.02049 s   101.20 Mpx/s
        +sharp              0.02079 s    99.74 Mpx/s
        +sharp              0.02085 s    99.45 Mpx/s
        +sharp              0.02118 s    97.91 Mpx/s
    real    1m25.715s
    user    5m36.984s
    sys     0m2.768s

    398 Mpx/s, 192 запусков в секунду.


    8 потоков, libjpeg-turbo 2.0


        +sharp              0.03201 s    64.77 Mpx/s
        +sharp              0.03203 s    64.74 Mpx/s
        +sharp              0.03246 s    63.88 Mpx/s
        +sharp              0.03246 s    63.88 Mpx/s
        +sharp              0.03303 s    62.77 Mpx/s
        +sharp              0.03303 s    62.77 Mpx/s
        +sharp              0.03296 s    62.91 Mpx/s
        +sharp              0.03295 s    62.92 Mpx/s
    real    2m10.901s
    user   17m12.692s
    sys     0m5.824s

    508 Mpx/s, 245 запусков в секунду.


    Ну и сводная табличка:


    |             | MPx/s | Op/s c5.2xlarge | Op/s c5.18xlarge |
    |-------------|-------|-----------------|------------------|
    | 1c, lib 1.4 | 89    | 43              | -                |
    | 4c, lib 1.4 | 353   | 171             | 1539             |
    | 8c, lib 1.4 | 439   | 212             | 1908             |
    | 1c, lib 2.0 | 101   | 48              | -                |
    | 4c, lib 2.0 | 398   | 192             | 1728             |
    | 8c, lib 2.0 | 508   | 245             | 2205             |

    Спасибо за подсказку с тредами, я был уверен, что это бесполезная фигня )

  • Быстрый ресайз джипегов на видеокарте
    +2
    Джипег не является беспотерьным алгоритмом именно из-за этих округлений

    Очень странно такое слышать от людей, занимавшихся разработкой кодека джипег. Джипег не является беспотерьным алгоритмом вообще не из-за округлений )

  • Быстрый ресайз джипегов на видеокарте
    +1
    36 виртуальных ядер (18 реальных) — это отлично.

    У c5.18xlarge инстансов 72 виртуальных ядра, 36 реальных. Так что умножение на 36 является пессимистичным в моих расчетах.


    В данном случае Tesla V100 — не оптимальный вариант. Оптимальный по цене вариант можно выбрать для заданного набора параметров задачи.

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


    Когда делают ресайз 2560->320, то таким образом явно улучшают результат для CPU.

    Я не понимаю, при чем тут 2560→320. Результаты для ресайза 2560→2048 и 2560→320 — это те цифры, которые были у меня на руках без дополнительных бенчмарков. Я их довольно грубо экстраполировал до 2048→1024, но не думаю, что моя оценка имеет точность меньше ±25%.


    Интересно, сколько получается на CPU?

    Будет что-то близкое к результату 2560→2048.


    Пользователь запросто может прислать картинку на 8 или 12 МПикс, а сохранять её в таком виде не стоит.

    Стоит или не стоит — зависит от задачи, тут уже не разработчику библиотек решать.

  • Быстрый ресайз джипегов на видеокарте
    0

    Тут оказывается вышла libjpeg-turbo 2.0, я потестил, можно накинуть еще 15% к скорости распаковки и запаковки. А так как это самая дорогая операция, мы получаем уже не 44, а 48 операций в секунду на ядро, или 1722 операции в секунду за те же деньги.

  • Быстрый ресайз джипегов на видеокарте
    +1

    Однако же в libjpeg-turbo все операции выполняются в целых числах: https://libjpeg-turbo.org/About/SIMDCoverage

  • Быстрый ресайз джипегов на видеокарте
    +1

    Давайте вместе посчитаем. Возьмем для примера цены AWS EC2:


    p3.2xlarge инстанс имеет на борту одну NVIDIA Tesla V100 GPU и стоит $3.06 в час.
    Столько же стоит c5.18xlarge инстанс на новых процессорах Intel c 36 ядрами.


    Сравнивать буду с одной из самых быстрых бесплатных библиотек для обработки изображений Pillow-SIMD.


    На странице бенчмарков пока что нет результатов c5 инстансов, поэтому возьмем результаты для c4. Уверяю, что c5 работают не медленнее.


    Сразу выпишу интересующие нас операции:


    Jpeg load speed = 181 Mpx/s
    Lanczos resize speed = 300 Mpx/s
    Sharp filter speed = 524 Mpx/s
    Jpeg save speed = 166 Mpx/s

    Скорости ресайза именно в два раза нет (потому что при уменьшении в кратное количество раз всегда можно считерить и сделать быстрее, так что для бенмарков такие значения лучше не брать), есть результаты для уменьшения в 1,25 раз (238 Mpx/s) и результаты для уменьшения в 8 раз (658 Mpx/s). Мне лень сейчас делать бенчмарк, поэтому я «на глазок» взял 300 Mpx/s.


    Все результаты приведены для одного ядра.


    Сравнивать будем на 2K разрешении, так как это разрешение показало значительно более хорошие результату на Tesla V100.


    Jpeg load time = 1920*1080 / 10**6 / 181 = 0.0115 s
    Lanczos resize time = 1920*1080 / 10**6 / 300 = 0.0069 s
    Sharp filter time = 960*540 / 10**6 / 524 = 0.001 s
    Jpeg save time = 960*540 / 10**6 / 166 = 0.003 s
    Total speed = 1 / (0.0115 + 0.0069 + 0.001 + 0.003) = 44 op/s

    Итого, 44 операции в секунду на одном ядре. Или 44×36 = 1584 операции в секунду на процессоре за ту же цену.


    Плюс практически пропорциональное увеличение производительности при уменьшении входного разрешения (как вы видите, для видеокарты при переходе от 2К к 1К производительность практически не растет). Плюс отсутствует необходимость проставлять рестарт-маркеры или иным образом модифицировать исходный контент. Плюс большая гибкость в выборе и добавлении других операций (не требуется перекомпиляция) или форматов. Плюс возможность разрабатывать и тестировать на обычном рабочем ПК или ноутбуке.


    Минус только в задержке. В случае обработки на CPU одно изображение все равно будет ресайзится минимум за 23 мс, тогда как на GPU этот показатель от 1,1 до 1,5 мс.

  • Быстрый ресайз джипегов на видеокарте
    +1
    В оффлайне с помощью ImageMagick, OpenCV или аналогичного софта, сохраняем цветовой профиль

    Забавно, что вы упоминаете OpenCV, потому что в ней нет вообще никакой возможности получить цветовой профиль. OpenCV — это библиотека компьютерного зрения, а не работы с зоопарком графических форматов.


    затем утилитой jpegtran добавляем рестарт-маркеры с заданным фиксированным интервалом.

    Интересно было бы узнать оптимальный интервал, хотя бы для конкретно вашего декодера.

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0

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


    ОС как раз не знает — предполагает.

    ОС как раз точно знает, какие страницы использовались в последнее время.


    В уже приведенном примере — для меня какая-то вкладка в браузере — всегда горячие данные. я хочу их в любой произвольный момент времени в памяти, а не в свопе

    И в чем отличие от гибернации? Что будет держать вашу любимую вкладку в памяти при гибернации?


    Простите? Если это моё приложение и весь код — тоже мой, я точно знаю какой код какие данные использует и зачем.

    Я рад, что вам не приходилось писать приложения больше 100к строк кода. К ожалению, браузеры намного более сложный продукт.


    Что ж тогда при её использовании максимум на 50% в своп что-то валится?

    Это элементарное логическое утверждение. Из того, что А является причиной для B никак не следует, что других причин у В быть не может. Я уже говорил, что в виндусе дисковые операции активно вытесняют память приложений в своп.


    Да, я в курсе про мантру «выгрузить всё что редко используется и отдать память кэшу» — но я этого не хочу

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


    Потому что я могу поставить на вкладке метку «не трогать»

    Что-то я видимо невнимательно прочитал статью, что не заметил там никаких меток. Опять какой-то придуманный мир?

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0
    ОС не имеет понятия о том что является горячими или холодными данными для приложения

    ОС как раз знает по факту, какие данные являются горячими. А приложение может лишь предполагать, потому что приложения большие и сложные и то что ваш код не использует какие-то данные, не значит что их не использует какой-то другой код.


    простой факт длительного неиспользования или редкого использования (пусть даже с элементами эвристики или даже AI) — вовсе не показатель того что память можно выгружать (это зависит от задачи).

    Верно. Показатель того, что память можно выгружать — наличие виртуальной памяти и подкачки. А показатель того, что память нужно выгружать — нехватка памяти. Что именно выгружать — вопрос алгоритмов ОС. Тут все просто — либо мы хотим многозадачности и тогда нужна подкачка и выгружать можно всё что угодно. Либо мы хотим сами управлять, что выгружать, тогда наш выбор однозадачность. Но что-то я не слышал, чтобы яндекс-браузер можно было загрузить в однозадачном режиме вместо ОС.


    подкачка не знает что если нечто не использовалось аж 23 часа может вдруг потребоваться мгновенно и заранее подкачать это к нужному моменту.

    А гибернация знает заранее? )

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0

    Каким образом контролируемое поведение в отрыве от всего остального может помочь? Вы можете например на бумажке карандашом исполнять процессорные инструкции, будете иметь 100% контроль над выполнением, но ускорения программы вы этим конечно же не добьетесь.

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0

    Жаль, что мое вопросы выше остались без ответа (

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0

    Вы несёте бред. Подкачка — это стандартный механизм всех ОС начиная с windows 3.1. Именно благодаря подкачке стала возможна истинная многозадачность и сильно упростилась разработка приложений, т.к. каждому приложению больше не нужно писать свой менеджер памяти. Память теперь условно бесконечная.


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

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0
    Когда мы говорим что процесс вкладки лежит в свопе, значит есть нехватка памяти

    Нет, не значит. Вы отвечаете на комментарий, в котором я описываю почему так может случится.


    ОС потребуется сжать WorkingSet других процессов, чтобы освободить RAM, куда загрузить страницы из свопа. Т.е. потребуется сначала сохранить в своп «не нужные» страницы, а потом загрузить «нужные».

    То же самое, что и при гибернации.


    И таких страниц в 5-10 раз больше чем нужно для сохранения в режиме Hibernate.

    Таких страниц (которых нужно освободить) будет ровно столько, сколько нужно реальной памяти, чтобы в ней поместилась вкладка. Но есть отличие: при свопе будут восстановлены только те страницы, которые нужны здесь и сейчас, их может оказаться 50% или меньше. При Hibernate нужно будет восстановить всю память процесса, даже если 80% не нужно для отображения прямо сейчас.

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    +2
    3 Мы работаем превентивно и не даем системе «уйти в своп».

    Вот это я не совсем понимаю. Для того, чтобы что-то ушло в своп, не обязательно должно не хватать памяти. Windows очень охотно вымывает память приложений при обычной дисковой активности. Это конечно большая проблема для пользователей, но для вас это данность. В результате фоновые вкладки скорее всего и так уже уйдут в своп после первой фоновой проверки антивируса или ежедневной индексации диска. Так что когда действительно понадобится память, вы начнете перекладывать старые вкладки с диска на диск, чем только усугубите ситуацию.


    4 ОС может загрузить из свопа из-за необязательной фоновой активности.

    Так такую фоновую активность нужно в первую очередь останавливать, а уже потом думать над другими способами оптимизации.

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0
    Ну, возможно, в том, что тут будут выгружаться только неактивные данные.

    И в чем отличие с фалом подкачки? Только в том, что файл подкачки более гранулярный и может выгрузить неиспользуемую память даже у текущей вкладки, если она не была нужна какое-то время. То есть файл подкачки в этом смысле эффективнее.

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    +2

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

  • iOS CSS of death
    0
    Блюр фильтр конечно довольно ресурсоемкая вещь, но не то, чтобы критически. Никаких проблем — секунд на 5-7 работы на уже 10 летней давности процессоре.

    Вы продолжаете «не обращать внимание». Backdrop-filter накладывается не на содержимое элемента, а на фон, который под ним. А фоном для элемента в том числе является родительский элемент. А там 3485 вложенных элементов. Более того, это фильтр гауссова размытия, так что для того, чтобы отрисовать экран 1000x1000 пикселей, нужно взять фон примерно 1030x1030 пикселей под ним. В результате уже где-то на 300-м элементе и дальше нужно размывать все 10000x10000 пикселей, а не только то, что видно на экране.


    Возможно в сафари такой же глюк как и хроме и он вложенные дивы пытается последовательно вывести

    Я уже выше писал, что нет, Сафари верно показывает вложенные дивы. Более того, если располагать элементы последовательно, нет никакой проблемы это отрисовать — нужно будет отрисовывать только то, что на экране, а на экране строго фиксированное количество пикселей, еще и пустых в случае filter, а не backdrop-filter.

  • iOS CSS of death
    +7

    Там вполне конечная рекурсия, просто очень затратная. backdrop-filter — это очень дорогая операция.

  • iOS CSS of death
    +5

    Там в исходном в коде несколько тысяч вложенных друг в друга блоков в которых через стили прописаны размеры 10000 х 10000 пикселей. То есть все вместе они должны занимать 10000 х 10000 пикселей, что корректно отображает ФФ и Сафари, если убрать backdrop-filter.


    При этом проблем со стабильностью или производительностью в Хроме или Лисе подобная страница не вызывает

    Еще бы вызывала, в них же нет никаких backdrop-filter.

  • iOS CSS of death
    0

    А почему в хроме эта страница имеет бесконечную высоту не сообщается?

  • PHP 7.3. Что нового
    +3

    Блин, ваш комментарий более информативен, чем вся статья )

  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    Во-первых, что значит «например» — если это единственный пример(вернее там много похожих инструкций, но суть одна). Зачем вы делаете вид, будто бы у вас много примеров?

    Ооох, да пожалуйста:


    __m256 _mm256_unpacklo_ps (__m256 a, __m256 b)
    
    INTERLEAVE_DWORDS(src1[127:0], src2[127:0]){
        dst[31:0] := src1[31:0] 
        dst[63:32] := src2[31:0] 
        dst[95:64] := src1[63:32] 
        dst[127:96] := src2[63:32] 
        RETURN dst[127:0]
    }   
    
    dst[127:0] := INTERLEAVE_DWORDS(a[127:0], b[127:0])
    dst[255:128] := INTERLEAVE_DWORDS(a[255:128], b[255:128])
    dst[MAX:256] := 0

    __m256i _mm256_packs_epi32 (__m256i a, __m256i b)
    
    dst[15:0] := Saturate_Int32_To_Int16 (a[31:0])
    dst[31:16] := Saturate_Int32_To_Int16 (a[63:32])
    dst[47:32] := Saturate_Int32_To_Int16 (a[95:64])
    dst[63:48] := Saturate_Int32_To_Int16 (a[127:96])
    dst[79:64] := Saturate_Int32_To_Int16 (b[31:0])
    dst[95:80] := Saturate_Int32_To_Int16 (b[63:32])
    dst[111:96] := Saturate_Int32_To_Int16 (b[95:64])
    dst[127:112] := Saturate_Int32_To_Int16 (b[127:96])
    dst[143:128] := Saturate_Int32_To_Int16 (a[159:128])
    dst[159:144] := Saturate_Int32_To_Int16 (a[191:160])
    dst[175:160] := Saturate_Int32_To_Int16 (a[223:192])
    dst[191:176] := Saturate_Int32_To_Int16 (a[255:224])
    dst[207:192] := Saturate_Int32_To_Int16 (b[159:128])
    dst[223:208] := Saturate_Int32_To_Int16 (b[191:160])
    dst[239:224] := Saturate_Int32_To_Int16 (b[223:192])
    dst[255:240] := Saturate_Int32_To_Int16 (b[255:224])
    dst[MAX:256] := 0

    __m256 _mm256_dp_ps (__m256 a, __m256 b, const int imm8)
    
    DP(a[127:0], b[127:0], imm8[7:0]) {
        FOR j := 0 to 3
            i := j*32
            IF imm8[(4+j)%8]
                temp[i+31:i] := a[i+31:i] * b[i+31:i]
            ELSE
                temp[i+31:i] := 0
            FI
        ENDFOR
    
        sum[31:0] := (temp[127:96] + temp[95:64]) + (temp[63:32] + temp[31:0])
    
        FOR j := 0 to 3
            i := j*32
            IF imm8[j%8]
                tmpdst[i+31:i] := sum[31:0]
            ELSE
                tmpdst[i+31:i] := 0
            FI
        ENDFOR
        RETURN tmpdst[127:0]
    }
    
    dst[127:0] := DP(a[127:0], b[127:0], imm8[7:0])
    dst[255:128] := DP(a[255:128], b[255:128], imm8[7:0])
    dst[MAX:256] := 0

    И в все остальные команды арифметических и логических действий соблюдают это правило: результат работы с нижними 128 битами записывается в нижние 128 битов. А теперь ваша очередь показать все остальные инструкции спокойно перекидываются битами из нижних и верхних частей? Такие команды конечно есть, но работают они со всеми 128 битами одновременно, то есть являются инструкциями копирования, а никак не SIMD-операциями.

  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    +1

    Вы вообще не поняли о чем я, видимо ни разу не использовали AVX. Я не про какие-то реализации каких-то процессоров, я про весь набор команд и их архитектуру. Посмотрите как работает например _mm256_shuffle_ps — в dst[127:0] могут попасть только биты из a[127:0] и b[127:0], но не из a[255:128] и b[255:128]. То есть нижние 128 бит работают только с нижними 128 битами, старшие со старшими — это больше похоже на два модуля SSE, чем на один модуль SSE, но в два раза больше. И это касается большинства команд. То же самое можно сказать про AVX512 — это скорее 4 модуля SSE, работающих параллельно, чем один очень длинный модуль SSE.

  • Наблюдения GRAVITY дополнительно подтвердили общую теорию относительности
    +3

    Скорее всего она движется по такой траектории уже миллиарды лет

  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0

    У вас данные выровнены по линиям кеша? 4x4x4 — это как раз одна линия. Возможно, если данные пересекают линии, результат будет отличаться.

  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0

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

  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    Код просто будет аналогичным.

    Если бы! AVX — это не в два раза больший SSE модуль, это два SSE модуля, работающих в паре. Если для сложения и умножения это ничего не меняет, то например _mm256_shuffle_ps ведёт себя совсем иначе.

  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    +3
    Разные руководства по оптимизации рекомендуют лишний раз не дёргать кэш для массовых операций сохранения.

    Это явно не ваш случай. Эти инструкции полезны, когда вам нужно обработать огромный массив данных (по крайней мере больше кеша) и вы уверены, что к нему не будет обращений до конца вашей работы. В вашем же случае вы оперируете 64 байтами, к которым с большой вероятностью в ближайшее время будет дальнейшая работа.


    По опыту использования в обработке изображений стриминг давал незначительный прирост на больших изображениях и проигрыш в несколько раз на изображениях поменьше.

  • Сколько тёмной материи проходит через ваше тело каждую секунду
    0

    Если вы имеете в виду обычную или близкую по свойствам к обычной материю в другой параллельной вселенной, то это тоже невозможно, так как ТМ не группируется под действием электромагнитных сил в комки, как это делает обычная материя, и совершенно иначе распределена в галактиках.


    Получается, что по этой теории ТМ все еще будет совершенно иных свойств, нежели привычная барионна, но только в другой вселенной. Вопрос, зачем тогда нужно это объяснение с другой вселенной, почему ТМ не может быть при всех прочих свойствах в нашей вселенной? Так-то мы можем хоть каждую частицу в отдельную вселенную засунуть и сказать, что они так же взаимодействуют сквозь вселенные, да только какой в этом смысл.

  • Сколько тёмной материи проходит через ваше тело каждую секунду
    0

    Напишите пожалуйста на support@habr.com (для верности с копией на support@habrahabr.ru), если вам не сложно.