forum.opennet.ru - "Доступен набор компиляторов LLVM 17.0 " (81)

"Доступен набор компиляторов LLVM 17.0 "

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

"Доступен набор компиляторов LLVM 17.0 "	+/–
Сообщение от opennews (??), 21-Сен-23, 13:12
После шести месяцев разработки представлен релиз проекта LLVM 17.0 - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59789
Ответить \| Правка \| Cообщить модератору

Оглавление

Когда наконец будет поддержка s390x Я уже не могу терпеть , Аноним (1), 13:12 , 21-Сен-23, (1)

Есть инфа от знающего человека, что в LLVM скоро ожидаются реальные изменения , Аноним (2), 13:13 , 21-Сен-23, (2)

Неужели наконец сможет составить реальную конкуренцию GCC , Аноним (4), 13:17 , 21-Сен-23, (4) –1

Еще годик другой и может так случится что не будет нормального браузера который , Советский инженер (?), 15:30 , 21-Сен-23, (23) +4

Уже пару раз было, но я так понимаю это от того что куски хромонога в жырнолиса , Аноним (4), 15:38 , 21-Сен-23, (26) –1

Хотя компиляцию spidermonkey в gcc тоже ломали, ещё чаще , Аноним (4), 15:39 , 21-Сен-23, (27)
Зачем нужно что-то там оптимизировать когда проще обновлять железо раз в год Оп, Аноним (47), 17:38 , 21-Сен-23, (47) –3

Обновлять раз в год что именно Селероны Атомы Пеньки 4 на версию с большим чи, Аноним (58), 18:17 , 21-Сен-23, (58) +2

Аноним, что ж ты так эксперта опеннета размазал Он уже хотел рассказать что Vis, Аноним (70), 20:48 , 21-Сен-23, (70) +1

Тут сарказм не понимают , Тот_ещё_аноним (ok), 23:15 , 21-Сен-23, (73) +1

Так уже составляет, ядро собирается клангом, статический анализатор используют д, Аноним (32), 16:00 , 21-Сен-23, (32)

Скрыто модератором, Аноним (-), 13:15 , 21-Сен-23, (3) +6

Скрыто модератором, Аноним (5), 13:19 , 21-Сен-23, (5) +5
Вопрос почему при сборке libomp скрипты сборки нашли в моей системе CUDA и комп, Zenitur (ok), 13:39 , 21-Сен-23, (6) +1

Ffmpeg использует llvm в большинстве дистрибутивов, чтобы он использовал нормаль, Аноним (4), 13:56 , 21-Сен-23, (9) +1

Ну, я собираю ffmpeg при помощи GCC С флагами --enable-nonfree и --enable-nvenc, Zenitur (ok), 14:06 , 21-Сен-23, (11)

Не, это отдельно и авторы ffmpeg пытаются убедить что надо переходить на плохой , Аноним (4), 14:36 , 21-Сен-23, (17)

Что Кодировать на видеокарте не актуально Я вот например пережимаю сериал Ска, cheburnator9000 (ok), 14:49 , 21-Сен-23, (18)

Очень неактуально Картинка паршивая от кодера, фильтры только дефективные или п, Аноним (4), 15:14 , 21-Сен-23, (20) –2

Ты явно болен Последние версии nvenc с vbr битрейтов с пресетом P7 кодируют на , cheburnator9000 (ok), 17:22 , 21-Сен-23, (43) –2

Нет, ты Я знаю, что такое vmaf, получше тебя, и он проморгает кучу дефектов и а, Аноним (4), 17:40 , 21-Сен-23, (50) –1

Это говно, то говно И чем же сударь изволит кодировать Давай еще скажи veryfas, cheburnator9000 (ok), 17:43 , 21-Сен-23, (51) +1

Я кодирую x265-slower с твиками, потому что не могу позволить veryslow, crf 21 2, Аноним (4), 18:12 , 21-Сен-23, (57) –1

crf overrated шлак раздувающий размер файла на пустом месте, если ты кодируешь B, cheburnator9000 (ok), 19:12 , 21-Сен-23, (63) –1

Вот из-за таких кадров с ококк битрейт давайте я лучше пережму по пятому кругу , Аноним (4), 19:33 , 21-Сен-23, (65) –1
Никто не пережимает уже пережатое Берут оригинал в виде BDRemux где видеопоток , cheburnator9000 (ok), 19:38 , 21-Сен-23, (67)
Блюрей уже пожат и качество может плавать Но это влияет на артефакты кодировщик, Аноним (4), 19:43 , 21-Сен-23, (69) –1

И да можешь выложить тут полностью команду кодирования ffmpeg x265 чтобы местные, cheburnator9000 (ok), 19:19 , 21-Сен-23, (64)

Кодирование с потерями подразумевает, что качество ухудшается в любом случае Не, Аноним (4), 19:41 , 21-Сен-23, (68) –1
Это не так для lossless кодеков Это не так для кодеков, у которых следующий фре, Прохожий (??), 07:13 , 22-Сен-23, (80)
Твоя правда, в теории Я не сравнивал и не могу ничего сказать по этому поводу , Аноним (4), 10:47 , 22-Сен-23, (81)

Обычные пользователи разные бывают - смотря для чего вы используете ваш ПК CUDA, ProfessorNavigator (ok), 14:06 , 21-Сен-23, (12) +1

Я использую CUDA в парочке прог В том же DaVince Resolve Однако все те проги, , Zenitur (ok), 14:09 , 21-Сен-23, (13)

Если вы про эту - https openmp llvm org - libomp, то как раз то, что доктор п, ProfessorNavigator (ok), 15:08 , 21-Сен-23, (19)

Потому что вам было пофиг и вы не задавали никакие опции для CMake, оно собрало , Ivan_83 (ok), 12:35 , 22-Сен-23, (86)

ranges iota до сих пор нет Реально достало , Аноним (7), 13:43 , 21-Сен-23, (7)

Это компилятор от друзей опенсорса только для того и существует, чтобы всех пе, Аноним (15), 14:26 , 21-Сен-23, (15) +1

