Сообщение Re[8]: Переполнение буфера от 27.09.2019 13:32
Изменено 27.09.2019 13:35 netch80
Re[8]: Переполнение буфера
Здравствуйте, Евгений Музыченко, Вы писали:
S>>при переключении процессов\потоков процессор случаем не сохраняет содержимое своих кэшей для данного процесса\потока?
ЕМ>Нет. Процессор вообще не знает ни о каких "процессах" и "потоках", как объектах ОС. Для него поток — это то, что исполняется ядром.
И вот ядро вполне может оповестить процессор в духе "а тут начинает работать задача номер 9". Процессору пофиг, что этот номер значит, у него просто все задачи номер 9 будут иметь равные права на кэш.
В сообщении рядом я описал, как такие вещи могут использоваться для оптимизации.
ЕМ>Теоретически возможно, вполне безопасно, но бессмысленно. Смысл кэша — держать наготове наиболее часто используемые код/данные.
Стандартно, но в общем неверно. Смысл кэша — держать наготове те данные, которые будут использоваться.
"Наиболее часто используемые" означает тупую LRU организацию, а она далеко не всегда лучшая. Иначе бы не появились команды prefetch и запись с хинтом "эта строка больше не нужна".
Там, где есть возможность применить более хитрые методы, используется, например, 2Q — он не страдает вымыванием данных при однократной обработке большого массива данных. Но его слишком дорого переносить в аппаратную реализацию.
EM> Переключение контекста — достаточно редкое событие на фоне быстродействия процессора, поэтому оптимизация кэшей на этом уровне эффекта не даст.
Этому утверждению есть какое-то обоснование с цифрами? А то я контрпример привёл из истории, да и сейчас теория шедулинга постоянно говорит про ценность кэшей и как следствие — желание сократить переключения.
S>>при переключении процессов\потоков процессор случаем не сохраняет содержимое своих кэшей для данного процесса\потока?
ЕМ>Нет. Процессор вообще не знает ни о каких "процессах" и "потоках", как объектах ОС. Для него поток — это то, что исполняется ядром.
И вот ядро вполне может оповестить процессор в духе "а тут начинает работать задача номер 9". Процессору пофиг, что этот номер значит, у него просто все задачи номер 9 будут иметь равные права на кэш.
В сообщении рядом я описал, как такие вещи могут использоваться для оптимизации.
ЕМ>Теоретически возможно, вполне безопасно, но бессмысленно. Смысл кэша — держать наготове наиболее часто используемые код/данные.
Стандартно, но в общем неверно. Смысл кэша — держать наготове те данные, которые будут использоваться.
"Наиболее часто используемые" означает тупую LRU организацию, а она далеко не всегда лучшая. Иначе бы не появились команды prefetch и запись с хинтом "эта строка больше не нужна".
Там, где есть возможность применить более хитрые методы, используется, например, 2Q — он не страдает вымыванием данных при однократной обработке большого массива данных. Но его слишком дорого переносить в аппаратную реализацию.
EM> Переключение контекста — достаточно редкое событие на фоне быстродействия процессора, поэтому оптимизация кэшей на этом уровне эффекта не даст.
Этому утверждению есть какое-то обоснование с цифрами? А то я контрпример привёл из истории, да и сейчас теория шедулинга постоянно говорит про ценность кэшей и как следствие — желание сократить переключения.
Re[8]: Переполнение буфера
Здравствуйте, Евгений Музыченко, Вы писали:
S>>при переключении процессов\потоков процессор случаем не сохраняет содержимое своих кэшей для данного процесса\потока?
ЕМ>Нет. Процессор вообще не знает ни о каких "процессах" и "потоках", как объектах ОС. Для него поток — это то, что исполняется ядром.
И вот ядро вполне может оповестить процессор в духе "а тут начинает работать задача номер 9". Процессору пофиг, что этот номер значит, у него просто все задачи номер 9 будут иметь равные права на кэш.
В сообщении рядом я описал, как такие вещи могут использоваться для оптимизации.
ЕМ>Теоретически возможно, вполне безопасно, но бессмысленно. Смысл кэша — держать наготове наиболее часто используемые код/данные.
Стандартно, но в общем неверно. Смысл кэша — держать наготове те данные, которые будут использоваться.
"Наиболее часто используемые" означает, с нынешним железом, тупую LRU организацию, а она далеко не всегда лучшая. Иначе бы не появились команды prefetch и запись с хинтом "эта строка больше не нужна".
Там, где есть возможность применить более хитрые методы, используется, например, 2Q — он не страдает вымыванием данных при однократной обработке большого массива данных. Но его слишком дорого переносить в аппаратную реализацию.
EM> Переключение контекста — достаточно редкое событие на фоне быстродействия процессора, поэтому оптимизация кэшей на этом уровне эффекта не даст.
Этому утверждению есть какое-то обоснование с цифрами? А то я контрпример привёл из истории, да и сейчас теория шедулинга постоянно говорит про ценность кэшей и как следствие — желание сократить переключения.
S>>при переключении процессов\потоков процессор случаем не сохраняет содержимое своих кэшей для данного процесса\потока?
ЕМ>Нет. Процессор вообще не знает ни о каких "процессах" и "потоках", как объектах ОС. Для него поток — это то, что исполняется ядром.
И вот ядро вполне может оповестить процессор в духе "а тут начинает работать задача номер 9". Процессору пофиг, что этот номер значит, у него просто все задачи номер 9 будут иметь равные права на кэш.
В сообщении рядом я описал, как такие вещи могут использоваться для оптимизации.
ЕМ>Теоретически возможно, вполне безопасно, но бессмысленно. Смысл кэша — держать наготове наиболее часто используемые код/данные.
Стандартно, но в общем неверно. Смысл кэша — держать наготове те данные, которые будут использоваться.
"Наиболее часто используемые" означает, с нынешним железом, тупую LRU организацию, а она далеко не всегда лучшая. Иначе бы не появились команды prefetch и запись с хинтом "эта строка больше не нужна".
Там, где есть возможность применить более хитрые методы, используется, например, 2Q — он не страдает вымыванием данных при однократной обработке большого массива данных. Но его слишком дорого переносить в аппаратную реализацию.
EM> Переключение контекста — достаточно редкое событие на фоне быстродействия процессора, поэтому оптимизация кэшей на этом уровне эффекта не даст.
Этому утверждению есть какое-то обоснование с цифрами? А то я контрпример привёл из истории, да и сейчас теория шедулинга постоянно говорит про ценность кэшей и как следствие — желание сократить переключения.