OSDev

Мне этот набор непонятных цифр ни о чём не говорит, а соответственно, и комментировать ничего не могу.



Эту ерунду нагородили не только в Интел, но и в АМД, и достаточно давно. Похоже, что это всё-таки не ерунда.

Что же касается скорости памяти, то, прежде чем начинать нести ерунду, сначала б изучили подробно, что она означает. Эта частота -- всего лишь скорость, с какой память теоретически может выдавать или принимать данные в пакетном режиме, но она совершенно не отражает время, необходимое памяти на то, чтобы догадаться, что же от неё хочет контроллер. В частности, когда контроллер выдаёт памяти команду чтения, она должна получить эту самую команду; дешифровать её; принять адрес и распихать его по своим внутренним регистрам; дождаться готовности накопителя к выдаче данных -- и лишь после этого начинается пакетная передача на высокой скорости. Если бы пакеты были длинными, временем на подготовку к их чтению или записи можно было бы пренебречь, однако пакеты весьма короткие (по длине строк кэша), а посему игнорировать подготовительные операции нельзя. А есть ещё регенерация... У кэш-памяти время на подготовку существенно меньше, а регенерация вообще не требуется, поскольку кэш -- статическая память, а не динамическая.

Ну так в современной памяти дешифровка сопряжена с отправкой предыдущих данных.

По поводу регенерации она идет по строчкам. Так что вероятность попадания на синхронизирующий импульс не столь велика.

А в последних на разработках. Которые пока не используются в современных ПК. Вообще реализована отправка следующего пакета может начаться как только ушла половина предыдущего.

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

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

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

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