LINUX.ORG.RU

Интерпретация, компиляция, а это что?

 ,


1

2

Если транслятор преобразовывает программу:

input i
let j = i * 2;
print j

в

#include "set_val.h"
hash vars;
int main()
{
   input("i");
   set("j", mult(val("i"), 2);
   print(val("j"));
}

где set, mult и val определены как

void set(char *key, variant & val)
{
   set_hash(vars, key, val);
}

variant val(char *key)
{
   return get_hash(vars, key);
}

variant mult(variant a, variant b)
{
   variant c;
   assert(a.type == NUMBER && b.type == NUMBER);
   c.type = NUMBER;
   c.number = a.number * b.number;
}

а затем при помощи gcc получает бинарник, то этот весь процесс является компиляцией или интерпретацией?

★★★★★

Последнее исправление: maxcom (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

так ты изложи свои возражения

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

не стесняйся

И не думал.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Наукоподобную муть вижу, на что возражать - не вижу.

сочувствую, че

Вполне очевидно, что выполнение интерпретируемой программы имеет накладные расходы, но они фиксированы.

и чем же они ограничены? как в яве «семикратное повторение — еще не копипаст», так и «семикратный расход памяти — это фиксированные накладные расходы», так?

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

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

вот скажем специализированная версия массива из-за того, что не имеет append, может аллоцировать ровно столько, сколько надо (а не 2^n — вот экономия уже кое-где в 2 раза) и выкинуть 1-2-3 указателя (вот экономия в K раз на коротких массивах)

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

Вполне очевидно, что выполнение интерпретируемой программы имеет накладные расходы, но они фиксированы.

и чем же они ограничены?

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

как в яве «семикратное повторение — еще не копипаст», так и «семикратный расход памяти — это фиксированные накладные расходы», так?

WTF am I reading?

вот скажем специализированная версия массива из-за того, что не имеет append, может аллоцировать ровно столько, сколько надо

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

tailgunner ★★★★★
()
Ответ на: комментарий от elyadow

Вали, некомпетентной школоте тут не место.

anonymous
()
Ответ на: комментарий от tailgunner

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 ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 5)

Интерпретация, компиляция, а это что?

Копропретация.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

питон жрет до 9×

Ты хоть понимаешь, что сравнивать интерпретатор байткода Питона надо с компилятором Питона в машкод?

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

tailgunner ★★★★★
()

Что вы тут развели? Компиляция - это перевод всей программы с одного языка на другой, с возможностью последующего выполнения на машине целевого языка. Интерпретация - процесс выполнения программы на одном языке на машине целевого языка. Что тут может быть непонятного? А если говорить другими словами, то компилятор - это генерирующей расширение интерпретатора и имея интерпретатор языка мы можем построить на нем компилятор. Подробности у Торчина, Ершова и Футамуры. Может быть Нила Джонса, но я сам его не читал.

anonymous
()

Компиляцией он является, компиляцией.

anonymous
()
Ответ на: комментарий от tailgunner

Ты хоть понимаешь, что сравнивать интерпретатор байткода Питона надо с компилятором Питона в машкод?

не надо

да, я конечно понимаю, что benchmarksgame.alioth.debian.org достаточно хреновые тесты, поскольку они не параметризованы, и впринципе можно написать программу а-ля std::cout << «precalculated test result here\n», но, поскольку там как-то следят за тем, чтобы алгоритм был реализован без подобных читов, то *в контексте рассмотрения специализации* можно сравнивать разные языки

кто мешает качественному компилятору питона выдать ровно с++ - исходник из benchmarksgame.alioth.debian.org?

кстати, ровно так же никто не мешает *качественному* компилятору с++ преобразовать один из примеров monk-а в другой (при условии, что там не светятся символы, видимые линкеру)

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Ты хоть понимаешь, что сравнивать интерпретатор байткода Питона надо с компилятором Питона в машкод?

не надо

okay.jpg

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

okay.jpg

давай рассмотрим такой сильно упрощенный вопрос:

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

имеет ли оптимизирующий компилятор питона право преобразовать ее просто в «print 42»?

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

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

имеет ли оптимизирующий компилятор питона право преобразовать ее просто в «print 42»?

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

оптимизирующй компилятор *должен* уважать эту инфу

Он должен уважать ее не больше, чем компилятор Си++.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 2)

