Да не за что, просто бросилось в глаза, что используется наивная реализация make_index_sequence, требущая инстанциации кучи классов. В стандартной библеотеке это делается через compiler intrinsics. Сделайте pull request в "не свой код" — сэкономите свое время компиляции.

в библиотеке поддержка с++11, там вроде не было ещё make_index_sequence

можно ли как-нибудь проверить свою программу на работу в условиях очень малого доступного объема ОЗУ на linux x86_64? Объем RAM может быть килобайты (стек + куча). Ну и вообще, как-нибудь точно мониторить сколько ОЗУ требуется проге. Или лучше сразу куда-нибудь в эмулятор залезть?

можно ли как-нибудь проверить свою программу на работу в условиях очень малого доступного объема ОЗУ на linux x86_64? Объем RAM может быть килобайты (стек + куча). Ну и вообще, как-нибудь точно мониторить сколько ОЗУ требуется проге. Или лучше сразу куда-нибудь в эмулятор залезть?

на килобайтах памяти линукс не взлетит)

речь идет не про систему целиком, а конкретное приложение в ней

можно ли как-нибудь проверить свою программу на работу в условиях очень малого доступного объема ОЗУ на linux x86_64? Объем RAM может быть килобайты (стек + куча). Ну и вообще, как-нибудь точно мониторить сколько ОЗУ требуется проге. Или лучше сразу куда-нибудь в эмулятор залезть?

лимит можно задать setrlimit

так то памяти десятки гигабайт.

речь идет не про систему целиком, а конкретное приложение в ней

ну профилировщики памяти для этого есть

лимит можно задать setrlimit

я подозреваю, что столь мелкий лимит оно не даст сделать.

в вижл студии классный очень даже

ну профилировщики памяти для этого есть

а какие из них умеют точно измерять? пусть прога при это и тормозит как угодно сильно.

я подозреваю, что столь мелкий лимит оно не даст сделать.

лучше проверить)

а какие из них умеют точно измерять? пусть прога при это и тормозит как угодно сильно.

да любые в принципе измеряют точно

но это все в винде

виндов не имею

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

виндов не имею

ну профилировщики везде есть

можно ли как-нибудь проверить свою программу на работу в условиях очень малого доступного объема ОЗУ на linux x86_64? Объем RAM может быть килобайты (стек + куча). Ну и вообще, как-нибудь точно мониторить сколько ОЗУ требуется проге. Или лучше сразу куда-нибудь в эмулятор залезть?

у setrlimit вот отдельно RLIMIT_AS, RLIMIT_STACK

у setrlimit вот отдельно RLIMIT_AS, RLIMIT_STACK

спасибо, попробую. а в плане профилировщиков памяти что-нибудь посоветуешь?

не пользовался много, знаю в основном только про валгринд

можно ли как-нибудь проверить свою программу на работу в условиях очень малого доступного объема ОЗУ на linux x86_64? Объем RAM может быть килобайты (стек + куча). Ну и вообще, как-нибудь точно мониторить сколько ОЗУ требуется проге. Или лучше сразу куда-нибудь в эмулятор залезть?

https://docs.docker.com/config/containers/resource_constraints/#limit-a-containers-access-to-memory

можно руками через cgroups

спасибо, попробую. а в плане профилировщиков памяти что-нибудь посоветуешь?

valgrind с Massif вроде бы делает именно это.

эти лимиты, кстати, довольно зыбкие на самом деле, как я понимаю. в том плане, что в linux же лениво реальная память выделяется. поэтому после new int[100500] памяти будет выделено примерно нуль. До тех пор пока по этой памяти прога не пройдется и странички не потрогает. Если ограничить же адресное пространство (виртуальную память) каким-нибудь мелким значением, то прога не взлетит вовсе, ибо не сможет либы загрузить/свой исполняемый файл в память отобразить.

спасибо, попробую. а в плане профилировщиков памяти что-нибудь посоветуешь?

HeapTrack

https://habr.com/company/oleg-bunin/blog/340394/

спасибо, попробую. а в плане профилировщиков памяти что-нибудь посоветуешь?

gperftools, Valgrind

Спасибо всем. Буду щупать ?

эти лимиты, кстати, довольно зыбкие на самом деле, как я понимаю. в том плане, что в linux же лениво реальная память выделяется. поэтому после new int[100500] памяти будет выделено примерно нуль. До тех пор пока по этой памяти прога не пройдется и странички не потрогает. Если ограничить же адресное пространство (виртуальную память) каким-нибудь мелким значением, то прога не взлетит вовсе, ибо не сможет либы загрузить/свой исполняемый файл в память отобразить.

если 10 программ напишут new[1GB], когда в системе только 1GB, то остальные 9 получат ошибку. Память у нас не при использовании будет крашится, а при выделении, соответственно подсчёт должен быть тоже в той точке

если 10 программ напишут new[1GB], когда в системе только 1GB, то остальные 9 получат ошибку. Память у нас не при использовании будет крашится, а при выделении, соответственно подсчёт должен быть тоже в той точке

а точно получат? в линуксе? с настройками по умолчанию?

откуда сомнения?

отсюда: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

если я запрашиваю, то ожидаю, что выделят при наличии свободной памяти

если 10 программ напишут new[1GB], когда в системе только 1GB, то остальные 9 получат ошибку. Память у нас не при использовании будет крашится, а при выделении, соответственно подсчёт должен быть тоже в той точке

а когда в системе 0.5 гб?

и из личного опыта

возможно, не сталкивался

если я запрашиваю, то ожидаю, что выделят при наличии свободной памяти

в линуксе (и в юниксах вообще) это не так работает

если я запрашиваю, то ожидаю, что выделят при наличии свободной памяти

Зависит от настроек memory_overcommit и ovecommit_ratio. А также от кучи условий в юзерспейсе.

в линуксе (и в юниксах вообще) это не так работает

ЕМНИП, в виндах тоже

new аллоцирует в разделяемой.. туда плюсуется ещё и своп

ЕМНИП, в виндах тоже

в виндах несколько иначе. там malloc таки умеет 0 вернуть.

наверно

new аллоцирует в разделяемой.. туда плюсуется ещё и своп

Аллоцирует в виртуальной, в соответствии с выбранными политиками memory managmment'а. Потом, при обращении, выкидывает, если отмапить в реальную, с учётом свопа, уже нельзя.

Другое дело, что new должен ещё и конструкторы вызвать, т.е. обращение должно быть сразу.

какой сигнал?

segv?

какой сигнал?

да, конечно.

Другое дело, что new должен ещё и конструкторы вызвать, т.е. обращение должно быть сразу.

если это не что-то примитивное. а new бывает и для примитивного.

если это не что-то примитивное. а new бывает и для примитивного.

ну да, согласен.

valgrind с Massif вроде бы делает именно это.

а не vagrant?

а не vagrant?

нее. Vagrant - это ж для управления виртуальными машинами )

а не vagrant?

http://valgrind.org/docs/manual/ms-manual.html

Аллоцирует в виртуальной, в соответствии с выбранными политиками memory managmment'а. Потом, при обращении, выкидывает, если отмапить в реальную, с учётом свопа, уже нельзя.

точно? виртуальной памяти же нет как таковой.. это сумма резидентной + кучи и ещё чего там ещё

просто в хабрастетье про вагрант пишут. может очепятка конечно

точно? виртуальной памяти же нет как таковой.. это сумма резидентной + кучи и ещё чего там ещё

Неточно, но близко к истине ) С vm.overcommit_memory, выставленным в OVERCOMMIT_GUESS , выделяется столько, сколько может адресоваться в принципе (48 бит в x86, если не ошибаюсь). Но при обращении к невлазящим страницам вылетит sigsegv.

у меня везде vm.overcommit_memory = 0 по дефолту

наверно незря

у меня везде vm.overcommit_memory = 0 по дефолту

это и есть OVERCOMMIT_GUESS )

у меня везде vm.overcommit_memory = 0 по дефолту

чтоб совсем без оверкоммита - это 2.

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

https://elixir.bootlin.com/linux/v4.2/source/include/uapi/linux/mman.h#L9

нашёл

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

https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

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

Название констант — откуда-то из исходников, да ) Их значения — из доков: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

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

про управление память в целом — https://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html

и ещё: http://catap.ru/blog/2009/05/03/about-memory-oom-killer/ http://catap.ru/blog/2009/05/05/about-memory-overcommit-memory/

да любые в принципе измеряют точно

нет. потому что это семплирующие профилировщики. или они уже научились не пропускать аллокации памяти?

нет. потому что это семплирующие профилировщики. или они уже научились не пропускать аллокации памяти?

семлдирующие то есть по снимкам измеряют?

семлдирующие то есть по снимкам измеряют?

да

в вижле, напомню, именно семплирующий

ну вижловской да

xperf емнип тоже

семлдирующие то есть по снимкам измеряют?

ага. Типа gprof.

вот про heaptrack не помню. могу сказать, что valgrind точно не пропустит, так как он эмулирующий

valgrind + massif кто-то выше упоминал уже

но вообще я бы при первом приближении наверное не сильно парился и началд бы работу с каким-нибудь heaptrack

с высокой частотой снимков

а какие библиотеки для жсона есть? небольшие. кроме rapidjson и nlohmann

а какие библиотеки для жсона есть? небольшие. кроме rapidjson и nlohmann

Boost.Property_tree? ?

а какие библиотеки для жсона есть? небольшие. кроме rapidjson и nlohmann

Тут целый список http://json.org/

Вон, minijson_reader/minijson_writer

Однофайловые =)

callback-based. да я с ума сойду

обожаю однофайловые header-only либы... открывать в IDE

А вот бенчмарки для них на всякий случай https://github.com/miloyip/nativejson-benchmark

а какие библиотеки для жсона есть? небольшие. кроме rapidjson и nlohmann

jsoncpp

jsoncpp

meson and ninja

как что-то плохое ?