Оптимизация для интерпретатора brainfuck

Ну, это не С. И это не является переводчиком. Так что, да, это совершенно неуместный вопрос.

но что это такое, это идеально портативный компилятор brainfuck, использующий C++0x variadic шаблоны. Вы должны #define PROGRAM как последовательность символов c-синтаксиса, разделенных запятыми, потому что я не мог извлечь их из строки во время компиляции. Но в остальном это законно. Я думаю.

протестировано с g++ 4.5.2, используя g++ -std=c++0x -O2 -Wall.

#include <cstdio>
#include <vector>

#define PROGRAM '+', '+', '+', '+', '+', '+', '+', '+', '[', '-', '>',  \
        '-', '[', '-', '>', '-', '[', '-', '>', '-', '[', '-', ']', '<', \
        ']', '<', ']', '<', ']', '>', '+', '+', '+', '+', '+', '+', '+', \
        '+', '[', '<', '+', '+', '+', '+', '+', '+', '+', '+', '+', '+', \
        '>', '-', ']', '<', '[', '>', '+', '>', '+', '<', '<', '-', ']', \
        '>', '-', '.', '>', '-', '-', '-', '-', '-', '.', '>'

template<char... all>
struct C;

template<char... rest>
struct C<'>', rest...> {
    typedef C<rest...> rest_t;
    typedef typename rest_t::remainder remainder;
    static char *body(char *p) {
        return rest_t::body(p+1);
    }
};

template<char... rest>
struct C<'<', rest...> {
    typedef C<rest...> rest_t;
    typedef typename rest_t::remainder remainder;
    static char *body(char *p) {
        return rest_t::body(p-1);
    }
};

template<char... rest>
struct C<'+', rest...> {
    typedef C<rest...> rest_t;
    typedef typename rest_t::remainder remainder;
    static char *body(char *p) {
        ++*p;
        return rest_t::body(p);
    }
};


template<char... rest>
struct C<'-', rest...> {
    typedef C<rest...> rest_t;
    typedef typename rest_t::remainder remainder;
    static char *body(char *p) {
        --*p;
        return rest_t::body(p);
    }
};

template<char... rest>
struct C<'.', rest...> {
    typedef C<rest...> rest_t;
    typedef typename rest_t::remainder remainder;
    static char *body(char *p) {
        putchar(*p);
        return rest_t::body(p);
    }
};

template<char... rest>
struct C<',', rest...> {
    typedef C<rest...> rest_t;
    typedef typename rest_t::remainder remainder;
    static char *body(char *p) {
        *p = getchar();
        return rest_t::body(p);
    }
};

template<char... rest>
struct C<'[', rest...> {
    typedef C<rest...> rest_t;
    typedef typename rest_t::remainder::remainder remainder;
    static char *body(char *p) {
        while (*p) {
            p = rest_t::body(p);
        }
        return rest_t::remainder::body(p);
    }
};


template<char... rest>
struct C<']', rest...> {
    typedef C<rest...> rest_t;
    struct remainder_hack {
        typedef typename rest_t::remainder remainder;
        static char *body(char *p) {
            return rest_t::body(p);
        }
    };
    typedef remainder_hack remainder;
    static char *body(char *p) {
        return p;
    }
};

template<>
struct C<> {
    static char *body(char *p) {
        return p;
    }
    struct remainder {
        static char *body(char *p) {
            return p;
        }
    };
};

int
main(int argc, char *argv[])
{
    std::vector<char> v(30000, 0);
    C<PROGRAM> thing;

    thing.body(&v[0]);
    return 0;
}

поскольку весь смысл этого проекта заключается в обучении, использование инструмента или заменяющего решения явно не отвечает на вопрос.

во-первых, отказ от ответственности: я не программист x86-я сделал приличный объем работы во встроенных средах и теперь (с мобильными телефонами) чипы ARM. Перейдем к хорошему...

есть два основных способа сделать ваш интерпретатор быстрее: Сделайте это оптимизировать сам код BF, и сделать сам интерпретатор оптимизирован. Я рекомендую понемногу в один шаг ниже.

насколько я знаю, x86 тратит много пространства краски на обеспечение относительно впечатляющих быстрых ветвящихся свойств. Вероятно, из-за этого я видел, как несколько компиляторов (включая gcc) создают вложенные ветви в пользу фактических таблиц перехода для x86. Таблицы перехода звучат привлекательно в теории, но на самом деле x86 оптимизирует так хорошо для устаревших методов, что обычное мышление big-O просто не применяется в большинстве случаев. Вот почему долгосрочные разработчики x86 расскажут вы, если вы хотите рассчитать, как быстро код, то вам нужно написать его, запустить его и время его.

несмотря на скорость, с которой ветви могут возникать на x86, по-прежнему, вероятно, стоит потратить немного накладных расходов на не ветвление. Поскольку инструкции BF так просты в любом случае, это может принять форму "сделать большинство инструкций сразу, так как это быстрее, чем другая ветвь."Некоторые из них могут даже выполняться параллельно процессором, где ветвление не может быть. (x86 имеет достаточно декодирования и единицы исполнения в одном ядре такие, что это, вероятно, возможно)

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

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

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

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

рассмотрим Java: Java не интерпретирует. Он JITs в совершенно разных языка.

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

Я рекомендую создать инструкцию со следующей информацией:

• сумма, чтобы добавить к значению at указатель данных (или вычесть -- вычитание просто добавляет отрицательное число)
• сумма, чтобы добавить к значению of указатель данных (или вычесть)
• указатель на следующую инструкцию для выполнения
• значение по сравнению со значением в ячейке до он изменен

цикл интерпретатора затем изменяется на логику следующим образом: добавьте значение данных в инструкции к значению в указателе данных добавить данные адрес значение в инструкции к самому указателю данных если значение в ячейке совпадает с нашим значением сравнения установите указатель инструкции на новый указатель инструкции продолжить (к следующему циклу интерпретатора) если значение сравнения является специальным значением (например, вы можете выбрать 0x80000000) ручка ввода/вывода питания увеличить адрес инструкции на единицу

первоначальная интерпретация становится сложнее: Инструкции теперь могут объединять +, -,, а иногда даже [, и обычно ] в одну и ту же инструкцию. Первая ветвь в цикле может быть представлена без ветвления, если вы умны в этом (и даже больше эффективно с некоторой сборкой, застрявшей в или некоторых встроенных компиляторах). Возможно, вы захотите сообщить компилятору, что вторая ветвь вряд ли попадет (в этом случае узким местом является ввод/вывод, а не скорость интерпретации, поэтому, даже если вы делаете много ввода/вывода, одна маленькая неоптимизированная ветвь не будет иметь значения).

необходимо позаботиться Для условия конц -- хода. Последняя инструкция в вашей интерпретируемой программе BF теперь всегда должна делать инструкцию указатель NULL, поэтому цикл завершается.

порядок, в котором происходит интерпретация, важен, потому что -/+ выполняется до выполняется до [ выполняется до ] выполняется до ввода-вывода.Итак, > + - это две интерпретируемые инструкции, а + > - одна.

помимо разработки быстрого узкополосного интерпретатора, подобного этому, вы смотрите на более сложный анализ кода, и в этом случае вы попадете в дизайн компилятора и меньше от прямого интерпретатора. Это не то, что я делаю каждый день, но книга Лоудена "конструкция компилятора"была очень хорошей для меня, но это не будет маленьким проектом. Если вы не серьезно относитесь к тому, чтобы сделать эту вещь смехотворно быстрой и, в конце концов, вероятно, скомпилированный код, я бы держался подальше от больших, жестких оптимизаций.

Я надеюсь, что я дал вам идею попробовать и проверить, что приводит вас к более шагам оптимизации. Я не пробовал ничего из этого сам, так что это все еще гипотеза, основанная на прошлом опыте. Однако, даже если это не будет быстрее, вы получите некоторый опыт в переписывании кода BF на относительно другую архитектуру от интерпретатора vanilla BF.

П. С. большой вопрос!

Brainfuck должен быть довольно легко скомпилирован в код C, который затем компилируется и выполняется. Это, вероятно, будет очень быстрый Bf "переводчик".

принципиально все, что вам нужно сделать, это создать довольно тривиальный код для каждого оператора brainfuck слева направо в программе. Можно легко оптимизировать последовательности + и -; аналогично, можно оптимизировать последовательности , кэшируя подсчеты каждого из последних встречающийся. Это своего рода глазок оптимизация.

вот компилятор проекта, принимающий код BF в командной строке и печать скомпилированной программы на консоль:

int increments;  // holds pending increment operations

void flush_increments(){
   if (increments==0) return;
   printf("  *ptr+=%d;\n",increments);
   increments=0;
}

int steps; // holds pending pointer steps

void flush_steps(){
   if (steps==0) return;
   printf("  ptr+=%d;\n",steps);
   steps=0;
}

int main(int argc, char **argv){
    // Brainfuck compiler
    if( !(argc > 1) )
        return 1;
    unsigned char *code = argv[1];
    int nesting=0;
    printf("int main(){\n");
    printf("  #define CELLSPACE 1000\n");
    printf("  unsigned char *ptr = malloc(sizeof(char)*CELLSPACE);\n");
    printf("  if(ptr == NULL) return 1;\n")
    printf("  for(int i=0;i<CELLSPACED;i++) ptr[i]=0; // reset cell space to zeros");
    increments=0;
    steps=0;
    for(;;) {
        switch(*code++) {
            case '+':
                flush_steps();
                ++increments;
                break;
            case '-':
                flush_steps();
                --increments;
                break;
            case '>':
                flush_increments();
                ++steps;
                break;
            case '<':
                flush_increments();
                --steps;
                break;
            case '[':
                flush_increments();
                flush_steps();
                printf("while(*ptr){");
                ++nesting;
                break;
            case ']': 
                flush_increments();
                flush_steps();
                if (--nesting<0)
                   { printf("Unmatched ']'\n");
                     return 1;
                   }
                printf("}\n";);
                break;
            case '.':
                flush_increments();
                flush_steps();
                printf(" putc(*ptr, stdout);\n");
                break;
            case ',':
                increments=0;
                flush_steps();
                printf("*ptr = getc(stdin);");
                break;
            case '':
                 printf("}");
                 if (nesting>0)
                   { printf("Unmatched '['\n");
                     return 1;
                   }
                return 0;
        }
    }
}

Это набирается с верхней части моей головы, вдохновленный кодом Мэтью Бланчарда (спасибо Мэтью!), но не проверял. Я оставлю это какой-нибудь другой душе; не стесняйтесь исправлять код если обнаружите проблему. Очевидно, было бы лучше, если бы он написал свой код в файл : -}

