Здравствуйте, Cyberax, Вы писали: C>Если у тебя туча файлов — такой трюк не проходит. Ну а если у тебя один большой файл — то проще, действительно, взять БД и не мучаться.
Так ведь это ж не индексер контента — это почтовый сервер. Никого не интересует, что у него унутре — куча файлов, одно хранилище, или несколько.
S>>Увы, мы ничего не знаем про то, какая была CУБД, какие были блобы, и каким кодом ты отдавал их по HTTP. C>PostgreSQL и Oracle. Код был самый тупой — проверяем права пользователя (один простой SQL-запрос), делаем запрос в хранилище по ID файла, получаем blob и отдаём по HTTP. Тупее некуда. Логи лайти смотрели? Сколько он отдает 304 Not Modified?
C>На самом деле, это весьма важный пункт. В Линуксе я реально могу использовать файловые системы с сотнями тысяч файлов в каталоге, и оно будет приемлимо работать. На Windows такое решение не будет работать вообще — сдохнет просто на простейших операциях, как ты ни бейся головой об стену. Это просто ещё одна разница между разными ОС.
Еще раз повторяю для тех, кто не читает: речь не идет про сравнение винды и линукса. Хочешь поговорить об этом — иди в КСВ и бейся там до упаду. Мы сравниваем "рукопашную" реализацию с "высокоабстрактной".
C>Кстати, тот же лайти элементарно прикрутился к файловой системе — там внутри всего стека сейчас получается поный zero-copy для данных. Ядро прямо из буффера файловой системы в сеть пакеты пихает. Стомегабитная сеть в результате засвечивается почти без видимой нагрузки на CPU. Это позволило на эти ноды воткнуть ещё и другую логику.
Ну, это не совсем то, что доктор прописал. К примеру, gzip компрессию так применить не получится а это может увеличить скорость отдачи (естественно, при использовании кэширования с zero-copy) еще серъезнее, чем просто zero-copy.
C>Такое сделать с БД — просто не получится. Если не организовать, конечно, файловый кэш для полученных из БД данных.
Смотря какая БД. Вон, команда SQL Server обещает получить производительность линейного чтения blob из БД сравнимой с голой файлухой. А это означает, что буфера db-client можно отдавать прямо в сокет, и результаты будут удивительными
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
Pzz>>А если так: для любой программы на языке высокого уровня существует эквиавалентная программа на ассемблере, которая работает не хуже? S>А вот для этого надо определиться, что значит "не хуже". И что значит "на ассемблере". Вот, к примеру, дотнет фреймворк — он на чём?
Мне нравится ход ваших мыслей. Вы ведь не будете утверждать, что фреймворк невозможно реализовать на ассемблере? Т.е., теорема существования доказана?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>А вот про матричную алгебру — это пожалуйста:
<местами skipped>
LCR>Скалярное умножение вектора-строки на вектор-столбец: LCR>Сложение матриц: LCR>Представьте себе, и это всё, да. В последний раз, когда я видел решение СЛАУ (моё) оно было минимум 5 экранов — и for-ы, for-ы, много for-ов... Выбор несколько других примитивов позволяет, даже в такой "цыкло-насыщенной" задаче, избежать явного применения оператора цикла. Казалось бы, согласно маэстро Дейкстре, основополагающего примитива.
Лет так 30 назад была такая система программирования Альфа, сделана была в Новосибирске Ершовым, поттосиным и др. На базе языка Алгол, но с расширениями. Так вот, там сложение матриц делалось еще проще
real array a[1:n][1:m],b[1:n][1:m], c[1:n][1:m];
// инициализация
c := a + b;
Проще некуда. И это во времена, когда ни о каком функциональном программировании и речи не было.
Но за эту простоту заплачено. В данном случае — куском компилятора, который разобрался, что эти массивы одинакового размера и создал код, который реализует это двойной цикл. В вашем примере — средствами иной системы. А в конечном счете их будет реализовать процессор P4, которому до матриц столько же дела, сколько мне до китайского языка .
Так что весь вопрос в цене этой платы — это раз, и в том, насколько хорошо это сделано — это два. Второе ИМХО выглядит так — если речь идет о чем-то стандартном, это может быть сделано очень хорошо, потому что писали реализацию грамотные люди. Но все стандартные задачи не переберешь, а когда что-то нестандартное потребуется, то будет уже и сложнее, и менее понятно, и менее эффективно. Это, кстати, хорошо демонстрируют приведенные примеры. По строкам и по столбцам (сложения, умножения) — очень ясно и просто, а что касается решения СЛАУ — не намного короче кода на С++. Не понял, кстати, для чего требуется 5 экранов для СЛАУ — ИМХО инвертирование матрицы по Гауссу-Жордану занимает строк 30-40. Не без циклов, правда. Но они и здесь есть — так же, как и в том примере сложения матриц, с которого я начал.
Здравствуйте, Sinclair, Вы писали:
S>А дальше начинаются вопросы практической применимости. Если ты писал свой алгоритм на ассемблере, а через полгода тебе заказчик сказал "опа, вышел новый процессор от Интел, мы будем гонять это на нём", то тебе останется только рвать растительность на различных частях тела.
Возьметесь ли вы утверждать, что чисто вычислительный код, например, криптографика или обработка изображений, могут выигрывать или хотя бы быть сравнимы с кодом, оптимизированным вручную с помощью более низкоуровнего инструмента?
А на невычислительных задачах это выжимание последнего такта никому нафиг не нужно. Все равно ждать придется окончания дисковой операции или приема/отправки пакета в сеть.
И не забывайте еще одно. Вот выйдет новый процессор Интел, а мелкософт скажет, что ему не интересно. И не будет его специальным образом поддерживать. Дворкин-то выматерится и руками все соптимизирует. А вы куда пойдете?
S>Я бы посмотрел на этого рыцаря меча и орала, если бы код был на ассемблере. Превратить массив в двумерный, и ввести вместо nHeight yStart и yEnd. А потом то же самое по диагонали.
А причем здесь? Павел не защищает ассемблер, а опровергает ваш тезис об однозначных преимуществах автоматической оптимизации перед ручной.
S>В итоге, у тебя очень хорошие шансы получить в итоге программу на ассемблере, которая уже не является оптимальной. Не потому, что ты ее плохо написал, а потому, что условия изменились. Твоя программа — бесполезна, ее надо оптимизировать заново. Развернутые циклы сворачивать, заинлайненный код выносить обратно, чтобы сократить длину цикла, менять выравнивание данных под новый размер линейки кэша.
Обычно нужна не программа, которая выжимает 100% из процессора, а программа, которая на разумном имеющемся железе успевает.
Если на новом процессоре ваша программа выжимает не 100% CPU, а лишь 30, но сам CPU в 4 раза быстрее старого, то задачу вы по-прежнему решили: ваша программа успевает и на старом, и на новом процессоре.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Проще некуда. И это во времена, когда ни о каком функциональном программировании и речи не было.
Ну чисто для справки: функциональное программирование придумано раньше Алгола. ЛИСП называется. Говорят, были очень хорошие оптимизирующие компиляторы лиспа, хотя в обычной реализации как правило ограничивались интерпретатором.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Лет так 30 назад была такая система программирования Альфа, сделана была в Новосибирске Ершовым, поттосиным и др. На базе языка Алгол, но с расширениями. Так вот, там сложение матриц делалось еще проще
PD>real array a[1:n][1:m],b[1:n][1:m], c[1:n][1:m]; PD>// инициализация
PD>c := a + b;
PD>Проще некуда. И это во времена, когда ни о каком функциональном программировании и речи не было.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А все же, может, не дожидаясь моего ответа , ответишь на мои вопросы, а ?
Нет.
PD> А то вы что-то оба с IT как будто сговорились, сначала требуете от меня, а сами даже сказать на словах не хотите
Мы с IT уже пмривели примеры кода в функциональном стиле и предложили тебе их повторить в императивном стиле. А ты все юлишь, как уж на сковородке.
>>А во-вторых, как напишешь императивный аналог алгоритма, что IT описал, ты сделаешь точно такое же как у IT описание своего собственного алгоритма, который ты хочешь увидеть в функциональной форме.
PD>Эту фразу я так и не смог понять. Если уж я напишу алгоритм, то зачем еще его описание ? Или ты комментарии к нему хочешь ?
Я хочу не кашу из звездочек и стрелочек, а вменяемое описание алгоритма.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Лет так 30 назад была такая система программирования Альфа, сделана была в Новосибирске Ершовым, поттосиным и др. На базе языка Алгол, но с расширениями. Так вот, там сложение матриц делалось еще проще
Уточняю. Не 30, а 40 (книга от 1968 года, можно, кстати, отметить — когда-то у нас компиляторы делали . Впрочем, Лиспу 50. Я просто не знал, что у него такой почтенный возраст.
S>Кстати, посмотрите кто статью переводил
Здравствуйте, Andrei F., Вы писали:
AF>Допустим, у нас есть некоторый GUI с деревом. Развесистым таким деревом, на 10^n элементов. И пользователь где-то в глубине иерархии поменял название одного элемента. Как это будет выглядеть в рамках ФП?
Здравствуйте, Andrei F., Вы писали:
AF>Допустим, у нас есть некоторый GUI с деревом. Развесистым таким деревом, на 10^n элементов. И пользователь где-то в глубине иерархии поменял название одного элемента. Как это будет выглядеть в рамках ФП?
Допустим, у нас есть некоторый компилятор с деревом (AST). Развесистым таким деревом, на 10^n элементов. И в процессе компиляции где-то в глубине иерархии поменяли тип одного элемента. Как это будет выглядеть в рамках ФП?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Pzz, Вы писали:
Pzz>Забудьте на секундочку о SQL-сервере как о продукте, готовом к употреблению. Я привожу его в качестве примера программы, которую тоже кто-то разрабатывает.
То есть ты признаешься в том, что сознательно уводишь от темы, так как Антон привел его именно в качестве примера продукта, готового к употреблению?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>К чьй реальности? К моей или к твоей? Или к некоей средневзвешенной реальности среди всех участников rsdn (которую лично я не имею наглости вычислять)?
Последнее. И не надо никакой наглости, чтобы предположить, что с решениями СЛАУ или вычислением детерминанта матрицы на практике встречается ничтожное количество разработчиков. Еще раз предлагаю глянуть на пример IT.
Но, это, ты можешь продолжать и дальше, если хочешь. Я просто намекнул на крайне низкую, по моему мнению, эффективность подобных примеров при объяснении преимуществ ФП для неподготовленных людей.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Pzz, Вы писали:
Pzz>А если так: для любой программы на языке высокого уровня существует эквиавалентная программа на ассемблере, которая работает не хуже?
Существует где? В воображении? Тогда запросто.
Бессмысленно выводить абстрактные теоремы, когда речь идет о практическом программировании.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>Продолжаю пояснять, несмотря на очевидные проблемы с восприятием. Вот то, что ты называешь "написать", это и есть "сформулировать".
. Теперь на игру понятий переведем.
S>Еще раз, на пальцах: пишешь ты add eax, [ebp+8]. Это означает: "нужно увеличить значение регистра EAX на значение, лежащее в четырех байтах памяти по такому-то адресу". Вот такая, значит, у нас формулировка решения некоторой задачи.
Спаси меня господи и помилуй и от такой формулировки задачи и от тех, кто так задачи формулирует. Похоже, они уже потеряли всякую человеческую сущность и полностью окомпьютеризировались. И поэтому их нужно не кормить, а просто включать в сеть 220В
S>Во-вторых, я ничего не обещал выжать из отдельной команды add. Я писал про то, что процессор выжимает максимум производительности из программы, сформулированной в терминах ассемблерных команд.
Ну что же, сравним
>Да, Павел, всё именно так плохо. Процессор пытается выжать максимум именно из add, mov и так далее.
PD>>Очень сильно похоже на ребенка, который узнал, откуда дети берутся и спешит сообщить своим друзьям по песочнице эту страшную тайну. Поверь, эта тайна — тайна только для тебя, всем остальным она давным-давно известна. В общем, почитай приличное руководство по архитектуре процессора, там есть и другие тайны, о которых можешь тоже всех оповестить S>Очень рад, что ты тоже читал руководство по архитектуре процессора (кстати, какого?). Жаль, что оно ничего не дало твоему развитию.
Ты по прежнему уверен, что таким способом тебе удастся что-то добиться в этой дискуссии ? Единственное, что ты демонстрируешь — это свое неумение вести ее. То у меня с восприятием что-то не так, то развитие не то, то про особо одаренных речь идет. Успокойся , вывести меня из себя тебе не удастся, хамством я не отвечаю, а аргументы такого рода лишь характеризуют соответствующим образом того, кто их употребляет. Я же все эти выпады просто сериализую в Гольфстрим
PD>>Ну и ну! Не вдаваясь в суть этого утверждения ( а оно совсем не верно, но объяснять почему просто нет времени), могу лишь сделать вывод — программист на асме глупый, а вот компилятор — умный, он видимо, такое делать не будет. Остается лишь ответить на вопрос, умные ли те, кто писал этот компилятор. S>Ну почему сразу "глупый"? С логикой проблемы? Поясняю еще раз, специально для альтернативно начитанных: программист на ассемблере не глупый. Просто он писал программу тогда, когда "руководства" еще и в помине не было. Откуда он мог знать, сколько будет конвееров?
Давай дальше, интересно, что еще будет. Еще одно открытие — программисты на ассемблере пишут без руководства, ясно.
PD>>А если серьезнее — почитай про penalty, про конвейеры, про рекомендации Intel, какие команды следует и в каком порядке выполнять, чтобы добиться наилучшего распараллеливания. VTune, наконец, загрузи и запусти, пусть она твою программу оценит. Может, перестанешь после этого нести ахинею насчет априорно глупых программистов на ассемблере. S>Павел, я всё это знаю. Какое отношение имеет VTune к интеллекту программистов?
Самое прямое. имеющие такой интеллект используют эту программу для нахождения своих не лучших решений. Не имеющие — не используют и подпадают под твои комментарии
PD>>В огороде бузина, а в Киеве дядька. Никто от процессора и не требует, чтобы он вдруг начал изображать собой твой любимый JIT и пытаться что-то понять. S>Он уже это делает. Внутри процессора как раз и работает микро-JIT, который превращает суперскалярные команды во внутренний микрокод, выполняющийся на RISC-ядре.
. Сравнил!
PD>>Не его это задача, а задача программиста на ассемблере — писать программу так, чтобы учесть специфику выполнения команд процессором. S>А мужики-то не знали!
Насчет мужиков — не знаю, а насчет рекомендаций Интел на этот счет для x86 — поищи, найдешь. У меня где-то дома книжка валялась.
PD>>И не только процессором, кстати, а еще и продумать, как доступ к ОП лучше организовать, чтобы не было проблем с кэшем и т.п. S>Ну так вот это — неразрешимая задача.
Угу. Вот сегодня я как раз в 2.5 раза повысил скорость работы, только за счет иного размещения в памяти, ничего в алгоритме не менял (и без ассемблера)Еще в 8 раз повысить — и все, задача решена.
>Чем быстрее ты это поймешь, тем лучше для твоих студентов.
Еще один выпад. Продолжай.
>Например, потому, что ты не знаешь заранее, какой именно будет кэш.
PD>>Устал я уже отвечать. Резюме твои высказываниям — компилятор умнее человека. Компилятор может такой код соорудить, что человек его соорудить не может. Остается только одно понять — кто же этот компилятор написал — сверхчеловеки? S>Совершенно неважно, кто написал компилятор. Компилятор не устает и не ошибается
Свершилось, господа — написана программа, которая не ошибается.
"О сколько нам открытий чудных
Готовит просвещенья дух"
особенно когда этот дух на тебя нисходит.
>у него нет проблем выполнить глобальные оптимизации
Это мы летом обсуждали, там выяснилось, как обстоят дела с глобальной оптимизацией
PD>>А то, что компилятор может сделать код лучше, чем средний программист на ассемблере — вполне мб и верно. Но я-то говорил про идеально написанную программу на ассемблере как некий теоретический предел, как теорему о существовании. S>Ты ее всё еще даже не попробовал толком сформулировать, не то что доказать.
Да зачем мне ее формулировать, если ты обещал мою программу сравнить и доказать, что она этому критерию не удовлетворяет. Критерий давай сюда, эталон, с которым сравнивать будешь!
PD>>Параллелить на одном ядре — это совершенно обычная практика, существующая уже лет так 30-40. S>Нерелевантный спам поскипан. Поясняю подробнее: я не имел в виду "параллелить ожидание", я имел в виду "параллелить задачу, которая полностью нагружает одно ядро". В частности, твоя числодробилка, приведенная в примере, явно даст худший результат, если запустить даже один лишний поток.
PD>>Ну и бери ее. Выкинь кусок без распараллеливаняи и бери второй. S>Отлично. Именно об этом я и говорил. Берем второй кусок, и что мы видим?
PD>>Как, кстати, ты этот предел вычислять собираешься, если не секрет Я готов попробовать доказать теорему о его существовании, а ты готов , видимо, дать прямо-таки методику его вычислкния ? . Давай сюда ее, обсудим S>Достаточно показать возможности по дальнейшей оптимизации. Понятно, почему?
Нет, давай критерий. Ты же мою программу хочешь сравнить, так что давай критерий, а не слова. Это я на слова имею право, если буду доказывать теорему о существовании — она по определению не говорит, как это найти. А ты готов программу сравнивать. Критерий давай!
S>Показываю, следим за руками: S>При запуске на 1 (одном) ядре, эта программа тратит X вычислительных ресурсов (временем я оперировать не буду, т.к. оно зависит много от чего еще). S>При этом непараллельная версия, которую ты привел, тратит X-delta ресурсов (например, потому что в ней нет WaitforMultipleObjects, нет динамического распределения памяти, да и вообще обращений к структурам chunk).
S>Значит, она заведомо хуже, чем теоретически достижимый предел.
Дай сначала определение ресурса (время тебя не устраивает, тогда что же это ?), тогда и поговорим. А пока это попытка доказать что-то с неопределенными утверждениями , используемыми для доказательства.
>Еще вопросы? Хочешь еще раз попробовать приблизиться к теоретическому пределу, или прямо сейчас сольешь?
Сливаешь именно ты. Но сдается мне, просто прикидываешься. Ну да все равно.
А кстати, как все же насчет распараллеливания на одном процессоре ? Ты по-прежнему готов похоронить всю вычмслительную технику или пусть она все же живет, вопреки твоим воззрениям ? Или просто лучше не отвечать, когда тебя поймали ?
Здравствуйте, Pzz, Вы писали:
Pzz>В линухе 2.4 нельзя было общаться с диском в обход системного кеша. В 2.6 стало можно.
Это исключительно проблемы линуха, и мне непонятно какое они имеют отношение к данному разговору.
Тем более, что речь шла о винде + MS SQL-е, где работать с диском в обход кеша можно было всегда и без особого напряжения.
Pzz> Факт в том, что SQL реализует весьма высокоуровневую штуку,
Именно. Мы взяли более высокоуровневую штуку и получили более эффективный результат — ЧТД.
Pzz>а пользоваться при реализации приходится уровнем абстракции даже более низким, чем то, с чем имеют дело обычные программы: не файлами, а блоками на диске.
Это уже детали реализации более высокоуровневой штуки, они не имеют никакого отношения к данному разговору.
Pzz>Плюс к этому самостоятельная реализация всей политики кеширования.
См. выше.
Pzz>Имеет. SQL-сервер это тоже программа.
Компилятор — тоже программа.
Pzz>Забудьте на секундочку о SQL-сервере как о продукте, готовом к употреблению. Я привожу его в качестве примера программы, которую тоже кто-то разрабатывает.
Компилятор тоже кто-то разрабатывает.
Pzz>Тем, что во-первых, файловую систему редко разносит до такого состояния, что ни одного файла нельзя отодрать.
Достаточно чтобы нелъзя было отодрать один.
Pzz>А во-вторых, есть миллион разных утилиток, позволяющих рассматривать файлы на файловой системе,
Данные в БД тоже.
Pzz> Либо не заводится, и тогда вам только остается сосать лапти.
Есть миллион утилит по восстановлению и обеспечению отказоустойчивости, с которыми никакая ФС не сравнится..
Здравствуйте, AndrewVK, Вы писали:
Pzz>>Забудьте на секундочку о SQL-сервере как о продукте, готовом к употреблению. Я привожу его в качестве примера программы, которую тоже кто-то разрабатывает.
AVK>То есть ты признаешься в том, что сознательно уводишь от темы, так как Антон привел его именно в качестве примера продукта, готового к употреблению?
А использование SQL-сервера в качестве примера готового продукта не может мирно сосуществовать с использованием его в качестве примера разрабатываемой программы?
Здравствуйте, IB, Вы писали:
Pzz>>В линухе 2.4 нельзя было общаться с диском в обход системного кеша. В 2.6 стало можно. IB>Это исключительно проблемы линуха, и мне непонятно какое они имеют отношение к данному разговору. IB>Тем более, что речь шла о винде + MS SQL-е, где работать с диском в обход кеша можно было всегда и без особого напряжения.
Pzz>Вплоть до использования своей собственной партиции, на которой нет никакой файловой системы.
Это официально не рекомендуемая экзотика, так что ""взрослые" SQL-сервера" как раз стараются работать поверх FS.
Если бы это было никому не нужно, зачем бы в линухе это стали делать?
Так же непонятно, с чего речь шла только о венде.
Pzz>> Факт в том, что SQL реализует весьма высокоуровневую штуку, IB>Именно. Мы взяли более высокоуровневую штуку и получили более эффективный результат — ЧТД.
Кто такие мы? Если для вас "мы" это те, кто пишет поделки на бейсике, а "они" — те, кто сделали бейсик, могу лишь посоветовать раздвинуть свои горизонты.
Pzz>>а пользоваться при реализации приходится уровнем абстракции даже более низким, чем то, с чем имеют дело обычные программы: не файлами, а блоками на диске. IB>Это уже детали реализации более высокоуровневой штуки, они не имеют никакого отношения к данному разговору.
Вы мне рассказываете, что есть такой слоистый мир, в котором программа на каждом уровне пользуется предыдущим слоем, а что ниже ее не касается.
Я вам привел пример программы, которая живет не так, как принято в рамках этого вашего слоистого мира. Вы ошибаетесь, если думаете, что эта программа — какое-то там особенное исключение.
Если после упоминания слова SQL у вас в голове случается короткое замыкание, и вы сразу начинаете мысленно выписывать SQL-запросы, могу только посочувствовать. Повторюсь еще раз, я использую SQL-сервер как пример программы, и обсуждаю использованное в ней архитектурное решение.
Pzz>>Плюс к этому самостоятельная реализация всей политики кеширования. IB>См. выше.
На что смотреть, простите?
Pzz>>Имеет. SQL-сервер это тоже программа. IB>Компилятор — тоже программа.
И что?
Pzz>>Забудьте на секундочку о SQL-сервере как о продукте, готовом к употреблению. Я привожу его в качестве примера программы, которую тоже кто-то разрабатывает. IB>Компилятор тоже кто-то разрабатывает.
Точно. И что?
Pzz>>Тем, что во-первых, файловую систему редко разносит до такого состояния, что ни одного файла нельзя отодрать. IB>Достаточно чтобы нелъзя было отодрать один.
Что лучше, потерять несколько писем, или потерять все письма?
Pzz>>А во-вторых, есть миллион разных утилиток, позволяющих рассматривать файлы на файловой системе, IB>Данные в БД тоже.
Они все упираются в одну — SDBM. Если она не работает с тем, что осталось от ваших данных, вам уже ничего не поможет.
Pzz>> Либо не заводится, и тогда вам только остается сосать лапти. IB>Есть миллион утилит по восстановлению и обеспечению отказоустойчивости, с которыми никакая ФС не сравнится..
Шансов восстановить, хотя бы частично, сломанную ФС значительно больше, чем восстановить аналогично поломаную БД. Уже потому, что у ФС структура значительно проще.
Потом поймите, я не призываю всех на свете использовать ФС в качестве базы данных. Я лишь объясняю, что этот подход имеет право на существование, и у него есть свои плюсы.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>А все же, может, не дожидаясь моего ответа , ответишь на мои вопросы, а ?
AVK>Нет.
Ну что же, все ясно. Ответ свой я дал в ответе IT.
PD>> А то вы что-то оба с IT как будто сговорились, сначала требуете от меня, а сами даже сказать на словах не хотите
AVK>Мы с IT уже пмривели примеры кода в функциональном стиле и предложили тебе их повторить в императивном стиле. А ты все юлишь, как уж на сковородке.
Еще раз (на этот раз тебе) объясняю — требовать от меня чего-либо ни ты, ни он не можешь. И не стоит бросаться словами и ярлыками — это бессмысленно.
PD>>Эту фразу я так и не смог понять. Если уж я напишу алгоритм, то зачем еще его описание ? Или ты комментарии к нему хочешь ?
AVK>Я хочу не кашу из звездочек и стрелочек, а вменяемое описание алгоритма.
Ну насчет каши — не нравится язык — дело твое. Я другой язык использовать не буду. А описание — мне казалось , что я его дал.
>поэтому я просто распараллелил вычисление сумм красных компонент по столбцам окна.
Если этого недостаточно — пожалуйста.
Дано окно Windows с неким рисунком в нем. Пройти по всем пиксельным столбцам клиентской области этого окна и найти для каждого столбца сумму R (красных) компонент пикселей , записать результаты в массив columnSum. Две реализации — в лоб без распараллеливания, и с распараллеливанием
Реализация в лоб — пройти и отсуммировать.
Реализация с распараллеливанием — создаются N потоков, где N — число процессоров (возвращает GetSystemInfo). Если процессоров 2, то один поток займется левой половиной окна, а другой правой. Если 3 — левой, средней и правой соответственно. И т.д.
GetPixel взята специально — она медленная, так что время получается такое, что его можно сравнивать.
Логи лайти смотрели? Сколько он отдает 304 Not Modified? 
а это может увеличить скорость отдачи (естественно, при использовании кэширования с zero-copy) еще серъезнее, чем просто zero-copy.
Мы уже победили, просто это еще не так заметно...
