Re[5]: а что насчет скорости?
От: Rtveliashvili Denys Великобритания  
Дата: 19.02.09 10:28
Оценка:
RD>>Я думаю она и так имеет смысл. Как я уже сказал, подозреваю что суммарное время выполнения word_server и db_server будет заметно больше, чем если бы был просто один процесс, что считает частоты, читая файл. Но раз эффективность не важна то и так сойдет.

D>Вы считаете что распараллеливание бессмысленно ибо тормозом является чтение из файла, как его ни делай, а не обработка слова?


Не совсем. Конечно, чтение файла обычно проходит медленно. Но если он в RAM, то достаточно быстро. Причем в обоих вариантах файл читается одинаково, так что это на разницу в скорости выполнения не влияет.

Если на время забыть про IO, то вот что получается:
1. ft разбивает список на сегменты, для каждого сегмента создается word_server
2. N word_server'ов создают "словари" и заполняют их данными на основе сегментов
3. word_server'а отдают результаты db_server'у и он собирает мегасловарь из результатов

Итого:
— словарей создается ~n
— операций со словарями в ft ~e
— операций со словарями в db_server ~n*l
— при этом создаются списки для сегментов, общая длина ~e

Здесь e — к-вло элементов, n — к-во сегментов [1;n], l = средняя длина словаря в word_server.

Предполагая, что создание словаря это не сильно дешевая операция, можно расчитывать на то, что при большом к-ве сегментов будет затык.
Более того, на больших сегментах для языков где к-во символов значительно меньше длины сегмента длина словарей в word_server будет лимитирована этим самым к-вом возможных символов. Что слегка уменьшает к-во элементарных операций на этапе подвода итогов.

Но теоретизировать мне не интересно. Я, как это не прискорбно, практик. Нет желания проверить вариант с большими сегментами — Ваше дело.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.