Чисто теоретический вопрос

← →
nick-from © (2003-02-15 22:39) [0]

Есть алгоритм копирования директории (со всеми вложенными)
Он выполняется рекурсивно.
Если его распараллелить так чтоб для копирования каждой директории создавался свой поток, будет ли выйгрыш в скорости?
Вроде как-бы да (всетки паралельно ж), но в конечном итоге ведь работа идет с винтом, а не только в памяти; если запускать большое кол-во фоновых потоков копирования в том же windows comander - скорость копирования у них снижается, но ведь опять же, это мы не одну дирректорию копируем параллельно а разные.
Что кто скажет? Интересны ваши мнения

← →
Vitek (2003-02-15 22:58) [1]

Это сколько же потоков надо?! Будет много времени уходить только на переключения между потоками :)

← →
Anatoly Podgoretsky © (2003-02-15 23:14) [2]

Чисто теоретический вопрос
Будет серьезный проигрыш, винчестер медленное устройство

← →
nick-from © (2003-02-15 23:15) [3]

Тоже фактор :)

← →
jack128 © (2003-02-15 23:18) [4]

А заодно объясните каким образом многопоточность (на однопроц машине) увеличивает производительность?
Какая разница как будут выполняться 2 функции : одна за другой или параллельно - выполняются, то они на одном процессоре, так что суммарное время выполнения в обоих случаях одинаковое...

← →
Anatoly Podgoretsky © (2003-02-15 23:33) [5]

jack128 © (15.02.03 23:18)
Она уменьшает

← →
sniknik © (2003-02-15 23:34) [6]

jack128 © (15.02.03 23:18)
чаще всего ~98% времени проги не работают а чегото ожидают, ввода, клика, события ....., почему бы это время не занять? именно для этого потоки и нужны.

← →
SPeller © (2003-02-16 02:22) [7]

> А заодно объясните каким образом многопоточность (на однопроц
> машине) увеличивает производительность?

А вот таким образом, что один поток, выполняя одну функцию, не потребляет 100% процессорного времени, и поэтому невостребованное время можно отдать другому потоку на выплнение другой функции.

← →
SPeller © (2003-02-16 02:24) [8]

> А вот таким образом, что один поток, выполняя одну функцию,
> не потребляет 100% процессорного времени

Обратное было в Win16 и DOS. Тогда во время выполнения одной программы все остальные останавливались ожидая её завершения. Таким образом, зависшая программа вешала всю систему.

Я как-то был вынужден копировать файлы целыми директориями в связи с задачей. Так вот что интересно. Стандартная функция API CopyFile (или FileCopy, не помню...) работала удивительно медленно при большом количестве мелких файлов. Опыты проводились под NT4 (Server and workstations) в сети 100 Mbit. Обычное копированеие в Far-е шло намного быстрее. Погрузившись в проблему я обнаружил в Far-е опцию типа "использовать стандартную функуцию Win32 API при копировании файлов" (что-то в этом роде). Когда я включил этот флажок, Far стал копировать так же медленно, как моя программа. Любопытно, что мой напарник, работавший на С копировал файлы на великолепной скорости, сам не зная как, просто используя библиотеку cout самого С. Мне все это показалось крайне странным и я уже стал подумывать о функциях 16-разрядных (старых), которые есть в Win32 для совместимости...
Времени было крайне мало и я должен был срочно уехать из Москвы. Мы остановились на простом решении - я попросил напарника сделать dll на C, экспортирующую функцию копирования файла средствами cout, а я из дельфийской программы вызвал ее stdcall. Так мы тогда вышли из положения, тем более, что мы много написали тогда всяких dll на С и на Delphi и это не выглядело, как что-то особенное...
Но вопрос у меня так и остался. Почему обычная функция копирования файлов, являющаяся стандартной в Win32 API нас тогда так подвела при работе в сети?
Если кто знает ответ - я был бы весьма признателен...

использование потоков для операций поиска - будут одни тормоза
это если ты ищешь файлы например в сети(локальной) - то тогда можно подумать о потокаха для каждой шары

а поиск файлов на дисках происходит очень и очень быстро - и не надо никаких потоков - 2-5 с. и все нужные файлы на одном диске найдены, проверено.

Чисто теоретический вопрос Найти похожие ветки