Всем хорошего настроения!ОС Солярис9/10
Необходимо из одного потока в другой передавать большие объемы данных.
Что будет работать быстрее: pipe или multithreaded queue?
Очередью будет CAsyncQueue(glibc) или class my_queue : public std::queue.
Какие вижу недостатки:
1. pipe - файл.система работает медленнее памяти.
2. queue - тормоза из-за блокировки.Хоть это и паранойя =), хочется идеала. =)
Никакой "файловой системы" в варианте с pipe'ом задействовано не будет.
Однако блокировка никуда не исчезнет (просто будет неявной), и добавятся накладные
расходы на копирование данных в трубу и из трубы.IMHO при прочих равных очередь с блокировочкой будет шустрее. Если объем элемента
очереди солидный, и в очередь класть не весь элемент, а только указатель на него,
то - намного шустрее.
Такой вариант меня уже заинтересовал, тем более, что буфер у трубы, говорят, 2Кбайта.
P.S. Странной, что в boost нет многопоточной очереди.
>Такой вариант меня уже заинтересовал, тем более, что буфер у трубы, говорят,
>2Кбайта.буффер у трубы неопределенного размера!!! зависит от многих параметров...
>>Такой вариант меня уже заинтересовал, тем более, что буфер у трубы, говорят,
>>2Кбайта.
>
>буффер у трубы неопределенного размера!!! зависит от многих параметров...сам то сообразил что написал, то неопределенного, то зависит =)
вообще-то есть limits.h где есть константы по которым можно узнать текущие ограничения
ссылка на стандарт http://www.opengroup.org/onlinepubs/009695399/basedefs/limit...пример:
#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
В Солярисе есть вызов sendfile?Если да, то посмотрите его. Копирование между дескрипторами будет проходить на уровне ядра, без передачи в юзверьспейс.
>В Солярисе есть вызов sendfile?Yes
Может стоит попробывать передавать большие объемы данных между процессами через отображенную память?
mmap c MAP_SHARED во FreeBSD 6.2 SMP, по моим тестам, быстрее всего.
>
>Необходимо из одного потока в другой передавать большие объемы данных."Потока"? Они же в одном адресном пространстве...
Задача: грузить файл в БД.Хотел в одном потоке его читать, в другом писать в БД.
Оказалось, 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.П.С. Если кому нужна многопоточная очередь - пишите =). Мне больше не нужна =)
>Хотел в одном потоке его читать, в другом писать в БД.В принципе большого прироста производительности я бы здесь не ждал. Современные ОС
используют достаточно интеллектуальные механизмы read-ahead, и весьма велика вероятность,
что нужный (сиречь читаемый) блок на момент чтения уже окажется в кеше. То бишь
работу "потока-читателя" при последовательном чтении файла с успехом берет на себя ОС.>Оказалось, mmap работает быстрее, чем построчное считывание файла. Причем не зависит
>от числа файлов. Сам не понимаю как так.Естественно. Построчное считывание поверх фактического неявного mmap()а выполняет
дополнительно обработку (разбиение на строки) и копирование данных.>П.С. Если кому нужна многопоточная очередь - пишите =). Мне больше не
>нужна =)Еще пригодится. Не выбрасывайте. ;)
>>Оказалось, mmap работает быстрее, чем построчное считывание файла. Причем не зависит
>>от числа файлов. Сам не понимаю как так.
>
>Естественно. Построчное считывание поверх фактического неявного mmap()а выполняет
>дополнительно обработку (разбиение на строки) и копирование данных.Мне не понятно, почему mmap для одного и того же файла(10 Мбайт) работает одинаковое время один раз и сто. Время начинает расти после 10000.
"Расти" здесь субъективно. Как будто кэш.
>Мне не понятно, почему mmap для одного и того же файла(10 Мбайт)
>работает одинаковое время один раз и сто. Время начинает расти после
>10000.Не понял, о чем речь. Sample в студию, please.
>"Расти" здесь субъективно. Как будто кэш.
Кеш, естественно, есть. Если сто раз подряд прочитать не очень большой (10 Мбайт)
файл, то вряд ли (при отсутствии нехватки памяти) он будет физически прочитан
с диска более одного раза.
>
>Оказалось, mmap работает быстрее, чем построчное считывание файла.Зависит скорее всего от размеров и месторасположения буферов. Да и в случае mmap данные не гоняются лишний раз между буфером ядра и буфером в пространством пользователя (ведь так реализован mmap в современных системах, я ничего не путаю?). Так что вполне логично.