Скрыто модератором, Аноним (40), 17:14 , 21-Сен-23, (40) –2
Скрыто модератором, АнонБатон (?), 17:18 , 21-Сен-23, (42) –2

Что там про Golang , Аноним (10), 14:00 , 21-Сен-23, (10) –1

Вышел 1 21 , Аноним (78), 06:08 , 22-Сен-23, (78) +1
tinygo к твоим услугам Hello, world что-то 16 кБ , Брат Анон (ok), 14:05 , 28-Сен-23, (96) +1

Теперь bool аж ключевое слово в Си - прогресс , Аноним (14), 14:10 , 21-Сен-23, (14) +2

Лично мне, 0 - false и 1- true ничем не мешали Читабельность никак не страдала , Аноним (-), 15:31 , 21-Сен-23, (24) +1

Если не вваливать в синтаксис новые и новые тонны сахара с каждым релизом, то че, YetAnotherOnanym (ok), 16:22 , 21-Сен-23, (37) +3
Типизация, сэр Типизация , Брат Анон (ok), 14:05 , 28-Сен-23, (97)

Авторы новости умалчивают, но поддержка модулей C 20 там до сих пор полностью т, Аноним (16), 14:34 , 21-Сен-23, (16) +4

Не раз слышу нытьё Си плюс-плюсников про поддержку модулей Вы чо там, все из , Аноним (-), 15:20 , 21-Сен-23, (22) –6

Не только Паскаль, система пакетов в Джаве вдохновлена Модулой , Аноним (32), 15:55 , 21-Сен-23, (28) –1

Вот казалось бы, самое важное новшество в плюсах, позволяющее ускорить компиляци, Аноним (32), 15:58 , 21-Сен-23, (29) –1

precompiled headers, ccache, да что угодно, только не бинарные исходники, 12yoexpert (ok), 15:59 , 21-Сен-23, (31) +2

Это никак не связано Хедеры те же тебе дают спокойно указывать на блобы , Аноним (32), 16:02 , 21-Сен-23, (33) +1

Системные бинарные файлы библиотек являются плотью и кровью экосистемы GNU Linux, Аноним (-), 16:10 , 21-Сен-23, (34) –1

и слава богу, хидеры должны быть человекочитаемымиStore data in flat text files, 12yoexpert (ok), 15:58 , 21-Сен-23, (30)

Модули никак этому не припятствуют Но тебе не нужно больше будет писать код два, Аноним (36), 16:13 , 21-Сен-23, (36) +3

В Сталкера переиграл , YetAnotherOnanym (ok), 16:26 , 21-Сен-23, (38) +9
Самое главное - проекты размером с ядро Линукс не будут компилироваться целыми д, Аноним (32), 16:43 , 21-Сен-23, (39)

Что-нибудь сломают и перестанет собираться , Аноним (45), 17:31 , 21-Сен-23, (45)
вся гента вместе с ff у меня собирается два часа на райзене, о каких днях речь , Аноним (48), 17:38 , 21-Сен-23, (48) +1

Это пока ты один Когда у тебя жирная контора, расходы на сборочные сервера начи, Аноним (36), 18:03 , 21-Сен-23, (55)

эээ, вот с этого момента поподробнееу вас каждый раз вся контора с нуля всё соби, Аноним (48), 18:41 , 21-Сен-23, (59)

Ой, знаешь сколько я этих пузырей про жирные конторы и миллионы серверов слышал , Аноним (84), 12:04 , 22-Сен-23, (84) +1

То есть, по-твоему это нормально целых два часа собирать систему Ты это можешь н, Аноним (82), 10:54 , 22-Сен-23, (82)

Тебя это как конечного пользователя или админа не должно волновать Это головн, Аноним (77), 05:27 , 22-Сен-23, (77)

От головняков системщиков зависит скорость поддержки оборудования, в т ч новых , Аноним (82), 10:55 , 22-Сен-23, (83)

1 поддержка модулей давно есть2 пока не будет допилена поддержка в CMake, подд, Аноним (-), 17:16 , 21-Сен-23, (41) –1

Пусть разрабы llvm уже допишут Cmake , Аноним (45), 17:29 , 21-Сен-23, (44) +1
Поддержка модулей в CMake будет допилена в этом году, а вот поддержка модулей ко, Аноним (16), 00:40 , 22-Сен-23, (75)

Вот бы что-нибудь скопмилировать, да только не знаю что, всё уже придумано и по , Аноним (47), 17:35 , 21-Сен-23, (46) +1

Операционные сборщики кончились от gcc-8 и llvm-8 10 так спрогнозировал griggori, Svidetel_polimorfizma (?), 18:06 , 21-Сен-23, (56) –2

Эх, жаль в своё время так и не устроился на С из-за документов Пошёл в веб-ра, Аноним (71), 23:09 , 21-Сен-23, (71) +1

Зачем тебе сишка В вебе все бабло, весь бизнес там Сишечка это скорее призвани, Аноним (77), 05:22 , 22-Сен-23, (76)

Спасибо, но вот вам ответ - мы не будем выходить за пределы Кернигана-Ритчи , Аноним (79), 06:41 , 22-Сен-23, (79) +2

Слова не мальчика, но мужа , Брат Анон (ok), 14:06 , 28-Сен-23, (98)

Навалили странного синтаксического сахара Ладно под кресты, там уже давно сошли , Ivan_83 (ok), 12:45 , 22-Сен-23, (88) +1

Да, что вы как дети малые Кому надо, те и будут пользоваться вас никто не за, Аноним (14), 14:09 , 22-Сен-23, (89) –1

полностью согласен и поддерживаю Аноним-а 5-го сообщения, что NULL 0 и далее , крокодил мимо.. (?), 16:00 , 22-Сен-23, (91)
До сих пор LLVM 13-м собирают Firefox и R-Studio, 15-м 8212 Mesa у, 16-м 82, iZEN (ok), 08:01 , 23-Сен-23, (93)

Причем тут FreeBSD , Аноним (95), 08:43 , 25-Сен-23, (95)

А вот этоgoto mov 1, 0 n tjmp l label r x r 45 label точ, nc (ok), 14:20 , 24-Сен-23, (94)

Встроенный ассемблер - это всегда расширение , Аноним (99), 17:18 , 29-Сен-23, (99)

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

1. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (1), 21-Сен-23, 13:12

Когда наконец будет поддержка s390x? Я уже не могу терпеть!

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

2. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (2), 21-Сен-23, 13:13

Есть инфа от знающего человека, что в LLVM скоро ожидаются реальные изменения.

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

4. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от Аноним (4), 21-Сен-23, 13:17

Неужели наконец сможет составить реальную конкуренцию GCC?

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

23. "Доступен набор компиляторов LLVM 17.0 " +4 +/–

Сообщение от Советский инженер (?), 21-Сен-23, 15:30

Еще годик другой и может так случится что не будет нормального браузера который собирается гцц. Такая вот конкуренция.

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

26. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от Аноним (4), 21-Сен-23, 15:38

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

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

27. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (4), 21-Сен-23, 15:39

Хотя компиляцию spidermonkey в gcc тоже ломали, ещё чаще.

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

47. "Доступен набор компиляторов LLVM 17.0 " –3 +/–

Сообщение от Аноним (47), 21-Сен-23, 17:38

Зачем нужно что-то там оптимизировать когда проще обновлять железо раз в год? Оптимизация не актуальна уже лет 15.

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

58. "Доступен набор компиляторов LLVM 17.0 " +2 +/–

Сообщение от Аноним (58), 21-Сен-23, 18:17

Обновлять раз в год что именно? Селероны? Атомы? Пеньки 4 на версию с большим числом мегагерц?
Ты если б умел в компиляцию и потребление знал бы что насиловать проц на 300 ватт чтобы браузером пользоваться - моветон.
Там всего несколько процентов прирост.
А вот компиляция дает и 30 и 50% прирост.
Тут не место для детской неожиданности в стиле "Мама я обослался.".

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

70. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Аноним (70), 21-Сен-23, 20:48

Аноним, что ж ты так эксперта опеннета размазал? Он уже хотел рассказать что Visual Studio или IntelliJ для командной разработки - отстой и все "клутые гэпээльники" сидят в VIM и дергают gcc

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

73. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Тот_ещё_аноним (ok), 21-Сен-23, 23:15

Тут сарказм не понимают)

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

32. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (32), 21-Сен-23, 16:00

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

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

3. Скрыто модератором +6 +/–

Сообщение от Аноним (-), 21-Сен-23, 13:15

Ненадо терпеть, в GCC давно есть.

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

5. Скрыто модератором +5 +/–

Сообщение от Аноним (5), 21-Сен-23, 13:19

> Добавлена полная реализация типов nullptr и nullptr_t. Например, можно указывать "void func(nullptr_t); func(0); func((void *)0);".
Вот из-а таких уродов, кто в качестве NULL-указателя передает 0 в func(0) и ввели это говно nullptr

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

6. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Zenitur (ok), 21-Сен-23, 13:39

Вопрос: почему при сборке libomp скрипты сборки нашли в моей системе CUDA и компильнули какие-то nvptx? Для чего нужна поддержка CUDA в LLVM?
Мне так понимается, что обычному пользователю - ни для чего (иначе это собирали бы в дистрах). И это только для нейросеток.

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

9. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Аноним (4), 21-Сен-23, 13:56

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

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

11. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Zenitur (ok), 21-Сен-23, 14:06

Ну, я собираю ffmpeg при помощи GCC. С флагами --enable-nonfree и --enable-nvenc. Тогда как cuvid и прочее не знаю зачем нужно, если есть nvenc (может рукастым ребятам с рутрекера для рипов нужно что-то более качественное, чем nvenc). А вот fbc - имбовая фича, жаль что заблокана по дефолту.

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

17. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (4), 21-Сен-23, 14:36

Не, это отдельно и авторы ffmpeg пытаются убедить что надо переходить на плохой вариант с llvm. Там флаги --enable-nonfree --enable-cuda --enable-nvenc --enable-nvdec --enable-ffnvcodec --disable-cuda-llvm --enable-cuda-nvcc --enable-libnpp. Но это имеет смысл только когда что-то кодируешь видеокартой, что не очень актуально на практике. Фильтры через libnpp не такие корявые, там и так качество ниже плинтуса.

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

18. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от cheburnator9000 (ok), 21-Сен-23, 14:49

Что? Кодировать на видеокарте не актуально? Я вот например пережимаю сериал. Скачал bdremux, каждая серия по 25 гб, кодирую под вендой через staxrip, H265 nvenc preset P7, vbr, bitrate 8000, -multipass 2pass-full результат примерно под 4гб на серию, качество судя по SSIM, VMAF в FFMetrics практически 99.7-9%. На моем томогочике вместо процессора кодируется 15 фпс, на видеокарте 90-150 фпс в зависимости от сцены.

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

20. "Доступен набор компиляторов LLVM 17.0 " –2 +/–

Сообщение от Аноним (4), 21-Сен-23, 15:14

Очень неактуально. Картинка паршивая от кодера, фильтры только дефективные или профита практически не будет если кадры туда-сюда гонять. А метрики не учитывают дефекты которые прекрасно видно глазами. Дело твоё конечно, но будь ты проклят, если ты собираешься это слить в интернет.

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

43. "Доступен набор компиляторов LLVM 17.0 " –2 +/–

Сообщение от cheburnator9000 (ok), 21-Сен-23, 17:22

Ты явно болен. Последние версии nvenc с vbr битрейтов с пресетом P7 кодируют на уровне и сравнимо с preset medium в x265. VBR работает по принципу если сцене нужно больше битрейта он возмет больше битрейта. Например, для сцены с высохшей травой и деревьями битрейт идет 15 мбит и никаких квадратов нет. FFMetrics сравнивают идентичность два кадра из оригинала и пользовательского файла и использует возможности ffmpeg. VMAF написали в Netflix, а не на чугуноплавильном заводе имени Ильича Ленина.
Но если у тебя 16 ядерный 5ггц Intel ты можешь вполне успеть пожарить яишницу с пресетом slow. Все что быстрее пресета medium на x265 дает худшие результаты по сравнению с nvenc.

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

50. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от Аноним (4), 21-Сен-23, 17:40

Нет, ты. Я знаю, что такое vmaf, получше тебя, и он проморгает кучу дефектов и артефактов. А medium у x265 низкосортный мусор, о чём и речь (хотя даже до него не дотянет). Аппаратные кодеки хорошо выглядят только на графиках и в синтетических условиях. Пойдёт только для тестового предрендера.

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

51. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от cheburnator9000 (ok), 21-Сен-23, 17:43

> Нет, ты. Я знаю, что такое vmaf, получше тебя, и он проморгает
> кучу дефектов и артефактов. А medium у x265 низкосортный мусор, о
> чём и речь (хотя даже до него не дотянет). Аппаратные кодеки
> хорошо выглядят только на графиках и в синтетических условиях. Пойдёт только
> для тестового предрендера.
Это говно, то говно. И чем же сударь изволит кодировать? Давай еще скажи veryfast CBR и в путь.

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

57. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от Аноним (4), 21-Сен-23, 18:12

Я кодирую x265-slower с твиками, потому что не могу позволить veryslow, crf 21/24/27. Психовизуальные оптимизации отключить, сао оставить. Смотри тут https://x265.readthedocs.io/en/latest/presets.html -- например, rd имеет очень большое значение для качества картинки. В остальном, зависит от контента, нет универсальных параметров. Кодировать всё подряд nvenc это надо совсем уж не заботиться о качестве.

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

63. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от cheburnator9000 (ok), 21-Сен-23, 19:12

> Я кодирую 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 ФПС по пол дня нет никакого смысла, а уж полностью апгрейдить комп на это дело тем более.

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

65. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от Аноним (4), 21-Сен-23, 19:33

Вот из-за таких кадров с "ококк битрейт давайте я лучше пережму по пятому кругу с потерями" ничего в нормальном качестве не найти уже через год. А так, на трекерах давно можно только ремуксы качать это давно известно. То цвета убьют, то гамму, то артефактами всё засрут. Иногда ещё есть гении с chroma upscaling.

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

67. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от cheburnator9000 (ok), 21-Сен-23, 19:38

> Вот из-за таких кадров с "ококк битрейт давайте я лучше пережму по
> пятому кругу с потерями" ничего в нормальном качестве не найти уже
> через год. А так, на трекерах давно можно только ремуксы качать
> это давно известно. То цвета убьют, то гамму, то артефактами
> всё засрут. Иногда ещё есть гении с chroma upscaling.
Никто не пережимает уже пережатое. Берут оригинал в виде BDRemux где видеопоток с BluRay диска копировался без конвертации.

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

69. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от Аноним (4), 21-Сен-23, 19:43

Блюрей уже пожат и качество может плавать. Но это влияет на артефакты кодировщиков, а вот картинку запарывают криворучки с "программами".

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

64. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от cheburnator9000 (ok), 21-Сен-23, 19:19

> Я кодирую x265-slower с твиками, потому что не могу позволить veryslow, crf
> 21/24/27. Психовизуальные оптимизации отключить, сао оставить. Смотри тут https://x265.readthedocs.io/en/latest/presets.html
> -- например, rd имеет очень большое значение для качества картинки. В
> остальном, зависит от контента, нет универсальных параметров. Кодировать всё подряд nvenc
> это надо совсем уж не заботиться о качестве.
И да можешь выложить тут полностью команду кодирования ffmpeg/x265 чтобы местные эксперты тут посчитали сколько световых лет ушло в черную дыру.

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

68. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от Аноним (4), 21-Сен-23, 19:41

Кодирование с потерями подразумевает, что качество ухудшается в любом случае. Нельзя уменьшить битрейт и сохранить сопоставимое качество. И чем дороже кодирование, тем больше качества в пересчёте на битрейт сохраняется. Давай ещё открою секрет: если кодировать больше, чем в 1 поток, качество картинки уменьшается в прогрессии. Это касается всех кодеков, у разных кодеков различные границы допустимого в пересчёте на разрешению. В этом отношении x265 не самый кошмарный. В общем, мир станет гораздо лучше, если конкретно ты перестанешь генерировать мусор.

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

80. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Прохожий (??), 22-Сен-23, 07:13

>если кодировать больше, чем в 1 поток, качество картинки уменьшается в прогрессии. Это касается всех кодеков
Это не так для lossless кодеков. Это не так для кодеков, у которых следующий фрейм не зависит от предыдущего.

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

81. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (4), 22-Сен-23, 10:47

>>если кодировать больше, чем в 1 поток, качество картинки уменьшается в прогрессии. Это касается всех кодеков
> Это не так для lossless кодеков. Это не так для кодеков, у
> которых следующий фрейм не зависит от предыдущего.
Твоя правда, в теории. Я не сравнивал и не могу ничего сказать по этому поводу. Скорее всего, качество и эффективность кодирования всё равно уменьшатся, но визуальных отличий может и не быть (если это настоящий лосслесс, не фейковый, как это принято).

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

12. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от ProfessorNavigator (ok), 21-Сен-23, 14:06

> Вопрос: почему при сборке libomp скрипты сборки нашли в моей системе CUDA и компильнули какие-то nvptx? Для чего нужна поддержка CUDA в LLVM?
> Мне так понимается, что обычному пользователю - ни для чего (иначе это собирали бы в дистрах). И это только для нейросеток.
Обычные пользователи разные бывают - смотря для чего вы используете ваш ПК. CUDA - это использование ядер видеокарты nvidia для вычислений. Фактически вы добавляете дополнительные возможности распараллеливания программ. Штука в целом небесполезная. Но, повторюсь, зависит от целей и задач.
Так-то большинству пользователей как таковой и ПК в общем-то не нужен, если посмотреть здраво.

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

13. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Zenitur (ok), 21-Сен-23, 14:09

Я использую CUDA в парочке прог. В том же DaVince Resolve. Однако все те проги, которые я использую, собираются обычным GCC. Поэтому мне и стало интересно, что даёт поддержка CUDA в libomp? Может для нейросеток что-то

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

19. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от ProfessorNavigator (ok), 21-Сен-23, 15:08

> Я использую CUDA в парочке прог. В том же DaVince Resolve. Однако
> все те проги, которые я использую, собираются обычным GCC. Поэтому мне
> и стало интересно, что даёт поддержка CUDA в libomp? Может для
> нейросеток что-то
Если вы про эту - https://openmp.llvm.org/ - libomp, то как раз то, что доктор прописал. Если у вас видеокарта ничем серьёзным не занята, то почему бы не нагрузить её парой-другой потоков? Тем более, что в современных программах многопоточность присутствует практически везде.

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

86. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Ivan_83 (ok), 22-Сен-23, 12:35

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

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

7. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (7), 21-Сен-23, 13:43

ranges::iota до сих пор нет. Реально достало.

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

15. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Аноним (15), 21-Сен-23, 14:26

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

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

40. Скрыто модератором –2 +/–

Сообщение от Аноним (40), 21-Сен-23, 17:14

gcc более медленный (менее быстрый) код генерит

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

42. Скрыто модератором –2 +/–

Сообщение от АнонБатон (?), 21-Сен-23, 17:18

gcc под лицензией gpl, правильностью там и не пахнет, как и перспективами.

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

10. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от Аноним (10), 21-Сен-23, 14:00

Что там про Golang?

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

78. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Аноним (78), 22-Сен-23, 06:08

Вышел 1.21...

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

96. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Брат Анон (ok), 28-Сен-23, 14:05

tinygo к твоим услугам.
Hello, world что-то 16 кБ.

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

14. "Доступен набор компиляторов LLVM 17.0 " +2 +/–

Сообщение от Аноним (14), 21-Сен-23, 14:10

Теперь bool аж ключевое слово в Си - прогресс:)

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

24. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Аноним (-), 21-Сен-23, 15:31

Лично мне, 0 - false и 1- true ничем не мешали. Читабельность никак не страдала. Новый стандарт ещё не принят, зачем они впереди паровоза бегут?

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

37. "Доступен набор компиляторов LLVM 17.0 " +3 +/–

Сообщение от YetAnotherOnanym (ok), 21-Сен-23, 16:22

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

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

97. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Брат Анон (ok), 28-Сен-23, 14:05

Типизация, сэр... Типизация!

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

16. "Доступен набор компиляторов LLVM 17.0 " +4 +/–

Сообщение от Аноним (16), 21-Сен-23, 14:34

Авторы новости умалчивают, но поддержка модулей C++20 там до сих пор полностью так и не реализована. Не говоря уже о такой мелочи, как поставка в виде модулей стандартной библиотеки (хоть это из C++23, - не суть).

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

22. "Доступен набор компиляторов LLVM 17.0 " –6 +/–

Сообщение от Аноним (-), 21-Сен-23, 15:20

Не раз слышу нытьё Си плюс-плюсников про "поддержку модулей". Вы чо там, все из Паскаля перешли что-ли? Модули - чисто Паскальская тема.

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

28. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от Аноним (32), 21-Сен-23, 15:55

Не только Паскаль, система пакетов в Джаве вдохновлена Модулой.

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

29. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от Аноним (32), 21-Сен-23, 15:58

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

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

31. "Доступен набор компиляторов LLVM 17.0 " +2 +/–

Сообщение от 12yoexpert (ok), 21-Сен-23, 15:59

precompiled headers, ccache, да что угодно, только не бинарные исходники

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

33. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Аноним (32), 21-Сен-23, 16:02

Это никак не связано. Хедеры те же тебе дают спокойно указывать на блобы.

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

34. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от Аноним (-), 21-Сен-23, 16:10

Системные бинарные файлы библиотек являются плотью и кровью экосистемы GNU/Linux. Не надо их сравнивать с так называемыми "блобами".

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

30. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от 12yoexpert (ok), 21-Сен-23, 15:58

> но поддержка модулей C++20 там до сих пор полностью так и не реализована
и слава богу, хидеры должны быть человекочитаемыми
Store data in flat text files

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

36. "Доступен набор компиляторов LLVM 17.0 " +3 +/–

Сообщение от Аноним (36), 21-Сен-23, 16:13

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

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

38. "Доступен набор компиляторов LLVM 17.0 " +9 +/–

Сообщение от YetAnotherOnanym (ok), 21-Сен-23, 16:26

> припятствуют
В Сталкера переиграл?

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

39. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (32), 21-Сен-23, 16:43

Самое главное - проекты размером с ядро Линукс не будут компилироваться целыми днями.
Хедеры в подобных проектах - Авгиевы конюшни.
https://www.opennet.dev/opennews/art.shtml?num=56475

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

45. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (45), 21-Сен-23, 17:31

Что-нибудь сломают и перестанет собираться.

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

48. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Аноним (48), 21-Сен-23, 17:38

вся гента вместе с ff у меня собирается два часа на райзене, о каких днях речь?

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

55. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (36), 21-Сен-23, 18:03

Это пока ты один. Когда у тебя жирная контора, расходы на сборочные сервера начинают расти неимоверно.

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

59. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (48), 21-Сен-23, 18:41

эээ, вот с этого момента поподробнее
у вас каждый раз вся контора с нуля всё собирает на одном райзене? про ccache/shared ccache не слышал?
и по какой причине ты со своего вранья про дни сборки спрыгнул на тему количества работников и в принципе на бизнес?

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

84. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Аноним (84), 22-Сен-23, 12:04

Ой, знаешь сколько я этих пузырей про жирные конторы и миллионы серверов слышал? Начинаешь копать - чел эникейщик с 1.5 писюками и 3 бухгалтершами.

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

82. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (82), 22-Сен-23, 10:54

