LINUX.ORG.RU

Стали доступны видео докладов с C++ CoreHard Spring 2019

 


13

3

На YouTube на канале corehard стали доступны видеозаписи следующих докладов с прошедшей весной конференции C++ CoreHard 2019:

★★★★★

Ответ на: комментарий от anonymous

Раст и стабильный ABI - помнишь, сколько танцевали по этому поводу? Сломают ещё раз, если это будет им мешать.

UB - это когда непонятно что ты получишь. Т.е. нет гарантии, что произойдёт именно Wrapping. А теперь посмотри на главную страницу Rust и притащи оттуда, про какую Safety заявляет команда.

Плюсовик успешно смотрит за лайфтаймом если он проект делает в одиночку и небольшой. И то - не факт. Иначе бы у ребят из PVS и подобных контор бизнеса бы не было.

Легаси никуда не исчезнет само. И его нужно поддерживать и аккуратно переписывать. Грамотные плюсовики могут писать и на Rust. Как и наоборот. Чистых Rust разработчиков найти сложно, то, что касается библиотек, касается и людей. Слишком мало времени прошло. Как бы Rust - это меньший шаг относительно C++, чем C++ в свое время относительно C. Да еще и слегка вбок, не пытаясь сказать: мы можем тащить всё легаси на предшественнике.

Они не пытаются сделать Франкенштейна.

Deleted
()
Ответ на: комментарий от seiken

Уровень C++ CoreHard очень сильно поднялся за последние 4 года. Вплоть до приезда на CoreHard докладчиков вроде Джосаттиса.

А какой именно доклад из вышеперечисленных вы причисляете к «самопиару»?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Если у вас есть возможность спрыгнуть с C++ на Rust, то спрыгните, кто вам мешает?

Только вот если вы спрыгнули, какое вам дело до проблем тех, кто по тем или иным причинам в C++ остается?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

А какой именно доклад из вышеперечисленных вы причисляете к «самопиару»?

Это я безотносительно конкретной конференции. Просто, если конференция зрелая, то процент понтовых докладов и рекламы должен быть минимален.

seiken ★★★★★
()

Никто не в курсе, почему с сайта cppconf.ru пропали презентации докладов прошлогодних конференций?

grem ★★★★★
()
Ответ на: комментарий от eao197

Не, проблема в холиварной постановке вопроса про Rust в докладе, а не в Rust или C++. Автор фактически призывает бойкотировать Rust для новых проектов.

Как бы, какое Антону дело до тех, кто думает о том, спрыгнуть или нет? Но пропаганду, что не надо спрыгивать, гонит.

Deleted
()
Ответ на: комментарий от Deleted

Как бы, какое Антону дело до тех, кто думает о том, спрыгнуть или нет? Но пропаганду, что не надо спрыгивать, гонит.

Вообще-то сам тезис о том, что на Rust нужно спрыгивать, так же нуждается в подтверждении.

Например, для меня и еще для множества разработчиков, Rust вовсе не выглядит достаточно хорошо, чтобы перейти на его использование.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

1) фронт раста на текущий момент генерит избыточный IR по сравнению с фронтом C++, это не очень хорошо, и будет сказываться в проиграше производительности С++

Ну и чтобы понимать - цифры в студию, какова величина эффекта этого «проигрыша производительности»? И IR не является конечным представлением. По нему, конечно, можно делать наколенные сферические бенчмарки в ваккуме, но как это будет относиться к производительности программы в реальной жизни?

shty ★★★★★
()
Ответ на: комментарий от eao197

Например, для меня и еще для множества разработчиков, Rust вовсе не выглядит достаточно хорошо, чтобы перейти на его использование.

И, возможно, и никогда не будет достаточно хорош. Но вопрос не об этом. Мне вот интересно, насколько обоснованные выводы о производительности языка можно делать по IR? (без, по-крайнeй мере, серьёзного обоснования таковых) Это ж, утрируя, как рассуждать о том, что быстрее будет "->" или "(*).".

// доклад не смотрел

shty ★★★★★
()
Последнее исправление: shty (всего исправлений: 1)
Ответ на: комментарий от shty

Мне вот интересно, насколько обоснованные выводы о производительности языка можно делать по IR?

Там речь идет об уже ассемблерном выхлопе. Т.е. после того, как и front-, и middle- и back-end-ы компилятора уже выжали из кода все, что могли.

доклад не смотрел

Так может посмотреть, чтобы не судить о том, что dave напел?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Так может посмотреть, чтобы не судить о том, что dave напел

Глянул быстро. Да, для сравнения используется ассемблерный выхлоп (кстати, было бы неплохо показать с какими ключами компилятора он был получен).

