The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Ричард Столлман выступил против добавления поддержки отладчи..., opennews (??), 08-Фев-15, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


14. "Ричард Столлман выступил против добавления поддержки отладчи..."  +13 +/–
Сообщение от Какаянахренразница (ok), 08-Фев-15, 10:06 
Тебе ответ от дедушки: не нравится -- можешь форкуть.
Ответить | Правка | Наверх | Cообщить модератору

21. "Ричард Столлман выступил против добавления поддержки отладчи..."  –7 +/–
Сообщение от bav (ok), 08-Фев-15, 10:26 
Дедушка уже ответил: "Я боюсь что поддержка LLDB будет круче GDB, поэтому ее быть не должно".

http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg003...

Ответить | Правка | Наверх | Cообщить модератору

73. "Ричард Столлман выступил против добавления поддержки отладчи..."  +12 +/–
Сообщение от myhand (ok), 08-Фев-15, 15:51 
Дедушка ответил: "We should do what is best for the GNU system's goal of
giving the users freedom.  This means considering what is good for
Emacs and what is good for GDB, to make a decision.  Then the whole
GNU Project should do what is best.  That is the responsibility of
each GNU package maintainer. If GNU packages do not support each other, it will be easier
for many of them to fail."

Грубо говоря: "Дубина, Emacs не единственный проект GNU.  Проекты должны координироваться и друг друга поддерживать, иначе пропиерасты передавят по одному.  Мейнтейнера нужно об этом помнить, а не мнить себя африканскими царьками."

Учи агглицкий, школие.

Ответить | Правка | Наверх | Cообщить модератору

286. "Ричард Столлман выступил против добавления поддержки отладчи..."  +/–
Сообщение от Аноним (-), 15-Фев-15, 19:37 
>[оверквотинг удален]
> Emacs and what is good for GDB, to make a decision.  
> Then the whole
> GNU Project should do what is best.  That is the responsibility
> of
> each GNU package maintainer. If GNU packages do not support each other,
> it will be easier
> for many of them to fail."
> Грубо говоря: "Дубина, Emacs не единственный проект GNU.  Проекты должны координироваться
> и друг друга поддерживать, иначе пропиерасты передавят по одному.  Мейнтейнера
> нужно об этом помнить, а не мнить себя африканскими царьками."

А под всем этим читается: "Я знаю лучше, я верховожу GNU, я лучше всех вижу, поэтому моё мнение априори важнее".

Лично я не буду сожалеть о смерти GDB, если это произойдёт за счёт вытеснения его более качественным open source проектом. Столлману жалко GNU-софтину? - Ну, давайте погладим дедушку по голове, платочек поднесём.

Потому что дедушка как был лицемерным хамлом (не грубияном, а именно хамлом), так и остался. Политик он хороший, спору нет, там эти качества в цене - без шуток. Пиариться на открытом софте RMS умеет. Спроси любого, кто хоть что-то слышал про open source - назови любого деятеля - назовут Столлмана и Торвальдса. Но если второй не скрывает своих амбиций и выражается прямо, при этом реально работая над одним из ключевых продуктов для всего open source (да, я это как не любящий Linux человек говорю - одно дело любить или не любить, а другое - признавать влияние), то первый - посмотрите внимательно на его заслуги? Написаный им софт - кривой до жути, его потом десятилетиями от детских проблем лечили совсем другие люди. Кстати, очень напоминает подход тов. Поттеринга... Но RMS продолжает этим всем махать, он машет своим пониманием свободы; забывая, что свобода выбирать для себя границы личной свободы - это тоже свобода, и когда её навязывают, убеждая, что AGPL - верх совершенства - это ни разу не свобода.

RMS - ли-це-мер. Он заявляет, что вот-де они работают над "полностью открытым" компьютером, и вот уже GNU рекламирует такую разработку. Плевать, что в ней сетевые карты и другие контроллеры потенциально не подконтрольны хоть тысячу раз открытой и GPL-ной ОС. Столлман с чистой совестью объявляет такой компьютер полностью принадлежащим пользователю, хотя не видел, скорее всего, ни одной схемы ни одного микропроцессора в этой системе.

Да Столлман делает и благое - защищает в судах отдельных разработчиков open source. Иногда. Когда считает нужным. Но если это единственное, что реально полезного он делает - может, стоит это честно признать?

Но пока что, видимо, нимб не жмёт.

Ответить | Правка | Наверх | Cообщить модератору

288. "Ричард Столлман выступил против добавления поддержки отладчи..."  +/–
Сообщение от myhand (ok), 15-Фев-15, 23:27 
> Лично я не буду сожалеть о смерти GDB, если это произойдёт за
> счёт вытеснения его более качественным open source проектом.

Я почему-то уверен, что лично ты gdb просто не используешь, и на
подобные "сожаления" можно оправданно "положить".  В принципе, это
несложно доказать.

> Столлману жалко GNU-софтину?

Да, как любому разумному человеку, целью которого является не "open
source" из альфа-версий для тестеров - а стабильная экосистема свободного ПО.

> Но если второй не
> скрывает своих амбиций и выражается прямо, при этом реально работая над
> одним из ключевых продуктов для всего open source

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

> Написаный им софт - кривой до жути

Анонимные иксперды лор^Wopennet гарантируют вам это!

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

Отака ****я малята!
,
> его потом десятилетиями от детских проблем лечили совсем другие люди.

Все больше напоминает linux.

Напомни от каких проблем дизайна лечили Emacs или gdb?  И, кстати, кто.

> RMS - ли-це-мер. Он заявляет, что вот-де они работают над "полностью открытым"
> компьютером, и вот уже GNU рекламирует такую разработку. Плевать, что в
> ней сетевые карты и другие контроллеры потенциально не подконтрольны хоть тысячу
> раз открытой и GPL-ной ОС. Столлман с чистой совестью объявляет такой
> компьютер полностью принадлежащим пользователю, хотя не видел, скорее всего, ни одной
> схемы ни одного микропроцессора в этой системе.

Цитату пожалуйста.  Или тапком в морду.

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

Ответить | Правка | Наверх | Cообщить модератору

290. "Ричард Столлман выступил против добавления поддержки отладчи..."  +/–
Сообщение от Michael Shigorinemail (ok), 16-Фев-15, 16:44 
> RMS - ли-це-мер.

Нет, он действительно делает то, что говорит.

Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

