Также задача это покрыть плюсами как можно более широкий объем.

алгоритм нормально опиши, а то на бред похоже

Далее он плюсует эту информацию пока загружется новая информаци

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

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

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

Можно сделать чтобы параметры ожидания стремились к оптимальным на базе эксперемента.

сабжевую фигню

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

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

Параметры системы неизвестны. Эстафета дожна выявить эти параметры и отразить их на жестком диске.

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

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

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

ТС, ты приблизительно представляешь, как работает процессор?

мы поочерёдно плюсуем грузим и измеряем время

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

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

Выполнять в это время другие инструкции процессор не может.

Hyperthreading есть же.

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

a = getTime(); плюсуем столькото грузим b = getTime()

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

ну вот и напиши программку и протестируй :)

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

Этот ник вроде же забанили?

Обязательно напишу, и выложу на гитхаб.

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

плюсовать то можно, но как при этом сделать так, чтобы в результате количество плюсов в одном блоке зависело от времени загрузки следующего блока, совершенно неясно :)

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

Нельзя, но при промахе кеша или ошибке предсказателя ветвлений управление передастся на «второй» процессор, т.е. процессор будет делать что-то ещё

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

а программа на втором процессоре как об этом узнает?

ТС не понимает, как работает проц, это факт

Никак.

В процессорах с использованием этой технологии каждый физический процессор может хранить состояние сразу двух потоков, что для операционной системы выглядит как наличие двух логических процессоров (англ. Logical processor). Физически у каждого из логических процессоров есть свой набор регистров и контроллер прерываний (APIC), а остальные элементы процессора являются общими. Когда при исполнении потока одним из логических процессоров возникает пауза (в результате кэш-промаха, ошибки предсказания ветвлений, ожидания результата предыдущей инструкции), то управление передаётся потоку в другом логическом процессоре. Таким образом, пока один процесс ждёт, например, данные из памяти, вычислительные ресурсы физического процессора используются для обработки другого процесса.[1]

Я прекрасно понимаю как процессор работает. И всё это можно сделать на одном процессоре. Просто вы предираетесь к словам. Тестовым путём узнать все параметры это реально.

Ну так пиши пруф-оф-концепт утилиту, выкладывай. Чего разорался-то?

Далее он плюсует эту информацию пока загружется новая информация

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

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

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

Я не хочу быть один. Возможно идея понравится другим.

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

Я даже не понимаю, как это работает

Разве процессор не может чтото делать пока данные грузятся ? Процессор ведь умеет оптимизировать.

Есть 2 выхода - hyperthreading или out-of-order execution (вроде так называется). Но это есть не везде, работает не всегда, итд итп. В любом случае процессору будет проще взять другую нить и исполнять её

Конечно же out-of-order

например

1 измеряем время а = взять из адреса x операция не зависящая от переменной а ++ операция не зависящая от переменной а ++ операция не зависящая от переменной а ++ операция не зависящая от переменной а ++ операция не зависящая от переменной а ++ ... 2 измеряем время

здесь мы произвели операцию с а, тоесть данные должны загрузиться

3 измеряем время

...

Получаем разницу во времени, значит нам нехватило столько то плюсов, компенсируем

Конечно же out-of-order

например

1 измеряем время
а = взять из адреса x
операция не зависящая от переменной а
++
операция не зависящая от переменной а
++
операция не зависящая от переменной а
++
операция не зависящая от переменной а
++
операция не зависящая от переменной а
++
...
2 измеряем время

здесь мы произвели операцию с а, тоесть данные должны загрузиться

3 измеряем время

...

Получаем разницу во времени, значит нам нехватило столько то плюсов, компенсируем

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

for (i=0; i<5634657657657656796705670; i++) a ++;

Скажем, куска памяти, на который ссылается a нет в кеше, проц грузит некотурую область вокруг a к себе. Что ему ещё тут делать? Он не знает, что там в a и ждет.

Тоесть я имел введу out of order prefetch переменной а.

<бред поскипан> хрептами <бред поскипан>

Розенталь тебя ненавидит.

Этот ник вроде же забанили?

Его разбанили, и правильно сделали. У мальчика таки есть интересные идеи;-)

Всё давно украдено до нас (c)

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

Ответ заранее известен практически для всех актуальных процессоров. Называется пиковая производительность. Измеряется в [M]IPS-ах (в данном случае) или Flops-ах.

Также задача это покрыть плюсами как можно более широкий объем.

Ответ также известен практически для всех уровней иерархии подсистемы хранения. Называется темпом доступа.

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

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

Да, конечно. они и используются, например, для оптимизации.

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

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

сам процессор как раз --- имеет, иначе он не смог бы воспользоваться этой информацией.

ну в смысле программа, исполняющася на процессоре

естественно и о кэш-промахах.

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

a = getTime(); плюсуем столькото грузим b = getTime()

учитывая первое попавшееся из гугла:
«Значение, возвращаемое методом getTime , равно количеству миллисекунд, прошедших с полуночи 1 января 1970 года GMT»
даже за одну миллисекунду процессор успеет сделать многие миллионы команд. Это всё равно, что спутники системы глобального позиционирования наделить песочными часам ;)
К счастью для Вас, в процессоре есть специальный регистр, содержимое которого инкрементируется каждый такт, т.е. 3-4раза каждую наносекунду.

ну в смысле программа, исполняющася на процессоре

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

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

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

Можно сделать свою реализацию getTime. Можно вообще всё на ассемблере написать.

Можно сделать свою реализацию getTime

дарю (x86/64 для gcc):
[code]inline unsigned long long int get_cur_time() {
union cpuclocks {
unsigned long long int ll;
struct d2i { unsigned int l, h; } i2;
} tm64;
int z=0;
__asm(«cpuid»:«=d»(tm64.i2.h), «=a»(tm64.i2.l):«a»(z));
__asm(«rdtsc»: «=d»(tm64.i2.h), «=a»(tm64.i2.l):«a»(tm64.i2.l),«d»(tm64.i2.h));
__asm(«cpuid»::«a»(z),«d»(tm64.i2.h),«c»(tm64.i2.l));
return tm64.ll;
}[/code]

Можно вообще всё на ассемблере написать.

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

это задача факториальной сложности

Можно сделать...

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

Все пути проходить совсем не нужно

А какие именно нужно проходить?

Более того --- именно с этого и надо было начинать. В результате рассмотрения этого вопроса может так оказаться, что и саму программу писать не нужно будет ;)

Какие пути должен пройти мурайвей за едой ? Ответ какие надо, а не все возможные. Задача охватить как можно больший объём, более эффективной зоной плюсовки.

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

Что именно является «едой»? И чем ограничены ментопсихофизические способности «муравья»?

Задача охватить как можно больший объём, более эффективной зоной плюсовки.

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

не только «понимаю», но и могу эту «стенку» нарисовать.
;)