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