Здравствуйте, Mamut, Вы писали:
LCR>>>2. Копирование n файлов из каталога А в каталог Б. Файлы копируются по-одному, и пока не будет скопирован i-й файл, не начинается копирование i+1-го.
M>>А кто мешает копировать их параллельно? Или Вы думаете, что гарантированно выжмете всю пропускную способность файловой системы и при копировании одиночных файлов?
M>B вот бац — закончилось место на диске. И все три файла не скопировались. Абыдна, да
Проблема глупых файловых систем. У них также есть другая проблема: файлы будут фрагментироваться при таком копировании, смешиваться друг с другом, что тоже не всегда хорошо. А по-хорошему можно было бы резервировать место под весь файл заранее.
Правда, это не относится к теме: жесткий диск всё равно один, так что параллелить тут вредно.
Здравствуйте, eao197, Вы писали:
E>Значит 10 лет, это слишком мало.
А, ну что ж, будем ждать.
E>И, если уже брать мое личное мнение по данному вопросу, то я вообще не очень верю в то, что прозрачную распределенность могут дать системы построенные на основе RPC-механизмов (когда присутствие удаленного объекта в твоем процессе имитируется наличием объекта-заменителя и скрытыми от тебя сетевыми обменами). Большая прозрачность достигается при обмене сообщениями между самостоятельными объектами-сущностями (агентами).
Это на самом деле пофигу. В более менее тяжелых системах все равно слой коммуникаций относительно изолированный и небольшой. И в судодейственность SOA я не верю. Гора красивых слов и демагогии, а как доходит до практического применения получается один пшик.
Здравствуйте, AndrewVK, Вы писали:
E>>Значит 10 лет, это слишком мало.
AVK>А, ну что ж, будем ждать.
Да, поживем, увидим.
E>>И, если уже брать мое личное мнение по данному вопросу, то я вообще не очень верю в то, что прозрачную распределенность могут дать системы построенные на основе RPC-механизмов (когда присутствие удаленного объекта в твоем процессе имитируется наличием объекта-заменителя и скрытыми от тебя сетевыми обменами). Большая прозрачность достигается при обмене сообщениями между самостоятельными объектами-сущностями (агентами).
AVK>Это на самом деле пофигу. В более менее тяжелых системах все равно слой коммуникаций относительно изолированный и небольшой.
Не знаю, пофигу ли. В асинхронных сообщениях есть важная особенность -- неизвесно, когда оно дойдет и дойдет ли вообще. А это накладывает свою печать на разработку приложений, основанных на обмене сообщениями.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Mamut, Вы писали:
LCR>>>2. Копирование n файлов из каталога А в каталог Б. Файлы копируются по-одному, и пока не будет скопирован i-й файл, не начинается копирование i+1-го.
M>>А кто мешает копировать их параллельно? Или Вы думаете, что гарантированно выжмете всю пропускную способность файловой системы и при копировании одиночных файлов?
M>B вот бац — закончилось место на диске. И все три файла не скопировались. Абыдна, да
У нас в ауле перед копированием проверяют свободное место на диске и общий объем файлов. И вообще не копируют, если они не влезут. Или Вы думаете, что во всех случаях корректнее скопировать часть файлов, чем ничего?
Здравствуйте, mik1, Вы писали:
M>У нас в ауле перед копированием проверяют свободное место на диске и общий объем файлов. И вообще не копируют, если они не влезут. Или Вы думаете, что во всех случаях корректнее скопировать часть файлов, чем ничего?
У Вас в ауле замирает жизнь и все стоят, затаив дыхание, когда Вы начинаете копировать файлы?
Здравствуйте, AndrewVK, Вы писали:
E>>А это накладывает свою печать на разработку приложений, основанных на обмене сообщениями.
AVK>Ага, и печать называется куча гемороя.
Дык, а с другой стороны-то что?:
И в судодейственность SOA я не верю. Гора красивых слов и демагогии, а как доходит до практического применения получается один пшик.
Шило на мыло, однако
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, А почему вы спрашиваете, Вы писали:
M>>У нас в ауле перед копированием проверяют свободное место на диске и общий объем файлов. И вообще не копируют, если они не влезут. Или Вы думаете, что во всех случаях корректнее скопировать часть файлов, чем ничего?
Перед глазами возникла залитая солнцем горная местность и десяток джигитов, столпившихся вокруг ноутбука
АПВ>У Вас в ауле замирает жизнь и все стоят, затаив дыхание, когда Вы начинаете копировать файлы?
Я же сказал, по-хорошему надо сразу резервировать место под весь файл. Это должна быть фича операционной системы, которая помечает секторы как занятые и работает очень быстро. Тогда процессы, встревающие в середине копирования вашего файла не будут ничего фрагментировать.
Здравствуйте, Кодёнок, Вы писали:
Кё>Я же сказал, по-хорошему надо сразу резервировать место под весь файл. Это должна быть фича операционной системы, которая помечает секторы как занятые и работает очень быстро. Тогда процессы, встревающие в середине копирования вашего файла не будут ничего фрагментировать.
Это не всегда возможно. Например, "дырявый" файл занимает физически меньше чем логически.
Здравствуйте, А почему вы спрашиваете, Вы писали:
АПВ>Здравствуйте, mik1, Вы писали:
M>>У нас в ауле перед копированием проверяют свободное место на диске и общий объем файлов. И вообще не копируют, если они не влезут. Или Вы думаете, что во всех случаях корректнее скопировать часть файлов, чем ничего?
АПВ>У Вас в ауле замирает жизнь и все стоят, затаив дыхание, когда Вы начинаете копировать файлы?
Так и знал, что кто-нибудь спросит об этом. А ответ был выше:
Есть две стратегии копирования
1)когда нужно скопировать хоть что-то (например, когда кучу скачанного надо с работы домой тащить )
2)когда нужно скопировать все или ничего (например, при накате обновления программного обеспечения)
Параллельно копировать можно в обоих случаях. Но, в первом это надо делать не жадно (хотя, если свободного места на диске очень много — можно и жадно). Во втором — можно наплодить очень много потоков копирования. Ведь если сделать копию всех файлов не удасться — это приравнивается к неудаче и все наши файлы надо будет удалять с результирующего диска.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Кодёнок, Вы писали:
Кё>>Я же сказал, по-хорошему надо сразу резервировать место под весь файл. Это должна быть фича операционной системы, которая помечает секторы как занятые и работает очень быстро. Тогда процессы, встревающие в середине копирования вашего файла не будут ничего фрагментировать.
ANS>Это не всегда возможно. Например, "дырявый" файл занимает физически меньше чем логически.
Давным-давно слышал про поддержку sparse-файлов в NTFS. И ни разу не встречал приложений, использующих их. Подскажите, для расширения кругозора?
Здравствуйте, mik1, Вы писали:
M>Давным-давно слышал про поддержку sparse-файлов в NTFS. И ни разу не встречал приложений, использующих их. Подскажите, для расширения кругозора?
Не знаю на счет NTFS, но в юнихах "дырявые" файлы сплош и рядом. Замечу, что, afaik, в NTFS для этого нужны особые телодвижения, а в унихах "дырки" получаются "просто так".
Здравствуйте, mik1, Вы писали:
M>Параллельно копировать можно в обоих случаях. Но, в первом это надо делать не жадно (хотя, если свободного места на диске очень много — можно и жадно). Во втором — можно наплодить очень много потоков копирования. Ведь если сделать копию всех файлов не удасться — это приравнивается к неудаче и все наши файлы надо будет удалять с результирующего диска.
Просто имена к файлам нужно прилинковывать в конце по факту копирования.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, mik1, Вы писали:
M>>Параллельно копировать можно в обоих случаях. Но, в первом это надо делать не жадно (хотя, если свободного места на диске очень много — можно и жадно). Во втором — можно наплодить очень много потоков копирования. Ведь если сделать копию всех файлов не удасться — это приравнивается к неудаче и все наши файлы надо будет удалять с результирующего диска.
ANS>Просто имена к файлам нужно прилинковывать в конце по факту копирования.
Это как? В CreateFile ничего подобного не помню.
А *nix мне, к сожалению, менее интересен, так как пользователи, увы — в Выньдоуз.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну так добавление в очередь и есть запись указателей. Блокировка штука весьма дорогая и вполне сопоставима с временем работы лексера на тот же токен. Так что овчинка выделки не стоит. Можешь провести экспееримент. Я как то пробовал — получил 3% потерь на двухпроцессорной машине и 12% на однопроцессорной.
Во первых, относительно чего?
Во-вторых, примитивы синхронизации InterlockedXXXX, мягко говоря, слишком неудовлетворительный список. И вообще, лучше не говорить о реализации платформы, поскольку ее и спрогнозировать сложно.
GZ>>>>В каком смысле? Торможение на jmp на PIV подойдут? AVK>>>И что торможение на jmp? GZ>>http://www.x86.org/articles/branch/branchprediction.htm AVK>И? Какое это имеет отношение к твоему утверждению, что AVK>
В процах то же самое. Все зависит от предыдущего
А что переходы редкая операция? Не очень. Точно также в LL(1) есть последовательности токенов. Просто иногда синтаксис нормализуют до нормальной формы Хомского(или еще кого-то). AVK>jmp это единстванная команда PIV?
Нет. Но немаловажная.
AVK>>>Выполнение сразу нескольких веток ветвления. GZ>>thanks. Значит мы говорим об одном и том же(или о взаимосвязанных вещах). AVK>Не совсем. Ветвление это весьма простой случай зависимости. Оно, грубо говоря, либо произойдет либо нет. Но уже свитч под спекулятивное выполнение не попадает, не говоря уж о зависимости по данным.
Если брать аналогию с процессорами, то он в случае первого выполнения переходит по жесткому алгоритму. Во втором проходе, прогнозирует что переход произойдет в то же место. С другой стороны, тут стоит поговорить о гранулярности. Мы что будем выполнять параллельно, switch или подпрограммы. Функцию в функциональном языке типа Haskell или Clean распараллелить легко, так как там нет зависимости от глоб. данных. Но все равно, без помощи компилятора такое вряд ли возможно.
AVK>>>Это никак не отвечает на заданный вопрос. GZ>>На какой? То что мы можем в один момент мыслить только об одной вещи? AVK>Именно. GZ>> Но теперь задумайся, с помощью чего. Каждый нейрон является процессорам(причем не очень быстрый). AVK>Ни в коем разе. Практически ничего общего.
Отчего — же. Мы делаем одну задачу, но множеством процессоров. Нейрон — между прочим достаточно сложный процессор. И насколько я помню — дискретный. Что в этом такого? Нормальное поведение природы. Для нее не свойственны абстракции и сферические лошади в вакууме. Она учитывает все что есть в один момент времени.
Здравствуйте, mik1, Вы писали:
ANS>>Просто имена к файлам нужно прилинковывать в конце по факту копирования.
M>Это как? В CreateFile ничего подобного не помню.
Никак
M>А *nix мне, к сожалению, менее интересен, так как пользователи, увы — в Выньдоуз.
И в уних тоже никак. Хотя сама идея связана с особенностью работы унихов. Там при удалении файла через unlink (замечу, что это не удаление, а именно отцепление ссылки-имени) сам файл не удалится если на него будут ссылки. При том ссылкой будет считаться не только hard-link (другое имя), но и если файл открыт процессом. То есть, открытый файл можно "удалить", но открывший процесс этого не заметит. Физически файл будет удалён ОС после закрытия всех дескрипторов. И уже давно народ заприметил, что наряду с unlink полезно бы иметь и обратную опирацию, типа link. afaik, в текущих апи это невозможно, потому что нужна операция создания анонимного файла и операция прилинковки.
Здравствуйте, Sinclair, Вы писали:
GZ>>Спроси у Intel. Многоядерность с простыми RISC процами появилась, по моему, еще в первом пентюхе. S>Вообще-то распараллеливалка на уровне процессора дает не так уж много выигрыша, если только компилятор не делает предварительную работу. Фактически, он сообщает процессору, каким образом наиболее эффективно использовать несколько ALU над заданным кодом. Я более чем уверен, что значительное увеличение количества исполнительных блоков не даст выигрыша на произвольном линейном алгоритме, т.к. анализ зависимостей становится слишком сложным.
Как бы логично. Но вполне достаточно чтобы эффективно выполнять линейные программы. Но честно говоря — уже сейчас основное торможение идет на работе одновременной работе нескольких процессов. И в 90 процентов случаев мощность процессора для одного процесса избыточна.
Здравствуйте, Кодёнок, Вы писали:
Кё>Я же сказал, по-хорошему надо сразу резервировать место под весь файл. Это должна быть фича операционной системы, которая помечает секторы как занятые и работает очень быстро.