Есть пара замечаний:

1) Вот докладчик долго-долго рассказывал о том как это плохо, код разный приводил, глаза закатывал, говорил «не здорово». А чего ж он код то не запустил, и не привел реальный оверхед исполнения?

2) Доклад переполнен манипуляциями и неточностями - а) выдумываются несуществующие фичи Rust'а (типа защиты от переполнения), которые успешно развеиваются и б) невнятные оценки - типа ну вот видите, это ж вот плохо.

Общее ощущение - докладчик натягивает сову на глобус. Rust он не знает и не понимает, и пытается отсутствие реальных аргументов заместить оценочными суждениями (типа «это не очень»).

shty ★★★★★
()
Последнее исправление: shty (всего исправлений: 1)
Ответ на: комментарий от shty

(кстати, было бы неплохо показать с какими ключами компилятора он был получен).

Ключи там видны на скриншотах.

  1. Вот докладчик долго-долго рассказывал о том как это плохо, код разный приводил, глаза закатывал, говорил «не здорово». А чего ж он код то не запустил, и не привел реальный оверхед исполнения?

Потому, что в каждой конкретной ситуации это будет разный оверхед? Ведь, допустим, для некой функции было добавлено три ассемблерные инструкции в эпилог. Если эта функция в программе вызывается всего один раз, то будет один результат. Если она вызывается непрерывно в цикле 100500 раз, то результат может быть другой.

Здорово ли, что есть лишние обращения? Нет, как по мне.

Каков будет реальный оверхед? Пусть каждый для себя сам решит, в своей конкретной ситуации. В конце-концов кто-нибудь скомпилирует Rust-овский код с -C debuginfo=0 и у него не будет оверхеда.

а) выдумываются несуществующие фичи Rust’а (типа защиты от переполнения), которые успешно развеиваются

Типа защита от переполнения в debug есть, а в release нет. Или он здесь что-то соврал? Нет такой фичи в Rust-е?

Общее ощущение - докладчик натягивает сову на глобус.

Общее ощущение, у растоманов подгорело от того, что в очередной раз опытный C++ник не рассыпался в комплиментах вашему любимому языку. Поэтому давайте будем спорить не с приведенными в докладе фактами, а с тем, чего докладчик не говорил. Или припомним, что он вздумал улыбаться во время доклада, когда говорил о Rust-е. Вот ведь, редиска!

eao197 ★★★★★
() автор топика

Доклад Ивана Чукича про средства построения DSL, как по мне, так весьма годный.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Здорово ли, что есть лишние обращения? Нет, как по мне.

Нет, это все так. Но для зявленного пафоса доклада как-то маловато будет.

Каков будет реальный оверхед?

Вот хотелось бы чтобы об этом рассказал докладчик.

а) выдумываются несуществующие фичи Rust’а (типа защиты от переполнения), которые успешно развеиваются

Типа защита от переполнения в debug есть, а в release нет. Или он здесь что-то соврал? Нет такой фичи в Rust-е?

Давайте разберемся. 1) Заявлялось ли наличие проверок overflow выражений вида x + y в release? 2) Есть ли способ написать код, который будет всегда делать такую проверку?

shty ★★★★★
()
Ответ на: комментарий от eao197

Общее ощущение - докладчик натягивает сову на глобус.

Общее ощущение, у растоманов подгорело от того, что в очередной раз опытный C++ник не рассыпался в комплиментах вашему любимому языку.

Итак я теперь «растоман», выходит? И с чего такой вывод был сделан?

Или припомним, что он вздумал улыбаться во время доклада, когда говорил о Rust-е.

Да пусть улыбается. Но если взялся раскрывать тему - раскрывай, а не «тут играй, тут не играй, а тут рыбу заворачивали».

shty ★★★★★
()
Ответ на: комментарий от shty

Но для зявленного пафоса доклада как-то маловато будет.

Вот про пафос мне ничего не ведомо. Я ни в заявке к докладу, ни в самом докладе никакого пафоса не видел.

Давайте разберемся.

Давайте. Только не с вашими непонятно откуда взявшимися вопросами, а с тем, что может дать Rust в плане безопасности.

Проверка на integer overflow в Rust-е есть?

В debug режиме есть. Что дает некоторым основание считать, что Rust в этом плане безопаснее C++.

В release режиме нет. Т.е. когда программа ушла в продакшен, то в плане целочисленных переполнений Rust не безопаснее C++.

И это наглядный пример того, как местами (подчеркну, местами) безопасность в Rust-е декларируется, но по факту её в результирующей программе не будет.

Да пусть улыбается.

Так выше по треду это человеку в вину вменили.

