The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Скорость: 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ообщить модератору

 Оглавление

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


1. "Скорость: pipe vs.queue"  
Сообщение от DeadMustdie email(??) 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 email 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 email(??) 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 email(??) 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 email(??) 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]




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру