LINUX.ORG.RU

История изменений

Исправление www_linux_org_ru, (текущая версия) :

WTF am I reading?

ну сходи что ли на http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=... — там питон жрет до 9×

Накладные расходы интерпретатора - это регистры ВМ, подпрограммы реализации команд ВМ, и цикл интерпретации (для стековой ВМ или AST-интерпретатора всё сложнее, но накладные расходы всё равно фиксированные).

append, массив... каким образом в этом замешана интерпретация?

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

вот грубо говоря как устроен массив неизвестной длины приемлемой производительности:

struct Array {
  Element* first_element;
  Element* after_last_element;
  Element* after_end_of_allocated_space;
};

если твой транслятор будет генерить целевой код, в котором AST «интерпретируется», но при этом на основе предваритального анализа в период трансляции устанавливается, что некоторые массивы имеют константную длину, меньшую 8, и в памяти рантайма эти массивы выглядят так:

class SpecializedArrayWithoutAppend {
public:
  Element* first_element() { return address & 0xFFFFFFF8; }
  Element* after_last_element() { return first_element() + (address & 7); }
private:
  uint address;
};

то твой транслятор проводит специализацию, и частично является компилятором

в этом случае твою «интерпретацию» AST на самом деле чистой интерпретацией назвать нельзя, а лучше было бы назвать только исполнением AST, т.к. если во время исполнения программы вместо одной из ветвей AST дебаггером злобно подставить такую, где в SpecializedArrayWithoutAppend происходит таки добавление в конец массива, который и так уже 7 элементов, то программа начнет функционировать неверно

и наконец — современные компиляторы с++ в этом аспекте ((не)умение специализировать) ближе к интерпретаторам, чем к компиляторам, гы-гы

Исправление www_linux_org_ru, :

WTF am I reading?

ну сходи что ли на http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=... — там питон жрет до 9×

Накладные расходы интерпретатора - это регистры ВМ, подпрограммы реализации команд ВМ, и цикл интерпретации (для стековой ВМ или AST-интерпретатора всё сложнее, но накладные расходы всё равно фиксированные).

append, массив... каким образом в этом замешана интерпретация?

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

вот грубо говоря как устроен массив неизвестной длины приемлемой производительности:

struct Array {
  Element* first_element;
  Element* after_last_element;
  Element* after_end_of_allocated_space;
};

если твой транслятор будет генерить целевой код, в котором AST «интерпретируется», но при этом на основе предваритального анализа в период трансляции устанавливается, что некоторые массивы имеют константную длину, меньшую 8, и в памяти рантайма эти массивы выглядят так:

class SpecializedArrayWithoutAppend {
public:
  Element* first_element() { return address & 0xFFFFFFF8; }
  Element* after_last_element() { return first_element() + (address & 7); }
private:
  uint address;
};

то твой транслятор проводит специализацию, и частично является компилятором

в этом случае твою «интерпретацию» AST на самом деле интерпретацией назвать нельзя, а можно назвать только исполнением AST, т.к. если во время исполнения программы вместо одной из ветвей AST дебаггером злобно подставить такую, где в SpecializedArrayWithoutAppend происходит таки добавление в конец массива, который и так уже 7 элементов, то программа начнет функционировать неверно

и наконец — современные компиляторы с++ в этом аспекте ((не)умение специализировать) ближе к интерпретаторам, чем к компиляторам, гы-гы

Исправление www_linux_org_ru, :

WTF am I reading?

ну сходи что ли на http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=... — там питон жрет до 9×

Накладные расходы интерпретатора - это регистры ВМ, подпрограммы реализации команд ВМ, и цикл интерпретации (для стековой ВМ или AST-интерпретатора всё сложнее, но накладные расходы всё равно фиксированные).

append, массив... каким образом в этом замешана интерпретация?

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

вот грубо говоря как устроен массив неизвестной длины приемлемой производительности:

struct Array {
  Element* first_element;
  Element* after_last_element;
  Element* after_end_of_allocated_space;
};

если твой транслятор будет генерить целевой код, в котором AST «интерпретируется», но при этом на основе предваритального анализа в период трансляции устанавливается, что некоторые массивы имеют константную длину, меньшую 8, и в памяти рантайма эти массивы выглядят так:

class SpecializedArrayWithoutAppend {
public:
  Element* first_element() { return address & 0xFFFFFFF8; }
  Element* after_last_element() { return first_element() + (a & 7); }
private:
  uint address;
};

то твой транслятор проводит специализацию, и частично является компилятором

в этом случае твою «интерпретацию» AST на самом деле интерпретацией назвать нельзя, а можно назвать только исполнением AST, т.к. если во время исполнения программы вместо одной из ветвей AST дебаггером злобно подставить такую, где в SpecializedArrayWithoutAppend происходит таки добавление в конец массива, который и так уже 7 элементов, то программа начнет функционировать неверно

и наконец — современные компиляторы с++ в этом аспекте ((не)умение специализировать) ближе к интерпретаторам, чем к компиляторам, гы-гы

Исправление www_linux_org_ru, :

WTF am I reading?

ну сходи что ли на http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=... — там питон жрет до 9×

Накладные расходы интерпретатора - это регистры ВМ, подпрограммы реализации команд ВМ, и цикл интерпретации (для стековой ВМ или AST-интерпретатора всё сложнее, но накладные расходы всё равно фиксированные).

append, массив... каким образом в этом замешана интерпретация?

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

вот грубо говоря как устроен массив неизвестной длины приемлемой производительности:

struct Array {
  Element* first_element;
  Element* after_last_element;
  Element* after_end_of_allocated_space;
};

если твой транслятор будет генерить целевой код, в котором AST «интерпретируется», но при этом на основе предваритального анализа в период трансляции устанавливается, что некоторые массивы имеют константную длину, меньшую 8, и в памяти эти массивы выглядят так:

class SpecializedArrayWithoutAppend {
public:
  Element* first_element() { return address & 0xFFFFFFF8; }
  Element* after_last_element() { return first_element() + (a & 7); }
private:
  uint address;
};

то твой транслятор проводит специализацию, и частично является компилятором

в этом случае твою «интерпретацию» AST на самом деле интерпретацией назвать нельзя, а можно назвать только исполнением AST, т.к. если во время исполнения программы вместо одной из ветвей AST дебаггером злобно подставить такую, где в SpecializedArrayWithoutAppend происходит таки добавление в конец массива, который и так уже 7 элементов, то программа начнет функционировать неверно

и наконец — современные компиляторы с++ в этом аспекте ((не)умение специализировать) ближе к интерпретаторам, чем к компиляторам, гы-гы

Исправление www_linux_org_ru, :

WTF am I reading?

ну сходи что ли на http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=... — там питон жрет до 9×

Накладные расходы интерпретатора - это регистры ВМ, подпрограммы реализации команд ВМ, и цикл интерпретации (для стековой ВМ или AST-интерпретатора всё сложнее, но накладные расходы всё равно фиксированные).

append, массив... каким образом в этом замешана интерпретация?

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

вот грубо говоря как устроен массив неизвестной длины приемлемой производительности:

struct Array {
  Element* first_element;
  Element* after_last_element;
  Element* after_end_of_allocated_space;
};

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

class SpecializedArrayWithoutAppend {
public:
  Element* first_element() { return address & 0xFFFFFFF8; }
  Element* after_last_element() { return first_element() + (a & 7); }
private:
  uint address;
};

то твой транслятор проводит специализацию, и частично является компилятором

в этом случае твою «интерпретацию» AST на самом деле интерпретацией назвать нельзя, а можно назвать только исполнением AST, т.к. если во время исполнения программы вместо одной из ветвей AST дебаггером злобно подставить такую, где в SpecializedArrayWithoutAppend происходит таки добавление в конец массива, который и так уже 7 элементов, то программа начнет функционировать неверно

и наконец — современные компиляторы с++ в этом аспекте ((не)умение специализировать) ближе к интерпретаторам, чем к компиляторам, гы-гы

Исходная версия www_linux_org_ru, :

WTF am I reading?

ну сходи что ли на http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=... — там питон жрет до 9×

Накладные расходы интерпретатора - это регистры ВМ, подпрограммы реализации команд ВМ, и цикл интерпретации (для стековой ВМ или AST-интерпретатора всё сложнее, но накладные расходы всё равно фиксированные).

append, массив... каким образом в этом замешана интерпретация?

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

вот грубо говоря как устроен массив неизвестной длины приемлемой производительности:

struct Array {
  Element* first_element;
  Element* after_last_element;
  Element* after_end_of_allocated_space;
};

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

class SpecializedArrayWithoutAppend {
public:
  Element* first_element() { return address & 0xFFFFFFF8; }
  Element* after_last_element() { return first_element() + (a & 7); }
private:
  uint address;
};


то твой транслятор проводит специализацию, и частично является компилятором

в этом случае твою "интерпретацию" AST на самом деле интерпретацией назвать нельзя, а можно назвать только исполнением AST, т.к. если во время исполнения программы  вместо одной из ветвей AST дебаггером злобно подставить такую, где в SpecializedArrayWithoutAppend происходит таки добавление в конец массива, который и так уже 7 элементов, то программа начнет функционировать неверно

и наконец -- современные компиляторы с++ в этом аспекте ближе к интерпретаторам, чем к компиляторам, гы-гы