87. "Ричард Столлман выступил против добавления поддержки отладчи..."  –1 +/–
Сообщение от 0xd34df00d (??), 08-Фев-15, 17:07 
gcc проще с нуля, чем форкать.
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

88. "Ричард Столлман выступил против добавления поддержки..."  +3 +/–
Сообщение от arisu (ok), 08-Фев-15, 17:11 
> gcc проще с нуля, чем форкать.

llvm-овцы тоже так думали. пока что пыхтят где-то сзади в пыли.

Ответить | Правка | Наверх | Cообщить модератору

94. "Ричард Столлман выступил против добавления поддержки..."  –2 +/–
Сообщение от 0xd34df00d (??), 08-Фев-15, 17:33 
По части количества поддерживаемых архитектур, разве что.

asan, кстати, тоже небось изобретение gcc'овцев, например?

Ответить | Правка | Наверх | Cообщить модератору

95. "Ричард Столлман выступил против добавления поддержки..."  +2 +/–
Сообщение от arisu (ok), 08-Фев-15, 18:01 
> По части количества поддерживаемых архитектур, разве что.

вполне достаточно, а не «разве что». вот когда они догонят gcc по *всем* параметрам — вот тогда и следует посмотреть, проще ли было с нуля.

Ответить | Правка | Наверх | Cообщить модератору

97. "Ричард Столлман выступил против добавления поддержки..."  –1 +/–
Сообщение от 0xd34df00d (??), 08-Фев-15, 18:13 
Зачем мне эти все параметры, если мне от компилятора C++ под x86_64 нужна поддержка C++ и x86_64? Тот же asan и C++14 мне куда важнее поддержки attiny какой-нибудь.

Инструмент под задачу, и с рядом задач clang/llvm справляется куда лучше gcc.

Ответить | Правка | Наверх | Cообщить модератору

101. "Ричард Столлман выступил против добавления поддержки..."  +5 +/–
Сообщение от arisu (ok), 08-Фев-15, 18:17 
> Зачем мне эти все параметры

затем, что если ты вдруг уже забыл, то напомню: речь шла про «проще с нуля», и в качестве примера я привёл llvm. который «с нуля», и пока что gcc не догнал никак, хотя пилится уже больше декады.

Ответить | Правка | Наверх | Cообщить модератору

177. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от 0xd34df00d (??), 09-Фев-15, 16:04 
> затем, что если ты вдруг уже забыл, то напомню: речь шла про
> «проще с нуля», и в качестве примера я привёл llvm. который
> «с нуля», и пока что gcc не догнал никак, хотя пилится
> уже больше декады.

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

Такое впечатление, что в этом ИТТ треде людям лицензионная чистота важнее, чем функциональность. Кстати, небольшой личный опыт показывает, что софт/либу под пермиссивной лицензией в корпоративном мирке возьмут куда охотнее, чем вирусный GPL. Зато и шанс возврата контрибьюшенов в апстрим выше, хотя бы для того, чтобы набор патчей не тянуть потом с собой всю жизнь.

Ответить | Правка | Наверх | Cообщить модератору

178. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 09-Фев-15, 16:11 
да пофигу, что он там поддерживает лучше: у него нет всех фич, которые есть у gcc. вопрос не в том, кто лучше, а кто хуже, а в том, что с нуля «догнать и обогнать» gcc у llvm пока что не получилось. за более чем десять лет разработки. потому нет, ни разу не проще «бросить gcc и сделать с нуля».
Ответить | Правка | Наверх | Cообщить модератору

179. "Ричард Столлман выступил против добавления поддержки..."  +1 +/–
Сообщение от 0xd34df00d (??), 09-Фев-15, 16:17 
> да пофигу, что он там поддерживает лучше

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

> у него нет всех фич,
> которые есть у gcc. вопрос не в том, кто лучше, а
> кто хуже, а в том, что с нуля «догнать и обогнать»
> gcc у llvm пока что не получилось. за более чем десять
> лет разработки. потому нет, ни разу не проще «бросить gcc и
> сделать с нуля».

Ну ёпрст, по той же логике и gcc не догоняет clang, ибо у него нет всех фич, которые есть у clang/llvm. Ни один из них не является, как это там, proper subset'ом другого. Так как, будем выбирать инструмент под задачу (gcc собирать прошивки для avr'ок, шлангом собирать под линукс x86_64), или выбирать, где у gcc преимущество?

Ответить | Правка | Наверх | Cообщить модератору

180. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 09-Фев-15, 16:43 
я всё ещё не теряю надежды вернуть беседу к исходному тезису: «проще с нуля».
Ответить | Правка | Наверх | Cообщить модератору

181. "Ричард Столлман выступил против добавления поддержки..."  +1 +/–
Сообщение от 0xd34df00d (??), 09-Фев-15, 16:47 
> я всё ещё не теряю надежды вернуть беседу к исходному тезису: «проще
> с нуля».

А теперь вспомним ещё
> потому что все устали от GCC с его кретинскими архитектурой, документацией и API

Чтобы это починить - проще с нуля. Нет?

Ответить | Правка | Наверх | Cообщить модератору

182. "Ричард Столлман выступил против добавления поддержки..."  +1 +/–
Сообщение от arisu (ok), 09-Фев-15, 16:52 
>> я всё ещё не теряю надежды вернуть беседу к исходному тезису: «проще
>> с нуля».
> А теперь вспомним ещё
>> потому что все устали от GCC с его кретинскими архитектурой, документацией и API
> Чтобы это починить - проще с нуля. Нет?

так вот я привёл пример, где начали с нуля и за >10 лет gcc ещё не догнали. совершенно неважно, есть ли у них что-то лучше, факт тот, что «с нуля» обозначает «умеет всё то же самое с тем же качеством». а если вдобавок что-то лучше умеет — ну ок, бонус.

тут, конечно, могут сказать, что llvm и не старался уметь всё, что умеет gcc. конечно. а если бы старался — был бы не менее уродливым монстром (он, правда, и сейчас не шибко на конкурс красоты пригоден), нежели gcc.

так вот, возвращаемся опять к началу: нет, с нуля не проще. делать кастрата — это да, возможно, проще. но интересует не кастрат.

Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

183. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от 0xd34df00d (??), 09-Фев-15, 16:55 
> так вот, возвращаемся опять к началу: нет, с нуля не проще. делать
> кастрата — это да, возможно, проще. но интересует не кастрат.

Так где ж он кастрат-то? Свою задачу выполняет, выполняет её хорошо. Задачи объять все поддерживаемые архитектуры нет, и славно, мне под обычные десктопы компилятор нужен.

От поддержки соляриса я бы не отказался, впрочем, но это так, специфика задач.

Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

184. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 09-Фев-15, 16:59 
> Так где ж он кастрат-то?

(вздыхает) умеет всё, что умеет gcc? нет? если брать за точку отсчёта gcc — получается кастрат.

Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

186. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от 0xd34df00d (??), 09-Фев-15, 17:12 
> (вздыхает) умеет всё, что умеет gcc? нет? если брать за точку отсчёта
> gcc — получается кастрат.

Ты под ответ подгоняешь, что ли?

Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

187. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 09-Фев-15, 17:18 
> Ты под ответ подгоняешь, что ли?

нет, это ты упорно пытаешься говорить не о том, о чём разговор идёт. а я не менее упорно пытаюсь тебя вернуть назад. а ты опять начинаешь про «меня устраивает», о чём речь вообще не шла.

Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

188. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от 0xd34df00d (??), 09-Фев-15, 17:20 
Речь шла, раз уж на то пошло, о том, что у gcc кривое API, документация и архитектура. Всё это в llvm/clang не то чтоб починено, но значительно лучше, чем у gcc, да.

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

Так что кто тут ещё не о том.

Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

189. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 09-Фев-15, 17:34 
> Речь шла, раз уж на то пошло, о том, что у gcc
> кривое API, документация и архитектура. Всё это в llvm/clang не то
> чтоб починено, но значительно лучше, чем у gcc, да.

потому что llvm — кастрат. сравнивать «лучше/хуже» будет иметь смысл только когда llvm научится делать всё то же самое, что делает gcc, и как минимум не хуже. а до тех пор даже однозначно ответить на вопрос: «а может, потому и лучше, что фич меньше?» не выйдет — нет материала для полноценного сравнения.

апи и архитектура имеют свойство превращаться в навоз с возрастанием количества фич.

> Ну и да, если рассуждать формально, то чем заниматься бесконечным рефакторингом по
> готовой кодовой базе, пытаясь починить API и архитектуру, проще переписать с
> нуля, не так ли?

пока что ни одного примера, подтверждающего это утверждение по отношению к gcc, нет. кастраты не считаются, потому что их невозможно сравнить по всем фичам.

> Так что кто тут ещё не о том.

в основном — ты. потому что упорно пытаешься свернуть на «лучше/хуже» и «мне хватает», а речь совсем о другом. о том, что доказательства утверждения «проще переделать с нуля» — нет. самый ближайший собрат gcc — за десять лет не смог получить все фичи, которые есть у gcc, и поэтому в сравнении проиграл ещё на старте.

Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

190. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от 0xd34df00d (??), 09-Фев-15, 17:44 
> потому что llvm — кастрат. сравнивать «лучше/хуже» будет иметь смысл только
> когда llvm научится делать всё то же самое, что делает gcc,
> и как минимум не хуже.

Почему? Если зафиксировать критерии сравнения, то прекрасно можно сравнивать. Можно сравнивать размер и скорость сгенерированного кода под arm или x86, можно сравнивать поддержку новых стандартов, можно сравнивать скорость компиляции, можно сравнивать качество и удобство ошибок компиляции, можно сравнивать встраиваемость, можно сравнивать поддержку различных архитектур, в конце концов. Зачем сравнивать всё вместе и сразу-то? Как правило, редко когда из этого списка нужно всё и сразу.

> апи и архитектура имеют свойство превращаться в навоз с возрастанием количества фич.

Время покажет.

> в основном — ты. потому что упорно пытаешься свернуть на «лучше/хуже» и
> «мне хватает», а речь совсем о другом. о том, что доказательства
> утверждения «проще переделать с нуля» — нет. самый ближайший собрат gcc
> — за десять лет не смог получить все фичи, которые есть
> у gcc, и поэтому в сравнении проиграл ещё на старте.

Я утверждаю, что такой критерий некорректен и не имеет смысла.

Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

191. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 09-Фев-15, 17:58 
> Почему? Если зафиксировать критерии сравнения, то прекрасно можно сравнивать.

можно, конечно. можно даже сравнивать квадратное и синее. желательно — в присутствии хаскелистов, пусть помучаются.

> Зачем сравнивать всё вместе и сразу-то?

потому что иначе сравнение правильно называется «читерство». самоочевидно, что мой компилятор, умеющий только компилировать «приветмир» — будет иметь намного более понятный API, намного более быстрый код и так далее. именно за счёт того, что он окромя «приветмира» другие фичи не реализует.

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

а без ответа на последний вопрос невозможно ответить и на основной — проще и лучше ли просто начать с нуля.

> Как правило, редко когда из этого списка нужно всё и сразу.

а это в данном случае неважно. важно то, что в разрезе данного разговора llvm попросту выпадает из сравнений, потому что не умеет всё то, что умеет gcc. при этом совершенно неважно, умеет ли он некоторые вещи, которые умеет, лучше gcc, и имеет ли он вещи, которых нет в gcc. попросту несравним — потому что ещё не догнал.

> Я утверждаю, что такой критерий некорректен и не имеет смысла.

тогда то же самое относится и к утверждению из #87 — потому что ты заведомо откидываешь всё, что мешает ему быть истиной, настаивая на том, что мой игрушечный компилятор «приветмир» можно сравнивать с llvm, например, и на этом основании утверждать, что llvm — куча тормозного уродливого гуано.

Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

192. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от 0xd34df00d (??), 09-Фев-15, 18:08 
> можно, конечно. можно даже сравнивать квадратное и синее. желательно — в присутствии
> хаскелистов, пусть помучаются.
> зафиксировать критерии
> зафиксировать критерии

Тип с обоих сторон оператора правильный будет, нормально.

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

>> Зачем сравнивать всё вместе и сразу-то?
> потому что иначе сравнение правильно называется «читерство». самоочевидно,
> что мой компилятор, умеющий только компилировать «приветмир» — будет
> иметь намного более понятный API, намного более быстрый код и так
> далее. именно за счёт того, что он окромя «приветмира» другие фичи
> не реализует.

О, ну вот уже пошёл относительно конструктивный диалог на втором десятке комментариев в ветке.

