Хотя да, тогда плюсы именно и называли короткоживущей поделкой для тех, кто не смог в сишечку.
Пример того, что я имею в виду – Линус про C++ и программистов на нем (хотя конкретно этот письмо было и позже 2000, да).
Линус о другом писал - C++ даёт штуки (STL, Boost, исключения), которые обязательно потянут в ядро. С чего вдруг их потянут в ядро, почему? Потому в этом случае плюсовикам можно показать средний палец и грязно выругаться. Это хорошо, а если серьёзно? Да не нравится ему C++ и всё тут. В дискуссии этого года в рассылке прозвучало очевидное:
Note that no one in their sane mind would expect to use all the features of C++. Just like we have "kernel C" (currently a subset of C11 with a relatively large set of allowed compiler-specific extensions) we would have "kernel C++"
Они не меняют стандарт языка, а выпускают новый стандарт.
Если буквоедствовать, то можно возразить, что магазин стандартов ISO старые версии изымает из продажи и помечает их как "отозванные". На что можно возразить - а магазин стандартов IEC - как "пересмотренные" и продолжает продавать. Затем можно возразить им всем: ребята, ну кто покупает WinRAR стандарт, пользуйтесь черновиками. И не испытывайте лишнего пиетета перед стандартом, вон, Linux активно использует расширения GCC и Линус ценности в стандарте не находит, на C++ зачастую тоже пишут под GCC/Clang: "V8 officially dropped support for MSVC" (тыц), "Firefox 63 onward MSVC is not supported" (тыц).
Шитпост звучит как-то безобидно. Эта транс-персона радостно пишет о нём, что нашла "possible anti-semitic dog whistle" (помимо двух других).
И отдельно рассказывает о нескольких расследованиях CoC-нарушений: "меня тайно проинформировали о расследовании насчёт CppCon" и второе "мне удалось узнать из достоверных источников, что кто-то увидел то письмо и перешел к жалобе на нарушение Кодекса", которая отправилась к тому-то, который её перенаправил туда-то, глава которого сообщил жалобщику то-то и то-то.
Одно с другим очень нехорошо сочетается ("anti-semitic dog whistle" && мне тут нашептали о CoC-жалобах).
Первое правило бойцовского к... комитета - не говорить о самом важном. Второе правило комитета - нигде не говорить о самом важном. Дедушка правила знает.
В тексте стандарта ABI нет? Нет. Страуструп об ABI старается не говорить? Старается. Может быть, есть документ а-ля C99 Rationale, где говорилось бы о сохранении ABI как о цели №1? Конечно, нет (и в самом C99 Rationale этого тоже нет). Какой язык на букву R назвал Страуструп в связи с АНБ и безопасностью? Ruby*.
В общем, в его тексте про "path to something that could destroy C++" самое важное как обычно не затрагивается, а в этой статье оно есть.
* Выглядит иронично, но, справедливости ради, в первой версии документа АНБ в одном месте Rust пропустили, Страуструп процитировал этот отрывок.
Последняя крупная новость была в январе, об ответвлении под названием "язык OpenD". Если про D вспоминать в контексте статьи, то у него есть @safe-атрибут (который, как пишут, на main() охватывает программу целиком), но unsafe-by-default для CISA недостаточно, судя по их таблице: "Memory-unsafe:Assembly, C, C++, C/C++ Header, Cython, D".
----
Создатель D отметился на HN (WalterBright) в обсуждении этой статьи.
Нет. Или просто непривычно. В своём варианте выпрямляю пальцы и перекатываю ладонь вперёд. Большой палец под ладонью ниже других, автоматически нажимает Ctrl в первую очередь, Shift во вторую (хотя Shift+Ctrl тоже сработает)... ОМГ, какая это ерунда.
Ada, Java, C#, D, Rust, Julia -- вот лишь верхушка длинного списка убийц языка C и примкнувшего к нему C++.
В этом списке только Rust целится именно на C и большое будущее ему гарантировано как минимум административными методами: движением правительства США за memory safety. Оно поставило вопрос ребром: не "приёмы безопасной работы с памятью", а "memory-safe языки", не "но в этом коде нет ручной работы с памятью", а "это код на memory-unsafe языке", не "декларация, как сделать мир лучше", а "пошевелитесь, иначе вы скоро заказ не получите". И какие остаются популярные языки кроме Rust в нише языков без сборки мусора?
Есть в ассемблере неопреденное поведение, указатели и ручное управление памятью? Есть, и в этом часть его силы.
Неопределённого поведения в нём всё-таки нет. Чтобы появилось, нужен некий оптимизирующий макроассемблер с тяжёлым прошлым - он должен появиться достаточно давно, чтобы ради оптимизаций оказалось допустимым молча выкидывать некорректный код.
Можно принять этот ход за псевдо-уступку сообществу, чтобы удалить чуть позже, используя как повод непопулярность спрятанной настройки, но она уже 3 года на месте.
Разве они принципиально сложнее жёстких дисков? Цена такая, потому что могут потому что не-энтерпрайзных форматов лент не осталось, спрос на приводы относительно небольшой и неэластичность спроса позволяет эту цену ставить.
Если бы не было этого "наследия" - никому бы в здравом уме и в голову не пришло тащить powershell на Linux.
В nushell и каком-то crush багажа уже написанных скриптов нет (и это не называют легаси), но они именно что тащат powershell в Linux. Только не его самого, а его идеи. Так называемые structured shell лучше масштабируется - с plaintext мы пришли к тому, что в ls уже 60 опций, необходимых для избегания конвейеров (потому что неудобно и новорит сломаться), а структурированные данные в конвейеры вдыхают жизнь. Но мир не идеален, nushell будет ещё долго добираться до v1, а powershell останется тяжеловесным и со старыми архитектурными ошибками.
Выглядит как проверка хабра на прочность (которую хабр провалил), после такого возникают подозрения ко всем статьям на аккаунте.
но и нельзя же утверждать что только из-за bframes пресет назван "placebo"
Поэтому никто этого и не утверждает.
просто в ходе моих экспериментов и проектов с сжатием анимации, такое значение показывало более хорошие результаты.
Достойно и даже требовало бы отдельной статьи, потому что слишком неочевидно. Но в том же абзаце нечеловеческая ошибка при пересказе документации: "B-frames. Количество кадров, используемых алгоритмом для анализа" ("Maximum number of consecutive b-frames").
Но я знаю о очевидных плюсах 10 бит кодировании
Для меня 10-битность вне HDR/WCG неочевидна.
не очень хорошо пытаться принизить мой труд и прибавить себе самому веса подобными утверждениями
Нет, я искренне читаю и стукаюсь об стол. Насчитал 121 опцию в SvtAv1EncApp, что лишь на 5% больше, чем у HEVC NVENC в статье и не знаю, что делать с этим знанием. Представьте себе обзорную статью о компиляторах C++, которая начинается со сравнения количества флагов.
На первый взгляд CRF похож на preset, но на самом деле это менее сложный инструмент, поэтому указание большего или меньшего значения CRF в большей степени зависит от скорости вашего накопителя, нежели от процессора.
Или, скажем, утверждение "я отобрал то, что действительно работает и оказывает значительное влияние на качество изображения, во всех случаях" оспаривает авторитет разработчиков x265, потому что bframes > 8 - это больше, чем в пресете placebo - то есть самом медленном из пресетов, в названии которого польза от выбранного "размена скорости на качество" сравнивается с плацебо.
А "Почти никогда не стоит поднимать планку выше 8 бит" возвращает читателя во времена до H.265. Дело в том, что в H.264 10-битность была в профиле "High 10", для которого нет аппаратных декодеров (не существует то ли вообще, то ли в потребительских устройствах) - телевизоры и приставки в софтовом декодировании захлебнутся, видео будет тормозить, зрители не будучи анимешниками такую тягу к прогрессу не оценят. С приходом H.265 разрядность в 10 бит стала доступна в профиле "Main 10", аппаратные декодеры в него смогли, все вздохнули с облегчением, жить стало лучше, появилась надежда. Проще говоря, предотвращение бандинга теперь стало возможно простым поднятием разрядности, а не дизерингом, расходующим больше битрейта.
Я снёс блок с GOP, пока сам пытаюсь разобраться в ситуации.
Эта статья же сгенерирована? Целиком? Страшно предположить, но сгенерированы даже картинки со сравнением результатов?
Например, GOP - это не Graphics Output Protocol (исправлено, но...), а Group of Pictures (группа кадров), она не специфична для аппаратного кодирования, а следует из идеи межкадрового сжатия ([IBBPBB]I... - вот [GOP], его длина 6 кадров aka keyframe interval), длина может настраиваться в разных энкодерах и по-разному (минимальная/максимальная/фиксированная, для поиска по ffmpeg: -g, -keyint, -keyint_min, -strict_gop), опция из статьи не существует.
Нет, серьёзно, опция не существует. Unrecognized option 'gop'. Гитхаб по repo:FFmpeg/FFmpeg /"-?gop"/ тоже говорит, что не существует (он найдёт только -header_insertion_mode gop). ffmpeg -h encoder=hevc_amf > hevc_amf.txt - пусто. Команда невалидная, но картинка с результатом есть. "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?".
Вы сказали, что x86 мог занять некую нишу, занятую теперь GPU.
Я в ответ спросил, что компании потеряли, если они обе производят GPU и как конкурировать со специализированными ускорителями?
Ничего не потеряли ("подвела жадность" - это возмущение несправедливостью), а если конкурировать, то тоже путём специализированного ускорения (AVX-512, AMX, HBM-память внутри процессора, NPU).
Флопсы говорят о рафинированном "числодроблении". На первом графике могли по ошибке смешать FP32 и FP64 ("Data ... was mainly Wikipedia and the odd mailing list post" ситуацию не проясняет), на втором в конце процессоры отстают в 3 раза в FP64 (график от nvidia, процессоры не уточняются).
К чему был кивок на экспериментальный 80-ядерный процессор? Чтобы возмутиться, что направление осталось экспериментальным. Но нет, x86-числодробилки пошли в продажу. И ради желанного дробления чисел им недостаточно было обрасти ядрами, пришлось мутировать и обзавестись 16-канальной распаянной GDDR5 (а в следующем поколении типа-HBM на подложке + 6 каналов DDR4). Подозреваю, что такие мутанты с распаянной памятью не интересны, но именно они хорошо дробят числа - надо бояться своих желаний.
Зачем обосновывать позицию "CPU так отстают от GPU из-за сговора" ссылкой (второй) на это?
GPUs obtain high FLOP rates because they are specialized for highly parallel computations and they have more transistors dedicated to data processing rather than flow control or data caching as in the case of a CPU.
к тому же у интел были HEDT под 2011 сокет, только за очень много денег
Из-за "очень много денег" они совсем не конкурировали. Ближайшее у AMD - склейка из двух FX'ов (Opteron 6300, до 4 сокетов).
FX в некоторых задачах дотягивались до i7, стоя гораздо дешевле. Благо были i7 без графики с 20% скидкой в виде Xeon E3.
Тезис, что "подвела жадность" у @MasterMentor- ерунда:
Intel теперь продаёт для нейронок Gaudi, но должен выкинуть HBM-память и вернуть x86-ядра а-ля Xeon Phi, чтобы стало хуже?
Нишу GPGPU AMD и Intel позорно отдали производителям GPU, среди которых AMD, Intel...
Но допустим, что из производства дешёвых много-многоядерников можно извлечь выгоду, пусть и непонятную мне. Тогда бы он знал, что потомок 80-ядерника вышел в продажу в виде ~60-ядерных Xeon Phi, которые распродавались в 2014-2015 по $200-$300. Что с ними делать?
10 лет назад в сервер можно было упихнуть 48 "больших" x86-ядер, 9 лет назад - уже 144. Зачем терять деньги, предлагая то же самое потребителям со скидкой? Получится нехорошая конкуренция между товарами. Зачем им было спешить с многоядерностью, если конкурентов тогда не было? Сейчас надо догонять Apple и проблема тоже не в количестве ядер.
Линус о другом писал - C++ даёт штуки (STL, Boost, исключения), которые обязательно потянут в ядро. С чего вдруг их потянут в ядро, почему? Потому в этом случае плюсовикам можно показать средний палец и грязно выругаться. Это хорошо, а если серьёзно? Да не нравится ему C++ и всё тут. В дискуссии этого года в рассылке прозвучало очевидное:
Note that no one in their sane mind would expect to use all the features of C++. Just like we have "kernel C" (currently a subset of C11 with a relatively large set of allowed compiler-specific extensions) we would have "kernel C++"
Если буквоедствовать, то можно возразить, что магазин стандартов ISO старые версии изымает из продажи и помечает их как "отозванные". На что можно возразить - а магазин стандартов IEC - как "пересмотренные" и продолжает продавать. Затем можно возразить им всем: ребята, ну кто покупает
WinRARстандарт, пользуйтесь черновиками. И не испытывайте лишнего пиетета перед стандартом, вон, Linux активно использует расширения GCC и Линус ценности в стандарте не находит, на C++ зачастую тоже пишут под GCC/Clang: "V8 officially dropped support for MSVC" (тыц), "Firefox 63 onward MSVC is not supported" (тыц).Шитпост звучит как-то безобидно. Эта транс-персона радостно пишет о нём, что нашла "possible anti-semitic dog whistle" (помимо двух других).
И отдельно рассказывает о нескольких расследованиях CoC-нарушений: "меня тайно проинформировали о расследовании насчёт CppCon" и второе "мне удалось узнать из достоверных источников, что кто-то увидел то письмо и перешел к жалобе на нарушение Кодекса", которая отправилась к тому-то, который её перенаправил туда-то, глава которого сообщил жалобщику то-то и то-то.
Одно с другим очень нехорошо сочетается ("anti-semitic dog whistle" && мне тут нашептали о CoC-жалобах).
Первое правило
бойцовского к... комитета - не говорить о самом важном. Второе правило комитета - нигде не говорить о самом важном. Дедушка правила знает.В тексте стандарта ABI нет? Нет. Страуструп об ABI старается не говорить? Старается. Может быть, есть документ а-ля C99 Rationale, где говорилось бы о сохранении ABI как о цели №1? Конечно, нет (и в самом C99 Rationale этого тоже нет). Какой язык на букву R назвал Страуструп в связи с АНБ и безопасностью? Ruby*.
В общем, в его тексте про "path to something that could destroy C++" самое важное как обычно не затрагивается, а в этой статье оно есть.
* Выглядит иронично, но, справедливости ради, в первой версии документа АНБ в одном месте Rust пропустили, Страуструп процитировал этот отрывок.
"\R matches any Unicode newline sequence", поддерживается только в диалектах PCRE и Java (среди диалектов на regex101).
А для Notepad++, вообще говоря, это было не нужно, в нём есть отдельная команда (Edit => Line Operations => Remove Empty Lines).
Последняя крупная новость была в январе, об ответвлении под названием "язык OpenD". Если про D вспоминать в контексте статьи, то у него есть
@safe-атрибут (который, как пишут, на main() охватывает программу целиком), но unsafe-by-default для CISA недостаточно, судя по их таблице: "Memory-unsafe: Assembly, C, C++, C/C++ Header, Cython, D".----
Создатель D отметился на HN (WalterBright) в обсуждении этой статьи.
Нет. Или просто непривычно. В своём варианте выпрямляю пальцы и перекатываю ладонь вперёд. Большой палец под ладонью ниже других, автоматически нажимает Ctrl в первую очередь, Shift во вторую (хотя Shift+Ctrl тоже сработает)... ОМГ, какая это ерунда.
Привык к этому, большой палец (правой стороной, прижав к ладони): Ctrl + Shift, средний: Esc.
Намекает на существование юниксовых переносов и возможность обработать оба варианта.
(^$\r?\n)+В этом списке только Rust целится именно на C и большое будущее ему гарантировано как минимум административными методами: движением правительства США за memory safety. Оно поставило вопрос ребром: не "приёмы безопасной работы с памятью", а "memory-safe языки", не "но в этом коде нет ручной работы с памятью", а "это код на memory-unsafe языке", не "декларация, как сделать мир лучше", а "пошевелитесь, иначе вы скоро заказ не получите". И какие остаются популярные языки кроме Rust в нише языков без сборки мусора?
Неопределённого поведения в нём всё-таки нет. Чтобы появилось, нужен некий оптимизирующий макроассемблер с тяжёлым прошлым - он должен появиться достаточно давно, чтобы ради оптимизаций оказалось допустимым молча выкидывать некорректный код.
Mozilla услышала эти протесты и вместо удаления компактного интерфейса на самом деле скрыла его за настройкой в about:config.
https://support.mozilla.org/en-US/kb/compact-mode-workaround-firefox
Можно принять этот ход за псевдо-уступку сообществу, чтобы удалить чуть позже, используя как повод непопулярность спрятанной настройки, но она уже 3 года на месте.
Вот это в списке лишнее, было новостью 19 лет назад.
Разве они принципиально сложнее жёстких дисков? Цена такая,
потому что могутпотому что не-энтерпрайзных форматов лент не осталось, спрос на приводы относительно небольшой и неэластичность спроса позволяет эту цену ставить.В nushell и каком-то crush багажа уже написанных скриптов нет (и это не называют легаси), но они именно что тащат powershell в Linux. Только не его самого, а его идеи. Так называемые structured shell лучше масштабируется - с plaintext мы пришли к тому, что в ls уже 60 опций, необходимых для избегания конвейеров (потому что неудобно и новорит сломаться), а структурированные данные в конвейеры вдыхают жизнь. Но мир не идеален, nushell будет ещё долго добираться до v1, а powershell останется тяжеловесным и со старыми архитектурными ошибками.
Выглядит как проверка хабра на прочность (которую хабр провалил), после такого возникают подозрения ко всем статьям на аккаунте.
Поэтому никто этого и не утверждает.
Достойно и даже требовало бы отдельной статьи, потому что слишком неочевидно. Но в том же абзаце нечеловеческая ошибка при пересказе документации: "B-frames. Количество кадров, используемых алгоритмом для анализа" ("Maximum number of consecutive b-frames").
Для меня 10-битность вне HDR/WCG неочевидна.
Нет, я искренне читаю и стукаюсь об стол. Насчитал 121 опцию в SvtAv1EncApp, что лишь на 5% больше, чем у HEVC NVENC в статье и не знаю, что делать с этим знанием. Представьте себе обзорную статью о компиляторах C++, которая начинается со сравнения количества флагов.
Я бы теперь на вашем месте этот ответ тоже доверил ChatGPT...
И предыдущую статью из серии тоже:
Или, скажем, утверждение "я отобрал то, что действительно работает и оказывает значительное влияние на качество изображения, во всех случаях" оспаривает авторитет разработчиков x265, потому что
bframes > 8- это больше, чем в пресетеplacebo- то есть самом медленном из пресетов, в названии которого польза от выбранного "размена скорости на качество" сравнивается с плацебо.А "Почти никогда не стоит поднимать планку выше 8 бит" возвращает читателя во времена до H.265. Дело в том, что в H.264 10-битность была в профиле "High 10", для которого нет аппаратных декодеров (не существует то ли вообще, то ли в потребительских устройствах) - телевизоры и приставки в софтовом декодировании захлебнутся, видео будет тормозить, зрители не будучи анимешниками такую тягу к прогрессу не оценят. С приходом H.265 разрядность в 10 бит стала доступна в профиле "Main 10", аппаратные декодеры в него смогли, все вздохнули с облегчением, жить стало лучше, появилась надежда. Проще говоря, предотвращение бандинга теперь стало возможно простым поднятием разрядности, а не дизерингом, расходующим больше битрейта.
(а я на всякий случай в вебархив положил)
Эта статья же сгенерирована? Целиком? Страшно предположить, но сгенерированы даже картинки со сравнением результатов?
Например, GOP - это не Graphics Output Protocol (исправлено, но...), а Group of Pictures (группа кадров), она не специфична для аппаратного кодирования, а следует из идеи межкадрового сжатия (
[IBBPBB]I...- вот [GOP], его длина 6 кадров aka keyframe interval), длина может настраиваться в разных энкодерах и по-разному (минимальная/максимальная/фиксированная, для поиска по ffmpeg:-g, -keyint, -keyint_min, -strict_gop), опция из статьи не существует.Нет, серьёзно, опция не существует.
Unrecognized option 'gop'. Гитхаб поrepo:FFmpeg/FFmpeg /"-?gop"/тоже говорит, что не существует (он найдёт только-header_insertion_mode gop).ffmpeg -h encoder=hevc_amf > hevc_amf.txt- пусто. Команда невалидная, но картинка с результатом есть. "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?".qp_i 20=>-qp_i 20qp_P21=>-qp_p 21AMF - не блок GPU, а библиотека для аппаратного энкодера VCE, который появился на кристалле в 2011, до 2016 к нему лишь получали доступ не через AMF.
Вы сказали, что x86 мог занять некую нишу, занятую теперь GPU.
Я в ответ спросил, что компании потеряли, если они обе производят GPU и как конкурировать со специализированными ускорителями?
Ничего не потеряли ("подвела жадность" - это возмущение несправедливостью), а если конкурировать, то тоже путём специализированного ускорения (AVX-512, AMX, HBM-память внутри процессора, NPU).
Флопсы говорят о рафинированном "числодроблении". На первом графике могли по ошибке смешать FP32 и FP64 ("Data ... was mainly Wikipedia and the odd mailing list post" ситуацию не проясняет), на втором в конце процессоры отстают в 3 раза в FP64 (график от nvidia, процессоры не уточняются).
К чему был кивок на экспериментальный 80-ядерный процессор? Чтобы возмутиться, что направление осталось экспериментальным. Но нет, x86-числодробилки пошли в продажу. И ради желанного дробления чисел им недостаточно было обрасти ядрами, пришлось мутировать и обзавестись 16-канальной распаянной GDDR5 (а в следующем поколении типа-HBM на подложке + 6 каналов DDR4). Подозреваю, что такие мутанты с распаянной памятью не интересны, но именно они хорошо дробят числа - надо бояться своих желаний.
Зачем обосновывать позицию "CPU так отстают от GPU из-за сговора" ссылкой (второй) на это?
(48 ядер - что я посчитал?.. 15 шт. в E7-8xxx v2 * 8 сокетов = 120)
Из-за "очень много денег" они совсем не конкурировали. Ближайшее у AMD - склейка из двух FX'ов (Opteron 6300, до 4 сокетов).
FX в некоторых задачах дотягивались до i7, стоя гораздо дешевле. Благо были i7 без графики с 20% скидкой в виде Xeon E3.
Тезис, что "подвела жадность" у @MasterMentor- ерунда:
Intel теперь продаёт для нейронок Gaudi, но должен выкинуть HBM-память и вернуть x86-ядра а-ля Xeon Phi, чтобы стало хуже?
Нишу GPGPU AMD и Intel позорно отдали производителям GPU, среди которых AMD, Intel...
Но допустим, что из производства дешёвых много-многоядерников можно извлечь выгоду, пусть и непонятную мне. Тогда бы он знал, что потомок 80-ядерника вышел в продажу в виде ~60-ядерных Xeon Phi, которые распродавались в 2014-2015 по $200-$300. Что с ними делать?
10 лет назад в сервер можно было упихнуть 48 "больших" x86-ядер, 9 лет назад - уже 144. Зачем терять деньги, предлагая то же самое потребителям со скидкой? Получится нехорошая конкуренция между товарами. Зачем им было спешить с многоядерностью, если конкурентов тогда не было? Сейчас надо догонять Apple и проблема тоже не в количестве ядер.