| OberonCore https://forum.oberoncore.ru/ |
|
| Абстракция Files.File и её реализации https://forum.oberoncore.ru/viewtopic.php?f=23&t=4214 |
Страница 3 из 3 |
| Автор: | Пётр Кушнир [ Четверг, 17 Январь, 2013 22:34 ] |
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации |
Илья Ермаков писал(а): Пётр, возьмите книги Рихтера - там WinApi в плане работы с памятью и прочей системщиной отлично описано. Почитал. В любом случае, не хотелось бы велосипедить. |
|
| Автор: | ilovb [ Четверг, 17 Январь, 2013 23:13 ] | ||
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации | ||
Обсуждение размера буфера ("Эзотерика и Флуд"(c) Пётр Кушнир) уехало сюда: http://oberspace.dyndns.org/index.php/topic,431.0.html 2 Иван Денисов А MFiles из Оберона тебе не подойдет?
|
|||
| Автор: | Евгений Темиргалеев [ Пятница, 18 Январь, 2013 02:42 ] |
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации |
Удалены (п. 3.3) три оффтоп-сообщения (п. 2.3). |
|
| Автор: | Пётр Кушнир [ Четверг, 22 Август, 2013 21:47 ] |
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации |
Только что реализовал модуль, который предоставляет возможность записи в untagged массивы информации посредством интерфейса Files. В реализации я использовал известную схему с блочным выделением памяти, которая затем объединяется в общий массив. Эта схема, которую реализовал Иван Горячев в модуле StringsXml. Насколько я понял, это довольно эффективная схема. Переложив схему на untagged байтовые массивы, я реализовал динамический массив байтов, а затем над ним описал файловую абстракцию. При этом блоки untagged массивов кэшируются в локальном буфере и повторно используются для работы, при необходимости. Проделал я это для того, чтобы удобно хранить в памяти порядка 30 мегабайт информации (граф), которая после создания в обычном режиме начинала замедлять работу ББ в целом. Сейчас я написал тестовый бенчмарк, который показал странные вещи. Тест простейший - пишем сто мегабайт в файл, а затем читаем побайтово. Проведя этот тест на только что реализованных файлах в памяти, и на стандартной реализации файлов, записываемых на диск я обнаружил, что запись и чтение с диска проходят быстрее (для 100 мегабайт - примерно в два раза быстрее), чем для файлов в памяти. Возможно, я что-то сделал не так? Я рассчитывал на ускорение хотя бы на порядок. Очень странно. Причём, на скорость не влияет размер выделяемого блока памяти. А ещё, результат не зависит от того, выделяется ли блок памяти впервые, или же он выдаётся из буфера готовых блоков, такое впечатление, что упирается всё в скорость записи в память каждого байта. Исходные файлы можно взять в репе, модуль ypkObxDataBlob содержит бенчмарк. Если что, у меня SSD-диск, но не думаю, что он быстрее оперативной памяти  upd: проверил на обычном HDD, никакой разницы, запись/чтение ста мегабайт на диск в два раза быстрее записи в память. Неужели это настолько тяжелая операция для ядра ББ? 
|
|
| Автор: | ilovb [ Четверг, 22 Август, 2013 22:24 ] |
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации |
А что показывает профилировщик? ps Скомпилить не смог, т.к. после поиска и установки 2 отсутствующих подсистем у меня кончилось терпение |
|
| Автор: | Илья Ермаков [ Четверг, 22 Август, 2013 23:00 ] |
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации |
Попробуйте ДО бенчмарка сделать запись, а потом поставить writer на начало, начать бенчмаркать и записать поверх уже выделенной памяти ещё раз. Хотя бы поймёте, тратится время на первичное выделение - или на запись. А сколько мс выполняется тест? Если меньше 50, то вообще доверять нельзя - это погрешность измерения времени... Сделайте основной цикл, который делает рабочий тест раз 10 - когда будете оперировать с временами порядка тысяч мс, то уже можно сравнивать. Вообще, для чистоты надо использовать WinApi.GetThreadTimes - сколько потрачено процессорного времени вашим потоком. А по системному времени. Может, на ваш процесс за это время пришлось процентов 20... |
|
| Автор: | Пётр Кушнир [ Четверг, 22 Август, 2013 23:07 ] |
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации |
Сто мегабайт записываются три секунды в память и две секунды на диск. Код: в память 104857600 3.105
на диск 104857600 1.981 |
|
| Автор: | Пётр Кушнир [ Четверг, 22 Август, 2013 23:11 ] |
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации |
Илья Ермаков писал(а): Попробуйте ДО бенчмарка сделать запись, а потом поставить writer на начало, начать бенчмаркать и записать поверх уже выделенной памяти ещё раз. Хотя бы поймёте, тратится время на первичное выделение - или на запись. Это я проверил, когда настраивал размер выделяемого блока - начиная с какого-то размера блока время записи не изменялось (до второго знака после запятой) даже при повторном использовании блоков. |
|
| Автор: | Роман М. [ Четверг, 22 Август, 2013 23:21 ] |
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации |
Может, виноваты излишние движения блоков памяти туда-обратно? |
|
| Автор: | Пётр Кушнир [ Четверг, 22 Август, 2013 23:22 ] |
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации |
После изучения кода HostFiles я увидел, что там у записывателя есть простой буфер на статических массивах и рекордах. Поменяв у себя некоторые типы мне удалось примерно уравнять время записи в память и в обычный файл, десятые части секунды можно списать на более сложную структуру буфера. При этом тэг untagged никакого влияния на скорость не оказывает. Но это всё равно медленно. |
|
| Автор: | Илья Ермаков [ Четверг, 22 Август, 2013 23:57 ] |
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации |
На самом деле, у Вас тест c 100 миллионами WriteByte(..). Соответственно, Вы меряете цену 10 миллионов вызовов процедуры, помноженные на число внутренних вызовов и всякой кухни. А не скорость доступа к памяти. Потестируйте запись хотя бы блоками по 100 байт, через WriteBytes. |
|
| Автор: | Пётр Кушнир [ Пятница, 23 Август, 2013 00:30 ] |
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации |
В общем, ситуацию с побайтовой записью/чтением решить не удалось, слишком высокие накладные расходы на запись одного байта (но HostFiles всё равно быстрее за счёт статического буфера в самом записывателе). Опытным путём выяснил, что запись в память начинает себя оправдывать с точки зрения быстродействия при блочной записи с помощью копирования средствами SYSTEM. При этом untagged никак себя не проявляет, разве что её сборщик мусора не трогает. При этом, на тестовом объёме в гигабайт при оптимальном размере записываемого в процессе тестирования блока (4 килобайта) уже начинает оказывать влияние объём выделяемого блока. Цитата: размер записываемого блока записано байт в память, сек записано байт на диск, сек 8 104857600 0.468 104857600 0.655 64 104857600 0.109 104857600 0.328 512 104857600 0.047 104857600 0.296 4096 104857600 0.062 104857600 0.296 32768 104857600 0.062 104857600 0.281 262144 104857600 0.063 104857600 0.281 Эксперименты с RAM-диском в принципе подтверждают, что запись идёт с максимальной скоростью гигабайт в секунду. ББ может закидать гигабайт в выделенные структуры за 0,2 сек, но для их выделения в первый раз потребуется три секунды. Собственно, вся проблема заключалась в высоких накладных расходах для записывания байта информации напрямую в блок памяти. Получается, надо создать самые простейшие буферы в самих Reader/Writer, размером в 4 килобайта, и читать/писать по 4 килобайта сразу, а затем внутри этого простейшего буфера работать. По сути, повторить схему из HostFiles. Всё уже придумали за меня
|
|
| Автор: | ilovb [ Пятница, 23 Август, 2013 08:42 ] |
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации |
Это о реализации MFiles... |
|
| Автор: | Пётр Кушнир [ Пятница, 23 Август, 2013 10:30 ] |
| Заголовок сообщения: | Re: Абстракция Files.File и её реализации |
По результатам вчерашних экспериментов перенёс код бегунков из HostFiles с минимальными правками. Наверное, этот код со временем можно вообще выделить в отдельный модуль, раз уж он так хорошо проработан. |
|
| Страница 3 из 3 | Часовой пояс: UTC + 3 часа |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|
