После шести месяцев разработки представлен релиз проекта LLVM 17.0 - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59789
Когда наконец будет поддержка s390x? Я уже не могу терпеть!
Есть инфа от знающего человека, что в LLVM скоро ожидаются реальные изменения.
Неужели наконец сможет составить реальную конкуренцию GCC?
Еще годик другой и может так случится что не будет нормального браузера который собирается гцц. Такая вот конкуренция.
Уже пару раз было, но я так понимаю это от того что куски хромонога в жырнолиса впихнули. Код шланг всё ещё не умеет адекватно оптимизировать, хотя казалось бы, да и у проприетарных компиляторов поверх llvm почему-то получается. Такой вот опенсорс.
Хотя компиляцию spidermonkey в gcc тоже ломали, ещё чаще.
Зачем нужно что-то там оптимизировать когда проще обновлять железо раз в год? Оптимизация не актуальна уже лет 15.
Обновлять раз в год что именно? Селероны? Атомы? Пеньки 4 на версию с большим числом мегагерц?
Ты если б умел в компиляцию и потребление знал бы что насиловать проц на 300 ватт чтобы браузером пользоваться - моветон.
Там всего несколько процентов прирост.
А вот компиляция дает и 30 и 50% прирост.
Тут не место для детской неожиданности в стиле "Мама я обослался.".
Аноним, что ж ты так эксперта опеннета размазал? Он уже хотел рассказать что Visual Studio или IntelliJ для командной разработки - отстой и все "клутые гэпээльники" сидят в VIM и дергают gcc
Тут сарказм не понимают)
Так уже составляет, ядро собирается клангом, статический анализатор используют для проверок кода.
Ненадо терпеть, в GCC давно есть.
> Добавлена полная реализация типов nullptr и nullptr_t. Например, можно указывать "void func(nullptr_t); func(0); func((void *)0);".Вот из-а таких уродов, кто в качестве NULL-указателя передает 0 в func(0) и ввели это говно nullptr
Вопрос: почему при сборке libomp скрипты сборки нашли в моей системе CUDA и компильнули какие-то nvptx? Для чего нужна поддержка CUDA в LLVM?Мне так понимается, что обычному пользователю - ни для чего (иначе это собирали бы в дистрах). И это только для нейросеток.
Ffmpeg использует llvm в большинстве дистрибутивов, чтобы он использовал нормальные проприетарные либы его надо настраивать и компилировать отдельно (поэтому и фильтры только плохие будут, когда с llvm скомпилировано).
Ну, я собираю ffmpeg при помощи GCC. С флагами --enable-nonfree и --enable-nvenc. Тогда как cuvid и прочее не знаю зачем нужно, если есть nvenc (может рукастым ребятам с рутрекера для рипов нужно что-то более качественное, чем nvenc). А вот fbc - имбовая фича, жаль что заблокана по дефолту.
Не, это отдельно и авторы ffmpeg пытаются убедить что надо переходить на плохой вариант с llvm. Там флаги --enable-nonfree --enable-cuda --enable-nvenc --enable-nvdec --enable-ffnvcodec --disable-cuda-llvm --enable-cuda-nvcc --enable-libnpp. Но это имеет смысл только когда что-то кодируешь видеокартой, что не очень актуально на практике. Фильтры через libnpp не такие корявые, там и так качество ниже плинтуса.
Что? Кодировать на видеокарте не актуально? Я вот например пережимаю сериал. Скачал bdremux, каждая серия по 25 гб, кодирую под вендой через staxrip, H265 nvenc preset P7, vbr, bitrate 8000, -multipass 2pass-full результат примерно под 4гб на серию, качество судя по SSIM, VMAF в FFMetrics практически 99.7-9%. На моем томогочике вместо процессора кодируется 15 фпс, на видеокарте 90-150 фпс в зависимости от сцены.
Очень неактуально. Картинка паршивая от кодера, фильтры только дефективные или профита практически не будет если кадры туда-сюда гонять. А метрики не учитывают дефекты которые прекрасно видно глазами. Дело твоё конечно, но будь ты проклят, если ты собираешься это слить в интернет.
Ты явно болен. Последние версии nvenc с vbr битрейтов с пресетом P7 кодируют на уровне и сравнимо с preset medium в x265. VBR работает по принципу если сцене нужно больше битрейта он возмет больше битрейта. Например, для сцены с высохшей травой и деревьями битрейт идет 15 мбит и никаких квадратов нет. FFMetrics сравнивают идентичность два кадра из оригинала и пользовательского файла и использует возможности ffmpeg. VMAF написали в Netflix, а не на чугуноплавильном заводе имени Ильича Ленина.Но если у тебя 16 ядерный 5ггц Intel ты можешь вполне успеть пожарить яишницу с пресетом slow. Все что быстрее пресета medium на x265 дает худшие результаты по сравнению с nvenc.
Нет, ты. Я знаю, что такое vmaf, получше тебя, и он проморгает кучу дефектов и артефактов. А medium у x265 низкосортный мусор, о чём и речь (хотя даже до него не дотянет). Аппаратные кодеки хорошо выглядят только на графиках и в синтетических условиях. Пойдёт только для тестового предрендера.
> Нет, ты. Я знаю, что такое vmaf, получше тебя, и он проморгает
> кучу дефектов и артефактов. А medium у x265 низкосортный мусор, о
> чём и речь (хотя даже до него не дотянет). Аппаратные кодеки
> хорошо выглядят только на графиках и в синтетических условиях. Пойдёт только
> для тестового предрендера.Это говно, то говно. И чем же сударь изволит кодировать? Давай еще скажи veryfast CBR и в путь.
Я кодирую x265-slower с твиками, потому что не могу позволить veryslow, crf 21/24/27. Психовизуальные оптимизации отключить, сао оставить. Смотри тут https://x265.readthedocs.io/en/latest/presets.html -- например, rd имеет очень большое значение для качества картинки. В остальном, зависит от контента, нет универсальных параметров. Кодировать всё подряд nvenc это надо совсем уж не заботиться о качестве.
> Я кодирую x265-slower с твиками, потому что не могу позволить veryslow, crf
> 21/24/27. Психовизуальные оптимизации отключить, сао оставить. Смотри тут https://x265.readthedocs.io/en/latest/presets.html
> -- например, rd имеет очень большое значение для качества картинки. В
> остальном, зависит от контента, нет универсальных параметров. Кодировать всё подряд nvenc
> это надо совсем уж не заботиться о качестве.crf overrated шлак раздувающий размер файла на пустом месте, если ты кодируешь BDRemux в еще один BDRip с битрейтом в 15 мбит никто тебе не запрещает только ты не решаешь никакой пробелмы, размер твоего файла с 25гб упал до 15гб и это уже результат "перекодирования" который уже никто не будет использовать за источник ибо это уже будет накладыванием шума поверх уже существующего шума. Можешь хоть 60фпс 8к апскеил колбасить на slower и анонировать до потери сознания на отсутствия микрошума на небритых волосяных покровах девушек.
Мой результат на глаз отличного качества, и весит 4гб, что уже 4 раза меньше того что на рутрекере назвывают BDRip. Более того мои конвертации в H265 из BDRemux намного лучше того мыльного блеклого треша что на рутекере раньше выкладывали под названием HDCLUB с битрейтом в 15 мбит. Люди качают чтобы побыстрее с хорошим качеством, чтобы посмотреть и удалить файл после, так ведут себя 99% пользователей торрент-пиратки. Твой BDRip с "оптимизациями" посмотрят от силы 100 человек против нескольких тысяч. Тем не менее я кодирую для архива любимых сериалов, и мне потребуется на это дело условные 100ГБ пространства, а не 500гб, в то же время сравнивая качество динамики и сцен с высоким битрейтов, я уже давно пришел к выводу, что пердеть по 5 ФПС по пол дня нет никакого смысла, а уж полностью апгрейдить комп на это дело тем более.
Вот из-за таких кадров с "ококк битрейт давайте я лучше пережму по пятому кругу с потерями" ничего в нормальном качестве не найти уже через год. А так, на трекерах давно можно только ремуксы качать это давно известно. То цвета убьют, то гамму, то артефактами всё засрут. Иногда ещё есть гении с chroma upscaling.
> Вот из-за таких кадров с "ококк битрейт давайте я лучше пережму по
> пятому кругу с потерями" ничего в нормальном качестве не найти уже
> через год. А так, на трекерах давно можно только ремуксы качать
> это давно известно. То цвета убьют, то гамму, то артефактами
> всё засрут. Иногда ещё есть гении с chroma upscaling.Никто не пережимает уже пережатое. Берут оригинал в виде BDRemux где видеопоток с BluRay диска копировался без конвертации.
Блюрей уже пожат и качество может плавать. Но это влияет на артефакты кодировщиков, а вот картинку запарывают криворучки с "программами".
> Я кодирую x265-slower с твиками, потому что не могу позволить veryslow, crf
> 21/24/27. Психовизуальные оптимизации отключить, сао оставить. Смотри тут https://x265.readthedocs.io/en/latest/presets.html
> -- например, rd имеет очень большое значение для качества картинки. В
> остальном, зависит от контента, нет универсальных параметров. Кодировать всё подряд nvenc
> это надо совсем уж не заботиться о качестве.И да можешь выложить тут полностью команду кодирования ffmpeg/x265 чтобы местные эксперты тут посчитали сколько световых лет ушло в черную дыру.
Кодирование с потерями подразумевает, что качество ухудшается в любом случае. Нельзя уменьшить битрейт и сохранить сопоставимое качество. И чем дороже кодирование, тем больше качества в пересчёте на битрейт сохраняется. Давай ещё открою секрет: если кодировать больше, чем в 1 поток, качество картинки уменьшается в прогрессии. Это касается всех кодеков, у разных кодеков различные границы допустимого в пересчёте на разрешению. В этом отношении x265 не самый кошмарный. В общем, мир станет гораздо лучше, если конкретно ты перестанешь генерировать мусор.
>если кодировать больше, чем в 1 поток, качество картинки уменьшается в прогрессии. Это касается всех кодековЭто не так для lossless кодеков. Это не так для кодеков, у которых следующий фрейм не зависит от предыдущего.
>>если кодировать больше, чем в 1 поток, качество картинки уменьшается в прогрессии. Это касается всех кодеков
> Это не так для lossless кодеков. Это не так для кодеков, у
> которых следующий фрейм не зависит от предыдущего.Твоя правда, в теории. Я не сравнивал и не могу ничего сказать по этому поводу. Скорее всего, качество и эффективность кодирования всё равно уменьшатся, но визуальных отличий может и не быть (если это настоящий лосслесс, не фейковый, как это принято).
> Вопрос: почему при сборке libomp скрипты сборки нашли в моей системе CUDA и компильнули какие-то nvptx? Для чего нужна поддержка CUDA в LLVM?
> Мне так понимается, что обычному пользователю - ни для чего (иначе это собирали бы в дистрах). И это только для нейросеток.Обычные пользователи разные бывают - смотря для чего вы используете ваш ПК. CUDA - это использование ядер видеокарты nvidia для вычислений. Фактически вы добавляете дополнительные возможности распараллеливания программ. Штука в целом небесполезная. Но, повторюсь, зависит от целей и задач.
Так-то большинству пользователей как таковой и ПК в общем-то не нужен, если посмотреть здраво.
Я использую CUDA в парочке прог. В том же DaVince Resolve. Однако все те проги, которые я использую, собираются обычным GCC. Поэтому мне и стало интересно, что даёт поддержка CUDA в libomp? Может для нейросеток что-то
> Я использую CUDA в парочке прог. В том же DaVince Resolve. Однако
> все те проги, которые я использую, собираются обычным GCC. Поэтому мне
> и стало интересно, что даёт поддержка CUDA в libomp? Может для
> нейросеток что-тоЕсли вы про эту - https://openmp.llvm.org/ - libomp, то как раз то, что доктор прописал. Если у вас видеокарта ничем серьёзным не занята, то почему бы не нагрузить её парой-другой потоков? Тем более, что в современных программах многопоточность присутствует практически везде.
Потому что вам было пофиг и вы не задавали никакие опции для CMake, оно собрало как авторы посчитали нужным.
ranges::iota до сих пор нет. Реально достало.
Это компилятор от "друзей опенсорса" только для того и существует, чтобы всех печалить и доставать, чтобы те присмотрелись к другим, более проприетарным, продуктам от "друзей".
Используйте GCC под правильной лицензией, и будет вам счастье.
gcc более медленный (менее быстрый) код генерит
gcc под лицензией gpl, правильностью там и не пахнет, как и перспективами.
Что там про Golang?
Вышел 1.21...
tinygo к твоим услугам.
Hello, world что-то 16 кБ.
Теперь bool аж ключевое слово в Си - прогресс:)
Лично мне, 0 - false и 1- true ничем не мешали. Читабельность никак не страдала. Новый стандарт ещё не принят, зачем они впереди паровоза бегут?
Если не вваливать в синтаксис новые и новые тонны сахара с каждым релизом, то чейнджлог очень скудный получится.
Типизация, сэр... Типизация!
Авторы новости умалчивают, но поддержка модулей C++20 там до сих пор полностью так и не реализована. Не говоря уже о такой мелочи, как поставка в виде модулей стандартной библиотеки (хоть это из C++23, - не суть).
Не раз слышу нытьё Си плюс-плюсников про "поддержку модулей". Вы чо там, все из Паскаля перешли что-ли? Модули - чисто Паскальская тема.
Не только Паскаль, система пакетов в Джаве вдохновлена Модулой.
Вот казалось бы, самое важное новшество в плюсах, позволяющее ускорить компиляцию проектов и повысить читаемость кода, до сих пор не реализовано.
precompiled headers, ccache, да что угодно, только не бинарные исходники
Это никак не связано. Хедеры те же тебе дают спокойно указывать на блобы.
Системные бинарные файлы библиотек являются плотью и кровью экосистемы GNU/Linux. Не надо их сравнивать с так называемыми "блобами".
> но поддержка модулей C++20 там до сих пор полностью так и не реализованаи слава богу, хидеры должны быть человекочитаемыми
Store data in flat text files
Модули никак этому не припятствуют. Но тебе не нужно больше будет писать код дважды. Плюс, что гораздо важнее, шаблоны будут вычисляться один раз, а не при каждом включении.
> припятствуютВ Сталкера переиграл?
Самое главное - проекты размером с ядро Линукс не будут компилироваться целыми днями.
Хедеры в подобных проектах - Авгиевы конюшни.
https://www.opennet.ru/opennews/art.shtml?num=56475
Что-нибудь сломают и перестанет собираться.
вся гента вместе с ff у меня собирается два часа на райзене, о каких днях речь?
Это пока ты один. Когда у тебя жирная контора, расходы на сборочные сервера начинают расти неимоверно.
эээ, вот с этого момента поподробнееу вас каждый раз вся контора с нуля всё собирает на одном райзене? про ccache/shared ccache не слышал?
и по какой причине ты со своего вранья про дни сборки спрыгнул на тему количества работников и в принципе на бизнес?
Ой, знаешь сколько я этих пузырей про жирные конторы и миллионы серверов слышал? Начинаешь копать - чел эникейщик с 1.5 писюками и 3 бухгалтершами.
То есть, по-твоему это нормально целых два часа собирать систему?
Ты это можешь нормально сделать либо ночью, либо на выходных.
> Хедеры в подобных проектах - Авгиевы конюшни.Тебя это как конечного пользователя (или админа) не должно волновать. Это головняк системных программистов и мейнтейнеров, которые эти конюшни разбирают не за бесплатно.
От головняков системщиков зависит скорость поддержки оборудования, в т.ч. новых видеокарт. Поэтому стоит волноваться обычному пользователю.
1. поддержка модулей давно есть
2. пока не будет допилена поддержка в CMake, поддержка модулей в компиляторе бесполезна.
Пусть разрабы llvm уже допишут Cmake.
Поддержка модулей в CMake будет допилена в этом году, а вот поддержка модулей компиляторами - ХЗ когда https://www.youtube.com/watch?v=DJTEUFRslbI
Вот бы что-нибудь скопмилировать, да только не знаю что, всё уже придумано и по 100500 раз переписано. Вовремя я свалил из IT, ох вовремя...
Операционные сборщики кончились от gcc-8 и llvm-8/10 так спрогнозировал griggorii дольше фаилы будут в размерах в два раза больше собранные другими компиляторами , тут стает вопрос нужен ли образ iso 4 Gb если можно сделать 2 Gb ?
Эх, жаль в своё время так и не устроился на С++ из-за документов. Пошёл в веб-разработку, а после этого на С++ просто никто не захотел брать.
Зачем тебе сишка? В вебе все бабло, весь бизнес там. Сишечка это скорее призвание но точно не про быстрые деньги, по крайней мере в этой стране. У нас вот в компании джаваскрипт-мaкаки зарабатывают больше чем один единственный сишник который держится всеми силами за эту работу в страхе что его уволят.
> возможности, определённые в будущем Си-стандартеСпасибо, но вот вам ответ - мы не будем выходить за пределы Кернигана-Ритчи.
Слова не мальчика, но мужа.
Навалили странного синтаксического сахара.
Ладно под кресты, там уже давно сошли с ума и вваливают всё что только могут, но кто в С будет юзать вот такое странное в здравом то уме!?
Да, что вы как дети малые!!! Кому надо, те и будут пользоваться; вас никто не заставляет, - вы до сих пор можете оставаться в рамках C90; тоже касается С++.
полностью согласен и поддерживаю Аноним-а 5-го сообщения, что NULL != 0 и далее..ещё может многим неактуально, но печалит отсутствие поддержки legacy кода.. нет backward compatible mode.. приходится в системе, как минимум, держать два компилятора: системный и "старый", а-ля gcc-8.4.0 или типа того.. иначе устаёшь править исходники..
и опции у llvm с gcc не идентичны: -Qunused-arguments и прочее.. иногда бывает быстрее тупо сменить компилятор на часть кода, чем причёсывать сырцы под то или иное..
p.s.: интересно, какая версия шланга будет у OpenBSD-7.4?..
До сих пор LLVM 13-м собирают Firefox и R-Studio, 15-м — Mesa'у, 16-м — FreeBSD, у Chromium собственный однопоточный сборщик на базе LLVM. Теперь вот это вот 17-е...КУДА СТОЛЬКО?!
Причем тут FreeBSD?
А вот это
goto("mov %1, %0\n\tjmp %l[label]" : "=r" (x) : "r" (45) : : label);
точно Си? Двоеточия между строковыми литералами, какие-то аргументы строк в скобках??? Это какое-то языковое расширение?
Встроенный ассемблер - это всегда расширение.