?

Log in

No account? Create an account
   Journal    Friends    Archive    Profile    Memories
 

Программирование, очерк об утилитах и их разработке, в историческом разрезе - morfizm


Oct. 21st, 2017 05:57 am Программирование, очерк об утилитах и их разработке, в историческом разрезе57 comments - Leave a commentPrevious Entry Share Next Entry

Comments:

From:morfizm
Date:October 21st, 2017 10:29 pm (UTC)
(Link)
Ну, меньше секунды. Без startup-overhead'а там 0.6 сек выходило. У меня процессор 2 поколения core i7, память DDR3. Не знаю, насколько это "современно", но интуитивно. Я могу попробовать просто просуммировать все байты и посмотреть, сколько это займёт. Подозреваю, что полсекунды это overhead на перекачку данных из файлового кэша OS, и быстрее будет никак.

Насчёт буфера ты не прав. Позапускай бенчмарки и охуей от того, что 64kb даёт best perf на современном железе. Я и сейчас в этом убедился, и недавно на работе к такому же выводу пришёл. Подозреваю, что когда working set порядка 64kb, overhead от memory аллокаций не выходит за пределы L1/L2 кэша. Но это всего лишь догадка. Суть в том, что 8 мегабайт - плохой буфер, будет медленнее!
From:_m_e_
Date:October 21st, 2017 11:04 pm (UTC)
(Link)
Я гонял бенчмарки на вращающихся дисках, очистив дисковый кеш системы. В таких условиях 64к - смерть.
Может, когда весь файл прокеширован, ты и прав.
From:morfizm
Date:October 21st, 2017 11:06 pm (UTC)
(Link)
Диски да, там просто очень много можно успеть прочесть за один seek, куда больше, чем 64k.

В моих тестах 2x SSD in RAID-0 (800 MB/sec throughput with 64K blocks, 30K+ random iops), а на работе было скачивание объектов из S3. Т.е. network, RAM, без вращающихся дисков.

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

Edited at 2017-10-21 11:07 pm (UTC)
From:metaller
Date:October 22nd, 2017 02:37 am (UTC)
(Link)
Файловая система имеет свой собственный буфер, он уровнем ниже. Так что увеличение буфера в проге наверное не имеет смысла.
From:morfizm
Date:October 22nd, 2017 02:49 am (UTC)
(Link)
Read-ahead буфер вряд ли большой, так что в случае rotating drives большие буфера имеют смысл хотя бы тем, что винч знает, что ты собираешься много читать. Когда I/O queue depth = 1, следующая последовательная команда чтения заведомо пропускает один оборот диска, ты чутка не успел, а это тормозня.