Re: Скорость чтения с диска < последовательно одним процессом> VS < параллельно несколькими>
В Вто, 24/03/2009 в 11:04 +0300, Alexey Pechnikov пишет: > Hello! > > On Monday 23 March 2009 21:12:32 Покотиленко Костик wrote: > > Для меня остаётся 2 загадки, почему при использовании 2х ядер такой > > маленький прирост 22.3% скорости, почему при 4х потоках на 2х ядрах > > скорость всё ещё увеличивается. > > Судя по приведенным цифрам, вы файлы только считываете и результат никуда не > передаете. Стоит хотя бы в stdout из дочерних потоков выводить, а из > родительского забирать. Ситуация с чтением без обработки и вывода данных > весьма неестественна. Согласен, но меня на данном этапе интересует именно скорость чтения в разных ситуациях. -- Покотиленко Костик -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Скорость чтения с диска < последовательно одним процессом> VS < параллельно несколькими>
Hello! On Monday 23 March 2009 21:12:32 Покотиленко Костик wrote: > Для меня остаётся 2 загадки, почему при использовании 2х ядер такой > маленький прирост 22.3% скорости, почему при 4х потоках на 2х ядрах > скорость всё ещё увеличивается. Судя по приведенным цифрам, вы файлы только считываете и результат никуда не передаете. Стоит хотя бы в stdout из дочерних потоков выводить, а из родительского забирать. Ситуация с чтением без обработки и вывода данных весьма неестественна. Best regards.
Re: Скорость чтения с диска < последовательно одним процессом> VS < параллельно несколькими>
В Пнд, 23/03/2009 в 20:12 +0200, Покотиленко Костик пишет: > Проверяем чтение с использованием кэша (прокэшировано ~100%) на моем > каталоге /lib/modules: > > # du -sh /lib/modules > 365M/lib/modules > > Погонял несколько предварительный тестов пока прокэшировалось и скорость > стало показывать стабильно. > > Проверяем для одного потока: > > ./simreadtest /lib/modules -n 1 > ... > CHILD00: printing results: > files: 12890 > bytes: 340750735 > speed: 1893669821 bytes/sec > time usecs: 179942 > ... > > Получаем скорость: 1806Мб/с, время: 0.179942с > > > Проверяем для двух потоков: > > ./simreadtest /lib/modules -n 2 > ... > CHILD01: printing results: > files: 6445 > bytes: 163305639 > speed: 1485055735 bytes/sec > time usecs: 109966 > ... > CHILD00: printing results: > files: 6445 > bytes: 177445096 > speed: 1206182295 bytes/sec > time usecs: 147113 > ... > > Получаем суммарную скорость: 2209Мб/с, время: 0.147113с > > Итого: на моей машине 2 ядра, при использовании 2х потоков общая скорость > увеличилась на (2209-1806)/1806=22.3%, скорость на ядро уменьшилась на > (1806-2209/2)/1806=38.8% > > > Проверяем для четырёх потоков: > > ./simreadtest /lib/modules -n 4 > ... > CHILD04: printing results: > files: 2 > bytes: 1460 > speed: 42941176 bytes/sec > time usecs: 34 > ... > CHILD03: printing results: > files: 3222 > bytes: 85661152 > speed: 921097560 bytes/sec > time usecs: 92999 > ... > CHILD02: printing results: > files: 3222 > bytes: 77683236 > speed: 924283270 bytes/sec > time usecs: 84047 > ... > CHILD00: printing results: > files: 3222 > bytes: 95082054 > speed: 1469288303 bytes/sec > time usecs: 64713 > ... > CHILD01: printing results: > files: 3222 > bytes: 82322833 > speed: 704312249 bytes/sec > time usecs: 116884 > ... > > Получаем суммарную скорость: 2780Мб/с, время: 0.116884с > > Итого: на моей машине 2 ядра, при использовании 4х(5ти) потоков общая > скорость увеличилась на (2780-1806)/1806=53.9%, скорость на ядро уменьшилась > на (1806-2780/4)/1806=61.5% относительно одного потока. > > Вывод: При ~100% эффективности кэша скорость чтения растёт с увеличением > количества потоков даже превышающих количество реальных ядер, но растёт > сильно не линейно. > > > В Пнд, 23/03/2009 в 18:21 +0300, Alexey Pechnikov пишет: > > Hello! > > > > On Monday 23 March 2009 12:03:05 Покотиленко Костик wrote: > > > > http://meteor.dp.ua/reference/simreadtest/simreadtest-0.1.tar.gz > > > > http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.ods > > > > http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.pdf > > > > > > По ходу дела хочу отметить тот факт, что в этой рассылке процветает > > > демагогия, а когда дело доходит до дела... > > > > А где у вас дело? Есть стандартные паттерны использования диска, вы их даже > > не > > смотрели. > > Гляну позже. Если дашь ссылку, буду благодарен. > > > Средняя скорость чтения в 13 Мб/с это полная ерунда. Реально > > получается в разы быстрее. > > Для небольших непрокэшированных файлов это как раз та скорость. На > больших она приближается к скорости линейного чтения, той, что hdparm -t > показывает. > > > Почему - я отписался в предыдущем письме. Вы же, > > вместо того чтобы проверить, абсолютно ошибочно заявляете, что кэш не > > влияет > > на многопоточное чтение (хотя его в основном для многопоточного чтения и > > сделали). > > Что-то не помню чтобы я такое заявлял. Я говорил, что в тех тестах, > которые я делал, кэш оказался не эффективен. Напомню, что файлы читались > последовательно, каждый один раз. Суммарный объём в несколько раз больше > кэша, поэтому он был не эффективен. > > Напомню ещё, что изначально в этой теме речь шла о чтении с диска, может > я зря не дописал, но имелось в виду именно с диска, без кэша ФС. > > И, получается, да, я был не прав считая, что увеличение количества потоков > не увеличит скорость чтения при 100%-ой эффективности кэша. > Для меня остаётся 2 загадки, почему при использовании 2х ядер такой маленький > прирост 22.3% скорости, почему при 4х потоках на 2х ядрах скорость всё ещё > увеличивается. Кажется я их разгадал, для упрощения я не привёл времена стартов клонов, вот они: ... CHILD04: printing results: start time: 123782.955115 end time: 123782.955149 ... ... CHILD03: printing results: start time: 123782.955312 end time: 123783.48311 ... ... CHILD02: printing results: start time: 123782.979149 end time: 123783.63196 ... ... CHILD00: printing results: start time: 123783.48590 end time: 123783.113303 ... ... CHILD01: printing results: start time: 123783.4289 end time: 123783.121173 ... Очевидно, что клоны работали не совсем одновременно. При таких скоростях/объёмах это не правильный подход. Кэша/памяти у меня больше нет, поэтому, эти выводы можно считать не действительными, а я сделаю синхронизацию запуска и перемеряю потом. P.S. в start|end time после точки стоит время в микросекундах, там пропущены предшествующие
Re: Скорость чтения с диска < последовательно одним процессом> VS < параллельно несколькими>
Проверяем чтение с использованием кэша (прокэшировано ~100%) на моем каталоге /lib/modules: # du -sh /lib/modules 365M/lib/modules Погонял несколько предварительный тестов пока прокэшировалось и скорость стало показывать стабильно. Проверяем для одного потока: > ./simreadtest /lib/modules -n 1 ... CHILD00: printing results: files: 12890 bytes: 340750735 speed: 1893669821 bytes/sec time usecs: 179942 ... Получаем скорость: 1806Мб/с, время: 0.179942с Проверяем для двух потоков: > ./simreadtest /lib/modules -n 2 ... CHILD01: printing results: files: 6445 bytes: 163305639 speed: 1485055735 bytes/sec time usecs: 109966 ... CHILD00: printing results: files: 6445 bytes: 177445096 speed: 1206182295 bytes/sec time usecs: 147113 ... Получаем суммарную скорость: 2209Мб/с, время: 0.147113с Итого: на моей машине 2 ядра, при использовании 2х потоков общая скорость увеличилась на (2209-1806)/1806=22.3%, скорость на ядро уменьшилась на (1806-2209/2)/1806=38.8% Проверяем для четырёх потоков: > ./simreadtest /lib/modules -n 4 ... CHILD04: printing results: files: 2 bytes: 1460 speed: 42941176 bytes/sec time usecs: 34 ... CHILD03: printing results: files: 3222 bytes: 85661152 speed: 921097560 bytes/sec time usecs: 92999 ... CHILD02: printing results: files: 3222 bytes: 77683236 speed: 924283270 bytes/sec time usecs: 84047 ... CHILD00: printing results: files: 3222 bytes: 95082054 speed: 1469288303 bytes/sec time usecs: 64713 ... CHILD01: printing results: files: 3222 bytes: 82322833 speed: 704312249 bytes/sec time usecs: 116884 ... Получаем суммарную скорость: 2780Мб/с, время: 0.116884с Итого: на моей машине 2 ядра, при использовании 4х(5ти) потоков общая скорость увеличилась на (2780-1806)/1806=53.9%, скорость на ядро уменьшилась на (1806-2780/4)/1806=61.5% относительно одного потока. Вывод: При ~100% эффективности кэша скорость чтения растёт с увеличением количества потоков даже превышающих количество реальных ядер, но растёт сильно не линейно. В Пнд, 23/03/2009 в 18:21 +0300, Alexey Pechnikov пишет: > Hello! > > On Monday 23 March 2009 12:03:05 Покотиленко Костик wrote: > > > http://meteor.dp.ua/reference/simreadtest/simreadtest-0.1.tar.gz > > > http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.ods > > > http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.pdf > > > > По ходу дела хочу отметить тот факт, что в этой рассылке процветает > > демагогия, а когда дело доходит до дела... > > А где у вас дело? Есть стандартные паттерны использования диска, вы их даже > не > смотрели. Гляну позже. Если дашь ссылку, буду благодарен. > Средняя скорость чтения в 13 Мб/с это полная ерунда. Реально > получается в разы быстрее. Для небольших непрокэшированных файлов это как раз та скорость. На больших она приближается к скорости линейного чтения, той, что hdparm -t показывает. > Почему - я отписался в предыдущем письме. Вы же, > вместо того чтобы проверить, абсолютно ошибочно заявляете, что кэш не влияет > на многопоточное чтение (хотя его в основном для многопоточного чтения и > сделали). Что-то не помню чтобы я такое заявлял. Я говорил, что в тех тестах, которые я делал, кэш оказался не эффективен. Напомню, что файлы читались последовательно, каждый один раз. Суммарный объём в несколько раз больше кэша, поэтому он был не эффективен. Напомню ещё, что изначально в этой теме речь шла о чтении с диска, может я зря не дописал, но имелось в виду именно с диска, без кэша ФС. И, получается, да, я был не прав считая, что увеличение количества потоков не увеличит скорость чтения при 100%-ой эффективности кэша. Для меня остаётся 2 загадки, почему при использовании 2х ядер такой маленький прирост 22.3% скорости, почему при 4х потоках на 2х ядрах скорость всё ещё увеличивается. -- Покотиленко Костик -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Скорость чтения с диска < последовательно одним процессом> VS < параллельно несколькими>
Hello! On Monday 23 March 2009 12:03:05 Покотиленко Костик wrote: > > http://meteor.dp.ua/reference/simreadtest/simreadtest-0.1.tar.gz > > http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.ods > > http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.pdf > > По ходу дела хочу отметить тот факт, что в этой рассылке процветает > демагогия, а когда дело доходит до дела... А где у вас дело? Есть стандартные паттерны использования диска, вы их даже не смотрели. Средняя скорость чтения в 13 Мб/с это полная ерунда. Реально получается в разы быстрее. Почему - я отписался в предыдущем письме. Вы же, вместо того чтобы проверить, абсолютно ошибочно заявляете, что кэш не влияет на многопоточное чтение (хотя его в основном для многопоточного чтения и сделали). Best regards.
Re: Скорость чтения с диска < последовательно одним процессом> VS < параллельно несколькими>
В Суб, 21/03/2009 в 17:04 +0300, Alexey Pechnikov пишет: > Hello! > > On Friday 20 March 2009 13:02:27 Покотиленко Костик wrote: > > О тесте: программа рекурсивно сканирует указанный каталог и составляет > > список обычных файлов, затем делит этот список на N частей. Далее > > программа создаёт N клонов с помощью fork(), каждый из которых читает > > файлы из своей части списка. По окончанию работы каждого клона выводится > > его статистика. > > Необходимо оценить средний размер файла. Пусть это будет 8 кБ согласно > паттерну работы с БД. Примечание: если реальные файлы больше, но запросов > много, то с диска они все равно будут читаться блоками, кратно 4 кБ (по > дефолту для ext3). > > 1. Необходимо обращаться к рандомному файлу. Каждый поток должен работать с > полным списком, случайным образом выбирая файл для чтения. Примечание: если > вы > посмотрите паттерны доступа от интел, то увидите, что для моделирования > работы > с БД и файлсервера предполагается именно 100% рандомный доступ (в первом > приближении стоит начинать именно с этого варианта). Учет этого фактора > незначительно ускорит многопоточное чтение. > > 2. Необходимо учесть "популярность" файлов - большинство обращений происходит > к одним и тем же файлам. Используйте гауссово распределение. Учет этого > фактора значительно оптимизирует работу файлового кэша и многократно ускорит > многопоточное чтение (в зависимости от параметров распределения). Это будет > второе приближение. В случаях, когда кэш эффективен нет разницы параллельно читать или последовательно. -- Покотиленко Костик -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Скорость чтения с диска < последовательно одним процессом> VS < параллельно несколькими>
Hello! On Friday 20 March 2009 13:02:27 Покотиленко Костик wrote: > О тесте: программа рекурсивно сканирует указанный каталог и составляет > список обычных файлов, затем делит этот список на N частей. Далее > программа создаёт N клонов с помощью fork(), каждый из которых читает > файлы из своей части списка. По окончанию работы каждого клона выводится > его статистика. Необходимо оценить средний размер файла. Пусть это будет 8 кБ согласно паттерну работы с БД. Примечание: если реальные файлы больше, но запросов много, то с диска они все равно будут читаться блоками, кратно 4 кБ (по дефолту для ext3). 1. Необходимо обращаться к рандомному файлу. Каждый поток должен работать с полным списком, случайным образом выбирая файл для чтения. Примечание: если вы посмотрите паттерны доступа от интел, то увидите, что для моделирования работы с БД и файлсервера предполагается именно 100% рандомный доступ (в первом приближении стоит начинать именно с этого варианта). Учет этого фактора незначительно ускорит многопоточное чтение. 2. Необходимо учесть "популярность" файлов - большинство обращений происходит к одним и тем же файлам. Используйте гауссово распределение. Учет этого фактора значительно оптимизирует работу файлового кэша и многократно ускорит многопоточное чтение (в зависимости от параметров распределения). Это будет второе приближение. Best regards.
