интересно, а можно ли программно узнать в любой момент времени, в каком конвеере что исполняется???
если да, то на каких процах? Opteron, Athlon64, Xeon???

AFAIK, нет...

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

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

http://www.wasm.ru/forum/index.php?action=vthread&forum=7&topic=4694

тоже был покой и тишина... Возможно, мы пришли на неправильный форум...

Вот еще одна формулировка: может быть где-нибудь есть описания каких-нибудь микроархитектур каких-нибудь процессоров в виде разностных (дискретных дифференциальных) уравнений? Если их не более нескольких тысяч и если их записать в нормальной форме Коши, то их очень просто можно было бы "просуммировать"...

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

Даже в "пределах" одной модели CPU могут быть "странные" вещи..
Вот есть документ от AMD "Using Block Prefetch for Optimized Memory Performance"
Там приводятся разные способы оптимизации простой операции - копирования.
Есть пример - разворачивают цикл *2 и далее:
"it's not clear why the performance dropped a little when loop was unrolled.."
Пишет это не вася пупкин, а "Member of Technical Staff Developer Performance Team"
Даже ему не совсем понятно.
Что процессор AthlonXP 1800+ имеет дробный коэффициент умножения, и поэтому в НЕКОТОРЫХ случаях может показывать падение производительности, когда по логике вещей должно быть наоборот. Например он может быть медленнее, чем 1700+


Возможно, мы пришли на неправильный форум...
На board32 есть такой человек - BitRAKE. Он предложил весьма интересный способ получения оптимальной производительности. Теоретически очень эффективный.

Смысл его такой: пусть даны исходные данные в регистрах CPU. Необходимо получить определенный результат (другие данные в этих регистрах). Неизвестен в нашей задаче "путь" - т.е. каким образом эти данные получить. Находится он приблизительно так:
-берем область памяти
-заполняем ее значениями
-запускаем на выполнение
-сревниваем результат с желаемым
если не то, что надо, повторяем с другими значениями.
Значения получаем путем последовательного перебора всех возможных :)
Ну надо еще обрабатывать исключения и прочае..

Осталось только реализовать на практике :)
Не знаю, сложнее это чем дифуры..


И еще, мне кажется, что производители CPU давно забили на этот вопрос.
Они сейчас все больше маркетингом занимаются

S_T_A_S_

Почитал я высказывания твоего BitRAKE и ничего не понял ;(

volodya
Ну-ну :-)) я и то понял.. что лучше.. на эту.. забить :-))

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

Тут алгоритмической оптимизацией заниматься надо
Вот!! Как данные правильно организовать и использовать потом. Да и то не всегда..

А конвеер.. Я вот по началу в Code Analiste мучал-мучал что нибудь.. а потом смотрю: мой код на ура практически выполняется, все спарено-лучше-некуда (ну, почти ;), а потом.. длиииииииные задержки: процессор кеш заполняет. Да еще банк-конфликты :(
А потом этот код P4 выполняет в 2 раза медленнее, чем Athlon!!
Поэтому сделал вывод: на все забить :) Если уж, что-то делать в такой оптимизации, то другой подход нужен. И среди всех этих "других", комбинаторика выгдыдит "наиболее реально" ;-))) . Можно еще третий глаз развивать, например :)
К тому, же данные етого Analista иногда расходятся с практическими замерами. Я так понял, он - больше для C :)

А BitRAKE это еще сто лет назад понял, вот и объяснил мне в шуточной форме сложность "конвеерного" вопроса.
Вообще, имхо, много интересного можно услышать от людей, пришедших на x86 с M68x00. Хотя они молчат обычно >:\

> Пишет это не вася пупкин, ... Даже ему не совсем понятно.

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

> комбинаторика выгдыдит "наиболее реально"

Нет, не выглядит :) Если мы хотим получить blended code (оптимизированный сразу под несколько процессоров) то должны иметь возможность померять его скорость на нескольких микроархитектурах. А как это сделать на одном процессоре без эмуляции?

Кроме того, тут же вылезают другие проблемы. Например, проблема остановки алгоритмически неразрешима. Это есть неопровержимый факт. Так что даже с теоретической точки зрения комбинаторика не является решением :)

captain cobalt
Если мы хотим получить blended code .. померять его скорость на нескольких микроархитектурах.

Ну-ну :) Не надо противоречить фирме intel. Они же популярно объясняют в рекламе, что PIV быстрее, чем P3. Хотя реальность показывает обратное. Так же было и с появлением P2. Да сколько таких примеров еще можно привести? Поэтому нет и не будет никогда этого blended code. Разве только на платформе .NET ;)
Имхо, разумное решение здесь - для некритичных участков использовать общие приемы оптимизации. А для критичных - никуда не деться от CPU-оринтированных.
А по поводу комбинаторики.. у буржуев просто воспитание не позволяет сказать человеку: забей!! Вот мне и нарисовали решение. Причем САМОЕ простое.

ЗЫ
По поводу дифуров, вопрос на засыпку: как они будут учитывать, скажем арес, который нам вернет HeapAlloc ?

А мы подставим в эти дифуры этот вызов и узнаем что должно произойти

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

Под уравнениями я понимаю СТАТИЧЕСКУЮ математическую модель процессора, законы перехода из одного состояния в "следующее". Ее можно также представить в виде конечного автомата. Например, в виде диаграммы Мура. Но в виде формул будет компактней.

А я понимаю, что мы не можем предсказать заранее где наши данные будут находиться в памяти. Поэтому появляется вероятность банк-конфликтов, не учтенных в этих уравнениях. И есть еще переключение задач.. Хотя ТЕОРЕТИЧЕСКИ - интересно