×Закрыть

Работа с кэшем и режимами кэширования под x86 архитектурой на примере одной разработки

Меня зовут Mike Gorchak, я работаю «обычным сеньором» в QNX Software Systems / BlackBerry в отделе engineering services, graphics team. Engineering services — это как аутсорс, только все разработки так или иначе свяазаны с нашей операционной системой QNX, плюс специализация на кастомных решениях для заказчиков и их оптимизация. Основными моими заказчиками являются Tier 1 из мира automotive.

Одной из основных моих специализаций последние 11 лет является x86 платформа, на базе решений от Intel (чипсеты, процессоры, GPU). 5 лет назад Intel зашла на рынок automotive со своей A-серией процессоров Intel Atom, архитектура ApolloLake со встроенной GPU 9-го поколения. Ближайший аналог десктоп архитектуры — это Skylake. С тех пор многие Tier 1 поставщики захотели поставлять автомобильную электронику на базе А-серий Intel Atom процессоров, с тех же самых пор заказчикам нужна постоянная кастомизация существующих решений, чтобы выжать из платформы всё до последней капли.

Одной из частей GPU на интелловской автомобильной платформе является медиа-процессор, который может сжимать и расжимать видеоряд используя многие современные кодеки с довольно приличной скоростью, как для такого embedded устройства. Драйвера были написаны, часть портирована как VA API драйвер Intel под Linux. Основной заказчик этого драйвера — внутренний, другая команда, которая занимается разработкой а-ля чёрного ящика для автомобилей, вся информация с экранов, камер, датчиков, сжимается и сохраняется. И если камера выдаёт 60 FPS, то и сжимать нужно со скоростью 60 FPS, чтобы не пропустить ни одного фрейма. Разработчики другой команды во время того как писались BSP и прочие драйвера для новой платформы использовали desktop аналог для разработки. Они говорят, мы всё протестировали и больше 40 FPS никак выдать не можем, а тестируем на десктопном аналоге — получается минимум 120 FPS, а автомобильный не должен от него отставать сильно.

Начинаем разбираться. В чём отличие десктопного варианта и автомобильного? У десктопного варианта есть LLC (Last Level Cache) кэш. Кэш называют LLC, когда он последний, например, для процессора он будет L3, а для GPU он будет L4. И он объединяет между собой не только процессор, но и другие устройства. Другие устройства постоянно занимаются процессом называемым Cache Snooping — они отслеживают записи и чтения в регионах памяти, в которых идёт обмен с устройствами и кладут данные в LLC кэш, т.к. могут его использовать вместе с процессором.

Подробнее про LLC: en.wikichip.org/...​fers,cores, IGP, and DSP
Подробне про Bus (Cache) Snooping: en.wikipedia.org/wiki/Bus_snooping

Используя LLC кэш процессор позволяет буферам с данными, которыми обменивается медиа-процессор в GPU и СPU быть кэшируемыми с точки зрения центрального процессора, что несомненно сказывается на быстродействии самым положительным образом. А вот автомобильная платформа LLC кэша не имеет, cache snooping протокол не работает, поэтому все буфера обмена должны быть uncacheable (некэшируемые) с точки зрения процессора, чтобы любые изменения делаемые GPU и CPU были мгновенно видны друг-другу. Ок, запускаем тест на измерение memory bandwidth (UC — uncacheable, WB — write-back — самый обыкновенный режим кэширования региона памяти используемый на x86 по умолчанию):

size      UC->WB, WB->UC
            memcpy
 ------ -------------
    256    41.44 Mb/s
    512    41.46 Mb/s
   1024    41.49 Mb/s
   2048    41.46 Mb/s
   4096    41.44 Mb/s
   8192    37.31 Mb/s
  16384    37.31 Mb/s

Приехали. Пропускная способность некэшируемой памяти на этой платформе около 110x раз медленее кэшируемой. Простые расчёты показывают, что если мы будем копировать Full HD видео фрейм, который занимает 1920*1080*1.5 (NV12) = 3,110,400 байт, то в секунду мы можем залить для GPU или забрать назад только 13 фреймов.

Немного полезной теории: Intel® 64 and IA-32 Architectures Software Developer Manuals: software.intel.com/...​p/articles/intel-sdm.html

Раздел 11.3 METHODS OF CACHING AVAILABLE описывает режимы кэширования регионов памяти, нас интересуют только три из них:

Strong Uncacheable (UC) or Uncacheable (UC-) — Регионы в системной памяти, имеющие этот аттрибут являются некэшируемыми. Все чтения и записи сразу появляются на системной шине и выполняются в порядке очереди заданной кодом при обращении. Этот режим кэширования подходит для доступа к memory mapped I/O при работе с устройствами. Когда используется для обычной системной памяти, он значительно замедляет работу процессора, т.к. он ожидает чтения и записи в память каждого обращения.

Write Combining (WC) — Тоже самое, что и Uncacheable (UC-). Но все записи осуществляются через Write Buffer внутри процессора, обычно это от одного до нескольких десятков cachelines. Реализация отличается от процессора к процессору, но общий подход следующий — все последовательные записи или записи не выходящие за пределы размера буфера, попадают в этот самый write buffer, если происходит выход за границы write buffer или он переполнен, то write buffer или его фрагмент сохраняется в памяти. Любое чтение из WC региона памяти также осуществляет сброс буфера в память, работая как posting read механизм. Также ряд процессорных команд делают тоже самое, например MFENCE, но быстрее, т.к. не нужно фиктивное чтение из некэшируемой памяти. Чтение такое же медленное, как и в случае с Uncacheable (UC-) памятью, но ряд процессорных команд могут использовать Write Buffer временно как Read Buffer, т.к. при чтении он полностью сброшен и доступен для временных операций. Это операция называется speculative reads.

Write-back (WB) — Чтение и запись проходят через кэши всех уровней по усмотрению процессора. Самый быстрый доступ к памяти, он же является доступом по умолчанию.

Так как мы используем QNX, который предоставляет очень удобные механизмы тонкого тюнинга и контроля маппинга памяти с разными режимами кэширования, мы решаем уйти от UC (uncacheable) и использовать WC (write-combining режим записи для некэшируемой памяти).

Например, выделение памяти с режимом кэширования Write-back (WB):

mmap(NULL, pix_buffer_mem_size, PROT_READ | PROT_WRITE, MAP_ANON | MAP_SHARED, NOFD, 0);

Выделение памяти с режимом кэширования Uncacheable (UC-):

mmap(NULL, pix_buffer_mem_size, PROT_READ | PROT_WRITE | PROT_NOCACHE, MAP_ANON | MAP_SHARED, NOFD, 0);

Выделение памяти с режимом кэширования Write-Combining (WC):

shm_fd = shm_open(SHM_ANON, O_RDWR | O_CREAT, 0);
shm_ctl(shm_fd, SHMCTL_ANON | SHMCTL_LAZYWRITE, 0, pix_buffer_mem_size);
mmap64(NULL, pix_buffer_mem_size, PROT_READ | PROT_WRITE, MAP_SHARED, shm_fd, 0);
close(shm_fd);

В Linux всё гораздо сложнее — для получения WC или UC памяти нужно писать свой драйвер для выделения такой памяти и задания нужны PAT аттрибутов. Можно взять за базу этот проект: github.com/...​nsqueeze/uncached-ram-lkm

Тестируем скорость доступа к Write-Combining (WC) памяти:

size        WC->WB       WB->WC
            memcpy       memcpy 
 ------ ------------- -------------
    256    41.44 Mb/s  2441.41 Mb/s
    512    41.46 Mb/s  3814.70 Mb/s
   1024    41.49 Mb/s  4069.01 Mb/s
   2048    41.46 Mb/s  4359.65 Mb/s
   4096    41.44 Mb/s  4695.01 Mb/s
   8192    37.31 Mb/s  4694.71 Mb/s
  16384    37.31 Mb/s  4694.71 Mb/s

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

Попробуем использовать SSE команды, которые поддерживают speculative reads из WC регионов памяти, например MOVNTDQA, в конце статьи я объясню почему именно эта команда с суффиксом NT в мнемонике.

Хороший образец кода для Streaming Load (Speculative Reads) можно посмотреть в исходниках Mesa3D. Код написан Intel и имеет BSD-подобную лицензию, за что им спасибо: gitlab.freedesktop.org/...​n/streaming-load-memcpy.c

size      WC->WB        WB->WC        WC->WB        WB->WC
            memcpy        memcpy       movntdqa      movntdqa
 ------ ------------- ------------- ------------- -------------
    256    41.44 Mb/s  2441.41 Mb/s   592.57 Mb/s  1695.42 Mb/s
    512    41.46 Mb/s  3814.70 Mb/s   610.35 Mb/s  2774.33 Mb/s
   1024    41.49 Mb/s  4069.01 Mb/s   629.23 Mb/s  3590.30 Mb/s
   2048    41.46 Mb/s  4359.65 Mb/s   629.23 Mb/s  4069.01 Mb/s
   4096    41.44 Mb/s  4695.01 Mb/s   629.23 Mb/s  4359.65 Mb/s
   8192    37.31 Mb/s  4694.71 Mb/s   333.50 Mb/s  5085.94 Mb/s
  16384    37.31 Mb/s  4694.71 Mb/s   333.50 Mb/s  5085.94 Mb/s

При доступе размером в одну страницу памяти — 4096 байт, получаем максимальный выигрышь на этой платформе, на других платформах скорости и гранулярность доступа могут отличаться, но одна страница выглядит логично и универсально также и для других архитектур интелловских процессоров. Итого 629 / 3 ~ 200 фреймов в секунду. Мы уложились. Всё работает. Но есть один ньюанс, загрузка ядра процессора, которое занимается копированием из Write-Combining (WC) региона памяти составляет около 30%, что довольно таки много, делая embedded процессор слегка тёплым, в районе 45-50 градусов Цельсия. Память тоже стала больше греться. Да и разработчики других подсистем не обрадуются тому, что мы забрали 30% одного из четырёх ядер просто так.

Так как современные автомобили имеют системы engine start/stop и выключают двигатель во время остановки, то всё питание всех систем идёт с аккумулятора, а не с генератора. То повышенное потребление нужно всё равно решать, рано или поздно. Пока тема горячая, нужно продолжать исследования дальше.

Вариантов по сути больше нет, только использовать кэшируемую память. Но проблема в том, что данные в памяти не когерентны с данными в кэше. И GPU об этом ничего не знает. Помните как в школе нас учили, что делить на ноль нельзя? И только повзрослев мы получили индульгенцию деления на ноль без последствий в виде CPU exceptions и прочих радостей. Используя FPU мы можем наслаждаться бесконечностью (infinity) в качестве результата. Все учебники и мануалы говорят, что использовать для устройств кэшируемую память нельзя, но если очень надо, то можно! А нам надо.

