Покровы сорваны!

[thedeemon]

Группа ученых под руководством Дэниела Лебреро из Лаборатории Торговых Программных Интерфейсов британской компании IG Markets Ltd провела статистическое исследование о связи числа баг-репортов и языков программирования на базе информации об открытых проектах на сайте "Центр деятельности мерзавцев" (GitHub.com, организация разрешена в России, за исключением некоторых периодов, когда она запрещена). Выяснилось, что наличие статической типизации и продвинутой системы типов не помогает в уменьшении ошибок, а порой даже вредит, в то время как меньше всего ошибок получается в программах на максимально простых языках.

Плотность багов у проектов с 10 звездами и более:


Теперь научно доказано, что theiced был прав: типы не нужны, а писать надо на Кложури. А также Эрланге и Го. Адептам сложных языков и развитых систем типов надлежит раскаяться, одуматься и перестать уже своими надуманными неработающими идеями отвлекать благородных донов, занятых TDD.

Comments

[nponeccop.livejournal.com]

Несколько возражений:

1. 10 звёзд - это очень мало. У моих проектов с 0 пользователей - по 40 звёзд.

2. Чарт отражает любовь авторов к бюрократии. Эрлангисты с рубистами просто бюрократию не любят, а джависты скрупулёзно малейшие бажики репортят.

У меня в одном закрытом проекте 500 ишшуёв, в том числе и дефекты. Кто-то может посчитать это демотивирующей бюрократией и не заниматься такой детализацией.

3. По поводу С++ - так и должно быть. Вокруг С++ много мифов, видимо распространяемых людьми, не работавшими в крестовых шопах и надрачивающими на опенсорс.

У меня в проекте за 15 лет было 2 (два) бага с повреждением памяти, и то в самом начале, пока низкоуровневые вещи писал. 0 утечек. Продвинутые фичи языка (за которые его часто ругают - шаблонное метапрограммирование, запутанное разрешение имён) - не используются. В результате от джавы отличается, внимание, только тем, что надо помнить про RAII и чтобы локальную переменную по ссылке не вернуть.

[binf.livejournal.com]

== Продвинутые фичи языка .. - не используются

STL, unique_ptr, вывод типов auto, move-перегрузки тоже в топку?

[nponeccop.livejournal.com]

У меня к сожалению да, ни одна фича из перечисленного списка не используется.

STL тормозит же безбожно, у меня везде где он раньше был пришлось выкинуть, т.к. немедленно возникали боттлнеки.

Буст тоже смешной местами. Например, date_time юзает lexical_cast, в качестве safe atoi. А этот lexical_cast тормозит ну просто безбожно. Авторы говорят "либа предназначена для парсинга конфигов, если вы засунули в inner loop - сами дурак, wontfix"

[binf.livejournal.com]

== STL тормозит же безбожно

странно. По идее контейнеры должны гарантировать заявленную О-сложность. Разве что происходит какая-то кривая реаллокация вкупе с копированием содержимого там, где надо было косвенно передавать (мой случай). Ну дык щас проще стало контролировать такие вещи, можно прописывать move-операции. В том числе и обобщённо благодаря "универсальным ссылкам"

== date_time юзает lexical_cast, в качестве safe atoi

ахаха))

буст да, чудён и это ещё мягко сказано. shared_ptr из буста например - это просто facepalm. Но по большому счёту буст после С++11 уже нафиг не нужен. тот же упомянутый unique_ptr они таки добавили в стандартную либу, и работает он именно так, как от него ждёшь.

[nponeccop.livejournal.com]

>> STL тормозит же безбожно

> контейнеры должны гарантировать заявленную О-сложность

так одно другому не мешает. Высокий константный оверхед.

Основная претензия - это что в 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, например.

Короче, мы с Вами в разных вселенных живём.

[yauheni akhotnikau (from livejournal.com)]

> Сколько указателей в std::map&ld;std::string, std::string>? Примерно 2 в дереве и 2 указателя на строки, и 2 указатедя из каждой строки на строковый буфер. И два size_t ещё. Короче 8 х 8 = 64 байта оверхед хранения. Плюс потери на оверхед и фрагментацию кучи.

Ok. А что тогда использовать взамен, если требуется ассоциативный контейнер для строк? Да еще со свойством стабильности ссылок (т.е. итераторы на элемент контейнера остаются валидными при вставке/удалении других элементов контейнера)?