Но если взялся раскрывать тему - раскрывай

Возникает вопрос: а какую именно тему? Может у автора доклада была своя тема и он ее раскрыл. А вы выдумали себе другую тему и сочли, что автор ее не раскрыл (см. выше про выдуманный пафос).

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Проверка на integer overflow в Rust-е есть? В debug режиме есть. В release режиме нет.

Точно нет? А если написать, например:

(i64::max_value()).checked_add(1)
что будет результатом выполнения?

shty ★★★★★
()
Последнее исправление: shty (всего исправлений: 1)
Ответ на: комментарий от shty

Так ведь речь идет не о специальной арифметике с проверкой на переполнение (которую, кстати, и в C++ можно изобразить, даже без необходимости вызова костыльных checked_add).

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Так выше по треду это человеку в вину вменили.

Предлагаю не обсуждать излишне экзальтированные аргументы.

Но если взялся раскрывать тему - раскрывай

Возникает вопрос: а какую именно тему?

Резонный вопрос, открываем видео и смотрим что написано на слайдах: «Сравним с другимим языками: C++ vs. Rust»

shty ★★★★★
()
Ответ на: комментарий от eao197

Так ведь речь идет не о специальной арифметике с проверкой на переполнение (которую, кстати, и в C++ можно изобразить, даже без необходимости вызова костыльных checked_add).

Так а она заявлялась в таком виде, чтобы кричать о ёё отсутствии?

shty ★★★★★
()
Ответ на: комментарий от shty

«Сравним с другимим языками: C++ vs. Rust»

Ну так сравнение и было. В том числе были перечислены и достоинства Rust-а.

А обещания сделать более-менее объемное сравнение результатов бенчмарков не было.

Тем более, что этот раздел был всего лишь частью более объемлющего доклада.

Так а она заявлялась в таком виде, чтобы кричать о ёё отсутствии?

Были же показаны фрагменты кода, на примере которых и говорилось о проверках переполнения (и их отсутствия в релизе).

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Ну так сравнение и было. В том числе были перечислены и достоинства Rust-а. А обещания сделать более-менее объемное сравнение результатов бенчмарков не было.

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

Были же показаны фрагменты кода, на примере которых и говорилось о проверках переполнения (и их отсутствия в релизе).

Были показаны фрагменты кода, которые работали согласно документации. При этом почему-то сей факт был представлен как недостаток.

И вообще, ну да Rust - это не волшебная кнопка с надписью «сделать хорошо», которая работает. А C++ - это такая кнопка, что-ли?

shty ★★★★★
()
Ответ на: комментарий от shty

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

Ну, собственно, было очевидно, что речь идет об обманутых ожиданиях. Что, в принципе, понятно.

Меня, правда, интересует вопрос о том, откуда взялись такие ожидания. Ну да ладно.

Я, например, если бы делал сравнение C++ и Rust-а, то упомянул бы о таких вещах, как отсутствие привычного ООП в Rust-е, наличие в Rust-е встроенных проверок границ при работе с массивами (соответственно с плюсами и минусами), наличие в Rust-е макросистемы, которая может компенсировать отсутствие в нем некоторых возможностей C++ных шаблонов. Хотя не факт, что все это удалось бы уместить в доклад.

Но это мой выбор, у Полухина свой выбор. И какой бы выбор не был сделан, всегда будет кто-то с обманутыми ожиданиями.

А C++ - это такая кнопка, что-ли?

Нет. Просто сам факт того, что Rust так же не является такой кнопкой, то смена C++ на тот же Rust может быть лишь сменой шила на мыло.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

В release режиме нет. Т.е. когда программа ушла в продакшен, то в плане целочисленных переполнений Rust не безопаснее C++.

Можно включить в Cargo.toml: [profile.release] overflow-checks = true

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Спасибо за дополнение.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Ну, собственно, было очевидно, что речь идет об обманутых ожиданиях.

Нет, не совсем об этом. Речь идет о низком качестве доклада.

Просто сам факт того, что Rust так же не является такой кнопкой, то смена C++ на тот же Rust может быть лишь сменой шила на мыло.

И немедленно застрелились сразу 3 капитана очевидность.

shty ★★★★★
()
Ответ на: комментарий от shty

Нет, не совсем об этом. Речь идет о низком качестве доклада.

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

anonymous
()
Ответ на: комментарий от shty

Речь идет о низком качестве доклада.

Не знаю, мне так не показалось. Но для меня в докладе не было открытий.

И немедленно застрелились сразу 3 капитана очевидность.

Вы недооцениваете падкость войтишников на новые серебряные пули.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

