Недостаток самозагрузки? - PullRequest
4 голосов
/ 22 апреля 2011

Я видел много ссылок по начальной загрузке, мне было интересно, каковы основные недостатки начальной загрузки компилятора для языка, скажем X, с использованием программирования C вместо языка ассемблера? Мне было интересно, ограничит ли использование C все, что я делаю, созданием на ассемблере на языке C (например, как это делает компилятор C).

Например, все, что я напишу в Python, в конечном итоге будет заботиться CPython, делая это в конечном итоге в C-подобной манере в аппаратном обеспечении - что может быть не оптимальным?

Конечно, C, вероятно, очень хороший язык, но для некоторых других общих языков это может быть не так. Разве при начальной загрузке не появятся узкие места, ограничения, специфичные для языка, который я использую для создания загрузочного компилятора? Как генерация машинного кода будет такой же, как С генерирует код, а не каким-то случайным образом.

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

Ответы [ 2 ]

5 голосов
/ 22 апреля 2011

Ранее у нас был очень похожий вопрос: интерпретатор Python на ассемблере .Все это применимо и к компиляторам: это невероятное усилие (настолько большое, что практически невозможно сделать что-либо такого размера), оно приводит к взрыву затрат на обслуживание, оно очень мало покупает, если вообще помогает - в по крайней мере 2/3 всех случаев, это будет активно вредно, потому что никто из нас не может победить современный компилятор C.

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

О, и пока мы на этом: Начальная загрузка может на самом деле привести к улучшению производительности.Проект PyPy реализует Python в (подмножество) Python.Вы должны быть медлительным, говорите? Неверно! Он может запускать почти все программы быстрее, чем CPython, который написан на C (который отображает примерно также и сборку, насколько это возможно) и оптимизирован очень умными людьми в течение многих лет.Зачастую для этого требуется лишь доля времени.Конечно, они выигрывают, используя компилятор Just In Time, который по своей природе хорошо подходит для оптимизации черт из динамических языков.Но даже не-JIT-версия, обычный интерпретатор, часто менее чем в 2 раза медленнее, чем CPython.См. PyPy центр скорости .

1 голос
/ 24 января 2012

Да.В некоторых случаях сопоставление функции вашего языка с аналогичной функцией C будет стоить вам.Два примера:

Если вы реализуете вызов функции YourLang как вызов функции C - то есть вы наивно используете стек C / native - вы теряете способностьдля поддержки глубокой рекурсии, правильной рекурсии хвоста, продолжений и, возможно, проверки стека.(Или, по крайней мере, вам нужно подумать о них.)

Если вы сопоставите один поток YourLang с одним потоком POSIX / Windows / любым другим потоком, вы не сможетеподдерживать массовый параллелизм, такой как Erlang.

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

...