2

В моей борьбе за то, чтобы расстаться с интерпретаторами, и, пытаясь продвинуть свои знания в C++, я недавно наложил копию «C++ в двух словах: краткое описание рабочего стола (In ореховая скорлупа (O'Reilly)) и «Написание компиляторов и переводчиков (Wiley)». В то время как мой курс колледжа на C++ научил меня сортировать стопки и списки, он ничего не учил мне по этим предметам. Я решил, что напишу компилятор, привязанный к моим уникальным привычкам и стилю кодирования.Об осуществлении нескольких одновременных задач компилятора

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

+0

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

+0

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

+1

Параллелизм как полезная языковая функция является предметом десятилетий академических исследований, поэтому это выходит за рамки вопроса SO. Вероятно, вам следует сосредоточиться на создании языка, адаптированного к вашим привычкам, прежде чем перейти к привычкам, которые вы намереваетесь развить позже: v). – Potatoswatter

ответ

0

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

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

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

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

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

1

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

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

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

+0

Это в основном верно для компилятора C++. Например, когда мы говорим о компиляторе Python, тогда * * значение * в многопоточности, потому что компилятор ищет и компилирует зависимости. –

+0

Конвей Грега концептуально «большие куски» (разбор файлов, построение АСТ, построение таблиц символов уровня сборки, анализ функций, глобальный анализ, генерация кода функции, оптимизация). На этом уровне детализации довольно сложно получить какой-либо параллелизм (кроме компиляции нескольких блоков компиляции параллельно, как заметил Грег). Если вы хотите сделать лучше, вы должны уменьшить размер вычислительных зерен. Вы можете использовать lex и parse параллельно; вы можете создавать таблицы символов функций и т. д. Организация этого сложна. –

0

Это зависит от типа языка, который вы хотите скомпилировать.

Если вы думаете о создании языка сегодня, он должен основываться на модулях, а не на пути заголовка/источника C++.С такими языками компилятору часто присваивается один «целевой» (модуль) и автоматически компилирует зависимости (другие модули), это, например, то, что делает компилятор Python.

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

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

1

Написание компилятора сложно; языки сложны, люди хотят хорошего кода, и они не хотят долго ждать. Это должно быть очевидно из вашего собственного опыта использования компиляторов C++. Написание компилятора C++ особенно сложно, потому что язык особенно сложный (новый стандарт C++ 11 делает его значительно более сложным), и люди ожидают, что действительно хороший код из компиляторов C++.

Вся эта сложность и недостаток фона в компиляторах предполагает, что вы вряд ли напишите компилятор C++, не говоря уже о параллельном. Сообщества GCC и CLANG имеют сотни людей и десятилетия прошедшего времени разработки. Возможно, стоит попытаться создать игрушечный компилятор, чтобы лучше понять проблемы.

Что касается параллелизма в самом компиляторе, можно сделать несколько подходов.

Первый - использовать стандартную библиотеку, как вы предложили, и попытаться модифицировать существующий компилятор с параллелизмом. Странно, что немногие, похоже, пытались выполнить эту задачу, учитывая, что GCC и CLANG являются инструментами с открытым исходным кодом. Но также очень трудно распараллелить программу, которая была разработана без параллелизма. Где можно найти единицы параллелизма (обрабатывая отдельные методы?), Как вы вставляете параллелизм, как вы гарантируете, что у модернизированного компилятора нет проблем с синхронизацией (если компилятор обрабатывает все методы параллельно, где гарантия что подпись из одного метода на самом деле готова и доступна для компиляции других методов?) Наконец, как можно гарантировать, что параллельная работа доминирует над дополнительными издержками инициализации/прерывания/синхронизации потока, так что компилятор на самом деле быстрее работает с несколькими процессорами? Кроме того, библиотеки потоков немного сложны в использовании, и относительно легко сделать немой ошибку кодирования потокового вызова. Если у вас их много в вашем компиляторе, у вас есть большая вероятность такой глупой ошибки. Отладка будет сложной.

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

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

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

Наш DMS Software Reengineering Toolkit - это именно такой набор инструментов и библиотек, которые позволяют создавать сложные инструменты для генерации/преобразования кода или анализа. DMS имеет full C++11 front end, который использует все вспомогательные устройства DMS (параллельно).

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

Смежные вопросы