The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Первый официальный выпуск rav1e, кодировщика AV1 на языке Rust , opennews (?), 09-Ноя-19, (0) [смотреть все]

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


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

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

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

95. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."  +1 +/–
Сообщение от Аноним (95), 11-Ноя-19, 14:40 
- Вот смешные пошли программисты...
"Дело не в стабильности языка"

(Или это только растаманы? Впрочем, само это название тут: пожалуй - намекает)

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

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

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

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

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

Я не говорю, что это прихоть, или что так не надо было делать. Но в контексте разговора о стабильности языка, это явное указание на его нестабильность, вне зависимости от причин её.

Ответить | Правка | Наверх | 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
Ответить | Правка | Наверх | 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.

Ну раз аноним так говорит, то так оно и есть.


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

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

Ответить | Правка | Наверх | 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 как минимум выделение памяти через подсчет ссылок, а операции увеличения
> / уменьшения счетчика атомарные, что ни разу не быстро.

Хм, т.е. на самом деле "занятия любовью" с владениями/заимствованиями -- это чисто из любви к мазохизму, а не потому что при этом компилятор может отслеживать владельца (ссылки) и автоматически вставлять освобождалку памяти при выходе владельца за пределы области видимости?


Ответить | Правка | Наверх | 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) это деза, как причина таких убер-тормозов.

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

98. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."  +/–
Сообщение от Ordu (ok), 11-Ноя-19, 15:14 
> Ага... Проверка индексов массивов в runtime, и всё прочее
> - типа бесплатно?...

Ты читал вообще о чём речь? Речь идёт о счётчиках ссылок, а не о массивах и индексах.

Но если тебе интересно поговорить про индексы, то да, эти проверки бесплатны в рантайме, дополнительная сложность выражается числами неотличимыми от статистической погрешности. Тому есть две причины:

1. агрессивный инлайн, оптимизация на фоне отслеживания владельца массива (оптимизатор может полагаться на то, что если поле size в динамическом массива де факто константно в данном куске кода, значит оно константно и никто исподтишка его не поменяет), вырезают большую часть проверок или хотя бы выкидывают их из циклов наружу

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

> Т.к."усложнения алгоритмов" - без публичного сравнения по скорости с полноценно оптимизированным вариантом на Си(+SIMD+Asm) это деза, как причина таких убер-тормозов.

Перечитай новость, там не сказано, что rust быстрее чем C. Там сказано, что данная реализация быстрее какой-то другой реализации. Там не сказано, что она быстрее из-за того, что написана на rust'е. Если тебе это всё равно не даёт покоя, возьми и напиши полноценно-оптимизированный вариант на C(+SIMD+Asm) -- я буду только рад, если тебе удастся сделать быстрее: мне нравится кодировать видео в небольшие объёмы, и время кодирования напрягает.

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

108. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."  –1 +/–
Сообщение от Аноним (95), 11-Ноя-19, 16:55 
Для начала скажу - не тыкай другим, хамя.

> "эти проверки бесплатны в рантайме, дополнительная сложность выражается числами неотличимыми от статистической погрешности"

Да, ну - потому наверное в Си[++] её и не делают... (а, в GCC сделав - выкинули в последующих версиях, в Delphi же выключали всегда в не DEBUG, кто нт тот сознательно доп.тормозил).
И я сказал - и другие случаи, всякие как раз фичи, раста. Они вовсе не бесплатны, тем более при типичном активном их использовании.

> "возьми и напиши полноценно-оптимизированный вариант на C(+SIMD+Asm)"

- Потратить кучу времени(чуть менее чем ~пол жизни) - только на изучние их кодека(и без оптимизаций)? А, что ещё?!...

Ответить | Правка | Наверх | 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)"
> - Потратить кучу времени(чуть менее чем ~пол жизни) - только на изучние
> их кодека(и без оптимизаций)? А, что ещё?!...

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

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

118. Скрыто модератором  –1 +/–
Сообщение от Аноним (118), 12-Ноя-19, 00:47 
Ответить | Правка | Наверх | Cообщить модератору

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

141. Скрыто модератором  –2 +/–
Сообщение от Аноним (141), 12-Ноя-19, 16:19 
Ответить | Правка | Наверх | 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 - незачем коверкать именования. И тем более Великий и Могучий.

Ответить | Правка | Наверх | 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'омана - я уже просто не жду таких элементарных вещей - потому и потратил своё время на "разжевывание". Впрочем, не жду принятия даже и того...
Ответить | Правка | Наверх | 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/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста.

Вот только пока код писался на сях, программисты не забывали про оптимизацию, а с появлением всяких растов и прочих питонов решили, что оптимизацией теперь должен заниматься кто угодно, только не они. В итоге мы имеем калькуляторы, требующие гиг оперативки ("Не, ну а чо, она же дИшОвая").

Ответить | Правка | Наверх | 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 парсер с табличкой  -- уделывает "щас мы зафигачим по быстрому снисходящий рекурсивный парсер, потому что все остальное на сишечке слишком геморно, а тут и так сойдет" :)

Ответить | Правка | Наверх | 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;
}

Простите за мой французский.
Ответить | Правка | Наверх | 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++, иначе каждая запись будет "поверх" предыдущей) -- именно как-то так ;)

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

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

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

Давай криво. Код после твоей правки - по прежнему нерабочий. Мне не очень понятно, зачем тогда вообще что-то править в примере было.


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

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

88. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."  +/–
Сообщение от Anonymoustus (ok), 10-Ноя-19, 23:32 
Такие примеры мне нравятся. Сразу с тестами.
Ответить | Правка | Наверх | 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 байт. Весьма интересная задача реализовать аллокатор под это дело.

Ответить | Правка | Наверх | 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 в худшем случае сработает каждую шестнадцатую итерацию. Проще говоря, не так страшна "постоянная реаллокация", как ею пугают.

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

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

Или он сработает каждый раз. Или не разу. Компилятор может его выкинуть из кода, потому как UB, а это значит его можно заменить на noop.

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

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

138. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."  +/–
Сообщение от Ordu (ok), 12-Ноя-19, 16:11 
> Если ты всерьёз предполагаешь, что написавший "сработает на 16й итерации" собирается такое
> запускать, лучше спрячься под стол. Пока не взорвался твой монитор, потому
> как UB.

Так у него взорвётся, если чё. Я предпочитаю такие вещи изучать так: https://gcc.godbolt.org/z/HCmknA

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

170. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."  +/–
Сообщение от Аноним (66), 13-Ноя-19, 11:17 
>> Если ты всерьёз предполагаешь, что написавший "сработает на 16й итерации" собирается такое
>> запускать, лучше спрячься под стол. Пока не взорвался твой монитор, потому
>> как UB.
> Так у него взорвётся, если чё. Я предпочитаю такие вещи изучать так:
> https://gcc.godbolt.org/z/HCmknA

Вполне предсказуемый результат трансляции. Плоская модель памяти, сегментные регистры не используются.

Что характерно, транслятор посчитал условие assert() выполнимым с малой вероятностью.

Assembly/Compiler Coding Rule 3. (M impact, H generality) Arrange code to be consistent with the static branch prediction algorithm: make the fall-through code following a conditional branch be the likely target for a branch with a forward target, and make the fall-through code following a conditional branch be the unlikely target for a branch with a backward target.

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

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

97. "Первый официальный выпуск rav1e, кодировщика AV1 на языке Ru..."  –1 +/–
Сообщение от Аноним (95), 11-Ноя-19, 15:00 
> Кто сказал, что хуже?

Я сказал.
Тут же выше: http://www.opennet.ru/opennews/art.shtml?num=51837#96
"... Проверка индексов массивов в runtime, и всё прочее - типа бесплатно?... ..."

P.S.
А, бенчмаркам верят только те - кому выгодно верить в *конкретный* бенчмарк...
Сколько было уже таких людей несосчитать... то C# такой же по скорости, то ранее - Джаба с JITом;
а, по факту - выше головы никому не прыгнуть.

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

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

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

А, в некоторых случаях - наверняка и куда побольше ваших % разницы - и без доп.оптизации, разные бывают ситуации...

Но, да сравнение Си - супернагло, до смехоты. Ещё бы сказали что так же быстр как на ассемблер (нет, ещё как можно и на нём - всё залагать, т.б.когда надо чтобы сравнительный бенчмарк и на нём был тоже похуже)

Ответить | Правка | Наверх | 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) и в расте... и будут увеличиваться ещё.
Именно версии компиляторов и стандартов - делают их непригодными с каждым новым годом.
Т.о.тоже самое грозит любому языку с неостановленным развитием.

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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