Начнем с конца. «Учет в муравейнике» — это I/O bound задача. Причем даже не I/O памяти, а практически безумно медленного по сравнению с процессором HDD. Так что никакое увеличение ПСП памяти там не поможет принципиально.
Далее. Объем L3 кэша среднего Core i5 и старших 2-ядерных Wolfdale равны (по 6 МБ). При этом у Wolfdale вдвое выше ассоциативность и вдвое же ниже латентность. Так что количество строк само по себе на скорость не влияет.
Еще далее. Не нужны пустые слова. Нужна КОНКРЕТНАЯ практическая задача. Пока вижу сферического коня в вакууме. И он стал еще сферичнее, а вакуум еще глубже.
Т.е. по сути никакой практической задачи нет и не предвидится. Есть гениальная задумка, для доказательства которой приводится абсолютно бессмысленный тест. Ну да, если вам действительно нужно исполнять с предельной скоростью эти 5 инструкций в такой последовательности, то всенепременно нужно потратить триллионы долларов, чтобы кардинально поменять архитектуру компьютеров.
Причем даже в этой совершенно вырожденной задаче ПОЛОВИНА ПСП и объема кэша тратится совершенно впустую. Потому что мало того, что используется абсолютно бессмысленное выравнивание, так еще и второй элемент вообще никак не используется.
Знаете, я не заметил, чтобы вы были ведущим инженером-архитектором Intel или IBM, чтобы с таким апломбом выдавать мне «домашнее задание».
И стоит избавиться от идиотской привычки возражать на то, чего оппонент никогда не говорил.
Независимо от того, может или не может L3 кэш выдавать данные каждый такт, его ПСП прямо пропорциональна тактовой частоте, его латентность в тактах от частоты не зависит, а в наносекундах — обратно пропорциональна ей.
Как только сможете тестами опровергнуть это — заходите, будет о чем поговорить.
Идиота тут скорее изображаете именно вы.
Не надо путать ПСП и латентность. ПСП зависит от ширины шины и частоты. А латентность еще и от организации кэша.
Смысл именно в том, что ПСП и латентность — величины в некоторой степени ортогональные.
А такой величины как «скорость» в данном случае вообще не существует.
1. Я нигде не утверждал, что размер кэша не влияет на скорость доступа. Я утверждал, что в существующих условиях размер кэша ограничен не малой длиной строки, а стоимостью и энергопотреблением.
2. Утверждение о том, что темп для данных в кэше и в памяти таков-то без указания в каком именно кэше не имеет смысла. В процессорах, начиная с архитектуры Nehalem латентность кэша L1D выросла с 3 до 4 тактов. А латентность доступа к Last Level Cache (L2 у Wolfdale и L3 у Ivy Bridge) при сравнимом объеме у Wolfdale вообще двое ниже — 15 тактов против ~30. Так что пока данные умещаются в L1D или превышают объем L2 Ivy Bridge, но умещаются в L2 Wolfdale последний будет быстрее, даже несмотря на меньшую частоту именно благодаря значительно меньшей латентности кэша. Но как только объем данных значительно превысит размер кэша, любой процессор с интегрированным контроллером памяти (iMC) будет превосходить по скорости работы процессор без IMC буквально в разы.
3. Я недаром спрашивал про ПРАКТИЧЕСКУЮ задачу, которую должно решать глобальное изменение архитектуры. Как и ожидалось, вместо практической задачи представлен сферический конь в вакууме, где как минимум 25% объема памяти теряется на абсолютно бессмысленное выравнивание, соответственно 25% объема кэша и 25% ПСП теряются впустую.
4. Мне неясен философский смысл инкремента edx и декремента ecx в приведенном ассемблерном коде. Они никуда не записываются и ни с чем не сравниваются.
Итого. Будет реальная задача, для которой так уж необходима глобальная перестройка всей архитектуры компьютеров? Естественно с кодом. С полным кодом, а не выдранным куском. Который можно скомпилировать/сассемблировать, измерить скорость, оптимизировать и т.п.
Нужно использовать оптимальные структуры данных, а не брутфорсить железом ситуацию, когда лишние байты неизбежно будут читаться вместе с необходимыми.
И так уже имеем ситуацию, когда в кармане у каждого лежит многоядерный компьютер, мощнее, чем любой суперкомпьютер 60-х годов или управляющий компьютер «Шаттла» или «Бурана», но используемый настолько неоптимально, что даже отрисовка UI на нем может тормозить.
КМК предложенные решения совершенно неоптимальны. Объем кэша ограничен отнюдь не «малой» длиной его строки, а «транзисторным бюджетом», т.е. размером кристалла, его стоимостью и энергопотреблением. Сверхдлинные строки кэша приведут к тому, что для доступа к одному байту придется читать уже не 31/63 лишних байта, а 4095. И когда понадобится освободить одну из строк кэша, в память придется записать целых 4 Кб, что почти на 2 порядка дольше записи стандартной 64-байтной строки. Соответственно, это катастрофически увеличит латентность. Предзагрузка в кэш реализована уже давным-давно, поэтому если встроенный prefetcher не справляется с каким-то хитрым шаблоном, то никто не мешает приложению самому загружать необходимые данные. Ну и т.п.
А можно узнать, какую практическую задачу должно решать вот это все?
Т.е. в каких именно задачах из реального мира не хватает пропускной способности памяти?
Сверхтяжелые РН проектировались под определенные задачи. Например, лунные программы для Н-1 и Сатурн-5. Коммерческие нагрузки, которые неспособен вывести Протон, мне неизвестны.
Для того, чтобы произвести ракету нужно оборудование, установленное на действующем заводе, а точнее на сотнях или даже, возможно, тысячах заводов. А оно (предположим) лежит на складе в пустыне Аризоны. Сколько сотен миллионов долларов (если не миллиардов) понадобится, чтобы доставить и установить законсервированное оборудование на заводы, где оно стояло раньше, построить заново те заводы. которые сейчас уже не существуют, обучить персонал для работы с этим оборудованием и т. п. Сколько времени на это понадобится?
Ракету забросили, поскольку коммерческих нагрузок для сколько-нибудь регулярных самоокупаемых запусков таких ракет просто нет. А сохранять все только для того, чтобы доказать скептикам, что ракета была, никто в здравом уме не будет. Научные же нагрузки худо-бедно выводят РН легкого и среднего классов. Пусть это именно худо-бедно, но приемлемо по цене.
Запуск Сатурна-5 сейчас стал бы крайне бессмысленной тратой огромного количества денег.
Даже если бы была вся документация и все оборудование, необходимое для его производства.
Видимо тем, что стоит задача объективно оценить именно подготовку летчиков к посадке.
А у «обычной автоматической посадки по ILS» ограничений вагон и маленькая тележка. Тем более что на военных аэродромах никаких ILS нет, и надеяться на их существование в боевых условиях вообще глупо.
Потому что опытный летчик очень быстро компенсирует минимальные отклонения от идеальной траектории, а неопытный реагирует гораздо медленнее, а его траектория в результате получается очень «горбатой».
Если говорить о сферическом самолете в вакууме (точнее абсолютно симметричном самолете в абсолютно изотропной атмосфере), то видимо так и есть. Бесконечно опытный пилот смог бы поставить самолет с бесконечно малой инерцией в нужное положение за одно движение.
На практике на самолет действует куча постоянно изменяющихся сил и моментов, а его моменты инерции далеко не нулевые: если это Су-27, то по массе это 3 КамАЗа.
Если посмотреть на масштаб оси Х, то «как бешеный» летчик ручку не дергает. Он просто парирует начинающиеся небольшие отклонения от идеальной глиссады, в то время как неопытный летчик регулярно отклоняется от нее на значительные углы. К сожалению, исходных данных для этой графиков нет, но даже без них очевидно, что если построить скользящие средние для углов отклонения РУС, то получившиеся кривые для классного летчика будут куда более гладкими.
Только вот Хендрикс, Сантана, Би Би Кинг и прочие играют на лучших гитарах, а не каком-нибудь китайском полене. Именно поэтому нет смысла обсуждать их технические характеристики — лучше (во всяком случае для них самих) просто нет.
2 стопа — это, конечно, хорошо.
Только шумы — это не светосила. Кроме того нет единой общепринятой методики количественного измерения таких шумов. Поэтому при выборе камеры ориентироваться на такой показатель весьма сложно.
Далее. Объем L3 кэша среднего Core i5 и старших 2-ядерных Wolfdale равны (по 6 МБ). При этом у Wolfdale вдвое выше ассоциативность и вдвое же ниже латентность. Так что количество строк само по себе на скорость не влияет.
Еще далее. Не нужны пустые слова. Нужна КОНКРЕТНАЯ практическая задача. Пока вижу сферического коня в вакууме. И он стал еще сферичнее, а вакуум еще глубже.
Т.е. по сути никакой практической задачи нет и не предвидится. Есть гениальная задумка, для доказательства которой приводится абсолютно бессмысленный тест. Ну да, если вам действительно нужно исполнять с предельной скоростью эти 5 инструкций в такой последовательности, то всенепременно нужно потратить триллионы долларов, чтобы кардинально поменять архитектуру компьютеров.
Причем даже в этой совершенно вырожденной задаче ПОЛОВИНА ПСП и объема кэша тратится совершенно впустую. Потому что мало того, что используется абсолютно бессмысленное выравнивание, так еще и второй элемент вообще никак не используется.
И стоит избавиться от идиотской привычки возражать на то, чего оппонент никогда не говорил.
Независимо от того, может или не может L3 кэш выдавать данные каждый такт, его ПСП прямо пропорциональна тактовой частоте, его латентность в тактах от частоты не зависит, а в наносекундах — обратно пропорциональна ей.
Как только сможете тестами опровергнуть это — заходите, будет о чем поговорить.
Не надо путать ПСП и латентность. ПСП зависит от ширины шины и частоты. А латентность еще и от организации кэша.
А такой величины как «скорость» в данном случае вообще не существует.
Еще попытка?
ВСЕ кэши процессоров Sandy Bridge, Ivy Bridge и Haswell работают на «полной частоте».
2. Утверждение о том, что темп для данных в кэше и в памяти таков-то без указания в каком именно кэше не имеет смысла. В процессорах, начиная с архитектуры Nehalem латентность кэша L1D выросла с 3 до 4 тактов. А латентность доступа к Last Level Cache (L2 у Wolfdale и L3 у Ivy Bridge) при сравнимом объеме у Wolfdale вообще двое ниже — 15 тактов против ~30. Так что пока данные умещаются в L1D или превышают объем L2 Ivy Bridge, но умещаются в L2 Wolfdale последний будет быстрее, даже несмотря на меньшую частоту именно благодаря значительно меньшей латентности кэша. Но как только объем данных значительно превысит размер кэша, любой процессор с интегрированным контроллером памяти (iMC) будет превосходить по скорости работы процессор без IMC буквально в разы.
3. Я недаром спрашивал про ПРАКТИЧЕСКУЮ задачу, которую должно решать глобальное изменение архитектуры. Как и ожидалось, вместо практической задачи представлен сферический конь в вакууме, где как минимум 25% объема памяти теряется на абсолютно бессмысленное выравнивание, соответственно 25% объема кэша и 25% ПСП теряются впустую.
4. Мне неясен философский смысл инкремента edx и декремента ecx в приведенном ассемблерном коде. Они никуда не записываются и ни с чем не сравниваются.
Итого. Будет реальная задача, для которой так уж необходима глобальная перестройка всей архитектуры компьютеров? Естественно с кодом. С полным кодом, а не выдранным куском. Который можно скомпилировать/сассемблировать, измерить скорость, оптимизировать и т.п.
И так уже имеем ситуацию, когда в кармане у каждого лежит многоядерный компьютер, мощнее, чем любой суперкомпьютер 60-х годов или управляющий компьютер «Шаттла» или «Бурана», но используемый настолько неоптимально, что даже отрисовка UI на нем может тормозить.
КМК предложенные решения совершенно неоптимальны. Объем кэша ограничен отнюдь не «малой» длиной его строки, а «транзисторным бюджетом», т.е. размером кристалла, его стоимостью и энергопотреблением. Сверхдлинные строки кэша приведут к тому, что для доступа к одному байту придется читать уже не 31/63 лишних байта, а 4095. И когда понадобится освободить одну из строк кэша, в память придется записать целых 4 Кб, что почти на 2 порядка дольше записи стандартной 64-байтной строки. Соответственно, это катастрофически увеличит латентность. Предзагрузка в кэш реализована уже давным-давно, поэтому если встроенный prefetcher не справляется с каким-то хитрым шаблоном, то никто не мешает приложению самому загружать необходимые данные. Ну и т.п.
Т.е. в каких именно задачах из реального мира не хватает пропускной способности памяти?
Для того, чтобы произвести ракету нужно оборудование, установленное на действующем заводе, а точнее на сотнях или даже, возможно, тысячах заводов. А оно (предположим) лежит на складе в пустыне Аризоны. Сколько сотен миллионов долларов (если не миллиардов) понадобится, чтобы доставить и установить законсервированное оборудование на заводы, где оно стояло раньше, построить заново те заводы. которые сейчас уже не существуют, обучить персонал для работы с этим оборудованием и т. п. Сколько времени на это понадобится?
Ракету забросили, поскольку коммерческих нагрузок для сколько-нибудь регулярных самоокупаемых запусков таких ракет просто нет. А сохранять все только для того, чтобы доказать скептикам, что ракета была, никто в здравом уме не будет. Научные же нагрузки худо-бедно выводят РН легкого и среднего классов. Пусть это именно худо-бедно, но приемлемо по цене.
Даже если бы была вся документация и все оборудование, необходимое для его производства.
А у «обычной автоматической посадки по ILS» ограничений вагон и маленькая тележка. Тем более что на военных аэродромах никаких ILS нет, и надеяться на их существование в боевых условиях вообще глупо.
На практике на самолет действует куча постоянно изменяющихся сил и моментов, а его моменты инерции далеко не нулевые: если это Су-27, то по массе это 3 КамАЗа.
Если посмотреть на масштаб оси Х, то «как бешеный» летчик ручку не дергает. Он просто парирует начинающиеся небольшие отклонения от идеальной глиссады, в то время как неопытный летчик регулярно отклоняется от нее на значительные углы. К сожалению, исходных данных для этой графиков нет, но даже без них очевидно, что если построить скользящие средние для углов отклонения РУС, то получившиеся кривые для классного летчика будут куда более гладкими.
Только шумы — это не светосила. Кроме того нет единой общепринятой методики количественного измерения таких шумов. Поэтому при выборе камеры ориентироваться на такой показатель весьма сложно.