> или в gcc, где всё ещё нормальный C, а не C++ вездеКак будто что-то плохое (что C++).
> и дурацкий пакованый формат IR, например. дурацкие gimple и rtl, может,
> приятней окажутся
Чем дурацкий? Впрочем, не знаю, как у тебя, а у меня опыта о профитах IR перед гимплом вот так сходу рассуждать нет. Погуглю, пойму, перескажу, это да, но не сходу.
> ну, «доказали» — это если все ушли на фронт, пилить llvm, а
> gcc помер. я пока что этого не наблюдаю.
Странные доказательства, конечно. Я к таким не привык.
> потому что llvm умеет меньше гитик, и за счёт этого меньше оброс
> костылями, например?
Умеет меньше чего?
>> Ещё придётся доказать, что изначальное планирование — единственный вариант для хреновой
>> архитектуры
> утверждение, что «лучше начать с нуля» — неявно это постулирует.
Нет, утверждение это постулирует лишь то, что проще всего изменить архитектуру переписыванием с нуля.
> потому
> что иначе никак не может быть лучше с нуля, ибо в
> конце получится то же самое по степени УЖОСА.
Неочевидное утверждение.
>> Максимум обрезанный там список платформ, а влияние его длины (при его нетривиальности)
>> на архитектуру сильно неочевидно, мягко скажем.
> однако возможно.
Чайник на орбите Плутона тоже возможен, но это не повод отталкиваться от его существования.
> я тоже хотел бы жить в мире, где всё идеально. а на
> практике часто получается, что не должно — а есть.
Однако, чем лажи меньше, тем оно ближе к идеальности.
> а так, что, например (абстрактный), при некоторых условиях и знании потрохов кодогенератора
> можно некоторые фичи сделать эффективней. преобразование в IR — это всё
> равно потеря некоторой части информации. которую кодогенератору иногда надо восстанавливать.
> а иногда можно — зная, как сделан кодогенератор — облегчить ему
> эту работу. там фичка, тут фичка — в итоге пользователи в
> выигрыше, потому что компилирует чуть быстрее, например, или делает код чуть
> лучше. а вот сам компилятор стал захламлённей.
Так это слегка так обратная задача допиливания кодогенератора под потребности фронтенда, не? Корректная реализация возможностей важнее, потом уже и оптимизировать можно.
> см. выше. в идеале оно всё, конечно, так. а на практике *может*
> оказаться иначе. именно поэтому я настаиваю на двух вещах: полном списке
> платформ и сгенерированном коде как минимум не хуже. чтобы наглядно увидеть,
> зря ли костыли накостылили и можно ли было без них обойтись,
> сохранив весь фичсет. и чего это могло стоить в других местах
> (скорость, память, etc).
Насчёт платформ мы уже обобсуждались, а что до кода — когда дело не доходит до заточенных под gcc бенчмарков, опирающихся на его особенности, и до специфичных приложений (вроде openmp, с которым у clang по тем же лицензионным соображениям напряг), оба компилятора выдают в среднем одинаковый с точки зрения производительности код. И бенчи в среднем со мной согласны (см. http://www.phoronix.com/scan.php?page=news_item&px=MTgzNDE ), да и мой опыт это показывает, причём, с достаточно разными паттернами работы с процессором и памятью. Например, NLP-движок, активно дёргающий разные области среди пары сотен гигабайт памяти, или какой-нибудь градиентный спуск с многократным и хорошо векторизуемым вычислением всякого матана по ходу. Разница во времени в пределах статистической погрешности.
Впрочем, непосредственно в процессе разработки скорость самой компиляции и качество сообщений об ошибках куда важнее, как по мне.
Качество сообщений так вообще отличный индикатор костыльности архитектуры, спасибо плюсам — причиной ошибки может быть совсем другой контекст, чем тот, где она появилась. Надо уметь это сохранять, протаскивать по процессу компиляции и понимать ещё.