[nponeccop.livejournal.com]

Вот же ж обобщателей понабежало. Перечитайте пост - я всего лишь о своём проекте говорил. Что там у вас - мне не интересно.Сами разбирайтесь.

[yauheni akhotnikau (from livejournal.com)]

У меня нет желания общаться в стиле "сам дурак". Однако, если уж по вашему мнению, STL медленный (и map в частности), то что быстрее при прочих равных?

А если ваш проект такой уникальный и map там не к месту, то чтож вы на него map примеряли?

[nponeccop.livejournal.com]

С чего вы решили, что у меня есть решение, быстрее STL при прочих равных? Если б оно у кого-то было - оно бы было в стандарте.

Речь у меня о том, что STL представляет компромиссные дефолтовые решения, удовлетворительно работающие на широком спектре нагрузок.

STL безбожно тормозит в том смысле, что универсальное решение почти всегда обгоняется специализированным, причём по моему опыту, в случае STL это ускорение в разы. И роль STL в проекте сводится к некритичным участкам и этапу быстрого прототипирования. После чего STL быстро вырезается по совету профайлера. Это ответ на вопрос "чего ж примеряли".

Мой проект уникальный, как и Ваш. Если у вас в проекте боттлнек в лукапах std::map, и вы не можете придумать более быстрой специализированной альтернативы - бесплатно за вас вашу работу я делать не буду. Тем более что оптимизация - это комплексная задача, нужно видеть всю систему в целом и роль std::map в ней.

std::map это красно-чёрные деревья. Одних только самобалансирующихся деревьев есть штук 10 разных. AVL часто позиционируют как альтернативу. Помимо этого есть tries, hash tables, сортированные массивы (и деревья упакованные в массивы), вероятностные алгоритмы (Bloom filters и т п), автоматы, и можно творчески комбинировать подходы, создавая гибридные структуры. Например, делать отдельный индекс по первым (или последним) символам.

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

[yauheni akhotnikau (from livejournal.com)]

> С чего вы решили, что у меня есть решение, быстрее STL при прочих равных?

Все понятно. В STL нет готовой структуры данных под вашу конкретную задачу, поэтому STL тормозит безбожно.

[nponeccop.livejournal.com]

С моей точки зрения вы пишете обычный, стереотипичный джуниорский бред.

В тред реквестируются комментаторы http://nponeccop.livejournal.com/490910.html - pappadeux, swizard и elizarov, чтобы разъяснить несчастному содержание предыдущих серий и показать, в каком именно смысле STL тормозит безбожно. Ну или опровергнуть - дескать, от задачи зависит, и STL не только медленный, но даже и шустрый очень, если правильно готовить.

[yauheni akhotnikau (from livejournal.com)]

Да я вообще программировать не умею, большинство LOR-овских аналитиков вам это с удовольствием подтвердят.

Ну и с моей джуниорской точки зрения вы ставите STL в вину то, что ради чего STL и создавалось: универсальное решение, которое трудно обогнать в общем случае. Что позволяет STL-ю решать, как минимум, две важнейшие задачи:

1. Быть единой системой типов для поставщиков различных компонентов. Грубо говоря, если одна команда пишет драйвер к СУБД, а вторая использует этот драйвер, то им нужно как-то между собой взаимодействовать: как-то строки должны передаваться, вектора строк, ассоциативные контейнеры и т.д. Наличие стандартизированных типов контейнеров сильно упрощает такое взаимодействие.

2. Быть базой, которая позволяет быстро и с минимальным количеством ошибок собирать работающие приложение или библиотеку, не тратя время на изобретение велосипедов. Чтобы потом, получив экономию времени на разработку прототипа, пройтись профайлером и определить, нужно ли что-то подкрутить и, если нужно, то где, как и чем.

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

[andrei-dikun.livejournal.com]

>> Быть единой системой типов для поставщиков различных компонентов.

Вот-вот. А то ведь это была проблема для Си/Си++. В каждой библиотеке своя строка и прочие типы. Потом в свой программе пытаешься их приклеить и состыковать.

[swizard.livejournal.com]

> Вокруг С++ много мифов
> У меня в проекте за 15 лет было 2 (два) бага с повреждением памяти

Мифов везде полно. У меня в CL, например, за всё время были какие-то единицы ошибок, связанных с типами. При этом считается, что на языках с динамической типизацией программировать невозможно, потому что это нескончаемая борьба с падающим рантаймом.