То есть, по-твоему это нормально целых два часа собирать систему?
Ты это можешь нормально сделать либо ночью, либо на выходных.

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

77. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (77), 22-Сен-23, 05:27

> Хедеры в подобных проектах - Авгиевы конюшни.
Тебя это как конечного пользователя (или админа) не должно волновать. Это головняк системных программистов и мейнтейнеров, которые эти конюшни разбирают не за бесплатно.

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

83. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (82), 22-Сен-23, 10:55

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

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

41. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от Аноним (-), 21-Сен-23, 17:16

1. поддержка модулей давно есть
2. пока не будет допилена поддержка в CMake, поддержка модулей в компиляторе бесполезна.

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

44. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Аноним (45), 21-Сен-23, 17:29

Пусть разрабы llvm уже допишут Cmake.

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

75. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (16), 22-Сен-23, 00:40

Поддержка модулей в CMake будет допилена в этом году, а вот поддержка модулей компиляторами - ХЗ когда https://www.youtube.com/watch?v=DJTEUFRslbI

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

46. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Аноним (47), 21-Сен-23, 17:35

Вот бы что-нибудь скопмилировать, да только не знаю что, всё уже придумано и по 100500 раз переписано. Вовремя я свалил из IT, ох вовремя...

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

56. "Доступен набор компиляторов LLVM 17.0 " –2 +/–

Сообщение от Svidetel_polimorfizma (?), 21-Сен-23, 18:06

Операционные сборщики кончились от gcc-8 и llvm-8/10 так спрогнозировал griggorii дольше фаилы будут в размерах в два раза больше собранные другими компиляторами , тут стает вопрос нужен ли образ iso 4 Gb если можно сделать 2 Gb ?

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

71. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Аноним (71), 21-Сен-23, 23:09

Эх, жаль в своё время так и не устроился на С++ из-за документов. Пошёл в веб-разработку, а после этого на С++ просто никто не захотел брать.

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

76. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (77), 22-Сен-23, 05:22

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

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

79. "Доступен набор компиляторов LLVM 17.0 " +2 +/–

Сообщение от Аноним (79), 22-Сен-23, 06:41

> возможности, определённые в будущем Си-стандарте
Спасибо, но вот вам ответ - мы не будем выходить за пределы Кернигана-Ритчи.

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

98. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Брат Анон (ok), 28-Сен-23, 14:06

Слова не мальчика, но мужа.

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

88. "Доступен набор компиляторов LLVM 17.0 " +1 +/–

Сообщение от Ivan_83 (ok), 22-Сен-23, 12:45

Навалили странного синтаксического сахара.
Ладно под кресты, там уже давно сошли с ума и вваливают всё что только могут, но кто в С будет юзать вот такое странное в здравом то уме!?

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

89. "Доступен набор компиляторов LLVM 17.0 " –1 +/–

Сообщение от Аноним (14), 22-Сен-23, 14:09

Да, что вы как дети малые!!! Кому надо, те и будут пользоваться; вас никто не заставляет, - вы до сих пор можете оставаться в рамках C90; тоже касается С++.

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

91. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от крокодил мимо.. (?), 22-Сен-23, 16:00

полностью согласен и поддерживаю Аноним-а 5-го сообщения, что NULL != 0 и далее..
ещё может многим неактуально, но печалит отсутствие поддержки legacy кода.. нет backward compatible mode.. приходится в системе, как минимум, держать два компилятора: системный и "старый", а-ля gcc-8.4.0 или типа того.. иначе устаёшь править исходники..
и опции у llvm с gcc не идентичны: -Qunused-arguments и прочее.. иногда бывает быстрее тупо сменить компилятор на часть кода, чем причёсывать сырцы под то или иное..
p.s.: интересно, какая версия шланга будет у OpenBSD-7.4?..

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

93. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от iZEN (ok), 23-Сен-23, 08:01

До сих пор LLVM 13-м собирают Firefox и R-Studio, 15-м — Mesa'у, 16-м — FreeBSD, у Chromium собственный однопоточный сборщик на базе LLVM. Теперь вот это вот 17-е...
КУДА СТОЛЬКО?!

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

95. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (95), 25-Сен-23, 08:43

Причем тут FreeBSD?

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

94. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от nc (ok), 24-Сен-23, 14:20

А вот это
goto("mov %1, %0\n\tjmp %l[label]" : "=r" (x) : "r" (45) : : label);
точно Си? Двоеточия между строковыми литералами, какие-то аргументы строк в скобках??? Это какое-то языковое расширение?

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

99. "Доступен набор компиляторов LLVM 17.0 " +/–

Сообщение от Аноним (99), 29-Сен-23, 17:18

Встроенный ассемблер - это всегда расширение.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Доступен набор компиляторов LLVM 17.0 "	+/–
Сообщение от Аноним (1), 21-Сен-23, 13:12
Когда наконец будет поддержка s390x? Я уже не могу терпеть!
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Доступен набор компиляторов LLVM 17.0 "	+/–
	Сообщение от Аноним (2), 21-Сен-23, 13:13
	Есть инфа от знающего человека, что в LLVM скоро ожидаются реальные изменения.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Доступен набор компиляторов LLVM 17.0 "	–1 +/–
	Сообщение от Аноним (4), 21-Сен-23, 13:17
	Неужели наконец сможет составить реальную конкуренцию GCC?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Доступен набор компиляторов LLVM 17.0 "	+4 +/–
	Сообщение от Советский инженер (?), 21-Сен-23, 15:30
	Еще годик другой и может так случится что не будет нормального браузера который собирается гцц. Такая вот конкуренция.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Доступен набор компиляторов LLVM 17.0 "	–1 +/–
	Сообщение от Аноним (4), 21-Сен-23, 15:38
	Уже пару раз было, но я так понимаю это от того что куски хромонога в жырнолиса впихнули. Код шланг всё ещё не умеет адекватно оптимизировать, хотя казалось бы, да и у проприетарных компиляторов поверх llvm почему-то получается. Такой вот опенсорс.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "Доступен набор компиляторов LLVM 17.0 "	+/–
	Сообщение от Аноним (4), 21-Сен-23, 15:39
	Хотя компиляцию spidermonkey в gcc тоже ломали, ещё чаще.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Доступен набор компиляторов LLVM 17.0 "	–3 +/–
	Сообщение от Аноним (47), 21-Сен-23, 17:38
	Зачем нужно что-то там оптимизировать когда проще обновлять железо раз в год? Оптимизация не актуальна уже лет 15.
	Ответить \| Правка \| К родителю #26 \| Наверх \| Cообщить модератору


	58. "Доступен набор компиляторов LLVM 17.0 "	+2 +/–
	Сообщение от Аноним (58), 21-Сен-23, 18:17
	Обновлять раз в год что именно? Селероны? Атомы? Пеньки 4 на версию с большим числом мегагерц? Ты если б умел в компиляцию и потребление знал бы что насиловать проц на 300 ватт чтобы браузером пользоваться - моветон. Там всего несколько процентов прирост. А вот компиляция дает и 30 и 50% прирост. Тут не место для детской неожиданности в стиле "Мама я обослался.".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	70. "Доступен набор компиляторов LLVM 17.0 "	+1 +/–
	Сообщение от Аноним (70), 21-Сен-23, 20:48
	Аноним, что ж ты так эксперта опеннета размазал? Он уже хотел рассказать что Visual Studio или IntelliJ для командной разработки - отстой и все "клутые гэпээльники" сидят в VIM и дергают gcc
	Ответить \| Правка \| Наверх \| Cообщить модератору


	73. "Доступен набор компиляторов LLVM 17.0 "	+1 +/–
	Сообщение от Тот_ещё_аноним (ok), 21-Сен-23, 23:15
	Тут сарказм не понимают)
	Ответить \| Правка \| К родителю #47 \| Наверх \| Cообщить модератору


	32. "Доступен набор компиляторов LLVM 17.0 "	+/–
	Сообщение от Аноним (32), 21-Сен-23, 16:00
	Так уже составляет, ядро собирается клангом, статический анализатор используют для проверок кода.
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	3. Скрыто модератором	+6 +/–
	Сообщение от Аноним (-), 21-Сен-23, 13:15
	Ненадо терпеть, в GCC давно есть.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору

5. Скрыто модератором	+5 +/–
Сообщение от Аноним (5), 21-Сен-23, 13:19
> Добавлена полная реализация типов nullptr и nullptr_t. Например, можно указывать "void func(nullptr_t); func(0); func((void *)0);". Вот из-а таких уродов, кто в качестве NULL-указателя передает 0 в func(0) и ввели это говно nullptr
Ответить \| Правка \| Наверх \| Cообщить модератору

6. "Доступен набор компиляторов LLVM 17.0 "	+1 +/–
Сообщение от Zenitur (ok), 21-Сен-23, 13:39
Вопрос: почему при сборке libomp скрипты сборки нашли в моей системе CUDA и компильнули какие-то nvptx? Для чего нужна поддержка CUDA в LLVM? Мне так понимается, что обычному пользователю - ни для чего (иначе это собирали бы в дистрах). И это только для нейросеток.
Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Доступен набор компиляторов LLVM 17.0 "	+1 +/–
	Сообщение от Аноним (4), 21-Сен-23, 13:56
	Ffmpeg использует llvm в большинстве дистрибутивов, чтобы он использовал нормальные проприетарные либы его надо настраивать и компилировать отдельно (поэтому и фильтры только плохие будут, когда с llvm скомпилировано).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Доступен набор компиляторов LLVM 17.0 "	+/–
	Сообщение от Zenitur (ok), 21-Сен-23, 14:06
	Ну, я собираю ffmpeg при помощи GCC. С флагами --enable-nonfree и --enable-nvenc. Тогда как cuvid и прочее не знаю зачем нужно, если есть nvenc (может рукастым ребятам с рутрекера для рипов нужно что-то более качественное, чем nvenc). А вот fbc - имбовая фича, жаль что заблокана по дефолту.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Доступен набор компиляторов LLVM 17.0 "	+/–
	Сообщение от Аноним (4), 21-Сен-23, 14:36
	Не, это отдельно и авторы ffmpeg пытаются убедить что надо переходить на плохой вариант с llvm. Там флаги --enable-nonfree --enable-cuda --enable-nvenc --enable-nvdec --enable-ffnvcodec --disable-cuda-llvm --enable-cuda-nvcc --enable-libnpp. Но это имеет смысл только когда что-то кодируешь видеокартой, что не очень актуально на практике. Фильтры через libnpp не такие корявые, там и так качество ниже плинтуса.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Доступен набор компиляторов LLVM 17.0 "	+/–
	Сообщение от cheburnator9000 (ok), 21-Сен-23, 14:49
	Что? Кодировать на видеокарте не актуально? Я вот например пережимаю сериал. Скачал bdremux, каждая серия по 25 гб, кодирую под вендой через staxrip, H265 nvenc preset P7, vbr, bitrate 8000, -multipass 2pass-full результат примерно под 4гб на серию, качество судя по SSIM, VMAF в FFMetrics практически 99.7-9%. На моем томогочике вместо процессора кодируется 15 фпс, на видеокарте 90-150 фпс в зависимости от сцены.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Доступен набор компиляторов LLVM 17.0 "	–2 +/–
	Сообщение от Аноним (4), 21-Сен-23, 15:14
	Очень неактуально. Картинка паршивая от кодера, фильтры только дефективные или профита практически не будет если кадры туда-сюда гонять. А метрики не учитывают дефекты которые прекрасно видно глазами. Дело твоё конечно, но будь ты проклят, если ты собираешься это слить в интернет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Доступен набор компиляторов LLVM 17.0 "	–2 +/–
	Сообщение от cheburnator9000 (ok), 21-Сен-23, 17:22
	Ты явно болен. Последние версии nvenc с vbr битрейтов с пресетом P7 кодируют на уровне и сравнимо с preset medium в x265. VBR работает по принципу если сцене нужно больше битрейта он возмет больше битрейта. Например, для сцены с высохшей травой и деревьями битрейт идет 15 мбит и никаких квадратов нет. FFMetrics сравнивают идентичность два кадра из оригинала и пользовательского файла и использует возможности ffmpeg. VMAF написали в Netflix, а не на чугуноплавильном заводе имени Ильича Ленина. Но если у тебя 16 ядерный 5ггц Intel ты можешь вполне успеть пожарить яишницу с пресетом slow. Все что быстрее пресета medium на x265 дает худшие результаты по сравнению с nvenc.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Доступен набор компиляторов LLVM 17.0 "	–1 +/–
	Сообщение от Аноним (4), 21-Сен-23, 17:40
	Нет, ты. Я знаю, что такое vmaf, получше тебя, и он проморгает кучу дефектов и артефактов. А medium у x265 низкосортный мусор, о чём и речь (хотя даже до него не дотянет). Аппаратные кодеки хорошо выглядят только на графиках и в синтетических условиях. Пойдёт только для тестового предрендера.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	51. "Доступен набор компиляторов LLVM 17.0 "	+1 +/–
	Сообщение от cheburnator9000 (ok), 21-Сен-23, 17:43
	> Нет, ты. Я знаю, что такое vmaf, получше тебя, и он проморгает > кучу дефектов и артефактов. А medium у x265 низкосортный мусор, о > чём и речь (хотя даже до него не дотянет). Аппаратные кодеки > хорошо выглядят только на графиках и в синтетических условиях. Пойдёт только > для тестового предрендера. Это говно, то говно. И чем же сударь изволит кодировать? Давай еще скажи veryfast CBR и в путь.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Доступен набор компиляторов LLVM 17.0 "	–1 +/–
	Сообщение от Аноним (4), 21-Сен-23, 18:12
	Я кодирую x265-slower с твиками, потому что не могу позволить veryslow, crf 21/24/27. Психовизуальные оптимизации отключить, сао оставить. Смотри тут https://x265.readthedocs.io/en/latest/presets.html -- например, rd имеет очень большое значение для качества картинки. В остальном, зависит от контента, нет универсальных параметров. Кодировать всё подряд nvenc это надо совсем уж не заботиться о качестве.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	63. "Доступен набор компиляторов LLVM 17.0 "	–1 +/–
	Сообщение от cheburnator9000 (ok), 21-Сен-23, 19:12
	> Я кодирую 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 ФПС по пол дня нет никакого смысла, а уж полностью апгрейдить комп на это дело тем более.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	65. "Доступен набор компиляторов LLVM 17.0 "	–1 +/–
	Сообщение от Аноним (4), 21-Сен-23, 19:33
	Вот из-за таких кадров с "ококк битрейт давайте я лучше пережму по пятому кругу с потерями" ничего в нормальном качестве не найти уже через год. А так, на трекерах давно можно только ремуксы качать это давно известно. То цвета убьют, то гамму, то артефактами всё засрут. Иногда ещё есть гении с chroma upscaling.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. "Доступен набор компиляторов LLVM 17.0 "	+/–
	Сообщение от cheburnator9000 (ok), 21-Сен-23, 19:38
	> Вот из-за таких кадров с "ококк битрейт давайте я лучше пережму по > пятому кругу с потерями" ничего в нормальном качестве не найти уже > через год. А так, на трекерах давно можно только ремуксы качать > это давно известно. То цвета убьют, то гамму, то артефактами > всё засрут. Иногда ещё есть гении с chroma upscaling. Никто не пережимает уже пережатое. Берут оригинал в виде BDRemux где видеопоток с BluRay диска копировался без конвертации.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	69. "Доступен набор компиляторов LLVM 17.0 "	–1 +/–
	Сообщение от Аноним (4), 21-Сен-23, 19:43
	Блюрей уже пожат и качество может плавать. Но это влияет на артефакты кодировщиков, а вот картинку запарывают криворучки с "программами".
	Ответить \| Правка \| К родителю #67 \| Наверх \| Cообщить модератору


	64. "Доступен набор компиляторов LLVM 17.0 "	+/–
	Сообщение от cheburnator9000 (ok), 21-Сен-23, 19:19
	> Я кодирую x265-slower с твиками, потому что не могу позволить veryslow, crf > 21/24/27. Психовизуальные оптимизации отключить, сао оставить. Смотри тут https://x265.readthedocs.io/en/latest/presets.html > -- например, rd имеет очень большое значение для качества картинки. В > остальном, зависит от контента, нет универсальных параметров. Кодировать всё подряд nvenc > это надо совсем уж не заботиться о качестве. И да можешь выложить тут полностью команду кодирования ffmpeg/x265 чтобы местные эксперты тут посчитали сколько световых лет ушло в черную дыру.
	Ответить \| Правка \| К родителю #57 \| Наверх \| Cообщить модератору


	68. "Доступен набор компиляторов LLVM 17.0 "	–1 +/–
	Сообщение от Аноним (4), 21-Сен-23, 19:41
	Кодирование с потерями подразумевает, что качество ухудшается в любом случае. Нельзя уменьшить битрейт и сохранить сопоставимое качество. И чем дороже кодирование, тем больше качества в пересчёте на битрейт сохраняется. Давай ещё открою секрет: если кодировать больше, чем в 1 поток, качество картинки уменьшается в прогрессии. Это касается всех кодеков, у разных кодеков различные границы допустимого в пересчёте на разрешению. В этом отношении x265 не самый кошмарный. В общем, мир станет гораздо лучше, если конкретно ты перестанешь генерировать мусор.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "Доступен набор компиляторов LLVM 17.0 "	+/–
	Сообщение от Прохожий (??), 22-Сен-23, 07:13
	>если кодировать больше, чем в 1 поток, качество картинки уменьшается в прогрессии. Это касается всех кодеков Это не так для lossless кодеков. Это не так для кодеков, у которых следующий фрейм не зависит от предыдущего.
	Ответить \| Правка \| Наверх \| Cообщить модератору