Но эмм, если не из чего выбирать, на ряде задач можно поиметь профит.

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

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

И? К чему ты это пишешь? Ты придумал какую-то херню и с ней споришь, её разоблачаешь. Ко мне это не имеет никакого отношения.

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

Какой пайплай, какой предсказатель, какое ручную? Что ты несёшь?

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

А поток управление ортогонален потокам вычисления.

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

Каких вопросов? Ты ни задал ни единого вопроса. Я вижу глупые потуги обвинять меня в то, о чём я не говорил. Срывать покровы моими же тезисами, и заспам рандомными базвордами.

Бери и задавай конкретные вопросы, а не пиши левую херню.

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

Или царское решение какой-нибудь задачи, чтоб всё по-пунктам демонстрировалось, как надо.

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

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

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

Вопрос один, почему существуют исследования и документы навроде этого. Это было 10 лет назад, и уже тогда SMT был спасителем человечества (и в течении 10 лет до того).

PHP runtime. А я ведь не ошибался.

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

Что я отрицаю, в каике детали я не вдаюсь? Давай уже, завози конкретику.

Ну и потом, как можно верить, если ты не даёшь ни какой проверяемой информации?

Верить чему?

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

Заранее всё оговорено, просто ты не читаешь. Я оговариваю столько условий, сколько не оговаривает ни один пациент.

Я сразу написал, что и зачем нужно. Сразу описал контекст, вернее описал его автор изначального тезиса.

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

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

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

Именно поэтому никаких «идеальных», да и вообще каких-то алгоритмов/структур в реальном мире нет. Они всегда новый, всегда уникальные.

Сводить всё к набору шаблонного дерьма - базовое свойство ламерков.

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

Я думаю, большинство получало знания из документов, подобных https://ieeexplore.ieee.org/document/1105971/ и если ты не согласен с более-менее общепринятым мнением, потрудись хотя бы приводить цитируемый источник, в котором твоя точка зрения бы подтверждалась какими-никакими аргументами или исследованиями.

ps. Запили хороший секурный Hurd, нам нужна альтернатива. Раз уж даже Qubes всосал. Хотя Xen и секурность?

Какие-то алгоритмы параллелят только колхозники.

Ты же сам хотел параллелить средствами суперскалярности и OoO.

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

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

А когда нельзя - ты не получишь никакого профита и от SMT/MT, повторю второй раз.

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

Проблема твоего колхоза, SMT никак не поможет.

Поможет запустить на HT sibling ещё какую-то обработку. Часть исполнительных устройств всё равно будет простаивать.

Перепутал колхоз, современные процессоры не про летенси.

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

Любая обработка в любом колхозном api буфиризована, а ничего, кроме колзоз-апи у колхозников нет.

Про API ты уже сам придумал. Я ничего про него не писал.

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

А кто тебе сказал, что ты успеешь обработать предыдущий пакет до того, как придут новые пакеты?

Опять же, если пакеты независимы - последовательность не противоречит параллельности и никакая буферизация не обязательна.

Пакеты могут быть зависимы, а могут и нет. Шире нужно бы смотреть на вещи. Мы же здесь не какой-то конкретный случай обсуждаем.

Если у тебя есть зависимости - ты уже прокукарекался с буферизацией.

Тю. Какой-то странный съезд. Про буферизацию в отдельном контексте, но контексты пересекаются.

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

Сеть ты тоже сам додумал. Это может быть shared memory, pipe или ещё какая-то хрень.

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

Можно. И запустить эти задачи на sibling-е.

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

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

Начнём.

Про API ты уже сам придумал. Я ничего про него не писал.

Ну расскажи мне, ламерок, откуда ты высрешь свои пакеты. Сразу и сходу.

Я тут накатал портянку, но ладно.

Слился ты, царёк, слился, ламерок.

откуда ты высрешь свои пакеты. Сразу и сходу.

А что, царёк-ламерок про маппинг памяти устройств прямо в юзерляндию ничего не знает, да?
Ну, пускай тогда гуглит про UIO. Я же специально царьку-ламерку про shared memory выше писал. Но он нифига не допёр.

Слился ты, царёк, слился, ламерок.

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

А что, царёк-ламерок про маппинг памяти устройств прямо в юзерляндию ничего не знает, да?

О, ламерок целую неделю гугли про ммапинг. Но сообщаю новость - ммапинг такое же апи.

Ну, пускай тогда гуглит про UIO.

Да ты прям явно одарён, поздравляю.

Опять же, ламерок, ты опять обделался. Любое io требует нотификации/синхронизации, а раз ты кукарекаешь про «обрабатывать каждый запрос отдельно», то никаким образом никакой юзерспейс тебе никак не поможет, ибо ты заново изобретёшь мусорные сокеты.

Хотя это всё неважно, ламерок в очередной раз сел в лужу. Кукарекал о том, что «я не говорил про api», но высрал очередной api. Особенно интересно то, что ламерок даже сам себя макнул в дерьмо, ведь если ты не говорил о чём-то конкретном, то каким образом ты можешь ссылаться на конретику, которую ты, к тому же, до этого отрицал?

О, ламерок целую неделю гугли про ммапинг.

Да ну, я про тебя, ламерка, просто вообще забыл.

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

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

Опять же, ламерок, ты опять обделался. Любое io требует нотификации/синхронизации, ...

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

ибо ты заново изобретёшь мусорные сокеты.

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

Особенно интересно то, что ламерок даже сам себя макнул в дерьмо, ведь если ты не говорил о чём-то конкретном, то каким образом ты можешь ссылаться на конретику, которую ты, к тому же, до этого отрицал?

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

Дальше не читал потуги школодауна. Хуже всего - глупого школодауна. Не отвечайте этому судаку, не кормите троля.

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

Эти детсадовские потуги.

Да ну, я про тебя, ламерка, просто вообще забыл.

Ога.

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

Покажешь, где именно шло? К тому же, что такое «настройка апи дня обмена»? Очередную рандомную херню высрал?

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

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

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

Недобиток, тебя никчёмная балаболка уже макнули в дерьмо с твоими пакетами. Кукарекал ты именно о сети, ведь нигде в другом месте никаких пакеты нахрен не упали. Теперь обосрался и пытаешься мазаться, но опять же, трепло, а почему ты сразу не кукарекал об этом? Почему ты кукарекал об абстрактных пакетах, а как обделался - начал кукарекать «да я не это имел ввиду»?

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

Нет, царёк, обосрался - обтекай.

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

Чисто взгляд со стороны, при упоминании пакетов первое первое что приходит в голову это пакетная обработка (т.е. batch processing). Каким боком ты постоянно сетевой обмен притягивешь я хз. Наверное, сетевой стек тебя изнасиловал, других причин я не вижу.

Кстати, при упоминании фреймов ты тоже про сеть думаешь?

Покажешь, где именно шло?

Да прямо чуть выше ты писал:

Любая обработка в любом колхозном api буфиризована, а ничего, кроме колзоз-апи у колхозников нет.

... и ты обосрался.

Конкретно, что именно твоя потуга опровергает и как.

Опровергает необходимость использования какого-то API для «нотификации/синхронизации». Достаточно поллить замапленный в память регистр устройства.
Ты вообще знаешь что такое «поллинг»? Или сейчас бросишься гуглить?

К тому же, что такое «настройка апи дня обмена»? Очередную рандомную херню высрал?

У тебя парсер, как у амёбы. Я писал об «использовании API для настройки самого обмена», а ты распарсил как «настройка апи дня обмена».
Царёк-ламерёк, у тебя какой-то серьёзный brain damage. Ты не можешь распарсить даже довольно простые фразы.
Это печально, мне тебя даже немного жаль.

Недобиток, тебя никчёмная балаболка...

Полыхающий царский зад, разве это не прекрасно?

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

Долбоящер, «пакеты данных» это весьма абстрактная хрень. А в контексте низких латентностей я думал о чём угодно, но не о сети. Я тебе там даже немного намекнул, но ты, ограниченное существо, как обычно нифига не допёр.

Нет, царёк, обосрался - обтекай.

Браво! Я всегда знал, что ты в глубине души самокритичен. :-D

тебе же натренированный идеолог Эльбруса сказал что квантовые компьютеры это дерьмо для домохозяек и что они ничего не могут? - значит так оно и есть

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

О боже, эти мазы, эти мазы бездарного мусора. Пакетная обработка у него случилась:

Т.е. ты не можешь сложить в буфер несколько пакетов данных и затем обработать их параллельно,

Я знаю про что кукарекал этот ламерок( про что кукарекал ты).

Ларок целую неделю гуглил про uio:

Ну, пускай тогда гуглит про UIO.

Опять же, всё про то же. Ни для какой пакетной обработки, ни для какого ipc и прочего - никакое uio нахрен не упало.

К тому же, он макнул себя в дерьмо ещё и тут:

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

И тут мы видим, что для ламерка(тебя) звук для него имеет «высокие требования к летенси», что опять же множит на ноль любые потуги. У звука летенси больше, нежели у сети в рамках локалхоста. А уж про uio, ipc и говорить нечего.

... и ты обосрался.

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

Опровергает необходимость использования какого-то API для «нотификации/синхронизации». Достаточно поллить замапленный в память регистр устройства.

О, да тут у нас мк-ламерок, причём совсем никчёмный. Заммапленный у него регистр случился.

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

Теперь ты мне, недобиток балаболящий, покажешь - откуда ты высрал это:

необходимость использования какого-то API для «нотификации/синхронизации».
API для «нотификации/синхронизации»

Я даже тебе помогу, убогий, и покажу что именно говорил я:

Любое io требует нотификации/синхронизации

В чём?

Да во всём. Ты в этой теме обсераешься на каждом шагу.

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

Прими таблетки, ламер-царь.

О, да тут у нас мк-ламерок

Хрен ты угадал. И ты опять обосрался.

Заммапленный у него регистр случился.

Что, не знал что так бывает, анскильная ты балаболка? И здесь ты тоже обосрался.

покажу что именно говорил я:

А что же ты, анскильное быдло, только начало своего предложения цитируешь, а? Где вторая часть, в которой ты писал, что «никаким образом никакой юзерспейс тебе никак не поможет»?
Что, снова обосрался, и из-за этого зассал цитировать предложение целиком?
Думал, небось, что никто не заметит твоего позора, да?

... звук для него имеет «высокие требования к летенси»...
... У звука летенси больше...

Царьог, ты баклажан.
Требования к латентности не у звука, а у задач по его обработке. Что включает в себя и латентность ввода/вывода, и латентность самих алгоритмов его обработки.
А алгоритмы могут быть совсем непростые, и при этом обычно последовательные.
Кроме того, бывают и другие волны, которые тоже необходимо обрабатывать с высокими требованиями к латентности.

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

Теперь ты мне, недобиток балаболящий, покажешь - откуда ты высрал это:

необходимость использования какого-то API для «нотификации/синхронизации».
API для «нотификации/синхронизации»

Я даже тебе помогу, убогий, и покажу что именно говорил я:

Любое io требует нотификации/синхронизации

Чёткий ответ, трепло, живо, либо в мусорку.

Чёткий ответ

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

Любая обработка в любом колхозном api буфиризована, а ничего, кроме колзоз-апи у колхозников нет.
...
Любое io требует нотификации/синхронизации, а раз ты кукарекаешь про «обрабатывать каждый запрос отдельно», то никаким образом никакой юзерспейс тебе никак не поможет, ибо ты заново изобретёшь мусорные сокеты.

Ты, царь-гребень, прочитал про то, как осуществляется обработка прерываний через UIO и сразу начал кукарекать про нотификации/синхронизации. Типа без использования API осуществлять I/O всё равно не получится. И ты обосрался, когда я тебе рассказал про поллинг замапленых в память регистров устройства. Но ты думал, никчемная ты балаболка, что это невозможно, и с этим ты опять обосрался.

Ламерок начал мазаться.

Кто начал мазаться, гребень ты балабольный? Я тебя давно уже слил в унитаз.

..летенси там мусорная, и никакой «высокой» никогда не станет.

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

Это я тебя ещё за контекст не спросил...

За какой контекст, даунито-царь?

... ты обосрался в рамках своих же потуг.

В рамках «своих же потуг» я тебя давно уже слил. Но ты, как истинное гуано, всё равно всплываешь.

Твои потуги как ответ мне - я даже не не разбирал.

Да-да, мы тебе верим. И обсераешься привселюдно ты тоже по приколу. :-D

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

Звук если чо должен быть максимально реалтайм, даже буферы минимально и крутят ядро, потому что в продакшене все косяки себя проявляют. Процессинг в реалтайме без dsp, да ещё на не реалтаймовой ос, вообще довольно грустное занятие конечно.

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

PREEMPT_RT значительно улучшает положение с софт-реалтайм задачами под Линуксом.

Ну и заодно покажу, почему ещё данный ламерок ламерок:

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

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

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

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

Что я говорил:

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

На что я вижу детсадовские потуги:

Внезапно, есть не код, а алгоритмы, на которых в принципе невозможно получить высокий ILP на современных процессорах с их ограничениями (размер instruction window, например).

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

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

Если кратко - проблема заключается примерно в следующем:

for(i) process(m[i]);
//соответственное, если process обладает малым уровнем параллелизма(уровня инструкций), это суперскаляр в дерьме. В рамках этого обработчика.



Но может случиться так( и зачастую случается), что истерии process() зависят друг от друга мала, а значит - их можно исполнять параллельно, что суперскаляр и делает.


По сути он просто читает и запоминает инструкции первой итерации, запоминает их и читает далее. Очевидно, до того момента - пока эта "память" не кончится. Это и есть то самое window в рамках терминологии колхозников. Правда, это нихрена не window, но это такое.



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

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

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

Колхознику сообщили, что таких задач нет. Он обделался целиком и полностью. Любая обработка буферизована.

(потоковая обработка с высокими требованиями по времени обработки

И тут мы видим то, как балаболка обделалась. Оказывается, у неё не объективно высокие требования, а просто «высокие» по мерках его колхоза.

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

И что самое интересное. С каких пор вообще «где-то есть» - стало аргументом? Где есть, как есть? Неизвестно и причина проста - данный аргумент работает только тогда, когда он абстрактный - когда ничего нет.

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

Далее, он понял свою ошибку - и начал опять юлить. Выкрикивая рандомные фразы дошколёнка «да, да - да у меня там такое, отвечаю». Скажи он ещё раз что-то конкретное, либо намекни на это - он тут же обдристается.

Я уже объяснял, что TDP процессоров в спецификации не учитывает их постоянную загрузку и задействование всех блоков.

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

Бротиш, хватит уже про сеть. Ну, серьёзно. Ты же вроде первый про неё начал.

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

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

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

Однако, как пример, мне так и не удалось добиться значимых результатов от graphite (помимо того, что большинство нетривиальных оптимизаций меняет смысл инструкций и ничего не работает в результате). Инструменты типа pgo (или даже ручное расставление register/likely) повышают эффективность значительно больше.

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