The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



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

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

Подробнее: https://www.opennet.ru/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 
Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

121. Скрыто модератором  –1 +/
Сообщение от Ordu (ok), 12-Ноя-19, 02:21 
Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

141. Скрыто модератором  –2 +/
Сообщение от Аноним (141), 12-Ноя-19, 16:19 
Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

142. Скрыто модератором  +/
Сообщение от Аноним (141), 12-Ноя-19, 16:20 
Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

143. Скрыто модератором  +/
Сообщение от Ordu (ok), 12-Ноя-19, 18:06 
Ответить | Правка | ^ к родителю #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 
Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

151. Скрыто модератором  +/
Сообщение от Аноним (144), 12-Ноя-19, 20:52 
Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

152. Скрыто модератором  +/
Сообщение от Ordu (ok), 12-Ноя-19, 20:57 
Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

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

160. Скрыто модератором  +/
Сообщение от анонн (ok), 12-Ноя-19, 22:20 
Ответить | Правка | ^ к родителю #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 
> Кто сказал, что хуже?

Я сказал.
Тут же выше: https://www.opennet.ru/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..."  +/
Сообщение от Lexemail (??), 12-Ноя-19, 23:53 
С каждыми "новыми плюшками", синтаксис плюсОв становится всё монструозней и уродливей.
Хотя, и с джавой примерно аналогично.
Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

89. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."  +3 +/
Сообщение от nelsonemail (??), 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 | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру