Вот вы тут много замысловатых примеров привели..
Я в них мало что понимаю, но дагадываюсь, что в каждом конкретном случае будет свой критерий оптимальности

Я упомянул только о примерах, где может потребоваться разложение в степенной ряд и притом не будет скорость обращения к памяти припятствие .
Итак
1. Выдача на печать. Представим сервер с высокоскоростной оптико-волоконной линией в сетке сотня - другая клиентов дающих запросы на рассчёт каких-то данных. Сервер должен быстро провести рассчёты и выдать на передачу данные в преобразованном виде по сетке, чтобы после получения их клиентом ему нужно было лишь послать их на свой клиентский принтер. В данном случае серверу нет необходимости ждать принтер - он его не тормозит, в сети сотни принтеров ждущих лишь переданный символьный файл. А вот создать в памяти такой файл т.е. произвести вычисления и привести их к символьному виду - задача сервера.
2. Картежи. Допустим существует набор из десяти элементов
каждый из которого может быть одного из десяти цветов.
Данные представляют собой массу таких наборов (вместо одного из десяти цветов может быть один из военных объектов одного из десяти типов или типов может быть больше меньше)
Это то же что и число в котором десять разрядом в каждом из которых может быть одна из десяти возможных цифр. Если ты будешь хранить такие данные в фиксированном колличестве бит на каждый разряд (например как BCD) то уйдёт у тебя по 4е бита на разряд минимум (а если их не десять а пять?)
т.е. 5 байт на набор картежей. Однако ты можешь хранить их в бинарном виде как число и раскладывать когда надо.
При этом разложенный в ряд набор возможно ввовсе не нужен будет для вывода на экран, принтер и т.п. он может быть нужет для отправки управляющих сигналов, вычисления местоположения, ситуации и т.п. Т.е. не будет никакого фактора "торможения".
3. В криптографии ты можешь по разложенному ряду определить делимость на определённые числа без деления, и бывает проще разложить на степени какой-то большой базы провести сложение и потом лишь проверку на делимость чем делить какое то огромное число.
Во всех этих случаях нет никакого торможения со стороны памяти или других операций. Во всех них чем быстрее ты разложишь - тем лучше.

The Svin

Ну вот.. Я и писал, почему с новым программным обеспечением.
Потому что пишется оно так, что не учитываются особенности работы с кешем / памятью.

И старое программное обеспечение не обязательно будет быстрее работать.
Если это, скажем, подсчет суммы всех байтов оперативной памяти, то от частоты процессора оно будет слабо зависить.
Если память как работала на одной частоте, так и продолжает работать при новом процессоре.
А мегагерцы - это для маркетинга хорошо подходит.

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

Про то, что я кого-то "отнимаю кэш.
Такой надуманный пример: в системе есть всего 2 подпрограммы, которые что-то там делают по очереди.
Код одной весит, скажем 2Мб, а 2й - 8 Кб.
Ясно, что после исполнения первой, кода 2й в кеше ни как не может быть.
А вот если первая весит тоже 8 Кб? Тогда, разумеется они обе будут сидеть в кеше и не мешать друг другу :)
Так же и с данными. Конечно я тут сильно утрирую, и учитывая многозадачность и т.п. влияние этого фактора небольшое.
Но оно зависит от контекста.


Что я хотел сказать, так это то что оптимизация - палка о двух концах.
Можно оптимизировать в 2 раза по скорости код, который в скорости не нуждается. Но его размер при этом увеличится в 20 раз.
А если знать реальные условия где он будет работать, то логичнее будет его оптимизировать по размеру.

А если эти условия не знать, то как тогда оптимизировать?
Может быть, оптимально написать интерпретатор какой-нибудь будет. Производители новых процессоров только спасибо скажут.

The Svin

Мне даже как-то неудобно, что заставил вас клаву топтать приводя мне все эти примеры ^^
(но по серверу я всеже думаю, что PCI шина медленнее чем память работает. Даже PCI 66.)

И кстати - вот это всё конкретные примеры, а первоначально какой был?
Просто оптимизация. Тут вон человек 5й раз спрашивает про Понятия Оптимизации

Мне вообще слово "оптимизация" не очень нравится приминительно к улучшению качества программ.
Как будто происходит исскуственное противопоставление между неким "обычным" кодом, и неким "оптимальным".
Причём под "обычным" имеется ввиду более понятный а "оптимальный" пусть быстрее или короче но путанней.
Это всё притянуто за уши.
Для того кто не помнит основное правило пропорции может показаться что
if a/b==c/d
более понятно чем когда нужно сравнить два отношения
if a*d==b*c
однако, для того кто помнит эквивалентность обоих условий понятна, и одинакова проста как понятно и то что проверка во втором варианте будет ~ в четыре раза быстрее.
Другой пример, мой тесть - программёр старой школы не заставший даже ассемблера не то что x86, говорил что программы следует упрощать и сокращать (читай в нашем понятии это эквивалентно оптимизации по скорости и размеру) потому, что они не только начинают занимать меньше памяти и выполнятся быстрее но и понимаются легче потому как меньше размером. Бывают конечно и обратные примеры, но мне хотелось привести этот так как часто под оптимизацией понимают разные трюки которые усложняют восприятие, а это ведь очень часто не одно и тоже.
Оптимизации в смысле различных соревнований интересна как игра где ищется любая щель и возможность выиграть байт или такт но программировать так невозможно. Поэтому я думаю нужно не оптимизировать учится а изучать и изобретать различные варианты рассчётов и мат. моделей. При этом главная задача - понимать их. Тогда написание эффективных программ не превращается в тяжкий труд по оптимизации каждой строчки, а просто на основе багажа, зная как по разному можно сделать одно и тоже - выбираешь из имеющегося наиболее эффективный. Тогда оптимизация - это выбор из уже наработанного знакомого, а не тяжкий труд и изобретательство над каждым байтом. И ты изучаешь не трюки - ты рассматриваешь и изучаешь РАЗНЫЕ ВАРИАНТЫ.
Я вообще торчу когда смотрю как разные логические приёмы в арифметике вызывают у некоторых трепетное чувство супертрюка. Ясно что чувство это вызвано не сложностью приёма а отсутсвием у объекта знакомства с азами мат. логики в частности тавтологиий. Как только распишешь по шагам почему так получается - налёт мистичности пропадает а человек уже на основании ЗНАНИЙ а не передираний из всяких док по "оптимизации" создаёт с лёгкостью свои подобные трюки. Раньше оптимизацией называли обычно "подгонку" уже выбранного алгоритма под наиболее эффективную программную модель для конкретного процессора.
Сейчас вообще называют этим словом всё подряд.
Меня лично коробит когда например предлогаешь использовать определённую последовательность бинарных масок и это называют оптимизацией хотя сам этот арифметико-логический приём был известен со времён DEC и подходит для любой машины с данными в дополнительном коде. Вот знание строения modrm и использование этого знания для того чтобы адресная часть команды была покороче не в ущерб скорости - это оптимизация с моей точки зрения, или знание расширения знакового байта и замена
add eax,128
на
sub eax,-128 что позволяет сократить 3и байта без ущерба скорости - тоже оптимизация. А применение математики - какая это оптимизация, это просто выбор наиболее эффективного алгоритма расчёта. Вот.

The Svin
> замена
add eax,128
на
sub eax,-128 что позволяет сократить 3и байта

Почему 3-и, если 2-а получается?

ADD EAX,128 (5 байт)
SUB EAX,-128 (3 байта)

Такой надуманный пример: в системе есть всего 2 подпрограммы, которые что-то там делают по очереди.
Код одной весит, скажем 2Мб, а 2й - 8 Кб
1. У кода и данных раздельный кеш.
2. Речь идёт о том что выполняется обработка большого потока данных и если ты в ускоряешь с 400 тактов до 74 при выполнении длительной операции на один вызов то 4 кб кеша - очень малая плата за это.

