Мелкие задачки для крупных мозгов 9

Да здравствует 486 !

Забавно P4 работает... 16 тактов на CLC -- отличный результат; Intel, так держать! Их зае#ы с параллельностью до добра не доведут. Какое же интересно будет программирование на ассемблере ч/з n лет для IA-64... Тогда, наверное, будет популярен лозунг Size doesn't matter. Их параллельность сделала команды громоздкими.

И всё таки в весовой категории "минимальный размер" мой код весьма неплох. Да, кстати про судьбу старших битов в условии ничего не сказано. Предполагается, что после вызова выполняется test/bt для ветвления.

 

Не сорьтесь друзья

И size и speed matter.

Задачки (ответы) носят для меня академический интерес, т.е. я просто с удовольствием слежу за вашей мыслью, и даже в неэффективном решении могу обнаружить любопытные алгоритмические моменты.

Но сами задачки из моей реальной прошлой практики и size всегда там в основном имел значение каждый лишний килобайт мог очень удорожить проект, а speed местами имел такое критичное значение, что от него зависела чья-то жизнь.

(Маленькая проблема с людьми у которых проффесиональный уровень в низкоуровневом программировании а вот использование деятельности - любительская, что они с трудом могут оценить что главное в подобных проектах и смотрят на это как пользователи какой-нить Windows XP и с трудом понимают зачем тут дорожить каждым байтом или зачем нужна скорость если всё основное (по их заблуждению) будет делаться у нормальных (с их точки зрения) программистов с помощью каких-нить системных или сторонних библиотек.)

И размер и скорость имеют значение. Медалей у меня всё одно ненапечатано. Специализируйтесь на чём вам интересней, включая (наиболее интересно) компромиссные варианты. Но хотелось бы чтобы перед началом любой задачи шла хоть какая-то оценка вероятности входных данных.

 

The Svin

Дык никто и не спорит

Тут, как заметил _BC_, можно спорить только с Intel, которые с каждым новым семейством своих кирпичей приподносят сюрпризы для низкоуровневой оптимизации (достаточно взглянуть на вышеприведенную табличку).



Кстати, на тему забавности работы P4 или как Intel заботится о размере кода в L1:



Во что превращается наш оптимизированный по размеру код, когда попадает в кэш микроопераций P4 ? Intel на эту тему помалкивает, но любознательные исследователи типа А.Фога считают, что каждая микрооперация занимает не менее 36 бит (включая 16 бит данных), возможно больше. Поэтому даже однобайтная инструкция занимает в трэйс-кэше не менее 4(5) байт. В итоге размер кода в трэйс-кэше получается > числа инструкций*4. Сложные инструкции содержат 2-4 микрооперации (если больше, как например в ADC, то "остатки" извлекаются из микрокод-ROM - тут Intel'ы видимо подумали о небезграничности кэша L1). Вот и получается - если мы сэкономим несколько байт своего кода за счет использования сложных инструкций, то можем съесть намного больше места в кэше микроопераций.

В качестве упражнения можно подсчитать число хранимых микроопераций в оптимизированном и неоптимизированном вариантах рассматриваемой задачки (по данным А.Фога). В варианте _BC_ их получается 25-26, а в варианте leo - 22. Ну что ж, разница опять небольшая, значит и в этой номинации код _BC_ весьма неплох Но примечательно то, что исходные 30 байт кода из L2 "забавным" образом превращаются на P4 в 100-125 байт в L1, а выигрыш нескольких байт в L2 может обернуться проигрышем десятка-другого байт в L1. Вот такая забавная арифметика