Вариант действий номер 1. Мы кладём и ложим данные для обработки медиа-процессором в кэшируемую память. Но надо позаботиться о том, чтобы данные из кэша записались в память. Как? Использовать старую добрую команду процессора WBINVD: www.felixcloutier.com/x86/wbinvd — Write back and flush Internal caches; initiate writing-back and flushing of external caches. Но у этой команды есть большие недостатки — она требует исполнения на уровне Ring 0 процессора — требует самый высокопривелигированный уровень из доступных для обычных приложения и ядер. Механизмы выполнить её в QNX существуют, но появляется вторая проблема, использование этой команды сродни разбиванию яиц кувалдой для омлета, мы будем 60 раз в секунду полностью уничтожать весь кэш процессора, причём всех четырёх ядер, т.к. они поддерживают когерентность кэша между собой. А вот за это нас точно по голове не погладят.

Вариант действий номер 2. Мы кладём и ложим данные для обработки медиа-процессором в кэшируемую память. Но надо позаботиться о том, чтобы данные из кэша записались в память. Как? Использовать «новые» команды процессора CLFLUSH и CLFLUSHOPT:
www.felixcloutier.com/x86/clflush
www.felixcloutier.com/x86/clflushopt

Данные команды работают на уровне cache line, поэтому нужно либо хардкодить размер кэшлайна 64 байта или спрашивать у CPUID инструкции. Второе предпочтительнее, если мы хотим использовать код не только на этой платформе. На помощь в реализации и имплементации workarounds для Intel Atom процессоров (а у нас именно он) приходит кладезь полезного кода — Mesa3D: gitlab.freedesktop.org/...​ntel/common/gen_clflush.h . Код написан Intel и опять под BSD-like лицензией, что очень удобно, к тому же код не завязан на внутренности Mesa3D. Сама Intel захардкодила размер кэшлайна равным 64 байтам, наверное они что-то знают :) Либо скоро будут переписывать этот код. Но сегодня для наших нужд с использованием CPUID инструкции пока всё хорошо.

Необходимо осуществлять следующие правила — пишем данные в буфер для отправки, сбрасываем (flush) все кэши в память, берём буфер для приёма и сбрасываем все кэши там тоже и инвалидируем весь кэш для этого региона памяти. Т.к. мы хотим читать актуальные данные, что сохранил GPU, а не то, что в кэше. Эти буфера никто не имеет права трогать кроме нашего приложения, чтобы никакие данные не проскользнули в кэш. Вроде все условия соблюдены.

Тестируем. Процессор холодный и скоро замёрзнет, всё работает у нас быстро. Но через неделю приходит другая команда и говорят, что когда работает наш код, то их код, который тоже супер-оптимизированный работает не очень быстро. Ищем подводные камни: en.wikipedia.org/wiki/Goldmont — Automotive processors (Apollo Lake)

Размер кэша второго уровня всего 2Mb. Копируя буфера по 3Mb с частотой 60 раз в секунду мы просто уничтожаем весь кэш процессора, он замещается данными из нашего буфера, оставляя другие ядра с бесполезным содержимым кэша на борту, т.к. они никогда не будут к этой памяти обращаться. Вот и негативная сторона когерентности кэша, с Write-Combining (WC) такой проблемы бы не имели, зато грелся процессор. Открываем библию Intel® 64 and IA-32 Architectures Software Developer Manuals (ссылка была дана вверху) и читаем главу 10.4.6.2 Caching of Temporal vs. Non-Temporal Data. Не мы первые и не мы последние столкнулись с этой негативной стороной кэширования в многоядерных и многопроцессорных системах. Некоторые команды процессора имеют Non-Temporal свойство по отношению к кэшу, они имеют суффикс NT в имени своей мнемоники, в середине статьи упоминалась команда MOVNTDQA с обещанием объяснить её смысл в конце статьи. При работе этих команд процессор выделает минимальный временный кэш только для ускорения работы этих команд при копировании, но не загрязняет остальной кэш ненужными данными. Заменяем нашу оптимизированную memcpy() функцию опять на функцию, любезно предоставленную Mesa3D с использованием MOVNTDQA (ссылка в середине статьи) и вуаля. Кэш практически не тронут, другие ядра, которые обслуживают распознование и прочие подсистемы ADAS больше не тормозят и работают на пределе выжимая последную каплю производительности из кремния.

Это не единственная проблема, которую приходилось решать, связанную с кэшированием, но наиболее яркая и простая для понимания.


Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Уважаемый автор,
Хочу себе купить на повседнев ноутбук на: Intel Atom x5-Z8550
(Очень мобильный)
Суть вопроса: Подскажите, пожайлуста с точки зрения архитектуры, насколько все плохо в плане производительности приложений Windows, например браузера Chrome по сравнению к примеру с 2х ядерным, 4х поточным I3.
Большое спасибо за ваше мнение.

Это Cherry Trai платформа, её основное предназначение быть запиханной в планшет или телефон и работать как можно дольше от батареи. Очень мобильный нотбук тоже вполне её ниша, изначально она предназначалась для Microsoft Surface планшетов/ноутов. Производительность по остаточному принципу.

Почитал статью.
Чувствую себя обезьяной из сюжета «Космической Одиссеи 2001».
www.youtube.com/watch?v=zmX7K8noikE

У меня смешанные чувства.

В целом ничего нового, и тут бац! Оказыватся, что SIMD работает на другой частоте! И никто этому не удивляется, т.к. все знали об этом!

Страшно подумать, но ведь я даже grep-ал ассемблерный выхлоп от gcc и радовался если видел там xmm, ymm или аж zmm!

Сейчас сижу у убеждаю сам себя, что всё- равно у SIMD больше приемуществ чем недостатков и его нужно использовать.

что всё- равно у SIMD больше приемуществ чем недостатков и его нужно использовать

Да.
Но нужно с ним быть аккуратным. Там тоже не всё просто. Процу пофиг на частоту, если не перегревается, а SIMD, особенно AVX2 и выше греют его конкретно.
Но лично я стараюсь работу с SIMD отдать интеловским либам типа MKL, IPP и подобным.

В ARM NEON ніби такої фігні з частотами нема

С точки зрения логики процессор не будет принудительно выполнять SIMD инструкции на пониженной частоте, но они его греют очень сильно и логично, что он будет сбрасывать частоты для всего или для конкретных модулей я не знаю.
Но с другой стороны, как я понял Майка ниже многие интеловские сразу исполняют SIMD на пониженной частоте, чтобы кристалл не потрескался от перегрева.
Поэтому с Неоном всё тоже самое будет. А учитывая, что он обычно на мобильниках всяких и встроеной фигне, то и акк он выжрет очень быстро.

В нас працює на максимальній частоті. Особливо не грілося, на наших частотах і розмірах кадрів. Між кадрами достатньо часу на охолодження.

На ARM цього не помічав. Може тому, що обробка зображення займає найбільше часу.

Большинство армов не умеют сбрасывать частоты при повышенной нагрузке, это прерогатива SoC, что в принципе логично, т.к. там целый огород на одном кристалле. Что касается neon инструкций — оно частоты не сбрасывает, но потребление увеличивает знатно. Если интел рекоммендует разбавлять SIMD инструкции обычными, то в ARM наоборот, neon ядро будет активно ещё какое-то время после начальной активации и неиспользования. Потребление некоторых SoC при активизации neon увеличивалось в 2 раза, поэтому тут правильная тактика — быстро посчитал — поспал. Энергоэффективность от 1.5 до 2.5 раз при кратковременном использовании neon по сравнению с обычным CPU. У интела для AVX-512 до 8 раз. Поэтому даже при сбрасывании частот всё равно выгодно использовать AVX-512. Другое дело — AVX-512 в OpenSSL на серверах — это использование 24/7 — тут уже хз как считать, особенно при влиянии на другие ядра.

у меня тоже смешанные чувства от подобного комментария, потому что это не SIMD работает на другой частоте, а вполне конкретные наборы SIMD-инструкций у вполне конкретного и единственного вендора

Работа с кэшем....

Каждый раз читаю название темы и каждый раз думаю «О, опять тема про деньги»

Хорошая статья, вспомнил времена, когда игрался с qnx 4 версий и ее фотоном, вещь крайне стабильная и неубиваемая) У интела большая проблема, что они тащат за собой весь ворох легаси инструкций, и режимов, накопившихся с времен 80286. Уже даже софт никто не компилит с поддержкой старых цпу, т.к. они вымерли вместе с софтом

1)
З мережею в QNX6 (QNet) було не все не так гладко.

Може вже все виправили, але були в нас цікаві історії...

Тому зараз — тільки UDP :)

2)
В режимі x86_64 викинули багато старих інструкцій, які погано лягають на мікрокод.

В режимі x86_64 викинули багато старих інструкцій, які погано лягають на мікрокод.

Та де ж викинули? Маячня на зразок RCL, RCR, або весь FPU з його стеком — все в повний зріст, а викинули тільки якісь DAA які не мали таких проблем.

Ну в этом виновата AMD, это ж они реализовали первыми x86_64, у Intel как раз был проект после Итаниума сделать несовместимую с x86_32 ISA, раз происходит переход на новую архитектуру и так, но пришлось тащить уже новую мёртвую лошадь благодаря AMD.

AMD64 как раз оказалась живой лошадью, в отличие от титаника.

Ну а что они мало поменяли — так скорее всего по бедности. Ну да, трёхногая и хромая ;(

AMD64 как раз оказалась живой лошадью, в отличие от титаника.

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

Где про это можно почитать?

Я пытался найти, но не смог. У интела слишком большое кладбище проектов, таких как Larrabee, например. По таймлайну я помню, что они долго собирались выпускать Itanium 2 и сказали, что будет десктопная линейка на базе Intel Deerfield, но то, что вышло был обычный Itanium 2, только сильно порезанный, буквально сразу после этого был удар AMD с AMD64 и они всё свернули. Буквально в это же время Intel занимался модификациями модулярных ARC процессоров, но они ушли в чипсеты и GPU и работают там только на подспорье и сейчас.

«Удар AMD» проектировался несколько лет до того (в 99-м году проект был уже вполне публичным, AFAIR). Так что Intel просто пытался до последнего тянуть Itanium на маркетинге (затыкая 32-битность четвертопнём) и, вероятно, надеясь, что RDRAM таки выстрелит. И тогда, да, даже с их ресурсами оставалось только перелицевать AMD64.
Вот интересно бы послушать, что таки сдохло и в каком лесу, что у них кто-то смог наконец честно признаться в провале.
Но, видимо, узнаем лет через 20.

Прям секрет Полишинеля! В одном из интервью в начале 2000-х Борис Арташесович четко указывал на проблемы при массовом внедрении VLIW: слишком много нужно вложить в переработку софта и средства разработки. В те времена на Intel в Омске работал RnD центр: писали оптимизирующий компилятор для Itanium. Но не смогли, вернее что смогли — вошло в Intel C++.

Да дело не в том, что кому-то надо софт переработать — с этим давно справились. Проблема в том, что это в принципе не поможет, когда оптимальный порядок выполнения команд зависит от таких непредсказуемых свойств, как нахождение данных в L1 (2 такта, грубо говоря) или RAM (200 тактов). Его нельзя в таких непредсказуемых условиях рассчитать заранее, нет, никак. Можно получить только потери в разы и десятки раз на неудачном предсказании, это и происходит.

На DDR4 лучшее на сейчас время на смену активной строки это 37.5 нс. Это адски много. DDR5 это, по отзывам, не улучшил (ждём подробностей), а вообще это время уменьшилось всего лишь в ~2 раза за 20 лет. Это страшный залёт всей индустрии, и никакой закон Мура тут не спасает.

EPIC хорошо работает только при предсказуемом доступе к памяти — а это значит или SRAM, или тактовые в десятки мегагерц. Вот в DSP его используют, без проблем. А в мейнстримных процессорах — никаких надежд, и на что Intel надеялся — я не знаю.

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

>

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

Практика оптимизаций первой половины 2000-х показала, что если правильно подготавливать данные и тратить много человекоресурсов на оптимизацию, то prefetch, параллельный доступ к разным банкам, выравнивание и прочие ухищрения могут дать существенный буст производительности.

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

Только на тех задачах, которые укладываются в рамки предсказуемого доступа к памяти. Да, таких много — грубо говоря, почти вся мультимедия, HPC. Но это ой далеко не всё, и обычный OoO исполняет их не хуже. А сейчас ещё и GPU подтянулось и перекрыло все ниши, и нафига тот EPIC?

Itanium позиционировался для HPC. В 1999 никто не мог предположить, что наследник GeForce256 уложит на обе лопатки Merced, самым распространенным CPU станет ARM, а архитектуры SPARC и Power уйдут.

Itanium позиционировался для HPC.

С чего вы это взяли?
Itanium позиционировался как будущий 64-битный универсальный заменитель x86, при этом уже зная, что граница, за которой 64-битность становится полезной (а это около 1.5GB RAM), ой не за горами, и надо шевелиться.

Но по рекламе того времени и по Pentium 4 видно, что заметная часть надежд была на то, что комп 99% времени будет исполнять действия, которые укладываются в понятие мультимедии (и соответственно легко предсказываются), и поэтому тормоза остальных блоков никого не будут волновать. Вот эти надежды тоже, мягко говоря, удивляют — как могли специалисты понять, что этого не будет.

Я ещё хорошо помню эти подвижки — я как раз выходил тогда в «первую профессиональную зрелость». И то, как начиная где-то с 2002 приходилось переходить на AMD, потому что все вокруг уже благим матом орали «что ты делаешь, Intel, остановись», а те продолжали клепать пару P4+Itanium.

В 1999 никто не мог предположить

Что именно GPU выскочит вперёд — да, мало кто мог предположить. А вот что EPIC заведомо провален, потому что нет в природе столько мультимедии — было очевидно. Intelʼу было достаточно посмотреть на опыт тех архитектур, где уже отработали векторные наборы команд — хотя бы VAX.

а архитектуры SPARC и Power уйдут.

У вас какие-то очень кривые представления. Power не ушёл, он продолжает развиваться и чётко держит свою нишу. Это остальной рынок расширился.

Itanium позиционировался как будущий 64-битный универсальный заменитель x86

Можно ссылку на такое позиционирование от Intel?

И то, как начиная где-то с 2002 приходилось переходить на AMD

Архитектурно Athlon 4 (в 2001-2002 у каждого второго были K7 в различных вариациях) продолжал верный путь K6 и PIII в развитии за счет тактовой частоты. Уже тогда тогда Крис Касперски выпустил свою книгу по оптимизациям и указывал, что виток истории повторяется: частоты процессоров опять стали значительно выше частоты памяти и опять память стала узким горлышком. Уже тогда выходили кучи документов от Intel и AMD относительно практик оптимизаций управления памятью. И только когда стало понятно, что ядро Tejas с 5ГГц и гигантским конвейером — это явный перебор, то стали смотреть в сторону AMD (как раз подоспело удачное ядро Newcastle). А массовый переход в серверном сегменте на Operton начался, наверно, после того как Blizzard стала использовать AMD в своих серверах для WoW.

У вас какие-то очень кривые представления. Power не ушёл, он продолжает развиваться и чётко держит свою нишу.

Это же круто быть в каждом Маке, пролезть в консоли и до сих пор «чётко держать свою нишу». Ну тогда можно сказать, что и EPIC (серия процессоров Эльбрус), и SPARC (серия МЦСТ R1000-2000) «продолжает развиваться и чётко держит свою нишу».

Можно ссылку на такое позиционирование от Intel?

Да пожалуйста. Вот даже с вики, если вам тяжело:

> targeted at high-end enterprise class servers and high performance computing (HPC)

Уже не только HPC; «enterprise class servers» это что угодно, но не HPC, и почти всегда это перемалывание _разнородных_ и разбросанных по памяти данных, где кэш — чуть ли не самая важная характеристика процессора.

> industry analysts predicted that IA-64 would dominate in servers, workstations, and high-end desktops, and eventually supplant RISC and complex instruction set computing (CISC) architectures for all general-purpose applications.

Тут можно сказать, конечно, что «industry analysts» это не сам Intel, но вряд ли это будет серьёзным возражением.

> As part of Intel’s definition and marketing process they engaged a wide variety of enterprise OEM’s, software, and OS vendors, as well as end customers in order to understand their requirements and ensure they were reflected in the product family so as to meet the needs of a broad range of customers and end-users.

Enterprise OEMs — см. выше. Broad range of end-users. Или в вашей вселенной так говорят про HPC?

Архитектурно Athlon 4 (в 2001-2002 у каждого второго были K7 в различных вариациях) продолжал верный путь K6 и PIII в развитии за счет тактовой частоты.

Абсолютно верно! Продолжался путь K6 и PIII, а не P4 или IA64. За счёт этого они и выехали аж до момента появления Intel Core.

Это же круто быть в каждом Маке, пролезть в консоли и до сих пор «чётко держать свою нишу».

Тут согласен, на маке они подсократились заметно. Я думал про pSeries (наследники RS6000) и iSeries (наследники AS/400). Оттуда их никто не погонит ещё долго, потому что влезть в такую нишу нереально — и это то место, где их архитектурные преимущества вылазят больше всего — в отличие от мака и консолей, где это было временно. Потому и не считаю существенным случаем.

(С Cellʼами HPC формата я даже чуть работал. Для них вообще конкретная разновидность ЦП была пофиг.)

И только когда стало понятно, что ядро Tejas с 5ГГц и гигантским конвейером — это явный перебор

Кому «стало понятно»? Уточняйте. Боюсь, кому-то в Intel и сейчас непонятно :)

Что P4 тупо не оправдывает своих денег даже в однотреде, больше половины моих знакомых (вот тут я явно уточняю: все слои — от домашних хакеров до суровых энтерпрайзников) поняли начиная с 2001 — местами, массово — с 2002. Вот переходить было местами сложно по куче причин начиная с административных, да — ну и плюс маркетинг. Но уже с 2003 я не слышал про P4 ничего, кроме плохих слов.
А зачем после этого было тянуть ещё три года до появления Core — вот это и было бы узнать интересно для ретроспективы — кто это такой безумный в руководстве Intel.

Да, кое-кто из знакомых ещё долго тосковал по высокоуровневым фишкам Itanium — но и то не по системе команд, а, например, по развитой инфраструктуре MCE (перетечка которой в x86 завершилась где-то на Nehalem).

А массовый переход в серверном сегменте на Operton начался, наверно, после того как Blizzard стала использовать AMD в своих серверах для WoW.

Вот на это у меня статистики нет (но и у вас, наверно, тоже). Но вообще 64-битку мы применяли с 1999 (правда, на Alpha), и когда возникла идея поставить веб-хостинг на 64-битной системе на Opteron в 2002 — оно уже просто заработало (чему я очень удивлялся — в 99-м mysql и postgres даже не скомпилировались).

Да пожалуйста. Вот даже с вики, если вам тяжело:

Я же просил ссылку на позиционирование от Intel. И да: графические станции, для которых специально сделали WinXP под Itanium — это тоже HPC (ray tracing). Но я все еще нигде не увидел, что

Itanium позиционировался как будущий 64-битный универсальный заменитель x86

Приведите ссылку от Intel.

Кому «стало понятно»? Уточняйте. Боюсь, кому-то в Intel и сейчас непонятно :)

Видимо тем руководителям Intel, которые и отменили выпуск Tejas, не?

Что P4 тупо не оправдывает своих денег даже в однотреде, больше половины моих знакомых (вот тут я явно уточняю: все слои — от домашних хакеров до суровых энтерпрайзников) поняли начиная с 2001 — местами, массово — с 2002.

Можно с этого момента подробнее? P4 в эти годы был одноядерным и только одноядерным, HT — это костыль. На что переходить? На Athlon 4? Они горели как свечки и скалывались. Хорошо работали только с int операциями, а любой fp — и приехали. AthlonXP? Да, увеличили кэш, но проблемы те же, кроме сколов: это стало делать труднее. На Athlon MP? так он появился только в 2002, его неохотно завозили в Украину и то, что заезжало стоило будь здоров! Сам в конце 2002 оптимизировал под него софт. На Power4? В specint он рвал P4, а в реальном софте отставания были иногда в разы!
А вот плохие слова полетели только с Prescott и уж точно ничего хорошего не говорили про Pentium D. Но это уже 2004-2005, когда уже был Athlon64 и Opteron с 2003 и был выбор.

Приведите ссылку от Intel.

www.pcworld.com/...​pcs-hits-end-of-line.html

Intel on Thursday started shipping its latest Itanium 9700 chip, code-named Kittson, in volume. It’s the last of the Itanium chips, which first appeared in early 2001.

Beyond Kittson, there will be no more chips coming from the Itanium family, an Intel spokesman said in an email. That ends a tumultuous, 16-year journey for Itanium, which Intel once envisioned as a replacement for x86 chips in 64-bit PCs and servers.

Это мнение Agam Shah. Если мне нужно было мнение о Power от IBM — его можно было бы представить: он там хотя бы 3 мес. работал, а в Intel он никогда не работал и не может озвучивать позиционирование продукта от этой компании.
В официальных пресс релизах от Intel я нигде не видел

Itanium позиционировался как будущий 64-битный универсальный заменитель x86
В официальных пресс релизах от Intel я нигде не видел

А с чего ты взял, что такое публикуют в пресс релизах? В пресс-релизах публикуют свершившиеся события. В то время было полно этой информации, включая ту, что я выше упоминал с Intel Deerfield — его пытались всунуть в десктопы, но потом оставили ему нишу low-end серверов и включились в гонку с EMT64

Точно так же ты не увидишь линии: Larrabee -> Xeon Phi -> Intel Xe. А также уши Xeon Phi во всех интеловских GPU. Но она очевидна всем кто работал со всем этим.

На всякий случай: позиционирование продукта — это элемент маркетинга и к инженерии если и имеет отношение, то отдаленное. Если продукт вышел (Itanium в отличие от Larrabee и Хeon Phi — реальный продукт, а не прототип или проект), то в маркетинговых материалах и действиях должен быть обозначен рынок: Itanium выпускался только в серверных решениях и high-end рабочих станциях (визуализация, CAD).

Intel Deerfield — его пытались всунуть в десктопы

С оптовой ценой 1200$ в 2003? А материнка сколько стоила? Десктоп!? Так и запишем десктопы в 2003 продавались от 7000$. Очереди выстраивались за неделю до презентации. Люди жили в палатках и ждали.

Itanium в отличие от Larrabee и Хeon Phi — реальный продукт

Xeon Phi более чем реальный продукт. И AVX расширения, которые тут пугают всех пришли как раз от туда, где они были обкатаны в в доль и поперёк. Но из-за разницы x86 архитектур в Xeon Phi и Xeon Skylake в последнем она стала колом. Потому что в Xeon Phi x86 используется для сетапа работы AVX команд, а в Xeon Skylake наоборот, AVX — это расширение, а не база процессора.

С оптовой ценой 1200$ в 2003? А материнка сколько стоила? Десктоп!? Так и запишем десктопы в 2003 продавались от 7000$. Очереди выстраивались за неделю до презентации. Люди жили в палатках и ждали.

ты оперируешь свершимся фактом, что он так и не стал десктоп процессором и приводишь цены серверного сегмента. Вопрос цены решается тем же маркетингом элементарно. Во многих Xeon нет ничего такого, чего нет в high end десктопных процессорах, но цена последних существенно ниже.

Xeon Phi более чем реальный продукт.

Блин, я как-то потерял его из виду из-за затяжного старта. Думал все.

Вопрос цены решается тем же маркетингом элементарно.

В 2003 на старте продаж ядра Deerfield компанией Intel была установлена оптовая цена от 1000 шт. в $1200. Это и правда свершившийся факт, и это нереальная цена на старте продаж для desktop даже сейчас, даже без учета разницы в покупательской способности доллара. А спустя несколько месяцев — в 2004 году — уже были в продаже Opteron с ценой от $200+ и легендарный Athon64 3000+ по цене $250. Ау! какой Itanium в десктопе???? На десктопе сливки не соберешь!

Я уже не знаю на каком языке объяснить. То, что мы видим сейчас как факт — это cancellation Deerfield как десктоп платформы. Если бы этого не случилось — цена была бы другая.

Если бы у бабушки был бы член... На момент выхода цена не была в допустимых рамках для десктопа. Причем такая цена для младшей модели была точно такой же и для Merced. Т.е. с 2001 и до самого последнего 9700 никто в Intel не снижал цену! Ни на одном из официальных пресс релизов Intel не было (по крайне мере я таких не видел, но если кто-то видел — представьте) такого позиционирования. Тогда откуда вы это

Itanium позиционировался как будущий 64-битный универсальный заменитель x86

взяли? Что является источником для вас???

взяли? Что является источником для вас???

Инсайд.

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

Инсайд в маркетинговом отделе Intel?

В R&D и с теми, кто предоставляет инженерные сэмплы.

Да и как проверить этого «инсайда»

А что это поменяет сейчас конкретно для тебя?

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

Бывает и так. Иногда рассказываешь Интелу их же новости о которых они не в курсе. Для такого размера компании и по-проектной сегрегации отделов — это нормально.

В R&D и с теми, кто предоставляет инженерные сэмплы.

В общем информация на уровне подруги брата соседа тети. В таких случая обычно указывают «по моим источникам», а не как некий всем известный факт.

Да, пожалуйста. Мир от этого не поменяется.

Приведу твои же слова

Давай не будем приводить то что мерещится или кажется за истину. Если нет информации из официальных источников, то и .

такого позиционирования нет и никогда не было.

Ну если быть технически корректным, то это я привёл твои слова в другом виде :)

Значит ты с этим мнением согласен — иначе не использовал бы его. Тогда зачем весь этот флейм о позиционировании и «идеологических соответствиях» разных архитектур? Зачем плодить мифы?

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

Нет, я не согласен,

«Ты либо крестик сними либо трусы надень».

потому что у меня больше информации для оперирования

"Больше" подразумевает сравнение. Вопрос: больше, чем у разработчиков архитектур или больше, чем у маркетингового отдела Intel?

Xeon Phi вже мертвий. І був мертвонародженим.

Досі пам’ятаю, як він гудів на всю кімнату.

Подивилися ми на нього, і повернулися до старої доброї Nvidia. Під яку код написаний в 2010 працює в 2020. На відміну від.

(І цей досвід не вберіг мене від того, щоб втратити десь пів року на такий же ж мертвонароджений Intel Joule в зовсім іншому проекті. Симпатично залізяка виглядала. Тільки не працювала).

Xeon Phi вже мертвий. І був мертвонародженим.

Как самостоятельній процессор — да, но всё что было внутри ушло в современные GPU от Intel и в x86 процессоры (AVX).

в отличие от мака и консолей, где это было временно. Потому и не считаю существенным случаем.

Тем не менее Itanium никогда не был в компьютерах обычных пользователей, а Power3 и Power4 — были. И вылетели. В консолях Cell был и вылетел ибо это была головная боль для всех: разработчиков аппаратуры (вспоминаем красный глаз смерти Xbox360 и вой первых версий PS3), разработчиков игр и издателей (нет простых портов между консолями, каждый раз нужно заново оптимизировать). Недавно в Sony признались, что PS3 чуть не угробила все игровое направление. По этому Power из консолей вылетел и все перекрестились.

Люблю IBM Cell.

Коли IBM його вбила, ми терміново переводили обчислення на CUDA. Так і отримали великого замовника.

С точностью до наоборот: Itanium — это VLIW, а не RISC.

тогда уж наверное EPIC, хотя согласен что эпик идет от истоков влива.

С точностью наоборот что? Я говорил про другую архитектуру, с которой они хотели зайти на 64 битные десктопы.

Каким образом можно набить шишки на VLIW и выпустить удачный RISC? ARM потребовалось 17 лет работы от ARM1 до более или менее удачной ARM11.

Каким образом можно набить шишки на VLIW и выпустить удачный RISC?

Потому что нужно понимать, что IA-64 с одним слотом для выполнениея — это RISC. Неожиданно, да. Intel даже в итаниумах варьировала размерами слотов. Но проблема была в том, что производительности это давало 0 без перекомпиляции. С двумя слотами для исполнения оно мало бы чем отличалось от современных x86 в функциональности паралеллизации комманд, только логика была бы не в процессоре, а в компиляторе. Да даже сейчас компиляторы для x86 группируют комманды по использованию функциональных блоков в декодере для увеличения параллелизации.

Потому что нужно понимать, что IA-64 с одним слотом для выполнениея — это RISC.

А поле шаблона каким образом на RISC натягивается?

С двумя слотами для исполнения оно мало бы чем отличалось от современных x86 в функциональности паралеллизации комманд

Кроме того, что x86 — это разная длина команд, что дает пенальти для невыровненных блок в циклах и ветвлениях. И именно из-за этого так сильно вырос кэш инструкций и кэш трасс. И именно по этому VLIW отлично себя чувствует вообще без кэша трасс.

только логика была бы не в процессоре, а в компиляторе.

Это ключевое отличие RISC, SISC от VLIW

А поле шаблона каким образом на RISC натягивается?

Таким же как и на CISC. Найди два отличия template’ов в IA64 и в port’ах и доменах на x86_64. Всё разница в том, что там ставил компилятор, теперь компилятор поле шаблонов не ставит, но всё равно группирует команды по этому же принципу.

Кроме того, что x86 — это разная длина команд, что дает пенальти для невыровненных блок в циклах и ветвлениях.

Это уже очень давно не так.

И именно из-за этого так сильно вырос кэш инструкций и кэш трасс.

Откуда куда вырос? В современных x86 он 32Кб, но это связано с тем, что процессор декодирует и выполняет команды наперёд, даже если она не потребуется. Trace cache уже 10 лет как умер, с переходом на Nehalem архитектуру, концепцию не меняют уже туеву хучу лет,

И именно по этому VLIW отлично себя чувствует вообще без кэша трасс.

Все современные x86 процессоры тоже прекрасно себя чувствуют без него. В том же 15-летней давности Itanium 2 instruction cache был 16 Кб, в Pentium 4 того времени 8 и 16Кб, а в современных SkyLake-X — 32Кб. Так что это очень странный довод.

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

Если я скомпилирую код на C, который умножает матрицы, средствами VC6, то получу группировку команд? Нет. Это перестанет быть x86? Нет. Та может быть разница есть?

В современных x86 он 32Кб, но это связано с тем, что процессор декодирует и выполняет команды наперёд,

Только декодирует наперед и префетчит. Даже если у меня смешаны код и данные. А VLIW так делает?

Все современные x86 процессоры тоже прекрасно себя чувствуют без него.

Это от того, что Intel вводила специфические mOp для отдельных распространенных x86 операций: на первых Core rep movsb убивал производительность на раз (привет memcpy в старых либах), только в Ivy это исправили путем ввода новой mOp.

Если я скомпилирую код на C, который умножает матрицы, средствами VC6, то получу группировку команд? Нет. Это перестанет быть x86? Нет. Та может быть разница есть?

Идеологически разницы нет — одно и то же, только разный интерфейс в процессоре для задания группировок.

Только декодирует наперед и префетчит. Даже если у меня смешаны код и данные. А VLIW так делает?

Ручной префетч — это основа и фейл EPIC платформы. Ну и 16Kb instruction cache в Itanium, наверное, для красоты. Единственное, что он не делает — это out-of-order execution, потому что задаётся компилятором, а всё остальное он делает тоже, что и x86.

