Исходное сообщение
"Выпуск CRIU 1.0, системы для заморозки и восстановления..." Отправлено AlexAT, 27-Ноя-13 22:01
> зато кэш процессора — существенно. указателей в ядре много, все указатели в > два раза больше. Кэши тоже растут, здесь прогресс определенно есть, в отличие от производительности самих вычислительных юнитов. По вычислениям остаётся только распараллеливание - и увеличение длины регистров - неплохой шаг. >> А еще в 64-битном режиме 64-разрядная математика работает быстрее. > через libastral, ALU боги послали? Да нет, через: а) отсутствие префиксов; б) бОльшее число явно доступных регистров; в) бОльший размер регистров - не забываем, что i?86 ядро ничего о расширенном наборе явно доступных регистров и их увеличенной длине не знает. Если уж хочется сократить объем памяти под указатели - есть x86-64/x32, хотя пользы от него кот наплакал. >> — 64-битная математика нынче в каждом закоулке. > это да, суперсложные операции сложения, вычитания и целочисленного умножения/деления > — они мегатормозят. Даже банальным strcpy/memcpy/memcmp хорошеет от наличия 16 регистров вместо 8. Большее число явно доступных регистров позволяет меньше лазить в память при вычислениях, и оперировать бОльшими блоками, что позитивно влияет на кеширование. >> И если 64-битному процу это 1 операция, на 32-битном это выливается > …в ту же одну операцию на том же ALU Ни разу. Чехарды с внутренним переименованием регистров больше, и не всегда оно оптимально в условиях конвееризации.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> зато кэш процессора — существенно. указателей в ядре много, все указатели в >> два раза больше. > Кэши тоже растут, здесь прогресс определенно есть, в отличие от производительности самих > вычислительных юнитов. По вычислениям остаётся только распараллеливание - и увеличение > длины регистров - неплохой шаг. >>> А еще в 64-битном режиме 64-разрядная математика работает быстрее. >> через libastral, ALU боги послали? > Да нет, через: а) отсутствие префиксов; б) бОльшее число явно доступных регистров; > в) бОльший размер регистров - не забываем, что i?86 ядро ничего > о расширенном наборе явно доступных регистров и их увеличенной длине не > знает. Если уж хочется сократить объем памяти под указатели - есть > x86-64/x32, хотя пользы от него кот наплакал. >>> — 64-битная математика нынче в каждом закоулке. >> это да, суперсложные операции сложения, вычитания и целочисленного умножения/деления >> — они мегатормозят. > Даже банальным strcpy/memcpy/memcmp хорошеет от наличия 16 регистров вместо 8. Большее > число явно доступных регистров позволяет меньше лазить в память при вычислениях, > и оперировать бОльшими блоками, что позитивно влияет на кеширование. >>> И если 64-битному процу это 1 операция, на 32-битном это выливается >> …в ту же одну операцию на том же ALU > Ни разу. Чехарды с внутренним переименованием регистров больше, и не всегда оно > оптимально в условиях конвееризации.
	Введите код, изображенный на картинке: