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

"Первый официальный выпуск rav1e, кодировщика AV1 на языке Rust "	+/–
Сообщение от opennews (?), 09-Ноя-19, 22:06
Состоялся первый выпуск нового высокопроизводительного кодировщика  формата кодирования видео AV1 -  rav1e 0.1, совместно развиваемого сообществами Xiph и Mozilla. Кодировщик написан на языке Rust и отличается от эталонного кодировщика libaom  значительным увеличением скорости кодирования и повышенным вниманием к обеспечению безопасности. Код проекта распространяется под лицензией BSD... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=51837
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–8 +/–
Сообщение от Анонидзе (?), 09-Ноя-19, 22:06
Есть же уже Dav1d
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+24 +/–
	Сообщение от Аноним (3), 09-Ноя-19, 22:09
	Только dav1d — декодер.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	110. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Анонидзе (?), 11-Ноя-19, 18:08
	То есть декодер сделали раньше кодировщика?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	111. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (3), 11-Ноя-19, 18:18
	> То есть декодер сделали раньше кодировщика? Есть по меньшей мере 3 кодировщика помимо сабжа (больше) и 3 декодировщика. Dav1d только декодировщик, работает быстрее libaom (референсной реализации). Спеки открыты, каждый пилит как хочет.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

2. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+5 +/–
Сообщение от Аноним (3), 09-Ноя-19, 22:08
А чё с аналогичными кодировщиками не сравнили? Ну, x265 там хотя бы, и libaom или как там его. Зачем сравнивать несравниваемое?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от антонимус (?), 09-Ноя-19, 22:22
	x265 ограничен глубиной цвета от 8 до 16 битов на пиксель.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	7. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (3), 09-Ноя-19, 22:32
	Сабж не ограничен? Я так картиночки сохранял, емнип пришлось взять tga вместо tiff. Не встречал больше 10 на практике, но 12 вроде уже в ходу (для сравнения, у мониторов ограничение 10 с хаками было, не в курсе как сейчас).
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	35. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от хотел спросить (?), 10-Ноя-19, 04:26
	а это плеать что? цветовой субдискретизации 4:2:0, 4:2:2 и 4:4:4, 8-, 10- и 12-разрядного кодирования глубины цвета
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

4. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
Сообщение от Блокнот.exe (?), 09-Ноя-19, 22:15
А Раст стоит учить?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
	Сообщение от Иван (??), 09-Ноя-19, 22:17
	однозначно, по перфомансу не уступает Си, безопасность на высшем уровне, никаких UB
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	8. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+4 +/–
	Сообщение от IRASoldier_registered (ok), 09-Ноя-19, 22:33
	Rust'у, имхо, пока не хватает чего-то типа LTS. Наподобие стандартов C++98, C++11, С++17 и т.п. Слишком частые релизы для того, чтобы можно было в спокойный, неторопливый продакшен.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	23. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+7 +/–
	Сообщение от Ordu (ok), 10-Ноя-19, 00:02
	> Rust'у, имхо, пока не хватает чего-то типа LTS. Наподобие стандартов C++98, C++11, С++17 и т.п. Есть такое. Rust 2015 и Rust 2018. Ты можешь взять распоследний rustc и сказать ему, что тебя интересует rust 2015, и будет тебе rust 2015. Впрочем они сломали rust 2018 в последней версии раста, переведя из разряда варнингов в разряд еггогов ругань нового борроу-чекера. Но они предупреждали заранее и эти варнинги довольно долго мозолили глаза, было время всё исправить. Они так же планируют сломать rust 2015, через некоторое время, сейчас там пока продолжают быть варнинги. Но это, по-моему, единственное что они ломали. Дело не в стабильности языка, дело в стабильности библиотек. Есть всякие там std, tokio и ряд других, которые достаточно стабильны, но их не так уж и много. Но для того, чтобы набрать достаточное количество и разнообразие стабильных библиотек расту потребуется ещё не меньше пяти лет, а может и лет десять. Это не быстро, потому что такое количество кода требует очень много человекочасов.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	95. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+1 +/–
	Сообщение от Аноним (95), 11-Ноя-19, 14:40
	- Вот смешные пошли программисты... "Дело не в стабильности языка" (Или это только растаманы? Впрочем, само это название тут: пожалуй - намекает)
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	117. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (117), 11-Ноя-19, 21:27
	Проблем со стабильностью языка не должно вроде быть пока все обратно совместимо, разве нет? Комментарий выше говорит про некоторые примеры когда обратная совместимость в последнее время ломалась, но вроде в целом выглядит все не так страшно, если честно. Насколько я понимаю они там говорят что обратная совместимость у вас сломается только если у вас уже баг в коде.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	119. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (119), 12-Ноя-19, 00:52
	Мы о разном.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	122. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (122), 12-Ноя-19, 02:49
	Это не просто варнинги, это баги старого чекера. Так что это не прихоть
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	127. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Ordu (ok), 12-Ноя-19, 03:02
	> Это не просто варнинги, это баги старого чекера. Так что это не > прихоть Я не говорю, что это прихоть, или что так не надо было делать. Но в контексте разговора о стабильности языка, это явное указание на его нестабильность, вне зависимости от причин её.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	9. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+2 +/–
	Сообщение от Блокнот.exe (?), 09-Ноя-19, 22:41
	Что такое UB?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	10. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+3 +/–
	Сообщение от Иван (??), 09-Ноя-19, 22:42
	Undefined behavior
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	14. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+12 +/–
	Сообщение от Аноним (14), 09-Ноя-19, 22:51
	Только вот перформанс сильно хуже C, а UB просто не называют UB. В остальном норм, поиграться полезно
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	16. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+6 +/–
	Сообщение от анонн (ok), 09-Ноя-19, 23:00
	> Только вот перформанс сильно хуже C, а UB просто не называют UB. Ну раз аноним так говорит, то так оно и есть.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	22. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от ПомидорИзДолины (?), 09-Ноя-19, 23:49
	Как там рекурсивный захват мьютексов из стандартной библиотеки поживает?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	33. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–2 +/–
	Сообщение от burjui (ok), 10-Ноя-19, 03:37
	Никак, для этого есть: https://docs.rs/parking_lot/0.9.0/parking_lot/type.Reentrant... Любой желающий может написать RFC, чтобы включили в std, а пока разработчики решают более важные проблемы, т.к. язык ещё относительно молод. Только, ради всего святого, не надо гундеть про 3rd party (это я не лично вам, а всем "критикам"). parking_lot - стандарт де-факто в Rust.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	44. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–2 +/–
	Сообщение от asdasd (?), 10-Ноя-19, 12:31
	В Rust как минимум выделение памяти через подсчет ссылок, а операции увеличения / уменьшения счетчика атомарные, что ни разу не быстро.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	52. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+3 +/–
	Сообщение от Аноним84701 (ok), 10-Ноя-19, 14:21
	> В Rust как минимум выделение памяти через подсчет ссылок, а операции увеличения > / уменьшения счетчика атомарные, что ни разу не быстро. Хм, т.е. на самом деле "занятия любовью" с владениями/заимствованиями -- это чисто из любви к мазохизму, а не потому что при этом компилятор может отслеживать владельца (ссылки) и автоматически вставлять освобождалку памяти при выходе владельца за пределы области видимости?
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	80. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+3 +/–
	Сообщение от Ordu (ok), 10-Ноя-19, 20:15
	> В Rust как минимум выделение памяти через подсчет ссылок Кто это тебе сказал такое? Rc и Arc -- это один из способов выделять память, но я чаще сталкиваюсь с памятью выделенной через Box, или даже ещё чаще с памятью, выделенной на стеке. Rust способствует тому, чтобы не дёргать кучу почём зря, потому что одной из его selling points (продажных точек?) является отслеживание времени жизни объектов на этапе компиляции, можно выделять на стеке, возвращать объекты, лежащие на стеке и вообще творить всё что угодно: если борроу-чекер съел, значит всё ок. В C тоже так можно, но C менее агрессивно инлайнит, по дефолту считает что всё mutable (а это значит больше работы для memcpy при передаче по значению), и требует внимательного отслеживания того, что ты возвращаешь: ты возвращаешь структуру по значению, и тебе надо помнить, не клал ли ты в эту структуру, нечаянно, указателей на стек. Поэтому на C так пишут только реально крутые ребята, типа Торвальдса и его банды, остальные предпочитают выделять -- мемлик лучше, чем разадресация висячего указателя.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	96. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (95), 11-Ноя-19, 14:49
	Ага... Проверка индексов массивов в runtime, и всё прочее - типа бесплатно?... Так что ничего не удивительно что: цитата:"из-за усложнения алгоритмов требует существенно больше времени для кодирования (по скорости кодирования libaom отстаёт от libvpx-vp9 в (!)сотни раз, а от x264 в (!)тысячи раз)" Т.к."усложнения алгоритмов" - без публичного сравнения по скорости с полноценно оптимизированным вариантом на Си(+SIMD+Asm) это деза, как причина таких убер-тормозов.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	98. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Ordu (ok), 11-Ноя-19, 15:14
	> Ага... Проверка индексов массивов в runtime, и всё прочее > - типа бесплатно?... Ты читал вообще о чём речь? Речь идёт о счётчиках ссылок, а не о массивах и индексах. Но если тебе интересно поговорить про индексы, то да, эти проверки бесплатны в рантайме, дополнительная сложность выражается числами неотличимыми от статистической погрешности. Тому есть две причины: 1. агрессивный инлайн, оптимизация на фоне отслеживания владельца массива (оптимизатор может полагаться на то, что если поле size в динамическом массива де факто константно в данном куске кода, значит оно константно и никто исподтишка его не поменяет), вырезают большую часть проверок или хотя бы выкидывают их из циклов наружу 2. эти проверки всегда выполняются, значит их можно оптимизировать так, чтобы предсказатель переходов процессора всегда их угадывал правильно, и не сбивал бы конвеер. В тех же случаях когда эти проверки не выполняются, производительность уже внезапно становится не важна. > Т.к."усложнения алгоритмов" - без публичного сравнения по скорости с полноценно оптимизированным вариантом на Си(+SIMD+Asm) это деза, как причина таких убер-тормозов. Перечитай новость, там не сказано, что rust быстрее чем C. Там сказано, что данная реализация быстрее какой-то другой реализации. Там не сказано, что она быстрее из-за того, что написана на rust'е. Если тебе это всё равно не даёт покоя, возьми и напиши полноценно-оптимизированный вариант на C(+SIMD+Asm) -- я буду только рад, если тебе удастся сделать быстрее: мне нравится кодировать видео в небольшие объёмы, и время кодирования напрягает.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	108. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
	Сообщение от Аноним (95), 11-Ноя-19, 16:55
	Для начала скажу - не тыкай другим, хамя. > "эти проверки бесплатны в рантайме, дополнительная сложность выражается числами неотличимыми от статистической погрешности" Да, ну - потому наверное в Си[++] её и не делают... (а, в GCC сделав - выкинули в последующих версиях, в Delphi же выключали всегда в не DEBUG, кто нт тот сознательно доп.тормозил). И я сказал - и другие случаи, всякие как раз фичи, раста. Они вовсе не бесплатны, тем более при типичном активном их использовании. > "возьми и напиши полноценно-оптимизированный вариант на C(+SIMD+Asm)" - Потратить кучу времени(чуть менее чем ~пол жизни) - только на изучние их кодека(и без оптимизаций)? А, что ещё?!...
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	115. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+2 +/–
	Сообщение от Ordu (ok), 11-Ноя-19, 20:37
	> Для начала скажу - не тыкай другим, хамя. Скажи ещё раз, мне нравится эротичный звук твоего голоса. >> "эти проверки бесплатны в рантайме, дополнительная сложность выражается числами неотличимыми от статистической погрешности" > Да, ну - потому наверное в Си[++] её и не делают... Что значит не делают? Делают. Загляни в код vector. Её не делают для родных массивов языка, да и то только потому, что эти родные массивы -- тяжкое наследие C, который до конца так и не научился различать массивы и указатели. И какой дурак в C++ будет использовать эти встроенные "массивы"? Они не массивы, а указатели, и их разадресация -- это чистой воды арифметика с указателями, только вместо оператора + там используется оператор [], но на этом различия и заканчиваются. > в GCC сделав - выкинули в последующих версиях, Интересно почему? Навскидку я предположу, что в C невозможно осмысленно проверять индексы на выход за границы, потому что границы эти есть только в голове у программиста. Ну, скажем, если я пишу person->name[-2], то это вполне валидный код в C и C++. И с точки зрения C и C++ тут вовсе не факт, что есть выход за границы массива. И самое что интересное, в C вполне можно наткнуться на подобное. То есть проверки индекса на выход за границы -- это отказ от обратной совместимости с кодом. > в Delphi же > выключали всегда в не DEBUG, кто нт тот сознательно доп.тормозил). Если кто-то там в третьем тысячелетии выключал проверку индексов на выход за границы при написании софта для процессоров десктопного класса, то это свидетельствует лишь о том, что они тупые идиоты, которые про оптимизацию слышали два раза и оба были на лекции восьмидесятелетнего профессора, который уже полвека как потерял способность усваивать новые идеи. Техники оптимизации этих проверок, типа выноса их за пределы циклов, были известны ещё в 70-х. И уже тогда, на всяких там паскалях показывали, что при использовании этих техник, проверок на выход за границы всё равно остаётся больше, чем требуется при ручном их расставлении, но уже тогда всё было больше похоже на статистические погрешности, нежели на что-то существенное. Если тебе интересно почему ты возражаешь против автоматических проверок, то я тебе расскажу остаток истории. Тогда появился C, тупо инженерная поделка людей, кто писал язык не заботясь о его качестве. И хрен бы с ним, но на нём написали Unix. Этот Unix в силу того, что на Bell Labs распространялись антимонопольные ограничения, не мог быть коммерциализирован в тот момент, поэтому Bell Labs стала раздавать его в виде сорцов. Unix тогда был хипстерством: какой дурак будет писать ОС на языке высокого уровня? Но за счёт бесплатности и портабельности он распространился по ВУЗам. Потом когда у Bell Labs появилась возможность сделать из Unix прибыльный проект, было уже поздно, Unix был везде. И Unix вытащил C в топ и сделал из него lingua franca программирования. И хрен бы с ним, но нарождающиеся личинки программистов, видя схожесть всяких там Pascal'ей и C, чувствовали свою ущербность, вне зависимости от того, что они выбрали -- Pascal или C. Особенно когда они входили в тот возраст, где самоутверждение является главным мотивом. И естественно они начинали изобретать аргументы в пользу того или иного языка. И изобретали они их очень просто: надо взять любое отличие языка, и сказать что язык выбранный мною по этому свойству лучше. Таким образом зародился холивар C vs Pascal. Сегодня это в общем уже дохлый и никому не интересный холивар, но эхо от него долетает до нас в виде, например, твоих заявлений о том, что автоматическая проверка на выход за границы -- это ужасно медленно. > И я сказал - и другие случаи, всякие как раз фичи, раста. > Они вовсе не бесплатны, тем более при типичном активном их использовании. Какие случаи? Ты о чём, детка? >> "возьми и напиши полноценно-оптимизированный вариант на C(+SIMD+Asm)" > - Потратить кучу времени(чуть менее чем ~пол жизни) - только на изучние > их кодека(и без оптимизаций)? А, что ещё?!... Да, то есть ты понял, что только для того, чтобы доказывать превосходство языка писать кодек -- это не очень вдохновляющая идея? Если она не вдохновляющая для тебя, то может она и для других не вдохновляющая, а?
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	118. Скрыто модератором	–1 +/–
	Сообщение от Аноним (118), 12-Ноя-19, 00:47
	>> Для начала скажу - не тыкай другим, хамя. > Скажи ещё раз, мне нравится эротичный звук твоего голоса. - Галлюцинации, о никогда не слышимом. К доктору! >>> "эти проверки бесплатны в рантайме, дополнительная сложность выражается числами неотличимыми от статистической погрешности" >> Да, ну - потому наверное в Си[++] её и не делают... > Что значит не делают? Делают. Загляни в код vector. - Это не массив. Я же сказал - к доктору. > "Её не делают для родных массивов языка, да и то только потому, что эти родные массивы -- тяжкое наследие C, который до конца так и не научился различать массивы и указатели. И какой дурак в C++ будет использовать эти встроенные "массивы"?" - Это массивы как раз - без кавычек. А, используют - всего лишь все Сишники... Но, вам конечно видней кто они... > Они не массивы, а указатели, и их разадресация -- это чистой воды арифметика с указателями, только вместо оператора + там используется оператор [], но на этом различия и заканчиваются. - Подмена массива, идентификатора и указателя - смешиванием в кучу. А, что идентификатор массива указатель на массив - "секрет Полишенеля" только такому "профи" как вы... >> в GCC сделав - выкинули в последующих версиях, > Интересно почему? Очевидно всем кроме вам. Даже если разжевать (выше). > "Навскидку я предположу, что в C невозможно осмысленно проверять индексы на выход за границы, потому что границы эти есть только в голове у программиста. Ну, скажем, если я пишу person->name[-2], то это вполне валидный код в C и C++. И с точки зрения C и C++ тут вовсе не факт, что есть выход за границы массива. И самое что интересное, в C вполне можно наткнуться на подобное. То есть проверки индекса на выход за границы -- это отказ от обратной совместимости с кодом." - Вот и нет, проверка была опциональной. А, person->name[-2] - хак, за который несёт ответственность его автор (в отл. от доступа по указателю), т.к.массивы в Си только с 0. И проверка была даже далеко не везде, насколько я предполагаю только для статических массивов и легко адресумых в них указателей, а не любых указателей, так что ваш пример - вообще ещё и мимо. Но, даже такая ограниченная проверка - всёравно неприемлема... в языке ориентированном на достижение максимальной производительности, в отличие от прочих, вроде Rust c C# или Pyton с LUA, это только декларируемщих на словах... >> в Delphi же выключали всегда в не DEBUG, кто нт тот сознательно доп.тормозил). > Если кто-то там в третьем тысячелетии выключал проверку индексов на выход за границы при написании софта для процессоров десктопного класса, то это свидетельствует лишь о том, что они тупые идиоты, которые про оптимизацию слышали два раза и оба были на лекции восьмидесятелетнего профессора, который уже полвека как потерял способность усваивать новые идеи. Да, я уже понял - все тупые кроме вас... ...козла - даже по собственному признанию - "Спросил бы, я бы тебе так сказал, что я козёл. Бееее" https://www.opennet.dev/openforum/vsluhforumID3/118938.html#141 ... skipped бред / дезъинформация _>> Если тебе интересно почему ты возражаешь против автоматических проверок, то я тебе расскажу остаток истории. Тогда появился C, тупо инженерная поделка людей, кто писал язык не заботясь о его качестве. O_o... И особо одарённым: я не возражаю против автоматических проверок, я возражаю против наглых и лживых утверждений что они бесплатны. Дезъинформации что Rust ровня Си по производительности. ... skipped бред / дезъинформация
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	121. Скрыто модератором	–1 +/–
	Сообщение от Ordu (ok), 12-Ноя-19, 02:21
	> - Это не массив. Я же сказал - к доктору. Ты уверен, что к доктору мне, а не тебе? Что по-твоему такое std::vector, если не массив? Может ты думаешь, что это дерево? > - Это массивы как раз - без кавычек. А, используют - всего лишь все Сишники... Но, вам конечно видней кто они... Это как раз "массивы". Потому что C не различает массивы и указатели. Это было офигенной фишкой языка поначалу, но сейчас это одна из тех вещей, которая топит и C, и C++. Что-то я начинаю подозревать, что ты не видел массивов нигде, кроме как в C, и при этом ты пытаешься рассуждать о массивах, так? Это глупость, мнение C о массивах -- это довольно специфичное мнение, основной фишкой которой является то, что массив и указатель на первый элемент массива -- это одно и то же. Ты мыслишь о языках программирования, не зная их и глядя на них через призму C, и иначе не умеешь, так? Если ты ещё в состоянии слышать меня, то выслушай совет: пойди и освой lisp. Я бы рекомендовал взять либо racket либо common lisp (sbcl, например). sbcl -- это жёстко и олдфажно, racket -- это очень молодёжно и под смузи зайдёт неплохо. Вообще полезно освоить lisp: repl lisp'а в качестве калькулятора и не только арифметического офигенно заходит. Но мало того, это даст тебе возможность смотреть на C со стороны, а не только изнутри. > - Подмена массива, идентификатора и указателя - смешиванием в кучу. Конечно. Ритчи думал, что так будет круто. Оно поначалу и было круто, но сейчас боком вышло. > А, что идентификатор массива указатель на массив - "секрет Полишенеля" только такому "профи" как вы... Чё? Ты тут как-то слишком сложно завернул, я не понимаю, что ты хочешь сказать. Ты не мог бы перефразировать? > Очевидно всем кроме вам. Даже если разжевать (выше). Тут я опять не понял, но, мне думается, что если "выше" заменить на "ниже", то тогда эта твоя фраза обретает некий смысл: ты ведь ниже предпринял попытку разжевать, так? > - Вот и нет, проверка была опциональной. А, person->name[-2] - хак, за который несёт ответственность его автор (в отл. от доступа по указателю), т.к.массивы в Си только с 0. В C нет массивов. person->name[-2] -- это синтаксический сахар для *(person->name - 2). > И проверка была даже далеко не везде, насколько я предполагаю только для статических массивов и легко адресумых в них указателей, а не любых указателей, так что ваш пример - вообще ещё и мимо. > Но, даже такая ограниченная проверка - всёравно неприемлема... Мне почему-то кажется, что здесь ты излагаешь своё собственное мнение, которые ты сочинил таким образом, чтобы оно подпирало бы твои догмы. Я с радостью соглашусь, что я ошибаюсь, но только после того как увижу ссылку на разработчиков gcc, обосновывающих отказ от проверок на выход за границы массивов. > Да, я уже понял - все тупые кроме вас... Да. Ты можешь спросить у любого здесь. > И особо одарённым: я не возражаю против автоматических проверок, я возражаю против наглых и лживых утверждений что они бесплатны. Дезъинформации что Rust ровня Си по производительности. А я возражаю против необоснованных утверждений. Ты не знаешь rust'а, ты не знаешь как оптимизируются автоматические проверки на выход за границы массива, ты не знаешь как их прожёвывает современный процессор -- всё это незнание я прям в глазах твоих вижу и в твоём эротичном голосе слышу. И несмотря на это ты продолжаешь утверждать, не приводя ни одного аргумента, кроме своей непоколебимой уверенности в своей непоколебимой правоте. У rust'а есть недостатки, но ты про них не знаешь ничего, ты не упомянул ни одного реального недостатка rust'а. Например у него ОГРОМНЫЕ проблемы с разделяемыми библиотеками, эти проблемы проистекают из самой сути языка, и я очень сомневаюсь, что rust когда-нибудь будет решать эти проблемы так, как их решает, например, Swift. Можно ещё упомянуть, что раст провоцирует людей писать переусложнённый код, оверинжиниринг во все поля, там всё так круто, что просто не остановиться, и хочется описать в типах свою программерскую мысль со всеми завитушками, в том числе и с теми, которые нахрен не нужны. Можно упомянуть то, что rust ещё не закончен нифига, тот же async/await сейчас находится на этапе MVP, то есть minimum viable product, то есть его использовать конечно уже можно, но его ещё допиливать и допиливать. Есть основания надеятся, что это допиливание не поломает код, который ты напишешь сегодня, но не факт. Если тебя волнует производительность, то можно упомянуть осложнения работы с указателями, которые приводят к тому, что сложнозаморочные структуры данных в памяти создавать сложно и заморочно. Если тебе это реально интересно, я могу найти ссылку на реп, где мужик пилит аналог libxml2 на расте: он поставил своей целью создать реализацию, которая будет не медленнее libxml2, некоторое время потыкался, и перешёл на raw-указатели для организации структур в памяти. То есть на указатели, которые являются полными аналогами указателей в C. Я сам не вчитывался в его код (надо будет как-нибудь на досуге), но издалека я не вижу в чём прикол писать это на rust'е. И во всяком случае это показывает ограничения раста. Но вместо этих _реальных_ замечаний в отношении раста, ты мне несёшь какой-то бред про проверку на выход за границы массива, не имея за этим бредом никаких аргументов. Ты пойми, если ты приведёшь мне сейчас кусок кода на rust'е, из которого rustc не сможет выкинуть проверку на выход за границы массива, которую следовало бы выкинуть, я буду _очень_ рад. В отличие от тебя, я люблю когда мне доказывают, что я не прав, потому что это приводит к тому, что я самым беспринципным образом изменяю своё мнение, и в следующий раз моим оппонентам становится ещё сложнее доказать мне, что я не прав. Поэтому не стесняйся, напиши здесь неоптимизируемый код на rust'е.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	141. Скрыто модератором	–2 +/–
	Сообщение от Аноним (141), 12-Ноя-19, 16:19
	Такой змее лживо-увертливой и даже хамской, вообще то и отвечать - мне не стоит... Ну разве что, чисто чтобы не подумиал что раз я неответил - то нечего. Ага уже, ждите! (и просто надо же кому то публично обломывать рога, козлоидо-подобным псевдо-hohosapiens) > > - Это не массив. Я же сказал - к доктору." > Ты уверен, что к доктору мне, а не тебе? Что по-твоему такое std::vector, если не массив? Может ты думаешь, что это дерево? - Уверен. (всё выше-написанное и ниже-следующее - то подтверждает). А, то у вас - вообще то: динамический-массив... Технически совершенно иная сущность. (Ещё и с доп-ми проверками диапазона же - ну этого же отличия в Rust нет потому могу опустить). Да.. Вы так не осилили разницу... Что тут скажешь. Ещё отрицаете своё слабоумие: куда уж проще вещи! Ну, вот какие ещё вам асинки Rust'a или упоминания вами его оптимизаций(ну оно и видно по вашим "описаниям" их) - вы в элементарном плаваете хуже новичка в программировании 7-го класса средней школы... Блин! Мне просто стыдно за себя - с кем я тут говорю !!! Кому (вынужденно мне)пытаюсь показать его неадекватность на примерах чтоб не зазнавался - тут же совсем запущенный случай: мании величия с неисправимым олигофренизмом, уровня "Путин - _уйло!" с Майдана подсша-террориста-попрыгунчика... А, с террористами - вообще то по другому надо общаться... Впрочем, всему своё время и сша-террористам тоже. Ну, а пока - я всё же незакончил, тем более раз уже всёравно написано то что ниже) > > - Это массивы как раз - без кавычек. А, используют - всего лишь все Сишники... Но, вам конечно видней кто они... > "Это как раз "массивы". Потому что C не различает массивы и указатели. ...skip бредо-умствования" - Cи различает массивы и указатели, уже расписал. Кто то настойчиво путает-подменяет указатели(ID), неявные указатели на массивы(ID), - и сами массивы. Даже сам же написал: ""> - Подмена массива, идентификатора и указателя - смешиванием в кучу." - Конечно." - Оно и видно у вас. Плюс клевета прямо там же далее: "Ритчи думал, что так будет круто. Оно поначалу и было круто, но сейчас боком вышло" - О так!... Далее "В C нет массивов. person->name[-2] -- это синтаксический сахар для *(person->name - 2)" - ну напишите на вашем не-"сахарном"-указателе "int a[3] = {1,2,3}", если это "сахар"... (Более того, даже если бы то был "сахар" - так можно сказать что, весь синтаксис любого языка: сахар для ассемблера... Так что "идите лесом" - дважды, с такими вашими "аргументами") > "Если ты ещё в состоянии слышать меня, то выслушай совет: пойди и освой lisp" - Чего не сразу brainfuk?... Это и куда новей/модней... Но, кто то мне морочит голову, таки "трахая мозг"/brainfuk'я - выпендриваясь, никак не признавая себе же что он ничтожество. Трахайте и дальше себе мозг(этими "аргументами" вашими и программированием на Rust и тем более Lisp...) - к другим только с этим не приставайте. А, то это у вас уже на бешенство смахивает... > "Но мало того, это даст тебе возможность смотреть на C со стороны, а не только изнутри" - Я в отличие от вас не закрываю глаз даже "на изнутри" - с ассемблерной кодо-генерационной стороны, а не только с позиции Rust... Lisp... и прочих недо-языков программирования от всяких козлоидов которым наcрать на конечного потребителя - по определению, да и на компанию в которой работает - нанося ей тем убытки. Я даже об таком случае уже упоминал как раз вчера тут: http://www.opennet.dev/opennews/art.shtml?num=51835#124 > "ты не знаешь как оптимизируются автоматические проверки на выход за границы массива, ты не знаешь как их прожёвывает современный процессор -- всё это незнание я прям в глазах твоих вижу и" - Нагло врёте, Mr.Козёл. > "и в твоём эротичном голосе слышу" - Я же сказал по вопросу моего голоса у вас в голове - к психиатру... Тут даже не отнекивайтесь, это очевидно всем кроме вас. И да в реально жизни у меня обычный мужской голос. Но, остаётся консттаировать что вы ещё и галлюционирующий педик, козёл-педик, чего только не бывает... > "У rust'а есть недостатки, но ты про них не знаешь ничего, ты не упомянул ни одного реального недостатка rust'а. Например у него ОГРОМНЫЕ проблемы с разделяемыми библиотеками, эти проблемы проистекают из самой сути языка, и я очень сомневаюсь, что rust когда-нибудь будет решать эти проблемы так, как их решает, например, Swift" - Зачем мне их знать, зачем в очередном "вашем" говне ковыряться? Это ваш козлов-моральных похоже удел, вот и ковыряйтесь. А, мне достаточно знать что, из самой сути языка - проистекают не только это, а и то что, меня держит на удалении даже начать сделать Hello world. И т.о.зачем мне знать как их решает Swift? - у которого свои проблемы, которые вы значит по аналогии с перечисленным ...предлагаете решать ещё каким-инибудь костылями и так до бесконечности... Как сказал бы тут проф.Преображенский из ХФ "Собачье сердце": Бардак не в Си, а в головах таких защитничков со слюной у рта убер-произвоительности всяких Rust'ов (C#, Pyhon, вот ещё и Swift с List вами помянуты не кночи). > "Если тебя волнует производительность, то можно упомянуть осложнения работы с указателями, которые приводят к тому, что сложно заморочные структуры данных в памяти создавать сложно и заморочно" - 1) Я не говорил что только. Далеко не только производительность... Один сознательно-извратский синтаксис - чего стоит... Но, и он далеко не последний в списке... Хоть только его достаточно чтобы большинству Сишников (и тем более понимающих его смысл - HiLevAssembler) - просто "рыгать" от Rust-a. Но, главная притензия тут в комментариях не они и не убер-производительность Rust, а то что такие как вы(аморальные-козлы получается) на каждом углу заявляете о непотере производительности, а то ьывает что и большей скорости чем Си(который HiLevAssemble) - что просто неадекватно и смешно! (Для примера LUA вот тоже тот ещё лаггер, хоть можно и на нём делать почти-приемлемо-быстро, если его фактичски не использовать(т.е.черезжопно, неинтересуясь производительностью) или вообще UScript(автор писал о x20 раз падении производительности(уверен автор даже приуменьшил, эта величина подходит скорей к более простому QuakeC, в тут overhead только кучи ещё и перегруженных классов сумасшедший), и вот представьте - именно я сожалею о его выкидывании в UT4, после чего он перестал меня вовсе интересовать, так что у вас неверное мнение о мне из-за вашей неадекватности которую вам не принять, потому услышать и значит не понять о чём речь, замкнутый круг...) в Unreal бегавший даже на ПК 1998 года (и "ходивший" на 1997  - пеньке-1), но о них даже LUA с JIT/компилятором - никому как то не приходило в голову поднимать столько дезинформации в сети, ну да LUA не умеет компилирвать например ОС, так и?... Вот даже на C# MS сварганила ОС... и всё - всё, стухла, нет резона у ОС в таких языках с типа-"защищённым" исполнением, а уж MS то имеет возможность сравнить ОС с таким языком и более традиционным.   (Кстати, чуть-оффтоп, но последнее слово(традиционный, язык) меня наводит на мысль о связи ваших извращенческих пристрастий к этим всем "изотеричесим" языкам программирования - и ваших извращенческих пристрастий к нетрадиционностью в половой сфере, сравните в т.ч.с фактом: *нетрадиционностью* использования своего языка, интересно получается... ну как доктору- кому то можно даже состряпать целую диссертацию о это связи и что первично ;], и просто всем должно бы быть очень показательно о таких языках...) 2) А, вы не далайте сложно. Не пользуйтесь всякими "бустами", MFC/ATL и схожим.   А, при желании обратного - на любом языке можно сделать сложно и очень сложно. > "Но вместо этих _реальных_ замечаний в отношении раста, ты мне несёшь какой-то бред про проверку на выход за границы массива, не имея за этим бредом никаких аргументов" - Вы же их откинули... Для мня, как Си'шника: ваши "реальные" замечания по Rust - пшик... Даже не интересно. Нам хватает других, более реальных и более актуальных НАМ (а, не говноедам сладко утонувшим в кале Rust-a). Я вот нежелаю к таким присоединяться, именно потому не собираюсь даже его себе ставить - так что недождётесь никаких примеров, вам надо - сами сделаете примеры и компильте хоть до усрачки. А, я и так, без примеров, знаю - что, динамическая проверка на выход за границы - часто не может быть соптимизированна в compile-time: в null, как на том вы настаиваете. В целом я понимаю что говорю с психическим ненормальным, больница не зря мной помянута, и потому все доводы будут беЗполезны - что и читатели могут видеть у вас.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	142. Скрыто модератором	+/–
	Сообщение от Аноним (141), 12-Ноя-19, 16:20
	(продолжение ответов) > "Ты мыслишь о языках программирования, не зная их и глядя на них через призму C, и иначе не умеешь, так?" - Нет. (Вы и сам знаете что это клевета, но выдаёте желаемое за правду). А, мыслю я как человек, да совсем несовременный, т.е.ещё именно с времём когда Сями (грамотно)называли Си - а, не Си++, но по достоинству оценивший улучшения в т.ч.в синтаксисе С++, в т.ч.и шаблоны, когда вмеру. В ч.н.считающий что оптимизирвать и готовить к оптимизации - надо всё и сразу по мере написания, а не на потом - после готовности продукта (а, фактически - на TO-DO, обычно вечное, в т.ч. из-за сроков). Это то и подразумевает и например неиспользование всяких проверрок на корректность(не считая ряда случаев допустим на АЭС, где уверен их всёравно - не делают предпочитая качественную мозговую-проверку/инспекцию-кода в т.ч.другими людьми, уж если она не поможет - то и автоматический RangeCheck..., ну и при отладке например - да Си тут даже Pascal'ю сливает, например К.Сильверман вон прототипировал свой сверх быстрый тогда движок BUILD - вообще на BASIC, вероятно из-за этого, но затем всё преводил таки на Си, так что и я не против прототипирования хоть на Rust - если так же затем всё переводить, но последнее то - куда проще/быстрей делать с Pascal или даже Basic как более близки Си, - так что Rust даже им сливает...), а так же категорически против использование всяких вечных-лаггеров-итераторов и всех лаговых и баговых этих раскрученных алгоримических библиотек шаблонов начиная с С++шного STL, ускоряющих выполнение максимум только названием(boost) в сравнении с в ч.н.самостоятельной реализацией тех же динамических масивов или там деревьев, - а, вы всё время приписываете мне - обратное...  Ну и кому к доктору?!... вы не только аморальный хамовитый козёл - вы таки просто неадекватны (уж не знаю это частно или обще-растоманское, не хочу огульно на всех, но все эти признаки минимум далеко не только у вас наблюдаются). И как и прочие желающие публично виртуально "ускорить" всякие поделки вроде Rust - в сравнительных тестах лукавенько сравниваете с перечисленными лаговыми библиотеками, либо ещё как [сознательно] деоптимизируете тестовые примеры, и всегда - вне реального серъёзного проекта тесты - этак и вообще некомпилируемые скрипты могут равняться по скорости... в частном случае, удобном. Вот честно: я чувствую себя в общении с вами - как доктор вынужденно говорящий с пациентом в дурке, которому ничего не доказать и который жопу рвёт заявляя что ему - там не место: т.к.он здоровый - причём во всём мире только один он... (и такие как он, кучка козлов, с [посовместительству] чуть большей кучкой бой-фанатиков/фанатов (ну реально)кривожопных языков-с-притензией) и потому это ему надо быть на месте доктора и всему миру "мозги личить". Нет уж - пытайтесь "лечить" только мне/доктору одному, у меня в отличие от многих других - всё же уже просто профессиональная языковая(>20 лет размышляю о вариантах улучшения Си) и (анти-трольная)докторскя подготовленность/осведомлённость, могущая противостоять вашей (тутпрограммитско-)субкультурной нео-религиозной козлоидной ахинеее. Кстати, те С++ библиотеки чаще лаговы даже не столько из-за кривой реализации, помноженной на универсализацию любой ценой  и в ч.н.производительности, но и тем - что, все ими пользующиеся либо по вырастания на них - либо сознательно клали на скорость конечного ПО, отсылаясь на то что совремнные ПК - мол уже всё тянут или что, мол не всегда нужна вообще оптимизация скорости, вот только всегда фейлясь по скорости - когда она нужна... (ВДРУГ!)  А, потом начинаются отмазки что мол де алгоритм[rav1e] более тяжолый реализаций на конкуренте (а, руки то - уже из жопы, его оптимизировать), или а давайте мы уменьшим качество рассчётов/графики и скорость станет приемлема - ура! Да уж, эврика!... А, когда нельзя - тогда переложим поблему производительности на пользователя, что с годами стало массовой нормой и уже 99% выходящих игр требуют топовых ПК, причём именно производительных - стационарных, "кладя сверху" на всех владльцев лаптопов, не говоря уже не топовыых, - в т.ч.ценой уменьшения числа покупателей, заведомо обркая компании на [многосот]миллионые потери прибыли(игры после GTA5), - знакомо вопреки адекватности же... Так может таких надекватов, зато умеющих пустить пыль в глаза больше других обычно, этим компаниям - стоило бы вытуривать под зад коленом? Как видим, если перевести ваши свистелки-первделки в деньги - очень уж дорого обходится им *ваши* удобства и "ускорения"(в кавычках) производства продукта (пусть наличествующие - в частных случаях, как с проверкой диапазонов, но вот суммарно...). Это относится не только к растаманом... даже к большинству Сяшников, особенно подсаженных на указаные библиотеки являющиеся не только лаггерами, а сильными мозго-отбивателями пользователю. Думаю это очень обширный класс людей, которым не повезло родится значительно ранее 2000-х годов - чтобы ещё по старому опыту знать сколько какая конструкция [их] языка будет стоит(и не неся чуши о отсутвии overhead их, или неся но это уже аналогично вам - прямиком в палату) и таких же из становящихся затем руководителями других программистов и уже вирусно нанимающих таких же горе-"программистов", в 99.9999% случаях не имеющих и понятия как оно там реально выполняется - - и уже только потому одному реально им нельзя доверять ответсвенность участия в создании сколько то серьёзного проекта.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	143. Скрыто модератором	+/–
	Сообщение от Ordu (ok), 12-Ноя-19, 18:06
	> Такой змее лживо-увертливой и даже хамской, вообще то и отвечать - мне > не стоит... > Блин! Мне просто стыдно за себя - с кем я тут говорю > !!! Это самая развлекающая меня ситуация, когда люди колются, но продолжают жрать кактус, в виде меня. > Ну разве что, чисто чтобы не подумиал что раз я неответил - > то нечего. Ага уже, ждите! Лол. > (и просто надо же кому то публично обломывать рога, козлоидо-подобным псевдо-hohosapiens) Аааааа, я поцталом! >> > - Это не массив. Я же сказал - к доктору." >> Ты уверен, что к доктору мне, а не тебе? Что по-твоему такое std::vector, если не массив? Может ты думаешь, что это дерево? > - Уверен. > (всё выше-написанное и ниже-следующее - то подтверждает). > А, то у вас - вообще то: динамический-массив... > Технически совершенно иная сущность. (Ещё и с доп-ми проверками диапазона же И после этого ты возникаешь против утверждения, что ты вне рамок C не можешь думать о программировании? > Кому (вынужденно мне)пытаюсь показать его неадекватность на примерах чтоб не зазнавался > - тут же совсем запущенный случай: мании величия с неисправимым олигофренизмом, > уровня "Путин - _уйло!" с Майдана подсша-террориста-попрыгунчика... А, с террористами > - вообще то по другому надо общаться... Впрочем, всему своё время > и сша-террористам тоже. Ну, а пока - я всё же незакончил, > тем более раз уже всёравно написано то что ниже) Оу, такого типа сознание называется "синкретическая куча". Всё в одну кучу, всё в кашу. > - Cи различает массивы и указатели, уже расписал. Нет. Ты ничего не расписал. Ты лишь заявил. Объяснить тебе не удалось ни предыдущим постом, ни этим. Ты разницу между формулировкой теоремы и её доказательством не уловил разве в школе? Разница между голословным утверждением и объяснением примерно такая же. > Далее "В C нет массивов. person->name[-2] -- это синтаксический сахар для *(person->name > - 2)" - ну напишите на вашем не-"сахарном"-указателе "int a[3] = > {1,2,3}", если это "сахар"... А это, простите, синтаксис декларации с инициализацией. Совсем иная ситуация. Рекомендую освежить память и полистать стандарты. > (Более того, даже если бы то был "сахар" - так можно сказать > что, весь синтаксис любого языка: сахар для ассемблера... Нет, нельзя. Это с точки зрения программиста на C так можно сказать, программиста который ничего кроме C не едал. >> "Если ты ещё в состоянии слышать меня, то выслушай совет: пойди и освой lisp" > - Чего не сразу brainfuk?... Это сложно объяснить. Очень долго объяснять. Проще написать учебник по lisp'у, чем объяснить как изучение лиспа меняет сознание. >> "Но мало того, это даст тебе возможность смотреть на C со стороны, а не только изнутри" > - Я в отличие от вас не закрываю глаз даже "на изнутри" > - с ассемблерной кодо-генерационной стороны, > а не только с позиции Rust... Lisp... и прочих недо-языков программирования от > всяких козлоидов которым наcрать на конечного потребителя - по определению, да > и на компанию в которой работает - нанося ей тем убытки. Это и видно, именно об этом я и говорю, и ты не представляешь себе насколько такой подход ограничивает твой профессиональный рост. > Я даже об таком случае уже упоминал как раз вчера тут: > https://www.opennet.dev/opennews/art.shtml?num=51835#124 Я простите, не буду читать тот срач, только для того, чтобы понять контекст какой-то очередной сгенерённой тобой гневной копипасты. Ты и здесь мне предостаточно генеришь. >> "ты не знаешь как оптимизируются автоматические проверки на выход за границы массива, ты не знаешь как их прожёвывает современный процессор -- всё это незнание я прям в глазах твоих вижу и" > - Нагло врёте, Mr.Козёл. Вот ещё одно голословное утверждение. >> "и в твоём эротичном голосе слышу" > - Я же сказал по вопросу моего голоса у вас в голове > - к психиатру... Тут даже не отнекивайтесь, это очевидно всем кроме > вас. Если тебе кажется, что я отнекиваюсь, то голоса в голове у тебя, а не у меня. > И да в реально жизни у меня обычный мужской голос. Ты не знал, что мужской голос может быть эротичным? У тебя девушка была хоть раз? >> "У rust'а есть недостатки, но ты про них не знаешь ничего, ты не упомянул ни одного реального недостатка rust'а. Например у него ОГРОМНЫЕ проблемы с разделяемыми библиотеками, эти проблемы проистекают из самой сути языка, и я очень сомневаюсь, что rust когда-нибудь будет решать эти проблемы так, как их решает, например, Swift" > - Зачем мне их знать, зачем в очередном "вашем" говне ковыряться? Вот я о том же: "не читал, но осуждаю". >> "Если тебя волнует производительность, то можно упомянуть осложнения работы с указателями, которые приводят к тому, что сложно заморочные структуры данных в памяти создавать сложно и заморочно" > - 1) Я не говорил что только. Я тоже не говорил, что только. От голосов в голове помогает галоперидол. Хотя прежде чем принимать, проконсультируйся с психиатром, есть более современные нейролептики с меньшим количеством побочек. Я сам не специалист, поэтому не могу ничего порекомендовать. Далеко не только производительность... > Один сознательно-извратский синтаксис - чего стоит... Но, и он далеко не последний > в списке... Хоть только его достаточно чтобы большинству Сишников (и тем > более понимающих его смысл - HiLevAssembler) - просто "рыгать" от Rust-a. Мне-то какое дело до большинства сишников? Или до большинства вообще? Люди рыгающие от синтасиса заслуживают лишь троллинга, который ты сейчас здесь получаешь. А так -- в игнор. > Но, главная притензия тут в комментариях не они и не убер-производительность Rust, > а то что такие как вы(аморальные-козлы получается) на каждом углу заявляете > о непотере производительности, а то ьывает что и большей скорости чем > Си(который HiLevAssemble) - что просто неадекватно и смешно! О, наконец-то мы добрались до сути. Остальное получается всё было лишь прелюдией и все те претензии сняты?  Или это ещё не суть, и надо копать дальше, чтобы ты наконец объяснил, что тебя так завело? >> "Но вместо этих _реальных_ замечаний в отношении раста, ты мне несёшь какой-то бред про проверку на выход за границы массива, не имея за этим бредом никаких аргументов" > - Вы же их откинули... Ты можешь их перечислить по пунктам, не разбавляя эмоциями? Попробуй вычленить их из своей синкретической кучи, отделив от Гитлера, украинцев, геев, козлов, и всего прочего, что у тебя там намешано, и изложить их по пунктам. Потому что я вот перечитал, и я не увидел ни одного реального замечания, одни сплошные эмоции. Всё твоё поведение здесь выглядит истерикой человека, которого выбешивает, что кто-то имеет мнение отличное от его собственного, да ещё и имеет наглость это мнение заявлять вслух. Выпей стакан воды, соберись, тряпка, и напиши по человечески, в чём собственно твои претензии к расту.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	144. Скрыто модератором	+/–
	Сообщение от Аноним (144), 12-Ноя-19, 19:32
	- "Блин! ... с кем я тут говорю !!! ... тут же совсем запущенный случай" Что тут добавить, всё сказанно.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	153. Скрыто модератором	+/–
	Сообщение от Ordu (ok), 12-Ноя-19, 20:59
	> - "Блин! ... с кем я тут говорю !!! ... тут же > совсем запущенный случай" > Что тут добавить, всё сказанно. Во, это шаг в нужном направлении. Следующий шаг -- это научиться не писать ничего, когда не хочется продолжать беседу. Не хочешь писать, не пиши. Тебя никто не держит и не заставляет писать. Не ведись на манипуляции.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	150. Скрыто модератором	+/–
	Сообщение от Аноним (144), 12-Ноя-19, 20:50
	Нет это "меня всегда умиляло ханжество" с такими как у вас притензиями. И это не оскорбления, а попускание выродков человечества - (сугубо) в ответ на как раз оскорбление меня,  как то подозрительно [заангажрвоанно] вы это замечаете... или может всё же не Анонн - а, по прежнему Ordu?...
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	151. Скрыто модератором	+/–
	Сообщение от Аноним (144), 12-Ноя-19, 20:52
	* "как то подозрительно [заангажрвоанно] вы это НЕ замечаете... или может всё же не Анонн - а, по прежнему Ordu?..."
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	152. Скрыто модератором	+/–
	Сообщение от Ordu (ok), 12-Ноя-19, 20:57
	> Нет это "меня всегда умиляло ханжество" с такими как у вас притензиями. > И это не оскорбления, а попускание выродков человечества - (сугубо) в ответ > на как раз оскорбление меня,  как то подозрительно [заангажрвоанно] вы > это замечаете... > или может всё же не Анонн - а, по прежнему Ordu?... =) Это уже мания преследования. Но не ссы, я не буду сниться тебе в кошмарных снах, я завязал с этим лет пять назад.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	166. Скрыто модератором	+/–
	Сообщение от Аноним (166), 13-Ноя-19, 04:08
	Ну, попробуйте...
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	160. Скрыто модератором	+/–
	Сообщение от анонн (ok), 12-Ноя-19, 22:20
	> Нет это "меня всегда умиляло ханжество" с такими как у вас притензиями. Да у меня вроде и нет особых претензий, просто недавно видел такое на ЛОРе, а теперь и тут. Но намекну для жирафов: оскорбления в целом и из под безликого "анонимного анонима" в частности совсем не способствуют восприятию анонимного анонима всерьез, совсем даже наоборот. > И это не оскорбления, Я бы оспорил, но лень и бессмысленно, т.к. сразу за этим опять противоречие: > а попускание выродков человечества - (сугубо) в ответ т.е. уважаете "выродков", раз обращаетесь к ним в уважительной форме? > или может всё же не Анонн - а, по прежнему Ordu?... Если в профиль глянуть влом и (ok) после ника ничего не говорит, то хоть по треду поискать-то можно? Мне до сего претендента на эталон ЧСВ вроде бы далеко - например, послать честно изучавшего предмет, со всей сопутствующей базой, на соотв. факультете не самого паршивого ВУЗа "почитать хотя бы азы в википедии" - я вроде еще не умудрялся ))
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	104. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (3), 11-Ноя-19, 16:30
	>libaom >C, assembly Раст тут ни при чём. Говорю же, сладкое с мягким сравнивают.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	109. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (95), 11-Ноя-19, 17:05
	==>> Раст тут ни при чём. Говорю же, сладкое с мягким сравнивают. Rust в отличие от например Pascal(в сравнении с Си) - целая отдельная идеалогия мышления программирования. (впрочем и С++ от тех тоже очень сильно отличается и не в лучшую сторону - если использовать все эти стандартные и раскрученные шаблонные механизмы написанные извращенцами 70-го уровня, и явно продавшиеся компаниям производителям оборудования, которым тормоза повсеместные - очень уж выгодны). P.S. И не Раст, а Rust - незачем коверкать именования. И тем более Великий и Могучий.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	135. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (135), 12-Ноя-19, 15:00
	> Ага... Проверка индексов массивов в runtime, и всё прочее - типа бесплатно?... На x86 со времен Core2 примерно. Когда сравнивали драйвер 10Gib карточки на C и Rust выяснили, что на несколько миллионов дополнительных проверок доступа к массиву было потрачено ровно ноль лишних тактов. То есть планировщик современного интеловского процессора в таком не ошибается никогда. https://github.com/ixy-languages/ixy-languages
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	168. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+1 +/–
	Сообщение от Аноним (168), 13-Ноя-19, 04:23
	Будь вы даже хоть бейсиковцем(но, DOS времён) вам бы и то - было бы понятно что небывает бесплатных исполнений команд, даже при поддержке ЦПУ распараллеливанний, - и значит что то с этим назовём своими словами: бенчмаком-Rust'a... - не в порядке (см.вопрос про другие бенчмарки тут же), но от очередного ура-Rust'омана - я уже просто не жду таких элементарных вещей - потому и потратил своё время на "разжевывание". Впрочем, не жду принятия даже и того...
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	32. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+2 +/–
	Сообщение от burjui (ok), 10-Ноя-19, 03:29
	"Тут Аноним взмахнул волшебной палочкой, и в комментарии появились пруфы" (С) Джоан Рофлинг
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	47. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (47), 10-Ноя-19, 13:12
	В некоторых кейсах Rust быстрее. Например проблема алиасинга разрешается на этапе компиляции, а не в рантайме. Возможности статического анализа у Rust значительно шире. Это позволит в будущем автоматически применять более глубокие и сложные алгоритмические оптимизации. C/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста. И это часто ведет к значительному усложнению кода, снижению читаемости. Но обычно разработчик просто забивает, т.к. это требует анализа и потерь времени.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	63. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+5 +/–
	Сообщение от Аноним (63), 10-Ноя-19, 16:43
	> C/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста. Вот только пока код писался на сях, программисты не забывали про оптимизацию, а с появлением всяких растов и прочих питонов решили, что оптимизацией теперь должен заниматься кто угодно, только не они. В итоге мы имеем калькуляторы, требующие гиг оперативки ("Не, ну а чо, она же дИшОвая").
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	64. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+3 +/–
	Сообщение от Аноним84701 (ok), 10-Ноя-19, 16:52
	>> C/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста. > Вот только пока код писался на сях, программисты не забывали про оптимизацию, Угу, а тож никто не помнит и ни разу не видел шЫдевры "оптимизации": while(n>0) { n= read(fd, buf + pos, 1);pos++; buf = realloc(buf, pos+1); } Особенно интересно было наблюдать, как фан-модер Готики I/II, будучи школьником(!), задолбался ждать по 1-2 минуты окончания парсинга скриптов  (только чтобы узнать о синтактических ошибках) на совсем не слабом железе и наваял на C# свой парсер, которому требовалось менее 1 секунды, да еще и выдавал более информативные сообщения об ошибках. Потому что таки алгоритмы рулят и педалят. И нормальный, сгенерированный с EBNF (или что-то похоже высокоуровневое) shift-reduce парсер с табличкой  -- уделывает "щас мы зафигачим по быстрому снисходящий рекурсивный парсер, потому что все остальное на сишечке слишком геморно, а тут и так сойдет" :)
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	66. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
	Сообщение от Аноним (66), 10-Ноя-19, 17:03
	>>> C/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста. >> Вот только пока код писался на сях, программисты не забывали про оптимизацию, > Угу, а тож никто не помнит и ни разу не видел шЫдевры > "оптимизации": > while(n>0) { n= read(fd, buf + pos, 1); size++; buf = realloc(buf, > size); } while(n>0) {     n= read(fd, buf + pos, 1);     size++;     old_buf = buf;     buf = realloc(buf, size);     assert (old_buf == buf);     old_buf = buf; } Простите за мой французский.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	68. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+1 +/–
	Сообщение от Аноним84701 (ok), 10-Ноя-19, 17:24
	>[оверквотинг удален] > while(n>0) { >     n= read(fd, buf + pos, 1); >     size++; >     old_buf = buf; >     buf = realloc(buf, size); >     assert (old_buf == buf); >     old_buf = buf; > } > > Простите за мой французский. Учитывая, что код был "демонстрационно-от балды" (основную деталь, которую я помню - читались данные, из сокета, по 1 байту за раз в буфер, который потом реаллоцировался по принципу  "прежний_размер + 1") и  даже в правленном виде очень условно рабочий (size нужно заменить на pos или делать pos++, иначе каждая запись будет "поверх" предыдущей) -- именно как-то так ;)
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	70. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (66), 10-Ноя-19, 17:30
	Давай прямо. assert сработает или нет?
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	71. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним84701 (ok), 10-Ноя-19, 17:34
	> Давай прямо. assert сработает или нет? Давай криво. Код после твоей правки - по прежнему нерабочий. Мне не очень понятно, зачем тогда вообще что-то править в примере было.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	74. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (66), 10-Ноя-19, 17:44
	Это не правка. Это намёк. Честно, не пойму, прикалываешься ты, или нет. С одной стороны, видел тут твои весьма грамотные сообщения, но надо учитывать выходные. С другой, я крайне мало писал на Сях, а realloc() так вообще ни разу не использовал. Зато написал парочку менеджеров памяти. Так вот, мой "realloc" не перемещает память в подобном коде навскидку в 90% вызовах, а уточнять мне лениво, как и смотреть переменённую стратегию роста кучи. Но лет 10 назад я бы тоже таким кодом пугал.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	84. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+3 +/–
	Сообщение от Аноним84701 (ok), 10-Ноя-19, 21:18
	> Так вот, мой "realloc" не перемещает память в подобном коде навскидку в 90% вызовах, а уточнять мне лениво, как и смотреть переменённую стратегию роста кучи. Но лет 10 назад я бы тоже таким кодом пугал. Хм, похоже, кто-то за деревьями не видит леса (вот поэтому при непонятках все же лучше просто спросить, а не намекать непоянтно на что). Просто все это -- куча оверхеда на абсолютно ровном месте. Не забываем о двух вещах: 1) речь о чтении данных 2) времена, когда при чтении ограничивались парой сотен байтов, минули давно … Т.е. при прочтении/приеме жалкого мегабайта будет миллион вызовов realloc и (что заметнее) read. Ладно, "a demo is worth a thousand words". Заморачиваться с realloc (который там не главное - хотя оверхед при использовании таким макаром тоже даcт вполне заметный) я не буду - "и так сойдет", просто считаем 5МБ в "никуда", по 1, 10 и 100 байтов за раз: #include <stdlib.h>                                                                       #include <fcntl.h>                                                                                                                                                                int main (int argc, char** argv) {                                                           if (argc != 2) return -1;                                                                                                                                                          int fd = open("/dev/zero", O_RDONLY);                                                     ssize_t cnt = 0;                                                                         size_t n = atoi(argv[1]);                                                                                                                                                          char buf[100];                                                                           while(cnt < 5*1024 * 1024) {                                                                 cnt += read(fd, buf, n);                                                                                                                                                      }                                                                                         return 0;                                                                             }                                                                                                 % gcc -O2 rd.c % time ./a.out 1 && time ./a.out 10 && time ./a.out 100 ./a.out 1  0,15s user 1,40s system 99% cpu 1,551 total ./a.out 10  0,02s user 0,12s system 99% cpu 0,136 total ./a.out 100  0,01s user 0,01s system 96% cpu 0,014 total % dd if=/dev/zero of=/dev/null bs=1M count=10000 10485760000 bytes (10 GB, 9,8 GiB) copied, 0,661329 s, 15,9 GB/s Так понятнее? Ну да, код с пропускной способностью в 3.3МБ/c вместо возможных пары ГБ/c -- меня таки немного пугает ;)
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	88. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Anonymoustus (ok), 10-Ноя-19, 23:32
	Такие примеры мне нравятся. Сразу с тестами.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	92. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (66), 11-Ноя-19, 07:40
	> Такие примеры мне нравятся. Сразу с тестами. Ещё бы интерполировать результаты с учётом затрат на обработку ISR, генерируемого сетевой картой и добавить симуляцию шторма. Ну так, что бы остался намёк про сокет.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	180. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–3 +/–
	Сообщение от Аноним (180), 14-Ноя-19, 17:09
	> Такие примеры мне нравятся. Сразу с тестами. А, ещё фанатик Rust... с розовыми очками. Не сильно надейтесь на все эти бенчмарки [Rusta - как видно по накрученным результатам его]: лохом первым будете - вы же... (Когда действтельность не сойдётся с мечтаниями, ВДРУГ) Вас предупредили. (spoiler) Ну разве что для чего то очень маленького или совсем непроизводитеных случаев, вроде для команд командной строки?, но тогда вообще же не важно какой язык программирвания выбирать, и не факт что есть резон что то настолько нетрадиционное - в ущерб же практике с традиционным. (/spoiler)
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	91. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (66), 11-Ноя-19, 07:30
	> Заморачиваться с realloc (который там не главное - хотя оверхед при использовании > таким макаром тоже даcт вполне заметный) я не буду Не будешь, потому что понимаешь, что не даст. Потому и сменил тему на стоимость вызова ядра в синтетическом тесте, которая совершенно из примера не очевидна и слабо коррелирует с приходом "пакета" по сетке и сборкой его сетевым стеком из кадров. > 2) времена, когда при чтении ограничивались парой сотен байтов, минули давно … Вот и не ограничивайся. Читай пакет _произвольного_ размера, а не 100 байт. Весьма интересная задача реализовать аллокатор под это дело.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	94. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+1 +/–
	Сообщение от Аноним84701 (ok), 11-Ноя-19, 12:15
	>> хотя оверхед при использовании таким макаром тоже даcт вполне заметный) я не буду > Не будешь, потому что понимаешь, что не даст. Потому и сменил тему > на стоимость вызова ядра в синтетическом тесте, которая совершенно из примера > не очевидна и слабо коррелирует с приходом "пакета" по сетке и > сборкой его сетевым стеком из кадров.     char *buf = malloc(1);                                                                   size_t r_cnt = 0;                                                                         while(cnt < 5*1024 * 1024) {                                                                 cnt++;                                                                           buf =  realloc(buf, cnt);                                                                 if(!buf) perror("fail");                                                             } % time ./a.out 1;time ./a.out 1;time ./a.out 1; ./a.out 1  0,28s user 0,00s system 99% cpu 0,283 total ./a.out 1  0,28s user 0,00s system 99% cpu 0,277 total ./a.out 1  0,27s user 0,01s system 99% cpu 0,280 total Ну не даст, значит не даст. >>>> { n= read(fd, buf + pos, 1) Ну не очевидна, так не очевидна. И правда -- если читать данные по _одному_ байту за вызов, чтож там может тормозить-то? Сам себе что-то придумал, сам же и оспорил. Молодец, возьми печеньку.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	101. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (66), 11-Ноя-19, 15:40
	> И правда -- Не стоит выдавать допущение за истину. > если читать данные по _одному_ байту за вызов, чтож > там может тормозить-то? Ты тут где-то выше хвалился скоростью ПС-парсера. Он тоже по "одному" символу "за вызов" читает. Правда, из предварительно закешированного в буфер. Так вот "проблемы" исходного варианта решаются без переписывания его вообще, путём линковки с адеватным задаче рантаймом. Ну а для лабы, откуда фрагмент был скопирован, и так пойдёт. > Сам себе что-то придумал, сам же и оспорил. Молодец, возьми печеньку.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	120. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Ordu (ok), 12-Ноя-19, 01:42
	> assert сработает или нет? Этот assert имеет квантовую природу, он сработает и не сработает. Доступ к указателю переданному в realloc -- это UB. Соответственно, программа с таким assert'ом может сплясать польку или взорвать Солнце, и это будет поведение допустимое стандартом языка.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	131. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (66), 12-Ноя-19, 10:42
	>> assert сработает или нет? > Этот assert имеет квантовую природу, он сработает и не сработает. Доступ к > указателю переданному в realloc -- это UB. Соответственно, программа с таким > assert'ом может сплясать польку или взорвать Солнце, и это будет поведение > допустимое стандартом языка. Добавим педантизму: Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Является ли размер ячейки памяти документированной характеристикой среды? Являются ли исходники той самой среды документацией? Можно ли реализовать кучу, которая выделяет области с гранулярностью 1 байт? Какие при этом окажутся накладные расходы на заголовки блоков для упомянутых аллокаций? Если над вопросами слегка призадуматься, может так оказаться, что assert в худшем случае сработает каждую шестнадцатую итерацию. Проще говоря, не так страшна "постоянная реаллокация", как ею пугают.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	132. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Ordu (ok), 12-Ноя-19, 11:44
	> Если над вопросами слегка призадуматься, может так оказаться, что assert в худшем > случае сработает каждую шестнадцатую итерацию. Проще говоря, не так страшна "постоянная > реаллокация", как ею пугают. Или он сработает каждый раз. Или не разу. Компилятор может его выкинуть из кода, потому как UB, а это значит его можно заменить на noop.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	136. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (66), 12-Ноя-19, 15:04
	Если ты всерьёз предполагаешь, что написавший "сработает на 16й итерации" собирается такое запускать, лучше спрячься под стол. Пока не взорвался твой монитор, потому как UB.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	138. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Ordu (ok), 12-Ноя-19, 16:11
	> Если ты всерьёз предполагаешь, что написавший "сработает на 16й итерации" собирается такое > запускать, лучше спрячься под стол. Пока не взорвался твой монитор, потому > как UB. Так у него взорвётся, если чё. Я предпочитаю такие вещи изучать так: https://gcc.godbolt.org/z/HCmknA
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	170. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (66), 13-Ноя-19, 11:17
	>> Если ты всерьёз предполагаешь, что написавший "сработает на 16й итерации" собирается такое >> запускать, лучше спрячься под стол. Пока не взорвался твой монитор, потому >> как UB. > Так у него взорвётся, если чё. Я предпочитаю такие вещи изучать так: > https://gcc.godbolt.org/z/HCmknA Вполне предсказуемый результат трансляции. Плоская модель памяти, сегментные регистры не используются. Что характерно, транслятор посчитал условие assert() выполнимым с малой вероятностью. Assembly/Compiler Coding Rule 3. (M impact, H generality) Arrange code to be consistent with the static branch prediction algorithm: make the fall-through code following a conditional branch be the likely target for a branch with a forward target, and make the fall-through code following a conditional branch be the unlikely target for a branch with a backward target.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	77. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+1 +/–
	Сообщение от Аноним (77), 10-Ноя-19, 17:58
	Кто сказал, что хуже? https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://www.techempower.com/benchmarks/
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	97. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
	Сообщение от Аноним (95), 11-Ноя-19, 15:00
	> Кто сказал, что хуже? Я сказал. Тут же выше: http://www.opennet.dev/opennews/art.shtml?num=51837#96 "... Проверка индексов массивов в runtime, и всё прочее - типа бесплатно?... ..." P.S. А, бенчмаркам верят только те - кому выгодно верить в *конкретный* бенчмарк... Сколько было уже таких людей несосчитать... то C# такой же по скорости, то ранее - Джаба с JITом; а, по факту - выше головы никому не прыгнуть.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	124. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (122), 12-Ноя-19, 02:55
	И бенчмаркам никаким верить нельзя, и головой думать не нужно. Весело наверное в твоем мире жить
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	146. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
	Сообщение от Аноним (144), 12-Ноя-19, 19:46
	По вам и видно чем вы думаете...
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	123. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+1 +/–
	Сообщение от Аноним (122), 12-Ноя-19, 02:52
	> сильно хуже да конеш. https://github.com/ixy-languages/ixy-languages/
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	26. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–3 +/–
	Сообщение от Аноним (26), 10-Ноя-19, 01:11
	Если -20-60% условной производительности(и это без компиляторной магии си) это "не уступает", то можете использовать, только про си не упоминайте, уместнее тогда сравнивать с го и джава.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	169. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
	Сообщение от Аноним (169), 13-Ноя-19, 04:49
	С чего такие цифры?  Они просто явно не учитывают умение доп-но оптимизировать ручками(и это без компиляторной магии си)(нолик добавьте, иногда даже за просто ассемблерную версию без убер оптимизаций), т.е.на Си... На Rust такое тоже возможно - профессиональному Сишнику... с умением оптимизирвоать и желанием...; плюс не используя весь ноухау фунционал Rust и поголовным unsafe - что малореально же делая что то на Rust, разве что для подкрутки сранительного бенчмарка. А, в некоторых случаях - наверняка и куда побольше ваших % разницы - и без доп.оптизации, разные бывают ситуации... Но, да сравнение Си - супернагло, до смехоты. Ещё бы сказали что так же быстр как на ассемблер (нет, ещё как можно и на нём - всё залагать, т.б.когда надо чтобы сравнительный бенчмарк и на нём был тоже похуже)
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	55. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
	Сообщение от Аноним (55), 10-Ноя-19, 14:30
	> никаких UB И как, бишь, D его B при целочисленном переполнении?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	100. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–2 +/–
	Сообщение от Аноним (95), 11-Ноя-19, 15:30
	> никаких UB Чтоооо? А, баги [компилятора], а кривые руки программиста (у растманов не знающих Си с времён 1990-х годов - втройне кривые, так же как у питонщиков и прочию любых таких "программистов", скриптёров), а ещё алгоритмические. А, если это не рассматривать как UB, то ...и в Си их тоже нет по кр.мере в реальных с конкретной реализации (в стандарте всё же UB таки полно - начиная с направления парсинга выражений, вот только на нем же ...никто и не пишет; а, чаще - и не читал никогда, в ч.н.за ненадобностью; а, те кто пытался выепнуться и сделать в своём компиляторе чуть сильней отличие иначе чем у других - всёравно вынужденны были сделать опции совместимости, как было даже с более коррестным: char - как unsigned, но...) А, так в Си и даже С++ - нет никакого UB, всё расписанно же в стандарте или документации на ЦПУ. Ну, конечно нет - несчитая перечисленного в начале: багов. А, так же можно вспомнить про (естественные)несовместимости разных компиляторов, даже [обратных]несовместимостей [под]версий (якобы)одного и того же, - соотв-но присутсвующие(UB) и в расте... и будут увеличиваться ещё. Именно версии компиляторов и стандартов - делают их непригодными с каждым новым годом. Т.о.тоже самое грозит любому языку с неостановленным развитием.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	19. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (19), 09-Ноя-19, 23:34
	Стоит. Заметил, что я стал в своих программах на полноценном ООП отказываться от наследования в пользу композиции. Правда можно было бы и сделать нормальное наследование через композицию, но таких ЯП я не знаю.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	20. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (19), 09-Ноя-19, 23:35
	*на полноценном ЯП
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	29. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Crazy Alex (ok), 10-Ноя-19, 02:19
	Ну и при чём тут Rust? Это отнюдь не вчера появившаяся идея. Я её у Саттера, кажется, первый раз встретил, а судя по википедии - она была ещё в книжке Банды Четырёх от 95-го года, и это много лет как совершенно базовый принцип, где-то рядом с single responsibility.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	81. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от a3k (?), 10-Ноя-19, 20:17
	Это как-то само доходит после опыта поддержки хоть немного большого ООП-кода с изменяющимися требованиями.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	40. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+4 +/–
	Сообщение от Ц (?), 10-Ноя-19, 08:47
	C++ будет быстрее. Учите лучше его.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	43. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+4 +/–
	Сообщение от Нонон (?), 10-Ноя-19, 12:04
	Ассемблер быстрее. Учите лучше его.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	46. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от JL2001 (ok), 10-Ноя-19, 12:49
	> Ассемблер быстрее. Учите лучше его. он не оптимизируется автоматически, непереносим, долог в написании и рефакторинге, порождает множество ошибок в силу ограниченности человеческого разума и больших размеров программ
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	51. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+1 +/–
	Сообщение от Аноним (66), 10-Ноя-19, 14:15
	> Ассемблер быстрее. Учите лучше его. Лучше так не шутите, ведь подобные утверждения начинают повсюду копировать. Человек может написать боле быстрый код чем оптимизатор, но далеко не каждый.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	102. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (95), 11-Ноя-19, 16:07
	Незнающий ассемблер и более того его оптимизации - ни на каком языке, не сможет и даже незахочет уже смочь уметь оптимизированно писать, ибо это доп-ный большой труд и КУЧА затрат времени, а изучение его когда спешишь что то ваять - практически уже нереально. Потому так много лагающих Си[++] программ, (начиная с ...LinuxKernel, всегда жутко лагавший - даже во времена 486 с 8Mb, а ныне и незапускабельный там вовсе, впрочем недавно кажется на Arch с кучей хаков таки смогли чудом запустить, но именно что "запустили", до скорости даже лагерра в те времна - win95/даже оно - тормозило мин.на 30-50% в ср.с чистым дос, даже при неактивности свопинга, а уж с ним... и это самая быстрая ОС в win линейке/, даже сверхнастраиваемому пользователем Арчу - нереально далеко); впрочем есть версия что эти лагия в ядре, DE и прочем включая OpenOffice - потому что Линусу и ко - активно "донатят" производители оборудования [акциями] - за то... Аналогично же у BSDшников. И по прочим факторам видно, у многих популярных форков Linux - судя только по отменённе 32-битности дистрибутивов. В общем не вижу отличия в подходе даже от хаямого тут и везде падлючного MS; как и от его падлючаний багами - чтобы вынудать пользователей устанавливать более новые версии ОС и значит более тормозные, т.о.навязывая Upgrade всего ПК). Впрочем, речь то была про ассемблер и забытость его критичной важности.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	128. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (66), 12-Ноя-19, 10:12
	> Впрочем, речь то была про ассемблер и забытость его критичной важности. Напомню: "Ассемблер быстрее". В то время как это лишь мнемоническая запись машинного кода. Надо ли понимать, как работает железо? Для определённых категорий это, безусловно, необходимый навык. Именно понимание даёт возможность написать "быстрее", но никак не ассемблер.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	149. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (144), 12-Ноя-19, 20:34
	Не только понимание как работает железо, но и - как компиляторы. А, ассембрер это компилятор в котором программист заведо понимает как и что работает в сгенерированном коде, без его знания - не будет никакого понимания. Другое дело что да, просто выучивание ассемблера, например в ВУЗах, обычно не приводит к полноценному понимаю оптимизаций, тут уже опыт в сфере именно оптимизаций и это не обязательно на ассемблере, но без знаний ассемблера это нереально или не полноценно. В общем, ещё и опыт именно в оптимизации нужен, а это не только книга по ассемблеру... К тому же, самые сильные оптимизации - даже не архитектурные, но без понимания архитектурных ограничений это затруднительно. Но, проблема даже не в этом, а в том что оптимизировать нужно хотеть желать (тратя время, а руководству т.о.инвестируя деньги), а без этого когда понадобится - уже поздно, даже при желании и выделении денег.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	171. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (66), 13-Ноя-19, 11:53
	> Не только понимание как работает железо, но и - как компиляторы. > А, ассембрер это компилятор в котором программист заведо понимает как и что > работает в сгенерированном коде, без его знания - не будет никакого > понимания. Ассемблер это ассемблер. Трансляция мнемоник выполняется 1 в 1 в машинный код. Кроме синтаксиса и пары директив там учить нечего. When instructions are represented symbolically, a subset of the IA-32 assembly language is used. In this subset, an instruction has the following format: label: mnemonic argument1, argument2, argument3 Вот и всё. > Другое дело что да, просто выучивание ассемблера, например в ВУЗах, > обычно не приводит к полноценному понимаю оптимизаций, тут уже опыт в > сфере именно оптимизаций и это не обязательно на ассемблере, но без > знаний ассемблера это нереально или не полноценно. Так выучили язык, как тут советовали, как набор мнемоник и копируют эти мнемоники. Хорошо бы понимать, что такое регистры, страницы, виртуальная память, как организуется стек и так далее. То есть выучивать надо железо. С таким пониманием можно почти на чём угодно писать "оптимально", когда потребуется. > В общем, ещё и опыт именно в оптимизации нужен, а это не только книга по > ассемблеру... К тому же, самые сильные оптимизации - даже не архитектурные, > но без понимания архитектурных ограничений это затруднительно. Да, не архитектурные, а алгоритмические. Кнут использует придуманный ассемблер с одной единственной целью -- что бы можно было точно подсчитать вычислительную сложность описанных им алгоритмов. > Но, проблема даже не в этом, а в том что оптимизировать нужно > хотеть желать (тратя время, а руководству т.о.инвестируя деньги), а без этого > когда понадобится - уже поздно, даже при желании и выделении денег.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	172. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (172), 13-Ноя-19, 13:17
	Ну, вперёд!  без знания и практики перечисленного мной - максимально оптимизировать....... Мне то что. Это же вы и такие как вы - навязываете всем якобы "быстрые" как Си лаггеры: Rust и прочее, собственно почти всё что когда либо выходило... не привыкать.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	173. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (66), 13-Ноя-19, 14:15
	> Ну, вперёд!  без знания и практики перечисленного мной - максимально оптимизировать....... Перечислен был некий загадочный "опыт оптимизации", в то время как "оптимизировать" возможно как минимум по двум параметрам: а) размеру; б) скорости. Допустим, мы выучили основные мнемоники. Что даёт такое знание по первому варианту? Ничего. Что бы иметь представление о размере опкодов, надобно знать формат команд. Допустим, мы выучили клёвую мнемонику prefetchnta. Что это даёт по второму пункту? Опят же, ничего. Что бы был толк от её применения, следует знать размер линеек кеша и механизм работы процессора с памятью -- что бы понимать, как развернуть циклы и в каком месте ту мнемонику написать. Однако, при наличии таких знаний, вместо мнемоники и ассемблера можно написать интринсик, а остальной текст на другом языке. После чего прочесть в мануале, что банальная rep movs десять лет как реализует всё в железе. Таким образом знание "ассемблера" даёт возможность растопыривать пальцы перед пионерами. Практическим навыком является понимание работы железа. > Мне то что. Это же вы и такие как вы - навязываете > всем якобы "быстрые" как Си лаггеры: Rust и прочее, собственно почти > всё что когда либо выходило... не привыкать. Осталось поискать и найти, где и что я кому-то навязывал. Так, что бы слов на ветер не бросать.
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	174. Скрыто модератором	+/–
	Сообщение от Аноним (174), 13-Ноя-19, 20:41
	Уже устал от вашей повсеместной тут неадекватности: вы же "Аноним"...   Или это такой софизм-ловушка? Ок: во всех (дезъинформационных)"обличениях" мной-сказанного (пряммо только тут выше) - вы навязываете своё лживое мнение, остальным. Далее. Вы не желаете слышать и притом - требете ответа вам на (все у вас)лживые надуманные утверждение, но у меня есть и свои дела - чем составлять в т.сл. всё увеличивающиеся простыни ответов, т.к. даже вам всёравно не нужные по оределению - как и видно из диалога прямо тут. Так что ограничюсь сказанным тут - лаконично: у вас всё надуманно/натянуто. Не хотите не верьте - мне "по барабану".   А, детальное вдалбливание вам в голову / обучение ассемблеру и архитектуре - это не ко мне, а для начала [опять] в ВУЗ.. Можете начать даже вообще с курса Логика...
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	175. Скрыто модератором	+/–
	Сообщение от Аноним (66), 14-Ноя-19, 07:40
	> Уже устал от вашей повсеместной тут неадекватности: вы же "Аноним"... > Или это такой софизм-ловушка? Эта такая самокритика от Анонима, на сообщение которого я даю ответ. И вот мой совет: разберитесь, кому и что тут пишете. "Обучатель ассемблера" своей способностью замечать детали (Анонимы пронумерованы) легко и непринуждённо поставил под сомнение свою компетенцию, так что и остальное спишем на тот уровень.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	45. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от JL2001 (ok), 10-Ноя-19, 12:47
	> C++ будет быстрее. Учите лучше его. не будет, ты просто не напишешь рабочую программу https://habr.com/ru/post/472780/
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	78. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+1 +/–
	Сообщение от Аноним (78), 10-Ноя-19, 18:28
	Ты эту ссылку из новости в новость тягаешь, не надоело еще? "Мы написали говнокод, хахаха, он работает неочевидным образом". Да подобным примерам на питоне и js целые сайты посвящены.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	90. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+2 +/–
	Сообщение от Анонии (?), 11-Ноя-19, 06:46
	А мужики-то и не знали! Писали себе программы на C++, а оказывается, это невозможно было!
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	67. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+1 +/–
	Сообщение от Wilem (?), 10-Ноя-19, 17:18
	Подобные вопросы лучше задавать гуглу. Если ты это делаешь на опеннете то ты либо тут первый раз, либо наслаждаешься неминуемым срачем (что не плохо, в общем-то - весело). Практической пользы немного, тк мало экспертов, в основном тут просто любители линукса.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

12. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+5 +/–
Сообщение от NaN (?), 09-Ноя-19, 22:48
Там же половина на асме.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	103. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–3 +/–
	Сообщение от Аноним (95), 11-Ноя-19, 16:23
	И даже это не помогло... так лагуч Rust.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	125. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
	Сообщение от Аноним (122), 12-Ноя-19, 02:57
	Хмм, а чего тогда не на сишке то написали оптимизированные оптимизации, зачем было тратить время на асм? Раст же виноват
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	155. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
	Сообщение от Аноним (144), 12-Ноя-19, 21:06
	А, кто же ещё. Ну не помянутый же Си... Оптимизация - должна быть комплексно... А, выросшим на Rust - откуда уметь даже просто ассемблерные оптимизации полноценно - пиши не пиши теперь на ассемблере..., и основной то код на Rust - никто не отменял. Не отмажитесь - тут уже таки: «Раст виноват».
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	185. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (122), 16-Ноя-19, 17:52
	Когда научишься связно излагать - возвращайся
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	186. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (186), 17-Ноя-19, 00:33
	Хамов никто не спрашивал же. +Вперёд - учиться читать.
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

13. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+11 +/–
Сообщение от Аноним (14), 09-Ноя-19, 22:49
Основная половина кодировщика написана на ассемблере. Смените название поста ;)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+1 +/–
	Сообщение от анонн (ok), 09-Ноя-19, 22:58
	> Основная половина кодировщика написана на ассемблере. Смените название поста ;) Основная половина mem/strcpy/strstr в glibc написана на асм, смените название либы
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	18. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+11 +/–
	Сообщение от Crazy Alex (ok), 09-Ноя-19, 23:26
	Ей можно - она не НА, а ДЛЯ C.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	27. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–2 +/–
	Сообщение от Аноним (27), 10-Ноя-19, 01:58
	>Основная половина mem/strcpy/strstr в glibc написана на асм но ведь это ложь
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	31. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+2 +/–
	Сообщение от анонн (ok), 10-Ноя-19, 02:42
	>>Основная половина mem/strcpy/strstr в glibc написана на асм > но ведь это ложь Но ведь это аноним i386/memcpy.S https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/i38... i386/i586/memcpy.S https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/i38... x86_64/multiarch/memcpy-ssse3-back.S https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86... x86_64/multiarch/memcpy-ssse3.S https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86... i386/i686/memcpy.S https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/i38... x86_64/strcpy.S https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86... x86_64/multiarch/strcpy-avx2.S https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86... x86_64/multiarch/strcpy-sse2-unaligned.S https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86... x86_64/multiarch/strcpy-ssse3.S https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86... x86_64/multiarch/strcpy-sse2.S https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86...
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	37. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
	Сообщение от Аноним (66), 10-Ноя-19, 06:07
	Но это половина не основная, а расширенная (см. extension). Кроме того, её возможно вообще выкинуть.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	34. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+1 +/–
	Сообщение от burjui (ok), 10-Ноя-19, 03:57
	Только подавляющая часть ассемблера - в директориях x86 и arm, что достаточно прозрачно намекает на то, что на ассемблере написаны специально оптимизированные версии алгоритмов и функций, а не основное мясо кодировщика.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	38. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–4 +/–
	Сообщение от Аноним (66), 10-Ноя-19, 06:16
	Названия каталогов явно говорят о том, что в них содержится оптимизация под конкретные архитектуры. Что именно там оптимизировано и где (и что) мясо -- непонятно как из тех названий следует (а изучение содержимого каталогов и файлов -- это задача как раз делавшего исходное утверждение).
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	49. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (49), 10-Ноя-19, 13:42
	Так ведь описанное —  и есть основное мясо кодировщика.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

21. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
Сообщение от Аноним (19), 09-Ноя-19, 23:37
А кодирование AV1 на GPU, TPU и FPGA будет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (25), 10-Ноя-19, 00:58
	Будут аппаратные декодеры и кодировщики во всех новых GPU и SoC.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	56. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (55), 10-Ноя-19, 14:37
	Аноним гарантирует?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	73. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+2 +/–
	Сообщение от iPony129412 (?), 10-Ноя-19, 17:36
	А куда они денутся. Тут даже VP9 появился при гораздо меньшей поддержке.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	105. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (95), 11-Ноя-19, 16:35
	При наличии уже даже OpenCL - давно нет смысла тратить транзисторы на codecs.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	106. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (95), 11-Ноя-19, 16:37
	(а, если и сделают - реально будет на OpenCL, из маркетинговых соображений это умолчат)
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	176. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от iPony129412 (?), 14-Ноя-19, 08:47
	> При наличии уже даже OpenCL - давно нет смысла тратить транзисторы на codecs. Бред https://trac.ffmpeg.org/wiki/HWAccelIntro#FFmpegAPIImplement... > ​OpenCL can be used for a number of filter
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	189. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (189), 18-Ноя-19, 00:46
	Бред у вас, я того что по ссылке - и не отрицал... go to школа учиться читать.
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

28. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
Сообщение от Аноним (27), 10-Ноя-19, 02:07
надо будет попробовать, сравнив с hevc
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	99. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+2 +/–
	Сообщение от Аноним (27), 11-Ноя-19, 15:24
	короче, проверил при аналогичном качестве видео занимает в ~8 раз меньше места на диске по сравнению с hevc но есть недостатки: 1) работает слишком медленно, почему-то использует только одно ядро процессора, несмотря на опции 2) принимает на вход только в y4m формате, который занимает слишком много места на винте
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	107. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (107), 11-Ноя-19, 16:45
	2) принимает на вход только в y4m формате, который занимает слишком много места на винте это референсный инкодер (commandline), подразумевается что либу запилят во что-то типа fmpeg (я надеюсь C биндинги будут), поэтому это вообще ни разу не недостаток. про первое - оч странно, какие опции использовали. Надо бы баг им запилить) должно все использовать.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	113. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (3), 11-Ноя-19, 20:00
	Корми в пайпе, типа такого: ffmpeg -v 0 -i source.mp4 -f yuv4mpegpipe -pix_fmt yuv420p -y /dev/stdout |
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

30. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
Сообщение от Ivan_83 (ok), 10-Ноя-19, 02:41
svt-av1 по любому быстрее должен быть.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–6 +/–
Сообщение от Аноним (-), 10-Ноя-19, 06:02
>Код проекта распространяется под лицензией BSD. Вот такое вот БЗДунство растаманов меня сильно огорчает. Ибо ничего лучше GPL v3+ нети никогда не будет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	39. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
	Сообщение от dimqua (ok), 10-Ноя-19, 07:57
	Откуда ты знаешь, ты GPLv4 видел, а GPLv5? :-)
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	41. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–6 +/–
	Сообщение от Аноним (41), 10-Ноя-19, 09:24
	Ну так форкни и перелицензируй под GPL, вы же так постоянно делаете.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	48. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–2 +/–
	Сообщение от Аноним (48), 10-Ноя-19, 13:34
	Один форкнет, измажет в гпл, а потом прибежит толпа боевых гплерастов и будет указывать на нарушения копилефт и копирайт
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	58. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (-), 10-Ноя-19, 15:56
	>Один форкнет, измажет в гпл, а потом прибежит толпа боевых гплерастов и будет указывать на нарушения копилефт и копирайт Не прибежит. Проприетарщики выбирают БЗДу. А с БЗДы на ГПЛ в можно. С БЗДы в любое направление можно.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	93. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от КО (?), 11-Ноя-19, 10:19
	>А с БЗДы на ГПЛ в можно Не совсем, в BSD есть одно требование, на которое в GPL кладут болт.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	112. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (95), 11-Ноя-19, 19:45
	Это должно быть: (аж) не требовать раскрытия исходников?... Или вы про 3-й clause, отсутствующий в нормальной версии с 2-мя только... А, ещё GPL таки очень вирусная, как её называют. Да и свободность к ней реально не относится никак.   (не мотивацию с выпытыванием исходников я понимаю, но не понимаю почему расплачиваться т.о. должен только производитель, а не потреблятель - вон сколько людей пользуют Linux и ПО - но, фактически ущерб несут только каждый последующий форкнувший вкладчик в проект, ибо далеко не все разработчики-конкуренты равны между собой по поулярности/раскрученности и по размеру своей команде и т.д., GNU - это обезценивание идей ибо иногда только 1 идея в форке больше ничего не имеющего может победить 1000000 форков даже куда раскрученней, а если заведомо понятно что те кто более расручен и/или обеспечен - за 1 клик всё позаимствуют, то уж извините - но не ждите реализации этой идей от нетаких производителей, заведомо окажущихся в проигрыши по затратам [усилий]. И тем более 100-500 идей реализовывать нет резона. Ибо рынок сбыта и в OSC совсем не резиновый. Так и в чём выгода тогда в GPL лицензии что этому некрупному разработчику[+без команды [на ставке]], что культу Прогресс? Выгода с GPL получается получают только те кто с командами на ставке и чаще они из корпораций(кому выгодно т.о.обходить доп.расходы на инфраструктуру и в т.ч.налогооблажение) или просто как то первым раскрутился т.ск.ещё до рождения "тебя", вроде Кармака, Торвальса(с его уж не первое десятилетие/вечно-неделанным ядром) и тех на кого он реально работает, выставляя своё ядро - фактически на бетатест, так же как и проприетарщики вроде MS - попутно сознательно добавляя багов, чтобы почаще обновлялись и обновляли оборуование, и вообще почаще вспоминая не забывали о них, всё тот же 1 в 1 маркетинг, и вот вопрос - где те 10-100-500 форков только Линупкс ядра? А, никому - не нужны... т.к. все ноухау угрожающие популярности Торвальдсу - тупо copy-pasted). Можно ещё много сказать, но например фанатам культа Прогресс будет достаточно того что GPL - враг Прогресса.   И именно Линуксы убили BSD NIXы на desktop'ах, как и всех некорпоративных-конкурентов винды(включая ОСь перекупленную MS и названную ими NT и значит последующие ОС), не удивлюсь если MS с Apple - даже донатят в Линухи больше чем IBM/Intel, так же как и в ReactOS, - это того стоит даже просто чтобы никто не смог обвинить их в монополизме... ну и чтобы разработчики ВСЕХ Линуксов молчали о реально ситуации с безопасностью их ОС, а она за последние 20 лет стала совсем ужасна. В целом дурацкая противоречивостью с OSC-идеалами ситуация. Для рядового желающего сделать свой улучшенный форк: получается что GPL - не многим то лучше проприетарной лицензии открытого исходного кода. Например, что нельзя продавать форк проприетарного OpenWatcom улучшая его, что нельзя т.к. безсмысленно - с той же целью делать форк GNU GCC... Да, даже бесплатно раздавая - показательных попыток в истории хватает, как и их прекращений развития начина DJCPP, а тот же переломный GCC 3.0 это фактически импорт кода Pentium-оптимизированного GCC-форка PGCC, после чего развитие того прекратилось... за т.о.безсмысленностью и потому что кушать тоже хочется, т.к.уж если и не коммерс у них был - то донаты то всёравно шли только к GCC, как самому раскрученному и потому например используемому в дистрибутивах.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	130. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (-), 12-Ноя-19, 10:36
	У противника Свободы бомбануло. Ничо FSF будет давить проприетарщиков и колаборантов-БЗДунов революционными методами.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	162. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (162), 12-Ноя-19, 23:41
	Значит вы противник прогресса. :]]] А, напомните то как в устах таких говнюков как вы - это звучит... ;) (Согласитесь, всё же красиво я вас уделал! Признаваться в этом - даже и не обязательно, а можно и поотрицать - что ж я не понимаю... таких) И не сказал бы что я противник свободы, но только вот "моя свобода - не вам же..." (это перефразируя ~"Мои права начинаются так где заканчиваются ваши", как сказал некто). И как написал - не вижу ничего свобоного в скрыто проприетарной даже кабальной GPL, мне она даже противна - но, именно тем что она не свободна *вопреки* тому что такие как вы - выдаёте её за такую. А, так никто не против... Вот только фонд SCO имеет такое же отношение к *моей*(и вашей - будь у вас мозг) свободе - как и прочие проприетарные лицензии... Но, вот они получается ... честней! А, уж про справедливость (в ч.н.оплаты труда) в GPL - и вовсе речи нет, когда она как вирус сделанна - что бы зарабатывали все кроме (тем более некорпорационных) создателей - либо продажные недотвари вроде Mozilla (всегда донатимая поисковиками за включение их троянской слежко-контроль функциональности в их браузер и всё прочее, - как то видел что был транш даже в $1 млд(!) от гугла, но позже прочёл что они вообще и раньше каждогодно брали взятку за это и не только от него), и это только одна компнания, таких паразитов-на-"свободе" - куча... Да что там они, вроде где то видел что и сам нео-бог-некоторых Торвальдс - как то оптом продал вкладчиков-кода(их труд, но назовём всё своими словами) - лицензировав ядро компании RedHut, и это GPL не воспрещает, как и много прочих способов. Именно потому я не хочу присоединяться к GPL сообществу например GCC, *не хочу что бы мной торговали*(aka моим трудом) да ещё безвозмездно им - как своим рабом. Нет не спорю, компаниям то есть резон например нанимать людей чтобы развивали что то сообща с другими компаниями (в идеале и дурачками-рабами - им всем), но тут тупо за зарплату батрачат - а, вовсе не за иделы GPL как послушать. Потому ещё раз: свобода к GPL не имеет отношения, это наоборот кабала... как минимум ук.части разработчиков/ И не только с ук.выше стороны скрытого парабощения - но и с точки зрения подсаживания на проект / затрат времени. Я это хорошо знаю т.к.давно мимиходом занимаюсь улучшением ряда проектов, ну вот например очень известная %игра-х% точней новый-движок для той - который как назло тоже GPL (ну там реально и проприетарный (C)-блоб впихнут потихому...) и потому дилема - начиная даже задолго до вопросов моей лично свободы как нераба условно-Столлману: я мог бы(и хотел бы и хотел, но пока собрал все баговые issue ...под тысячу - понял следующее) я мог бы очень долго и нудно, но исправить все тысячи багов и более того затем хоть годами круто улушить gameplay, но всё же это никем неоплаченные год(ы)... а, без возможности легально закрыть для коммерса - тот  считай и не светит особо, т.е.в лицензии я могу хоть продавать - но, *по факту зарабатывать будет кто угодно КРОМЕ меня/разработчика*, начиная с компаний распространителей всякого GPL на CD/DVD дисках, косвенно - но всё же и компаний дистрибутивов NIX'ов и не только [включением в свой репозиторий], а может и сам оригинальный автор проекта таки "проснётся" и решит, прям как Торвальдс,  продавать движок(с даже его же (С)) хоть в том же стиме и прочем (и такое видел) (да это им начатый проект, но за него же допиленный, до коммерческого качества и конкруенции...), т.е.как сказал - кто угодно кроме меня. Я отлично понимаю высер-вопрос: мол оригинальный то проект не мой, а пусть всего сообщества как ему переданный, - я беру чужой (конечно совсем немалый)труд и типа вот такая цена, а не устраивает - никто не заставляет же, могу даже и сам с нуля сделать благо исходники есть подглядеть форматы... Но: 2) с нуля - неполучится, тупо по затратам времени, в смысле - я неготов таким мне неинтересным заниматься(вместо улучшений которые хотелось бы внести), не говоря уже про ещё несколько лет на то; 1) ну и что пользы OSC сообществу (и игрокам из них в частности) - с того что движок валяется с каждым годом всё больше протухая... вместе с устареванием игры, а уж ИИ - вообще жутко имбицильный, видать автор надеялся подсадить игроков на мультиплеер и затем брать денюжку(как делают чуть ли не все такие) - но, что то несраслось или не смог аудиторию набрать(всё же и качество OSC-халтурно и серьёзно раскрутить халтурку нереально(но, даже раскрутив за счёт популярности игры когда то - всёравно не удалось заманить), да тут и неважно почему. Повторю мысль: ну и что пользы OSC сообществу (и игрокам из них в частности) - с того что движок валяется с каждым годом всё больше протухая... вместе с устареванием игры. Получается что, GPL это не для тех кому ехать (т.е.играть в полноценный reengine с новыми свистелками и перделками и более совремнным управлением, а в идеале и с новой улучшенной графикой и прочим [чтобы непересекаться по (С) с самой игрой или иначе хотя бы просто хитро-отмасштабированная старая графика под совремные мониторы (а, она там 2D и очень поганенько выглядит на совремнных FullHD и выше экранах, как и поныне фанаты олдфаги играя уже просто мучаются, не говоря уже про 256 цветов)]), - а, для тех кому нужны только шашечки(исходники, пусть и говно заглюченное трудно-играбельное тем более фактически без ИИ)?... Получается так, безальтернативно. Так что GPL - убивает прогресс. Другое дело что я бы к BSD лицензии ряд пунктов касающихся прибыли особенно крупных [корпорациями] добавил бы, чтобы делилсь с оригинальными разработчиками, но понимаю что это технически трудно проконтроллировать и уже будет ...не свободно же. Тут могли бы GPL пойти на встречу сделав так, ибо они - итак несвободны и т.о. только увеличили бы свободу у себя, но тоже понимаю что это поработительная лицензия/Corporation и на это не пойдут под разными реальными - но, натянутыми предлогами, начиная с вирусной убер-идеи открытости кода. Замкнутые круги в общем в OSC. Но, свободна всё же только BSD лицензия и точка. А, всякие например CCA это тоже какой то хитрый зонд, который вроде и заявляет предложенное, но слишком уж много там пунктов как в GPL... Но, даже если сделать ещё другую лицензию с указанным мной - не ясна ситуация с доступностью и методикой оплатой %/n прибыли, и думаю компании вообще на такое не пойдут (их бухгалтерия вскроется [у кого то и на отмывании денег гипер "продажами" ПО], или низкие продажи продукта - вопреки публичным пиар заявлениям). Тут ещё и другие проблемы. А, донаты - не решение, могли бы быть им - будь на уровне госфонда, но тут маячит вопрос распилов... (хоть уверен такое не только в госфондах у OSC) и жуткой дискредитации честных разработчиков т.о., впрочем как и не достаточного выделения финансирования - как раз таким. Ну и вопрос надобности разрабатываемого - кто будет решать?... Что то у меня сомнения что я бы с указанным движком - дождался бы финансирования, тем более что фанатов игры с каждым годом - всё меньше и меньше, а новым поколениям - графон не тот и вообще 2D, ну вы поняли. Т.о. BSD лицензию даже и не улучшить, её прикол остаётся именно в полной свободе, путь и лукавенько - тоже заманивая внештатных рабов, ну а пока компании или просто оригинальные авторы сами пилят и учитывают запросы - никто не против, и я тоже не мечтаю вместо оригинального автора продолжать форк, вот только он забил, форки были - но, по мелочам. Проект мёртв, был бы под BSD - это глядишь меня простимулировало бы больше подсуетьться и начал пилить, кто знает мождет даже и открыл бы код - например если бы не вышло монетизировать, или после периода того, а то и сразу пусть и (С)-перелицензировав[до поры времени] - что позволило бы не только моды лучше делать, но и портировать в другие ОС - а разве не это главное линуксоидам по нормальному (по кр.мере пока и я не забросил бы разработку), а вот желание заработать на мне желая форканув - как то не очень соотносится тут c линуксоидными идеалами :]). Т.о. GPL = ни сам не гам, ни другим не дам.   (По кр.мере когда популярность проекта средняя и тем более низка, и когда массово нанятые/задонатенные работники - не сильно помогут проекту из-за отсутвия идей и тем более правильных(что очень субъективно вдобавок), а значит даже и когда оригинальный автор ещё не бросил разработку, но очень тянет или идеи закончились, или если неполучить "донаты" за вставку дыр).
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	57. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (-), 10-Ноя-19, 15:50
	>Ну так форкни и перелицензируй под GPL, вы же так постоянно делаете. Расскажи это пацыкам, которые переписали утилиту ls. Вместе посмеёмся.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	60. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (41), 10-Ноя-19, 16:02
	> GPL v3+ Я правильно понимаю, что ты, придя, скажем, в банк, подписываешь абсолютно чистые листы А4, а уже потом банк печатает на эти листы абсолютно любые условия? Потому что "+" в GPLv3+ именно то и означает, что ты передал столлману пачку листов А4 со своей подписью внизу. Ну а он в них может вписать любой свой маразматический бред.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	69. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (19), 10-Ноя-19, 17:24
	Не столлману, а форкеру. Форкер может апгрейднуть версию. А может и не апгреднуть
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

50. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
Сообщение от Простой парень (?), 10-Ноя-19, 14:00
Проблема не в том, какой язык лучше, а в том, какое место он может занять. Вот смотрите: приложение пишется на питоне, интерпретатор питона на си, а среда выполнения си на ассемблере. Чёткая иерархия, каждому языку есть место, согласно тому, какие задачи на нём проще решать. Проблема в том, что это складывается стихийно, а не предсказуемым образом. Разработчики языка исходят из того, что они могут сделать, какие у них есть идеи, а не из того, какие задачи стоят перед современным языком. Вот раст пока не нашёл свою нишу, но то что развитие с++ зашло в тупик, подталкивает разработчиков испытывать новые языки у себя в проектах, и только поэтому раст держится.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	54. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+2 +/–
	Сообщение от Аноним (41), 10-Ноя-19, 14:28
	> каждому языку есть место, согласно тому, какие задачи на нём проще решать Аналогия, где языки представляются различными инструментами (молоток чтоб забивать гвозди, микроскоп чтоб рассматривать бактерии) неверна и является попыткой оправдать уродливые решения в отдельно взятом языке. Правильная аналогия представляет языки программирования как естественные языки: подавляющее большинство мыслей можно выразить на всех языках мира, но у каких-то языков при выражении определенных мыслей наблюдаются проблемы. Если взять задачку написать хелловорлд, то никакой адепт аналогии с инструментами-молотками-микроскопами не возьмется утверждать, что для написания хелловорлда как нельзя лучше подойдет такой-то язык: хелловорлд может быть написан на всех языках. Но по мере усложнения задачки, языки один за другим станут отваливаться вследствие их недостатков, пока не останутся самые сильные. Что касается вышеупомянутого пихона, то он отваливается раньше всех.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	79. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (27), 10-Ноя-19, 19:31
	>развитие с++ зашло в тупик и в чём это проявляется?
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	82. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Простой парень (?), 10-Ноя-19, 20:40
	>>развитие с++ зашло в тупик > и в чём это проявляется? map, unordered_map - этого мало? А то что конструктора для std::string из форматированной строки до сих пор нет, это что? Эти все конференции где тучи высоколобых с упорством достойным лучшего применения спорят о какой то никому кроме них не нужной сpaни, мало?
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	85. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (27), 10-Ноя-19, 21:37
	https://www.youtube.com/watch?v=fT3OALUyuhs
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	163. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Lex (??), 12-Ноя-19, 23:53
	С каждыми "новыми плюшками", синтаксис плюсОв становится всё монструозней и уродливей. Хотя, и с джавой примерно аналогично.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	89. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+3 +/–
	Сообщение от nelson (??), 10-Ноя-19, 23:39
	> приложение пишется на питоне, интерпретатор питона на си, а среда выполнения си на ассемблере Среда выполнения си на ассемблере, говорите? Правду говорят, что обучение программированию питоном до добра не доводит )
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

83. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+1 +/–
Сообщение от Аноним (83), 10-Ноя-19, 21:06
А как там у Rust с экспортом? Можно библиотеку с ABI использовать в сишной программе просто линконув их?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	86. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+3 +/–
	Сообщение от Ordu (ok), 10-Ноя-19, 23:01
	#[no_mangle] fn print_int(i: i32) {     println!("{}", i); } Такое вполне можно вызывать из C. Но если ты заботишься о кроссплатформенности кода, то вместо i32 тебе лучше использовать std::os::raw::c_int.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

87. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+2 +/–
Сообщение от Аноним (87), 10-Ноя-19, 23:03
> Формат AV1 заметно опережает x264 и libvpx-vp9 по уровню сжатия Абсолютно безграмотная фраза, спутаны сущности формата и кодировщика. Формат предоставляет не определённый уровень сжатия, а инструментарий для укладывания контента в бит-поток, который при использовании кодировщиком даёт определённый уровень сжатия (причём сильно зависимый от настроек кодирования и характера контента). Корректно сравнивать формат AV1 с форматами H.264 и VP9 — в этом случае AV1 действительно на голову выше, но есть ньюанс: речь не о непосредственно доступном пользователю инструменте, а о неком его описании. Также корректно сравнивать кодировщики libaom-av1 и rav1e с x264 и libvpx-vp9, и это уже будет речь не о сферических конях в вакууме, а о практически применимых инструментах. Такого сравнения с использованием релиза сабжа сильно не хватает в тексте новости, но, к сожалению, его крайне сложно провести всесторонне, да и однозначного результата оно не даст.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

114. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
Сообщение от Аноним (95), 11-Ноя-19, 20:01
Всё же хотелось бы и тестов, ладно фиг с ними с тормозами Rust, но что - на счёт самого сжатия?... И патентов...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

116. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
Сообщение от Аноним (87), 11-Ноя-19, 20:58
Что-то ебилдов не видно — ни в портеже, ни в оверлеях, ни на багтрекере нет. Деплой зоопарка растолиб оказался гентушникам не под силу?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	126. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (122), 12-Ноя-19, 03:00
	Какой такой зоопарк? В расте статическую линковку делают обычно,.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	129. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	–1 +/–
	Сообщение от Аноним (-), 12-Ноя-19, 10:31
	>Какой такой зоопарк? В расте статическую линковку делают обычно,. Поэтому helloworl! на Расте весит 5 Мегабайт?
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	134. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от анонн (ok), 12-Ноя-19, 13:03
	> Поэтому helloworl! на Расте весит 5 Мегабайт? Странно. % rustc -V                                                                         rustc 1.38.0 % cat hello.rs fn main() {   println!("Hello World!"); } % rustc hello.rs % ll hello -rwxr-x---  1 анонн  wheel   286K 12 Nov. 16:59 hello % readelf -d hello|grep NEED                                                   0x0000000000000001 NEEDED               Shared library: [libthr.so.3] 0x0000000000000001 NEEDED               Shared library: [libgcc_s.so.1] 0x0000000000000001 NEEDED               Shared library: [libc.so.7] % strip hello % ll hello -rwxr-x---  1 анонн  wheel   215K 12 Nov. 16:59 hello % rustc hello.rs -O -C lto % strip hello % ll hello -rwxr-x---  1 анонн  wheel   189K 12 Nov. 17:00 hello Попробуйте собирать не из под Виндовс.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	140. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Anonymoustus (ok), 12-Ноя-19, 16:19
	>> Поэтому helloworl! на Расте весит 5 Мегабайт? > % ll hello > -rwxr-x---  1 анонн  wheel   189K 12 Nov. 17:00 > hello > > Попробуйте собирать не из под Виндовс. Всё равно же много. У меня в Виндовс хелловорлд на Сишечке, собранный посредством TCC (Tiny C Compiler by Fabrice Bellard), весит 2048 байт. TCC, конечно, не мейнстрим вроде GCC, но пусть будет убойным примером ради высшей справедливости. Если собирать обычным GCC (была использована версия 4.7.2), то получается 34816 байт статически слинкованного сабжа.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	145. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от анонн (ok), 12-Ноя-19, 19:43
	> Всё равно же много. Учитывая, что libc вообще-то рантайм библиотека для этой самой сишечки, а не раста, то нормально. > У меня в Виндовс хелловорлд на Сишечке, собранный посредством TCC (Tiny C > Compiler by Fabrice Bellard), весит 2048 байт. Ну, хелловорлд я вам и в 20-100 байтов запулить могу, если брать старые версии виндовс. А PE32 в винде ЕМНИП ограничен минимально прожевываемым самим PE-загрузчиком размером выравнивавия секции (в смысле: section alignment) -- т.е. если без слишном уж грязных хаков, то 0.5-2КБ, зависит от версии винды и от дырявости моей памяти ;) > TCC, конечно, не мейнстрим вроде GCC, но пусть будет убойным примером ради высшей справедливости. А убоен он в первую очередь беспощадной бессмысленность такого примера, потому что все же, в конечном итоге интересны совсем не хелловорды? ;) Ну и: % cat hw.c && gcc -Os -s hw.c -o hw && ll hw #include <stdio.h> int main(void) {     puts("Hello World!");     return 0; } -rwxr-x---  1 анонн  wheel   4,8K 12 Nov. 21:00 hw % gcc --version       gcc (FreeBSD Ports Collection) 9.2.0 > Если собирать обычным GCC (была использована версия 4.7.2), то получается 34816 байт > статически слинкованного сабжа. В винде - статистически слинкованный? Я что-то пропустил и PE-бинарник уже "годен" (valid) без привязки к kernel32.dll/user32.dll (и они точно-точно не прилинковываются ;) )? Если слинковать статистически, это выглядит примерно вот так: gcc -O2 -s -static hw.c -o hw && ll hw -rwxr-x---  1 анонн wheel   553K 12 Nov. 21:09 hw ldd hw ldd: hw: not a dynamic ELF executable Сейчас возможно набегут особо поклоннистые поклонники альтератив типа musl и заявят, что я ламо, протому что получить можно в 10 раз меньший бинарник, если использовать прямые руки и т.д. и т.п. - но вообще-то это не принципиально. В расте тоже можно немного поизвращаться с (расто-std) библиотеками: https://github.com/johnthagen/min-sized-rust ldd target/release/min-sized-no_std target/release/min-sized-no_std:     libc.so.7 => /lib/libc.so.7 (0x800248000) -rwxr-x---  2 анонн  wheel    15K 12 Nov. 21:25 target/release/min-sized-no_std Но смысл сего действа все же ускользает от меня (сравнение размера хелловорда ради сравнения размеров хелловордов?)
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	148. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Anonymoustus (ok), 12-Ноя-19, 20:05
	>> Всё равно же много. > Учитывая, что libc вообще-то рантайм библиотека для этой самой сишечки, а не > раста, то нормально. Ничего нормального в этом нет, просто все уже привыкли к жирному тормознутому говнософту. Внутри жирных бинарников — мусор. В памяти, когда они выполняются, тоже мусор. >> У меня в Виндовс хелловорлд на Сишечке, собранный посредством TCC (Tiny C >> Compiler by Fabrice Bellard), весит 2048 байт. > Ну, хелловорлд я вам и в 20-100 байтов запулить могу, если брать > старые версии виндовс. А PE32 в винде ЕМНИП ограничен минимально прожевываемым > загрузчиком размером выравниваия секции (т.е. если без слишном уж грязных хаков, > то 0.5-1.5КБ, зависит от версии винды и от дырявости моей памяти) > ;) Примеры в студию, чо. :) >> TCC, конечно, не мейнстрим вроде GCC, но пусть будет убойным примером ради высшей справедливости. > А убоен он в первую очередь беспощадной бессмысленность такого примера, потому что > все же, в конечном итоге интересны совсем не хелловорды? ;) Я так и написал: этот пример исключительно для убойности, а не для пользы. > Ну и: > -rwxr-x---  1 анонн  wheel   4,8K 12 Nov. 21:00 Другим компилятором (GCC 6.3.0) у меня получилось 12 КБ. Ну есть же простор для манёвров. >> Если собирать обычным GCC (была использована версия 4.7.2), то получается 34816 байт >> статически слинкованного сабжа. > В винде - статистически слинкованный? Я что-то пропустил и Portable Executable уже > годен(valid) без привязки к kernel32.dll/user32.dll (и они точно-точно не прилинковываются)? > Если слинковать статистически Статически же. Статистика про совсем другое. > это выглядит примерно вот так: > > gcc -O2 -s -static hw.c -o hw && ll hw > -rwxr-x---  1 анонн wheel   553K 12 Nov. 21:09 hw > ldd hw > ldd: hw: not a dynamic ELF executable > Как-то так: ldd Hello.exe         ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77c00000)         kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x759d0000)         msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x75d60000) В опциях компилятора: -static-libstdc++ -static-libgcc > Сейчас возможно набегут особо поклоннистые поклонники альтератив типа musl и заявят, что > я ламо, протому что получить можно в 10 раз меньший бинарник, // поскипано > Но смысл сего действа все же ускользает от меня (сравнение размера хелловорда > ради сравнения размеров хелловордов?) Смысл действа в рационализации того, что происходит. Выше я отметил про современный жирнософт, на 95 % наполненный цифровым мусором. Сколько, например, процессорного времени и оперативной памяти потребляет говнософт на каком-нибудь электроне? Вам не кажется это немножечко 3,14здецом?
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	156. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от анонн (ok), 12-Ноя-19, 21:19
	>>> У меня в Виндовс хелловорлд на Сишечке, собранный посредством TCC (Tiny C >>> Compiler by Fabrice Bellard), весит 2048 байт. >> Ну, хелловорлд я вам и в 20-100 байтов запулить могу, если брать >> старые версии виндовс. А PE32 в винде ЕМНИП ограничен минимально прожевываемым >> загрузчиком размером выравниваия секции (т.е. если без слишном уж грязных хаков, >> то 0.5-1.5КБ, зависит от версии винды и от дырявости моей памяти) >> ;) > Примеры в студию, чо. :) Для PE32 классика же: http://www.phreedom.org/research/tinype/ Конкретно у себя нашел пару-другую 512 байтов (там всех делов-то - указать линковщику размер выравнивания и чтобы все в одну секцию мержил: Link /SUBSYSTEM:WINDOWS /FILEALIGN:512 /MERGE:.rdata=.text /MERGE:.data=.text /section:.text,RWE ) ну и кучу 1KB-мелочи. На фоне tinype не вижу особого смысла колупать доисторическое. А насчет старых версий: CSEG segment org 100h Begin:     mov ah,9     mov dx,offset Message     int 21h     mov ah,1     int 21h       int 20h Message db 'Hello, world!$' CSEG ends end Begin => 27 байтов "hello.com" ;) Moгу еще подкинуть кейген BURN.COM, размером в 136 байтов (чуть ли не половина - реализация генератора псевдо-случайных чисел), для уже-неведомо-чего ну и прочего добра (та же реализация RC4 в 293 байта) DOS-EXE "Hello World" будет чуть побольше - 59 байтов (для сборки современным FASM можно использовать вооот этот хелловрд https://board.flatassembler.net/topic.php?t=1736) > Смысл действа в рационализации того, что происходит. Выше я отметил про современный жирнософт, на 95 % наполненный цифровым мусором. Как будто от возмущения (тем более на опеннете) хоть что-то изменится. Разве что бананом (возможно, уже разок съеденным) кинуть могут.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	164. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Ordu (ok), 12-Ноя-19, 23:56
	>[оверквотинг удален] > Begin: >    mov ah,9 >    mov dx,offset Message >    int 21h >    mov ah,1 >    int 21h   >    int 20h > Message db 'Hello, world!$' > CSEG ends > end Begin Тут как минимум пять байт лишние. Второй вызов int 21h не нужен -- он туда вставлен в силу дурацкой манеры вендовсюзеров завершать досовские программы, которая возникла из-за того способа, которые вендо-IDE запускают досовские программы. ппц выбешивает, когда утилита отработав, подвисает ожидая ввода. И вместо int 20h можно сделать ret. Это работает с com'ами, и экономит ещё один байт. И в ответ на это: > Примеры в студию, чо. :) Я докину примерчик под линь: http://timelessname.com/elfbin/ 142 байта и по словам автора есть возможности для дальнейшего уменьшения размера.
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	184. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (122), 16-Ноя-19, 17:51
	Нужно с opt-level=3 собирать чтобы работыл dead code elimination
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	133. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (87), 12-Ноя-19, 11:56
	Дикий зоопарк совершенно, который при запуске сборки начинает качаться с репозиториев на жидхабе неконтролируемым образом. Для сборки сабжа нужно скачать 138 (!) пакетов с библиотеками, все из которых для включения в Gentoo нужно оформить в виде ебилдов. Это уже привязка к облаку какая-то пошла, в оффлайне build-система раста растеряется и ничего не сможет сделать. Статическая линковка помогает только в случае распространения бинария от разработчика к пользователю. В большинстве дистрибутивов unix-подобных ОС принята другая модель, в которой от разработчика берутся только исходники и далее подготавливаются мэйнтейнерами для автономной сборки на build-фермах. Сабж довольно сложно деплоить таким образом.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	137. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (-), 12-Ноя-19, 15:37
	Слыхал поговорку: "Linux писан сишными прогоаммистами, и для сишных программистов Linux". UNIX - BSD - Linux - это множество кусков сишного кода. При всём уважении к языку Rust, но всё же этот язык является чужеродным элементом в Unix-подобных системах.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	154. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (87), 12-Ноя-19, 21:05
	Проблема не в языке, а в том, что используемая сабжем build-система, cargo, включает в себя средство установки компонентов из удалённого репозитория, что в UNIX-подобных ОС является прерогативой исключительно пакетного менеджера. В экосистеме UNIX отлично живут программы на любых языках, где build-системе достаточно скормить каталог с исходниками и она его автономно и предсказуемо соберёт, но ситуация, когда эта build-система при сборке внезапно (в man cargo-build нигде не сказано о возможной сетевой активности, а также нет опции для её отключения) начинает самостоятельно ломиться во внешний мир и что-то непонятное из него тащить, абсолютно недопустима.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	182. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от пох. (?), 15-Ноя-19, 07:29
	> Проблема не в языке, а в том, что используемая сабжем build-система, cargo, > включает в себя средство установки компонентов из удалённого репозитория, что в > UNIX-подобных ОС является прерогативой исключительно пакетного менеджера. В экосистеме как будто в неюниксоподобных это не так (разумеется, там тоже можно нагадить в %USER%/ApplicationData точно так же, как все новые модные язычки в новом-стандарте гадят вам в $HOME - и, разумеется, это тоже признак макаки, если только пользователь специально не сообщил о своем нежелании пользоваться защитными механизмами системы и делиться с другими пользователями своим прекрасным софтом.) > UNIX отлично живут программы на любых языках, где build-системе достаточно скормить > каталог с исходниками и она его автономно и предсказуемо соберёт, но вообще-то уже давно - нет, если программа сложнее х-ловрот. :-( Новые-модные девелоперы-обезьянки разучились autoconf. Вермишель из pkg-config, модных систем сборок на нескучных язычках с зависимостями всего от всего, и каких нибудь авторских соплей сверху фэйлится на любом чуть отличающемся от совсем дубового раскладе. При том что в остальных случаях вместо всего этого мегатрэша хватило бы -I/usr/local/include -L/usr/local/lib почти всегда и на весь миллион нескучных библиотечек. То что не в local - и так гвоздем прибито к компилятору. (до сих пор удивляет что в *bsd не могут добавить туда и local, и навсегда избавиться от ненужных поисков ненужных pkg-config'ов и прочего хлама - в 99.99% случаев не возвращающего ничего кроме этого самого local/{include,lib}, а в уникальном где оно так не работает - требующего ручного патча, потому что все равно не работает) > ситуация, когда эта build-система при сборке внезапно (в man cargo-build нигде > не сказано о возможной сетевой активности, а также нет опции для афтыри раньше программировали на nodejs, им и в голову не приходит, что можно было как-то иначе. > её отключения) начинает самостоятельно ломиться во внешний мир и что-то непонятное и обламывается о корпоративные правила, где внешний мир только через прокси-сервер, настройки которого это недоразумение правильно прочитать тоже не умеет. Даешь каждому тазу где надо что-то разово пересобрать - полный доступ в интернет!
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	183. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
	Сообщение от Аноним (87), 15-Ноя-19, 18:54
	> как будто в неюниксоподобных это не так Там обычно нет пакетного менеджера с исключительной прерогативой установки компонентов из внешнего мира. Вместо этого программы поставляются в виде отдельного инсталлятора, который всё чаще самой программы не содержит, а лезет за ней в веб. Вероятно, по образу и подобию этих инсталляторов и сделан вышеупомянутый cargo. > Вермишель из pkg-config, модных систем сборок на нескучных язычках с зависимостями всего от всего, и каких нибудь авторских соплей сверху фэйлится на любом чуть отличающемся от совсем дубового раскладе. Как же тогда софт собирается в nixos и guixsd, где /usr и /lib вообще отсутствуют? > афтыри раньше программировали на nodejs Похоже на то: js-макакам вообще никакие правила не писаны.
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

161. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."	+/–
Сообщение от Аноним (161), 12-Ноя-19, 23:02
Ну, hevc не такой уж медленный. У меня на Pentium 4 он кодит 576p с пресетом fast аж целый 1 fps. Мне не проблема подождать пару часов, чтобы закодить 6-минутный ролик. Другое дело, что декод 576p 1500k в realtime уже не тянет. Результат не посмотреть, только для других делать. Меньшие разрешения идут.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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