Лингвофорум

Int to String в куче итераций:

Первый пришедший в голову вариант:
  char buff[32];
  sprintf(buff, "%d", self);
1340 мс

Вторый пришедший в голову вариант через не везде имеющуюся функцию itoa:
  char buff[32];
  itoa(self, buff, 10);
970 мс

Немного подумав:
    char buff[16];
    char* ptr = buff + 15;

    bool neg = (n < 0);

    if(neg)
        n = -n;

    *ptr-- = 0;

    do
    {
        *ptr-- = (n % 10) + '0';
        n /= 10;
    }
    while(n);

    if(neg)
        *ptr-- = '-';

char* result = ++ptr;
930-950 мс

Развернул цикл в предыдущем примере в goto'ы:
   again:
    {
        *ptr-- = (n % 10) + '0';
        n /= 10;
    }
    if(n)
        goto again;
900-920 мс


Как бы ещё ускориться...

Да, туповато вышло. Перепутал местами всего-то false и true, а вышло так драматично (замена o->x < 30 на o->x абсолютно ничего не изменила).

Но я не унываю, потому что с учётом исправлений в среднем у меня выходит так:

ЦитироватьPolymorph.: 10140 ms
Plain code: 10219 ms

Тем более что тест не то, чтобы тщательно продуманный, так, эссэ.
Теоретически единственный оверхед — маппинг нужной функции + последующий дереференсинг функции каждый раз. Если есть возможность таким методом вырезать нечто, куда большее по трудозатратом, чем это - оно оправдано (правда, надо посмотреть скорость маппинга для 40 полей... ужость. Слава богу что он происходит только раз, при записи, а не при чтении).

Хм, я этого и боялся. Посмотрим.

Зато знаю теперь, что хоть кто-то сомтрит вложения Ж)

Алексей, у вас пример с грубыми ощибками.
1) Почему-то у вас в функции  rfc_func_variant_yesX_noZ стоит условие if(o->x < 30) вместо if(o->x) как в основной функции. С учётом того, что x вы ставите в 100, это имеет значение.
2) Но эта функция у вас даже и не вызывается из-за другой ошибки. В "мегапродвинутом" варианте вы вызываете map_rfc_func(false, true) вместо map_rfc_func(true, false). Тем самым, хотя вы обнуляете z, но не x, вызывается функция rfc_func_variant_noX_yesZ.

Исправьте ошибки и замерьте время заново. Результаты вас удивят. 

Шустрый. Но огромный количеством -- именно за счет фабрик, взаимосвязей, переходников и пр.

Цитата: oort от июля 27, 2009, 11:54
А если еще учесть чуть ли не тот же экспоненциальный рост кода при простом использовании ООП...

В смысле кода — исходного или бинарного?
В смысле писанины букв руками чрезмерное увлечение ООПом приводит к огромному количеству бессмысленных интерфейсов, фабрик, взаимосвязей и т. д.
В смысле генерируемого кода, С++-таки генерит очень шустрый код.

А если еще учесть чуть ли не тот же экспоненциальный рост кода при простом использовании ООП... В общем, если программа влезет в память, она будет выполняться быстро.

Цитата: oort от июля 27, 2009, 10:59
Да, это, разумеется, не так удобно, как при реализации этой идеи в компиляторе.

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

Тут же опущение кода по проверке на булевость — лишь одна десятая того, что ещё можно замутить на такой концепции Правда, размер бинарников будет экспоненциально-геометрически расти (и тут хопа! - нам какбэ говорят джиттеры упакованных синтаксических деревьев )

Цитата: Алексей Гринь от июля 27, 2009, 10:19

Цитата: oort от июля 26, 2009, 12:27
На языках с хорошим препроцессором это пишется довольно легко. Для языков с плохим препроцессорм, типа сей, можно написать маленький препроцессор на каком-нибудь легком языке. Что-нибудь типа

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

Маленький препроцессор на перле, который добавит #for к сишному препроцессору, мне кажется, много времени не займет. А это все, что нужно. С помощью этого препроцессора пишется `проверочно-зависимый' код, в который проверки, благодаря препроцессору, вставляются без дублирования полезного кода. Да, реальную реал-таймовую проверку придется писать руками. Две переменные. Одна поднимается при любом изменении второй, вторая когда нужно. Если поднята первая переменная, переназначаем полиморфную функцию и опускаем первую переменную.

Да, это, разумеется, не так удобно, как при реализации этой идеи в компиляторе. Когда компиляторы начнут ее поддерживать, такие извращения станут не нужны.

Цитата: oort от июля 26, 2009, 12:27
На языках с хорошим препроцессором это пишется довольно легко. Для языков с плохим препроцессорм, типа сей, можно написать маленький препроцессор на каком-нибудь легком языке. Что-нибудь типа

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