В release режиме нет. Т.е. когда программа ушла в продакшен, то в плане целочисленных переполнений Rust не безопаснее C++.

В отличие от С++, в котором переполнение знакового целого - UB, переполнение для знаковых целых в Rust определено как 2's complement и в safe Rust может вызвать только логическую ошибку.

red75prim ★★★
()
Ответ на: комментарий от eao197

Да, спасибо что приносишь подобные доклады на ЛОР. Посмотрел парочку.

EXL ★★★★★
()
Ответ на: комментарий от eao197

смена C++ на тот же Rust может быть лишь сменой шила на мыло.

Ну, по крайней мере, сесть на мыло безопаснее. Шёпотом: 70 percent of all security bugs are memory safety issues

red75prim ★★★
()
Ответ на: комментарий от red75prim

Шёпотом: 70 percent of all security bugs are memory safety issues in C code used by Rust

Исправил

anonymous
()
Ответ на: комментарий от anonymous

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

Но всё же от профессионала ожидаешь больше, нежели от любителя.

shty ★★★★★
()
Ответ на: комментарий от eao197

Вы недооцениваете падкость войтишников на новые серебряные пули.

Но такой доклад разумных людей не убедит (они и так это знают), а неразумных вообще никакой не убедит. Смысл такого доклада, получается, немного теряется.

shty ★★★★★
()
Ответ на: комментарий от rupert

Я пока посмотрел полностью только четыре доклада. Мне понравился доклад Ивана Чукича.

Если интересно, как организовать message-passing между прибитыми гвоздями к конкретным ядрам нитям, то можно посмотреть доклад Максима Хижинского. Но, если его доклады с предыдущих конференций CoreHard смотрели, то здесь нового особо ничего не будет.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от red75prim

В отличие от С++, в котором переполнение знакового целого - UB, переполнение для знаковых целых в Rust определено как 2's complement

В С++20 переполнение знакового целого определено как 2's complement, всё закапываем раст?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1236r1.html

fsb4000 ★★★★★
()
Ответ на: комментарий от shty

Но такой доклад разумных людей не убедит (они и так это знают)

Вот прям так сразу и знают? Подключены к телепатическому каналу абсолютной истины?

Знания они получают из видео и статей. Вы много видели докладов о Rust с чем-то кроме бездоказательных и, как видно из видео, неверных утверждений?

anonymous
()
Ответ на: комментарий от red75prim

Рад за них. А потом результат 2's complement попадает в vector::operator[].

vector::operator[] принимает параметр size_t, прям как в расте usize, видишь опять похожи один в один.

https://en.cppreference.com/w/cpp/container/vector/operator_at

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от eao197

Да он слился просто и хотел убежать с треда :)

bonta ★★★★★
()
Ответ на: комментарий от Deleted

И как бы нить всего доклада: давайте не писать на Rust, давайте не делать инфраструктуру для Rust

Не увидел такой мысли, но было бы здорово если бы к такой мысли приходили чаще.

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

bonta ★★★★★
()
Ответ на: комментарий от eao197

Проверка на integer overflow в Rust-е есть?

В debug режиме есть. Что дает некоторым основание считать, что Rust в этом плане безопаснее C++.

В release режиме нет. Т.е. когда программа ушла в продакшен, то в плане целочисленных переполнений Rust не безопаснее C++.

Мне кажется это не имеет отношение к языку, а к его среде. Например msvc по моему опыту вообще самый строгий компиллер и не уверен что он прям инт+инт оверфлов отлавливает, но на потенциальные проблемы реагирует порой даже избыточно.

bonta ★★★★★
()
Ответ на: комментарий от bonta

не хочется чтобы однажды появился какой-то проект, в котором придется разбираться, а он хоба и на этой нечитаемой гадости.

Такие проекты на Расте и не появятся, ведь всем известно, что Раст является сертифицированным языком для написания хелловорлдов, не более.

anonymous
()
Ответ на: комментарий от eao197

Если интересно, как организовать message-passing между прибитыми гвоздями к конкретным ядрам нитям

Как чувак не осили асио и придумал флейма на доклад, заметим - теоретического флейма. Рабочей модели как он сказал нет.

anonymous
()
Ответ на: комментарий от anonymous

Как чувак не осили асио и придумал флейма на доклад, заметим - теоретического флейма. Рабочей модели как он сказал нет.

Он рассказывал в 2017-ом году про детали реализации DLP-системы, в которой использовалась именно эта модель обмена сообщениями: https://www.youtube.com/watch?v=e1AD27EtYTU

А сейчас он просто сделал доклад только на эту узкоспециализированную тему.

eao197 ★★★★★
() автор топика

Rust. Поджигая пердаки since 2010.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.