LLVM 4.0.0

новая схема номеров версий предусматривает увеличение мажорной версии с каждым новым релизом

лавров.жпг

В чем профит такой наркомании с версионированием? Кроме радости хипстеров, которые хотят каждую неделю «пробовать новую версию».

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

нормальным людям пофиг

Оно и верно ― нормальные люди не знают что такое LLVM.

Вот это владельцам видеокарт амд было обидно.

Новость о LLVM - мини, новость о БаттхертОС - полная. Чего-то я не понимаю %)

Новость о LLVM - мини, новость о БаттхертОС - полная. Чего-то я не понимаю %)

Чего тут непонятного ― там исправлены три ошибки, а тут какая-то минорщина.

греп был задолго до

Вопрос про корутины.

Правильно ли я понимаю, что ни корутины в MSVC ни в clang не используют пул потоков для фонового выполнения задач, а выполняются в том же потоке, в котором они были вызваны изначально? Т.е. не получится как в Go запустить goрутину, которая в фоне выполнит работу и вернет результат по окончанию (через promise, очередь или как-то еще). Вопросы про защиту от многопоточной работы с данными пока оставим в стороне.

Такое мнение у меня возникло, когда читал про LLVM Coroutines (по ссылке из новости), которые в результате оптимизации могут вообще исчезнуть.

Ты косячишь? Погасил звезду?

Только 3.9.1 собрал. (Из-за clang-format.)

Ещё не открыл новость, но у меня уже было плохое предчувствие. Открыл. В начале новости всё тихо. Перематываю в конец... так и есть!

Зря. Помните GCC 4.0? Все заморочились и сделали код для него. Потому что смена первой цифры - это сигнал. А теперь способа дать такой сигнал не будет.

Я ещё понимаю Linux, там с 2.6 фундаментальных изменений не было. Но даже там мсжорная версия - это второе число. А тут - проект, который мутирует, как ДНК черепашки под мутагеном в сумме с гамма-излучением! Крайне неразумно было так делать

Я тоже в шоке. Хотел сам запилить новость, но ты меня опередил =)

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

LLVM релизится раз в пол-года и в каждом релизе ломает совместимость.

Как по мне, так штука очсложная, не удивительно что что-то ломают

LLD

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

А они не говорили, когда у них появится нормальный линковщик?

Также с 4.0.0 проект LLVM присоединился к гонке версий

Когда же кто-нибудт из этих «гонщиков» додумается экспоненту использовать? «новая_нумерация» = exp(«старая_нумерация») - сразу бы всех обогнали.

мажорный релиз будет 5.0.0
обновления к 4.0.0 будут нумероваться 4.0.x.

Зачем тогда «0» посередине оставляют?

Чем lld не нормальный?

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

А они производительность компилятора не поправили? Или опять просадка будет?
А то в 3.8 и 3.9 такие жуткие регрессии произошли, что профита от шланга теперь нет. Собирает столько же сколько и gcc - в 2 раза дольше 3.7.

активно пилят его, есть масштабное исследование на тему сборки ядра линукс им. Можешь в архиве llvm-dev@ почитать.

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

Я прослоупочил новость https://www.infoq.com/news/2017/02/lld-coming-in-llvm-4

А lld будет чувствителен к порядку линковки, как и ld? Или сделают нормально?

Опять поломали все так что теперь ни один сторонний бэк не взлетит?

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

а его вроде как и отправили. если я правильно понял дискус - в этом lld от старого lld осталось одно название. его вроде как в начале третьей ветки выпилили совсем, а потом в конце (3.8) начали запиливать обратно

Если честно, я не в курсе, я lld ваще не трогал, краем глаза видел обсуждения в рассылке, я по llvm/clang (и то, по одной подсистеме) и совсем чуть-чуть по lldb, а по lld, я даже не знаю, могу ли я туда коммитить (не проверял).

А то в 3.8 и 3.9 такие жуткие регрессии произошли, что профита от шланга теперь нет.

А шланг он вовсе не компилятор. Он backend для инструментов типа clang-format, синтаксического анализа и выдачи сообщений об ошибках компиляции и неопределенного поведения.

http://llvm.org/docs/Coroutines.html Корутины тупо делают быстрое переключение (сохраняют callee-saved регистры и некоторые флаги при начальном вызове или resume и меняют указатель стека), возвращают изменённый хендл после suspend. done проверяет закончилось ли выполнение.

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

Да уж, скандалы интриги расследования!

Блин, вот теперь сижу переписываю бэк. Начиная с 3.7 одна и та же функция сначала возвращала указатель, потом значение, теперь снова указатель. Вот нахрена эта моральная мастурбация? Еще веселее только с case-sensitive названиями. Блин, RemoveBranch и removeBranch - оно уже тоже раза три менялось.

Не знаю как в llvm. В msvc коруьины работают через fiberы. API fiberов позволяет вроде запускать их в разных потоках и делать переключение на fiber созданный в другом потоке. Соответственно можно считать на коруьины в другом потоке и ждать ее через тоже вроде можно

