Здравствуйте, Cyberax, Вы писали: C>А он работает с файлами на блоковом уровне, обходя почти все механизмы FS.
Поинт не в этом. Поинт в том, что нативной аппликухе тоже никто не мешает "работать с файлами на блоковом уровне".
К тому же эта работа, в общем-то, сводится к выставлению флагов запрета кэширования при открытии файла, и тупом выравнивании обращений по 8к и 64к границе. Тем не менее, "не получилось".
C>У меня вот прямо сейчас есть хранилище документов на Линуксе, которое пользователи мучают в особо извращённой форме. После перехода с блобов в базе данных на хранилище в файловой система производительность поднялась в 4 раза. После того, как для отдачи этих файлов я подключил lighttppd — производительность поднялась во столько раз, что даже мерить лень.
Увы, мы ничего не знаем про то, какая была CУБД, какие были блобы, и каким кодом ты отдавал их по HTTP.
C>Про сравнение производительности виндовых FS и линуксовых я тут как-то уже писал. Разница легко может быть в десятки раз, так что ничего удивительного.
Вообще-то я ничего не писал про сравнение производительности линукса и винды. Да, наверное в моем случае почтовик писали криворукие люди, а сиквел — пряморукие. В твоем случае получилось наоборот: СУБД писали криворукие, а файлуху и лайти — нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IT, Вы писали:
PD>>А теперь вопросы к тебе.
IT>Ты сначала сделай то, что тебя просили
Ну вот что, уважаемый IT. Давать мне задания и требовать их выполнения у тебя права нет. Я сделал то, что нашел нужным. Принципиально это мало чем отличается от того, что ты хочешь. У меня реальная работа есть, и ты ее за меня делать не будешь.
>и мы это обсудим
Ты уж прямо на себя функции верховного арбитра взял. Ты мол, сделай, а мы тут посмотрим и решим. Не слишком ли много на себя берешь ?
А ответов на мои вопросы нет. Ну хоть, если нет времени, напиши на словах, как будешь делать. Ну хоть не на все 5, хоть на 2-3 из них
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Тогда и к тебе те же вопросы, что я задал IT в
AVK>Сначала я подожду, когда ты приведешь то, что тебя просили. Это во-первых.
А все же, может, не дожидаясь моего ответа , ответишь на мои вопросы, а ? А то вы что-то оба с IT как будто сговорились, сначала требуете от меня, а сами даже сказать на словах не хотите, как будете делать. Я даже код не прошу — просто скажите. Ну что вам стоит . Хоть на 2-3 вопроса ответьте — вы же такие крутые специалисты
>А во-вторых, как напишешь императивный аналог алгоритма, что IT описал, ты сделаешь точно такое же как у IT описание своего собственного алгоритма, который ты хочешь увидеть в функциональной форме.
Эту фразу я так и не смог понять. Если уж я напишу алгоритм, то зачем еще его описание ? Или ты комментарии к нему хочешь ?
Здравствуйте, VladD2, Вы писали:
PD>>1. Приведи , где и когда я говорил, что я вижу код уже в оптимизированном виде. Ссылку! PD>>2. Приведи, где и когда я выступал против списков. Ссылку! PD>>3. Приведи, где и когда я выступал против использования функций. Ссылку! PD>>4. Приведи, где и когда я заявлял, что я все напишу в виде одного огромного for. Ссылку!
VD>Мне прийдется приводить все твои сообщения в которых речь идет об оптимизации. Собственно все твои рассуждения даже в этой ветке (вообще не имеющей отношения к оптимальности или оптимизациям) снова свелись к оптимизации. О чем еще можно говорить то?
Не надо все. Приведи по одной ссылке по каждому из 4 пунктов, перечисленных выше. Только найди, где я именно это говорил. Про списки, про функции и т.д. Можно даже не в этой ветки.
Здравствуйте, Pzz, Вы писали:
Pzz>Это очень неоднозначное утверждение. Можно ли, например, понимать его так: "разница в эффективности скомпилированного кода при включенной и выключенной оптимизации гораздо заметнее у декларативной программы, чем императивной. И она тем больше, чем ниже уровень императивной программы. В частности, для программ, написаных на ассемблере, эта разница практически не заметна"?
Не совсем, но уже ближе к истине.
А дальше начинаются вопросы практической применимости. Если ты писал свой алгоритм на ассемблере, а через полгода тебе заказчик сказал "опа, вышел новый процессор от Интел, мы будем гонять это на нём", то тебе останется только рвать растительность на различных частях тела. Вон неподалеку, Павел Дворкин в качестве аргумента в защиту ассемблера приводит
Напиши аналогичное со свои любимым AsParallel, только не вертикальными полосами, а прямоугольно-гнездовыми кусками. Мне, как понимаешь, это на пять минут работы — массив columnSum превратить в двумерный, а в CHUNK вместо nHeight ввести yStart, yEnd.
Я бы посмотрел на этого рыцаря меча и орала, если бы код был на ассемблере. Превратить массив в двумерный, и ввести вместо nHeight yStart и yEnd. А потом то же самое по диагонали.
В итоге, у тебя очень хорошие шансы получить в итоге программу на ассемблере, которая уже не является оптимальной. Не потому, что ты ее плохо написал, а потому, что условия изменились. Твоя программа — бесполезна, ее надо оптимизировать заново. Развернутые циклы сворачивать, заинлайненный код выносить обратно, чтобы сократить длину цикла, менять выравнивание данных под новый размер линейки кэша.
Хуже того: есть задачи, в которых заранее неизвестны условия исполнения. Максимум, что может себе позволить классическая ассемблерная программа — это сделать условный либо косвенный вызов в зависимости от некоего условия. Например, в зависимости от количества доступных ядер вызвать разные версии подпрограмм для расчета.
Современные процессоры даже постараются предсказать результат ветвления. Тем не менее, эта оптимизация никогда не порвет по производительности код, в котором уже заинлайнена версия, оптимальная для текущей ситуации.
Динамический инлайнинг в классическом ассемблере делать нельзя. Для того, чтобы он был возможен, нужен не целевой код, а специальным образом подготовленный. Что мы получаем? Правильно, получаем JIT (если это во время исполнения) или LTCG (если во время линковки).
Ну так это же как раз тот самый уровень абстракции, который мы полагали лишним! Парадокс? Или закономерность?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну вот что, уважаемый IT. Давать мне задания и требовать их выполнения у тебя права нет. Я сделал то, что нашел нужным. Принципиально это мало чем отличается от того, что ты хочешь. У меня реальная работа есть, и ты ее за меня делать не будешь.
Слив защитан. Другого я и не ожидал. Трындеть, оно понятно, не мешки таскать.
PD>Ты уж прямо на себя функции верховного арбитра взял. Ты мол, сделай, а мы тут посмотрим и решим. Не слишком ли много на себя берешь ?
Не много. Ты влез в это обсуждение со своим несогласным с другими мнением. Всё, что я прощу — это свои слова подкрепить делом. Приведённый мной код был написан за 20 минут для разъяснения моей позиции. Если я имею позиции и мнение, то я её стараюсь разъяснить и наглядно продемонстрировать. Тебе предлагается всего лишь сделать тоже самое — разъясниь и прдемонстрировать. Вместо этого ты приводишь какой-то левый код, задаёшь какие-то вопросы и ссылаешься на занятость. Думаешь это сильно доказывает твою правоту? Сначала приведи распараллеливание приведённого алгоритма, в нём нет ничего сложного (он, кстати, не только выражен в коде, но ещё и доступно описан на словах). Затем мы сравним его с двумя первыми реализациями, выявим достоинства и недостатки всех подходов. Ну, а потом, если у нас останутся непрояснённые моменты, мы попробуем ответить на твои вопросы.
PD>А ответов на мои вопросы нет.
Воспитанные люди не отвечают вопросами на вопросы.
PD>Ну хоть, если нет времени, напиши на словах, как будешь делать. Ну хоть не на все 5, хоть на 2-3 из них
Ты проценты распараллелил? Нет? Ну так иди параллель. До тех пор разговор окончен и своё особое мнение может написать на заборе. Или нашкрябать не сиденье в маршрутке.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Ну прикол-то в том, что если программа сформулирована в терминах mov, add, jmp и т.д, то простор для ее оптимизации крайне мал. PD>Ты когда-нибудь видел задачу, которая могла бы быть сформулирована в терминах mov, add, jmp и т.д ? Я таких задач в предметной области не встречал, разумееется, драйверы и прочие средства доступа к железу не в счет.
PD>На тебе банальную задачу умножения матриц и сформулируй ее в терминах mov, add, jmp и т.д. Подчеркиваю, сформулируй, а не напиши програму. А мы посмотрим, что из этого вышло
Повторяю специально для альтернативно одаренных: речь о том, в каких абстракциях сформулирована программа. А не исходную задачу.
>>Да, процессоры сейчас выжимают максимум из этого PD>Из чего они выжимают, ты что говоришь-то ? Из себя, что ли ? Или из своих собственных команд add. mov и т.д. ? Вот сижу и вижу — процессор пытается из самого себя выжать максимум. Меня это даже пугает немного — а вдруг чего-то выжмет
Да, Павел, всё именно так плохо. Процессор пытается выжать максимум именно из add, mov и так далее. Тебе вообще знакома хотя бы поверхностно архитектура современных процессоров? Термин "предсказание переходов" тебе что-нибудь говорит? Это как раз и есть попытка изменить стратегию исполнения ассемблерного кода так, чтобы увеличить throughput. Потому что формально любое ветвление обязано приводить к простою конвеера: на ассемблере ясно написано "пока не сравнишь содержимое EAX с EBX, непонятно куда переходить".
Далее, я тебе открою страшную тайну: реально никаких EAX и EBX в процессоре нету. Есть внутренние регистры, и маппинг "внешних" регистров на внутреннние определяется только в момент исполнения программы. Более того, процессор переупорядочивает команды для обеспечения лучшей производительности. Добро пожаловать в реальный мир, Павел.
Все эти трюки призваны исправить глупости, допущенные программистом ассемблера. Потому, что если бы он был умным, то он бы сам переупорядочил командны так, чтобы обеспечить максимальную микропараллельность. Вот только возможности процессора в этом ограничены.
>> но у них есть существенные ограничения как по ресурсам, которые можно на это потратить, так и по возможным действиям, которые они могут выполнить. PD>Это у процессоров ограничения по действиям, которые они могут выполнить ? Ну , кажется, приехали. У процессоров , значит, ограничения, а вот если на этих процессорах исполнять управляемый код со всеми наворотами, то эти ограничения куда-то исчезают и открываются у процессоров дополнительные возможности, так , что ли ? Ну и ну!
Совершенно верно. Для человека, который декларирует стремление к оптимальности, ты последовательно демонстрируешь потрясающую некомпетентность в вопросах оптимизации. На любом, причем, уровне. Поясняю еще раз: у процессора очень маленькое "окно просмотра кода", внутри которого он пытается понять намерения программиста, и обеспечить их выполнение с наилучшей производительностью. У него очень мало прав по внесению изменений в код, т.к. ему неясна семантика.
Вот простейший пример: ты пишешь код, вычисляющий сумму целых чисел в массиве. По какой-то причине на каждой итерации цикла ты выполняешь запись в определенную ячейку памяти.
Процессору совершенно непонятно, зачем ты это делаешь. То ли ты просто забыл, что можно использовать регистр, то ли есть другой поток, который наблюдает за этой ячейкой. В итоге, процессор честно выполняет обращение к памяти.
Если та же программа написана в терминах языка высокого уровня, типа того же С++, то по ней можно гораздо лучше понять, что именно происходит.
В частности, например, компилятор может выбрать хранение промежуточных результатов в регистре, потому что это эффективнее.
Далее, если процессор видит вызов в ассемблерном коде, он попытается предсказать переход и накормить конвейер. Но он не может выполнить инлайнинг кода, потому что у него нет такого права. А инлайнинг позволяет массу других оптимизаций. Тебе понятно, что сам по себе инлайнинг требует размеченного кода? Мы вроде уже обсуждали LTCG. Жаль, что ты ничего из этого не запомнил.
PD>Можно. Алгоритм всегда поменять можно, было бы на что менять. И доступ тоже поменять можно. И распараллелить. Поверь, все это вполне можно и без всяких управляемых сред. Это еще лет 20 назад умели и даже раньше.
Да-да. Я как бы в курсе.
S>>Более того, во многих задачах невозможно заранее предложить оптимальное решение в терминах mov, add, jmp и т.д.
PD>И неоптимальное тоже — см. выше, потому что так никто задачи не формулирует.
Еще раз повторяю для альтернативно одаренных: я говорю не о формулировке задачи, а о формулировке решения.
PD>И зря ты пытаешься доказать, что я это утверждаю. Я лишь одно утверждал — есть некий теоретический предел, им является идеально написанная программа на ассемблере. На любом языке с любыми средствами лучше сделать нельзя. При этом я вовсе не утверждаю, что знаю, как такую программу написать. Это лишь теорема о существовании. Но теорема верная. И из нее вовсе не следует, что программы надо писать на ассемблере.
Эта теорема неверна. Попробуй ее доказать
>>Просто потому, что еще нет информации о том, в каких условиях будет алгоритм выполняться.
PD>Если он на нетипичном процессоре или на иной архитектуре может выполняться — я со скрипом, но соглашусь. Потому что не знаю. что там хорошо, а что плохо. (В скобках : если буду знать — не соглашусь)
PD>Если же речь идет об обычной архитектуре, то не соглашусь. Windows NT-Vista, как тебе известно должно быть, написана так, что кроме HAL, все остальное от архитектуры не зависит. И работает она на x86, x64, а до этого были Alpha, MIPS, Power PC.
И почему ты думаешь, что Windows NT — это теоретический предел быстродействия???
>>Потому, что, к примеру, параллелить на 1 ядре — это гарантированная потеря производительности.
PD>Грандиозная мысль! Я бы сам никак не догадался . Но , к твоему сведению, узнать число процессоров через Win32 совсем не сложно. См. мой ответ IT с примером программы. PD>А вот до этого я не догадался. Я как-то до сих пор считал, что параллелить можно либо распараллеливаемые алгоритмы, либо массовые операции. А ты, похоже, дай тебе 4 ядра — возьмешься параллелить все, что угодно. Успехов >>А никакого способа автоматически трансформировать mov/add/jmp так, чтобы они были оптимальны для 1/2/4 ядер наука не знает. Зато знает способы делать это в том случае, если программа написана в декларативном стиле. PD>Посмотри мой пример. Там хоть и не mov и не add (опять борьба с ветряными мельницами), но вполне-таки распараллелено, и без всякого декларативного стиля. Без LINQ. Без интерфейсов. И даже (о ужас!) без классов. Кошмар просто
Павел, это даже смешно. Во-первых, твоя программа тупо делает два прохода: один в последовательном режиме, второй в параллельном.
Давай ты приведешь ту программу, которая просто старается сделать один проход, но как можно быстрее. В том числе и в зависимости от количества процессоров. И мы сразу убедимся, что теоретического предела она не достигает.
Во-вторых, Павел, ты же против лишнего уровня абстракции, так? Давай-ка, приведи код сразу на ассемблере; посмотрим, насколько он порвет высокоабстрактные плюсы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
AndrewVK,
LCR>>Не понял. Ты предлагаешь локальные бинды обзывать my_favourite_name. Или что? Если так, то это контрпродуктивно.
AVK>Я предлагаю использовать примеры, которые ближе к реальности, и писать их так, чтобы они не напоминали птичью тропку на снегу. Обсуждаемый тут пример IT как раз такой.
К чьй реальности? К моей или к твоей? Или к некоей средневзвешенной реальности среди всех участников rsdn (которую лично я не имею наглости вычислять)?
Допустим, у нас есть некоторый GUI с деревом. Развесистым таким деревом, на 10^n элементов. И пользователь где-то в глубине иерархии поменял название одного элемента. Как это будет выглядеть в рамках ФП?
Здравствуйте, geniepro, Вы писали:
FR>>Ну тогда и в Си есть ООП G>В этом случае понятие ООП уж слишком сильно размывается...
А не надо пытаться определять ООП через язык программирования.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
PD>>И зря ты пытаешься доказать, что я это утверждаю. Я лишь одно утверждал — есть некий теоретический предел, им является идеально написанная программа на ассемблере. На любом языке с любыми средствами лучше сделать нельзя. При этом я вовсе не утверждаю, что знаю, как такую программу написать. Это лишь теорема о существовании. Но теорема верная. И из нее вовсе не следует, что программы надо писать на ассемблере. S>Эта теорема неверна. Попробуй ее доказать
А если так: для любой программы на языке высокого уровня существует эквиавалентная программа на ассемблере, которая работает не хуже?
Здравствуйте, VladD2, Вы писали:
VD>Ага... эмуляция эмперативщины на функциональном языке эмулиуемом в императивной машине.
Влад, ну это ж уже сто раз обсасывалось.
кто-то пользует mutable для изменяемых переменных, а кто-то State и IO.
где-то mutable захардкоженый элемент языка, а где-то это сделано на основе патттерна который применяется еще многими способами.
Допустим на той же идеологии монад в f# сделали красивые асинхронные вычисления. И software transactional memory. В Немерле допустим это можно было бы организовать макросами. разные подходы просто.
А где что кому лучше... Оно вопрос из серии "на вкус и цвет фломастеры разные".
Здравствуйте, Sinclair, Вы писали:
S>Поинт не в этом. Поинт в том, что нативной аппликухе тоже никто не мешает "работать с файлами на блоковом уровне". S>К тому же эта работа, в общем-то, сводится к выставлению флагов запрета кэширования при открытии файла, и тупом выравнивании обращений по 8к и 64к границе. Тем не менее, "не получилось".
Нет. В NTFS тормозит сам по себе поиск и открытие файла. Скажи, как ты это собираешься оптимизировать? MSSQL это делать часто не надо — он один раз открыл хранилище и работает дальше с ним уже напрямую.
Если у тебя туча файлов — такой трюк не проходит. Ну а если у тебя один большой файл — то проще, действительно, взять БД и не мучаться.
C>>У меня вот прямо сейчас есть хранилище документов на Линуксе, которое пользователи мучают в особо извращённой форме. После перехода с блобов в базе данных на хранилище в файловой система производительность поднялась в 4 раза. После того, как для отдачи этих файлов я подключил lighttppd — производительность поднялась во столько раз, что даже мерить лень. S>Увы, мы ничего не знаем про то, какая была CУБД, какие были блобы, и каким кодом ты отдавал их по HTTP.
PostgreSQL и Oracle. Код был самый тупой — проверяем права пользователя (один простой SQL-запрос), делаем запрос в хранилище по ID файла, получаем blob и отдаём по HTTP. Тупее некуда.
C>>Про сравнение производительности виндовых FS и линуксовых я тут как-то уже писал. Разница легко может быть в десятки раз, так что ничего удивительного. S>Вообще-то я ничего не писал про сравнение производительности линукса и винды.
На самом деле, это весьма важный пункт. В Линуксе я реально могу использовать файловые системы с сотнями тысяч файлов в каталоге, и оно будет приемлимо работать. На Windows такое решение не будет работать вообще — сдохнет просто на простейших операциях, как ты ни бейся головой об стену. Это просто ещё одна разница между разными ОС.
S>Да, наверное в моем случае почтовик писали криворукие люди, а сиквел — пряморукие. В твоем случае получилось наоборот: СУБД писали криворукие, а файлуху и лайти — нет.
Ну то же самое и с файловыми системами в Линукс и Виндоус
Кстати, тот же лайти элементарно прикрутился к файловой системе — там внутри всего стека сейчас получается поный zero-copy для данных. Ядро прямо из буффера файловой системы в сеть пакеты пихает. Стомегабитная сеть в результате засвечивается почти без видимой нагрузки на CPU. Это позволило на эти ноды воткнуть ещё и другую логику.
Такое сделать с БД — просто не получится. Если не организовать, конечно, файловый кэш для полученных из БД данных.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>>>Ну прикол-то в том, что если программа сформулирована в терминах mov, add, jmp и т.д, то простор для ее оптимизации крайне мал. PD>>Ты когда-нибудь видел задачу, которая могла бы быть сформулирована в терминах mov, add, jmp и т.д ? Я таких задач в предметной области не встречал, разумееется, драйверы и прочие средства доступа к железу не в счет.
PD>>На тебе банальную задачу умножения матриц и сформулируй ее в терминах mov, add, jmp и т.д. Подчеркиваю, сформулируй, а не напиши програму. А мы посмотрим, что из этого вышло S>Повторяю специально для альтернативно одаренных: речь о том, в каких абстракциях сформулирована программа. А не исходную задачу.
А не может ли уважаемый сэр, хоть и допускающий невежливые высказывания (чтобы не сказать больше) пояснить, как это можно сформулировать хотя бы программу на уровне абстракций типа mov — jmp. Мне это все же кажется странным. Написать ее с применением mov, jmp — или if, for — это понятно, а вот сформулировать в абстракциях хоть тех, хоть других — нет. Формулируют обычно в абстракциях структур данных и алгоритмов, а уж потом кодируют с помощью mov или for. Это курсе так на 1-2 объясняют вообще-то.
S>Да, Павел, всё именно так плохо. Процессор пытается выжать максимум именно из add, mov и так далее. Тебе вообще знакома хотя бы поверхностно архитектура современных процессоров?
И даже очень неплохо.
>Термин "предсказание переходов" тебе что-нибудь говорит?
Примерно так лет 10 назад с ним ознакомился. При появлении Pentium
>Это как раз и есть попытка изменить стратегию исполнения ассемблерного кода так, чтобы увеличить throughput.Потому что формально любое ветвление обязано приводить к простою конвеера: на ассемблере ясно написано "пока не сравнишь содержимое EAX с EBX, непонятно куда переходить".
Батенька, не морочь людям голову и не путай божий дар с яичницей. Предсказание переходов, конвейер и внутренние регистры — это одно, а время выполнения команды add, взятой самой по себе, от конвейера и предсказания переходов не зависит. А ты обещал выжать что-то из самой add
S>Далее, я тебе открою страшную тайну: реально никаких EAX и EBX в процессоре нету.Есть внутренние регистры, и маппинг "внешних" регистров на внутреннние определяется только в момент исполнения программы. Более того, процессор переупорядочивает команды для обеспечения лучшей производительности. Добро пожаловать в реальный мир, Павел.
Очень сильно похоже на ребенка, который узнал, откуда дети берутся и спешит сообщить своим друзьям по песочнице эту страшную тайну. Поверь, эта тайна — тайна только для тебя, всем остальным она давным-давно известна. В общем, почитай приличное руководство по архитектуре процессора, там есть и другие тайны, о которых можешь тоже всех оповестить
S>Все эти трюки призваны исправить глупости, допущенные программистом ассемблера. Потому, что если бы он был умным, то он бы сам переупорядочил командны так, чтобы обеспечить максимальную микропараллельность. Вот только возможности процессора в этом ограничены.
Ну и ну! Не вдаваясь в суть этого утверждения ( а оно совсем не верно, но объяснять почему просто нет времени), могу лишь сделать вывод — программист на асме глупый, а вот компилятор — умный, он видимо, такое делать не будет. Остается лишь ответить на вопрос, умные ли те, кто писал этот компилятор.
А если серьезнее — почитай про penalty, про конвейеры, про рекомендации Intel, какие команды следует и в каком порядке выполнять, чтобы добиться наилучшего распараллеливания. VTune, наконец, загрузи и запусти, пусть она твою программу оценит. Может, перестанешь после этого нести ахинею насчет априорно глупых программистов на ассемблере.
>>> но у них есть существенные ограничения как по ресурсам, которые можно на это потратить, так и по возможным действиям, которые они могут выполнить. PD>>Это у процессоров ограничения по действиям, которые они могут выполнить ? Ну , кажется, приехали. У процессоров , значит, ограничения, а вот если на этих процессорах исполнять управляемый код со всеми наворотами, то эти ограничения куда-то исчезают и открываются у процессоров дополнительные возможности, так , что ли ? Ну и ну! S>Совершенно верно. Для человека, который декларирует стремление к оптимальности, ты последовательно демонстрируешь потрясающую некомпетентность в вопросах оптимизации. На любом, причем, уровне. Поясняю еще раз: у процессора очень маленькое "окно просмотра кода", внутри которого он пытается понять намерения программиста, и обеспечить их выполнение с наилучшей производительностью. У него очень мало прав по внесению изменений в код, т.к. ему неясна семантика.
В огороде бузина, а в Киеве дядька. Никто от процессора и не требует, чтобы он вдруг начал изображать собой твой любимый JIT и пытаться что-то понять. Не его это задача, а задача программиста на ассемблере — писать программу так, чтобы учесть специфику выполнения команд процессором. И не только процессором, кстати, а еще и продумать, как доступ к ОП лучше организовать, чтобы не было проблем с кэшем и т.п.
S>Вот простейший пример: ты пишешь код, вычисляющий сумму целых чисел в массиве. По какой-то причине на каждой итерации цикла ты выполняешь запись в определенную ячейку памяти. S>Процессору совершенно непонятно, зачем ты это делаешь. То ли ты просто забыл, что можно использовать регистр, то ли есть другой поток, который наблюдает за этой ячейкой. В итоге, процессор честно выполняет обращение к памяти.
А по какой, собственно , причине ты это делаешь (я это не делаю без надобности и про регисты не забываю — про все.). Причин две — либо твое неумение писать на ассемблере как следует, либо volatile. Второе вполне разумно, хотя и странно при сумировании, а если первое — иди учись.
S>Если та же программа написана в терминах языка высокого уровня, типа того же С++, то по ней можно гораздо лучше понять, что именно происходит.
Вот это верно.
S>В частности, например, компилятор может выбрать хранение промежуточных результатов в регистре, потому что это эффективнее.
И грамотный программист тоже. В общем, изобрел ты себе некий образ неграмотного программиста, не умеющего писать как следует на ассемблере и успешно с ним расправился. Бога ради, но какое это отношение к делу имеет ?
S>Далее, если процессор видит вызов в ассемблерном коде, он попытается предсказать переход и накормить конвейер. Но он не может выполнить инлайнинг кода, потому что у него нет такого права. А инлайнинг позволяет массу других оптимизаций. Тебе понятно, что сам по себе инлайнинг требует размеченного кода? Мы вроде уже обсуждали LTCG. Жаль, что ты ничего из этого не запомнил.
Устал я уже отвечать. Резюме твои высказываниям — компилятор умнее человека. Компилятор может такой код соорудить, что человек его соорудить не может. Остается только одно понять — кто же этот компилятор написал — сверхчеловеки ?
А то, что компилятор может сделать код лучше, чем средний программист на ассемблере — вполне мб и верно. Но я-то говорил про идеально написанную программу на ассемблере как некий теоретический предел, как теорему о существовании. А ты это понять не хочешь, а вместо это рассказываешь мне банальные истины под видом страшной тайны для маленьких детей.
S>>>Более того, во многих задачах невозможно заранее предложить оптимальное решение в терминах mov, add, jmp и т.д.
Все ясно. Человек не может, а вот компилятор может. Приехали.
PD>>И зря ты пытаешься доказать, что я это утверждаю. Я лишь одно утверждал — есть некий теоретический предел, им является идеально написанная программа на ассемблере. На любом языке с любыми средствами лучше сделать нельзя. При этом я вовсе не утверждаю, что знаю, как такую программу написать. Это лишь теорема о существовании. Но теорема верная. И из нее вовсе не следует, что программы надо писать на ассемблере. S>Эта теорема неверна. Попробуй ее доказать
Подумаю, сейчас нет времени.
>>>Просто потому, что еще нет информации о том, в каких условиях будет алгоритм выполняться.
PD>>Если он на нетипичном процессоре или на иной архитектуре может выполняться — я со скрипом, но соглашусь. Потому что не знаю. что там хорошо, а что плохо. (В скобках : если буду знать — не соглашусь)
PD>>Если же речь идет об обычной архитектуре, то не соглашусь. Windows NT-Vista, как тебе известно должно быть, написана так, что кроме HAL, все остальное от архитектуры не зависит. И работает она на x86, x64, а до этого были Alpha, MIPS, Power PC. S>И почему ты думаешь, что Windows NT — это теоретический предел быстродействия???
>>>Потому, что, к примеру, параллелить на 1 ядре — это гарантированная потеря производительности.
А вот на этот пункт я тебе вчера неверно ответил. Исправляюсь.
Параллелить на одном ядре — это совершенно обычная практика, существующая уже лет так 30-40. Тебе , видимо, просто неизвестны такие понятия как состояния потоков, переходы между этим состояниями, ожидание и т.д. И имея 10 потоков, каждый из которых по своему характеру может работать 10% времени, а 90% должен ожидать, скажем, завершения операции ввода-вывода, можно получить десятикратное (в пределе) ускорение работы при одном ядре. Это все азбучные истины, и их изучают на средних курсах института. Я студентам об этом в спецкурсе рассказываю. Приезжай, послушаешь
Да больше скажу — ты ведь своим высказыванием просто похоронил всю вычислительную технику, начиная с 60-х-70-х годов. Все мультпрограммирование похоронил — оно начиналось, когда о нескольких процессорах и речи не было. Windows похоронил — она внутри себя асинхронна и распараллелена. Зачем ей потоки, если при одном ядре параллелить — это гарантированная потеря производительности ?
Ты уж хоть думай следующий раз, прежде чем такое писать. И почитай хотя бы тут в форумах, это много раз обсуждалось в самых разных аспектах. А то решили — AsParallel и ура, пусть умный компилятор все остальное за нас сделает
S>Павел, это даже смешно. Во-первых, твоя программа тупо делает два прохода: один в последовательном режиме, второй в параллельном.
Ты хоть посмотри на нее как следует и почитай что я написал. Там есть тест без распараллеливания (для сравнения времени только) и тест, когда каждый поток берет себе 1/N работы, гдк N- число процессоров. И в обоих случаях один проход — по всем столбцам окна. Только в параллельном тесте это проход разделен на N частей.
S>Давай ты приведешь ту программу, которая просто старается сделать один проход, но как можно быстрее.
Что быстрее ? Пиксели с окна считывать ?
>В том числе и в зависимости от количества процессоров.
Ну и бери ее. Выкинь кусок без распараллеливаняи и бери второй.
>И мы сразу убедимся, что теоретического предела она не достигает.
Ну и аргументы!. Сначала IT меня подначил, требуя от меня доказать, что я умею писать распараллеливание. А теперь от меня требуют, чтобы этот простенький тест, написанный за 20 минут, выдал прямо-таки теоретический предел. Да еще с GetPixel внутри цикла . И подай мне эту программу, и мы все убедимся, что твоя программа не достигает теоретического предела .
Как, кстати, ты этот предел вычислять собираешься, если не секрет Я готов попробовать доказать теорему о его существовании, а ты готов , видимо, дать прямо-таки методику его вычислкния ? . Давай сюда ее, обсудим
S>Во-вторых, Павел, ты же против лишнего уровня абстракции, так? Давай-ка, приведи код сразу на ассемблере; посмотрим, насколько он порвет высокоабстрактные плюсы.
Это точно! Правильное замечание, с примесью демагогии, конечно, но правильное. Еще надо будет Windows выкинуть, вернуться к MS-DOS, напрямую читать из видеопамяти (думаю, не забыл еще , запретить все прерывания, оптимизировать донельзя код — вот тогда мы и получим этот самый теоретический предел
Забавно с вами спорить, господа (и не с тобой одним). Из кожи лезете вон, готовы всякую чепуху писать, противника в незнании элементарных вещей обвинять, передергивать, демагогией заниматься и т.д. — и все лишь ради одного — доказать, что мой Спартак — это круто, а ваше Динамо никуда не годится. А когда вам говорят — да, есть в Спартаке хорошие игроки, но в Динамо тоже есть — получаем в ответ — Спартак рулез, Динамо маст дай.
Здравствуйте, Pzz, Вы писали: Pzz>А если так: для любой программы на языке высокого уровня существует эквиавалентная программа на ассемблере, которая работает не хуже?
А вот для этого надо определиться, что значит "не хуже". И что значит "на ассемблере". Вот, к примеру, дотнет фреймворк — он на чём?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pzz, Вы писали:
Pzz>Если не ошибаюсь, именно Оракл протолкал поддержку "сырых" дисков в linux 2.6 (в 2.4 их не было). Вероятно, ребята из Оракла забыли почитать официальные рекомендации
Ага, чтобы хоть как-то оправдать наличие этих сырых дисков, пришлось поддержать их в ОС. Иначе вообще, не пришей кобыле хвост.
Pzz>А вы посмотрите на это не с точки зрения пользователя SQL-сервера, а с точки зрения его разработчика.
Зачем? Не о разработчиках сиквела речь. Преобразования из высокий абстракций в конкретные низкоуровневые реализации тоже кто-то пишет, они не святым байтом появляются.
Pzz>Казалось бы, ну зачем возиться со всем этим низкоуровневым доступом к диску, когда есть файловая система, которая все замечательно оптимизирует, да еще и автоматически. Ан нет, возятся.
В том-то и дело, что не возятся. Вся возня заключается в выставлении одного флага и выравнивании на границу страницы или экстента.
Опять-таки, даже если и возятся, к данному разговору это никакого отношения не имеет.
Pzz>SQL ващето это не только драйвер диска, но еще и реляционная алгебра.
И? Это как-то отменяет тезис о том, что уровень абстракции при работе с сиквелом выше, чем непосредственно с файловой системой? Как раз у этой самой алгебры уровень абстракции такой, что абстрактнее не придумаешь.
Pzz>Проще тем, что вот они письма, лежат на диске, каждое письмо в своем файле.
Ну вот они в табличке лежат, каждое в своей записи. Так чем проще-то?
Здравствуйте, VladD2, Вы писали:
N>>Единственный объективный индикатор профессионализма — это уровень зарплаты.
VD>Тогда те кто работают в США большие профессионалы чем те кто работает Москве. А те кто работает в Малых Васюках вообще ламеры.
Речь шла об "уровне", то есть некой относительной величине. Только вот не ясно, как её мерять.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А не может ли уважаемый сэр, хоть и допускающий невежливые высказывания (чтобы не сказать больше) пояснить, как это можно сформулировать хотя бы программу на уровне абстракций типа mov — jmp. PD>Мне это все же кажется странным. Написать ее с применением mov, jmp — или if, for — это понятно, а вот сформулировать в абстракциях хоть тех, хоть других — нет. Формулируют обычно в абстракциях структур данных и алгоритмов, а уж потом кодируют с помощью mov или for. Это курсе так на 1-2 объясняют вообще-то.
Продолжаю пояснять, несмотря на очевидные проблемы с восприятием. Вот то, что ты называешь "написать", это и есть "сформулировать".
Еще раз, на пальцах: пишешь ты add eax, [ebp+8]. Это означает: "нужно увеличить значение регистра EAX на значение, лежащее в четырех байтах памяти по такому-то адресу". Вот такая, значит, у нас формулировка решения некоторой задачи. Если подумать головой, то окажется, что это решение — не единственно возможное. На самом деле решение можно сформулировать как-то по-другому, так, чтобы в нём не фигурировали регистры и адреса. К примеру, "увеличить значение целочисленной переменной a на значение целочисленной переменной b". Это по-прежнему часть решения той же самой задачи, но уже немножко более высокоуровневое. Оно допускает несколько различных формулировок в терминах регистров и памяти, но все эти формулировки продолжают оставаться эквивалентными. Проблема в том, что у нас нет способа доказать эквивалентность этих формулировок, глядя в их ассемблерное представление. Значит, мы не можем выбрать из множества семантически эквивалентных решений то, которое получает наилучшую производительность.
Если мы поднимем голову повыше, то окажется, что и это решение не единственное; оно часть решения еще более общей задачи, например "найти сумму целых чисел в массиве". Для такой формулировки есть масса эквивалентных представлений в терминах переменных и присваиваний; это, очевидным образом, резко увеличивает пространство выбора для оптимизации. Всё еще понятно?
PD>И даже очень неплохо.
PD>Батенька, не морочь людям голову и не путай божий дар с яичницей. Предсказание переходов, конвейер и внутренние регистры — это одно, а время выполнения команды add, взятой самой по себе, от конвейера и предсказания переходов не зависит. А ты обещал выжать что-то из самой add
Продолжаю, несмотря на очевидные проблемы с восприятием. Во-первых, "время выполнения команды add" зависит от конвеера и внутренних регистров, и еще как. Саму по себе эту команду выполнить за 1 такт невозможно. Но процессор, грубо говоря, делает так, чтобы за 500 тактов выполнялось 500 команд add.
Во-вторых, я ничего не обещал выжать из отдельной команды add. Я писал про то, что процессор выжимает максимум производительности из программы, сформулированной в терминах ассемблерных команд. Кстати, это далеко не для всех процессоров справедливо. К примеру, итаниум возлагал эти задачи на компиляторы.
PD>Очень сильно похоже на ребенка, который узнал, откуда дети берутся и спешит сообщить своим друзьям по песочнице эту страшную тайну. Поверь, эта тайна — тайна только для тебя, всем остальным она давным-давно известна. В общем, почитай приличное руководство по архитектуре процессора, там есть и другие тайны, о которых можешь тоже всех оповестить
Очень рад, что ты тоже читал руководство по архитектуре процессора (кстати, какого?). Жаль, что оно ничего не дало твоему развитию.
PD>Ну и ну! Не вдаваясь в суть этого утверждения ( а оно совсем не верно, но объяснять почему просто нет времени), могу лишь сделать вывод — программист на асме глупый, а вот компилятор — умный, он видимо, такое делать не будет. Остается лишь ответить на вопрос, умные ли те, кто писал этот компилятор.
Ну почему сразу "глупый"? С логикой проблемы? Поясняю еще раз, специально для альтернативно начитанных: программист на ассемблере не глупый. Просто он писал программу тогда, когда "руководства" еще и в помине не было. Откуда он мог знать, сколько будет конвееров?
PD>А если серьезнее — почитай про penalty, про конвейеры, про рекомендации Intel, какие команды следует и в каком порядке выполнять, чтобы добиться наилучшего распараллеливания. VTune, наконец, загрузи и запусти, пусть она твою программу оценит. Может, перестанешь после этого нести ахинею насчет априорно глупых программистов на ассемблере.
Павел, я всё это знаю. Какое отношение имеет VTune к интеллекту программистов? Ты предлагаешь программу отдельно оптимизировать под каждый целевой процессор?
PD>В огороде бузина, а в Киеве дядька. Никто от процессора и не требует, чтобы он вдруг начал изображать собой твой любимый JIT и пытаться что-то понять.
Он уже это делает. Внутри процессора как раз и работает микро-JIT, который превращает суперскалярные команды во внутренний микрокод, выполняющийся на RISC-ядре.
PD>Не его это задача, а задача программиста на ассемблере — писать программу так, чтобы учесть специфику выполнения команд процессором.
А мужики-то не знали! То, о чем ты говоришь — это итаниумная архитектура; была похоронена, в частности, потому, что не получилось написать компилятор, достаточно умный для полного учета "специфики выполнения команд процессора". PD>И не только процессором, кстати, а еще и продумать, как доступ к ОП лучше организовать, чтобы не было проблем с кэшем и т.п.
Ну так вот это — неразрешимая задача. Чем быстрее ты это поймешь, тем лучше для твоих студентов. Например, потому, что ты не знаешь заранее, какой именно будет кэш.
PD>Устал я уже отвечать. Резюме твои высказываниям — компилятор умнее человека. Компилятор может такой код соорудить, что человек его соорудить не может. Остается только одно понять — кто же этот компилятор написал — сверхчеловеки?
Совершенно неважно, кто написал компилятор. Компилятор не устает и не ошибается; у него нет проблем выполнить глобальные оптимизации и точно посчитать соотношение количества экземпляров каждого из классов в системе. Программист — устает и ошибается. Кроме того, его знания о целевой системе быстро устаревают.
PD>А то, что компилятор может сделать код лучше, чем средний программист на ассемблере — вполне мб и верно. Но я-то говорил про идеально написанную программу на ассемблере как некий теоретический предел, как теорему о существовании.
Ты ее всё еще даже не попробовал толком сформулировать, не то что доказать.
PD>А ты это понять не хочешь, а вместо это рассказываешь мне банальные истины под видом страшной тайны для маленьких детей.
Я как раз всё прекрасно понимаю. А вот ты почему-то упорно не можешь понять то, что тебе пишу я. S>>>>Более того, во многих задачах невозможно заранее предложить оптимальное решение в терминах mov, add, jmp и т.д. PD>Все ясно. Человек не может, а вот компилятор может. Приехали.
Нет, просто управляемой среде не обязательно делать это заранее.
PD>Параллелить на одном ядре — это совершенно обычная практика, существующая уже лет так 30-40.
Нерелевантный спам поскипан. Поясняю подробнее: я не имел в виду "параллелить ожидание", я имел в виду "параллелить задачу, которая полностью нагружает одно ядро". В частности, твоя числодробилка, приведенная в примере, явно даст худший результат, если запустить даже один лишний поток.
PD>Ну и бери ее. Выкинь кусок без распараллеливаняи и бери второй.
Отлично. Именно об этом я и говорил. Берем второй кусок, и что мы видим?
PD>Как, кстати, ты этот предел вычислять собираешься, если не секрет Я готов попробовать доказать теорему о его существовании, а ты готов , видимо, дать прямо-таки методику его вычислкния ? . Давай сюда ее, обсудим
Достаточно показать возможности по дальнейшей оптимизации. Понятно, почему?
Показываю, следим за руками:
При запуске на 1 (одном) ядре, эта программа тратит X вычислительных ресурсов (временем я оперировать не буду, т.к. оно зависит много от чего еще).
При этом непараллельная версия, которую ты привел, тратит X-delta ресурсов (например, потому что в ней нет WaitforMultipleObjects, нет динамического распределения памяти, да и вообще обращений к структурам chunk).
Значит, она заведомо хуже, чем теоретически достижимый предел. Еще вопросы? Хочешь еще раз попробовать приблизиться к теоретическому пределу, или прямо сейчас сольешь?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ну вот что, уважаемый IT. Давать мне задания и требовать их выполнения у тебя права нет. Я сделал то, что нашел нужным. Принципиально это мало чем отличается от того, что ты хочешь. У меня реальная работа есть, и ты ее за меня делать не будешь.
IT>Слив защитан. Другого я и не ожидал. Трындеть, оно понятно, не мешки таскать.
Естественно, демагогией заниматься легче, чем ответить. Никакой принципиальной разницы в том, чтобы читать писксели и суммировать их в массиве или читать значения из коллекции и вычислять проценты, нет, и ты это сам прекрасно понимаешь. Не согласен — объясни, в чем разница — только принципиальная, а не по мелочам.
PD>>Ты уж прямо на себя функции верховного арбитра взял. Ты мол, сделай, а мы тут посмотрим и решим. Не слишком ли много на себя берешь ?
IT>Не много. Ты влез в это обсуждение со своим несогласным с другими мнением. Всё, что я прощу — это свои слова подкрепить делом. Приведённый мной код был написан за 20 минут для разъяснения моей позиции. Если я имею позиции и мнение, то я её стараюсь разъяснить и наглядно продемонстрировать. Тебе предлагается всего лишь сделать тоже самое — разъясниь и прдемонстрировать.
Я предложил свой код и продемонстрировал. Это мое право — предложить код, который я хочу для демонстрации. А вот права требовать, чтобы я делал то, что тебе хочется, у тебя нет. Можешь от своих подчиненных требовать, если они у тебя есть.
>Вместо этого ты приводишь какой-то левый код, задаёшь какие-то вопросы и ссылаешься на занятость.
Ну насчет того, чей код левый, а чей правый — опустим.
>Думаешь это сильно доказывает твою правоту? Сначала приведи распараллеливание приведённого алгоритма, в нём нет ничего сложного (он, кстати, не только выражен в коде, но ещё и доступно описан на словах). Затем мы сравним его с двумя первыми реализациями, выявим достоинства и недостатки всех подходов. Ну, а потом, если у нас останутся непрояснённые моменты, мы попробуем ответить на твои вопросы.
Ну надо же! Почти как господь бог — мы решим, правы вы или нет. А не допускаешь, что кто-то может и о вас такое же решить ?
PD>>А ответов на мои вопросы нет.
IT>Воспитанные люди не отвечают вопросами на вопросы.
Воспитанные люди не требуют от других, чтобы они писали программы по заказанному ими алгоритму. В лучшем случае просят, а получив отказ — принимают его как должное.
PD>>Ну хоть, если нет времени, напиши на словах, как будешь делать. Ну хоть не на все 5, хоть на 2-3 из них
IT>Ты проценты распараллелил? Нет? Ну так иди параллель. До тех пор разговор окончен и своё особое мнение может написать на заборе. Или нашкрябать не сиденье в маршрутке.
Да уж. Не помню, кто сказал — когда аргументов иных нет, остается только ругаться. Впрочем, если это очередная провокация — то не жди от меня неадекватной реакции. Я всегда остаюсь политкорретен, даже если приходится отвечать на такие вот "аргументы".
Ладно. Остальное не к тебе, а просто для сведения читающих. Поскольку ответа на мои вопросы нет, скажу сам.
Те пять вопросов, которые я задал, выбраны не случайно. Я вовсе не утверждаю, что в рамках .Net или LINQ на все из них нет ответов. На некоторые ИМХО нет, но я вовсе не специалист в LINQ, чтобы это утверждать точно. Их особенность в том, что нужно выполнить некоторое действие, которое требует не крупноблочного строительства, а тонкой настройки. Выбрать по строкам — хорошо, по столбцам — тоже (там пример есть, ссылку я выше по треду приводил), а вот квадратно-гнездовым — там же и объясняется, что параллелить по двум измерениям нельзя. Почти наверняка это можно как-то обойти, но это будет уже не так уж просто и совсем не очевидно. То же касается и диагоналей. И т.д. Вот и все. Пока стандартные действия — легко, просто и понятно, может быть, даже и эффективно (зависит от того, что там под спудом в этом AsParallel делается), а как только надо что-то нестандартное сделать — увы...
Здравствуйте, IB, Вы писали:
Pzz>>Если не ошибаюсь, именно Оракл протолкал поддержку "сырых" дисков в linux 2.6 (в 2.4 их не было). Вероятно, ребята из Оракла забыли почитать официальные рекомендации IB>Ага, чтобы хоть как-то оправдать наличие этих сырых дисков, пришлось поддержать их в ОС. Иначе вообще, не пришей кобыле хвост.
Я вообще не понял, что вы сказали. В линухе 2.4 нельзя было общаться с диском в обход системного кеша. В 2.6 стало можно. В других юниксах это было можно всегда, и этим базы данных пользовались. В линух добавили, чтобы можно было достичь высокой производительности.
Pzz>>А вы посмотрите на это не с точки зрения пользователя SQL-сервера, а с точки зрения его разработчика. IB>Зачем? Не о разработчиках сиквела речь. Преобразования из высокий абстракций в конкретные низкоуровневые реализации тоже кто-то пишет, они не святым байтом появляются.
Какая разница, о разработчиках чего идет речь? Факт в том, что SQL реализует весьма высокоуровневую штуку, а пользоваться при реализации приходится уровнем абстракции даже более низким, чем то, с чем имеют дело обычные программы: не файлами, а блоками на диске.
Вы же не будете утверждать, что SQL пишут небожители, а простому человеку это никогда не понадобится?
IB>В том-то и дело, что не возятся. Вся возня заключается в выставлении одного флага и выравнивании на границу страницы или экстента.
Плюс к этому самостоятельная реализация всей политики кеширования.
IB>Опять-таки, даже если и возятся, к данному разговору это никакого отношения не имеет.
Имеет. SQL-сервер это тоже программа.
Pzz>>SQL ващето это не только драйвер диска, но еще и реляционная алгебра. IB>И? Это как-то отменяет тезис о том, что уровень абстракции при работе с сиквелом выше, чем непосредственно с файловой системой? Как раз у этой самой алгебры уровень абстракции такой, что абстрактнее не придумаешь.
Забудьте на секундочку о SQL-сервере как о продукте, готовом к употреблению. Я привожу его в качестве примера программы, которую тоже кто-то разрабатывает.
Pzz>>Проще тем, что вот они письма, лежат на диске, каждое письмо в своем файле. IB>Ну вот они в табличке лежат, каждое в своей записи. Так чем проще-то?
Тем, что во-первых, файловую систему редко разносит до такого состояния, что ни одного файла нельзя отодрать. А во-вторых, есть миллион разных утилиток, позволяющих рассматривать файлы на файловой системе, даже на частично разрушенной файловой системе. А с базой, либо ваша SDBM заводится, и тогда у вас есть SELECT. Либо не заводится, и тогда вам только остается сосать лапти.
Если нам не помогут, то мы тоже никого не пощадим.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Мы уже победили, просто это еще не так заметно...