Компиляторы приветмиров тоже хороши (см. DSL), однако, чем более близкие предметы мы сравниваем, тем проще. При этом предметы быть равными не обязаны, и кланги всякие с гцц этому вполне удовлетворяют, ИМХО.

А что до читерства - ну это как школьники в онлайн-стрелялках, право дело. Как только тебя чуть убили или ещё что, сразу кричи про читерство.

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

Нет, нет, и ещё раз нет.

Во-первых, тогда давай рассматривать не такие фичи, как «поддержка ATTiny23 и S/390», а просто «кроссплатформенность». Для ответа на вопрос выше о том, лучше ли архитектура потому, что руки и мозги у разработчиков прямее, этого хватит, потому что 5 или 50 платформ поддерживает компилятор, уже не столь принципиально, если он вообще способен генерировать код под более чем одну платформу.

А вот что новые фичи в плане стандарта запиливаются систематически быстрее, чем в случае gcc, это вот хороший и позитивный знак, например. И в ряде приложений это куда важнее.

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

Хорошо, llvm с gcc сравнивать нельзя, а gcc-то с llvm можно хоть? Или вообще ни один компилятор ни с каким другим сравнивать нельзя, и вообще ничего сравнивать нельзя?

Это, если что, ирония над тем, что твои слова звучат как «если вещи разные, то их сравнивать нельзя». А нахрена сравнивать одинаковые вещи?

>> Я утверждаю, что такой критерий некорректен и не имеет смысла.
> тогда то же самое относится и к утверждению из #87 — потому
> что ты заведомо откидываешь всё, что мешает ему быть истиной, настаивая
> на том, что мой игрушечный компилятор «приветмир» можно сравнивать с llvm,
> например, и на этом основании утверждать, что llvm — куча тормозного
> уродливого гуано.

Нет. Сначала надо определиться с задачами и критериями оценки. Вот что этого сразу не было сделано, это да, это проблема всего треда.

Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

195. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 09-Фев-15, 18:24 
> О, ну вот уже пошёл относительно конструктивный диалог на втором десятке комментариев
> в ветке.

mea culpa. забыл, что телепаторы ещё не изобрели.

> При этом предметы быть равными не обязаны, и
> кланги всякие с гцц этому вполне удовлетворяют, ИМХО.

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

> А что до читерства - ну это как школьники в онлайн-стрелялках, право
> дело. Как только тебя чуть убили или ещё что, сразу кричи
> про читерство.

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

> Во-первых, тогда давай рассматривать не такие фичи, как «поддержка ATTiny23 и S/390»,
> а просто «кроссплатформенность».

нет. именно поддержка *всех* платформ, которые умеет gcc.

> Для ответа на вопрос выше о том, лучше
> ли архитектура потому, что руки и мозги у разработчиков прямее, этого
> хватит, потому что 5 или 50 платформ поддерживает компилятор, уже не
> столь принципиально, если он вообще способен генерировать код под более чем
> одну платформу.

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

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

> А вот что новые фичи в плане стандарта запиливаются систематически быстрее, чем
> в случае gcc, это вот хороший и позитивный знак, например. И
> в ряде приложений это куда важнее.

и это никак не отвечает на вопрос «лучше и проще ли было переделать gcc с нуля». потому что, например, запиливаться быстрее они могут именно потому, что у llvm местами обрезаный (по сравнению с gcc) фичсет. см. выше про всякие костыли.

> Хорошо, llvm с gcc сравнивать нельзя, а gcc-то с llvm можно хоть?
> Или вообще ни один компилятор ни с каким другим сравнивать нельзя,
> и вообще ничего сравнивать нельзя?
> Это, если что, ирония над тем, что твои слова звучат как «если
> вещи разные, то их сравнивать нельзя». А нахрена сравнивать одинаковые вещи?

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

Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

196. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от 0xd34df00d (??), 09-Фев-15, 18:33 
> если сравнивать, скажем, как реализована поддержка некоего языка, или насколько хорош кодогенератор
> — вполне. а вот если сравнивать архитектуру — то сначала надо
> доказать, что архитектура gcc (ну да, мягко говоря, не образец красоты)
> стала такой только и исключительно потому, что хреново спланирована.

Кому надо? Условному контрибьютору это не надо. Условный контрибьютор пойдёт контрибьютить в clang с хорошей архитектурой, документацией и C++ везде, а не последний год, или сколько там.

Только тут и сравнивать не нужно, доказали — всё, чего тут ещё обсуждать.

Интересно, почему в ИСП РАН мой бывший сокурсник занимается всякими клёвыми ништяками над компиляторами на примере clang/llvm, а не gcc? Наверное, потому что первый лучше [для этой задачи]?

> а чтобы
> это доказать, надо реализовать в другом проекте всё то же самое,
> что умеет gcc, и как минимум на том же уровне (в
> том числе и кодогенератор, который должен быть по всем параметрам как
> минимум не хуже, чем у gcc)

Ещё придётся доказать, что изначальное планирование — единственный вариант для хреновой архитектуры, но тогда, правда, и реализовывать ничего больше не придётся. Доказывать forall-утверждения позитивным примером вообще очень неблагодарное дело.

Прошу прощенья, если я «доказать» слишком серьёзно воспринимаю.

> так вопрос же не в том, кто победит, вопрос в том, что
> иначе сравнение не имеет смысла: нечто с обрезаным фичсетом почти всегда
> можно сделать лучше и понятней, чем с необрезаным.

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

>> Для ответа на вопрос выше о том, лучше
>> ли архитектура потому, что руки и мозги у разработчиков прямее, этого
>> хватит, потому что 5 или 50 платформ поддерживает компилятор, уже не
>> столь принципиально, если он вообще способен генерировать код под более чем
>> одну платформу.
> принципиально. тут пример с VLIW уже приводили.

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

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

А не должно быть никаких костылей для этого при нормальном планировании.

> у кого-то вот такая последовательность
> команд работает медленней, чем вот нетакая — и опа! в кодогенераторе
> появляется костыль со специальным случаем. и так далее.

И тут.

>> А вот что новые фичи в плане стандарта запиливаются систематически быстрее, чем
>> в случае gcc, это вот хороший и позитивный знак, например. И
>> в ряде приложений это куда важнее.
> и это никак не отвечает на вопрос «лучше и проще ли было
> переделать gcc с нуля». потому что, например, запиливаться быстрее они могут
> именно потому, что у llvm местами обрезаный (по сравнению с gcc)
> фичсет. см. выше про всякие костыли.

Если от фронтенда зависит кодогенератор, то я даже не знаю, что тут сказать. Как capture-init из C++14, или там, не знаю, расширенный noexcept оттуда же вообще относится к кодогенерации? Первая вещь разворачивается на этапе компиляции в обычную структурку, вторая вообще по определению компил-тайм.

>[оверквотинг удален]
>> Это, если что, ирония над тем, что твои слова звучат как «если
>> вещи разные, то их сравнивать нельзя». А нахрена сравнивать одинаковые вещи?
> см. выше. одинаковые по выхлопу вещи можно делать разными путями. вот пути
> и есть смысл сравнивать. но чтобы эти пути сравнивать — сначала
> выхлоп должен быть одинаковый. в данном случае «одинаковый» — это все
> архитектуры, и на каждой у нового проекта код должен быть как
> минимум не хуже, чем у старого проекта. потому что если код
> хуже — опять не ясно: может, он хуже как раз потому,
> что в старом проекте всунули мегакостыль в оптимизатор, который уродливый, но
> зато делает код чуть лучше?

Локальные мегакостыли в оптимизаторе глобальную архитектуру трогать не должны, а в гцц, поговаривают, системные проблемы.

Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

202. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 09-Фев-15, 18:49 
> Кому надо? Условному контрибьютору это не надо. Условный контрибьютор пойдёт контрибьютить
> в clang с хорошей архитектурой, документацией и C++ везде, а не
> последний год, или сколько там.

или в gcc, где всё ещё нормальный C, а не C++ везде и дурацкий пакованый формат IR, например. дурацкие gimple и rtl, может, приятней окажутся.

> Только тут и сравнивать не нужно, доказали — всё, чего тут ещё
> обсуждать.

ну, «доказали» — это если все ушли на фронт, пилить llvm, а gcc помер. я пока что этого не наблюдаю.

> Интересно, почему в ИСП РАН мой бывший сокурсник занимается всякими клёвыми ништяками
> над компиляторами на примере clang/llvm, а не gcc? Наверное, потому что
> первый лучше [для этой задачи]?

потому что llvm умеет меньше гитик, и за счёт этого меньше оброс костылями, например?

> Ещё придётся доказать, что изначальное планирование — единственный вариант для хреновой
> архитектуры

утверждение, что «лучше начать с нуля» — неявно это постулирует. потому что иначе никак не может быть лучше с нуля, ибо в конце получится то же самое по степени УЖОСА.

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

однако возможно.

>> штука в том, что разные
>> архитектуры могут иметь разные «бзики». у кого-то какой-то регистр только вот
>> так использовать можно, а так нельзя — и опа! в регистровом
>> аллокаторе появляется костыль для этой архитектуры.
> А не должно быть никаких костылей для этого при нормальном планировании.

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

> Если от фронтенда зависит кодогенератор, то я даже не знаю, что тут
> сказать. Как capture-init из C++14, или там, не знаю, расширенный noexcept
> оттуда же вообще относится к кодогенерации? Первая вещь разворачивается на этапе
> компиляции в обычную структурку, вторая вообще по определению компил-тайм.

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

> Локальные мегакостыли в оптимизаторе глобальную архитектуру трогать не должны, а в гцц,
> поговаривают, системные проблемы.

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

Ответить | Правка | К родителю #196 | Наверх | Cообщить модератору

211. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от 0xd34df00d (??), 09-Фев-15, 19:54 
> или в 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-движок, активно дёргающий разные области среди пары сотен гигабайт памяти, или какой-нибудь градиентный спуск с многократным и хорошо векторизуемым вычислением всякого матана по ходу. Разница во времени в пределах статистической погрешности.

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

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

Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

217. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 09-Фев-15, 20:49 
>> или в 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 примерно по тем же причинам начинает просираться подобными заклинаниями, тоже хочется кого-то убить. или хотя бы спрятаться в бомбоубежище.

> Качество сообщений так вообще отличный индикатор костыльности архитектуры, спасибо плюсам
> — причиной ошибки может быть совсем другой контекст, чем тот, где
> она появилась. Надо уметь это сохранять, протаскивать по процессу компиляции и
> понимать ещё.

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

Ответить | Правка | К родителю #211 | Наверх | Cообщить модератору

219. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от 0xd34df00d (??), 09-Фев-15, 21:01 
> с моей точки зрения — однозначно плохое: я ненавижу c++ и не
> скрываю этого.

Сочувствую. А тред обещает стать ещё бессмысленнее и горячее.

На самом деле я тоже ненавижу C++, но все остальные императивные и/или сиподобные языки я ненавижу ещё больше.

> тем, что пакованый. и поэтому есть кучка кода, которая занимается его упаковкой
> и распаковкой.

Занимается и занимается себе, кушать не просит, компилирует быстро.

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

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

> ну так если llvm и лучше, и красивше — логично будет ожидать,
> что народ бросит кусок мамонтятины и пойдёт пилить новое, а с
> мамонтятиной останутся три инвалида и пёс барбос. однако пока что этого
> не наблюдается.

По-моему, llvm вполне себе отлично пилится, в том числе и в институтах всяких, что является достаточно хорошим критерием.

> gcc — оно подразумевается в контексте обсуждения.

Это я понимаю. Что за гитики-то?

> тогда я неверно его понял, видимо.

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

>> Чайник на орбите Плутона тоже возможен, но это не повод отталкиваться от
>> его существования.
> именно поэтому я и говорю на протяжении кучи постов, что вместо теорезирования
> нужно использовать практику. для чего llvm'у следует сначала научиться всем гитикам
> gcc.

На протяжении кучи постов не перестаю удивляться этому логическому переходу.

>>> я тоже хотел бы жить в мире, где всё идеально. а на
>>> практике часто получается, что не должно — а есть.
>> Однако, чем лажи меньше, тем оно ближе к идеальности.
> я подозреваю, что почти никто не делает проект с прицелом «а запихаем-ка
> побольше лажи!» лажа возникает в процессе адаптации идеала к неидеальному миру.

Иногда лажа просто сама возникает вследствие сущности, которую требуется адаптировать. Прицел «а сделаем-ка фигак-фигак-и-в-продакш^Wдебиан, а там посмотрим» вполне себе имеет место быть.

> а потом может оказаться, что вариантов осталось примерно два: или полностью переделать
> кодоген, потому что упс… не учли кое-что.

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

> новый проект, кстати, не факт, что учёл все шишки предшественника.

Ну с этим никто не спорит. Поэтому я когда-то давно уже и написал, что поживём — увидим.

> я не говорил, что у llvm код хуже (или лучше). пока что
> это и неважно, потому что многого другого, необходимого для сравнения в
> рамках данного обсуждения, всё равно нет.

Да хватит уже цепляться к этим архитектурам. Давай уже рассматривать «компилятор для x86 и производных».

> ну, -O0 вполне себе быстрый.

А в clang быстрее.

> а сообщения об ошибках благодаря шаблонной магии
> в c++ всегда были какими-то заклинаниями на древнешумерском.

На самом деле их даже у гцц можно читать вполне, если не упарываться по шаблонам серьёзно.

Но я вот, к сожалению, упарываться люблю.

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

Нет чтоб фронтенд сделать к llvm!

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

clang примером показывает, что можно сделать лучше.

Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

232. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 09-Фев-15, 21:37 
>> с моей точки зрения — однозначно плохое: я ненавижу c++ и не
>> скрываю этого.
> Сочувствую.

спасибо, я не страдаю.

> На самом деле я тоже ненавижу C++, но все остальные императивные и/или
> сиподобные языки я ненавижу ещё больше.

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

> Нормальное решение — рассуждать в терминах некоей абстрактной машины.

до этого момента — да. а вот пытаться её эмулировать в том числе и битовой упаковкой команд — уже нет.

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

критерием чего? это утверждение не имеет никакой связи с моим.

>> gcc — оно подразумевается в контексте обсуждения.
> Это я понимаю. Что за гитики-то?

архитектуры-с.

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

пока что ни у кого не получилось.

>>> Чайник на орбите Плутона тоже возможен, но это не повод отталкиваться от
>>> его существования.
>> именно поэтому я и говорю на протяжении кучи постов, что вместо теорезирования
>> нужно использовать практику. для чего llvm'у следует сначала научиться всем гитикам
>> gcc.
> На протяжении кучи постов не перестаю удивляться этому логическому переходу.

тогда мы всё-таки возвращаемся к тому, что llvm — оверинжениреное гуано с невнятным апи и атомным говнокодом. потому что мой компилятор «приветмира» намного меньше, проще, быстрее, и для «приветмира» генерит почти идеальный код даже для 51-х.

> Иногда лажа просто сама возникает вследствие сущности, которую требуется адаптировать.
> Прицел «а сделаем-ка фигак-фигак-и-в-продакш^Wдебиан, а там посмотрим» вполне
> себе имеет место быть.

причём практически везде.

>> а потом может оказаться, что вариантов осталось примерно два: или полностью переделать
>> кодоген, потому что упс… не учли кое-что.
> Опыт показывает, что такое бывает настолько исключительно редко при корректной изначальной
> архитектуре, что можно это не учитывать.

хм. а мне мой многолетний опыт разработки JIT-ов показывает, что «как лучше» при разрастании проекта всё равно превращается в «как всегда». потому что начинали, например, на x86, а потом пришли армы с условными флажками в каждой инструкции — и кодоген оказался… ну, скажем так, не очень хорошим в новых условиях. ок, сделали по-новому… а тут тумбочки, зараза, пришли, на которые опять никто не рассчитывал.

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

> Да хватит уже цепляться к этим архитектурам. Давай уже рассматривать «компилятор для
> x86 и производных».

нет, не давай. это ничем не отличается от моего предложения рассматривать мой компилятор «приветмира».

>> ну, -O0 вполне себе быстрый.
> А в clang быстрее.

быстрее. не то, чтобы сильно намного, правда. по крайней мере C++ — быстрее. и тут я испытываю неудержимое желание тоже перейти на аргументы «но мне пофигу, потому что я не ребилдю весь проект после каждого изменения».

>> а сообщения об ошибках благодаря шаблонной магии
>> в c++ всегда были какими-то заклинаниями на древнешумерском.
> На самом деле их даже у гцц можно читать вполне, если не
> упарываться по шаблонам серьёзно.

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

>> когда D примерно
>> по тем же причинам начинает просираться подобными заклинаниями, тоже хочется кого-то
>> убить. или хотя бы спрятаться в бомбоубежище.
> Нет чтоб фронтенд сделать к llvm!

кагбэ есть. и отдельный есть, и ldc есть, и gdc есть. все используют один и тот же официальный фронтэнд для своих бэкэндов.

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

ну да, даже хреновую партитуру можно научиться сносно играть. но партитура всё равно…

Ответить | Правка | К родителю #219 | Наверх | Cообщить модератору

248. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от 0xd34df00d (ok), 10-Фев-15, 17:25 
> я лично с удовольствием убежал на D: у него хотя бы метапрограммирование
> можно и писать без тяжёлых наркотиков, и читать без длительных медитаций.

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

А вообще, личная практика показывает, что любой инструмент после некоторого освоения и опыта использования начинает вызывать ненависть. Серебряной пули нет.

> критерием чего? это утверждение не имеет никакой связи с моим.
> ожидать, что народ ... пойдёт пилить новое
> llvm вполне себе отлично пилится
> утверждение не имеет никакой связи с моим

Ладно.

> пока что ни у кого не получилось.

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

> тогда мы всё-таки возвращаемся к тому, что llvm — оверинжениреное гуано с
> невнятным апи и атомным говнокодом. потому что мой компилятор «приветмира» намного
> меньше, проще, быстрее, и для «приветмира» генерит почти идеальный код даже
> для 51-х.

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

> хм. а мне мой многолетний опыт разработки JIT-ов показывает, что «как лучше»
> при разрастании проекта всё равно превращается в «как всегда». потому что
> начинали, например, на x86, а потом пришли армы с условными флажками
> в каждой инструкции — и кодоген оказался… ну, скажем так, не
> очень хорошим в новых условиях. ок, сделали по-новому… а тут тумбочки,
> зараза, пришли, на которые опять никто не рассчитывал.
> нет, возможно, у тех, у кого есть неограниченое время, неограниченый бюджет и
> будущескоп — у тех всё сразу отлично получается.

Я, конечно, JIT'ы не пилил, но вот кодогенераторы делать приходилось, и не раз. Мой опыт, в общем, слегка с вышеприведённым не согласен.

> нет, не давай. это ничем не отличается от моего предложения рассматривать мой
> компилятор «приветмира».

На самом деле отличается.

> быстрее. не то, чтобы сильно намного, правда. по крайней мере C++ —
> быстрее. и тут я испытываю неудержимое желание тоже перейти на аргументы
> «но мне пофигу, потому что я не ребилдю весь проект после
> каждого изменения».

Я тоже, но темплейтомагия имеет плохое свойство находиться в хедерах.

> а без шаблонов там всё достаточно очевидно.

А без ошибок ещё очевиднее.

> ну за исключением когда gcc
> начинает рассказывать какие-то прохладные истории про vmt, например, что очень сильно
> помогает, если не знать, в каких случаях он так жалуется. правда,
> не знаю, что в тех же случаях clang говорит и воспроизводить
> лень.

Это в каких, например? Я с непонятными прохладными на эту тему не сталкивался.

> ну да, даже хреновую партитуру можно научиться сносно играть. но партитура всё
> равно…

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

Ответить | Правка | К родителю #232 | Наверх | Cообщить модератору

249. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 10-Фев-15, 17:44 
> Я плюсы знаю достаточно хорошо для того, чтобы и читать без медитация,
> и наркотики синтезировать внутривенно.

да ты марсианин. или александреску. хотя это, наверное, одно и то же.

> А вообще, личная практика показывает, что любой инструмент после некоторого освоения и
> опыта использования начинает вызывать ненависть. Серебряной пули нет.

вопрос в количестве ненависти. ну, и возможности поправить инструмент. D я таки ещё могу подпилить под свои нужды (ну да, я псих, я правлю компилятор, если там нет нужной мне фичи, и она не очень сложно добавляется). с C++ такое не прокатит: и компиляторы большие, и его таки используют «в продакшэне», в отличие от D.

> Ладно.

цитировать иногда полезно полностью, а то высказывание может волшебным образом изменить смысл.

>> пока что ни у кого не получилось.
> Как будто медленным и долгим рефакторингом получается, ага.

а про это разговор и не шёл.

> Твоей же логикой, не с чем сравнивать.

так и не начинали.

> Тебе важны архитектуры, но это, мягко скажем, не так и не всё.

и опять не так. не «мне важны архитектуры», а «чтобы полноценно сравнивать, нужно иметь все фичи, в том числе и архитектуры». я уже кучу раз пояснял, почему.

> Зачем ты прикидываешься дурачком с приветмиром и доводишь до абсурда?

потому что ты упорно делаешь то же самое, предлагая сравнивать несравнимое.

>> нет, не давай. это ничем не отличается от моего предложения рассматривать мой
>> компилятор «приветмира».
> На самом деле отличается.

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

>> ну за исключением когда gcc
>> начинает рассказывать какие-то прохладные истории про vmt, например, что очень сильно
>> помогает, если не знать, в каких случаях он так жалуется. правда,
>> не знаю, что в тех же случаях clang говорит и воспроизводить
>> лень.
> Это в каких, например? Я с непонятными прохладными на эту тему не
> сталкивался.

уже не помню точно. помню, что сталкивался и был весьма озадачен — то ли разные декларации класса в разных хидерах, то ли ещё что-то такое. которое, в общем, имеет отношение к vmt, но из ошибки совершенно непонятно, что за фигня.

Ответить | Правка | К родителю #248 | Наверх | Cообщить модератору

252. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от 0xd34df00d (ok), 10-Фев-15, 17:56 
> вопрос в количестве ненависти. ну, и возможности поправить инструмент. D я таки
> ещё могу подпилить под свои нужды (ну да, я псих, я
> правлю компилятор, если там нет нужной мне фичи, и она не
> очень сложно добавляется). с C++ такое не прокатит: и компиляторы большие,
> и его таки используют «в продакшэне», в отличие от D.

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

> цитировать иногда полезно полностью, а то высказывание может волшебным образом изменить
> смысл.

Да вроде б и не поменялось. Ломанулись пилить же, использовать, и так далее. Ну да, gcc по-прежнему развивается. Кто-то ненавидит плюсы, кто-то любит gcc, мало ли причин у людей. Может, стокгольмский синдром у кого.

> и опять не так. не «мне важны архитектуры», а «чтобы полноценно сравнивать,
> нужно иметь все фичи, в том числе и архитектуры». я уже
> кучу раз пояснял, почему.

Нет, чтобы полноценно сравнивать нужно договориться о том, что такое полноценное сравнение. Почему ты отказываешься от критерия «рассматриваем все компиляторы современного языка C++14 под платформу x86»? А, ну да, из такого критерия же gcc выпадает :)
Кроме шуток, мне очень сильно кажется, что ты пытаешься притянуть решение к ответу.

> потому что ты упорно делаешь то же самое, предлагая сравнивать несравнимое.

Как «компиляторы для платформы x86» отлично сравнимые. И туда же ещё какой-нибудь icc добавится отлично, и какое-нибудь гуано мамонта под AIX. Мне вот надо сравнивать и выбирать, что в CC вписывать в мейкфайле, например.

> ага. количеством вырезаных фич. не вижу, почему в контексте темы одни фичи
> вырезать можно, а другие нет.

Потому что компилятор от этого перестаёт быть компилятором плюсов. Если мы рассматриваем не компиляторы плюсов, а компиляторы под avr или компиляторы под более чем 50 платформ, то да, тогда про llvm можно сразу забыть, но зачем?

> уже не помню точно. помню, что сталкивался и был весьма озадачен —
> то ли разные декларации класса в разных хидерах, то ли ещё
> что-то такое. которое, в общем, имеет отношение к vmt, но из
> ошибки совершенно непонятно, что за фигня.

Ну так за нарушение ODR компиляторы больно бьют и вообще не обязаны это диагностировать. Можно было вообще без ошибок остаться и получить очень милые вещи в рантайме.

Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

253. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 10-Фев-15, 18:08 
> Почему ты отказываешься от критерия «рассматриваем все компиляторы современного
> языка C++14 под платформу x86»?

потому что невозможно редуцировать gcc до этого состояния, выяснив историю добавления каждой строки кода и убрав всё, что не относится к x86. единственная реальная возможность привести проекты в соответствие — добавить отсутствующие фичи в llvm.

мы про #87, не забыл? не про то, кто лучше для какой-то платформы, а про то, что создать проект, *полностью* заменяющий gcc, но с лучшей архитектурой — проще с нуля. ключевые слова — «полностью заменяющий». поэтому пока llvm не умеет всего, что умеет gcc, и как минимум с таким же качеством — сравнивать тупо нечего.

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

