как бы разные адреса Schedule 0x7ffe4887b67f Schedule 0x7ffe4887b67f Schedule 0x7ffe4887b67f Take 0x1287c30 Execute 0x1287c30 Take 0x1287c31 Execute 0x1287c31 Take 0x1287c32 Execute 0x1287c32

push_back(T&&)

Есть два range-loop. for (auto& a : b) и for (auto&& a : b). http://coliru.stacked-crooked.com/a/3076969a7943976f http://coliru.stacked-crooked.com/a/3c5019e1663ddcfe В чем разница и когда полезно?

Говорят, что практически ничем не отличаются, за исключением экзотических случаев вроде "код не компилируется с auto&, потому что итератор возвращает rvalue прокси-объект вроде vector<bool>::iterator" https://stackoverflow.com/questions/13130708/what-is-the-advantage-of-using-universal-references-in-range-based-for-loops

push_back(T&&)

Для этого надо, чтобы переданный параметр был rvalue. Job&& job_ не является rvalue. Это lvalue.

Да, я вижу теперь о чем ты. Сейчас посмотрю куда и что копируется

Да, без std::move там копирование

Спасибо, поправлю 😉

http://coliru.stacked-crooked.com/a/9ecb10f0c0d59eaf

теперь все мувится

кстати, почему вектор не делает мув объектов при реаллокации буфера?

кстати, почему вектор не делает мув объектов при реаллокации буфера?

Делает, если они noexcept

отлично!

объекты noexcept быть не могут, а вот их move конструктор должен быть таким

а правда, что std::vector не использует realloc?

объекты noexcept быть не могут, а вот их move конструктор должен быть таким

да, добавил noexcept для move-ctor

теперь все мувится

а правда, что std::vector не использует realloc?

Кажется, что скорее да, потому что такой операции в стандартных аллокаторах не имеется.

вот ведь жопа

realloc во многих аллокаторах вообще zero cost

в ряде случаев, конечно

это какието магические аллокаторы без фрагментации?

при чем тут магия?

нафига вообще вам вектор в большинстве случаев? почему не дек?

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

дек тормоз, ты чего

в общем, читаю уже https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md

нафига вообще вам вектор в большинстве случаев? почему не дек?

vector by default is the best, give proper reason for the rest

в общем, читаю уже https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md

еще https://github.com/facebook/folly/blob/master/folly/docs/small_vector.md

ну да, похоже, придется кусочки этого folly себе втягивать, когда буду на плюсы переходить

потому что иначе смысла как-то маловато

хеш таблицы стандартные тоже сосут :(

ну да, похоже, придется кусочки этого folly себе втягивать, когда буду на плюсы переходить

откуда, с джаваскрипта?

у вектора есть reserve() если что

хеш таблицы стандартные тоже сосут :(

а в чем проблема?

дек тормоз, ты чего

зато без релокейтов

reserve применим не всегда

в фбвекторе не увидел чегото особого от реаллока

тот же memcpy/memmove упоминают

не вижу разницы с move от с++

На винде тестил ?

или с++ это делает поэлементно?

https://github.com/facebook/folly/blob/master/folly/FBVector.h#L1603

или с++ это делает поэлементно?

При любых раскладах выгоднее написать свой мув

На интринсиках

И с префетчингом

или с++ это делает поэлементно?

если нет, то семантику noexept в move-конструкторе они поменяли на IsRelocatable. не вижу разницы опять

https://github.com/facebook/folly/blob/master/folly/FBVector.h#L1603

if there is a possibility == если нет фрагментации. я правильно понимаю?

ну если один вектор на всю программу то да, повезет, наверное. а так — не вижу разницы с reserve

если нет, то семантику noexept в move-конструкторе они поменяли на IsRelocatable. не вижу разницы опять

ну кроме того что это будет работать без c++11

для reserve ты должен сам рассказать свои предположения о размере

а тут он спрашивает аллокатор

это удобно

я с jemalloc делаю точно также

а тут аллокатор угадывает за тебя

я блин не вижу разницы между скрытыми дырами которые делает аллокатор и стретегией выделения памяти обычным вектором

нет, аллокатор знает, из какой зоны у тебя чанк памяти, и нет ли за этим чанком еще свободных

плохо, что не видишь, а я, вот, вижу

и бенчмарки тоже делал

И с префетчингом

Это уже не C++

дак их там не будет почти всегда

и бенчмарки тоже делал

синтетические тесты тут не подходят

хотя не сказать, что безумный прирост производительности - копирование нынче не такая дорогая операция, да и аллокатор не всегда укладывается в оптимальный паттерн

стретегия выделять в N раз памяти больше вполне себе ок

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

и бенчмарки тоже делал

На какой ОС бенчамарки делал то ?

в N раз больше чего?

Каким компилятором ?

при чем тут компилятор, когда это зависит от аллокатора

в моем случае jemalloc и его метод nallocx

Просто под каждую ось разные компили

Так на какой ты тестировал и какой профит вышел ?

понятия не имею, какой-то свежий gcc и какой-то свежий linux

gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3) видимо, только это вообще не связано с темой разговора

Тогда фигня дело. На винде было бы интересно о профитах fbvector на std vector послушать

а мне - неинтересно

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

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

вот именно на мелких и будет прирост - вместо удвоения с копированием пары байт просто возвращать больший кусок памяти

но, как уже заметили выше, reserve(128) решает эту проблему, хотя и не бесплатно

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

Про std deque не забывай, кстати.

да что за приложения вы такие пишите где вам надо много непрерывных блоков элементов в памяти. возьмите дек, можетбыть?