недавно где-то видел картинку в тему... https://hsto.org/web/d61/005/8cf/d610058cf6094336ba3f4de1d1829f5a.jpg

Ну, мою аудиотеку можно, например.

64 гига хватит.

Операционка и прилажуха поживут в кэшеипооца

Кэше проца*

Быстрее всего читать mmap :)

Нет. Не всегда и не обязательно.

Я не хочу уходить в дискусс, но в данном случае все зависит от page fault и т.п А на счет того что я не хочу в дискусс, потому что проще всего этот момент погуглить и почитать что к чему - я серьезно, холиваров на эту тему полно.

https://lemire.me/blog/2012/06/26/which-is-fastest-read-fread-ifstream-or-mmap/

template <typename Type, Type ... Args> strcut Foo{};

так можно сделать?

https://lemire.me/blog/2012/06/26/which-is-fastest-read-fread-ifstream-or-mmap/

да, я как-то пару недель назад на это натыкался

Маллока там не используется, как я понимаю(использовать маллок, наверное было бы глупо - во первых, так сложнее следить за памятью(перегрузки new и т.п), а во вторых new умеет все тоже самое)

это смешно, а new по твоему что обычно использует? )

Эй, гуру С++, так реально сделать?

template <typename Type, Type ... Args> strcut Foo{};

template <typename Type, Type ... Args> strcut Foo{};

нет, strcut не определен

template <typename Type, Type ... Args> strcut Foo{};

почему не template <auto ... Args>? это же тоже самое

почему не template <auto ... Args>? это же тоже самое

потому что надо один выделенный тип и остальные trailing?

а, нуда. один же тип надо

template <typename Type, Type ... Args> struct Foo{};

я хочу сделать что-то такое: Foo<int,2,3,4,5>

ну, всё же должно работать ровно как ты написал

я хочу сделать что-то такое: Foo<int,2,3,4,5>

Ну и делай на здоровье :)

так, окей. Я вижу, что работает. Понимаю, что работает

но у меня не работает.... ладно, пойду дальше копать

но у меня не работает.... ладно, пойду дальше копать

Ну или кусок кода кидай побольше

сейчас, 1 момент. Кое-что проверю

https://godbolt.org/g/NGu7kc

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

да нет, всё ок.

Забавно, у чувака результаты "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

А, у него проц мощнее и данных поменьше! Тогда всё ок

https://godbolt.org/g/NGu7kc

Чет телефон мой тупит. Ты с С++17 компилишь?

Потому как иначе class вроде должен быть

Чет телефон мой тупит. Ты с С++17 компилишь?

не-не, я исправил уже ошибку. У меня значит в коде где-то в другом месте проблема

А, у него проц мощнее и данных поменьше! Тогда всё ок

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

Чет телефон мой тупит. Ты с С++17 компилишь?

Исправил https://godbolt.org/g/BeUzq8

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

Я вот тоже .

Исправил https://godbolt.org/g/BeUzq8

я быстрее)

Но ЗНАТАКИ говорят — ОНО ЖЕ Ф ЯДРЕ, ОНО КРУТОЕ, ОНО БЫСРТЕЕЕ... почему ?

если замапить кусок и потом с ним работать - да, быстрее. А если просто читать... какие-то неведомые мне вещи начинают работать что ли

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

Чтение через read как правило читает в оперативу а потом копирует в твой буфер Чтение через mmap читает просто в оперативу Экономия на memcpy

Ну, может оно читает большими блоками (не такими уж и), может оно ЛЕНИВО ЗАГРУЖАЕТ СТРАНИЦЫ — согласен. Но вот БЫСТРЕЕ с какого перепугу оно будет — совсем не ясно

Чтение через read как правило читает в оперативу а потом копирует в твой буфер Чтение через mmap читает просто в оперативу Экономия на memcpy

Это — экономия на спичках.

вы всё ещё про файлы? https://stackoverflow.com/a/17925143/864782

скорость чтения с диска — десятки микросекунд, памяти — нано.

Это — экономия на спичках.

Ну это от платформы зависит

Ну да, если там не SSD стоит, а ленточный накопитель, то ДАААА!

скорость чтения с диска — десятки микросекунд, памяти — нано.

Зависит от системы. Игоры критичны на чтение с лиска, например

Зависит от системы. Игоры критичны на чтение с лиска, например

?

mmap дает выигрыш при random seek read; при последовательном - выгода не должна быть большой

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

вы всё ещё про файлы? https://stackoverflow.com/a/17925143/864782

я упорный: если использовать MAP_HUGETLB для mmap, то будет чуть быстрее чем последний вариант :)

Это — экономия на спичках.

Это незаметно ускоряет, если происходит чтение страницы с диска, и ощутимо ускоряет, если работаете с уже подгруженной в оперативу страницей (например если этот файл кто-то недавно читал/писал)

Это незаметно ускоряет, если происходит чтение страницы с диска, и ощутимо ускоряет, если работаете с уже подгруженной в оперативу страницей (например если этот файл кто-то недавно читал/писал)

это понятно. Просто у нас разговор именно шёл про чтение с диска.

Это незаметно ускоряет, если происходит чтение страницы с диска, и ощутимо ускоряет, если работаете с уже подгруженной в оперативу страницей (например если этот файл кто-то недавно читал/писал)

при чтении через read() ОС точно так же пойдет в кеш, разве нет?

почему как только я делаю std::experimental::filesystem::path p = "/some/path" пишет ошибка: undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()' ?

почему как только я делаю std::experimental::filesystem::path p = "/some/path" пишет ошибка: undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()' ?

линокваться надо

линокваться надо

что?

https://stackoverflow.com/questions/33149878/experimentalfilesystem-linker-error

это только для experimental или всегда так будет?

https://stackoverflow.com/questions/33149878/experimentalfilesystem-linker-error

спасяб

я упорный: если использовать MAP_HUGETLB для mmap, то будет чуть быстрее чем последний вариант :)

Современные Линуха это делают автоматически. Нужно поэкспериментировать с MAP_POPULATE и перемерить на новых ядрах...

при чтении через read() ОС точно так же пойдет в кеш, разве нет?

Да, но из кеша ОС скопирует в пользовательских буфер, тоесть вызовет memcpy

Да, но из кеша ОС скопирует в пользовательских буфер, тоесть вызовет memcpy

А. Теперь понял мысль

как эти hugetlb включить то по нормальному?

а что значит по-нормальному?

ну у меня тут инвалиды аргументы

hugetlbfs надо монтировать?

или это просто в ядре должно быть включено?

ERROR: S client not available

в ядре

включено. дефолтное арчевое

в nr_hugepages надо писать?

MAP_POPULATE в два раза быстрее того варианта что с posix_fadvise на SO

надо проверить на большом кол-ве файлов. у меня как раз утилита для этого есть

Да, но из кеша ОС скопирует в пользовательских буфер, тоесть вызовет memcpy

Вообще-то и просто память смапировать можно. Ну так, чисто теоретицки... А скопировать только свисающие часть по краям границ страниц.

Вообще-то и просто память смапировать можно. Ну так, чисто теоретицки... А скопировать только свисающие часть по краям границ страниц.

так mmap это и делает...

Ну тогда вообще не понятно, в чём экономия.

Вообще-то и просто память смапировать можно. Ну так, чисто теоретицки... А скопировать только свисающие часть по краям границ страниц.

Можно, но для этого надо иметь куски памяти (в которые вы читаете), выровненные по размеру страницы. Это оч редко когда случается

Я ж говорю, что свисает — скопировать

Если маленькое будет — что так, что так, экономии нет. Если большое — большую часть перемапить, остальное скопировать. Тоже нет экономии. Ну это всё равно фантазии...Надо код ядра линука смотреть...

как при помощи CMake собрать инструмент, который использует библиотеку, у которой есть файл, который генерируется этим инструментом

как при помощи CMake собрать инструмент, который использует библиотеку, у которой есть файл, который генерируется этим инструментом

GLOB?

но в этом инструменте этот файл не используется

почти circular dependencies

а как же ты этот файл использовать хочешь?

ЯННП

смотрите, есть asc.exe

он генерирует cpp файл

окей

который линкуется с библиотекой

ок

которую использует asc.exe

имя тебе известно этого генерируемого файла?

но этот функционал этой библиотеки asc.exe не использует

имя тебе известно этого генерируемого файла?

+, кнчн

теперь понял

тогда в чём проблема его прилинковать этот сгенерированный файл?

или тебе нужно запускать генерацию во время работы cmake?

или тебе нужно запускать генерацию во время работы cmake?

+

ага, вот теперь понял

как собрать библиотеку без него, а потом с ним