а без поддержки архитектур — перестаёт быть аналогом gcc и выпадает из условия #87.

Ответить | Правка | К родителю #252 | Наверх | Cообщить модератору

254. "Ричард Столлман выступил против добавления поддержки..."  –1 +/–
Сообщение от 0xd34df00d (ok), 10-Фев-15, 18:10 
Подожди, давай проще. Вот смотри, вот clang/llvm, оно на плюсах всё. А gcc, оно ж сишное почти целиком, сколько там плюсокода-то сейчас? Давай просто скажем, что это всё из-за выбора языка, и чего тянуть. Тогда кланг не станет аналогом вообще никогда, профит!
Ответить | Правка | К родителю #253 | Наверх | Cообщить модератору

255. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 10-Фев-15, 18:16 
> Подожди, давай проще. Вот смотри, вот clang/llvm, оно на плюсах всё. А
> gcc, оно ж сишное почти целиком, сколько там плюсокода-то сейчас? Давай
> просто скажем, что это всё из-за выбора языка, и чего тянуть.
> Тогда кланг не станет аналогом вообще никогда, профит!

а это тут при чём? для сравнения необходимо, чтобы были реализованы все фичи gcc. именно для того, чтобы увидеть, как это изуродовало (или не изуродовало) архитектуру llvm. это в итоге вполне можно сравнивать в отрыве от того, си там или кресты.

Ответить | Правка | К родителю #254 | Наверх | Cообщить модератору

256. "Ричард Столлман выступил против добавления поддержки..."  –1 +/–
Сообщение от 0xd34df00d (ok), 10-Фев-15, 18:20 
Почему? Выбор языка влияет на архитектуру не меньше, чем количество поддерживаемых архитектур, разве нет?
Ответить | Правка | К родителю #255 | Наверх | Cообщить модератору

257. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 10-Фев-15, 18:25 
> Почему? Выбор языка влияет на архитектуру не меньше, чем количество поддерживаемых архитектур,
> разве нет?

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

Ответить | Правка | К родителю #256 | Наверх | Cообщить модератору

258. "Ричард Столлман выступил против добавления поддержки..."  –1 +/–
Сообщение от 0xd34df00d (ok), 10-Фев-15, 18:26 
> нет, конечно. влияет на реализацию аспектов выбраной архитектуры. однако фундаментальной
> разницы между объявлениями классов конструкциями языка или обмазыванием сишными макросами
> нет, это чистая косметика.

Это-то да, а какие-нибудь там темплейты позволяют просто по-другому писать код. Костыли там вставлять не придётся, не знаю.

В качестве примера крайнего случая, на хаскеле и на плюсах я код пишу сильно по-разному, например.

Только с архитектурами ты почему-то это понимаешь, а с языком — нет.

Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

259. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 10-Фев-15, 18:31 
> Только с архитектурами ты почему-то это понимаешь, а с языком — нет.

э? O_O

Ответить | Правка | К родителю #258 | Наверх | Cообщить модератору

260. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от Vkni (ok), 10-Фев-15, 21:54 
> нет, конечно. влияет на реализацию аспектов выбраной архитектуры. однако фундаментальной
> разницы между объявлениями классов конструкциями языка или обмазыванием сишными макросами
> нет, это чистая косметика.

Сложно поверить.

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

С другой стороны, если возьмёшь ассемблер и Паскакаль, напишешь сперва программу на Паскакале, то потом на ассемблере сделаешь, в целом, то же самое. Просто в развёрнутом виде. Т.о. программа на Паскакале будет просто прототипом.

Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

261. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 10-Фев-15, 22:07 
> Сложно поверить.

ну, если кто-то не способен разглядеть архитектуру за реализацией — то это никак не моя проблема.

Ответить | Правка | К родителю #260 | Наверх | Cообщить модератору

281. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от Vkni (ok), 11-Фев-15, 19:25 
> ну, если кто-то не способен разглядеть архитектуру за реализацией — то это
> никак не моя проблема.

Я не знаю. С одной стороны, ты вроде и прав. Обычное ведь дело: создаём прототип на ЯВУ, потом пишем реализацию на Цэ. Разумеется, реализация имеет ту же самую архитектуру, что и прототип. С другой стороны, низкоуровневые языки сдерживают полёт фантазии. А это должно так или иначе влиять на архитектуру.

Видимо, всё несколько тоньше.

Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

282. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от arisu (ok), 11-Фев-15, 19:38 
сдерживают. но не фатально, хоть и неприятно местами.
Ответить | Правка | К родителю #281 | Наверх | Cообщить модератору

285. "Ричард Столлман выступил против добавления поддержки..."  +/–
Сообщение от Аноним (-), 12-Фев-15, 20:38 
>так вот я привёл пример, где начали с нуля и за >10 лет gcc ещё не догнали

во-первых, из этих >10 лет примерно половину LLVM пилилась одним человеком, причем студентом. О поддержке C++ (т.е. о clang) стали задумываться, только когда Латтнер закончил универ и устроился работать в Apple в конце нулевых.

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

Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

118. "Ричард Столлман выступил против добавления поддержки..."  +2 +/–
Сообщение от Аноним (-), 08-Фев-15, 19:23 
> asan, кстати, тоже небось изобретение gcc'овцев, например?

Я вот видел как амдшники в этой СуперФигне два года пилили кодогенератор чтобы он вообще валидный поток команд мог начать генерить. Почему эта СуперШняга с МегаАрхитектурой не в курсе что в природе бывают VLIW, с заморочками по части зависимостей команд - загадка природы. Видимо не такие уж и суперские у яблока были архитекты - сделали шнягу под х86 и прочие армы нужные яблочку по бырому и успокоились. Никакого запаса и продуманности.

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

В результате большой вопорс что приобрели амдшники. После 3 лет долботни у них по прежнему 1 разработчик который в этом разбирается, куча глюков, плохая производительность и прочая. Совершенно не выглядит как EPIC WIN мегаархитектуры. А на х86 оно и по сей день не поддерживает OpenMP. Уже джва года обещают. А до тех пор imagemagic какой-нибудь по прежнему втыкает clang'у в разы. И не знаю кому как, а мне возможность прогрузить все 8 ядер моего компьютера вместо 1 ядра - очень даже в кассу.

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру