forum.opennet.ru - "Скорость: pipe vs.queue" (14)

форумы

помощь

поиск

регистрация

майллист

ВХОД

слежка

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

Форумы Программирование под 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ообщить модератору

Оглавление

Скорость: pipe vs.queue, DeadMustdie, 12:57 , 17-Авг-07, (1)

Скорость: pipe vs.queue, dronord, 13:19 , 17-Авг-07, (2)

Скорость: pipe vs.queue, Ray Dudu, 11:40 , 20-Авг-07, (3)

Скорость: pipe vs.queue, vic, 12:54 , 20-Авг-07, (4)

Скорость: pipe vs.queue, Niam, 13:48 , 20-Авг-07, (5)

Скорость: pipe vs.queue, vic, 14:06 , 20-Авг-07, (6)

Скорость: pipe vs.queue, ws, 23:36 , 20-Авг-07, (7)

Скорость: pipe vs.queue, pahom, 18:36 , 07-Сен-07, (8)

Скорость: pipe vs.queue, Michelnok, 16:39 , 08-Сен-07, (9)

Скорость: pipe vs.queue, dronord, 11:08 , 11-Сен-07, (10)

Скорость: pipe vs.queue, DeadMustdie, 13:39 , 11-Сен-07, (11)

Скорость: pipe vs.queue, dronord, 14:57 , 11-Сен-07, (12)

Скорость: pipe vs.queue, DeadMustdie, 15:03 , 11-Сен-07, (13)

Скорость: pipe vs.queue, Michelnok, 17:33 , 11-Сен-07, (14)

Сообщения по теме [Сортировка по времени, 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]

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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]