Здравствуйте, Pzz, Вы писали:
Pzz>>>Ну в принципе, во многих случаях лучше. Например, у долгоживущей программы это может отложить освобождение памяти на периоды меньшей нагрузки,
M>>Ага, и GC выжрет всю доступную память.
Pzz>Ну, всю-не всю, но выжрет, конечно, больше, чем не-GC. Но это стандартный такой tradeoff, производительность можно купить, заплатив памятью.
А по разному бывает
M>>Или — поймает низкую загрузку, начнёт гарбажить, а тут — опа — сервис снова понадобился, но нет, сорян, подождите, у нас тут мусор собирают
Pzz>Знаешь, чем протоколы, придуманные телефонистами, отличаются от протоколов, которые используются в интернете? Телефонисты всегда резервируют ресурсы с гарантией, в рассчете на самый плохой сценарий. А интернетчики, оптимисты, считают, что если рассчитывать на некий средний случай с небольшим запасом, то и так сойдет.
Pzz>Поэтому теперь по проводам, которые телефонисты проложили для себя, ходит IP трафик с IP телефонией, за которую телефонисты не получают ни копейки
Но это никак не доказывает мифическое преимущество сишечки над современными плюсами
Здравствуйте, Pzz, Вы писали:
Pzz>>>Кстати, аналог этой програмки, написанный на перле, отрабатывал за те же полсекунды, безо всякой нужды отламывать перловый аллокатор.
M>>Как-то ты неправильно строки готовишь. У меня 700Кб кода работает со строками очень быстро. Да, тоже из мейкфайлапроекта вызывается раз по 5-10. Секунды три на всё про всё. И как я понимаю, основное время тратится на запуск процесса
Pzz>Там входной файл очень большой.
И как бы ты его обрабатывал на сишечке? Что вообще с ним делал?
Здравствуйте, Marty, Вы писали:
Pzz>>Там входной файл очень большой.
M>И как бы ты его обрабатывал на сишечке?
Вот я как раз и взял ++, чтобы не трахаться в этом месте с управлением памятью. Там достаточно сложные манипуляции с достаточно сложными данными, чтобы мне еще и этой головной болью не заниматься.
Кончилось тем, что освобождения я вообще отломил, ибо было невыносимо медленно. Так что мог бы сразу на сишечке писать
M>Что вообще с ним делал?
Перерабатывал полную таблицу инструкций 80x86 из одного представления в другое.
Здравствуйте, Pzz, Вы писали:
M>>И как бы ты его обрабатывал на сишечке?
Pzz>Вот я как раз и взял ++, чтобы не трахаться в этом месте с управлением памятью. Там достаточно сложные манипуляции с достаточно сложными данными, чтобы мне еще и этой головной болью не заниматься.
Pzz>Кончилось тем, что освобождения я вообще отломил, ибо было невыносимо медленно. Так что мог бы сразу на сишечке писать
И нигде бы не ошибся с указателями?
M>>Что вообще с ним делал?
Pzz>Перерабатывал полную таблицу инструкций 80x86 из одного представления в другое.
Хз, конечно, что это значит, но чем-то неподъемным не выглядит. Странно, что сложные манипуляции со сложными данными, а выбрал ты строки.
Профайлить пробовал?
Вообщем, конечно, не зная деталей, сложно что-то говорить. Но если данные и алгоритмы не закрытые, было бы интересно глянуть
Здравствуйте, Pzz, Вы писали:
_>>Нуу ознакомься ещё и с этим https://en.cppreference.com/w/cpp/string/basic_string/to_string. И естественно тебе никто не мешает перегрузить эту функцию для любого числа своих типов.
Pzz>Угу. А потом выясняется, что to_string нужен один для JSON, другой для XML, третий для ASN.1, и все они разные.
Pzz>В принципе, это хорошо, конечно, что этих дебильных внешних форматов, в которые надо сериализовать, не так уж и много. Но как-то не очень-то generic получается. В общем, серебряной пули опять не получилось.
В случае динамической рефлексии описанная ситуация чем-то отличается?
[]
BFE>Исходя из этого для многих проектов просто запрещается динамическая аллокация памяти. Соответственно выбрасывается всё, что аллоцирует память, начиная с std::vector …
А можно подробностей? А то все что я видел "у взрослых пацанов" без динамической памяти — это своя нарукоблуженная вариация хипа поверх статического буфера. Но память они не аллоцируют, ага. И исключений нету =)
Здравствуйте, CreatorCray, Вы писали:
Pzz>>В линухе stdlib'овский malloc и есть платформенный.
CC>Ну, значит то же самое что и в MSVC — просто вызывается платформенный аллокатор.
Да, но это совсем не объясняет, зачем он такой тормозной.
Здравствуйте, Marty, Вы писали:
Pzz>>Кончилось тем, что освобождения я вообще отломил, ибо было невыносимо медленно. Так что мог бы сразу на сишечке писать
M>И нигде бы не ошибся с указателями?
Ну, если память вовсе не освобождать, с чего бы мне с ними ошибаться?
M>Хз, конечно, что это значит, но чем-то неподъемным не выглядит. Странно, что сложные манипуляции со сложными данными, а выбрал ты строки.
Строки там были, помимо прочего.
M>Профайлить пробовал?
А какой смысл профайлить, если запрет освобождения дал сразы прирост скорости больше, чем на порядок?
M>Вообщем, конечно, не зная деталей, сложно что-то говорить. Но если данные и алгоритмы не закрытые, было бы интересно глянуть
Здравствуйте, Мирный герцог, Вы писали:
B>>А о том, что С++ повторяет судьбу С и постепенно сужается в узкие вышеозначенные области. Причем последние две области будут, скорее всего, относительно динамично переползать на Go и Rust. И только графика и ML, в силу мощных устоявшихся библиотек, еще долго будут тащить за собой C++. МГ>из C++ надо убегать роняя тапки, rust кстати не взлетит, потому что птичий язык для извращенцев-мазохистов (а-ля C++ или Haskell), а не для инженеров. Го взлетит, потому что наоборот, практичный язык для инженеров, а не теоретиков кайфа.
С++ тоже на заре был языком для инженеров, созданным инженером, разрабом бизнес логики. Очень много критичного промышленного софта написано именно на том языке. Но потом он превратился в какое-то реально УГ. Об этом не в курcе только несведущие хеллоуворлдщики, вроде местных гуру. С того C++ не переписывают на современнный C++-нутый кал, чтоб не испортить то, что прекрасно работатет, хотя желающий ыксперты-велосипедисты лезут изо всех щелей.
Здравствуйте, Marty, Вы писали:
M>Но вот например, забагованное до нельзя поделие — GCC — написано от и до на чистой сишечке, а качественный компилятор с человеческим лицом (clang/llvm) — на C++
По качеству генерируемого кода clang пока не дорос до GCC (вроде не один большой проект еше не использоует clang для релизов), но он уже получает очень широкое распространение за счет лучшей архитектуры. Clang-tidy, clang-format, clazy реально облегчают жизнь и улучшают качество кода.
Здравствуйте, Basil2, Вы писали:
B>Я здесь не про язык вообще, а конкретно про С++. Он сложнее чем большинство предметных областей. Если человек знает С++, он осилит почти что угодно. Поэтому знание С++ является определяющим, на мой взгляд.
Я с тобой согласен, но это не очень популярное мнение
Здравствуйте, Nuzhny, Вы писали:
N>FreeBSD, MacOS (?), Android, Google Chrome на Windows — это всё мелкие проекты?
Тут основной мотив-лицензия. БСДишники приняли решение выпилить GCC исключительно чтоб отвязать базовую систему от GPL. Clang же сильно сливает GCC во всём, начиная от оптимизации и заканчивая количеством поддерживаемых архитектур.
Здравствуйте, lpd, Вы писали:
lpd>В распозновании речи важен алгоритм, а не тулзы. Потому что оптимизировать будут именно его(при необходимости), а не лепить мув-семантику везде где попало.
Сейчас подобные задачи решаются и на ОЧЕНЬ ограниченном железе (в т.ч. на 8051), так что оптимизируют и алгоритмы и код. И альтернативы С/С++ там нет.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, lpd, Вы писали:
lpd>>В распозновании речи важен алгоритм, а не тулзы. Потому что оптимизировать будут именно его(при необходимости), а не лепить мув-семантику везде где попало. S>Сейчас подобные задачи решаются и на ОЧЕНЬ ограниченном железе (в т.ч. на 8051), так что оптимизируют и алгоритмы и код. И альтернативы С/С++ там нет.
Только оптимизируют simd инструкциями и ручным управлением памятью, а вовсе не мув-семантикой.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, De-Bill, Вы писали:
DB>Согласен. Распознавании речи инструмент — это не язык программирования С++. Это математика, модели, алгоритмы. Непростые такие инструменты.
Следующий шаг это заставить работать алгоритм на чем-то типа телефона. И тут только С++ иначе батарея сядет на порядок быстрее.
Здравствуйте, smeeld, Вы писали:
S>Всё просто-не пытайтесь устроиться работать в компании, с оборотом больше $100M и собственным фондом софта размеры которого больше гигабайта исходников (суммарный размер последних релизных веток).
Обычно полезной логики в этом коде 5-10%, остальное копи-паста с небольшими изменениями (или даже без них).
S>И тогда избежите встречи с кодом, который по-Вашему, несомненно компетентному мнению эксперта, считается говнокодом. Пилите и дальше свои хеллоуворлды кучкой единомышлеников-говноэкспертов.
Но совет хороший: если есть возможность посмотреть репозитория, то многие вопросы сразу отпадают.
Здравствуйте, Pzz, Вы писали: Pzz>Угу. А потом выясняется, что to_string нужен один для JSON, другой для XML, третий для ASN.1, и все они разные.
Pzz>В принципе, это хорошо, конечно, что этих дебильных внешних форматов, в которые надо сериализовать, не так уж и много. Но как-то не очень-то generic получается. В общем, серебряной пули опять не получилось.
