Покровы сорваны!
May. 20th, 2016 02:44 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
thedeemonГруппа ученых под руководством Дэниела Лебреро из Лаборатории Торговых Программных Интерфейсов британской компании IG Markets Ltd провела статистическое исследование о связи числа баг-репортов и языков программирования на базе информации об открытых проектах на сайте "Центр деятельности мерзавцев" (GitHub.com, организация разрешена в России, за исключением некоторых периодов, когда она запрещена). Выяснилось, что наличие статической типизации и продвинутой системы типов не помогает в уменьшении ошибок, а порой даже вредит, в то время как меньше всего ошибок получается в программах на максимально простых языках.
Плотность багов у проектов с 10 звездами и более:
Теперь научно доказано, что![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
theiced был прав: типы не нужны, а писать надо на Кложури. А также Эрланге и Го. Адептам сложных языков и развитых систем типов надлежит раскаяться, одуматься и перестать уже своими надуманными неработающими идеями отвлекать благородных донов, занятых TDD.
Плотность багов у проектов с 10 звездами и более:
Теперь научно доказано, что
theiced был прав: типы не нужны, а писать надо на Кложури. А также Эрланге и Го. Адептам сложных языков и развитых систем типов надлежит раскаяться, одуматься и перестать уже своими надуманными неработающими идеями отвлекать благородных донов, занятых TDD.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2016-05-21 08:06 am (UTC)странно. По идее контейнеры должны гарантировать заявленную О-сложность. Разве что происходит какая-то кривая реаллокация вкупе с копированием содержимого там, где надо было косвенно передавать (мой случай). Ну дык щас проще стало контролировать такие вещи, можно прописывать move-операции. В том числе и обобщённо благодаря "универсальным ссылкам"
== date_time юзает lexical_cast, в качестве safe atoi
ахаха))
буст да, чудён и это ещё мягко сказано. shared_ptr из буста например - это просто facepalm. Но по большому счёту буст после С++11 уже нафиг не нужен. тот же упомянутый unique_ptr они таки добавили в стандартную либу, и работает он именно так, как от него ждёшь.
no subject
Date: 2016-05-21 10:15 am (UTC)> контейнеры должны гарантировать заявленную О-сложность
так одно другому не мешает. Высокий константный оверхед.
Основная претензия - это что в STL указатель на указателе сидит и указателем погоняет. Сколько указателей в std::map<std::string, std::string>? Примерно 2 в дереве и 2 указателя на строки, и 2 указатедя из каждой строки на строковый буфер. И два size_t ещё. Короче 8 х 8 = 64 байта оверхед хранения. Плюс потери на оверхед и фрагментацию кучи.
А какой у нас оверхед на разыменование указателя? Во-первых выбирается вся строка кеша, а это порядка 64 байт, во-вторых, на префетчер нагрузка.
Короче, с памятью надо работать так, как будто это диск с 64-байтовыми секторами. Аллокации делать чанками-массивами, и вместо указателей использовать индексы в этих массивах, т.к. в разы короче.
Ну итеде итепе. Лоу-левел во всей красе.
http://igoro.com/archive/gallery-of-processor-cache-effects/
Я у себя в проекте по верхам совершенно копнул, просто чтобы зияющие проседания заткнуть, там ещё копать и копать в плане оптимизации. STL же годится только для всякого служебного кода, где можно писать хоть на луа. Мало данных и скорость не нужна.
Процессорный оверхед на аллокации да, местами затыкается стекоподобными пулами.
> буст после С++11 уже нафиг не нужен
Ну и сколько из 130+ библиотек нафиг не нужны по причине включения в стандарт и наличия поддержки в компиляторе 5-летней давности от вендора на ваш выбор? Даже если брать последний компилятор от труЪ-вендора - окажется ненужных штук 5 всего, которые у всех на слуху. Из не упомянутых boost::function, например.
Короче, мы с Вами в разных вселенных живём.
no subject
Date: 2016-05-22 04:46 pm (UTC)Ok. А что тогда использовать взамен, если требуется ассоциативный контейнер для строк? Да еще со свойством стабильности ссылок (т.е. итераторы на элемент контейнера остаются валидными при вставке/удалении других элементов контейнера)?
no subject
Date: 2016-05-22 05:31 pm (UTC)no subject
Date: 2016-05-22 05:54 pm (UTC)А если ваш проект такой уникальный и map там не к месту, то чтож вы на него map примеряли?
no subject
Date: 2016-05-22 06:30 pm (UTC)Речь у меня о том, что STL представляет компромиссные дефолтовые решения, удовлетворительно работающие на широком спектре нагрузок.
STL безбожно тормозит в том смысле, что универсальное решение почти всегда обгоняется специализированным, причём по моему опыту, в случае STL это ускорение в разы. И роль STL в проекте сводится к некритичным участкам и этапу быстрого прототипирования. После чего STL быстро вырезается по совету профайлера. Это ответ на вопрос "чего ж примеряли".
Мой проект уникальный, как и Ваш. Если у вас в проекте боттлнек в лукапах std::map, и вы не можете придумать более быстрой специализированной альтернативы - бесплатно за вас вашу работу я делать не буду. Тем более что оптимизация - это комплексная задача, нужно видеть всю систему в целом и роль std::map в ней.
std::map это красно-чёрные деревья. Одних только самобалансирующихся деревьев есть штук 10 разных. AVL часто позиционируют как альтернативу. Помимо этого есть tries, hash tables, сортированные массивы (и деревья упакованные в массивы), вероятностные алгоритмы (Bloom filters и т п), автоматы, и можно творчески комбинировать подходы, создавая гибридные структуры. Например, делать отдельный индекс по первым (или последним) символам.
И помимо замены структуры на другую, есть чисто сишные трюки: укорачивание указателей, локальная сборка мусора (сокращает расходы на деаллокацию), хитрые схемы аллокации, хитрые склеивания чтобы вместо трёх аллокаций была одна, генерация специализированного кода в рантайме через LLVM и т.д.
no subject
Date: 2016-05-22 07:33 pm (UTC)Все понятно. В STL нет готовой структуры данных под вашу конкретную задачу, поэтому STL тормозит безбожно.
no subject
Date: 2016-05-22 08:45 pm (UTC)В тред реквестируются комментаторы http://nponeccop.livejournal.com/490910.html -
no subject
Date: 2016-05-22 09:12 pm (UTC)Ну и с моей джуниорской точки зрения вы ставите STL в вину то, что ради чего STL и создавалось: универсальное решение, которое трудно обогнать в общем случае. Что позволяет STL-ю решать, как минимум, две важнейшие задачи:
1. Быть единой системой типов для поставщиков различных компонентов. Грубо говоря, если одна команда пишет драйвер к СУБД, а вторая использует этот драйвер, то им нужно как-то между собой взаимодействовать: как-то строки должны передаваться, вектора строк, ассоциативные контейнеры и т.д. Наличие стандартизированных типов контейнеров сильно упрощает такое взаимодействие.
2. Быть базой, которая позволяет быстро и с минимальным количеством ошибок собирать работающие приложение или библиотеку, не тратя время на изобретение велосипедов. Чтобы потом, получив экономию времени на разработку прототипа, пройтись профайлером и определить, нужно ли что-то подкрутить и, если нужно, то где, как и чем.
По-моему, опять же, джуниорскому разумению, ради этого STL создавался и стандартизировался. И говорить, что STL безбожно тормозит вне рамок этих условий... Ну, блин, странно это.
no subject
Date: 2016-05-23 12:56 pm (UTC)Вот-вот. А то ведь это была проблема для Си/Си++. В каждой библиотеке своя строка и прочие типы. Потом в свой программе пытаешься их приклеить и состыковать.