Вариант с сетевухой я написал просто как пример, показывающий, что порой смысла нет оптимизировать по скорости.
И если синхронный код и если асинхронный - в любом случае есть. Быстрое выполнение и в Африке быстрое - ты либо быстро завершаешь задачу, либо часть задачи, либо освобождаешь время процессора под другие задачи. Это очень простая арифметика.
Другое дело - я согласен что если всего делов то выполнить простой расчёт и показать результат, то если на то чтобы выполнить такой расчёт (одноразовый) на несколько тактов быстрее тратится по туче кб в бинарнике - это маразм.
Например в простых утилитах которые я постил я не тратил байт на оптимизацию того, чтобы какой-то код которому сейчас нужно 100я тактов на завершение своей работы стал быстрее тактов на 20 но для этого нужно было бы сделать его подлинее. Такие утилитки должны прежде всего быстро загружаться и быстро выгружаться, поэтому обычно оптимизированны по размеру и эффективность по скорости принималось в учёт в их архитектуре если не вела к увеличению размера. Тем не менее они всё одно быстрые и я видел как подобные же по сложности прожки и жирнее и так тормозят, что понимаешь, что предела человеческой распущенности просто нет, вот предел эффективности есть - а тормознутось стремится к плюс бесконечности.

Asterix
Ну ты разные форматы сравниваешь. Для add eax,imm32 есть отдельный код без modrm. Замени eax на ecx и станет понятно.
Мысль была простая - в одном случае длина кода на непосредственный операнд 4е байта в другом 1.
Я могу привести пример с add eax,128 в 6 байт.

All
А как насчёт старого доброго fild fbstp ?

The Svin

После исправлений алгоритм выполняется:
Celeron 2,6 GHz WinXP
без таблицы:240-250
с таблицей :190-205
P4 3,0 GHz WIn2003 Server
без таблицы:243-245
с таблицей :193-196
Тестировал твой программой:
Дома на AthlonXP 2500+ Barton
без таблицы:105-110
с таблицей :72-75
Вообще для использования я выбрал свой он поменьше.
Спасибо за помощь а алгоритм мне был нужен для моей игры хотя там переводов и не много хочется чтобы было по быстрей


1793715693__3243248358.rar

Молодец что сообщил результаты.
Данные интересные. Теперь мы начинаем говорить на общем языке :)

[ The Svin : У кода и данных раздельный кеш. ]

Это верно, но что это меняет в принципе?
Помимо этого кеш L2 - общий.


> Быстрое выполнение и в Африке быстрое

Пусть у меня есть надуманный сервер, где работает только 20 процессов.
Каждый из них весит, скажем 8К.
Понятно, что все вместе они весят 20*8=160К, что позволяет им спокойно работать в 256К кеше вашего Coppermine.
Теперь кто-то оптимизировал все модули по скорости в 2 раза, но размер каждого можуля также увеличился в 2 раза.

Что же будет теперь?
Код весит 20*16=320Кб. Это уже больше чем может поместиться в кеш!
То есть, код и/или данные будут регулярно читаться из памяти, скорость работы которой 133МГц, что в 4,5 раза меньше, чем у кеша.
Думаю понятно, что ожидать 2х кратного прироста скорости в этом случае не сОит.


[ Evg666 : лгоритм мне был нужен для моей игры ]

Ну вот. А не лучше ли в таком случае просто хранить числа в ASCII формате, и работать с ними в BCD?
Тут ни умножений, ни делений :)


ЗЫ

The Svin
Вы работали на DEC? Именно у них использовалась восьмеричная система, очень наглядно показывающая строение опкода.
У других архитектур (8080, 6502, 6800) принято было использовать HEX, что сильно запутывало и запутывает.

А можете объяснить почему у меня на Athlon2400XP (Win XP) каждый раз настолько разные результаты :
1.
без таблицы: 72
с таблицей 110
2.
без таблицы: 422
с таблицей 103
3.
без таблицы: 72
с таблицей 511
4.
без таблицы: 444
с таблицей 105
?

Уменьшить колличество самплингов. Идиотский менеджер. памяти видимо. Очевидно что вообще сливает страницу в свап И к тому же первый результат - с таблицей а не наоборот. Ты перепутал.