Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, krasin, Вы писали:

K>>Какая, говорите, пропускная способность у вашего винчестера?

ВВ>Обычный винт, Samsung SP0411N. Заметно медленее скажем популярной нынче Barracuda 7200.8.

Потому что у вас скорость передачи данных 133 Мб/с, а в тесте >80*3 = 240 Мб/с. Хотя это не имеет отношения к замеру скорости сравнения строк, явное несоответствие заявляемых данных действительным не клево.

Здравствуйте, krasin, Вы писали:

K>Потому что у вас скорость передачи данных 133 Мб/с, а в тесте >80*3 = 240 Мб/с. Хотя это не имеет отношения к замеру скорости сравнения строк, явное несоответствие заявляемых данных действительным не клево.

Я не скорость IO мерю. Ее мерять вообще бессмысленно, когда речь идет об алгоритмах поиска в строке. Объяснять почему?

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, komaz, Вы писали:

K>>Имхо ScanDirectory лучше сделать так:

ВВ>Чем лучше? Скорее всего это было бы куда медленнее..
Согласен, но на мой взгляд это было бы более похоже на ту многозадачность, которую хотели бы увидеть проверяющие.

Здравствуйте, komaz, Вы писали:

ВВ>>Чем лучше? Скорее всего это было бы куда медленнее..
K>Согласен, но на мой взгляд это было бы более похоже на ту многозадачность, которую хотели бы увидеть проверяющие.

Тогда уж надо очередь потоков делать. А то в теории на тысячу файлов получится тысяча потоков — тут никакой многопроцессорности не хватит.

Здравствуйте, trotski, Вы писали:

[skip]

T>Как все это сделать правильней и элегантней? Научите идиота.

А на чём завалился-то? Не работает что-то, или им хотелось что-то иного?

C Уважением, Andir!

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, GlebZ, Вы писали:

GZ>>Сомневаюсь что они имели ввиду просто открытие второго потока вначале. Скорее многопоточность касалась операции поиска значения.

ВВ>Это в принципе можно прикрутить с минимальными изменениями. Так как мы ищем не первый матч а все совпадения то процедуры поиска вообще друг от друга не зависят. Правда, смысла от такого распараллеливания будет ИМХО немного.

Более того, на нормальной однопроцессорной системе смысл будет в снижении быстродействия. Проц УЖЕ ищет значение. Не нада ему мешать созданием дополнительных нитей, которые, кстати, сожрут часть ресурсов просто фактом своего появления, еще даже не сделав ничего полезного. Проц все-равно не будет искать РЕАЛЬНО два значения паралелльно. Вместо того, что бы сосредоточить его на одной задаче мы заставим его переключаться между одной и той же задачей, но в разных потоках. Классический пример того, что самое сложное в многозадачности — это понимание того, что зачастую она ВРЕДНА и только изредка действительно полезна. Ну и уменее, конечно, отделять первые варианты от вторых. Что возможно даже важнее умения грамотно вторые варианты реализовывать.

Здравствуйте, Smarty, Вы писали:

S>Более того, на нормальной однопроцессорной системе смысл будет в снижении быстродействия. Проц УЖЕ ищет значение. Не нада ему мешать созданием дополнительных нитей, которые, кстати, сожрут часть ресурсов просто фактом своего появления, еще даже не сделав ничего полезного. Проц все-равно не будет искать РЕАЛЬНО два значения паралелльно. Вместо того, что бы сосредоточить его на одной задаче мы заставим его переключаться между одной и той же задачей, но в разных потоках. Классический пример того, что самое сложное в многозадачности — это понимание того, что зачастую она ВРЕДНА и только изредка действительно полезна. Ну и уменее, конечно, отделять первые варианты от вторых. Что возможно даже важнее умения грамотно вторые варианты реализовывать.
Не все так просто. Чтение с дисковых устройств происходит через DMA канал. Использование процессора при этом практически нулевое. В это время вполне можно заниматься чем нибудь полезным. За счет этого, даже на однопроцессорной машине для двух задач будет выйгрыш. Каков выйгрыш получится зависит от данных.

ВВ>Вариант из 5 строк прогоняется 200 тыс. раз.

Интересно сравнить QuickSort и пузерек таким образом. Почему-то мне кажется, что пузырек порвет

Здравствуйте, GlebZ, Вы писали:

GZ>Не все так просто. Чтение с дисковых устройств происходит через DMA канал. Использование процессора при этом практически нулевое. В это время вполне можно заниматься чем нибудь полезным. За счет этого, даже на однопроцессорной машине для двух задач будет выйгрыш. Каков выйгрыш получится зависит от данных.

Но так пардон — как выяснили выше(Вы же сами, кстати):

Скорее многопоточность касалась операции поиска значения.

Т.е. исходим из того, что данные УЖЕ в памяти и вот в этот момент проверяющие хотели зачем-то видеть стартующую многозадачность поиска. Вот исходя из этого я и писал свой мессаг... Кстати — о ДМА... это, конечно, уже чисто эмпирические рассуждения (т.е. строгое ИМХО), но представляется, что и в этом сценарии(допустим проверяющие на него намекали) с многозадачности можно поиметь "хоть шерсти клок" лишь в случае, если файл(каждый) будет размером метров 5, не меньше. И только если он сразу, целиком заливаться в память будет. При размерах файла 10-100 килограмм многозадачность опять в пролете — слишком мгновенно будут подгоняться новые данные.