форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Скорость: pipe vs.queue"

Сообщение от dronord (ok) on 17-Авг-07, 12:25

Всем хорошего настроения! ОС Солярис9/10 Необходимо из одного потока в другой передавать большие объемы данных. Что будет работать быстрее: pipe или multithreaded queue? Очередью будет CAsyncQueue(glibc) или class my_queue : public std::queue. Какие вижу недостатки: 1. pipe - файл.система работает медленнее памяти. 2. queue - тормоза из-за блокировки. Хоть это и паранойя =), хочется идеала. =)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Сообщения по теме

[Сортировка по времени, UBB]

1. "Скорость: pipe vs.queue"

Сообщение от DeadMustdie (??) on 17-Авг-07, 12:57

Никакой "файловой системы" в варианте с pipe'ом задействовано не будет. Однако блокировка никуда не исчезнет (просто будет неявной), и добавятся накладные расходы на копирование данных в трубу и из трубы. IMHO при прочих равных очередь с блокировочкой будет шустрее. Если объем элемента очереди солидный, и в очередь класть не весь элемент, а только указатель на него, то - намного шустрее.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "Скорость: pipe vs.queue"
	Сообщение от dronord (ok) on 17-Авг-07, 13:19
	Такой вариант меня уже заинтересовал, тем более, что буфер у трубы, говорят, 2Кбайта. P.S. Странной, что в boost нет многопоточной очереди.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Скорость: pipe vs.queue"
	Сообщение от Ray Dudu on 20-Авг-07, 11:40
	>Такой вариант меня уже заинтересовал, тем более, что буфер у трубы, говорят, >2Кбайта. буффер у трубы неопределенного размера!!! зависит от многих параметров...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Скорость: pipe vs.queue"
	Сообщение от vic (??) on 20-Авг-07, 12:54
	>>Такой вариант меня уже заинтересовал, тем более, что буфер у трубы, говорят, >>2Кбайта. > >буффер у трубы неопределенного размера!!! зависит от многих параметров... сам то сообразил что написал, то неопределенного, то зависит =) вообще-то есть limits.h где есть константы по которым можно узнать текущие ограничения ссылка на стандарт http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html пример: #include <iostream> #include <limits.h> int main() {     std::cout << "PIPE BUF MAX: "  << PIPE_BUF               << " PIPE BUF MIN: " << _POSIX_PIPE_BUF << std::endl;     return 0; } Результат для Fedora 4 (Linux 2.6.11) $ ./test PIPE BUF MAX: 4096 PIPE BUF MIN: 512
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Скорость: pipe vs.queue"
	Сообщение от Niam (??) on 20-Авг-07, 13:48
	В Солярисе есть вызов sendfile? Если да, то посмотрите его. Копирование между дескрипторами будет проходить на уровне ядра, без передачи в юзверьспейс.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Скорость: pipe vs.queue"
	Сообщение от vic (??) on 20-Авг-07, 14:06
	>В Солярисе есть вызов sendfile? Yes
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Скорость: pipe vs.queue"

Сообщение от ws (??) on 20-Авг-07, 23:36

Может стоит попробывать передавать большие объемы данных между процессами через отображенную память?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Скорость: pipe vs.queue"
	Сообщение от pahom on 07-Сен-07, 18:36
	mmap c MAP_SHARED во FreeBSD 6.2 SMP, по моим тестам, быстрее всего.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Скорость: pipe vs.queue"

Сообщение от Michelnok (ok) on 08-Сен-07, 16:39

> >Необходимо из одного потока в другой передавать большие объемы данных. "Потока"? Они же в одном адресном пространстве...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Скорость: pipe vs.queue"
	Сообщение от dronord (ok) on 11-Сен-07, 11:08
	Задача: грузить файл в БД. Хотел в одном потоке его читать, в другом писать в БД. Оказалось, mmap работает быстрее, чем построчное считывание файла. Причем не зависит от числа файлов. Сам не понимаю как так. П.С. Проводил различные тесты скорости считывания строк(std::string), способы отсортировал по возрастанию: 1. Thread Safe очередь с pthread_rwlock_t. При передаче указателей(std::string*) чууть быстрее. 2. Thread Safe очередь с pthread_mutex_t. С указателями в 1,5-2 раза быстрее. 3. Очередь msgget() (только указатели std::string*). 4. mmap && memncpy. П.С. Если кому нужна многопоточная очередь - пишите =). Мне больше не нужна =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Скорость: pipe vs.queue"
	Сообщение от DeadMustdie (??) on 11-Сен-07, 13:39
	>Хотел в одном потоке его читать, в другом писать в БД. В принципе большого прироста производительности я бы здесь не ждал. Современные ОС используют достаточно интеллектуальные механизмы read-ahead, и весьма велика вероятность, что нужный (сиречь читаемый) блок на момент чтения уже окажется в кеше. То бишь работу "потока-читателя" при последовательном чтении файла с успехом берет на себя ОС. >Оказалось, mmap работает быстрее, чем построчное считывание файла. Причем не зависит >от числа файлов. Сам не понимаю как так. Естественно. Построчное считывание поверх фактического неявного mmap()а выполняет дополнительно обработку (разбиение на строки) и копирование данных. >П.С. Если кому нужна многопоточная очередь - пишите =). Мне больше не >нужна =) Еще пригодится. Не выбрасывайте. ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Скорость: pipe vs.queue"
	Сообщение от dronord (ok) on 11-Сен-07, 14:57
	>>Оказалось, mmap работает быстрее, чем построчное считывание файла. Причем не зависит >>от числа файлов. Сам не понимаю как так. > >Естественно. Построчное считывание поверх фактического неявного mmap()а выполняет >дополнительно обработку (разбиение на строки) и копирование данных. Мне не понятно, почему mmap для одного и того же файла(10 Мбайт) работает одинаковое время один раз и сто. Время начинает расти после 10000. "Расти" здесь субъективно. Как будто кэш.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Скорость: pipe vs.queue"
	Сообщение от DeadMustdie (??) on 11-Сен-07, 15:03
	>Мне не понятно, почему mmap для одного и того же файла(10 Мбайт) >работает одинаковое время один раз и сто. Время начинает расти после >10000. Не понял, о чем речь. Sample в студию, please. >"Расти" здесь субъективно. Как будто кэш. Кеш, естественно, есть. Если сто раз подряд прочитать не очень большой (10 Мбайт) файл, то вряд ли (при отсутствии нехватки памяти) он будет физически прочитан с диска более одного раза.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Скорость: pipe vs.queue"
	Сообщение от Michelnok (ok) on 11-Сен-07, 17:33
	> >Оказалось, mmap работает быстрее, чем построчное считывание файла. Зависит скорее всего от размеров и месторасположения буферов. Да и в случае mmap данные не гоняются лишний раз между буфером ядра и буфером в пространством пользователя (ведь так реализован mmap в современных системах, я ничего не путаю?). Так что вполне логично.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]