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

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

Спасибо 👍
Вот вопрос в этом
>А иногда получается, что нет сумматоров в наличии, они чем то другим заняты и операция увеличивается на два / три такта и суммирование далется одним.

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

А что-то не гуглится особо

@byte_word ты вроде против митапов, но вот ещё парочка таких постов и обзорный доклад про архитектуру процессоров и ассемблер на пальцах уже готов.
я почему-то уверен, что интересно такое будет примерно всем

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

MUL EAX, EDX
ADD ECX, EBX

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

@byte_word круто! Даже я понял.

+1, спасибо за краткое и ясное изложение

мои глубокие знания уже не актуальны. Я хорошо знал 486 ( у меня была подробная книга по тактам). Более менее первый пентиум. По ним у меня было много инфо. С третим пнем я детально уже не разобрался. Не было уже инфы в открытом доступе, да и желания не было. Анализировать все эти векторые переходы, не было никакого желания. Интеловский компилятор это лучше делал и значительно быстрее.
Еще был интеловский профайлер, кажется он назывался tune. Вот он умел показывать как идет запрос внутри процессора и где параллельность лочилась. Тогда это было просто космос.

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

+1

Вообще если кто то хочет проникнуться низкоуровневой магией, могу порекомендовать сайты с демосценой. (это когда в относительно маленькие программы от 128 байт до 64 киллобайт засовывали чуть ли не целые фильмы).
Во времена заката фидо и появления интернета, именно в демосценических эхах писалась вся эта магия.
Вот нашел Faq по демкам, который был моей "настольной книгой": https://www.enlight.ru/demo/faq/
100%  в этом факе были ссылки на устройство контейнеров и тактовку процессоров. Но сейчас я этих ссылок что то не вижу.

Ну, наверно в SIMD компиляторы не особо умеют - по-крайней мере такое слышал недавно на Хайлоад - там доклад про векторизацию на уровне инструкций sse был.

MMX, SSE они точно умеют. возможно надо иногда какими нить интрисектами подсказать..
Но так да, векторная арифметика сложна для компиляторов. Ибо для эффективных  реализаций, надо другие абстракции использовать (векторные). То бишь компилятор должен увидеть что ты хочешь матрицу на вектор умножить, а не два вложенных цикла с одним умножением и сложением.
Шаг влево / вправо и эвристика дает сбой.  но в основном, SIMD нужен в компьютерной графике и всяких видео/аудио кодеках. В жизни обычно программиста это редко используется, ИМХО.
Возможно сейчас SIMD в нейросетях найдет применение. Но в любом слуаче, это проблемы писателей низкоуровневых либ.  Большинства это не касается.
Всё это мое предположение, ибо я уже больше 10 лет не смотрел в эту сторону.

Да всё наверно так. На практике наверно иногда можно оптимизировать какой-то внутренний цикл... Но тема вполне себе жива, это то место где компилятор без интринсиков плохо работает

твой рассказ звучал не как инструкция по использованию, а как теоретические знания.
а теория скорее всего не устарела?

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

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

Возвращаясь к теме криптографии - я правильно понимаю, что шифрование сертов от активного митм Маллори не защищает, только от пассивной Евы?

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

Это фича в tls1.3 - чтобы не было видно в открытом тексте, к какому серверу подключение

так это защита от РКН и аналогов, а не защита твоих секретов. Хотя в случае МИТМ тоже может помочь, наверное.

Этот профилировщик называется сейчас Intel VTune Amplifier. Полезная вещь для оптимизации. И ещё он теперь бесплатный даже для коммерческого использования.