Да не вопрос Но мое мнение от этого не изменится
PD>Я бы так сказал — к некоторому множеству проектов. Поймите одну простую вещь — мир программирования не сводится ни к web-программированию, ни вообще к той его части, для которой Вы в предыдущем письме столь настойчиво проповедывали в общем-то, справедливые для этой части идеи. Мир большой, и в нем есть всякое — как то, что соответствует Вашим представлениям, так и то, что им безусловно противоречит. Ну а каково процентное соотношение этих частей — это не так уж важно. Сегодня оно одно, завтра другое, а послезавтра вообще что-то иначе будет
Понятно, что есть не Евклидовы пространства и там параллельные прямые имеют свойство пересекаться. Просто подходы проповедуемые вами — загубят почти любой боевой проект. Да есть ненулевое подмножество проектов, где подобные принципы могут быть чем-то оправданы. Но размеры его будут очень небольшие. А причины обоснованности этих подходов почти всегда будут нетехническими (вот только не надо опять про сэкономленные лицензии — цена этой экономии слишком уж большая).
Но тогда к вашим утверждениям сформулированном в самой начале этой темы нужно добавить эти ограничения накладываемые на проект. Причем не припиской мелким текстом в подвале темы, а в самом начале большими красными мигающими буквами. Потому что изначально они выглядели как указания к разработке стандартных проектов, чем они являться не могут в принципе. Собственно из-за этого противоречия тут великий срач и поднялся.
Здравствуйте, Кэр, Вы писали:
Кэр>Понятно, что есть не Евклидовы пространства и там параллельные прямые имеют свойство пересекаться. Просто подходы проповедуемые вами — загубят почти любой боевой проект.
Из того множества проектов, о которых Вы так печетесь — может и да. Может, и нет. Но почему Вы решили, что я проповедую свой подход именно для них ?
>Да есть ненулевое подмножество проектов, где подобные принципы могут быть чем-то оправданы. Но размеры его будут очень небольшие.
Еще раз — не стоит в процентах измерять эти множества. Это как грибы — чтобы наполнить корзину, хватит десятка белых, а опят понадобятся сотни.
>А причины обоснованности этих подходов почти всегда будут нетехническими (вот только не надо опять про сэкономленные лицензии — цена этой экономии слишком уж большая).
Не знаю, какие там нетехнические причины, и чем отличаются технические от нетехнических, но причины были и есть.
Кэр>Но тогда к вашим утверждениям сформулированном в самой начале этой темы нужно добавить эти ограничения накладываемые на проект.
А я же и так не раз говорил — есть разные задачи, и для них разные принципы.
>Причем не припиской мелким текстом в подвале темы,
Мелким текстом — это как ? Я вообще-то размерами шрифта здесь не балуюсь
>а в самом начале большими красными мигающими буквами. Потому что изначально они выглядели как указания к разработке стандартных проектов
Здравствуйте, Cyberax, Вы писали:
C>В нём мало смысла просто. На карте-то выполняется небезопасный код.
Не понял проблемы. На CPU тоже выполняется "небезопасный код". Просто он порождается из безопасного, благодаря чему всё становится здорово. Не вижу никаких причин не применить это для КУДЫ.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>У меня никаких проблем нет, а требование максимальной скорости выдвинуто заказчиком, с которым я работаю почти 10 лет. Обсуждать характер моей работы я здесь не буду.
Знаешь, Павел, как-то настораживает твоё упорное нежелание обсуждать настоящую работу. Уже пять лет на этом форуме ты делаешь одни и те же утверждения.
Про "заказчика, у которого нет формальных требований к быстродействию, зато неформальные важнее всего", но называть имя заказчика нельзя.
Про "задачу, которая похожа на сложение матриц", но рассказывать эту задачу нельзя.
Про "область, в которой нет конкурентов", но называть эту область нельзя.
Складывается впечатление, что ты выигрываешь-то в этой области только оттого, что тщательно бережёшь её и заказчика от конкурентов.
PD>Представьте себе, есть. Мне заказчик как-то выразил благодарность за то, что я ускорил быстродействие на 1%.
Это та же самая благодарность, о которой ты говорил в прошлые разы?
Или у тебя этими благодарностями вся стена обвешана? Просто если она одна — то как-то один процент за пять лет — это не ахти какой прогресс.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Я говорил о том, что File.ReadAllLines можно заменить на что-то вроде S>>IEnumerable<string> MyFileUtilities.ReadAllLines(string fileName);
PD>Я все же не понял. IEnumerable (то есть чтение по одной строке, так ?) — конечно лучше, но зачем вообще все строки читать, если нужна последняя ?
Ок, пусть будет ISmartNavigable<string>. Который помимо унаследованных от IEnumerable методов будет иметь метод string Last(), оптимизированный для обратного чтения (а уж есть ли там файлмаппинг — дело десятое)
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
C>>В нём мало смысла просто. На карте-то выполняется небезопасный код. S>Не понял проблемы. На CPU тоже выполняется "небезопасный код". Просто он порождается из безопасного, благодаря чему всё становится здорово. Не вижу никаких причин не применить это для КУДЫ.
Не получится. В КУДЕ точно так же идёт работа с указателями. С помощью них можно что угодно делать с карточкой, фактически. Но вот проверку на выход за диапазон ты просто поставить везде не сможешь — ветвления жутко дорогие без предсказателя переходов.
Основной метод борьбы с глючными ядрами (программами для КУДА) сейчас — это переинициализация карты по таймауту. Ну и ещё есть зачаточная виртуальная память.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Кэр, Вы писали:
Кэр>>Понятно, что есть не Евклидовы пространства и там параллельные прямые имеют свойство пересекаться. Просто подходы проповедуемые вами — загубят почти любой боевой проект.
PD>Из того множества проектов, о которых Вы так печетесь — может и да. Может, и нет. Но почему Вы решили, что я проповедую свой подход именно для них ?
Это то множество проблем, где есть конкуренты. То есть тотальное, подавляющее большинство. И важно не только решить задачу — но сделать это максимально эффективно.
>>Да есть ненулевое подмножество проектов, где подобные принципы могут быть чем-то оправданы. Но размеры его будут очень небольшие.
PD>Еще раз — не стоит в процентах измерять эти множества. Это как грибы — чтобы наполнить корзину, хватит десятка белых, а опят понадобятся сотни.
Я слаб в метафизических аллегориях сегодня. Вы этим утверждением пытаетесь избежать инжинерного подхода к решению проблем (определить проблему, включая измерения и оценки, и решить ее — в данном случае, какие методологии нужно применять при разработке проектов и почему) или просто самоутверждаетесь?
>>А причины обоснованности этих подходов почти всегда будут нетехническими (вот только не надо опять про сэкономленные лицензии — цена этой экономии слишком уж большая).
PD>Не знаю, какие там нетехнические причины, и чем отличаются технические от нетехнических, но причины были и есть.
Например, при разработке национального школьного портала можно было использовать любые методологии, технологии и религиозные убеждения в разработке. Просто потому что разработка там не имела вообще никакого значения. Конкурентов там тоже не было. Поэтому технические причины в этом проекте даже не второстепенны — они просто не играют никакой роли.
Кэр>>Но тогда к вашим утверждениям сформулированном в самой начале этой темы нужно добавить эти ограничения накладываемые на проект.
PD>А я же и так не раз говорил — есть разные задачи, и для них разные принципы.
Это не означает, что их нельзя классифицировать, оценить размеры и действовать соответствующим образом.
>>Причем не припиской мелким текстом в подвале темы, PD>Мелким текстом — это как ? Я вообще-то размерами шрифта здесь не балуюсь >>а в самом начале большими красными мигающими буквами. Потому что изначально они выглядели как указания к разработке стандартных проектов PD>Ссылку ?
Пардон, ссылку найти не могу. Я про ваш пост, где были постулаты "Быстрее, еще быстрее, еще быстрее черт возьми".
Собственно все спорят именно с этим. Никто не спорит с тем, фактом что для некоторых задач С необходим (хотя их все меньше и меньше), никто не спорит с тем фактом, что иногда производительность является функциональным требованием (по крайней мере не я). Но все возражают против этого вашего подхода, где производительность — это такая священная корова, которой нужно принести любые жертвы.
Но, после того как вы сказали, что у вашего проекта конкурентов нет — мне вот сильно обсуждать тему не особенно интересно. По причинам изложенным выше. При отсуствии конкурентов можно безнаказанно заниматься любым безобразием. Можно даже вообще не работать, а создавать только видимость, чтобы у клиента желание платить деньги не пропало.
Здравствуйте, Cyberax, Вы писали:
C>Ты же сам понимаешь, что если статически проверки у тебя уберутся — то всё будет нормально. А если не уберутся — упс. Причём в достаточно большом количестве случаев тебе их убрать не получится (а в общем случае это и невозможно).
В том то и дело что эта техника позволяет убирать проверки в очень большом колличестве случаев.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Ты же сам понимаешь, что если статически проверки у тебя уберутся — то всё будет нормально. А если не уберутся — упс. Причём в достаточно большом количестве случаев тебе их убрать не получится (а в общем случае это и невозможно). WH>В том то и дело что эта техника позволяет убирать проверки в очень большом колличестве случаев.
Того что не уберёт — более чем хватит.
Здравствуйте, Cyberax, Вы писали:
WH>>В том то и дело что эта техника позволяет убирать проверки в очень большом колличестве случаев. C>Того что не уберёт — более чем хватит.
А ты можешь сказать что конкретно в полезных на практике вычислениях оно не сможет убрать?
В данной работе не смогли убрать проверки только из реализации поиска подстроки алгоритмом Knuth-Morris-Pratt'а.
Причем они остались только в функции генерации индекса. В основном цикле проверок нет.
Более того если сделать реализацию несколько умнее можно и их задавить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>В том то и дело что эта техника позволяет убирать проверки в очень большом колличестве случаев. C>>Того что не уберёт — более чем хватит. WH>А ты можешь сказать что конкретно в полезных на практике вычислениях оно не сможет убрать?
Не сможет. КУДАвые ядра пишут так, чтобы там ветвлений не было — иногда проще посчитать несколько значений (как если бы прошли по всем возможным веткам), чем делать ветвление.
WH>В данной работе не смогли убрать проверки только из реализации поиска подстроки алгоритмом Knuth-Morris-Pratt'а. WH>Причем они остались только в функции генерации индекса. В основном цикле проверок нет. WH>Более того если сделать реализацию несколько умнее можно и их задавить.
Так КУДУ используют не для поиска в строках.
Здравствуйте, Cyberax, Вы писали:
C>Не сможет. КУДАвые ядра пишут так, чтобы там ветвлений не было — иногда проще посчитать несколько значений (как если бы прошли по всем возможным веткам), чем делать ветвление.
Повторять ты можешь это столько сколько хочешь но того факта что оно таки устраняет это не отменяет.
C>Так КУДУ используют не для поиска в строках.
Во-во. То что считает КУДА не требует столь извращенной работы с индексами как КМП.
Так что там вообще никаких проверок не останется с вероятностью близкой к 1.
Короче попробуй привести пример задачи для КУДЫ в котором данная техника не сможет устранить проверки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Cyberax, Вы писали:
C>>Не сможет. КУДАвые ядра пишут так, чтобы там ветвлений не было — иногда проще посчитать несколько значений (как если бы прошли по всем возможным веткам), чем делать ветвление. WH>Повторять ты можешь это столько сколько хочешь но того факта что оно таки устраняет это не отменяет.
C>>Так КУДУ используют не для поиска в строках. WH>Во-во. То что считает КУДА не требует столь извращенной работы с индексами как КМП.
Хех. Тебе рассказать про то как извращаются с памятью для увеличения локальности?
Кстати, ты ещё не забывай, что в CUDA часто индексы — не целые, а float'ы. С аппаратной интерполяцией. Да, а ещё я могу с помощью race condition'ов элементарно сделать невалидные указатели. И это ты НИКАК не проверишь — нет в CUDA сильной типизации.
Здравствуйте, Sinclair, Вы писали:
S>Знаешь, Павел, как-то настораживает твоё упорное нежелание обсуждать настоящую работу. Уже пять лет на этом форуме ты делаешь одни и те же утверждения.
И буду делать
Что же касается нежелания обсуждать — оно останется без изменений. Если оно тебя настораживает — это не мои проблемы.
S>Про "заказчика, у которого нет формальных требований к быстродействию, зато неформальные важнее всего", но называть имя заказчика нельзя.
Не то что нельзя, но не хочу.
S>Про "задачу, которая похожа на сложение матриц", но рассказывать эту задачу нельзя.
Не утрируй. Сложение матриц было приведено просто в качестве прототипа, по O(N^2) алгоритму и там и здесь.
S>Про "область, в которой нет конкурентов", но называть эту область нельзя.
S>Складывается впечатление, что ты выигрываешь-то в этой области только оттого, что тщательно бережёшь её и заказчика от конкурентов.
От заказчика беречь просто невозможно, а конкурентов нет.
PD>>Представьте себе, есть. Мне заказчик как-то выразил благодарность за то, что я ускорил быстродействие на 1%. S>Это та же самая благодарность, о которой ты говорил в прошлые разы?
S>Ок, пусть будет ISmartNavigable<string>. Который помимо унаследованных от IEnumerable методов будет иметь метод string Last(), оптимизированный для обратного чтения (а уж есть ли там файлмаппинг — дело десятое)
М-да... Если не секрет, объясни, как реализовать обращение к этому Last в процессе обычной энумерации. То есть идем себе и идем по коллекции, потом захотели Last, а потом продолжаем идти с того места, где остановились... Чудо, а не код получится.
Здравствуйте, Кэр, Вы писали:
PD>>Из того множества проектов, о которых Вы так печетесь — может и да. Может, и нет. Но почему Вы решили, что я проповедую свой подход именно для них ?
Кэр>Это то множество проблем, где есть конкуренты. То есть тотальное, подавляющее большинство.
Ну и что ? Кстати, если не секрет — почему большинство должно подавлять ?
PD>>Еще раз — не стоит в процентах измерять эти множества. Это как грибы — чтобы наполнить корзину, хватит десятка белых, а опят понадобятся сотни.
Кэр>Я слаб в метафизических аллегориях сегодня. Вы этим утверждением пытаетесь избежать инжинерного подхода к решению проблем (определить проблему, включая измерения и оценки, и решить ее — в данном случае, какие методологии нужно применять при разработке проектов и почему) или просто самоутверждаетесь?
Пытаюсь довести до Вашего понимания, что не все , чему Вы поклоняетесь, есть истина в последней инстанции. Используя при этом аллегории.
А вот не могли бы Вы объяснить, почему Вас так разражает наличие несогласного с Вашим подхода. Ну пусть он справедлив для 1%, а Ваш для 99% по объему. Ну и что ?
>>>А причины обоснованности этих подходов почти всегда будут нетехническими (вот только не надо опять про сэкономленные лицензии — цена этой экономии слишком уж большая).
Кэр>Например, при разработке национального школьного портала можно было использовать любые методологии, технологии и религиозные убеждения в разработке. Просто потому что разработка там не имела вообще никакого значения. Конкурентов там тоже не было. Поэтому технические причины в этом проекте даже не второстепенны — они просто не играют никакой роли.
Ничего не понял. Если разработка не имела вообще никакого значения — может, лучше было ее не начинать вообще ?
PD>>А я же и так не раз говорил — есть разные задачи, и для них разные принципы.
Кэр>Это не означает, что их нельзя классифицировать, оценить размеры и действовать соответствующим образом.
Вполне согласен. Именно об этом я говорю — для разных задач надо действовать соотвтествующим образом. Например, иногда использовать сверло, а иногда топор
PD>>Ссылку ?
Кэр>Пардон, ссылку найти не могу. Я про ваш пост, где были постулаты "Быстрее, еще быстрее, еще быстрее черт возьми".
Цитирую оттуда
PD>Давай точки над i расставим.
PD>Я не пытаюсь распространить свой крайний случай на всё программирование в мире. Ни в коем разе! PD>Я не пытаюсь доказать, что С++ нужно использовать для написания сайтов. PD>И т.д. я не пытаюсь.
PD>Я просто утверждаю, что для разного рода задач нужны и должны использоваться свои инструменты. Где-то лучше всего Питон, а где-то С. Для данной задачи что лучше — Питон или С — обсуждать имеет смысл , если знать задачу, иначе не стОит. Поэтому априорные, без знания задачи, рекомендации неуместны.
Это и есть то, что я не устаю повторять.
Кэр>Собственно все спорят именно с этим. Никто не спорит с тем, фактом что для некоторых задач С необходим (хотя их все меньше и меньше), никто не спорит с тем фактом, что иногда производительность является функциональным требованием (по крайней мере не я). Но все возражают против этого вашего подхода, где производительность — это такая священная корова, которой нужно принести любые жертвы.
Ссылку на то место, где я утверждал, что производительности надо принести любые жертвы!
Кэр>Но, после того как вы сказали, что у вашего проекта конкурентов нет — мне вот сильно обсуждать тему не особенно интересно. По причинам изложенным выше. При отсуствии конкурентов можно безнаказанно заниматься любым безобразием. Можно даже вообще не работать, а создавать только видимость, чтобы у клиента желание платить деньги не пропало.
Не волнуйся, у него никогда не пропадет. А вот видимость создать не удастся. По очень простой причине — есть четкий и определенный критерий качества. Если он не улучшается, то и платить не будут.
With best regards
Pavel Dvorkin
Re[11]: Павлу Дворкину: о понимании того что делаешь и прост
Здравствуйте, FR, Вы писали:
FR>Для C++ тоже вполне реально, та же изоляция в системный процесс например.
Это фантастика. Для классического неуправляемого приложения граница разрушения — это процесс. Взаимодействие процессов — очень дорогое. Поэтому реализация всех кирпичиков в виде отдельных процессов в большинстве случаев неприемлема по производительности. (Хотя, конечно, и возможна).
Именно поэтому управляемые среды представляют значительно больший интерес с точки зрения производительной надёжности. Там можно весьма гранулярно провести границы повреждённого состояния, и при этом не иметь накладных расходов при доступе через эти границы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>М-да... Если не секрет, объясни, как реализовать обращение к этому Last в процессе обычной энумерации. То есть идем себе и идем по коллекции, потом захотели Last, а потом продолжаем идти с того места, где остановились... Чудо, а не код получится.
Павел, ты что, серъёзно? Меня поражает порой — такие разговоры про секретные алгоритмы, выполняющиеся на тысячах машин... А как до реализации простого IEnumerable<string> — так всё, наивная вера в чудо...
Никаких чудес. На всякий случай напомню, что IEnumerable — это всего лишь способ получения IEnumerator. И у одного IEnumerable можно получить сколько угодно одновременно активных енумераторов.
Поэтому самый простой вариант кода будет открывать файлмэппинг, GetEnumerator будет возвращать новый экземпляр IEnumerable<string>, который содержит в себе текущую позицию, а Last будет обращаться к концу отмапленной области.
Основная сложность будет в том, чтобы аккуратно работать с файлами "слишком большого" размера, чтобы не исчерпать адресное пространство раньше времени.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Но мое мнение от этого не изменится 
