Ситуацию 80-х годов тут обсуждать нечего, а среди современных x86 (и не только?) процессоров это справедливо только для Intel (которые не в состоянии или принципиально не желают сделать даже такую банальность, как быстрая работа с денормализованными), и это не зависит от десктопа или сервера - Xeon у них точно так же тормозит, как В моём тесте AMD, который давно и прочно заботится о плавучке - вот, например, я недавно сравнивал (http://netch80.livejournal.com/39929.html).
> А процы для серверов и для рабочих станций, конечно всегда оптимизировали под плавучку, потому что это в дооблачную эру было их главное приложение.
Что-то непохоже. Скорее они готовы заставить пользователей и авторов компиляторов выгнуться и перейти на тотальный SSE.
> А целочисленные у десктопов всегда были хорошими, ибо оно как раз более всего влияет на десктопную активность.
Тут вопрос не в целочисленности как таковой (иначе то же деление уже бы ускорили по максимуму, а не гнали всё через ленивый, как турист под пальмой, SRT). Тут отсутствие SIMD для целочисленных в массовых реализациях (MMX не вспоминать), а как следствие - зависимость скорости работы от скорости шедулинга команд. А быстрый шедулинг простых команд больше зависит от отработанности системы исключения конфликтов в конвейере, от качества реализации базовых OoO подходов вроде Tomasulo, и тому подобного.
У меня сильное подозрение, что это то, на чём десять лет назад споткнулся Intel с IA-64. Можно легко заточить систему команд под конкретные количественные свойства процессора, как количество АЛУ и их сочетаемость - для этого всего лишь надо выставить конкретные потроха наружу. Но как только возникает вопрос о развитии или расширении (что будет, если я поставлю 3 АЛУ вместо 2?), кто будет переписывать программы под другой шедулинг и увеличенную ширину необходимого командного слова? А наоборот, что будет, если в пакете на исполнение послать 3 действия для АЛУ вместо 2, что на это скажут старые процессоры? IA-64 имел фиксированную ширину команды. Эльбрус-4 имеет нефиксированную пачку субкоманд и слово "commit" в конце, но пределы исполнения всё равно заданы. Можно ли исполнять команды быстрее, чем они поступают, и сколько блоков детекта потенциальных конфликтов потребуется для этого? Скорее всего, у Эльбруса крайне слабый шедулер, который тормозит по каждому чиху.
Вообще, VLIW в этом плане именно как ISA (а не как внутренние детали) выглядит крайне неудачно. И системы с трансляцией, как x86, и с прямым исполнением и минимумом OoO вроде переименования регистров, как быстрые версии современных RISC, его обгоняют. Он оказался как фиксация на машинном коде устаревшего компьютера вместо переносимого языка хотя бы уровня Паскаля.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2016-02-06 09:50 (UTC)Ситуацию 80-х годов тут обсуждать нечего, а среди современных x86 (и не только?) процессоров это справедливо только для Intel (которые не в состоянии или принципиально не желают сделать даже такую банальность, как быстрая работа с денормализованными), и это не зависит от десктопа или сервера - Xeon у них точно так же тормозит, как В моём тесте AMD, который давно и прочно заботится о плавучке - вот, например, я недавно сравнивал (http://netch80.livejournal.com/39929.html).
> А процы для серверов и для рабочих станций, конечно всегда оптимизировали под плавучку, потому что это в дооблачную эру было их главное приложение.
Что-то непохоже. Скорее они готовы заставить пользователей и авторов компиляторов выгнуться и перейти на тотальный SSE.
> А целочисленные у десктопов всегда были хорошими, ибо оно как раз более всего влияет на десктопную активность.
Тут вопрос не в целочисленности как таковой (иначе то же деление уже бы ускорили по максимуму, а не гнали всё через ленивый, как турист под пальмой, SRT). Тут отсутствие SIMD для целочисленных в массовых реализациях (MMX не вспоминать), а как следствие - зависимость скорости работы от скорости шедулинга команд. А быстрый шедулинг простых команд больше зависит от отработанности системы исключения конфликтов в конвейере, от качества реализации базовых OoO подходов вроде Tomasulo, и тому подобного.
У меня сильное подозрение, что это то, на чём десять лет назад споткнулся Intel с IA-64. Можно легко заточить систему команд под конкретные количественные свойства процессора, как количество АЛУ и их сочетаемость - для этого всего лишь надо выставить конкретные потроха наружу. Но как только возникает вопрос о развитии или расширении (что будет, если я поставлю 3 АЛУ вместо 2?), кто будет переписывать программы под другой шедулинг и увеличенную ширину необходимого командного слова? А наоборот, что будет, если в пакете на исполнение послать 3 действия для АЛУ вместо 2, что на это скажут старые процессоры? IA-64 имел фиксированную ширину команды. Эльбрус-4 имеет нефиксированную пачку субкоманд и слово "commit" в конце, но пределы исполнения всё равно заданы. Можно ли исполнять команды быстрее, чем они поступают, и сколько блоков детекта потенциальных конфликтов потребуется для этого? Скорее всего, у Эльбруса крайне слабый шедулер, который тормозит по каждому чиху.
Вообще, VLIW в этом плане именно как ISA (а не как внутренние детали) выглядит крайне неудачно. И системы с трансляцией, как x86, и с прямым исполнением и минимумом OoO вроде переименования регистров, как быстрые версии современных RISC, его обгоняют. Он оказался как фиксация на машинном коде устаревшего компьютера вместо переносимого языка хотя бы уровня Паскаля.