Обфускация.

Ещё один умник решил притырить GPL кода ? Ясно-понятно.

vasha_catpcha_vret
()

Это терминология, придуманная мартышками для организации их узкого мышления. Реального значения не несёт.

anonymous
()
Ответ на: комментарий от i-rinat

А если из бинарника в эквивалентный исходник, это трансляция или декомпиляция? (Интересна правильная терминология).

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

Т.ч. это декомпиляция, а не трансляция. При трансляции результат однозначен(не считая UB и оптимизаций).

emulek
()
Ответ на: комментарий от i-rinat

Только цель в запуске бинарника собранного под один CPU на CPU с другой архитектурой.

а это уже трансляция. Ну или там компиляция(если не сразу выполнять). Тут результат видимо будет однозначный.

Тащем-то gcc так и делает, сначала в какой-то свой внутренний ЯП переводит, а потом в целевую архитектуру. Можешь просто добавить ещё одну архитектуру и скормить листинг дизассемблера.

emulek
()
Ответ на: комментарий от monk

То есть интерпретация — частный случай компиляции?

да, конечно. Просто выхлоп компилятора ты сразу скармливаешь CPU. Без сохранения. Впрочем, часто сохраняют короткие циклы. Это уже гибрид.

emulek
()
Ответ на: комментарий от elyadow

Как можно спутать компиляцию с интерпретацией, когда это вообще не похожие вещи?

это одно и то же на самом деле.

emulek
()
Ответ на: комментарий от www_linux_org_ru

не исключено, что более специализированная программа будет жрать существенно больше памяти, чем недоспециализированная, и что тогда?

а тогда вводи в условие «специализации» — «жрать минимум памяти».

emulek
()
Ответ на: комментарий от tailgunner

Раскрой тему жручести памяти.

код транслятора придётся на лету интерпретировать в специальный код вычислителя. А код компилятора не придётся.

emulek
()
Ответ на: комментарий от anonymous

имея интерпретатор языка мы можем построить на нем компилятор.

да, только это будет плохой компилятор. Хороший компилятор помнит, что у него утка, и выделяет ему памяти как положено утке.

Хороший интерпретатор полагает, что то, что крякает как утка == утка. Посему, выхлоп хорошего интерпретатора не может дать хороший код в принципе, ибо интерпретатор должен проверить, как ЭТО крякает, прежде чем дать ему места.

Посему, компилятор может раз и навсегда выделить утке ровно столько, сколько надо, а интерпретатор — не может. Т.к. не может заглядывать вперёд по коду.

emulek
()
Ответ на: комментарий от anonymous

RTFM про Futamura projection, ламер. Специализация съест все эти проверки.

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

emulek
()
Ответ на: комментарий от elyadow

То есть компиляция — частный случай иинтерпретации?

именно так. при компиляции мы просто сохраняем код целевой платформы в файл, без выполнения. Разница в том, что для компилятора входной ЯП другой, более жёсткий, без всяких eval'ов, и утиных типизаций.

emulek
()
Ответ на: комментарий от elyadow

То есть при интерпретации мы просто сохраняем код целевой платформы в файл, без выполнения?

наоборот жеж.

например $ X=7; (( Y = (X + 10)/3 )); echo $Y 5 порождает код, который нигде не хранится, а сразу выполняется.

emulek
()
Ответ на: комментарий от emulek

Можешь просто добавить ещё одну архитектуру и скормить листинг дизассемблера.

Какой же бред ты несёшь...

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

какой-же ты неумный... Ну не понял — так и скажи: «я не понял». А ты сразу — бред. Для меня вот партитура — тоже непонятна. Но я не называю это «бредом».

Больше читай по теме, и тогда тебе многое откроется. Это совет.

emulek
()
Ответ на: комментарий от emulek

Больше читай по теме, и тогда тебе многое откроется. Это совет.

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

«Talk is cheap. Show me the code.»

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

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

Сложно даже что-то возразить, потому что концентрация бреда запредельная.

ты сам себе противоречишь. Если-бы я бы не был в теме, мне было-бы легко возразить.

