Господа, ни у кого не завалялся хороший сборник вопросов для собеседования?
cracking the coding interview
Evgenii
Sergey
в переводе говорят лучше не смотреть
Matwey
Студия не умеет такой синтаксис
Matwey
Господа, а инициализация union-ов по-типу
union_type x{.field=42};это стандартный синтаксис, или какое-то загнутое расширение?
Matwey
Такой
Alexey
Отсылка к Страструпу и 7/10?
Vitaliy
Господа, ни у кого не завалялся хороший сборник вопросов для собеседования?
https://isocpp.org/faq
Vadim
@vsbaldeev спасибо
Berkus
Nik
std::variant не?
Berkus
std::variant
vladislav
ответ в вопросе, классика
Berkus
он не сказал почему не катит
Berkus
опять же я видел отдельнстоящий с++14 вариант довольно маленький однохедерный
Berkus
но искать лень, гугл на что
Stanislav
опять же я видел отдельнстоящий с++14 вариант довольно маленький однохедерный
https://github.com/mapbox/variant этот?
Stanislav
из стандарта 17
🐙 Antony
Подкапотные в std::variant изменения весьма годные:
* никогда не аллоцирует динамически память под свои нужды
* constexpt очень много где, включая std::visit
* get(variant*) -> get_if(variant*) уменьшает путаницу и улучшает читаемость
* in_place конструирование
Nik
Как-то покрасивее смотрится, чем std. С паттернматчингом, ням.
Nik
https://github.com/mapbox/variant этот?
🐙 Antony
А чего именно хочется? Озвучьте конкретные требования
🦥Alex Fails
Anton
Ребят, в std::allocator реализовано слежение за фрагментацией памяти?
Anton
Или там используется наивный подход с malloc + placement new?
Anonymous
А не случаем malloc должен следить за фрагментацией памяти?
Berkus
маллок не очень много может сделать в большинстве случаев
Anton
А не случаем malloc должен следить за фрагментацией памяти?
По идее да. Но кол-во libc в мире как говна.
Square
Ребят, в std::allocator реализовано слежение за фрагментацией памяти?
Hoard, tbb::allocator
У последнего stl совместимость полная
Ioann_
Или там используется наивный подход с malloc + placement new?
Маллока там не используется, как я понимаю(использовать маллок, наверное было бы глупо - во первых, так сложнее следить за памятью(перегрузки new и т.п), а во вторых new умеет все тоже самое)
Square
Маллока там не используется, как я понимаю(использовать маллок, наверное было бы глупо - во первых, так сложнее следить за памятью(перегрузки new и т.п), а во вторых new умеет все тоже самое)
У hoard точно нет. Там heap layers в бекенде - своя хитрота какая то.
У них там вообще много интересного - есть die hard allocator - для рил критикал приложений
Square
А Интел не открыт
Ioann_
Я тут как то уже выкладывал резы своего аллокатора. Вроде быстрее всего что есть. Т.е буста, стл, и EAGames
Anton
Я тут как то уже выкладывал резы своего аллокатора. Вроде быстрее всего что есть. Т.е буста, стл, и EAGames
Можешь ещё раз ссыль выложить?
Square
Square
Вообще лучший аллокатор - который не выделяет :))
Square
Я тут как то уже выкладывал резы своего аллокатора. Вроде быстрее всего что есть. Т.е буста, стл, и EAGames
А чо в бусте? Я прост не юзаю буст в бою :(
Square
++
Ioann_
Сам аллокатор я не выкладывал, но резы вввкладывал. Мне конечно не сложно выложить его, но это смогу позже - т к не у основного пеки сейчас, и вообще за телефоном. А небольшой бенч вот
Ioann_
Ioann_
Да
Ioann_
Первая строка построение, вторая строка поиск и проходы по памяти соответственно. Только надо вспомнить условия теста. Там было, что буст вообще отставал.
Ioann_
Там было так - буст аллокатор использовался в своем контейнере. И эти результаты наверху. Мой аллокатор я использовал в std set и они тоже на картинке. А вот когда буст аллокатор пмхаешь не в бустовый контейнер а в stl - то буст очень сильно отставал. Когда свой аллокатор вставлял в буст контейнер - было тоже самое что на картинке.
Ioann_
Но третьи результаты на картинке показывают мой собственный set с моим же аллокатором ;)
Ioann_
Еще отмечу что 64 бит апп работает медленнее 32, при тесте аллокатора. Это возможно связано как раз с кешем. Система у меня 64бита, десяточка.
Ioann_
От части так наверное и есть.
Ioann_
Да можно будет. Но сначала хочу проверить как файлег быстрее всего читать fread ом. Сразу весь или блоками под кеш hdd~(65kb)
Ioann_
Ну тоже не спорю. Но интересно ж.
Matwey
Ребят, в std::allocator реализовано слежение за фрагментацией памяти?
он дергает ОС по этому поводу
Диджитал
зависит от ОС, но вообще аллокатор запрашивает у ОС большой кусок, а потом от него нарезает сам, и дефрагментирует тоже
Диджитал
каждый раз дергать ось было бы слишком дорого
🐙 Antony
Крылатый
Думаю, быстрей прочитать из оперативы.
Pavel
есть ещё posix_fadvise и POSIX_FADV_SEQUENTIAL
Aleksei
недавно где-то видел картинку в тему...
https://hsto.org/web/d61/005/8cf/d610058cf6094336ba3f4de1d1829f5a.jpg
Крылатый
недавно где-то видел картинку в тему...
https://hsto.org/web/d61/005/8cf/d610058cf6094336ba3f4de1d1829f5a.jpg
Ну, мою аудиотеку можно, например.
Крылатый
64 гига хватит.
Крылатый
Операционка и прилажуха поживут в кэшеипооца
Крылатый
Кэше проца*
Ioann_
Я не хочу уходить в дискусс, но в данном случае все зависит от page fault и т.п А на счет того что я не хочу в дискусс, потому что проще всего этот момент погуглить и почитать что к чему - я серьезно, холиваров на эту тему полно.
Ioann_
https://lemire.me/blog/2012/06/26/which-is-fastest-read-fread-ifstream-or-mmap/
Berkus
Маллока там не используется, как я понимаю(использовать маллок, наверное было бы глупо - во первых, так сложнее следить за памятью(перегрузки new и т.п), а во вторых new умеет все тоже самое)
это смешно, а new по твоему что обычно использует? )
Berkus
нет, strcut не определен
Pavel
почему не template <auto ... Args>? это же тоже самое
Berkus
почему не template <auto ... Args>? это же тоже самое
потому что надо один выделенный тип и остальные trailing?
Pavel
а, нуда. один же тип надо
Pavel
ну, всё же должно работать ровно как ты написал
Tom
Ну и делай на здоровье :)
Tom
Ну или кусок кода кидай побольше
🐙 Antony
https://lemire.me/blog/2012/06/26/which-is-fastest-read-fread-ifstream-or-mmap/
Забавно, у чувака результаты "Conclusion: For sequential access, both fread and ifstream are equally fast. Unbuffered IO (read) is slower, as expected. Memory mapping is not beneficial."
А у меня mmap жог и на 10% работал быстрее, вот на таком бенчмарке https://github.com/apolukhin/Boost-Cookbook/blob/second_edition/Chapter11/08_reading_files/main.cpp
🐙 Antony
Забавно, у чувака результаты "Conclusion: For sequential access, both fread and ifstream are equally fast. Unbuffered IO (read) is slower, as expected. Memory mapping is not beneficial."
А у меня mmap жог и на 10% работал быстрее, вот на таком бенчмарке https://github.com/apolukhin/Boost-Cookbook/blob/second_edition/Chapter11/08_reading_files/main.cpp
А, у него проц мощнее и данных поменьше! Тогда всё ок
Tom
Чет телефон мой тупит. Ты с С++17 компилишь?
Tom
Потому как иначе class вроде должен быть