| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Программирование под Unix/Linux > Асинхронный вывод - достижимо ли ускорение |
| Автор: marcusmae 24.1.2008, 15:20 |
| Всем привет, Изучаю, как можно было бы занять процессор полезной работой в то немаленькое число тактов, в которое он "занят" ожиданием появления результата на контроллере шины IDE. В стандарте Linux существует пакет POSIX AIO (asyncronious i/o), в котором есть функции aio_read и aio_write. Особенность в том, что возврат из них происходит сразу же после вызова, без ожидания результата операции, отложенная обработка которого может быть осуществлена по сигналу. На этот счёт вопрос : достижимо ли хоть какое-то ускорение работы приложения при использовании асинхронного вывода вместо обычного? Из тех тестов, что я провёл следует, что нет, не достижимо. Но, во-первых, я мог где-то и наляпать |
| Автор: GrayCardinal 24.1.2008, 18:07 | ||
Именно так. Тупо создаётся новый поток. Только в Linux'е. В других ОС, к примеру FreeBSD, на сколько знаю - сделано всё как надо... |
| Автор: GrayCardinal 24.1.2008, 20:04 |
| Ещё хочу добавить, что в NetBSD, OpenBSD aio_ отсутствует... http://nixdoc.net/man-pages/FreeBSD/?cmst=&cmsct=&cmsss=&cmss=2 (или я плохо смотрел ? ) |
| Автор: marcusmae 24.1.2008, 21:01 |
Я бы сказал, что приведённая Вами ссылка - вообще единственное место, где упоминается aio безотносительно выбора системы на левом фрейме Ну, на SuSE, кстати, libaio ставится отдельно. |
| Автор: MAKCim 24.1.2008, 21:13 | ||
Добавлено @ 21:17
да пример сервер + система логирования |
| Автор: marcusmae 24.1.2008, 21:36 |
| MAKCim, у меня тоже есть повод для оптимизма : я получил ускорение для Windows - мне это удобнее всего |
| Автор: MAKCim 24.1.2008, 21:57 |
| marcusmae, вопрос то в чем? |
| Автор: marcusmae 24.1.2008, 22:34 | ||||
| MAKCim, вопрос в том, что асинхронный вывод под OpenSuSE работает медленнее обычного вывода с блокировкой. Вот код с использованием aio_write :
А вот обычный вывод :
|
| Автор: MAKCim 24.1.2008, 22:42 |
| marcusmae, естественно, асинхронный I/O не в любом случае дает преимущества он оправдан, когда приходится читать или писать большие объемы данных, и этот процесс не должен снижать интерактивность больший выигрыш можно получить на MP-системе |
| Автор: marcusmae 24.1.2008, 22:50 | ||||
Сколько? У меня разом пишется 200мб на фоне ёмких вычислений. То есть, выводы не накладываются др на друга. Да и под виндовс ускоряется.
на многоядерной то есть? |
| Автор: MAKCim 24.1.2008, 23:02 | ||
на любой MP в том числе многоядерной
ну 200МБ это достаточно много а как ты скорость замерял? |
| Автор: marcusmae 24.1.2008, 23:16 | ||
На стороне теста (fortran) :
не самый лучший способ для экстремального тайминга : у этой функции не очень хорошее разрешение. Но значительные различия она улавливает. А многоядерность - всё же странное решение проблемы. Освобождая от тормозов, связанных с выводом одно ядро, это счастье просто прибывает другому ядру. |
| Автор: marcusmae 25.1.2008, 01:21 |
| GrayCardinal, я включил PCBSD. Вижу, поставить на него компиляторы Intel - целая проблема. Хотя, возможно, имея средство двоичной совместимости, можно попытаться запустить там уже готовые бинарники... |
| Автор: MAKCim 25.1.2008, 11:03 |
| marcusmae, разница в том, что уведомление о завершении операции асинхронного I/O приходит после физической записи данных на устройство если же использовать обычные операции write()/read() (без O_SYNC), то они возвращают управление после отправки пакета bio планировщику I/O, т. е до физической записи на устройство поэтому время работы асинхронных функций при таком способе измерения времени больше тем более у тебя в примере используется ofstream :: write(), который так же как и fwrite() буферизируем, т. е возврат управления может происходить еще раньше (нет обращения к ядру, а данные записываются в user-level буфер) я такого не говорил читай внимательнее MP - это способ повысить общее быстродействие приложения, использующее операции асинхронного I/O |
| Автор: marcusmae 25.1.2008, 12:26 | ||||||||
Да, более того, можно вообще обойтись без уведомления, если не заказывать получение сигнала.
Я конечно не знаток никсов, но что-то мне это кажется малоправдоподобным. А что, если, допустим, понадобится записать и тут же этот файл считать? Read ведь не выдаст отказ в доступе? Где-то можно прочитать об этом?
Нет, нелогично Я вот что думаю : может, какая-то тонкая настройка системы играет роль?
|
| Автор: MAKCim 25.1.2008, 12:49 | ||
для каждого файла в Linux существует кэш страниц, в которых кэшируются операции I/O при записи в файл модифицируется соответствующая страница (или страницы) его кэша далее, запрос на чтение будет удовлетворен из него (т. е из памяти) потоки ядра pdflush выполняют запись модифицированных страниц на диск т. е ты при использовании асинхронного I/O конечное время высчитываешь не после получения уведомления о завершении операции I/O |
| Автор: marcusmae 25.1.2008, 13:05 | ||||
MAKCim, спасибо за информацию! = К своему стыду я не слишком засиживаюсь за чтением книжек по внутреннему устройству Unix. Скажите, а есть ли способы настройки того процесса, что Вы описали?
Да. Меня в большей степени волнует, с какой скоростью будет работать программа. Впрочем, Вы правы, стоило бы засечь время от aio_write до SIG_AIO. |
| Автор: MAKCim 25.1.2008, 13:13 | ||||
вот естественно, инициализация aiocb и выполнение вызова aio_write() может занимать больше времени, нежели ofstream :: write() однако это вовсе не означает, что физическая запись на диск во втором случае будет осуществлена быстрее
какого плана настройки? |
| Автор: marcusmae 25.1.2008, 15:14 |
Ну вот CPU-bound и I/O-bound процессы? = О чём может идти речь? |
| Автор: MAKCim 25.1.2008, 17:19 | ||
это совсем из другой темы а именно, для более гибкой реализации стратегии планирования процессов |
| Автор: marcusmae 31.1.2008, 13:44 | ||
MAKCim, напрасно я переживал : на реальном SuSE (без виртуальной машины) всё оказалось лучше, чем я думал (графики присоединены). Остаётся маленькая проблемка, связанная с тем, что генерируемые в асинхронном варианте файлы получают ограниченные права на доступ. Наверно дело в этой строчке
http://ipicture.ru/Gallery/Viewfull/439764.html Маленькая поправка : Xeon всё-таки по-быстрее : 2,6 GHz. Теперь пробовать на реальных задачах |
| Автор: MAKCim 31.1.2008, 17:13 | ||||
угу нужно так
0666 - битовая маска прав в 8-ой СС подробнее man 2 chmod Добавлено через 2 минуты и 21 секунду
что же ты раньше не сказал, что на виртуальной машине тестировал? |
| Автор: marcusmae 31.1.2008, 19:00 |
спасибо! Нда, sorry, явно не сказал. Я расчитывал, она хоть динамику будет воспроизводить. Не тут-то было |