«Talk is cheap. Show me the code.»

как ты это представляешь в разрезе сабжа? Я тебе дал совет, посмотри, как оно сделано в gcc, и добавь туда ещё одну архитектуру. Что конкретно тут тебе не понравилось? Продолжаем заниматься демагогией, и выдвигать необоснованные обвинения? Ну хорошо, вопросов не имею больше.

emulek
()
Ответ на: комментарий от yyk

порождает код, который нигде не хранится, а сразу выполняется.

а если без jit-а?

а если без jit'а, то код получается неявно. Т.е. сразу. С jit'ом сначала получается байткод, который потом и интерпретируется llvm прямо в машинный код, который сразу и выполняется.

emulek
()
Ответ на: комментарий от emulek

Если-бы я бы не был в теме, мне было-бы легко возразить.

Уверен?

Создано новое общество «Люди за этическое обращение с адронами» [People for the Ethical Treatment of Hadrons или PETH] Его оганизатор, Tia Aumiller, заявляет: «Вы разгоняете адроны до световой скорости, сталкиваете и уничтожаете их!! Одумайтесь! А что если адронам БОЛЬНО?! Через сотню лет вы оглянётесь назад и пожалеете о содеянном!»

ЦЕРН вынужден был признать, что никаких исследований на тему, может ли адронам быть больно при столкновениях или может ли их укачивать на таких высоких скоростях, не проводилось, но только лишь потому, что это «очевидный идиотизм»

как ты это представляешь в разрезе сабжа?

В виде листингов.

Я тебе дал совет, посмотри, как оно сделано в gcc, и добавь туда ещё одну архитектуру. Что конкретно тут тебе не понравилось?

А ты попробуй сформулировать свой совет в одном куске текста. Потом сам посмотри, как это сделано в gcc. Тогда поймёшь, где ты ошибся.

Продолжаем заниматься демагогией, и выдвигать необоснованные обвинения?

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

Профессор, а где Ваш репозиторий на GitHub?

i-rinat ★★★★★
()
Ответ на: комментарий от emulek

А при чем тут java, ламеришка ты убогий? Ты на Tachyon или PyPy смотри, или хотя бы v8.

anonymous
()
Ответ на: комментарий от emulek

или ты про конкретную неведомую мне «зверушку» (сиречь - интерпретатор), или дремуч донельзя...

yyk ★★★★★
()
Ответ на: комментарий от i-rinat

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

значит ты неправильно реализовал.

Профессор, а где Ваш репозиторий на GitHub?

АПВС?

emulek
()
Ответ на: комментарий от i-rinat

Можешь просто добавить ещё одну архитектуру и скормить листинг дизассемблера.

Какой же бред ты несёшь...

Может он под архитектурой в данном случае имел в виду язык. Например, я могу написать транслятор asm x86 -> C и автоматически получу трансляторы x86 -> arm, x86 -> mips, x86 -> ... через gcc.

И опять же будут ли они являться компиляторами при том, что все регистры станут обычными переменными. А если позволять вычислимый jmp и модификацию сегмента кода, то придётся делать частичную трансляцию при выполнении. И опять же, можно ли получившийся комбайн называть компилятором. Получится что-то наподобие шитого кода в Forth (вот опять, выполнение шитого кода — интерпретация или компиляция?).

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

В llvm до версии 2.7 была такая целевая платформа, «c backend». Потом убрали, некому поддерживать было.

anonymous
()
Ответ на: комментарий от emulek

значит ты неправильно реализовал.

«Реализовал с ошибками» лучше «не реализовал, но и не допустил ошибок». В первом случае ошибки можно исправить, во втором ничего сделать нельзя.

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

АПВС?

Статья короткая, прочитай, там написано.

i-rinat ★★★★★
()
Ответ на: комментарий от tailgunner

Чисто теоретически - можешь.

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

yyk ★★★★★
()
Последнее исправление: yyk (всего исправлений: 1)
Ответ на: комментарий от anonymous

Отличная прога! Вот только пытаться разобрать получившийся код от декомпиляции какого-нибудь ядерного/CUPS/X-драйвера (при отсутствии *.h используемых библиотек) и врагу не пожелаешь.

yyk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.