?

Log in

No account? Create an account

Previous Entry | Next Entry

Ответ на бнопню по C++

Код, который напрямую зовёт std::vector{std::move(foo)} на данных в ощущениях компиляторах (gcc, clang) будет медленнее, чем construct_vector(std::move(foo)), где:

std::vector construct_vector(Foo && foo) {
    std::vector vec;
    vec.emplace_back(std::move(foo));
    return vec;
}


Почему это так случается? Из-за отсутствия оптимизации std::initializer_list. Конструкция вектора через std::vector{} создаёт initializer_list, мувает в него один элемент foo, затем копирует из initializer_list внутрь вектора. К сожалению.

construct_vector же копированием foo не занимается, а делает move construction. Значение вектора попадает в место вызова без копирования, через RVO.

Ну вот так хреново пока работаем с std::initializer_list. В стандарте C14 про это вот что есть: "the underlying array is copy-initialized". Опаньки.

Типичный C++, что ни фича, то засада. JavaScript и то без копирования передавал бы всё :)

P.S. По поводу «почему C++» (mpd) — это было не моё решение. Нам и на Эрланге с сишными вставками неплохо работалось, правда, в сервис работал в десять раз медленнее. Но если у компании есть ресурсы и время на то, чтобы создать поддерживать в тонусе команду C++-програмистов, почему бы и нет? :)

Ключевой момент тут такой: если не заниматься байтодрочерством, C++ из-за подобных недофич (чуть что — копируем! ну или не смогли понять жизненный цикл — тоже на всякий случай скопируем) будет работать не сильно быстрее остальных дефолтных языков, а то и медленнее и/или глючнее. Только если действительно понимать, что происходит, можно выжрать нетривиальный буст по производительности, и, если повезёт, не сильно потерять в безопасности. Но это если такая производительность действительно нужна. На мобилке она, за редкими исключениями, вряд ли нужна. В датацентре (если это не cuda) — уже более интересное распределение. Разница между десятью нодами и сотней нод в плане управления — колоссальна. Между сотней и тысячью — уже речь встаёт о дешевизне датацентра по сравнению с рабочим временем программиста.

Если C++ на вашем продукте позволяет обеспечить эту разницу в 10x, есть средства на программистов и время на их реализацию, почему бы и нет? У нас в MZ — есть. Компания зарабатывает несколько миллионов долларов в день. А в вашем НИИГиТ наверняка нет ни таких средств, ни таких требований к производительности, которые бы требовали кластера из более чем десятка машин, а их оптимизация явно встанет зарплатой программистов дороже, чем выгода от их сокращения.

Comments

mpd
Oct. 4th, 2016 08:34 am (UTC)
Re: «почему C++» (mpd) — это было не моё решение
Большое спасибо за отдельный ответ! Я уже думал, что - сознательно игнорируешь.

> Только если действительно понимать, что происходит

Вот, зря ты так говоришь!!!
Это же можно понять так, что ты популяризируешь идею что не надо ничего понимать, среда-компилятор-утилиты - всё за тебя решат! (и это говорит человек, который отключает подсветку в редакторе, чтобы держать всё в голове!!!)

Например, я - не знаю Erlang, Вики - это не всегда хорошо, но даже там пишут, что бездумно писать на этом языке - не совсем хорошо:

Эффективность

Как и многие другие языки программирования, Erlang имеет свои секреты написания эффективного кода. Совершенствование языка делает некоторые из трюков устаревшими, поэтому документация является лучшим руководством в вопросах оптимизации, в совокупности с профилированием и стресс-тестированием.

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

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

Или - ява, там есть сборка мусора. У меня есть друг, который умудрялся так писать сервлеты, что обслуживающий его сервер БД Оракл - замирал через пару часов после вывода веб-сайта с этими сервлетами в он-лайн. А отчего? Ну, он-то думал: ну, открою соединение при обработки страницы, обработка закончится - всё почиститься. Угу, как же! Соединение были такими "лёгкими" на стороне веб-сервера, что они скапливались, держа на стороне БД очень даже нехилые ресурсы... Думать надо!!!

Похоже, за это действительно стоит платить работникам, что они могут себе представить в голове задачу и понять, что они делают, даже если за них среда-компилятор-утилиты - решают (что решают, почему).
lionet
Oct. 4th, 2016 04:08 pm (UTC)
Re: «почему C++» (mpd) — это было не моё решение
Если не понимать, что происходит, в эрланге, часто получается просто немного медленнее, и, реже, подглючивает для какого-то юскейса.

Если не понимать, что происходит, в C++, получаются периодические краши (факап для всех клиентов сразу) и дырки в безопасности.

Qualitatively, конечно.
mpd
Oct. 4th, 2016 05:13 pm (UTC)
Re: «почему C++» (mpd) — это было не моё решение
Т.е., оглядываясь назад, ты всё же советуешь обратить внимание на Эрланг?

А - Haskell? Почему в http://lionet.livejournal.com/139828.html?thread=4604468#t4604468 zyxman скептически отозвался о нём?

Objective-C - извини, я сам - не хочу.

Ну и, насколько я понимаю, в сухом остатке, Си++ - не мёртв? ;-)
lionet
Oct. 4th, 2016 06:30 pm (UTC)
Re: «почему C++» (mpd) — это было не моё решение
Ну надо отличать троллинг от рабочих моментов. Я C и C++ знаю, скажем так, получше, чем многие. Когда я говорю, что он мёртв и нужно изучать тот же хаскель, то хуже всего, что может придумать какой-нибудь монокультурный PHP-шник — это бросаться изучать хаскель.

И да, Erlang и Haskell — их нужно изучать. Что в продакшне потом использовать — зависит от задач. Изучи Haskell, потом возьми Swift и херач — и то больше пользы будет, чем если сразу фигачить на Swift'е.

Profile

lionet
Lev Walkin
Website

Latest Month

December 2016
S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728293031
Powered by LiveJournal.com
Designed by yoksel