Корутины тупо делают быстрое переключение (сохраняют callee-saved регистры и некоторые флаги при начальном вызове или resume и меняют указатель стека), возвращают изменённый хендл после suspend. done проверяет закончилось ли выполнение.

Это ты щас описал корутины boost::context, а в MSVC и clang именно так и не стали делать (https://www.youtube.com/watch?v=Ts-1mWBmTNE). Насколько я понял, корутина в версии от MS - это результат превращения функции в функтор C++ (локальные данные сохраняются в переменных объекта). Причем компилятор разбивает функцию на несколько частей (начальная инициализация, куски между co_yield) и при очередном вызове operator() (оно же coroutine_resume()) срабатывает диспетчер на switch(), который передает управление на метку, с которой нужно продолжить выполнение (а при вызове co_yield() индекс следующей метки сохраняется в переменные объекта). В результате такая корутина работает на одном стеке и для ее работы нужна поддержка компилятора.

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

У меня тоже создалось такое впечатление, но его придется делать вручную (в смысле по стандарту он не предусмотрен). Опять же эти корутины разрабатывались под Windows, а там completion ports сильно отличается от того, что есть в Linux и в результате, потребность в отдельном менеджере там сильно меньше.

В msvc коруьины работают через fiberы

Насколько я понял из https://www.youtube.com/watch?v=Ts-1mWBmTNE, виндовые корутины не используют fibers сами по себе (там сознательно отказались использовать fiber), однако, пользовательский код в этих корутинах вполне может запустить что угодно, в том числе и создавать fibers, нужные для их работы и выполнять их в фоновых потоках. (т.е. когда ты пишешь корутину, которая будет что-то загружать по сети, то она может создать fiber, thread, что угодно, инициализировать начало загрузки и далее работать в другом потоке, однако компилятор сам ничего не знает про fiber, когда генерирует код для корутины и ни к каким fiber его не привязывает). Но, возможно, я что-то не так понял.

IMHO, когда рассказывают про корутины в примерах в документации используют неудачные примеры - там везде примеры с генераторами (для которых никакие корутины не нужны, достаточно функтора). Гораздо интереснее, если бы они рассказали, как на корутине реализовать фоновую закачку по сети (Гор приводит код, но там про виндовый completion port, которому передают callback, и который я не понимаю кто и когда вызывает, в общем мне это осталось не понятно).

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

В msvc коруьины работают через fiberы

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

В общем, не догоняю я смысла этого творения от MS. Генераторы, которые любят использовать в примерах для корутин делаются с таким же успехом через функторы и для этого не надо в язык вводить три новых ключевых слова и заставлять компилятор преобразовывать функцию в функтор, а функции, которые возвращают future<> и что-то делают в фоне с помощью файберов не нужно вызывать повторно (т.е. опять же корутины тут не нужны).

По ходу ты прав, затупил файберов действительно нету. Т.к там stackless corutine. Но они были в await для msvs13))

которому передают callback, и который я не понимаю кто и когда вызывает

он вызывается где то из WinApi и в том callback делается resume корутине которая зделала co_await на соответсвующем awaitable

Блин, вот теперь сижу переписываю бэк

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

Никто и не переписывает

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

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

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

Если стоит задача просто перегнать свой ЯП в бинарь, то разбиратся с LLVM assembly очень муторно, а генерить его сразу в виде структуры в памяти непортируемо между версиями. Вот и хочется плюнуть и сгенерить у себя на выходе текстовый си файл, который потом просто пропустить через gcc не задумываясь. Но да, согласен, задачи разные бывают. Не все программисты до сих пор болеют своим ЯП с блекджеком...

часть скриптом если изменения тривиальные, часть вручную

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

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

Да и нафига тебе на выходе текстовый С если бинарь нужен?

нафига тебе на выходе текстовый С если бинарь нужен?

gcc из любого текстового С сделает бинарь же. И довольно неплохой по качеству к тому же.

gcc из любого текстового С сделает бинарь же

ок... а чем ты текстовый С собрался делать? просто прикрутить транслятор? это с точки зрения оптимизации редкий шлак будет

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

Если суть твоего языка

я бэк пишу вообще-то. ну да ладно.

добавить к С нормальные классы с интерфейсами и пропертями

это у нас что, пачку define теперь языком стало можно назвать?

и кстати - ок, вот есть у тебя транслятор в C. а почему его нужно собирать gcc, а не шлангом?

llvm37-3.7.1_4.txz - 22 987 696 байтов

llvm39-3.9.1_2.txz - 216 339 864 байта

llvm40-4.0.0.r4.txz - 228 886 956 байтов

Компиляторы с каждой новой версией всё жирнее и жирнее...

Если стоит задача просто перегнать свой ЯП в бинарь, то разбиратся с LLVM assembly очень муторно

Если тебе с LLVM assembly разобраться сложно,то сделать свой ЯП вообще неподъемная задача