|
|
|
4.111, Аноним (3), 18:18, 11/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> То есть декодер сделали раньше кодировщика?
Есть по меньшей мере 3 кодировщика помимо сабжа (больше) и 3 декодировщика. Dav1d только декодировщик, работает быстрее libaom (референсной реализации). Спеки открыты, каждый пилит как хочет.
| |
|
|
|
1.2, Аноним (3), 22:08, 09/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
А чё с аналогичными кодировщиками не сравнили? Ну, x265 там хотя бы, и libaom или как там его. Зачем сравнивать несравниваемое?
| |
|
|
3.7, Аноним (3), 22:32, 09/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Сабж не ограничен? Я так картиночки сохранял, емнип пришлось взять tga вместо tiff. Не встречал больше 10 на практике, но 12 вроде уже в ходу (для сравнения, у мониторов ограничение 10 с хаками было, не в курсе как сейчас).
| |
3.35, хотел спросить (?), 04:26, 10/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
а это плеать что?
цветовой субдискретизации 4:2:0, 4:2:2 и 4:4:4, 8-, 10- и 12-разрядного кодирования глубины цвета
| |
|
|
|
2.5, Иван (??), 22:17, 09/11/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
однозначно, по перфомансу не уступает Си, безопасность на высшем уровне, никаких UB
| |
|
3.8, IRASoldier_registered (ok), 22:33, 09/11/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
Rust'у, имхо, пока не хватает чего-то типа LTS. Наподобие стандартов C++98, C++11, С++17 и т.п. Слишком частые релизы для того, чтобы можно было в спокойный, неторопливый продакшен.
| |
|
4.23, Ordu (ok), 00:02, 10/11/2019 [^] [^^] [^^^] [ответить]
| +7 +/– |
> Rust'у, имхо, пока не хватает чего-то типа LTS. Наподобие стандартов C++98, C++11, С++17 и т.п.
Есть такое. Rust 2015 и Rust 2018. Ты можешь взять распоследний rustc и сказать ему, что тебя интересует rust 2015, и будет тебе rust 2015.
Впрочем они сломали rust 2018 в последней версии раста, переведя из разряда варнингов в разряд еггогов ругань нового борроу-чекера. Но они предупреждали заранее и эти варнинги довольно долго мозолили глаза, было время всё исправить.
Они так же планируют сломать rust 2015, через некоторое время, сейчас там пока продолжают быть варнинги.
Но это, по-моему, единственное что они ломали. Дело не в стабильности языка, дело в стабильности библиотек. Есть всякие там std, tokio и ряд других, которые достаточно стабильны, но их не так уж и много. Но для того, чтобы набрать достаточное количество и разнообразие стабильных библиотек расту потребуется ещё не меньше пяти лет, а может и лет десять. Это не быстро, потому что такое количество кода требует очень много человекочасов.
| |
|
5.95, Аноним (95), 14:40, 11/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
- Вот смешные пошли программисты...
"Дело не в стабильности языка"
(Или это только растаманы? Впрочем, само это название тут: пожалуй - намекает)
| |
|
6.117, Аноним (117), 21:27, 11/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Проблем со стабильностью языка не должно вроде быть пока все обратно совместимо, разве нет? Комментарий выше говорит про некоторые примеры когда обратная совместимость в последнее время ломалась, но вроде в целом выглядит все не так страшно, если честно. Насколько я понимаю они там говорят что обратная совместимость у вас сломается только если у вас уже баг в коде.
| |
|
5.122, Аноним (122), 02:49, 12/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Это не просто варнинги, это баги старого чекера. Так что это не прихоть
| |
|
6.127, Ordu (ok), 03:02, 12/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Это не просто варнинги, это баги старого чекера. Так что это не
> прихоть
Я не говорю, что это прихоть, или что так не надо было делать. Но в контексте разговора о стабильности языка, это явное указание на его нестабильность, вне зависимости от причин её.
| |
|
|
|
3.14, Аноним (14), 22:51, 09/11/2019 [^] [^^] [^^^] [ответить]
| +12 +/– |
Только вот перформанс сильно хуже C, а UB просто не называют UB. В остальном норм, поиграться полезно
| |
|
4.16, анонн (ok), 23:00, 09/11/2019 [^] [^^] [^^^] [ответить]
| +6 +/– |
> Только вот перформанс сильно хуже C, а UB просто не называют UB.
Ну раз аноним так говорит, то так оно и есть.
| |
|
|
6.33, burjui (ok), 03:37, 10/11/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Никак, для этого есть:
https://docs.rs/parking_lot/0.9.0/parking_lot/type.ReentrantMutex.html
Любой желающий может написать RFC, чтобы включили в std, а пока разработчики решают более важные проблемы, т.к. язык ещё относительно молод.
Только, ради всего святого, не надо гундеть про 3rd party (это я не лично вам, а всем "критикам"). parking_lot - стандарт де-факто в Rust.
| |
|
5.44, asdasd (?), 12:31, 10/11/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
В Rust как минимум выделение памяти через подсчет ссылок, а операции увеличения / уменьшения счетчика атомарные, что ни разу не быстро.
| |
|
6.52, Аноним84701 (ok), 14:21, 10/11/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
> В Rust как минимум выделение памяти через подсчет ссылок, а операции увеличения
> / уменьшения счетчика атомарные, что ни разу не быстро.
Хм, т.е. на самом деле "занятия любовью" с владениями/заимствованиями -- это чисто из любви к мазохизму, а не потому что при этом компилятор может отслеживать владельца (ссылки) и автоматически вставлять освобождалку памяти при выходе владельца за пределы области видимости?
| |
6.80, Ordu (ok), 20:15, 10/11/2019 [^] [^^] [^^^] [ответить] | +3 +/– | Кто это тебе сказал такое Rc и Arc -- это один из способов выделять память, но ... большой текст свёрнут, показать | |
|
7.96, Аноним (95), 14:49, 11/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Ага... Проверка индексов массивов в runtime, и всё прочее
- типа бесплатно?...
Так что ничего не удивительно что:
цитата:"из-за усложнения алгоритмов требует существенно больше времени для кодирования (по скорости кодирования libaom отстаёт от libvpx-vp9 в (!)сотни раз, а от x264 в (!)тысячи раз)"
Т.к."усложнения алгоритмов" - без публичного сравнения по скорости с полноценно оптимизированным вариантом на Си(+SIMD+Asm) это деза, как причина таких убер-тормозов.
| |
|
8.98, Ordu (ok), 15:14, 11/11/2019 [^] [^^] [^^^] [ответить] | +/– | Ты читал вообще о чём речь Речь идёт о счётчиках ссылок, а не о массивах и инде... большой текст свёрнут, показать | |
|
|
10.115, Ordu (ok), 20:37, 11/11/2019 [^] [^^] [^^^] [ответить] | +2 +/– | Скажи ещё раз, мне нравится эротичный звук твоего голоса Что значит не делают ... большой текст свёрнут, показать | |
|
|
|
9.168, Аноним (168), 04:23, 13/11/2019 [^] [^^] [^^^] [ответить] | +1 +/– | Будь вы даже хоть бейсиковцем но, DOS времён вам бы и то - было бы понятно что ... текст свёрнут, показать | |
|
|
|
|
|
4.32, burjui (ok), 03:29, 10/11/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
"Тут Аноним взмахнул волшебной палочкой, и в комментарии появились пруфы" (С) Джоан Рофлинг
| |
4.47, Аноним (47), 13:12, 10/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
В некоторых кейсах Rust быстрее. Например проблема алиасинга разрешается на этапе компиляции, а не в рантайме. Возможности статического анализа у Rust значительно шире. Это позволит в будущем автоматически применять более глубокие и сложные алгоритмические оптимизации. C/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста. И это часто ведет к значительному усложнению кода, снижению читаемости. Но обычно разработчик просто забивает, т.к. это требует анализа и потерь времени.
| |
|
5.63, Аноним (63), 16:43, 10/11/2019 [^] [^^] [^^^] [ответить]
| +5 +/– |
> C/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста.
Вот только пока код писался на сях, программисты не забывали про оптимизацию, а с появлением всяких растов и прочих питонов решили, что оптимизацией теперь должен заниматься кто угодно, только не они. В итоге мы имеем калькуляторы, требующие гиг оперативки ("Не, ну а чо, она же дИшОвая").
| |
|
|
7.66, Аноним (66), 17:03, 10/11/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>> C/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста.
>> Вот только пока код писался на сях, программисты не забывали про оптимизацию,
> Угу, а тож никто не помнит и ни разу не видел шЫдевры
> "оптимизации":
> while(n>0) { n= read(fd, buf + pos, 1); size++; buf = realloc(buf,
> size); }
[CODE]
while(n>0) {
n= read(fd, buf + pos, 1);
size++;
old_buf = buf;
buf = realloc(buf, size);
assert (old_buf == buf);
old_buf = buf;
}
[/CODE]
Простите за мой французский.
| |
|
|
|
10.120, Ordu (ok), 01:42, 12/11/2019 [^] [^^] [^^^] [ответить] | +/– | Этот assert имеет квантовую природу, он сработает и не сработает Доступ к указа... текст свёрнут, показать | |
|
11.131, Аноним (66), 10:42, 12/11/2019 [^] [^^] [^^^] [ответить] | +/– | Добавим педантизму Possible undefined behavior ranges from ignoring the situati... большой текст свёрнут, показать | |
|
12.132, Ordu (ok), 11:44, 12/11/2019 [^] [^^] [^^^] [ответить] | +/– | Или он сработает каждый раз Или не разу Компилятор может его выкинуть из кода,... текст свёрнут, показать | |
|
|
|
15.170, Аноним (66), 11:17, 13/11/2019 [^] [^^] [^^^] [ответить] | +/– | Вполне предсказуемый результат трансляции Плоская модель памяти, сегментные рег... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
|
|
|
5.97, Аноним (95), 15:00, 11/11/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Кто сказал, что хуже?
Я сказал.
Тут же выше: https://www.opennet.ru/opennews/art.shtml?num=51837#96
"... Проверка индексов массивов в runtime, и всё прочее - типа бесплатно?... ..."
P.S.
А, бенчмаркам верят только те - кому выгодно верить в *конкретный* бенчмарк...
Сколько было уже таких людей несосчитать... то C# такой же по скорости, то ранее - Джаба с JITом;
а, по факту - выше головы никому не прыгнуть.
| |
|
6.124, Аноним (122), 02:55, 12/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
И бенчмаркам никаким верить нельзя, и головой думать не нужно. Весело наверное в твоем мире жить
| |
|
|
|
3.26, Аноним (26), 01:11, 10/11/2019 [^] [^^] [^^^] [ответить]
| –3 +/– |
Если -20-60% условной производительности(и это без компиляторной магии си) это "не уступает", то можете использовать, только про си не упоминайте, уместнее тогда сравнивать с го и джава.
| |
|
4.169, Аноним (169), 04:49, 13/11/2019 [^] [^^] [^^^] [ответить] | –1 +/– | С чего такие цифры Они просто явно не учитывают умение доп-но оптимизировать р... большой текст свёрнут, показать | |
|
3.55, Аноним (55), 14:30, 10/11/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
> никаких UB
И как, бишь, D его B при целочисленном переполнении?
| |
|
4.100, Аноним (95), 15:30, 11/11/2019 [^] [^^] [^^^] [ответить] | –2 +/– | Чтоооо А, баги компилятора , а кривые руки программиста у растманов не знаю... большой текст свёрнут, показать | |
|
|
2.19, Аноним (19), 23:34, 09/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Стоит. Заметил, что я стал в своих программах на полноценном ООП отказываться от наследования в пользу композиции. Правда можно было бы и сделать нормальное наследование через композицию, но таких ЯП я не знаю.
| |
|
3.29, Crazy Alex (ok), 02:19, 10/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Ну и при чём тут Rust? Это отнюдь не вчера появившаяся идея. Я её у Саттера, кажется, первый раз встретил, а судя по википедии - она была ещё в книжке Банды Четырёх от 95-го года, и это много лет как совершенно базовый принцип, где-то рядом с single responsibility.
| |
|
4.81, a3k (?), 20:17, 10/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Это как-то само доходит после опыта поддержки хоть немного большого ООП-кода с изменяющимися требованиями.
| |
|
|
|
|
4.46, JL2001 (ok), 12:49, 10/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Ассемблер быстрее. Учите лучше его.
он не оптимизируется автоматически, непереносим, долог в написании и рефакторинге, порождает множество ошибок в силу ограниченности человеческого разума и больших размеров программ
| |
4.51, Аноним (66), 14:15, 10/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Ассемблер быстрее. Учите лучше его.
Лучше так не шутите, ведь подобные утверждения начинают повсюду копировать. Человек может написать боле быстрый код чем оптимизатор, но далеко не каждый.
| |
|
5.102, Аноним (95), 16:07, 11/11/2019 [^] [^^] [^^^] [ответить] | +/– | Незнающий ассемблер и более того его оптимизации - ни на каком языке, не сможет... большой текст свёрнут, показать | |
|
6.128, Аноним (66), 10:12, 12/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Впрочем, речь то была про ассемблер и забытость его критичной важности.
Напомню: "Ассемблер быстрее". В то время как это лишь мнемоническая запись машинного кода. Надо ли понимать, как работает железо? Для определённых категорий это, безусловно, необходимый навык. Именно понимание даёт возможность написать "быстрее", но никак не ассемблер.
| |
|
7.149, Аноним (144), 20:34, 12/11/2019 [^] [^^] [^^^] [ответить] | +/– | Не только понимание как работает железо, но и - как компиляторы А, ассембрер э... большой текст свёрнут, показать | |
|
8.171, Аноним (66), 11:53, 13/11/2019 [^] [^^] [^^^] [ответить] | +/– | Ассемблер это ассемблер Трансляция мнемоник выполняется 1 в 1 в машинный код К... большой текст свёрнут, показать | |
|
|
10.173, Аноним (66), 14:15, 13/11/2019 [^] [^^] [^^^] [ответить] | +/– | Перечислен был некий загадочный опыт оптимизации , в то время как оптимизирова... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
4.78, Аноним (78), 18:28, 10/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ты эту ссылку из новости в новость тягаешь, не надоело еще? "Мы написали говнокод, хахаха, он работает неочевидным образом". Да подобным примерам на питоне и js целые сайты посвящены.
| |
4.90, Анонии (?), 06:46, 11/11/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
А мужики-то и не знали! Писали себе программы на C++, а оказывается, это невозможно было!
| |
|
|
2.67, Wilem (?), 17:18, 10/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Подобные вопросы лучше задавать гуглу. Если ты это делаешь на опеннете то ты либо тут первый раз, либо наслаждаешься неминуемым срачем (что не плохо, в общем-то - весело). Практической пользы немного, тк мало экспертов, в основном тут просто любители линукса.
| |
|
|
|
3.125, Аноним (122), 02:57, 12/11/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Хмм, а чего тогда не на сишке то написали оптимизированные оптимизации, зачем было тратить время на асм? Раст же виноват
| |
|
4.155, Аноним (144), 21:06, 12/11/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
А, кто же ещё. Ну не помянутый же Си...
Оптимизация - должна быть комплексно...
А, выросшим на Rust - откуда уметь даже просто ассемблерные оптимизации полноценно - пиши не пиши теперь на ассемблере..., и основной то код на Rust - никто не отменял.
Не отмажитесь - тут уже таки: «Раст виноват».
| |
|
|
|
1.13, Аноним (14), 22:49, 09/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +11 +/– |
Основная половина кодировщика написана на ассемблере. Смените название поста ;)
| |
|
2.15, анонн (ok), 22:58, 09/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Основная половина кодировщика написана на ассемблере. Смените название поста ;)
Основная половина mem/strcpy/strstr в glibc написана на асм, смените название либы
| |
|
3.27, Аноним (27), 01:58, 10/11/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
>Основная половина mem/strcpy/strstr в glibc написана на асм
но ведь это ложь
| |
|
4.31, анонн (ok), 02:42, 10/11/2019 [^] [^^] [^^^] [ответить] | +2 +/– | Но ведь это аноним i386 memcpy S https sourceware org git p glibc git a blob ... большой текст свёрнут, показать | |
|
5.37, Аноним (66), 06:07, 10/11/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Но это половина не основная, а расширенная (см. extension). Кроме того, её возможно вообще выкинуть.
| |
|
|
|
2.34, burjui (ok), 03:57, 10/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Только подавляющая часть ассемблера - в директориях x86 и arm, что достаточно прозрачно намекает на то, что на ассемблере написаны специально оптимизированные версии алгоритмов и функций, а не основное мясо кодировщика.
| |
|
3.38, Аноним (66), 06:16, 10/11/2019 [^] [^^] [^^^] [ответить]
| –4 +/– |
Названия каталогов явно говорят о том, что в них содержится оптимизация под конкретные архитектуры. Что именно там оптимизировано и где (и что) мясо -- непонятно как из тех названий следует (а изучение содержимого каталогов и файлов -- это задача как раз делавшего исходное утверждение).
| |
|
|
|
2.25, Аноним (25), 00:58, 10/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Будут аппаратные декодеры и кодировщики во всех новых GPU и SoC.
| |
|
|
|
5.105, Аноним (95), 16:35, 11/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
При наличии уже даже OpenCL - давно нет смысла тратить транзисторы на codecs.
| |
|
6.106, Аноним (95), 16:37, 11/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
(а, если и сделают - реально будет на OpenCL, из маркетинговых соображений это умолчат)
| |
|
7.189, Аноним (189), 00:46, 18/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Бред у вас, я того что по ссылке - и не отрицал...
go to школа учиться читать.
| |
|
|
|
|
|
|
|
2.99, Аноним (27), 15:24, 11/11/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
короче, проверил
при аналогичном качестве видео занимает в ~8 раз меньше места на диске по сравнению с hevc
но есть недостатки:
1) работает слишком медленно, почему-то использует только одно ядро процессора, несмотря на опции
2) принимает на вход только в y4m формате, который занимает слишком много места на винте
| |
|
3.107, Аноним (107), 16:45, 11/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
2) принимает на вход только в y4m формате, который занимает слишком много места на винте
это референсный инкодер (commandline), подразумевается что либу запилят во что-то типа fmpeg (я надеюсь C биндинги будут), поэтому это вообще ни разу не недостаток.
про первое - оч странно, какие опции использовали. Надо бы баг им запилить) должно все использовать.
| |
|
4.113, Аноним (3), 20:00, 11/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Корми в пайпе, типа такого:
ffmpeg -v 0 -i source.mp4 -f yuv4mpegpipe -pix_fmt yuv420p -y /dev/stdout |
| |
|
|
|
1.36, Аноним (-), 06:02, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
>Код проекта распространяется под лицензией BSD.
Вот такое вот БЗДунство растаманов меня сильно огорчает. Ибо ничего лучше GPL v3+ нети никогда не будет.
| |
|
2.41, Аноним (41), 09:24, 10/11/2019 [^] [^^] [^^^] [ответить]
| –6 +/– |
Ну так форкни и перелицензируй под GPL, вы же так постоянно делаете.
| |
|
3.48, Аноним (48), 13:34, 10/11/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Один форкнет, измажет в гпл, а потом прибежит толпа боевых гплерастов и будет указывать на нарушения копилефт и копирайт
| |
|
4.58, Аноним (-), 15:56, 10/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
>Один форкнет, измажет в гпл, а потом прибежит толпа боевых гплерастов и будет указывать на нарушения копилефт и копирайт
Не прибежит. Проприетарщики выбирают БЗДу. А с БЗДы на ГПЛ в можно. С БЗДы в любое направление можно.
| |
|
5.93, КО (?), 10:19, 11/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
>А с БЗДы на ГПЛ в можно
Не совсем, в BSD есть одно требование, на которое в GPL кладут болт.
| |
|
6.112, Аноним (95), 19:45, 11/11/2019 [^] [^^] [^^^] [ответить] | +/– | Это должно быть аж не требовать раскрытия исходников Или вы про 3-й claus... большой текст свёрнут, показать | |
|
7.130, Аноним (-), 10:36, 12/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
У противника Свободы бомбануло. Ничо FSF будет давить проприетарщиков и колаборантов-БЗДунов революционными методами.
| |
|
8.162, Аноним (162), 23:41, 12/11/2019 [^] [^^] [^^^] [ответить] | +/– | Значит вы противник прогресса А, напомните то как в устах таких говнюков ... большой текст свёрнут, показать | |
|
|
|
|
|
3.57, Аноним (-), 15:50, 10/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
>Ну так форкни и перелицензируй под GPL, вы же так постоянно делаете.
Расскажи это пацыкам, которые переписали утилиту ls. Вместе посмеёмся.
| |
|
2.60, Аноним (41), 16:02, 10/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> GPL v3+
Я правильно понимаю, что ты, придя, скажем, в банк, подписываешь абсолютно чистые листы А4, а уже потом банк печатает на эти листы абсолютно любые условия? Потому что "+" в GPLv3+ именно то и означает, что ты передал столлману пачку листов А4 со своей подписью внизу. Ну а он в них может вписать любой свой маразматический бред.
| |
|
3.69, Аноним (19), 17:24, 10/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Не столлману, а форкеру. Форкер может апгрейднуть версию. А может и не апгреднуть
| |
|
|
1.50, Простой парень (?), 14:00, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Проблема не в том, какой язык лучше, а в том, какое место он может занять. Вот смотрите: приложение пишется на питоне, интерпретатор питона на си, а среда выполнения си на ассемблере. Чёткая иерархия, каждому языку есть место, согласно тому, какие задачи на нём проще решать. Проблема в том, что это складывается стихийно, а не предсказуемым образом. Разработчики языка исходят из того, что они могут сделать, какие у них есть идеи, а не из того, какие задачи стоят перед современным языком. Вот раст пока не нашёл свою нишу, но то что развитие с++ зашло в тупик, подталкивает разработчиков испытывать новые языки у себя в проектах, и только поэтому раст держится.
| |
|
2.54, Аноним (41), 14:28, 10/11/2019 [^] [^^] [^^^] [ответить] | +2 +/– | Аналогия, где языки представляются различными инструментами молоток чтоб забива... большой текст свёрнут, показать | |
|
3.82, Простой парень (?), 20:40, 10/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
>>развитие с++ зашло в тупик
> и в чём это проявляется?
map, unordered_map - этого мало? А то что конструктора для std::string из форматированной строки до сих пор нет, это что? Эти все конференции где тучи высоколобых с упорством достойным лучшего применения спорят о какой то никому кроме них не нужной сpaни, мало?
| |
3.163, Lex (??), 23:53, 12/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
С каждыми "новыми плюшками", синтаксис плюсОв становится всё монструозней и уродливей.
Хотя, и с джавой примерно аналогично.
| |
|
2.89, nelson (??), 23:39, 10/11/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
> приложение пишется на питоне, интерпретатор питона на си, а среда выполнения си на ассемблере
Среда выполнения си на ассемблере, говорите? Правду говорят, что обучение программированию питоном до добра не доводит )
| |
|
1.83, Аноним (83), 21:06, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
А как там у Rust с экспортом? Можно библиотеку с ABI использовать в сишной программе просто линконув их?
| |
|
2.86, Ordu (ok), 23:01, 10/11/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
#[no_mangle]
fn print_int(i: i32) {
println!("{}", i);
}
Такое вполне можно вызывать из C. Но если ты заботишься о кроссплатформенности кода, то вместо i32 тебе лучше использовать std::os::raw::c_int.
| |
|
1.87, Аноним (87), 23:03, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ] | +2 +/– | Абсолютно безграмотная фраза, спутаны сущности формата и кодировщика Формат пре... большой текст свёрнут, показать | |
1.114, Аноним (95), 20:01, 11/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Всё же хотелось бы и тестов, ладно фиг с ними с тормозами Rust, но что - на счёт самого сжатия?...
И патентов...
| |
1.116, Аноним (87), 20:58, 11/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Что-то ебилдов не видно — ни в портеже, ни в оверлеях, ни на багтрекере нет. Деплой зоопарка растолиб оказался гентушникам не под силу?
| |
|
|
3.129, Аноним (-), 10:31, 12/11/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Какой такой зоопарк? В расте статическую линковку делают обычно,.
Поэтому helloworl! на Расте весит 5 Мегабайт?
| |
|
4.134, анонн (ok), 13:03, 12/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Поэтому 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
Попробуйте собирать не из под Виндовс.
| |
|
5.140, Anonymoustus (ok), 16:19, 12/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
>> Поэтому 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 байт статически слинкованного сабжа.
| |
|
6.145, анонн (ok), 19:43, 12/11/2019 [^] [^^] [^^^] [ответить] | +/– | Учитывая, что libc вообще-то рантайм библиотека для этой самой сишечки, а не рас... большой текст свёрнут, показать | |
|
|
|
9.164, Ordu (ok), 23:56, 12/11/2019 [^] [^^] [^^^] [ответить] | +/– | gt оверквотинг удален Тут как минимум пять байт лишние Второй вызов int 21h н... текст свёрнут, показать | |
|
|
|
|
|
|
3.133, Аноним (87), 11:56, 12/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Дикий зоопарк совершенно, который при запуске сборки начинает качаться с репозиториев на жидхабе неконтролируемым образом. Для сборки сабжа нужно скачать 138 (!) пакетов с библиотеками, все из которых для включения в Gentoo нужно оформить в виде ебилдов. Это уже привязка к облаку какая-то пошла, в оффлайне build-система раста растеряется и ничего не сможет сделать.
Статическая линковка помогает только в случае распространения бинария от разработчика к пользователю. В большинстве дистрибутивов unix-подобных ОС принята другая модель, в которой от разработчика берутся только исходники и далее подготавливаются мэйнтейнерами для автономной сборки на build-фермах. Сабж довольно сложно деплоить таким образом.
| |
|
4.137, Аноним (-), 15:37, 12/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Слыхал поговорку: "Linux писан сишными прогоаммистами, и для сишных программистов Linux".
UNIX - BSD - Linux - это множество кусков сишного кода. При всём уважении к языку Rust, но всё же этот язык является чужеродным элементом в Unix-подобных системах.
| |
|
5.154, Аноним (87), 21:05, 12/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Проблема не в языке, а в том, что используемая сабжем build-система, cargo, включает в себя средство установки компонентов из удалённого репозитория, что в UNIX-подобных ОС является прерогативой исключительно пакетного менеджера. В экосистеме UNIX отлично живут программы на любых языках, где build-системе достаточно скормить каталог с исходниками и она его автономно и предсказуемо соберёт, но ситуация, когда эта build-система при сборке внезапно (в man cargo-build нигде не сказано о возможной сетевой активности, а также нет опции для её отключения) начинает самостоятельно ломиться во внешний мир и что-то непонятное из него тащить, абсолютно недопустима.
| |
|
6.182, пох. (?), 07:29, 15/11/2019 [^] [^^] [^^^] [ответить] | +/– | как будто в неюниксоподобных это не так разумеется, там тоже можно нагадить в ... большой текст свёрнут, показать | |
|
7.183, Аноним (87), 18:54, 15/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> как будто в неюниксоподобных это не так
Там обычно нет пакетного менеджера с исключительной прерогативой установки компонентов из внешнего мира. Вместо этого программы поставляются в виде отдельного инсталлятора, который всё чаще самой программы не содержит, а лезет за ней в веб. Вероятно, по образу и подобию этих инсталляторов и сделан вышеупомянутый cargo.
> Вермишель из pkg-config, модных систем сборок на нескучных язычках с зависимостями всего от всего, и каких нибудь авторских соплей сверху фэйлится на любом чуть отличающемся от совсем дубового раскладе.
Как же тогда софт собирается в nixos и guixsd, где /usr и /lib вообще отсутствуют?
> афтыри раньше программировали на nodejs
Похоже на то: js-макакам вообще никакие правила не писаны.
| |
|
|
|
|
|
|
1.161, Аноним (161), 23:02, 12/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну, hevc не такой уж медленный. У меня на Pentium 4 он кодит 576p с пресетом fast аж целый 1 fps. Мне не проблема подождать пару часов, чтобы закодить 6-минутный ролик. Другое дело, что декод 576p 1500k в realtime уже не тянет. Результат не посмотреть, только для других делать. Меньшие разрешения идут.
| |
|