только в Ivy это исправили путем ввода новой mOp.

И что это меняет?

Идеологически разницы нет — одно и то же, только разный интерфейс в процессоре для задания группировок.

Идеологически получается разницы нет в RISC, SISC, MISC и VLIW. Раз разницы — «идеологической»! — нет, но на фига Intel менять отличную IA-32? Идеологически IA-64 ничем не отличается!

Ручной префетч — это основа и фейл EPIC платформы.

Это не основа, а лишь одно из улучшений по сравнению с VLIW, но это именно улучшение. Если хочешь эффективно перемалывать данные, нужно вовремя их подкидывать. Процессор не телепат и не знает, что именно хочет разработчик и какая наиболее эффективная стратегия префеч. Это работает и сейчас в CUDA.

Единственное, что он не делает — это out-of-order execution

Придержи-ка коней! EPIC не делает out-of-order execution — это сильное утверждение, даже если бы такое сказал сам Бабаян. В EPIC планировщик не угадывает как в RISC, а знает. Это большая идеологическая разница.

Идеологически получается разницы нет в RISC, SISC, MISC и VLIW. Раз разницы — «идеологической»! — нет, но на фига Intel менять отличную IA-32?

По-моему тебя понесло. Если ты не видишь ничего общего — в этом нет ничего страшного, твоя жизнь врядли от этого сильно поменяется.

Процессор не телепат и не знает, что именно хочет разработчик и какая наиболее эффективная стратегия префеч. Это работает и сейчас в CUDA.

А почему тогда в Nehalem (как и всех последующих, кто базируется на этой архитектуре, включая самые последние процессоры) ручной префетч тормознее «телепатического» модуля в x86?

Придержи-ка коней! EPIC не делает out-of-order execution — это сильное утверждение, даже если бы такое сказал сам Бабаян.

Т.е. ты утверждаешь что EPIC делает out-of-order execution?

А почему тогда в Nehalem (как и всех последующих, кто базируется на этой архитектуре, включая самые последние процессоры) ручной префетч тормознее «телепатического» модуля в x86?

Не везде. www.researchgate.net/...​s_When_It_Doesn’t_and_Why

Т.е. ты утверждаешь что EPIC делает out-of-order execution?

Если смотреть на низком уровне отложенный exception не является out-of-order execution? В любом случае на уровне планировщика компилятор выделяет «независимые» блоки и перегруппировывает операции. Чистой воды out-of-order execution, только не на лету, а в момент компиляции.

В любом случае на уровне планировщика компилятор выделяет «независимые» блоки и перегруппировывает операции. Чистой воды out-of-order execution, только не на лету, а в момент компиляции.

Давай не будем приводить то что мерещится или кажется за истину. Если нет информации из официальных источников, то и out-of-order execution тоже нет.

Давай не будем приводить то что мерещится или кажется за истину.

Если ты не понимаешь о чем я — в этом нет ничего страшного, твоя жизнь вряд ли от этого сильно поменяется.

А официальное подтверждение, что в Itanium есть OOE будет?

1. Не Itanium, а в целом архитектура EPIC.
2. Ты готов выдержать пространные измышлизмы и выдумки под соусом «я вижу намного больше»?

Простого нет было бы достаточно.

Ты должен осознать то, какая у меня выдержка: я же это все выдержал

Не везде. www.researchgate.net/...​s_When_It_Doesn’t_and_Why

Intel optimization guide говорит, что сейчас уже везде. Оно имеет смысл только за 100-200 комманд до чтения участка памяти размером не более 64 байта (cacheline), при условии, что ты знаешь, что не займёшь чужую линию для prefetch и не замедлишь выполнение текущих команд. «Телепатический» модуль в разы эффективнее. Это как тут один гуру до сих пор живёт тем, что верит, что доступ к EAX регистру быстрее.

Оно имеет смысл только за 100-200 комманд до чтения участка памяти размером не более 64 байта (cacheline), при условии, что ты знаешь, что не займёшь чужую линию для prefetch и не замедлишь выполнение текущих команд.

Да, такие паттерны в «телепатический» модуль хрен завезешь, как и предварительное обращение к другому банку. Умение оптимизировать все еще остается уделом программистов, а не инженеров Intel.

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

Как раз ручной прифетч и перестал приносить пользу после того, как глубина декодирования команд была сильно увеличена. По поводу банков — как раз эту логику и привезли, процессор сам раскладывает паттерны обращения к памяти используя 2, 3, 4, 6 — канальный контроллер памяти. Часто память вообще нелинейно организована, только это прозрачно для устройств, ОС, и пользователей.

Умение оптимизировать все еще остается уделом программистов, а не инженеров Intel.

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

Вообще-то программистам даются типичные паттерны кода, всё остальное делают компиляторы.

Отчасти согласен: время на тонкую оптимизацию остается все меньше и меньше.

Отчасти согласен: время на тонкую оптимизацию остается все меньше и меньше.

И знаний тоже. Для тонкой оптимизации нужно представлять как работает современный процессор, а многие застряли в 2000-ых годах, а подходы тех времен даже вредны сейчас. Ведь большинство даже не понимает как работала аппаратная x86 эмуляция на итаниуме и как её засунули назад в x86 в современных процессорах. И это тоже объяснимо, не всем нужны такие тонкости, гораздо проще в голове разделить всё на 100% RISC, CISC, VLIW.

То, что вчера было смешно, сегодня уже навевает грусть. Еще немного и ты переплюнешь местного гуру с регистром EAX: он тоже в «тонкостях» был спец.

Есть теоретики, есть практики. Но даже теоретики такие теоретики, они не могут пройтись по патентной базе Intel и сопоставить 2+2 на временной шкале + прочитать наконец-то optimization guide от Intel’а.

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

Выдуманный инсайд передаёт тебе привет из соседнего кубикла %)

Я рад за него и за то, что он работает за десктопным итаниумом.

что он работает за десктопным итаниумом

К чему это?

Чистой воды out-of-order execution, только не на лету, а в момент компиляции.

И именно поэтому он чудовищно неэффективен.

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

Про то, что невозможно предсказать задержки доступа к памяти, когда они прыгают в диапазоне от 1 до 300 тактов? Это даже в учебниках много лет (как например Патерсон), а тем более на каждом углу сказано. Ну можете ещё Дреппера про память почитать, там ровно то же самое.

Возвращаемся к исходному утверждению:

Чистой воды out-of-order execution

... И именно поэтому он чудовищно неэффективен.

Выходит ordered execution эффективней, чем out of order execution? Какое имеет отношение к этому Дреппер с его заметками о памяти для начинающих программистов?

«В момент компиляции».
Перестаньте заниматься художественной резкой по квотингу.

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

Вот интересно откуда это все берется?

Из грустной тупой объективной реальности, дорогой коллега.

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

И я так понимаю,

тупая объективная реальность

подкреплена цифрами, графиками и вообще оформлена в виде научной статьи?

подкреплена цифрами, графиками и вообще оформлена в виде научной статьи?

Да.
Но я видел эти статьи за ACMʼовским paywallʼом, а сейчас у меня туда доступа нет. Хотите найти — 180$ наверняка не проблема. Я искать не буду, пока у меня нет причины подписываться к ним.

У нас есть такие приборы! Но мы вам о них не расскажем.
Достаточно было бы просто сказать «нет»

Что такое

конвейеры на сотню команд и две сотни микроопераций

? Это размер кэша инструкций? количество стадий конвейера (какого именно порта?)? кол-во портов (всех или каких-то именно?)? размер ROB? размер moP буфера? Длина очереди (какой?)?

Давай не будем приводить то что мерещится или кажется за истину. Если нет информации из официальных источников, то и.

VLIW никакими вариациями не является ни RISC, ни SISC. Отсюда повторяю вопрос:

Каким образом можно набить шишки на VLIW и выпустить удачный RISC?
Каким образом можно набить шишки на VLIW и выпустить удачный RISC?

Я уже выше объяснял. Посмотри на правила UV commands pairing в интелловских x86 того времени — там те же темплейте, что и в EPIC, только негласные и дающие обратную совместимость для кода, если UV pairing не поддерживается.

www.agner.org/...​ze/instruction_tables.pdf

Cмотри страницу 122 по Pentium MMX. Свойство Pairability. Это та база с которой они начали.

После Itanium все идеи в более продвинутом были воплощены в x86. Те же самые длинные VLIW инструкции но в микрокоде.

Давай не будем приводить то что мерещится или кажется за истину. Если нет информации из официальных источников, то и.

никакого соответствия и нет.

Ок, нет, так нет.

После Itanium все идеи в более продвинутом были воплощены в x86. Те же самые длинные VLIW инструкции но в микрокоде.

А нафиг тут Itanium был? Только чтобы самому те же шишки набить?

Айтэниум проще в реализации, там, где играет роль количество ядер — они могли представить 64+ ядер на кристалле без теплового удара, на x86 они так не могут.

Те же самые длинные VLIW инструкции но в микрокоде.

Я так понимаю, ты готов указать в документации где же именно

VLIW инструкции но в микрокоде

применены в последних ядрах Intel x86?

Я так понимаю, ты готов указать в документации где же именно

Если бы ты хотел узнать, то начал бы зондировать архитектуру современных процессоров на wikichip. Начать с этого:
en.wikichip.org/...​ki/macro-operation_fusion
en.wikichip.org/wiki/micro-operation

Если же тебе это нужно, чтобы всё отрицать — я не против, оставайся с тем багажом знаний и представлений, что у тебя есть.

Представь пункт в документации Intel по любому ядру x86 2018-2020, где были бы описаны VLIW инструкции в микрокоде.

Такие вещи не документируют. Как я уже сказал, если тебе интересно — штудируй открытые источники:

patents.google.com/patent/US6675376

Дорогой «практик», значит так: документацией ты НЕ ВЛАДЕЕШЬ, несешь откровенную пургу ибо ни ссылок на документацию, ни официальных документов ты на свое «творчество» представить не в состоянии. Возможно ты просто не в состоянии, тогда это объясняет твое поведение. По итогу ты знаниями ничем не лучше адепта регистра EAX, только комплексов у тебя больше.

Если быть откровенным, то мне всё равно, что ты думаешь, сути вещей это не менят, как и реальное положение дел.

Если речь идет о XScale, который выпускал Intel с 2003, то при чем тут Itanium? Процессор с ARMv5 instruction set, был на многих устройствах под управлением MS Mobile 6.x

Мне больше всего тут была новым специфика WC — мне в обычной работе такое не попадалось. Просто неоптимальный доступ, false sharing и прочее — сколько угодно, но это всё на WB.

А вот это

Любое чтение из WC региона памяти также осуществляет сброс буфера в память, работая как posting read механизм.

это имеется в виду сброс той же строки, что читается, или всего региона? (хм)

это имеется в виду сброс той же строки, что читается, или всего региона? (хм)

По логике вещей — должно быть всего региона, оно ж расчитано не на рандом доступ, а последовательный, когда ты что-то заливаешь в эту память. Это может быть и буфер для обмена с устройством, так и framebuffer.

но наиболее яркая и простая для понимания

Прикалываешься?
Да на это, чтобы только найти места тормозов и найти, как починить 3-6 месяцев уйдет.
Подобное могут себе позволить только конторы типа той, в которой ты работаешь.
И второе, учить подобное и использовать на практике можно только в конторе подобной той, где ты работаешь.

Представь таким занимаются в единорожке или на галере. Кто позволит столько времени ковыряться в этих нюансах процессоров и памяти и платить всё это время таким спецам большие деньги.

З.Ы. Ну и мне не нравится такое современное усложнение работы процессоров и памяти и кешей. Это усложнение не позволяет использовать возможности процессоров и памяти современной в массовом программировании. Как минимум нужны либы, что хоть частично избавляют от таких трюков и имеют полноценную документацию. Второе — это усложнение всё дальше отделяет конторы-гиганты от мелких контор по качеству их продуктов. Получается, что только богатая контора может выпустить качественный продукт (я не про продукты уровня СД-еджектор).
А еще добавь к этому всякие мельдауны и подобное, патчи для которых меняют работу процессоров с памятью и кешированием.

Кто, кроме Горчака подобное делал сам тут (проживая не в Канаде, Германии, США и не работая на богатой конторе)? Отзовитесь.

Кто, кроме Горчака подобное делал сам тут

Когда я проходил собеседование, чтобы работать тут контрактором из Украины — им не очень нравилась идея контракторства. И они очень сомневались, в дискуссии был упомянут один из драйверов — VESA драйвер, который очень тормозил у заказчика, но так видеоконтроллер там был очень нестандартный на то время, то драйвера не было и никто его писать не собирался. Я сказал, давайте поступим так — две недели, если я его не ускорю в несколько раз, то на работу меня не берут, если ускорю, то берут. Deal is a deal.

Если кто помнит, для доступа к VESA видео-памяти можно было проводить только через окно размером в 64Kb в среднем через VGA сегмент. Через API можно было получить указатель на код внутри видео BIOS чтобы выполнить переключение банков памяти для записи и чтения, а можно было вызвать прерывание BIOS Int10 для этого. Дефолтный драйвер вызывал через эмуляцию Int10. Я переделал код на получения указателя для подпрограммы переключения банков из биоса, но быстрее стало немного. Много дней я делал замеры, дизассемблировал код и смотрел почему там медленно пока до меня не дошло, что код был в ROM на PCI устройстве. Все ROM на PCI по умолчанию не используют кеши, а находясь на PCI устройстве доступ тормозиться ещё раза в 2-4, т.к. запросы на чтения проходят через PCI bridge. В драйвере я скопировал PCI ROM в обычную кешируемую память, далее была сложность оформить эту память как EXECUTABLE со стороны процессора, из-за секьюрити, многие ОС выключают эту возможность. После я получил просто сумасшедшее ускорение. Далее я решил его ускорить ещё — все записи проводились в shadow RAM в кешируемой памяти а затем копировались с помощью оптимизированного memcpy() в video RAM. Далее я включил Write-Combine для этого региона, ведь отрисовка — это 95% записи и 5% чтения из видео памяти, но чтения обслуживала shadow RAM и тоже было быстро. Получился настолько быстрый драйвер, что можно было даже тягать окошки без особых тормозов.

Работу я получил :)

Так я тебя и не критикую. Я прекрасно знаю, что ты спец в своей области.

Ты делал? Или слышал, что где-то кто-то в стиле «по ночам там ходит черный погроммист»?

Т.е. тебе в оном и признаться стыдно?

Alex Rzvd
час назад

Делали, BSP и сейчас есть. Прикол ещё может быть в том, что в больших конторах тоже не сильно хотят/могут таким заниматься. Поэтому могут и аутсорсить
Ответить Поддержать
Viktor Chyzhdzenka
час назад

Ты делал? Или слышал, что где-то кто-то в стиле «по ночам там ходит черный погроммист»?

Я в такую проходил интервью два года назад.
Но им в тот момент нужен был только джанговод.

Но вопрос мой был о другом. А я понял, если нужна уборщица в компанию, где работает Горчак, это тоже считается.

Но вопрос мой был о другом.

Я на него ответил. Люди ваяют свои железки. Или тебе нужно чтобы и сами SoC проектировали (хотя бы на уровне «склеим вот такие готовые ядра»)?

А я понял, если нужна уборщица в компанию, где работает Горчак, это тоже считается.

Смешно, но не в тему.

Не розумію, чому ти вважаєш, що такі проблеми тільки в гігантах вирішують?

Ми ще 17 років тому пиляли систему віртуалізації FreeVPS в маленькій американській конторці Positive Software. І були попереду Parallels із їх Virtuozzo, могли нарізати фізичну пам’ять, а не віртуальну, як у них (це дуже важливо якщо, наприклад, якую java клієнт хоче гоняти), був віртуалізований шедулер, була підтримка віртуалізації дискових квот (одна з найскладніших задач була), віртуалізація всього мережевого стеку, був свій віртуальний ethernet-драйвер із нарізкою пропускої здатності. До речі, потім конотору викупила як раз велика корпорація (Comodo) й проект поховала. Тож, великий не завжди гарно :)

А візьми, наприклад, XEN for ARM. Його запилили хлопці із київського GlobalLogic (зараз більшість тої команди в EPAM, якщо не помиляюсь). Дуже цікавий і складний проект:
wiki.xenproject.org/...​ion_Extensions_whitepaper
Зараз його використовують у всьому світі.

Та багато чого цікавого робиться. Просто далеко не все виходить в паблік.

Ну embedded скоріш за все буде теж розвиватися від атмела в пральній машині до джаваскрипту на хромі в тій же пральній машині.

А замість бетонного чи чавунного якоря буде використовуватися масив оперативки :)

В стиралке часто есть кусок балласта, чтобы её не носило при отжиме. Вот туда и пойдёт.
Или ты под «якорем» имел в виду именно это? Тогда меня термин удивляет.

Да на это, чтобы только найти места тормозов и найти, как починить 3-6 месяцев уйдет.

С чего это? Тут можно за неделю сузить поиск до конкретного типа операции.

Представь таким занимаются в единорожке или на галере.

У меня на прошлой работе было (не единорог и не галера, нормальная продуктовая). Надо прилетевшее сообщение (100-200 байт полутекста, 15-20 AVP) препарировать и выслать дальше (или не высылать; обычно высылать).
Собственно тест работы сообщения показал, что все варианты разложить сообщение по атрибутам (даже в супероптимальном варианте, массив атрибутов, большинство инлайнятся в структуры) в ~3 раза дороже, чем просто манипулировать сообщением как строкой... а вся разница в том, что строка занимает те же 200 байт, а минимальный массив получался где-то 500.
Вот вам и кэш...

А вот там один сайт на жабаскрипте в 10 раз ускорил.

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

Зачем придумывать?) Другие уже сделали))
Лет пять назад пришлось мне портировать с дельфы на шарп узкоспециальный оптимизационный проектик, так вот, там для проверки на деление на ноль использовался try/catch....

для проверки на деление на ноль использовался try/catch

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

Всё так. Но дать явную пометку типа [unlikely] было бы полезнее (если компилятор поддерживает).
JITʼы используют это в варианте — не проверять, а если вылезет машинное исключение, тогда уже реагировать (а если доля таких исключений превосходит некоторый порог — то перекомпилирует в более пессимистичный вариант), так работает, например, Hotspot.

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

Во входных данных ноль встречался довольно часто, так что замена try/catch на if ускорила раз в 15) Да, ещё там промежуточные результаты сохранялись в текстовом файле и перед началом очередного прохода парились (а проходов было 10K+)

Часто эффективнее к входному числу прибавлять маленькое и все работает быстро, точно и никаких делений на 0.

Для целых чисел отлично работает, но не для double. Ты ж знаешь, какой цирк с мантиссами случается при сложении/вычитании. А там как раз все было дробным с большим количеством знаков после запятой.

Вообще-то это стандартный трюк для double. Для целых всё сложнее.
И нет там цирка, есть четкие стандарты.

Для целых всё сложнее.

для целых n >= 0 прекрасно работает
а цирк, это вот такие приколы:
habr.com/ru/post/258483

В Києві є automotive проекти як мінімум у трьох лідерів ринку. На співбесідах в такі проекти, буває, про кеш також запитують.
Тож стаття дійсно дуже корисна тим, що показує, як саме розуміння роботи кеша допомагає вирішувати задачі, які можуть виникнути перед розробниками ПЗ на таких проектах.

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

Так, бінарні дерева там дійсно просять обходити.
Якось так сталося, що про наслідування мене востаннє питали на співбесідах років десять тому.

судя по порядку величин в

41.44 Mb/s

это точно был не

memory bandwidth

Если следовать классическому определению — memory bandwidth is the rate at which data can be read from or stored into a semiconductor memory by a processor. То это именно он и есть. Процессор при данном режиме кэширования быстрее не может.

Прочитав статтю на одному подиху, наче детективну історію.
Відразу ж видно високий професіоналізм автора, і що особливо цікаво — на реальних прикладах показана необхідність розуміння роботи кеша для розробників ПЗ для embedded пристроїв.

роботи кеша для розробників ПЗ для embedded пристроїв

якщо цей кеш буде в embedded пристрої

Звісно, для розробників ПЗ для embedded пристроїв без кеша необхідність розуміння роботи кеша може бути і не настільки актуальною, як для розробників ПЗ для embedded пристроїв з кешем, але оскільки в будь-який момент розробнику ПЗ для embedded пристроїв без кеша можуть запропонувати написати ПЗ для embedded пристроїв з кешем, то на всяк випадок розуміння роботи кеша не завадить навіть розробникам ПЗ для embedded пристроїв без кеша.

Embedded — он разный. И если уже говорить о тенденциях, количестве предложений и зарплатах, то рано или поздно эмбеддерам микроконтроллеров стоит свичнуться в эмбеддеров на SoC.

У нас тут в наших степах нема особливо вакансій підтримувати BSP та лізти до ядра, а лінунс ембедед мігрує в такий собі бекенд на C++, Java, Rust, Python, bash, Lua думаю, Go теж скоро буде, як і node js.
Тобто свічнутися в бекендщики/фулстекери мікроконтролерщикам.

Да вроде у гигантов аутсорсинга всю жизнь были подобные проекты, особенно у тех, кто в automotive сидит.

формочки на хідюніті малювати в Qt

Тут были статьи и про ядреную разработку и GPU и хайпервайзеры. Значит есть... ну или было :)

я про руст писав, і що значить що 100500 руст вакансій у лідерах появилося?

Значит есть... ну или было :)

или «и ты говори» ))

Не зрозумів, як MOVNTDQA, яка гріла процесор в середині статті, перестала його гріти в кінці.

Різні типи кешування регіону пам’яті, котрий використовується. В першому випадку в одному з напрямків кеш не працює, проц тупить на доступі до кожного ворда, тому процес роботи з пам’яттю довгий, проц мало відпочиває, тому гріється.

загрузка ядра процессора, которое занимается копированием из Write-Combining (WC) региона памяти составляет около 30%, что довольно таки много, делая embedded процессор слегка тёплым, в районе 45-50 градусов Цельсия
Вариант действий номер 2. Мы кладём и ложим данные для обработки медиа-процессором в кэшируемую память. Но надо позаботиться о том, чтобы данные из кэша записались в память.

Именно так, как объяснил Денис, данный процессор на чтение некушируемой памяти тратит в ~100 раз больше тактов, задействует контроллер памяти на борту для каждой операции вместо кеша, спать некогда. Не используются «burst» групповые операции при работе с памятью. Ну и как я написал — не то, чтобы он был горячий, но мониторинг показал увеличение с дефолтных 38-40 градусов до 45-50.

Какими инструментами пользуетесь для профилирования приложений с такими проблемами?

Такие проблемы можно определить только косвенно. Например у нас есть продукт на базе Eclipse — www.qnx.com/...​/analyze_performance.html , который может снимать трейсы всей системы и потом детально под микроскопом их разглядывать. Как правило они видны как процессы или потоки, которые едят CPU под 100% в определенные моменты времени без перерыва. Дальше остаются детали — понять почему большая загрузка. В случае описанном в самом конце статьи — такие проблемы решаются только аналитически.

Или например, взять тот же пример VA API из статьи — вызываются функции vaCreateImage() и затем vaMapBuffer(). По сути чёрный ящик. Память выделяется драйвером и мапится в адресное пространство процесса и какой режим кеширования он выберет неизвестно по-началу. Анализируется скорость доступа с помощью нашей библиотеки, которую мы можем подлинковать в любой продукт — она произведёт все замеры. Дальше снимаем дамп процесса через /proc/ и смотрим с какими аттрибутами память была выделена и где она физически находится и кто её owner. Далее в исходниках смотрим почему именно так, а не иначе (описанный случай с LLC). Ну и затем пытается решить проблему.

У процессоров есть performance counters, по которым можно получить данные типа «мы 90% времени стоим в ожидании памяти». А дальше уже только разбираться, почему такое, оценив, какие цифры нормальны.
В Linux я для такого применял обычный perf. В других ОС должны быть аналоги.
Ну а специфику происхождения проблем (как в описанном, какие регионы памяти с какими свойствами) это уже только знать или гуглить...

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

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

Чем меньше искусственного интеллекта и больше контроля над ним в процессоре, тем более быстрее и прогнозируемо можно написать код. Детерминированность всегда была краеугольным камнем в разработке. Фантастика нам не нужна.

Буквально месяц назад был сильный идоло-пад, то ли карантин плохо влияет, то ли к людям приходит старость без мудрости.

«I hope AVX-512 dies a painful death, and that Intel starts fixing real problems instead of trying to create magic instructions to then create benchmarks that they can look good on,» wrote Torvalds. ... He notes that «in the heyday of x86», Intel’s rivals always outperformed it on FP loads.Jul 13, 2020

www.zdnet.com/...​tperformed it on FP loads.

Всё, чувак закостенел и новое прошло мимо его понимания. Он даже не понял, что дело далеко не в FP loads....

Детерминированность всегда была краеугольным камнем в разработке.

Увы, физический мир не детерминированый. Так что надо иметь инструменты и такие. Никто не отменял применение инструментов с умом.

Всё, чувак закостенел и новое прошло мимо его понимания.

«чувак» как раз по делу сказал, просто в фальшивом мире, где тебе улыбаются в лицо, сложив руку в дулю за спиной, не воспринимают адекватно подобную прямоту и открытость
а вот беглочитатели и быстрокомментаторы таки явно недопонимают, что активация AVX-512 кратно снижает производительность CPU Intel на всех других инструкциях

а вот беглочитатели и быстрокомментаторы таки явно недопонимают, что активация AVX-512 кратно снижает производительность CPU Intel на всех других инструкциях

Смотря от чего отталкиваться и что брать за базу. Первое правило — халявы нет. У процессора есть базовые частоты и набор turbo boost частот. То, что одно ядро получает больше частоту turbo boost за счёт других — это не кратно снижает производительность, а заставляет другие ядра работать на штатной частоте. Покупая процессор 2.4GHz с turbo boost под 3.2Ghz не стоит ожидать постоянной работы на 3.2GHz, а стоит исходить из того,что будет работать под 2.4GHz всегда.

отталкиваться от того, что люди таки не читают
на CPU Intel активация AVX-512 снижает именно БАЗОВЫЕ частоты кратно, на некоторых моделях вплоть до 0.8GHz
P.S. AMD EPYC при активации AVX2 на всех ядрах не снижает базовые частоты

на CPU Intel активация AVX-512 снижает именно БАЗОВЫЕ частоты кратно, на некоторых моделях вплоть до 0.8GHz

То, что имплементация на _некоторых моделях_ не совсем удачная — не делает это расширение ужасным или ненужным. Первые SSE в многоядерных процессорах создавали ещё больше проблем.

Например, это исследование hal.archives-ouvertes.fr/hal-02167083v2/document показывает, что на процессорах 5-летней давности УЖЕ такого эффекта нет — However, AVX512 seem to have a different behavior where its power consumption is lower than the other instructions despite providing better performance

Почему Линус разморозился только сейчас? Ну и AVX512 — это целая серия команд, которая появлялась не одним куском, а постепенно и мы её используем также без какой-либо драмы вокруг неё. И объявлять всё это ненужным — как-то недалеко. Ему не нужно — нам нужно.

Например, это исследование hal.archives-ouvertes.fr/hal-02167083v2/document показывает, что на процессорах 5-летней давности УЖЕ такого эффекта нет

и, даже в специально отобранных для «исследования» процессорах, частоты все равно снижаются
а Xeon 3104 3-летней давности просто своим существованием наглядно опровергает это исследование, снижая базовую частоту с и так убогих 1.7GHz до совсем уж неприличных 0.8GHz при активации AVX-512

Ему не нужно — нам нужно.

ну и зачем тогда это впиливать везде, а не только для эмбеддет

Скинь какую-то доку по этому поводу

Xeon 3104

Посмотри правде в глаза — 6-ядерный процессор с TCASE
78°C, и TDP 85W при базовой частоте 1.7GHz — они пойдут на любое преступление, чтобы оставаться в заданных пределах. Это далеко не производительный сереверный процессор. Я вообще слабо представляю, какую нишу он занимает и зачем он нужен.

У него даже ниша не прописана Intel’ом, как HPC, Enterprise, просто стоит прочерк: ark.intel.com/...​8-25m-cache-1-70-ghz.html

ну и зачем тогда это впиливать везде, а не только для эмбеддет

Ну IP core не будут переделывать, слишком много нужно перетестировать, поэтому набор команд есть всегда при использовании определенной архитектуры. Когда-то доходило до смешного, когда AMD в своих Geode процессорах лепили MMX и SSE, которые там вообще еле шевелились, на что они отвечали — это для совместимости с существующими приложениями, а не для скорости.

8-сокетная машина с 28-ядерными CPU будет достаточно производительной?
Xeon 8180
Base Frequency 2.5 GHz
Max Turbo Frequency 3.80
AVX-512 Base Frequency 1.7 GHz
Sockets 2S/4S/8S

AVX-512 Base Frequency 1.7 GHz

И что? Они понижают частоту ядра, которое использует AVX512, а не то, о чём ты говорил выше, другие ядра подвержены минимальным изменениям, как раз то, о чём писалось в статье, которую я привёл.

Смотри табличку — там предоставлены все детали по изменениям частот и максимальным Turbo Boost частотам в зависимости от использования. По ядрам: en.wikichip.org/...​/intel/xeon_platinum/8180

По ссылкам типа такой идут массовые плачи о том, что переход на AVX512 занижает итоговую производительность. Есть пример даже где вроде бы частота снижается на копейки (3.1->2.9), но и итоговая производительность соответствует не 1.9x от AVX256, а ~0.95 — лучше бы не включали.

Ну и влияние на _соседние_ ядра убивает логику шедулера. Так что я в принципе согласен с Линусом: если бы на одном ядре что-то менялось от этого только на время работы команд — да пожалуйста, но когда это превращается в неуправляемую ерунду — оно того не стоит...

Но виновата не технология, а иплементация. Я выше привел пример с AMD Geode, а до этого были и Cyrix первые, в которых MMX являлась серьезным замедлителем. И в программах того времени определяли, что за процессор, чтобы разрешить или запретить оптимизацию на MMX.

А Линус против технологии как таковой, хотя даже тот же AVX512 — это целый зонтик расширений, а не одно единственное.

Ну и влияние на _соседние_ ядра убивает логику шедулера.

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

Но виновата не технология, а иплементация.

Зачем делать имплементацию, заведомо зная про проблемы?
Снижение частоты идёт даже на AVX-256. Что-то в консерватории там не то.

А Линус против технологии как таковой, хотя даже тот же AVX512 — это целый зонтик расширений, а не одно единственное.

У него позиция вполне понятная:
1. Ложка дёгтя против бочки мёда.
2. Видя, что AVX256 не научили не тормозить с 2013-го, вводить AVX512 с ещё большим торможением, создавая проблемы соседним ядрам(!) - преступление.

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

. Видя, что AVX256 не научили не тормозить с 2013-го, вводить AVX512 с ещё большим торможением, создавая проблемы соседним ядрам(!) - преступление.

К сожалению, они просто не расчитывали на постоянный workload, паттерн использования при дизайне был другой, по идее должны были быть всплески и пульсы команд. Например, на многих уровнях в процессоре не происходит понижение частот, если частота появления команд меньше threshold’а опредленного. На серверном рынке барыгам, которые продают виртуальные процессоры пришлось несладко, конечно. Но влияние на соседние ядра можно просто создать и так — пример в моей статье. И чем больше ядер, тем большее адище можно устроить. Тут только спасает аппаратный partitioning, но барыги все равно продают виртуальные ядра даже после partitioning’а.

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

Осописателем не приходится делать ровным счётом ничего, чтобы показывать факи. Thermal и Power throttling никто не отменял, к понижению частот нужно быть всегда готовым. На самом деле причин Throtlling’а около шести в интелловских процессорах.

Розказували мені про один автомобіль, в якому ABS і дисплей на одному процесорі під гіпервізором.

Навіть не знаю, чи вони бариги, чи це вже brave new world...

Если гипервизор работает «железобетонно» в плане как изоляции, так и выделения гарантированных долей времени и прочих ресурсов, то пусть.
Но что-то я в это слабо верю...

Но что-то я в это слабо верю...

Почему?

Потому что ошибки есть везде, а тут ещё прошло мало времени, чтобы этому всему быть вылизанным, а как автопроизводители экономят на спичках — мы видим по Тойоте и Фольцу.
Да, это аргументация системы «с миру по нитке», но для личной веры при отсутствии прямого взаимодействия и более конкретных аргументов — устраивает полностью.

а как автопроизводители экономят на спичках — мы видим по Тойоте и Фольцу.

Там нет такой уж страшной экономии. Сейчас выдам тайну Полишинеля %) У каждой линейки машин существует два, а то и три-четыре полностью альтернативных комплектов всей электроники, на случай если поставщик или софта или железа склеет ласты. Также с этой электроникой постоянно собирают статистику и если количество отказов одного типа довольно высоко его меняют на электронику другого производителя. Вполне возможно, что остальное сваливают в страны третьего мира, тут правды никто не знает. Решения с хайвервайзером — это luxury сегмент. Например, я помню у mitsubishi опцию в прайсе — добавить мультимедия систему за 10К баксов, там не только мультимедия система, но беда, например, у mitsubishi — это то, что покупая аутлендер за 20К, 10К никто за рюшечки платить не будет, а премиум сегмента у них нет. Другое дело, Cadillac — это практически весь премиум сегмент и там дешевые системы будут только в самом нижнем ценовом диапазоне, а в остальных premium по дефолту.

Тойота, Фольц, Митсубиши, Ниссан — это ягоды с одного куста по сути. Не стоит ожидать супер решений на борту.

Там нет такой уж страшной экономии.

Я говорил не только про электронику. См. тему Фольца + тесты дизеля.

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

У каждой линейки машин существует два, а то и три-четыре полностью альтернативных комплектов всей электроники, на случай если поставщик или софта или железа склеет ласты.

И что, меняют каждые 10000 выпущенных машин?
Если просто держат в запасе, то это невыгодно тому поставщику.

Про цену — понятно, тут всё криво и косо из-за сложности переключения. Увы.

И что, меняют каждые 10000 выпущенных машин?

Врядли по количеству определяют, на сколько я помню по месяцам, машины, выпущенные в таких-то кварталах с одной электроникой, в других кварталах с другой. Это связано с supply chain, когда на складах одного типа становится меньше чем другого типа их меняют. Юзер видет немного измененный GUI на кластерной панеле, а в качестве развлекательной системы, везде Android, похожий как две капли или в виртуалке или на живой системе (самоубийцы). Ну а в среднем юзер даже не догадывается об существовании альтернатив.

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

Понятно, спасибо. Забавный метод диверсификации всего включая риски...

Там другая цель — не дать андроиду или другому безобразию, которое живёт под виртуалкой существленно влиять на хост в плане производительности. Там полная дискриминация виртуалок.

Например, мы используем виртуализацию для интеловских GPU — GVT-g: wiki.archlinux.org/index.php/Intel_GVT-g . Где используется приоритезация и pre-emption, чтобы обеспечить 60 FPS на хосте за счёт виртуальных клиентов, а Андроид или другое под виртуалкой работает по принципу, что останется.

Чи гіпервізор може гарантувати неможливість атак типу thermal throttling? Чи frequency throttling з використанням AVX512? Чи скидання кеша для всіх ядер, як описано в статті.

Розумію, що всі небезпечні операції мали б виконуватися на нульовому кільці, але ж діри трапляються.

Я намагаюся розносити різні задачі по різних фізичних процесорах, щоб спокійніше спати вночі. І не завантажувати процесор і мережу вище номіналу. Мав колись цікаву розмову з інженерами з Siemens про real-time і Ethernet...

Разница в том, что ты owner всей системы и можешь контроллировать всё, весь софт и т.п., в случае же с хостингом или облаком ты не контроллируешь ничего, если купил виртуальный процессор. А если ещё учесть и жадность хостеров, то можно смело запускать виртуалок на 133%-150% от количества ядер, чтобы уж совсем не простаивали.

Розумію, що всі небезпечні операції мали б виконуватися на нульовому кільці

А от не називайте більше його «нульовим» :)
Це аж до x86 було нормою, що 0 — найбільш впливовий, але після введення SMM, який тоді має бути −1, система зламалась і в новіших розробках (ARM/64, RISC-V, etc.) 0 це user, а рівень машини це, наприклад, 3.
Тепер краще казати «supervisor level», «hypervisor level» і «machine level». А ще є secure mode, в якого ті ж рівні, але окремо...

Чи скидання кеша для всіх ядер, як описано в статті.

Скидання кеша це лиш часткове уповільнення, і взагалі на вході в привілейований режим невідомо, що в кеші — може, йому самому треба скинути все попереднє (а враховуючи Meltdown/Spectre/etc. — і при виході у менш привілейований режим може бути корисне скинути все). Але якщо залізо буде досить сучасне — там скоріше виділятимуть фіксовані сектори кешу кожній задачі. До речі, таке вмів Pentium Pro.

А ось регулювання частоти від всяких AVX це серйозніше. Щонайменше, супервізор має бути освідченим, що юзерська задача таке запросила, і коли дозволяє — підкоректувати свою логіку...

Для АБС нужно считать 8 датчиков и выдавать команды по 4 каналам... +1 на чек енжин ...

Чтобы вырезать аппендицит нужно строить больницу©

Пускай себе гипервизор на слив в унитазе поставят!
(Тут я вспомнил про японские стульчаки... )

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

Даже ежу понятно, что эта гарантия не сработает никогда, а тем более строителям процессоров с 40-летней историей.

Но влияние на соседние ядра можно просто создать и так — пример в моей статье.

Кэш — относительно известное зло (то есть он, конечно, добро при нынешней тормозной DRAM, но выражение сохраним). И с ним свои уже известные проблемы. А тут новый эффект.

Тут только спасает аппаратный partitioning

А он на x86 работает? Что-то я пропустил.

Thermal и Power throttling никто не отменял, к понижению частот нужно быть всегда готовым.

Ну в большинстве случаев ОС стоит на пути оповещения об этом и сама принимает решение, кроме совсем уж критических перегревов... насколько я помню (оно с каждым поколением чуть меняется). А тут что — запрещать AVX512 юзерленду, чтобы взорвалось на первой команде, и тогда разрешать, но пинать шедулер «эй, тут сейчас начнётся фигня»?

А он на x86 работает? Что-то я пропустил.

patents.google.com/patent/US8862828B2/en

В двух последних линеек Xeon оно там есть и работает. Вопрос насколько глубоко реализован partitioning.

ну и зачем тогда это впиливать везде, а не только для эмбеддет

Ну и, кстати, у нас почему-то довольно-таки много заказчиков сидят на Xeon процессорах в embedded. Раньше Intel делал даже линейки мобильных Xeon для embedded. Может именно эта модель имеет нишу для home / embedded (негласную).

Да вы что, кто такой этот Линус Торвальдс? А вот синьйор Mike Gorchak...

Таки да. Горчак это та рабочая лошадка, которая делает, а Торвальдс уже давно занимается административной работой.

То може підете й запитаєте думку коня в якому-небудь радгоспі: шо від думає про тенденції розвитку процесорів? Ну або принаймні як збільшити врожайність вівса (це коням має бути ближче).

Нет, я спрошу у таракана — он знает всё и ответы на все вопросы. А если что не согласуется указом изменит, чтобы согласовывалось.

Тобто спитаєте в адміністратора?
В принципі правильне рішення, а інакше навіщо в радгоспі агрономи?
Нехай робочі конячки самі все вирішують, адже ж вони більше всіх працюють.
І знаєте ще в чому тут ще закавика?
Лінус Торвальдс перед тим як стати адміністратором таки шось зробив дуже корисне.
Але шось мені підказує шо щоб не зробив Горчак — він навіть і близько не стане Лінусом Торвальдсом.
Надмірно роздуте ЧСВ завадить.

Тобто спитаєте в адміністратора?

Нет, у локального Бога (он же таракан).

Спасибо, интересно! Многих вещей не знал (посмотрев всё доступное по оптимизациям от гугла и фб с cppcon).

Дуже цікаво. Багато про що перший раз чув, що є Write combining режим, це, типу теж кеш але з L1 одразу на шину ? Про команди MOV, які специфічно використовують кеш. Мабуть, з часів, коли всі кеши і контролер пам’яті переїхали в процесор все стало складніше ніж колись.

Дуже цікаво. Багато про що перший раз чув, що є Write combining режим, це, типу теж кеш але з L1 одразу на шину ?

Сейчас они его называют write buffer. Отдельный он или они берут кэшлайны из L1 — это скрыто под капотом. Говорят, что у Skylake он состоит из 56 кэшлайнов, 56*64=3584 байт. Так что можно сказать, что очень маленький временный L1.

все стало складніше ніж колись.

В 90-е я случайно попал в программу поддержки разработчиков от Intel, когда при регистрации (а они принимали только штатовские адреса), указал USA, штат не помню какой, а в графе адрес — Ukraine, etc. Какое было удивление, когда на домашний адрес пришёл именно мешок книг, килограмм 15-20. Среди них был двухтомник по архитектуре 486, по 200 страниц каждый. А сейчас тот PDF на который есть ссылка в статье содержит 5000 страниц. Так что немного написали нового, да :)

Я тоже помню заказал где-то тогда. Но одну книжку. Таможня попросила за растаможку книжки стоимостью 1 бакс 25 баксов. Пришлось отказаться от книжки.

В 90-е я случайно попал в программу поддержки разработчиков от Intel, когда при регистрации (а они принимали только штатовские адреса), указал USA, штат не помню какой, а в графе адрес — Ukraine, etc. Какое было удивление, когда на домашний адрес пришёл именно мешок книг, килограмм 15-20. Среди них был двухтомник по архитектуре 486, по 200 страниц каждый.

о, а я в ті часи Intel CD замовив і він прийшов, з купою pdf

Большое спасибо, очень интересно !

Подписаться на комментарии