Здравствуйте, lpd, Вы писали:
lpd>Но в эмбеддеде нужна близость к оборудованию (и иногда real-time), а не move-семантика и шаблоны, не говоря уж об исключениях.
В embedded (и kernel) надо писать простой и чистый код, без goto и bolierplates. И вот там С++ удобен как никогда, даже 11й.
lpd> Так что массовая популярность последних стандартов С++ в эмбдеддед это скорее всего миф(впервые слышу от тебя).
Это не миф.
Здравствуйте, bc_kaya, Вы писали:
_>Поделитесь впечатлением и опытом программирования с использованием языка С++? _>Холивары просьба не разводить, иначе уйдём не в ту степь обсуждения
язык как язык, требует знаний и определенной дисциплины, но с нормальными процессами в команде и современным тулингом (билд, ревью, CI) проблем не сильно больше чем с управляемыми языками, с последними пожалуй даже больше проблем, т.к. там больше свободы и индивидуальная производительость у каждого разработчика выше, а ревью менее строгое, скажем, у нас в команде в С++ коде не пернуть лишний раз, ревьюеры голыми руками задушат, а в java коде полный бардак (может и без UB, но зато с эпичными логическими ошибками, в духе "пожалуй буду писатдь этот алгоритм так, словно в кампьютыре бесконечное количетво памяти!"), причем высокоуровневый с++ (без темплейтов, низкоуровневой многопоточки и арифметики указателей) не сильно сложнее того же питона или golang, еще из плюсов — стандартая библиотека — ТОП, лучшая алгоритмическая библиотека, на мой взгляд, можно очень многие вычисления представить стандартыми алгоритмами, еще корутины в 20х плюсах — тоже ТОП, golang не нужен больше, т.к. на плюсах тоже самое (с адекватной библиотекой) получается сильно проще и более поддерживаемо, т.к. у тебя есть отдельные примитивы для работы с concurrency и с параллелизмом
ну и без с++ не вьехать в кучу интересных проектов, которые на нем пишут, это всякая инфраструктура, базы данных, распределенные очереди и тд
благодаря новому железу, у языка новая жизнь, потому что DPDK, и DMA в память, вместо обычных системных вызовов для чтения и записи, у современного нвме диска десятки тысяч очередей для вполнения запросов и ты тупо не можешь остановиться для сборки мусора, потому что там все занимает микросекунды теперь, вместо десятков милисекунд (раньше gc был одного порядка с seek-ом дисковым, теперь нет больше этих ваших seek-ов), чтобы адекватно работать с современным I/O нужно писать так, как пишут разработчики scylladb, например, а не на java
Здравствуйте, chaotic-kotik, Вы писали:
CK>у нас в команде в С++ коде не пернуть лишний раз, ревьюеры голыми руками задушат, а в java коде полный бардак
И виноват, конечно, язык. Только вот почему то у нас в конторе ситуация прямо противоположная. В плюсовом коде бардак и наслоения многолетнего говтехдолга, в от код на шарпе по большей части чистенький.
CK>ну и без с++ не вьехать в кучу интересных проектов, которые на нем пишут, это всякая инфраструктура, базы данных, распределенные очереди и тд
Всякие кролики, кафки, minio, кассандры, тысячи их смотрят на тебя как на представителя из параллельной реальности.
CK>благодаря новому железу, у языка новая жизнь, потому что DPDK, и DMA в память, вместо обычных системных вызовов для чтения и записи, у современного нвме диска десятки тысяч очередей для вполнения запросов и ты тупо не можешь остановиться для сборки мусора, потому что там все занимает микросекунды теперь, вместо десятков милисекунд
Но тот же писанный на С++ драйвер CIFS почему то тормозит как обкуренная улитка.
Здравствуйте, Ip Man, Вы писали:
IM>Но — с другой стороны, спрос на С++ есть в узких нишах (напр. в финансах), и, по-моему, спрос на хороших специалистов значительно превышает предложение.
На C++ писать в финансах это самоубийство, пишут на Java, реже на .NET. Особые извращенцы в HFT что-то делают на C++, но таких мало и HFT это доли процента от финансов. В алгоритмической торговле пока вы напишите на C++ один алгоритм, на Java напишут 10, они будут на 10% медленнее, но успеют заработать. А супер быстрый C++ пока до рынка доедет, рынок поменяется.
Здравствуйте, bc_kaya, Вы писали:
_>Хотел бы поинтересоваться у знающих людей, за что весь мир недолюбливает плюсы. Конкретно у меня данный язык вызывает симпатию (возможно потому, что это мой самый первый более менее освоенный язык программирования); _>Поделитесь впечатлением и опытом программирования с использованием языка С++? _>Холивары просьба не разводить, иначе уйдём не в ту степь обсуждения
C++ это архаичный язык, в этом его основная проблема. После лиспа в нем не хватает простоты синтаксиса, а метапрограммирование на шаблонах иначе как извращением называть не хочется. После Objective-C задаешься вопросом — если хотели "C с классами", то почему не сделали так? Попробовав ARC из Objective-C хочется задать много вопросов по поводу всей этой возни вокруг умных указателей. После Java или C# хочется нормальной экосистемы, с пакетами, с рефлексией, с нормальным ABI, с удаленной отладкой, хорошей IDE, с мониторингом и так далее. Я знаю, что все это в C++ есть, но в той же Java оно на порядок лучше и проще работает. Из C++ хочется взять только производительность и детерминированную работу с памятью. Но все это есть в Rust. Итого выбирают все что угодно кроме C++ потому что у него просто нет комбинации хороших фич, они все идут с слишком большим багажом проблем.
В 2021 году чтобы начинать что-то на C++ надо прямо быть даже не фанатом, а фанатиком языка. Есть Rust в конце-концов и, похоже, лет за 20-30 он C++ убьёт.
PS: Java тоже старый язык, но не архаичный, это к вопросу о силах, которые за развитием языка стоят.
CK>>ну и без с++ не вьехать в кучу интересных проектов, которые на нем пишут, это всякая инфраструктура, базы данных, распределенные очереди и тд НС>Всякие кролики, кафки, minio, кассандры, тысячи их смотрят на тебя как на представителя из параллельной реальности.
Но никто кактус не жрет. И, в любом случае, проект Кассандры это не отменяет.
CK>кафку переписали на плюсы и тоже получилось сильно лучше — https://vectorized.io/blog/fast-and-safe/
Но никто кактус не жрет. И, в любом случае, проект Кафки это не отменяет.
CK>кролику уже пора на пенсию давно, это первая итерация подобных систем, которую превратил в легаси сначала Storm, а потом Kafka, Pulsar и со
Кафка с Пульсаром и Кролик это довольно разные вещи, не полностью взаимозаменяемые. Первые это data streaming, а кролик это таки message broker. Но я понял — если факт не подходит под теорию, тем хуже для факта.
НС>>Но тот же писанный на С++ драйвер CIFS почему то тормозит как обкуренная улитка. CK>если какой-то софт на плюсах тормозит, то значит весь софт на плюсах тормозит, я тебя правильно понял?
Нет. Ты придумал чебе удобное для избиения чучелко. Напомню, что это ты заявил, что: "без с++ не вьехать в кучу интересных проектов, которые на нем пишут, это всякая инфраструктура, базы данных, распределенные очереди". А оказывается куча таких проектов таки обходится без плюсов.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>hi perf S3 совместимый сторадж на го.
у S3 стораджа низкие требования к latency, его можно хоть на руби написать, у оригинального S3 latency порядка десятков миллисекунд
CK>>кассандру переписали на плюсы и получилось сильно лучше — https://www.scylladb.com/2017/02/15/scylladb-vs-cassandra-performance-benchmark-samsung/ НС>Но никто кактус не жрет. И, в любом случае, проект Кассандры это не отменяет. CK>>кафку переписали на плюсы и тоже получилось сильно лучше — https://vectorized.io/blog/fast-and-safe/ НС>Но никто кактус не жрет. И, в любом случае, проект Кафки это не отменяет.
я не утверждал что отменяет, это просто примеры того, как интересный инфраструктурный поект был переписан на плюсы с большим эффектом
и кстати про кактус ты зря https://www.scylladb.com/users/ (у вторых нет такого раздела на сайте)
вообще, изначально поинт был в том, что на плюсах есть интересные инфраструктурные проекты, которые написаны под современное железо (DMA с сетью и диском) и низкий latency, и их пишут в основном на плюсах, я не утверждал что на других языках ничего не пишут
НС>Нет. Ты придумал чебе удобное для избиения чучелко. Напомню, что это ты заявил, что: "без с++ не вьехать в кучу интересных проектов, которые на нем пишут, это всякая инфраструктура, базы данных, распределенные очереди". А оказывается куча таких проектов таки обходится без плюсов.
гхм, как можно понять фразу "без с++ не вьехать в кучу интересных проектов, которые на нем пишут, это всякая инфраструктура, базы данных, распределенные очереди" как "без с++ не вьехать в кучу интересных проектов, которые ТОЛЬКО на нем пишут, это ВСЯ инфраструктура, базы данных, распределенные очереди"? ты понимаешь русский язык вообще? я могу по английски написать, если хочешь
Здравствуйте, chaotic-kotik, Вы писали:
CK>благодаря новому железу, у языка новая жизнь, потому что DPDK, и DMA в память, вместо обычных системных вызовов для чтения и записи, у современного нвме диска десятки тысяч очередей для вполнения запросов и ты тупо не можешь остановиться для сборки мусора, потому что там все занимает микросекунды теперь, вместо десятков милисекунд (раньше gc был одного порядка с seek-ом дисковым, теперь нет больше этих ваших seek-ов), чтобы адекватно работать с современным I/O нужно писать так, как пишут разработчики scylladb, например, а не на java
Современный C# позволяет писать код-не аллоцирующий память и явно запрещающий шевеление GC.
И тогда что-плюса не нужны для low latency, да?
И это-покажите мне channel latency arbitrage гомогенных датафидов на плюсах с временем обработки тика в несколько сотен нс.
На unsafe C# я его написал за 8 месяцев до production ready состояния(уже эксплуатируется в бою).
На плюсах бы помер от старости скорее всего
Но апологеты плюсов будут рассказывать, как на нем хорошо писать low latency приложения.
Ну ок, пусть дальше пишут годами то, что на других платформах делается за месяцы
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, Ночной Смотрящий, Вы писали:
CK>>>ну и без с++ не вьехать в кучу интересных проектов, которые на нем пишут, это всякая инфраструктура, базы данных, распределенные очереди и тд НС>>Всякие кролики, кафки, minio, кассандры, тысячи их смотрят на тебя как на представителя из параллельной реальности.
CK>не знаю про minio ничего CK>кассандру переписали на плюсы и получилось сильно лучше — https://www.scylladb.com/2017/02/15/scylladb-vs-cassandra-performance-benchmark-samsung/ CK>кафку переписали на плюсы и тоже получилось сильно лучше — https://vectorized.io/blog/fast-and-safe/
Это результаты проектирования сразу на performance, не более(пулинг памяти, кешфрендли раскладка данных, отсутствие динамической аллокации ака предварительный подъем "мира" разом, инлайнинг кода в HotPath, уменьшение меморитраффика в алгоритмах, использование векторизации где только она втыкается и дает результат и прочая).
Причем проектирование на performance нужно только в основных HotPath и все.
Я в лоб сравнивал решения на плюсах и на шарпе для одинаковых задач HFT, плюса в лучшем случае были быстрее на 30% в части задач, и то, после завоза возможностей ручной векторизации в .NET преимущество плюсов в части задач подсдулось.
Ну конечно кастомный TCP/IP стек на плюсах(FStack&DPDK), это факт, но не мы же его пишем, поэтому оставим честь мудохаться с плюсами оставим другим
А уж с завозом ref struct, Span, пулинга памяти из коробки, возможностью рулить GC в .NET вообще настала лафа для разработки, ориентированной на low latency.
Только есть огроменный нюанс-код на шарпе быстрее разрабатывать, компилировать, сопровождать, и чем больше инфраструктура-тем больше выигрыш.
А так уже все сказано здесь: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-gpp.html
Если где-то прямо сильно плюса бустят HotPath-не проблема воткнуть конкретный кусман код на нем и через PInvoke заюзать. Но пилить все на плюсах?
Плюсы остались только там, где уже вбуханы человеко-года(а то и десятки человеко-лет)-в конкретную инфру и отказываться от неё никто не будет.
А начинать с нуля пилить подобное? Ну ок-вперед! Пока вы годами будете пилить то, что на других техстеках при прямых руках делается за месяцы
Здравствуйте, chaotic-kotik, Вы писали:
НС>>hi perf S3 совместимый сторадж на го. CK>у S3 стораджа низкие требования к latency,
Во-первых, S3 это просто API, с чего бы оно определяло требования к латентности?
Во-вторых, minio затачивался прежде всего под AI/ML и я бы не сказал что там какие то особо низкие требование к латентности.
В-третьих, с какого фига в топике всплыли высокие требования к латентности?
CK>я не утверждал что отменяет
Ты заявил, что С++ нужен для входа в эту сферу. И вдруг, внезапно, оказалось что самые популярные решения зачастую написаны вовсе не на С++. А переписанные на С++ они используются полутора калеками. Вот и весь факт.
CK>и кстати про кактус ты зря https://www.scylladb.com/users/
Совсем не впечатляет. С Кассандрой смешно сравнивать
CK>, которые написаны под современное железо (DMA с сетью и диском) и низкий latency
В первоначальном сообщении ничего не было про низкий latency. А если бы упомянул про это сразу — необходимость знания С++ для достаточно узкого сегмента рынка (а не широченного, как изначально тобой было заявлено) выглядит не особо убедительно.
CK>гхм, как можно понять фразу "без с++ не вьехать в кучу интересных проектов, которые на нем пишут, это всякая инфраструктура, базы данных, распределенные очереди" как "без с++ не вьехать в кучу интересных проектов, которые ТОЛЬКО на нем пишут, это ВСЯ инфраструктура, базы данных, распределенные очереди"? ты понимаешь русский язык вообще?
Понимаю. А еще вижу как активно ты завилял жопой, на ходу придумывая новые требования и ограничения.
НС>>>hi perf S3 совместимый сторадж на го. CK>>у S3 стораджа низкие требования к latency,
НС>Во-первых, S3 это просто API, с чего бы оно определяло требования к латентности?
Ну ты посмотри на S3 API для начала
НС>В-третьих, с какого фига в топике всплыли высокие требования к латентности?
из того сообщения, на которое ты отвечал
благодаря новому железу, у языка новая жизнь, потому что DPDK, и DMA в память, вместо обычных системных вызовов для чтения и записи, у современного нвме диска десятки тысяч очередей для вполнения запросов и ты тупо не можешь остановиться для сборки мусора, потому что там все занимает микросекунды теперь, вместо десятков милисекунд (раньше gc был одного порядка с seek-ом дисковым, теперь нет больше этих ваших seek-ов), чтобы адекватно работать с современным I/O нужно писать так, как пишут разработчики scylladb, например, а не на java
НС>Ты заявил, что С++ нужен для входа в эту сферу. И вдруг, внезапно, оказалось что самые популярные решения зачастую написаны вовсе не на С++. А переписанные на С++ они используются полутора калеками. Вот и весь факт.
нет, это ты просто не понял что я написал
я написал, что для эффективной работы с современным железом (и соотв. входа в сферу, где его эксплуатируют для создания продуктов), нужен С++. это очевидно любому кто этим занимается, код, эфективно работающий с диском, сегодня выглядит совсем не так, как привыкло большинство программистов, он очень асинхронный и активно юзает, скажем, linux aio и io_uring
НС>Понимаю. А еще вижу как активно ты завилял жопой, на ходу придумывая новые требования и ограничения.
у меня складывается впечатление, что когда ты видишь слово latency, срабатывает knee jerk reaction, которая заставляет тебя думать о том, что речь шла о трейдинге и HFT и тому подобных вещах. но речь шла ровно о том, что я написал в первом сообщении
HFT>Это результаты проектирования сразу на performance, не более(пулинг памяти, кешфрендли раскладка данных, отсутствие динамической аллокации ака предварительный подъем "мира" разом, инлайнинг кода в HotPath, уменьшение меморитраффика в алгоритмах, использование векторизации где только она втыкается и дает результат и прочая).
в той же сцилле, никакой мир разом не поднять, в любой СУБД материализовать в памяти все что только можно заранее — гиблое дело
еще там полно динамических аллокаций, так что интуиция насчет проектирования на performance неверная
HFT>Только есть огроменный нюанс-код на шарпе быстрее разрабатывать, компилировать, сопровождать, и чем больше инфраструктура-тем больше выигрыш. HFT>А так уже все сказано здесь: HFT>https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-gpp.html HFT>Если где-то прямо сильно плюса бустят HotPath-не проблема воткнуть конкретный кусман код на нем и через PInvoke заюзать. Но пилить все на плюсах? HFT>Плюсы остались только там, где уже вбуханы человеко-года(а то и десятки человеко-лет)-в конкретную инфру и отказываться от неё никто не будет. HFT>А начинать с нуля пилить подобное? Ну ок-вперед! Пока вы годами будете пилить то, что на других техстеках при прямых руках делается за месяцы
я не помню когда в последний раз писал на плюсах что-то такое, что было сильно сложнее дольше чем на шарпе или джаве, современные плюсы сейчас за тебя даже операторы генерируют
в нормальном коде обычно нет арифметики указателей, а работа с коллекциями и объектами выглядит точно также как и в друих языках, управление памятью тоже автоматизированно
в целом я согласен, что на шарпе или жаве писать проще и быстрее, но есть один ньюанс, если в плюсах я испорчу память, то легко найду это с помощью ASan, низкоуровневый код на шарпе или джаве тоже может испортить память, но вот помощи от туллинга — никакой, ну а сильно оптимизированный код выглядит сильно хуже чем на плюсах (скажем та же векторизация, в плюсах я могу положиться на компилятор и написать простой цикл, в шарпе же сам понимаешь что получится)
Потому что из прошлого тянется догма "C++ — быстро, Java — медленно", которая заставляет выбирать С++ в качестве основного языка нового проекта. Но в современном мире почти не осталось задач, в которых С++ нельзя было бы заменить на что-то подобное или лучше. Кстати, у меня есть совершенно обратный пример. Я попал на проект по разработке робота, и директор по разработке специально запретил использовать С++, потому что большинство сотрудников пришло из embedded, и едва ли хорошо знали язык. В итоге всё спокойно писалось на Си + Python (в том числе и расчёт в реальном времени позиций манипулятора), и по вычислительной мощности был огромный запас.
Ещё одна немаловажная деталь: многие верят, что если проект mission critical, то С++ гарантирует предсказуемость из коробки. Типа GC требует времени, а вот malloc выполняется всегда предсказуемо и за микросекунды. А это не так. Правда в том, если вам надо просто переворачивать биты, то даже мнимое ускорение на 5-10% не стоит головной боли, которую (возможно) даст С++, а если же проект требует стабильности и предсказуемости в расчётах, то всё равно придётся следить за руками, денормализировать структуры данных, не использовать стандартные компоненты и так далее.