[я использовал http://en.wikipedia.org/wiki/Brainfuck статья как очевидное вдохновение для создания кода].

программа BF OP:

++++++++[->-[->-[->-[-]++++++++[-]+>+-.>-----.>

следует скомпилировать в (добавлен отступ):

 int main(){
 #define CELLSPACE 1000
   unsigned char *ptr = malloc(sizeof(char)*CELLSPACE);
   if(ptr == NULL) return 1;
   for(int i=0;i<CELLSPACED;i++) ptr[i]=0; // reset cell space to zeros
   *ptr+=8;
   while(*ptr) {
      *ptr+=-1;
      ptr+=1;
      *ptr+=-1;
     while(*ptr) {
       *ptr+=-1;
       ptr+=1;
       *ptr+=-1;
       while(*ptr) {
         *ptr+=-1;
         ptr+=1;
         *ptr+=-1;
         while(*ptr) {
            *ptr+=-1;
         }
         ptr+=-1;
       }
       ptr+=-1;
     }
     ptr+=1;
     *ptr+=8;
     while (*ptr) {
        ptr+=-1;
        *ptr+=10;
        ptr+=1;
        *ptr+=-1;
     }
     ptr+=-1;
     while (*ptr) {
        ptr+=1;
        *ptr+=1;
        ptr+=1;
        *ptr+=1;
        ptr+=-2;
        *ptr+=-1;
     }
     ptr+=1;
     *ptr+=-1;
     putc(*ptr,stdout);
     ptr+=1;
     *ptr+=-5;
     putc(*ptr,stdout);
     ptr+=1;
 }

это, вероятно, в среднем довольно близко к одной машинной инструкции на Bf op.

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

Если вы действительно хотели сходить с ума, вы могли бы выяснить, что делают команды BF до первого входного запроса; это должна быть "постоянная" начальная конфигурация памяти, и генерировать intializer CELLSPACE с этой константой и генерировать код для остальной части программы, как я показал. Если вы это сделали, пример OP программа исчезнет в один cellspace initialzer и несколько вызовов putc.

используйте инфраструктуру LLVM JIT и оптимизируйте код для вас...

edit: на самом деле это уже было сделано несколько раз; компилятор:http://www.remcobloemen.nl/2010/02/brainfuck-using-llvm/ JIT:https://github.com/resistor/BrainFTracing (Обратите внимание, как "компилятор" имеет длину 230 строк, считая также пустые строки, комментарии и #includes)

edit2: для downvoter: поскольку вы, похоже, пропустили его, значение моего ответ был "не изобретай колесо"

Я бы увидел несколько вещей.

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

у вас слишком много косвенных ответов. Например, ваш индекс ci не служить. Иметь указатель, указывающий на фактическую ячейку. Это позволяет сохранить регистр. Вы можете сделать подобное с ii. Вместо того, чтобы сохранять номер инструкции, просто наведите указатель на позицию в cm.

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

вот пример того, как вы можете сделать быстрый интерпретатор BF:

int main(int argc, char **argv)
{
    if( !(argc > 1) )
        return 1;
    unsigned char *progmem = argv[1];
    unsigned char *cellmem = malloc(sizeof(char)*CELLSPACE);
    if(cellmem == NULL)
        return 1; 
    unsigned char **loopdepth = malloc(sizeof(char*)*MAXLOOPDEPTH);
    if(loopdepth == NULL)
        return 1;

    unsigned char *origcellmem = cellmem;
    unsigned char **origloopdepth = loopdepth;

    for(;;)
    {
        switch(*progmem)
        {
            case '+':
                ++*cellmem;
                break;
            case '-':
                --*cellmem;
                break;
            case '>':
                cellmem++;
                break;
            case '<':
                cellmem--;
                break;
            case '[':
                *loopdepth = progmem-1;
                loopdepth++;
                break;
            case ']':
                loopdepth--;
                if(*cellmem)
                {
                    progmem = *loopdepth;
                }
                break;
            case '.':
                putc(*cellmem, stdout);
                break;
            case ',':
                *cellmem = getc(stdin);
                break;
            case '':
                free(origcellmem);
                free(origloopdepth);
                return 0;
        }
        progmem++;
    }
}

Так, основные моменты моего кода, которые должны сделать его быстрее, чем ваше решение:

Я не делаю никакой проверки каждого цикла, компилятор, вероятно, сгенерирует необработанный безусловный цикл здесь(или так мне говорят мастера C.) И поскольку я использую необработанные данные из строки вместо структур, мне просто нужно поставить "\0 " в конце переключателя! Это означает единственный раз, когда мой переводчик проверяет если ему нужно закончить программу, когда ничто другое не соответствует коммутатору.

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

Я использую простой "стек" для хранения циклов, это ограничивает максимальную глубину циклов, которые вы можете иметь, но 32 достаточно для большинства brainfuck программы, и он регулируем в источнике.

Я заказал случай переключателя для того, как часто появляются вещи, видя, как + и - являются наиболее распространенными символами brainfuck, а затем > и

Я не делаю никакой проверки ошибок, я предполагаю, что ввод пользователя идеален. Хотя это может не дать хороших ошибок, таких как запуск границы и тому подобное, это именно то, что языки делают во время выполнения, программа C может легко генерировать segfault, мы, вероятно,- не должны - проверять их. (Быстрая заметка, моя сгенерировала много segfaults при написании этого: P)

и, наконец, одна возможная оптимизация, о которой я подумал:

выполнить кодировку длины, как при сжатии. Вы можете запустить кодирование длины brainfuck в простом формате, так что: + + + превращается в 3+, а интерпретатор "получает" его и вместо добавления одного три раз, он добавляет три один раз. Прирост производительности здесь может быть удивительным в некоторых местах