Что там получилось — обсуждать сейчас не буду, так как жду ответа на мое утреннее письмо. Ну а о прочем порассуждаем.
Нужна ли нам свобода ? Для того, чтобы ответить, надо задать другой вопрос — а что вообще надо ?
Говорить буду от своего имени. Согласные могут присоединиться
Мне надо
1. Иметь возможность делать все, что я хочу. Разумееется, в рамках того, что мне позволяет аппаратура и (возможно) операционная система, а также мои мозги. Слово "возможно" здесь не случайно. В определенных границах я могу изменить поведение ОС, добавив к ней свой модуль (драйвер)
2. Чтобы это работало как можно более быстро и потребляло ресурсов как можно меньше. Я пишу не серверное ПО, а моя ОС не MS-DOS, так что работать это все будет в коммунальной квартире, а поэтому ванную занимать на 3 часа нечего и свет в туалете надо тушить.
3. Чтобы в этом коде было как можно меньше ошибок. Говорить "чтобы не было ошибок" не буду, так как программа без ошибок есть абстрактное теоретическое понятие.
4. Чтобы я на это потратил как можно меньше своего времени.
Замечу, что эти пожелания выстроены мной строго в соответствии с моими приоритетами. Иными словами, если мне предлагается нечто, резко улучшающее пункт i+1 за счет ухудшения в пункте i — меня это не устроит.
Ты мне предлагаешь начать с пунктов 3 и 4. Обещаешь, что в коде будет меньше ошибок, и я смогу написать быстрее. Насчет второго не спорю, а первое еще обсудим, попозже.
Первый мой вопрос — а как с п.1 и 2 будет. Гарантируете ли вы, что я по-прежнему смогу делать все. что я умею делать, использовать все те возможности ОС, которые умею использовать ? И будет ли это работать столь же быстро и требовать ресурсов не больше ?
Как только я этот вопрос задаю, так сразу мои оппоненты начинают юлить. Сможешь , наверное, только вот иногда тебе придется на неуправляемый код переходить, а иногда и вообще не получится. Но ты мол, не огорчайся, если не получится, то это значит, что тебе такое и не надо, мы тебе другое предложим... И работать это будет быстрее. Ах, у тебя все же медленнее получается... Ну значит , ты неправильно меряешь, не на тех тестах , и вообще имей в виду — в светлом будущем наш код намного лучше будет. Светлое будущее обещать они очень любят.
Я утрирую ? Нет. Ну насчет скорости — мы тут уже столько копий сломали, что вряд ли стоит еще одно ломать. А вот насчет возможностей... Никакой я не специалист в C# и .NET, я там просто дилетант, не более. Но тем не менее мне неоднократно доводилось давать советы в форуме по .NET, причем за эти советы я получал баллы в рейтинге. Разумеется, мне и в голову не придет давать совет, когда речь идет о каких-то итераторах или замыканиях, но вот когда речь заходит о взаимодействии с Windows, об использовании ее механизмов — мои советы порой звучат для некоторых там как откровение.
Так что , увы, по п. 1 и 2 ощущения у меня складываются ... как бы это помягче сказать... не очень. Цена отказа от свободы для меня слишком уж велика.
А теперь перейдем к п.3. Вот тут мои оппоненты сразу отыграться готовы. Да, пусть ты кое-что в плане свободы потеряешь, но это мелочи. Зато мы тебе взамен предлагаем безопасность. Ошибок будет меньше. Это же хорошо ?
Хорошо, конечно. Что я еще могу сказать! Вы предлагаете мне отказаться от свободы, но в ответ обещаете, что я смогу писать код без ошибок ? Да — мне в ответ.
Без любых ошибок ?
И тут опять мои опппоненты юлить начинают. Мемори ликов у тебя не будет. Ладно, говорю, спасибо, хотя у меня их и так не много, инструменты для их обнаружения есть. Индекс у тебя за пределы массива не выйдет. Тоже спасибо, отвечаю я, он и так у меня как правило не выходит, если только я сам не хочу, чтобы он выходил. Что там еще ? Уничтоженные объекты не будешь использовать. Тоже спасибо, хотя и так попытка взятия по NULL определяется без особого труда.
А от логических ошибок вы меня оградите ? От ошибок алгоритма или его реализации ? От того, что я при вычислении корней уравнения вместо b*b-4*a*c написал b*b+4*a*c ? От того, что я понимал эту задачу так-то, а она, оказывается, выглядит совсем не так, но это проявляется в одном случае на миллион ? С IndexOutOfRange я как-нибудь и так справлюсь, а вот с этим-то что делать ? Поможете ?
А в ответ — либо тишина, либо рассуждения о светлом будущем, когда весь код будет верифицироваться (надо полагать, верификатор будет распознавать подпрограмму вычисления корней уравнения, знать этот алгоритм и подскажет мне — ты там плюс вместо минуса поставил Остается только понять — почему он в таком случае за меня программу сам не написал.)
Кстати, и твой пример с пайпами. Я до конца не разобрался, в чем там ошибка, гипотеза — мютекс создается после защищаемого объекта (а надо до, эту ошибку я тоже как-то делал). Да, управляемый код скорее всего вместо UB и следующей за ним уязвимости просто устроит exception. Но при написании кода была допущена логическая ошибка (если это так). Помочь мне не допустить , чтобы я эту ошибку сделал, кто мне может ? Никто. Тот код, который ты показал, при определенных условиях вполне безупречен.
И вот эти логические ошибки меня больше всего и беспокоят. Они у меня львиную часть времени съели. А не выходы индексов и прочая чепуха.
Резюмирую. Готов ли я отдать свою свободу (в программировании, конечно, только там) за что-то ? Пока не дадите твердого ответа на п.1 и 2. — категорически не готов. А когда дадите — тогда поторгуемся по п.3. Пока хорошо не заплатите — тоже не отдам.
Но!
Если встретится задача, где можно ваши способы и методы использовать — а почему бы и нет ? Если п. 1-2 несущественны или не лимитируют — да бога ради. Попастись на вашем поле я вполне готов, но как только понадобится что-то серьезное сделать — на свободу! В пампасы . Там трава погуще, хотя и львы бегают.
И в заключение лирическое отступление.
Есть такая машина — вертолет называется. Летает себе куда хочет, садится — почти где хочет, взлетает там, где села. Жаль, не довелось мне на ней полетать. Вот представляю себе — летим, а внизу шоссе. И на нем — поток машин. Все в одном направлении едут. А вот здесь вообще стоят — пробка.
Ну зачем вы все как на параде, в одну сторону едете ? Вам же в разные места надо! Возьмите карту, проложите прямую (или геодезическую), да по прямой, по прямой! Ах, там дома, говорите. Ну и что ? У них же высота — жалкие десятки, ну сотни метров. А в горы вы сможете, а ? На Мерседесе — да прямо в горы, без дороги ? А как насчет речку пересечь ? Мост вам, оказывается нужен, или паром. А я пересек и не заметил. И чего вы так медленно едете ? Я , пока вы там в пробке стоите, вокруг вас несколько раз облетел и язык вам показал.
В общем, лучше вертолет, чем автомобиль. Намного лучше. Но один недостаток у него есть. Серьезный. Иногда они падают. Не часто, но бывает. И последствия обычно тяжелые.
А автомобили — не падают. Сталкиваются — да, с обрыва летят — тоже бывает. Я так думаю, что они при этом очень хотят хоть напоследок полетать. Свободы им хочется. Той самой, о которой они уже и думать забыли.
Но не получается. Рожденный ползать — летать не может.
Здравствуйте, Tilir, Вы писали:
T>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Я вот сижу и думаю, а может ну ее нафиг эту свободу, а?
T>Не так давно от одного моего друга слесаря прозвучало
T>
T>Я бы так сказал — токарный станок дает мне свободу делать все, что я хочу. А это неизбежно сопряжено с возможностью сделать и ошибку. Чтобы свободой как следует воспользоваться, надо хорошо понимать, что при этом можно, и что нельзя делать. Например палец туда совать нельзя.
T>Вместо "палец" он употребил иное слово, но вы понимаете, слесарь...
Я совершенно согласен, но, думаю, это все же был токарь
With best regards
Pavel Dvorkin
Re[5]: Павлу Дворкину: о понимании того что делаешь и просты
Приветствую, samius, вы писали:
s> IT>Уж лучше в дворники, чем в дворкины? s> На РСДН уже видимо правило хорошего тона: если не разделяешь точку зрения человека — просклоняй его /*или фамилию, если доступна*/. s> Пол беды, когда это делают пользователи, но от админа
Ну у меня "Дворкин" в первую очередь ассоциируется с "9 принцев Амбера".
Здравствуйте, gandjustas, Вы писали:
G>>>Напиши highload сайт полностью на С\C++. PD>>Что за чепуха ? Когда это я предлагал сайты на С/C++ писать ? Он совсем не для написания сайтов! G>А для чего? Если че — написание для веба на сегодня одна из самых востребованных областей.
Меня поражают иногда такие споры. Оппонент практически в каждом сообщении описывает свой круг задач, но его никто не слушает и со своей колокольни начинают мучать сайтами и базами данных. Ей богу, Павлу надо подпись сделать: "Сайты не разрабатываю".
Для разнообразия предлагаю тебе, gandjustas, написать безопасное приложение, которое будет работать на видеокарте с CUDA SDK. Потренируйся, посмотри что это практически невозможно. (Даже стандартный пример с рекомендуемыми дровами, на рекомендованном оборудовании может вызвать синий экран.) Примени свои знания C#, .Net, храни текстуры в MS SQL и подгружай их запросами. А мы посмотрим.
Re: Павлу Дворкину: о понимании того что делаешь и простых п
KV>Я бы так сказал — язык С++ дает мне свободу делать все, что я хочу. А это неизбежно сопряжено с возможностью сделать и ошибку. Чтобы свободой как следует воспользоваться, надо хорошо понимать, что при этом можно, и что нельзя делать.
Я кода прочел "Павел", думал, что ты о Павле Кузнецове .
Что до свободы делать что хочет Дворкин, то у него просто довольно странные желания. Лично мне хочется побыстрее написать программу которая будет работать надежно, стабильно и при этом с приемлемой (а не максимально возможной) производительностью. И я не хочу траха. А вот люди вроде Дворкина считаю, что максимальная производительность — это главный приоритет перекрывающий все остальне. Плюс Дворкин фактически заперт в миру идеом С/С++ и просто не представляет как писать софт по другому. Так что от части его свобода только ему кажется свободой, а на самом деле — это клетка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Павлу Дворкину: о понимании того что делаешь и простых п
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>"Суслика видите? А он есть..."
Уважаемый. А вам не кажется что вышеописанное ортогонально языку, и подобное можно сделать практически на любом языке. Хотя для некоторых придется проявить выдержку, спокойствие и сообразительность?
Re: Павлу Дворкину: о понимании того что делаешь и простых п
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я вот сижу и думаю, а может ну ее нафиг эту свободу, а?
Не так давно от одного моего друга слесаря прозвучало
Я бы так сказал — токарный станок дает мне свободу делать все, что я хочу. А это неизбежно сопряжено с возможностью сделать и ошибку. Чтобы свободой как следует воспользоваться, надо хорошо понимать, что при этом можно, и что нельзя делать. Например палец туда совать нельзя.
Вместо "палец" он употребил иное слово, но вы понимаете, слесарь...
Он, наверное, глупый и не понимает насколько безопасней ватные тампоны.
Это ядро Linux. Ещё раз -- ядро. Операционной системы. То самое место, где любые "управляемые решения" с JIT, сборкой мусора и прочими подгузниками просто не роляют. Ошибки? Их не бывает только у тех, кто ничего не делает. А свобода программиста, которую даёт C, ну да в том числе и свобода ошибаться, это самое ценное что у меня, например, есть.
Re[2]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, Tilir, Вы писали:
T>Это ядро Linux. Ещё раз -- ядро. Операционной системы. То самое место, где любые "управляемые решения" с JIT, сборкой мусора и прочими подгузниками просто не роляют.
С чего ты взял?
T>Ошибки? Их не бывает только у тех, кто ничего не делает. А свобода программиста, которую даёт C, ну да в том числе и свобода ошибаться, это самое ценное что у меня, например, есть.
Тоже чушь, MS активно использует верификатор кода C, количество таких ошибок снижается на порядки.
Программирование уже давно не искусство, тут рулят надежные решения. На свободу насрать.
Павлу Дворкину: о понимании того что делаешь и простых прави
Я бы так сказал — язык С++ дает мне свободу делать все, что я хочу. А это неизбежно сопряжено с возможностью сделать и ошибку. Чтобы свободой как следует воспользоваться, надо хорошо понимать, что при этом можно, и что нельзя делать.
Я вот сижу и думаю, а может ну ее нафиг эту свободу, а? А то получится как с ядром линукса
pipe_read_open(struct inode *inode, struct file *filp)
{
int ret = -ENOENT;
mutex_lock(&inode->i_mutex);
if (inode->i_pipe) {
ret = 0;
inode->i_pipe->readers++;
}
mutex_unlock(&inode->i_mutex);
return ret;
}
и приплыли — уязвимы все версии ядра линукса с 2001 года (хорошо хоть не во всех дистрибутивах)... И я не думаю, что писавший первоначальный вариант кода не понимал "что при этом можно, и что нельзя делать", он скорее просто не предполагал, что в другом процессе все же может произойти вызов free_pipe_info(), освобождающий i_pipe до того, как был установлен мьютекс.
Я не понимаю вас Господа. Мы же не политики и философы, чтобы вести разговоры о свободе. Так мы договоримся что железо вредно так как ограничивает свободу.
Не думаю что найдется большой процент програмистов на С++ или С которые откажутся от статического и динамического верификатора кода.
Я не думаю что найдется много прогамистов которые бы отказались от снятия накладных расходов накладываемых JVM.
Зачем писать утилиту администрации ДБ на С++?
Зачем писать мультимедиа кодеки на питоне?
Неужели математики используют матлаб вместо PHP иззи любви к свободе?
Я один ничего не понимаю? Неужели в среде технических инженеров нетехнические аргументы имеют больший вес?
"90% задач не требуют эфективной реализации и расходуют пренебрежительно мало памяти" — это повод обобщить вывод на 10% задач?
Здравствуйте, Pavel Dvorkin, Вы писали: PD>У меня никаких проблем нет, а требование максимальной скорости выдвинуто заказчиком, с которым я работаю почти 10 лет. Обсуждать характер моей работы я здесь не буду.
Знаешь, Павел, как-то настораживает твоё упорное нежелание обсуждать настоящую работу. Уже пять лет на этом форуме ты делаешь одни и те же утверждения.
Про "заказчика, у которого нет формальных требований к быстродействию, зато неформальные важнее всего", но называть имя заказчика нельзя.
Про "задачу, которая похожа на сложение матриц", но рассказывать эту задачу нельзя.
Про "область, в которой нет конкурентов", но называть эту область нельзя.
Складывается впечатление, что ты выигрываешь-то в этой области только оттого, что тщательно бережёшь её и заказчика от конкурентов.
PD>Представьте себе, есть. Мне заказчик как-то выразил благодарность за то, что я ускорил быстродействие на 1%.
Это та же самая благодарность, о которой ты говорил в прошлые разы?
Или у тебя этими благодарностями вся стена обвешана? Просто если она одна — то как-то один процент за пять лет — это не ахти какой прогресс.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, remark, Вы писали:
R>Ну будет не падать программа, а деньги переводить на неправильный счёт. Если она падает — это ещё лучший исход.
А это смотря как она падает. Ибо если она падает из-за того, что поток управления пошел по левому адресу, в который мы можем записать нужный нам код, то лучше бы она переводила деньги на неправильный счет...
Да и, если бы она просто падала — тоже мало приятного, например для владельца интернет-магазина. Я думаю, что он был рад и сам деньги на неправильный счет перевести, лишь бы она падать перестала
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Я никуда не ухожу. Меня интересует прежде всего эффективность всего решения. Если к системе предъявляются серьёзные нефункциональные требования и заказчик за это готов платить, то он это получит, не переживай.
PD>Что за нефункциональные требования у тебя там могут быть — не знаю и не хочу обсуждать. Я говорил именно о функциональных требованиях. Быстрее, черт возьми. Еще быстрее! А теперь еще быстрее.
Быстрее и еще быстрее сделать что? А то может тебе не надо ничего писать а просто скачать Nada — она выполняет свои обязанности в режиме 24/7, с нулевыми затратами процессорного времени и оперативной памяти — просто идеальное решение!
Функциональные требования описывают, что должна делать система. Нефункциональные — как она должна это делать. То есть ограничения, накладываемые при выполнении данных функций. В том числе и ограничения по скорости выполнения заданных функций и потребляемым при этом ресурсам.
Причем, твое ограничение "Быстрее, черт возьми. Еще быстрее! А теперь еще быстрее" делается просто на раз, всегда бы такие задачи мне ставили. Решение очень простое — делаем очень медленную версию, потом немного улучшаем ее — и она "быстрее, черт возьми", потом еще раз улучшаем — и она "Еще быстрее!", а теперь опять оптимизируем — и теперь она "еще быстрее!". Ура, требования по быстродействию удовлетворены всего за 4 релиза, забираем деньги, идем радоваться.
Почему-то чаще ограничения по быстродействию накладываются как-то иначе. Примерно так:
1. Сперва все функциональные требования
2. Нефункциональные:
2.1. Быстродействие:
2.1.1 Имеющееся оборудование (или пределы, какое оборудование возможно установить)
2.1.2 Список по всем функциям системы с указанием максимального (либо, в зависимости от задачи, среднего) времени выполнения данной функции (и, если надо, потребляемых прочих ресурсов) на указанном выше оборудовании.
И что тут характерно — требования четки и легко проверяемые — запускаем программу и смотрим, выполнился ли расчет задачи "А" за 3 секунды или нет (ну и заодно, что посчиталось правильно). Выполнился? Молодцы, вот вам деньги. Нет? Идите дорабатывайте систему.
А вот как доказать заказчику, что ты успешно выполнил функции "Быстрее, черт возьми" и, одновременно, "Еще быстрее"? Особенно, если система — что-то новое и раньше другой версии ее же не было? Тут можно только прогрузить его, что делается это на чистом С и использовалось 148 ассемблерных вставок, и, черт возьми, быстрее уже никто не будет, зуб даю. Короче — упражнение в красноречии.
Жаль у нас таких требований не ставят — у нас есть хороший специалист по маркетингу, уболтает кого угодно. Типа "Вы думаете, что это медленно?! Да вы просто не знаете что такое медленно, а это же очень хорошее решение, что вы, все прекрасно и ровно как вы хотели!"
А вот уболтать спецификацию с явно прописанной цифрой и секундомер, на котором высветилась совсем другая цифра — почему-то выходит с трудом.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Замечу, что эти пожелания выстроены мной строго в соответствии с моими приоритетами. Иными словами, если мне предлагается нечто, резко улучшающее пункт i+1 за счет ухудшения в пункте i — меня это не устроит.
С такими низкоуровневыми приоритетами можно решать только низкоуровневые задачи. Для узкой группы задач вроде ковыряния в железках это возможно будет работать. О решении бизнес и ряда системных задач можно сразу забыть навсегда.
Если нам не помогут, то мы тоже никого не пощадим.
Джон Бентли. Жемчужины программирования. 2-е изд. стр. 248 перевода (в пункте 6, вверху):
"В этой программе, как в любой другой большой системе, есть ошибки. На данный момент их известно 10 штук, они все не слишком серьёзны. В следующем месяце, возможно, будет обнаружено ещё 10 таких же ошибок. Если бы вы могли выбирать между устранением 10 известных на данный момент ошибок или увеличением скорости работы программы в 10 раз, что бы вы выбрали?"
фсЗдравствуйте, gandjustas, Вы писали:
KV>>>"Суслика видите? А он есть..." GZ>>Уважаемый. А вам не кажется что вышеописанное ортогонально языку, и подобное можно сделать практически на любом языке. G>Ага, пример на .NET в студию.
GZ>>Хотя для некоторых придется проявить выдержку, спокойствие и сообразительность? G>Там где сборка мусора такое сделать почти невозможно.
Что невозможно? Гонку сделать? Чего ж тут невозможного?
Ну будет не падать программа, а деньги переводить на неправильный счёт. Если она падает — это ещё лучший исход.
Здравствуйте, A13x, Вы писали:
A>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>... KV>>Я вот сижу и думаю, а может ну ее нафиг эту свободу, а?
A>А может тогда сразу нафиг программирование — и в дворники?
Ну если эта типа свобода (проявление которой, бывает в форме, представленной в исходном сообщении) — это единственное, что держит человека в отрасли, то почему бы и нет?
Здравствуйте, A13x, Вы писали:
A>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>... KV>>Я вот сижу и думаю, а может ну ее нафиг эту свободу, а?
A>А может тогда сразу нафиг программирование — и в дворники?
блин...а я прочитал — ...в Дворкины...
Re[4]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, LaptevVV, Вы писали:
LVV>А можешь КОНКРЕТНО представить себе предприятие, в котором при эксплуатации ПО
крах приложения вполне может быть допускаемым событием с предусмотренной реакцией.
LVV>Я, например, не могу...
Развивайте воображение Ну там в LEGO играйте, например
LVV>Во всех конторах, где я работал, крах... считался ЧП.
Такие конторы значится А вот бортовое военное ПО специально проектируется исходя из требований мгновенного рестарта в случае отказа. Известнейший эпизод — F-16 и высота 0 футов над уровнем моря Ну деление на ноль, ну и что Рестарт, и через секунду всё опять работает.
Более того, не редкость вообще построение системы на схеме с постоянным рестартом, например, у спутникового ПО. Менеджер памяти в таких штуках, например, умеет её только выделять. Когда же память заканчивается, то приложение сохраняет своё состояние в постоянную память, и рестартуется.
LVV>А в производстве ИМХО НЕЛЬЗЯ НИКОГДА!
Нельзя только в очень узком сегменте, например, в последней линии защиты исполнительных механизмов. Но там кода с гулькин нос, и его вполне реально сделать надёжным за разумные средства.
Re[10]: Павлу Дворкину: о понимании того что делаешь и прост
Здравствуйте, LaptevVV, Вы писали:
LVV>Это как раз из той оперы, что на безрыбье и рак — рыба... По мне так лучше бы он вообще не падал... Ну а раз упал, тогда чтоб не было потерь...
+1
LVV>В общем, понятно, что требования и к надежности, и к эффективности определяются при разговоре с заказчиком. LVV>При этом, очевидно, заявления типа"чтоб работало максимально быстро" — требованиями не являются...
Не согласен.
LVV>И еще одно соображение по эффективность... LVV>Сначала занимаются скоростью. Памятью занимаются только тогда, когда ее не хватает...
Тоже не согласен. Если текстовый редактор будет работать очень быстро и хорошо, но займет 1 Гб — я его выброшу. Хоят у меня 2 Гб на машине. Но есть и другие приложения, их список неопределен, а поэтому надо брать памяти как можно меньше, чтобы и другим осталось.
LVV>Но и скорость может иметь обратный психологиченский эффект (об этом писали), когда слишком быстрый ответ системы у простого пользователя вызывает эффект комплекса неполноценности из-за разница в скорости коммуникаций...
Ну замедлить-то как-нибудь сможем, если надо. А во-вторых, я говорил в основном отнюдь не о скорости взаимодействия с пользователем, а о скорости обработки данных.
LVV>Поэтому резюме ИМХО. LVV>Твой приоритет эффективности определен не твоими вкусами и предпочтениями, а постоянными требованиями заказчика или характером задачи....
Совершенно верно. Я его никому не навязываю. Но и мне не надо иные навязывать (это не к тебе относится). И не надо иные принципы выставлять в качестве универсально — обязательных.
>Если б не требовали, то и упираться б в эффективность слишком не стал бы...
Стал бы. Привычка
>А вот ошибки б — исправлял бы всегда...
Ну это уж да.
LVV>Если б писал лично для себя...
Эх...
With best regards
Pavel Dvorkin
Re[4]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Ты так говоришь, как будто ее возможно у вас отобрать CC>Просто не хочется очередной холивор "что-то vs C(или C++)"
Вопрос стоял иначе, и отбирай-не отбирай — знай-не знай этот инструмент, — как показывает практика, подобные ошибки будут всегда. Вопрос наверное в том — как с ними бороться?
Re[5]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, fddima, Вы писали:
F> Вопрос стоял иначе, и отбирай-не отбирай — знай-не знай этот инструмент, — как показывает практика, подобные ошибки будут всегда. Вопрос наверное в том — как с ними бороться?
Используя безопасное подмножество языка (или язык) там, где возможно, и небезопасное (или безопасный язык) — там, где необходимо?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Замечу, что эти пожелания выстроены мной строго в соответствии с моими приоритетами. Иными словами, если мне предлагается нечто, резко улучшающее пункт i+1 за счет ухудшения в пункте i — меня это не устроит.
Может именно в этом ваша ошибка ? Вы пытаетесь строить приоритеты в отрыве от выполняемой задачи? Много моих отличных знакомых програмистов, выстраивают приоритеты исходя из задачи, я с ними солидарен.
Здравствуйте, IT, Вы писали:
IT>С такими низкоуровневыми приоритетами можно решать только низкоуровневые задачи. Для узкой группы задач вроде ковыряния в железках это возможно будет работать. О решении бизнес и ряда системных задач можно сразу забыть навсегда.
Бизнес (в твоем понимании) — пожалуй, да, так как там царит, похоже, принцип — хоть как, но быстрее, давай-давай. Впрочем, есть и другие бизнес-задачи, и там это вполне работает (в моей работало).
With best regards
Pavel Dvorkin
Re[2]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
G>>>>Продолжай мысль: потратиться на железо дешевле, чем оптимизировать программу. Особенно это касается памяти.
PD>>>Доказательства в студию. G>>Месяц работы программиста — от 30000 до 80000 рублей. Гигабайт оперативки стоит меньше 1000р. За месяц работы программиста можно купить неплохой компьютер.
PD>Замечательно. А теперь иначе посчитаем.
PD>ПО работает на 1000 компьютеров. Стоимость компьютера примем за 1000 USD. На каждом компьютере должно быть установлено еще некоторое 3dparty ПО, лицензия на место стоит 5000 USD. PD>Мне удается оптимизировать на 1% всего. Ничтожно мало, по мнению многих. Но это значит, что вместо 1000 компьютеров хватит 990. PD>10 компьютеров * (1000 + 5000) = 60,000 USD.
И что ты посчитал?
Если это 1000 разных пользователей, то затраты по ним разделятся и будет по максимум 60$ на человека. Хотя многим эти затраты не понадобятся, так как 1% никто не заметит.
Если дело касается большой распределенной сиситемы, то оптимизация в 1% может выйти гораздо дороже 60 килобаксов.
PD>Стоит ли дать мне возможность сделать это за месяц , заплатив от 30000 до 80000 рублей ( от 1000 до 3000 USD) ?
См выше.
Кроме того, чтобы заниматься такой оптимизацией надо уже иметь рабочую систему. Если начинать писать на C, то до получения рабочей системы затраты будут гораздо больше
PD>>>Если продукт не работает с минимально требуемой скоростью — он не продукт. G>>Правильно. Какая скорость работы минимально требуется? И как её определить?
PD>Как мы ее определяем — рассказывать не буду, но определяем, не беспокойся. А требуется — как можно больше.
Ну так расскажи что ты имеешь ввиду под скоростью работы и как ты её увеличиваешь.
G>>>>А с чего ты взял что на С буждет потребляться меньше ресурсов (и каких ресурсов вообще)? PD>>>Я это обосновывал не раз, новых аргументов нет. Прежние ты знаешь. G>>Да ты ниче не обосновывал. Максимум приводил тривиальные примеры, которые вообще ничего не доказывают. PD>Ну не доказывают они тебе ничего, ну и ладно. Не могу же я специально для тебя годовой проект сделать, чтобы что-то доказать.
Да ты больше конкретики приводи, а не общетеоретических рассуждений с непоказательными примерами.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, kochetkov.vladimir, Вы писали:
OE>>>>ну и аргумент, охренеть — ваша кофеварка не умеет стирать бельё!??? в топку её! PD>>>Если меня больше всего интересует, как постирать белье , а ты мне предлагаешь кофеварку — в топку!
KV>>Угу, правда не понятно при этом, каким боком тебя интересует стирка белья в рамках процесса приготовления кофе
PD>Нет, все как раз наоборот. У меня проблемы со стиркой белья, вода извне в машину не течет, а изнутри вытекает на пол, ротор не крутится и т.п, а тут ко мне приходят и говорят : "Мы знаем, что вам нужно, и именно сейчас! Мы решим все ваши проблемы. Самая лучшая кофеварка от фирмы Идиотекс!!! Только у нас!"
А ты теперь поставь себя на их место: они к тебе приходят с классной кофеваркой и видят как чел варит кофе в стиральной машине...
SC>Джон Бентли. Жемчужины программирования. 2-е изд. стр. 248 перевода (в пункте 6, вверху):
SC>"В этой программе, как в любой другой большой системе, есть ошибки. На данный момент их известно 10 штук, они все не слишком серьёзны. В следующем месяце, возможно, будет обнаружено ещё 10 таких же ошибок. Если бы вы могли выбирать между устранением 10 известных на данный момент ошибок или увеличением скорости работы программы в 10 раз, что бы вы выбрали?"
Устранение ошибок.
Если скорость заказчика устраивает — то и нефиг ее повышать.
И даже если не устраивает — сначала ошибки убрать, а потом скорость повышать...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
KV>Я хотел сказать, что даже на железе, которое сейчас считается не самым производительным, чтобы занять все доступные ресурсы памяти и проца, нужно постараться и потратить на это некоторое время.
Без труда не вытащищь и рыбку из пруда
PD>>Ну а второе — что , не мог занять проц на 60% без написания своей программы ?
KV>"Это не наш метод" (с)
KV>Ну я же лазил пол-дня по git-у в поисках интересующих тебя определений
А кто все это начал ? Предожил мне найти ошибку в ядре Линукса при том. что я вообще первый раз в жизни вижу исходники этого ядра, да и с Линуксом не работаю, а теперь еще хочешь, чтобы я копался в тысячах его файлах ? . Да еще выясняется, что вся линуксовская конница и вся линуксовкая рать до сих пор причины этой ошибки найти не могут
KV>>>Да, меня это тоже удручает. К сожалению, в .NET еще встречаются задачи, когда полностью абстрагироваться от окружающей тебя ОС не получится при всем желании PD>>И никогда не перестанут встречаться.
KV>Это почему?
Потому что для того, чтобы абстрагироваться от реальной ОС, надо реализовать .NET на абстрактном компьютере
KV>Дык я ж не предлагал переходить на .NET. Я говорил о добровольном ограничении свободы (например, в рамках того С++)
А на С++ мы это и делаем. Свобода — это ответственность. Я могу делать все, что хочу, но это не значит, что я буду делать бог знает как. Если буду — я только себе проблемы создам. В нормальной ситуации я всегда предпочту более безопасные решения, которые мне меньше проблем создадут. Но в случае чего я всегда знаю, что могу взять управление на себя. То есть сказать (самому себе) — я отказываюсь от всех защитных механизмов, полностью беру ответственность на себя и буду делать, что хочу, а если сделаю не так — сам и виноват, сам и плакать буду. Но зато я действительно могу делать что хочу.
Это как в авиации. Лучше лететь на автопилоте. Надежно и безопасно. Но если вдруг надо сделать мертвую петлю, то я сомневаюсь, что автопилот такое позволит. В этом случае летчик говорит — беру управление на себя и делает ее. Если грохнется — сам и виноват.
KV>Во-во. А потом указатели на пайпы в ядрах обнуляться начинают
Бывает. Но!
Я, скорее всего, ошибку там не найду, тем более, что люди, намного лучше меня в Линуксе разбирающиеся, ее найти не могут. Но давай подумаем немного о ее характере.
Это ведь логическая ошибка. Да, есть некая вероятность , что зануление i_pipe есть следствие некорректного доступа к памяти откуда-то еще. Но скорее всего это не так. Все корректно, кто-то ставит его в NULL при том, что делать это не должен в этой ситуации (точнее, не должны ему были позволить).
Допустим, это было бы на .NET
inode->i_pipe->readers++;
Здесь вместо доступа по NULL (кстати, я не понял, почему при этом в Линуксе чего-то вроде BSOD не происходит — явно же необработанное исключение в режиме ядра, Windows такое не прощает) было бы исключение. С записью в лог стека и т.д. Отлично. Это дало бы возможность быстро найти ошибку. Но ее и так нашли, как видишь. А вот как .NET помог бы найти причину ошибки ? Кто-то поставил i_pipe в NULL (nul), и что ? И в С поставил, ив С# поставил бы. Само по себе присваивание ему NULL есть действие корректное и никаких возражений вызвать не может. Так что имеем явный повтор того, о чем я пару дней назад писал — логическая ошибка, для обнаружения которой нет иных средств, кроме того органа, что в черепной коробке находится.
PD>>И вообще должен сказать, что до появления .NET этому вопросу (выход индекса), как бы это помягче сказать и никого не обидеть... не уделялось слишком большого внимания при обсуждении проблем программирования.
KV>Ну конечно. А то, что перечислено хотя бы здесь — понапридумывали после выхода .NET?
Не напридумывали. Все верно, проблемы есть. Вертолеты иногда падают. Потом вносят в их конструкцию изменения, после чего они падают реже, но все равно падают. Полную гарантию дает только страховой полис
PD>>Да и вообще, что такое выход индекса ? Это логическая ошибка, это неверное вычисление функции (в широком смысле слова). Одна из многих возможных логических ошибок. Что в формуле для корней вместо минуса плюс поставить, что в массиве из n обратиться к n-му элементу.
KV>Это одна из возможных ошибок, позволяющих изменить поток управления текущего процесса. Любая уязвимость — одна из возможных логических ошибок, разница лишь в уровне абстракции, на котором она совершается
Совершенно верно. Одна из. Не самая главная и не самая важная. Но очень уж на виду и понятная даже младенцу. Вот с i_pipe младенцу не очень понятна. Скорее всего там нет выхода индекса, хотя бы потому, что нет индексов. А результат тот же.
>>>и про то, как именно ты определяешь попытки использования нулевого указателя?
PD>>Запусти
PD>> char* p = NULL; PD>> *p = 0;
PD>>и все сам увидишь.
KV>Попробовал: собралось, запустилось, крэшнулось на виндовом необработанном исключении доступа к нулевому адресу.
Ну вот и все. Если запустить под отладчиком — покажет строку. Исправляй Чего еще хочешь ?
KV>Потом попробовал переписать это в лоб на C#: не собралось с ошибкой "Указатели и буферы фиксированного размера можно использовать только в небезопасном контексте". Ок, добавим небозопасный контекст:
<skipped> Довольно забавно было читать про твои сражения с unsafe и типами
Но зачем же так сложно ?
Class c = nul;
c.Name = "aaa";
даст тебе в точности то же самое
KV>ну слава богу... собралось, запустилось и упало с CLR'ным NullReferenceException.
Что есть C# представление Access Violation, которое имеет место быть — доступ по нулевому адресу.
KV>Feel the difference, что называется.
А в чем разница-то ? Да, С++ программа не будет тебе выдавать CLR'ные исключения. Там просто исключение по доступу к памяти, EXCEPTION_ACCESS_VOLATION, если не ошибаюсь. Стек получить можно. В C# это же исключение перехватили, завернули в C# exception и выложили тебе. А мне его дают в голом виде. В чем разница-то.
(примерно так, я не проверял). И теперь оно завернуто в мой класс исключения. А можно было просто обработать, без перевыбрасоывания.
PD>>А я и не говорю, что ты утверждал. Я просто отмечаю, что те ошибки, от которых меня намерены защищать, есть 1-2% моих ошибок. А остальные 98% никакими тулзами и средствами не контролируются в принципе. И за эти 1-2% платить цену, о которой я говорил — не стоит, да и шум вокруг них поднимать такой уж нечего.
KV>Наличие цифры 1-2% говорит о твоей осведомленности по части общего числа всех ошибок в твоем коде, включая необнаруженные, вообще-то
Не понял. Почему ты так уверен, что я делаю гораздо больше, чем 1-2 % ошибок, связанных именно с выходом индекса, по сравнению с общим числом ошибок ? Вообще-то я помню считанное количество раз, когда я делал ошибку IndexOutOfRange, гораздо больше было иных. На порядок больше.
KV>Чисто в перемножении, действительно что-то придумать тяжело. Но оно же где-то используется? А тогда, навскидку, уязвимости арифметического переполнения еще никто не отменял
Арифметическое переполнение с плавющей точкой вызывает исключение.
>Если на данные из результирующей матрицы завязана какая-либо логика, то только в путь. Просто как пример.
Это и есть логическая ошибка — в данном случае, при безупречном алгоритме, не продумано, поместятся ли промежуточные данные в диапазон, допустиый для float-double.
KV>>>Неужели оно того стоит?
PD>>Стоит.
KV>Да не
Здравствуйте, IT, Вы писали:
IT>Я никуда не ухожу. Меня интересует прежде всего эффективность всего решения. Если к системе предъявляются серьёзные нефункциональные требования и заказчик за это готов платить, то он это получит, не переживай.
Что за нефункциональные требования у тебя там могут быть — не знаю и не хочу обсуждать. Я говорил именно о функциональных требованиях. Быстрее, черт возьми. Еще быстрее! А теперь еще быстрее.
IT>Конечно, возможна, я это вполне допускаю. Но как я уже сказал такое встречается довольно редко. Ты же пытаешься распространить свой крайний случай на всё программирование в мире.
Давай точки над i расставим.
Я не пытаюсь распространить свой крайний случай на всё программирование в мире. Ни в коем разе!
Я не пытаюсь доказать, что С++ нужно использовать для написания сайтов.
И т.д. я не пытаюсь.
Я просто утверждаю, что для разного рода задач нужны и должны использоваться свои инструменты. Где-то лучше всего Питон, а где-то С. Для данной задачи что лучше — Питон или С — обсуждать имеет смысл , если знать задачу, иначе не стОит. Поэтому априорные, без знания задачи, рекомендации неуместны.
А часто ли нужен Питон, С, С# или Хаскель — так ли это важно ? Для конкретной задачи и будем решать. А для другой будем решать заново.
И если ты готов то же самое повторить, иными словами, под этим подписаться — тогда нечего больше обсуждать.
Покажи мне хоть одно место, где я предлагал изничтожить, к примеру, C#. Не найдешь.
А вот что ты предлагал делать с теми, кто на С++ программирует, я не забыл. Напомнить ?
Так кто из нас терпимее к чужим мнениям ?
Вы ей-богу, как ранние христиане. Вам надо во что бы то ни стало все языческие культы изничтожить. Я (как язычник) говорю вам — ничего не имею против вашего бога, у меня богов много, одних я люблю больше, других меньше, я и вашего в этот сонм добавлю. А мне в ответ — веруй только в одного нашего бога, а иначе...
IT>А при чём здесь ты? Твои задачи — это капля в море и почему на эту каплю должно равняться всё море.
См. выше.
PD>>В теории совершенно верно, а практически не всегда возможна. Например, обработка производится 3dparty lib, свою написать — годы понадобятся, да и будет ли лучше... а вот оптимизировать то, что от меня зависит, я могу. Даже если это 1-2%.
IT>Да сколько угодно. Только то, что ты оптимизируешь сегодня под имеющееся у тебя железо, не факт что будет работать быстрее на завтрашнем.
Мне сегодня надо чтобы работало. Завтра видно будет. Завтра будут другие задачи и другие деньги.
PD>>Не согласен. Они определяются тем, насколько инструмент близок по своему духу машинному языку. Чем ближе — тем больше у меня возможностей, не переходя или почти не переходя на асм, написать наилушим образом. Что же касается выразительных и простых конструкций иных языков, то эта простотоа и ясность, вполне приемлемые в иных случаях, здесь проигрывают. По той простой причине, что высокоуровненвые конструкции неизбежно компилируются неким стандартным образом, без учета конкретной специфики. Ее полностью можно учесть в идеале на асме, а в реальности — на очень низкоуровневом ЯВУ.
IT>Под оптимизацию стандартных высокоуровневых конструкций, если ты не знал, затачиваются внутренности процессоров.
Расскажи подробнее, какие именно внутренности процессора заточены под ваш любимый SELECT из Linq.
>Ещё год назад ты говорил о 5%, сегодня уже об 1-2%, а что будет ещё через пару лет?
О чем речь идет-то ? В предыдущей моей фразе про проценты ни слова.
PD>>С точностью до наоборот.
IT>А ты сам-то пробовал писать на чём-то другом кроме C? Или это всё теории?
C#, Java, Fortran, PL/1, VB,, Asm, ну и кое-что по мелочи.
IT>>>До определённого момента они и не должны никого интересовать. Если же приложение слишком прожорливо, то здесь уже никакой C не поможет.
PD>>А что поможет ?
IT>Поможет пересмотр архитектуры.
А если ее нельзя пересмотреть ?
PD>>Задачи разные бывают.
IT>Это правда, только понимаешь ты это очень однобоко. Складывается впечатление, что они только у тебя разные бывают, а у остальных в точности такие как у тебя и другими быть не могут.
Ни из чего, что я сказал, это не следует. Если это только впечатление — значит, оно неверно. Если я такое говорил — ссылку в студию!
PD>>Если не трудно, расскажи, как можно оптимизировать эти матричные сложения на порядок по скорости. Я тебе благодарен буду до предела.
IT>Купи проц с 16-ю ядрами и сделай алгоритм многопоточным.
Многопоточность тут не поможет, я уже объяснил почему, идет пакетная обработка, так что все равно — одну матрицу разбивать или несколько обрабатывать. А вот насчет 16 ядер — не лукавь. Я тебя спросил — как можно оптимизировать. А ты мне в ответ — купи более мощное железо. Почему бы в таком случае не посоветовать — купи 16 компьютеров ?
IT>Напомни. А тебя тем временем ещё больше огорчу. С появлением Linq сегодня этот код у меня выглядел бы вот так:
IT>
IT>File.ReadAllLines("filename").Last();
IT>
IT>Свой оптимизированный вариант можешь не приводить, мне он не интересен.
Мой вариант был тогда еще приведен, и в нем ничего не меняется. А вот в твоем время замерь. Без LinQ ты проиграл в 33 раза
А здесь, я думаю, побольше. Судя по тому, что нахождение простой суммы чисел проигрывает в 4-5 раз отнюдь не С++, а C# без Linq
IT>Потому что для решаемой задачи, а именно для файла размером в 120 байт, моё решение будет более чем приемлемым.
А почему же ты тогда, предлагая свое решение (тогда еще, да и сейчас) не оговорился — оно хорошо будет работать для малых файлов, но для достаточно больших его применять не следует ? Если бы ты это сделал — я и возражать бы не стал, если там 120 байт — все равно, что делать. Но ты ведь предлагаешь свое решение как универсальное, не так ли ?
PD>>Для того, чтобы его сделать, надо как можно пониже уровнем спуститься. Не оперировать абстракциями как-то реализованными, а использовать те средста, которые требуют минимальных действий. А для этого надо работать не с высокоуровневыми, а наоборот, низкоуровневыми средствами. Иными словами, Fine Tuning.
IT>Не надо никуда опускаться. Данная задачка не стоит выеденного яйца Пушкина ни по временным затратам, ни по производительности. Таких задачек в день я решаю мильён. Если оптимизировать каждую, то жизни не хватит.
М-да, ну и аргументы...
With best regards
Pavel Dvorkin
Re[9]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, LaptevVV, Вы писали:
LVV>>В ваших рассуждениях только один минус — не видать что-то рисовалок, рестартующих после краха...
PD>А Word восстанавливает документ после краха. Open Office тоже. И более или менее успешно. FireFox после краха восстанавливает все табы.
А IE после краха восстанавливает NTFS и побитые системные библиотеки
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Например, неправильное форматирование строки в выходном документе — это, конечно, важнее, чем повысить скорость его генерации в 10 раз
Безусловно. И улыбки тут не уместны, чаще всего дело обстоит именно так.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Когда встанет задача обеспечить адаптацию уже написанного кода, который читает все строки, к большим файлам, я возьму и адаптирую его (а не перепишу заново).
PD>Его — перепишешь. Просто тот вариант не пройдет в принципе, поэтому придется сменить алгоритм. Ну хотя бы с IEumerable.
Две строчки скорее всего перепишу. Но если речь пойдет о задаче большей — буду пытаться адаптировать.
S>>Да, есть StreamReader.ReadLine(). Но он мне не совсем подходит, т.к. первоначальное решение использовало массив строк из File.ReadAllLines(). Безболезненно я ее могу заменить только на IEnumerable<string>. Потому StreamReader.ReadLine() придется обернуть в IEnumerable, чтобы не переписывать все решение.
PD>Хм... А стоит ли ? Обернуть, конечно, можно, но, честно говоря, сделать просто замену кода — работы на полчаса. Кстати, никакого IEnumerable пока что в варианте IT нет, это тоже надо делать.
Нет? А что там есть? Массив строк? Если честно, я его в точности не помню.
PD>Так не проще ли выкинуть его решение и сделать чтение по строкам(я сейчас абстрагируюсь от того, что это тоже не хорошо, временно допустим, что хорошо), чем насильно пытаться то решение адаптировать. Зачем ?
Конкретно в этой задаче может и проще. В других случаях будет проще адаптировать, даже не разбираясь в сути алгоритма.
S>>У меня некоторые пробелы на тему кодировок. Я вот не уверен, что при чтении файла задом наперед, или какими-то кусками не с самого начала, можно гарантированно идентифицировать символы конца строки.
PD>По крайней мере для ASCII-8, UTF-8 и Unicode 0D0A всегда на месте (для юникода, конечно, short). Что касается всех возможных на свете форматов — как говорится. я вам не скажу за всю Одессу. Но тут опять же истина конкретна. Если речь идет о возможности чтения всех и всяческих форматов — тогда стоит подумать. Ну а если ясно, что никаких экзотических форматов не будет — вперед и с песнями.
UTF-16 — экзотика? Нет, там символы перевода строки не кодируются, но это уже будет не 0D0A!
>>Это еще одна причина, по которой я бы текстовый файл читал только последовательно.
PD>Слишком дорогая плата. Ты обеспечишь, что программа будет корректно работать с экзотическими форматами, но заткнется на файле в 5-10 Гб (с IEnumerable по времени, в варианте IT — по нехватке памяти ). Я этот файл обработаю, но проблемы будут с экзотикой . ИМХО второе лучше.
Потом заказчик решит, что 5-10Гб текстового файла — слишком жестко для диска (или передачи по сети). И предложит зазиповать тексты.
Вот тогда мы с IT изменим одну строчку, а тебе придется опять переписать все!
Но это все к теме о выдумывании условий, чтобы коню в вакууме скучно не было.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ты даже простую вещь не понимаешь. Взять 16 ядер — это не ускорение алгоритма. Это использование дополнительных ресурсов при неизменной (а то и хуже) скорости алгоритма. С таким же успехом можно предложить вместо Pentium 100 взять Pentium 4 3000 и сказать — мы ускорили в N0 раз. Ничего тут не ускоряется и нет никаких заслуг программиста в этом.
Это ты Гуглю расскажи, а то они за каким-то вместо одного большого компьютера и оптимизации алгоритма пользуют сотни тысяч средненьких серверов и затачивают свои алгоритмы под распределённую многопоточную среду.
Полировка алгоритма даст тебе в лучшем случае проценты, а наращивание железа даёт легко разы. Но алгоритм при этом должен быть заточен для работы в таких условиях. Буржуи такое свойство алгоритма называют иностранным словом scalability — масштабируемость, расширяемость. И это свойство именно алгоритма, а не дополнительных ресурсов, как ты изволил выразиться.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здесь Павел прав, если я правильно его понимаю. Требования к максимальному отклику тех или иных компонентов системы вполне могут быть внесены в функциональные требования в том случае, если их невыполнение делает ничтожными значительную часть функционала системы, либо если этот параметр определяет непосредственно функциональность системы (например, если система предоставляет функционал по взаимодействию сторонних систем в режиме реального времени).
KV>Точно так же, как и требования по безопасности (в большинстве случаев, входящие в НФТ), могут и должны быть вынесены в ФТ в случае разработки систем безопасности и противодействия информационным угрозам (IDS, FW, антивирусы и т.п.)
Тогда я не понимаю. Функциональное требование, это то, что должна делать система.
Пример: система выдает список заказов — функциональное требование. Но очень важно, что время выполнение этой функции не более 2х секунд. Это нефункциональное требование.
Если есть важное нефункциональное требование, вроде времени в системах реального времени, то это не делает его автоматически функциональным.
AVK>А хамло удалять нужно тем более. Товарищь получил совершенно заслуженный бан.
Да тут общая проблема в том, что русский язык (и не только) позволяет говорить/писать грубости и без перехода на личности, а этот момент не наказывается модераторами. От того многие "поднаторевшие" форумчане этим охотно пользуются для изливания безнаказанного неконструктива (некоторые весьма из популярных на этом ресурсе в т.ч.). Достаточно применнить аллегорию — и вот вроде уже никакой личности, а собеседник, извините, обгажен по полной.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, FR, Вы писали:
FR>>Да нормально они к C++ прикручиваются, я подобные классы еще когда NET не было использовал:
PD>Речь идет об интерфейсах. Их в языке С++ нет.
В языке С++ есть чисто абстрактные классы, также есть шаблоны с утиной типизацией, так что не вижу
проблем чтобы прикрутить.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да мне хоть так, хоть этак, хоть с энумератором, хоть вообще без него. Я просто говорю — если по ходу прямого перебора строк нужно вдруг получить последнюю, придется делать новый view. А обертку делай какую хочешь.
Да, я в курсе, что ты любишь менять и усложнять задачу по ходу дела. Просто последнюю строку брать уже неинтересно (описали же уже не раз как это можно) — начит надо собеседникам подкинуть какое-угодно усложнение.
Здравствуйте, Pavel Dvorkin, Вы писали:
F>>Да, я в курсе, что ты любишь менять и усложнять задачу по ходу дела. Просто последнюю строку брать уже неинтересно (описали же уже не раз как это можно) — начит надо собеседникам подкинуть какое-угодно усложнение.
PD>Читать топик внимательно надо PD>http://www.rsdn.ru/forum/philosophy/3688862.1.aspx
Да-да, ты мог бы прямо тут привести эту цитату, чтобы все видели, что там ничего про 1-2 view не говорилось, а только про то, как вообще возможно в процессе обычной энумерации обратиться к Last. Что, разумеется, никакой сложности не представляет. И тут вдруг бац — джокер — меняем задним числом условие на то, что view должна быть ровно одна, и все вокруг оказываются дураками.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Точный совет можно дать только зная точные приоритеты решаемой задачи. А об этом позаботиться, если ты всё ещё не понял, должен тот, кто спрашивает совета. Если человека волнует в первую очередь производительность, то об этом должно быть оговорено в самом начале. Если такого требования нет, то в современном софтостроении на первый план выходят совсем другие приоритеты. И таких случаев на порядок больше.
PD>Если это даже и так, то человек, который берется давать советы, должен в первую очередь поинтересоваться требованями и ограничениями. Ничего такого ты не сделал, а прямо с лету дал свое решение, не зная ничего о задаче.
Ну так IT же дал самое простое решение, стоящее 10 секунд времени. Ну не подойдет оно — спрашивающий уточнит требования. Но времени своего на испытание предложенного решения он много не потеряет. А до тех пор пока он их не указал — их можно считать несущественными
Не нужно бежать впереди паровоза и создавать какое-то "оптимальное" решение по неуказанным ограничениям. Нужно либо спрашивать по ограничения, либо прелагать наиболее простой способ, который позволит, тем не менее, в большинстве случаев решить задачу.
Хуже того — считать последнюю строку файла (как и перемножить две матрицы) — это не задача реальной жизни. Это может быть задача только в универе на занятиях. В реальной жизни задача более глобальна и формулируется по бизнес-требованиям, которые она должна решить. А собственно операции перемножения матриц или взятия последней строки из файла — это уже отдельные подзадачи (методы, модули, задания кодерам), и совершенно не факт, что наиболее узкие места будут именно в них.
В реальной задаче, столкнувшись с проблемой, что файлы стали уже по 500Гб и кусочек кода от IT с получением последней строчки жутко тормозит — там, может быть, применят оптимизацию, и перепишут этот маленький кусочек кода в боле большой и умный. А может быть просто решат (по совокупности показателей всей задачи с файлом же наверняка делают и что-то еще, кроме взятия последней строки), что файл тут уже не оправдывает себя и надо вместо него использовать СУБД. В результате задача остнется, а проблема взятия последней строки файла полностью исчезнет из нее.
Здравствуйте, samius, Вы писали:
S>Вернет последнюю строку если хватит памяти чтобы затолкать все строки. Единственная проблема ReadAllLines в том, что он читает все строки файла за раз и возвращает массив. Возвращал бы IEnumerable через yield return — не было бы проблем.
Наконец-то в 4-м фрейморке это дела пофиксят, добавив File.ReadLines. И memory-mapped files добавят. Не то чтобы раньше это все самостоятельно не решалось, но удобно что в самом фрейморке будет.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Исходный код — будет, не спорю, а эффективность — наоборот. Тебе про чтение последней строки из файла напомнить ? . F> Напомни мне, плиз!
Здравствуйте, Alexey Voytsehovich, Вы писали:
AV>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Господь с тобой, какая тут СУБД. Чтобы взять из файла любой длины последнюю строчку, совсем не надо все остальное читать. Надо именно последнюю строчку.
AV>а можно ссылку на оригинальное задание про последнюю строку?
Здравствуйте, Flem1234, Вы писали:
F>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>Еще раз. Быстродействие входит в число функциональных требований. При недостаточно высоком — решение просто не рассматривается.
F>>>Не хотите статью на rsdn написать? Это новое слово в разработке требований.
PD>>Этому новому слову лет так 50. Почитай, к примеру, про real-time приложения, если нет реакции за фиксированное время — решения нет.
F>Ухты! real-time приложения! Круто! Если "решения нет за фиксированное время — решения нет" верно, значит быстродействие входит в число функциональных требований. Если "я сегодня не завтракал" верно, то 2*2=5! Еще круче!
Здесь Павел прав, если я правильно его понимаю. Требования к максимальному отклику тех или иных компонентов системы вполне могут быть внесены в функциональные требования в том случае, если их невыполнение делает ничтожными значительную часть функционала системы, либо если этот параметр определяет непосредственно функциональность системы (например, если система предоставляет функционал по взаимодействию сторонних систем в режиме реального времени).
Точно так же, как и требования по безопасности (в большинстве случаев, входящие в НФТ), могут и должны быть вынесены в ФТ в случае разработки систем безопасности и противодействия информационным угрозам (IDS, FW, антивирусы и т.п.)
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, samius, Вы писали:
S>>На РСДН уже видимо правило хорошего тона: если не разделяешь точку зрения человека — просклоняй его /*или фамилию, если доступна*/.
IT>Пойти в дворкины — заняться выжиманием битов из байтов.
Ну вот, опять, только потоньше...
S>>Пол беды, когда это делают пользователи, но от админа
IT>Тут согласен. Погорячился, был не прав. Приношу свои извинения.
Не мне, я не обиделся, только децл удивился.
Re: Павлу Дворкину: о понимании того что делаешь и простых п
KV>Я бы так сказал — язык С++ дает мне свободу делать все, что я хочу. А это неизбежно сопряжено с возможностью сделать и ошибку. Чтобы свободой как следует воспользоваться, надо хорошо понимать, что при этом можно, и что нельзя делать.
... и обязанность делать то, что я не хочу.
Pro
Re: Павлу Дворкину: о понимании того что делаешь и простых п
Ну спасибо. Чтобы мое имя прямо-таки профигурировало в названии топика — такого еще не было. Да и других тоже что-то не упомню, хотя были, наверное, но не часто.
По существу отвечу завтра, надо и подумать, да и поздно уже. У меня как раз примерно час поездки домой, успею продумать.
KV>Не так давно от Павла прозвучало
KV>Я бы так сказал — язык С++ дает мне свободу делать все, что я хочу. А это неизбежно сопряжено с возможностью сделать и ошибку. Чтобы свободой как следует воспользоваться, надо хорошо понимать, что при этом можно, и что нельзя делать.
KV>Я вот сижу и думаю, а может ну ее нафиг эту свободу, а? А то получится как с ядром линукса
Ну а по поводу линукса вообще и этого примера в частности — no comments, так как не имею в с ним дела. Впрочем, это лишь пример, как я понимаю, но в своем ответе я его обсуждать не буду.
With best regards
Pavel Dvorkin
Re: Павлу Дворкину: о понимании того что делаешь и простых п
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я вот сижу и думаю, а может ну ее нафиг эту свободу, а?
Давайте таки оставим программисту право выбора.
Я совершенно разделяю возмущение по поводу описанной баги, но не вижу необходимости в тотальном запрете инструмента только потому, что далеко не все умеют им безопасно пользоваться.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Ты так говоришь, как будто ее возможно у вас отобрать
Просто не хочется очередной холивор "что-то vs C(или C++)"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[2]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну спасибо. Чтобы мое имя прямо-таки профигурировало в названии топика — такого еще не было. Да и других тоже что-то не упомню, хотя были, наверное, но не часто.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И тут опять мои опппоненты юлить начинают. Мемори ликов у тебя не будет. Ладно, говорю, спасибо, хотя у меня их и так не много, инструменты для их обнаружения есть. Индекс у тебя за пределы массива не выйдет. Тоже спасибо, отвечаю я, он и так у меня как правило не выходит, если только я сам не хочу, чтобы он выходил. Что там еще ? Уничтоженные объекты не будешь использовать. Тоже спасибо, хотя и так попытка взятия по NULL определяется без особого труда.
PD>А от логических ошибок вы меня оградите ? От ошибок алгоритма или его реализации ? От того, что я при вычислении корней уравнения вместо b*b-4*a*c написал b*b+4*a*c ? От того, что я понимал эту задачу так-то, а она, оказывается, выглядит совсем не так, но это проявляется в одном случае на миллион ?
Проблема в том, что голова не безразмерная и чем больше думаешь про "мемори-лики", тем меньше про логику программы
PD>С IndexOutOfRange я как-нибудь и так справлюсь, а вот с этим-то что делать ? Поможете ?
ну и аргумент, охренеть — ваша кофеварка не умеет стирать бельё!??? в топку её!
Re[3]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, gandjustas, Вы писали:
GZ>>Уважаемый. А вам не кажется что вышеописанное ортогонально языку, и подобное можно сделать практически на любом языке. G>Ага, пример на .NET в студию.
Net — это не язык. Net — это платформа исполнения.
GZ>>Хотя для некоторых придется проявить выдержку, спокойствие и сообразительность? G>Там где сборка мусора такое сделать почти невозможно.
Тут вопрос цены ошибки. Если ты получишь NullReferenceException в ядре в неожиданном месте, то ненамного лучше не станет. В С++ кроме указателей есть много других опасностей.
1. Иметь возможность делать все, что я хочу. Аппаратура мне нужна только постольку поскольку она поддерживает высокоуровневые конструкции языка.
2. Чтобы в этом коде было как можно меньше ошибок. Это для меня самое важное.
3. Чтобы программа имела хорошую архитектуру.
4. Чтобы я на это потратил как можно меньше своего времени.
5. Чтобы это работало как можно более быстро и потребляло ресурсов как можно меньше.
Вывод: есть разные типы программистов с разными приоритетами.
Re[3]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, blackhearted, Вы писали:
A>>>А может тогда сразу нафиг программирование — и в дворники?
B>>блин...а я прочитал — ...в Дворкины...
IT>Уж лучше в дворники, чем в дворкины?
На РСДН уже видимо правило хорошего тона: если не разделяешь точку зрения человека — просклоняй его /*или фамилию, если доступна*/.
Пол беды, когда это делают пользователи, но от админа
И в чей адрес? Человеку, который всегда как минимум тактичен с собеседниками, даже если они этого не заслуживают...
Re[4]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, A13x, Вы писали:
A>Словом я уверен, что и C# не панацея. A>No silver bullet. A>А жаль.
Проблема не в том, что мы совершаем ошибки, проблема в том, как быстро мы их выявляем и как эффективно устраняем. Выйти, например, за пределы массива можно в любой среде. Но если в управляемой мы сразу же получим вполне вменяемую диагностику и точное местоположение ошибки, то в неуправляемой мы получим испорченную память и далеко и в разные стороны идущие последствия.
Что касается Бленда, то думаю, что на C такого класса продукт вообще сделать сегодня не реально. А проблемы в нём нужно искать не в используемой среде, а в архитектуре, кривых руках и посредственном тестировании.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Прикольно, а зачем по-твоему я тогда его сюда вставил? Но ок, буду ждать. PD>У меня сейчас лекция, после нее отвечу.
А у меня случился больничный , и под рукой ядра нет, а лазать по git'у через GPRS — долго и нудно. В общем, предлагаю перенести обсуждение конкретно этого кода на следующую неделю, ок?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Т.е. тебе необходимо ощущение того, что ты можешь сделать все что захочешь под конкретной ОС (именно ощущение, т.к. меня терзают смутные сомнения о частоте возникновения потребности в написании драйвера при решении повседневных задач).
Верно. Кстати, драйверы я не писал.
PD>>2. Чтобы это работало как можно более быстро и потребляло ресурсов как можно меньше. Я пишу не серверное ПО, а моя ОС не MS-DOS, так что работать это все будет в коммунальной квартире, а поэтому ванную занимать на 3 часа нечего и свет в туалете надо тушить.
KV>Знаешь, у меня был рабочий (конторский ноут) с одним ядром на полтора гигагерца и одним гигом оперативки. Однажды я подошел к коллеге, который отвечает в ИТ за апгрейды оборудования для рабочих мест и спросил, что нужно сделать, чтобы заменить себе ноут на более мощный? Он ответил, что по старой дружбе, правильного скриншота закладки "быстродействие" из диспетчера задач, на котором будет наглядно показано, как мне грустно работается на текущей конфигурации, будет более чем достаточно. Казалось бы, простая задача — занять проц на 70-80% (не на 100% — чтобы не палиться) и вызвать безудержный своп. Попробуй решить ее на C# (на самом деле, это легко, но тогда я еще не владел дао управления памятью в .net)... Мне это удалось минут через 15-20 борьбы с GC и при этом прога проработала около 5 минут, прежде чем началось то, что мне было нужно. С тех пор у меня двухядерный ноут на 2,5 гигагерца с 4 гигами оперативки
KV>Намек, думаю понятен...
Не очень. Честно говоря, я просто не понял, что ты хотел сказать. Если ты не зная .NET, сумел это сделать через 15 мин, то значит, это не так уж сложно. Ну а второе — что , не мог занять проц на 60% без написания своей программы ?
PD>>Первый мой вопрос — а как с п.1 и 2 будет. Гарантируете ли вы, что я по-прежнему смогу делать все. что я умею делать, использовать все те возможности ОС, которые умею использовать ? И будет ли это работать столь же быстро и требовать ресурсов не больше ?
KV>Я прямо сейчас, безотносительно языка, могу гарантировать, что это тебе не нужно в 80-90 процентах решаемых тобой задач
Мне это нужно в 99% моих задач. Говорю совершенно честно. От меня основное что требую — время, время и еще раз время. А сам я при этом себе добавляю как требование — при этом еще и память, память, память. Потому что знаю , конечно. что время и память конкуренты (и выбор, конечно, всегда сделаю в пользу времени), но и памяти чем меньше возьму, тем меньше и времени на ее обработку уйдет.
PD>>Как только я этот вопрос задаю, так сразу мои оппоненты начинают юлить.
KV>Они просто пугаются, т.к. думают что ты работаешь на оборонку и пишешь софт для ядерных боеголовок
Упаси боже. Я человек совершенно мирный и занимаюсь совсем прозаической деятельностью. Просто те задачи, которыми я занимаюсь, едят процессорное время безбожным образом.
PD>>Сможешь , наверное, только вот иногда тебе придется на неуправляемый код переходить, а иногда и вообще не получится. Но ты мол, не огорчайся, если не получится, то это значит, что тебе такое и не надо, мы тебе другое предложим... И работать это будет быстрее. Ах, у тебя все же медленнее получается... Ну значит , ты неправильно меряешь, не на тех тестах , и вообще имей в виду — в светлом будущем наш код намного лучше будет. Светлое будущее обещать они очень любят.
KV>А можно взглянуть на реальную (не надуманную задачу) где быстродействие, достижимое на управляемых платформах является неприемлемым, из твоей практики? А десяток таких задач?
Ничего себе заявление! Я, значит, должен был десяток задач решить на .NET, чтобы удовлетворить твое любопытство ? Мне , чтобы убедиться в том. что .NET здесь не пойдет, десяток реальных задач решать незачем. Достаточно несколько тестов пропустить, что я когда-то и сделал, получил проигрыш в 1.5-2 раза (это еще до LinQ было, ну а с ним — 4-5 раз, недавно тут как-то обсуждали). И зачем, спрашивается, после этого я буду писать код реальной задачи (и кто мне будет за это платить ?), если тесты мне показывают. что я явно потеряю в быстродействии ?
PD>>Ну насчет скорости — мы тут уже столько копий сломали, что вряд ли стоит еще одно ломать. А вот насчет возможностей... Никакой я не специалист в C# и .NET, я там просто дилетант, не более. Но тем не менее мне неоднократно доводилось давать советы в форуме по .NET, причем за эти советы я получал баллы в рейтинге.
KV>*закадровый шепот* Павел, я тут за такую фигню, вообще не имеющую отношения к программированию, пол своего рейтинга заработал...
Э нет, не пойдет. Безопасность — дело серьезное, даже если специалист по ней не программист вообще.
KV>Да, меня это тоже удручает. К сожалению, в .NET еще встречаются задачи, когда полностью абстрагироваться от окружающей тебя ОС не получится при всем желании
И никогда не перестанут встречаться.
PD>>Хорошо, конечно. Что я еще могу сказать! Вы предлагаете мне отказаться от свободы, но в ответ обещаете, что я смогу писать код без ошибок ? Да — мне в ответ. PD>>Без любых ошибок ?
PD>>И тут опять мои опппоненты юлить начинают. Мемори ликов у тебя не будет. Ладно, говорю, спасибо, хотя у меня их и так не много, инструменты для их обнаружения есть. Индекс у тебя за пределы массива не выйдет. Тоже спасибо, отвечаю я, он и так у меня как правило не выходит, если только я сам не хочу, чтобы он выходил. Что там еще ? Уничтоженные объекты не будешь использовать. Тоже спасибо, хотя и так попытка взятия по NULL определяется без особого труда.
KV>Тебя это просто перестанет беспокоить с переходом на .NET А если это сейчас тебя и так не беспокоит, то и переходить на .NET, пожалуй не стоит.
Так я это и утверждаю. Ты же меня на дискуссию вызвал, ну вот я и отбиваюсь
>Но мне вот что интересно: можно чуть подробнее про поиск ликов
VLD, Bounds Cheker (раньше).
>(и его достоверность)
Да ловит вроде. Тот же VLD — просто работа с CRT, проход по куче. То же самое, что и в .NET, только никто ничего не освобождает.
Ну а на худой конец
void* mymalloc(size_t size)
{
// add to list
return malloc(size);
}
и соответствующий myfree. Впрочем, это на С. Для С++ немного посложнее.
>про основу твоей уверенности в том, что индексы не выходят за предел
Если уж очень надо, то
class Wrapper
{
int& operator[](int index)
{
if(index > ... || index < ...
А вообще — не надо. Он и так выходить не должен. Он у меня и на Фортране никуда особенно не выходил, а там вообще говорить о проверке можно с натяжкой
И вообще должен сказать, что до появления .NET этому вопросу (выход индекса), как бы это помягче сказать и никого не обидеть... не уделялось слишком большого внимания при обсуждении проблем программирования. Выходят у тебя индексы — исправь, что надо, а оповещать весь мир об этом как-то считалось дурным тоном и признаком невысокой квалификации. А тут из мухи сделали слона. Да и вообще, что такое выход индекса ? Это логическая ошибка, это неверное вычисление функции (в широком смысле слова). Одна из многих возможных логических ошибок. Что в формуле для корней вместо минуса плюс поставить, что в массиве из n обратиться к n-му элементу.
>и про то, как именно ты определяешь попытки использования нулевого указателя?
Запусти
char* p = NULL;
*p = 0;
и все сам увидишь.
PD>>А от логических ошибок вы меня оградите ? От ошибок алгоритма или его реализации ? От того, что я при вычислении корней уравнения вместо b*b-4*a*c написал b*b+4*a*c ? От того, что я понимал эту задачу так-то, а она, оказывается, выглядит совсем не так, но это проявляется в одном случае на миллион ? С IndexOutOfRange я как-нибудь и так справлюсь, а вот с этим-то что делать ? Поможете ? PD>>А в ответ — либо тишина, либо рассуждения о светлом будущем, когда весь код будет верифицироваться (надо полагать, верификатор будет распознавать подпрограмму вычисления корней уравнения, знать этот алгоритм и подскажет мне — ты там плюс вместо минуса поставил Остается только понять — почему он в таком случае за меня программу сам не написал.)
KV>Тут затрудняюсь что-либо прокомментировать, т.к. ничего подобного лично я не утверждал
А я и не говорю, что ты утверждал. Я просто отмечаю, что те ошибки, от которых меня намерены защищать, есть 1-2% моих ошибок. А остальные 98% никакими тулзами и средствами не контролируются в принципе. И за эти 1-2% платить цену, о которой я говорил — не стоит, да и шум вокруг них поднимать такой уж нечего.
PD>>Тот код, который ты показал, при определенных условиях вполне безупречен.
KV>Он не безупречен по одной лишь причине: у его разработчика не было ни малейших оснований предполагать, что указатель на пайп не может быть нулевым при входе в функцию, либо после входа в функцию, но до установки мьютекса.
Еще раз. Кода установки не видел, но
1. Мютекс надо создавать до указателя на пайп, а уничтожать — после.
2. Если это сделано, и операции с пайпом стоят под мютексом, то предполагать такое вполне можно. Войти в функцию при нулевом пайпе просто не удастся, мютекс не пустит.
PD>>И вот эти логические ошибки меня больше всего и беспокоят. Они у меня львиную часть времени съели. А не выходы индексов и прочая чепуха.
KV>Эта самая "чепуха" занимает 45% от всех уязвимостей, когда-либо публиковавшихся на secunia (один из наиболее авторитетных и полных источников подобной информации). Поэтому меня эта чепуха также беспокоит. Впрочем, как и логические ошибки, если быть честным.
А меня логические ошибки беспокоят, а безопасность — абсолютно нет. Ну какая может быть безопасность в задаче перемножения матриц, например ? Индексы пусть где попало не бегают, NULL вместо матриц не используй и не будет никаких угроз
PD>>Резюмирую. Готов ли я отдать свою свободу (в программировании, конечно, только там) за что-то ? Пока не дадите твердого ответа на п.1 и 2. — категорически не готов. А когда дадите — тогда поторгуемся по п.3. Пока хорошо не заплатите — тоже не отдам.
KV>Неужели оно того стоит?
Стоит.
KV>P.S: Про вертолет, как я понимаю, это было в отместку за "простреленные ноги"?
Здравствуйте, IT, Вы писали:
PD>>Бизнес (в твоем понимании) — пожалуй, да, так как там царит, похоже, принцип — хоть как, но быстрее, давай-давай. Впрочем, есть и другие бизнес-задачи, и там это вполне работает (в моей работало).
IT>Это всё домыслы. В решении бизнес задач царит принцип эффективности.
Эффективности чего ? Работы программиста или конечного кода ?
>Писать сегодня код на C дорого
Да
>медленно
Да
>не эффективно
С точки зрения времени работы программиста — да. С точки зрения эффективности рабочей программы — наоборот.
>Тоже самое касается и системных задач, но в них требования к потреблению ресурсов могут оказаться приоритетнее. Там, где в системных задачах ресурсы мало кого интересуют, тоже используются более эффективные инструменты, чем C.
Да. Но только когда ресурсы мало кого интересуют.
With best regards
Pavel Dvorkin
Re: Павлу Дворкину: о понимании того что делаешь и простых п
KV>Я бы так сказал — язык С++ дает мне свободу делать все, что я хочу. А это неизбежно сопряжено с возможностью сделать и ошибку. Чтобы свободой как следует воспользоваться, надо хорошо понимать, что при этом можно, и что нельзя делать.
KV>Я вот сижу и думаю, а может ну ее нафиг эту свободу, а? А то получится как с ядром линукса
: KV>"Суслика видите? А он есть..."
Ну это примерно так же, как запретить кухонные ножи. Ведь дети могут порезаться! Да и вообще — мало ли ножами кухонными друг-друга режут!?
ИМХО, нужно просто лучше готовить профессионалов. Чтобы любители с ними близко не стояли по квалификакции... Тогда и не будет таких ляпов...
И устаканить в мозгах постулат: НАДЕЖОСТЬ ВАЖНЕЕ ЭФФЕКТИВНОСТИ!!!!!!!!!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, gandjustas, Вы писали:
G>>>Продолжай мысль: потратиться на железо дешевле, чем оптимизировать программу. Особенно это касается памяти.
PD>>Доказательства в студию. G>Месяц работы программиста — от 30000 до 80000 рублей. Гигабайт оперативки стоит меньше 1000р. За месяц работы программиста можно купить неплохой компьютер.
Замечательно. А теперь иначе посчитаем.
ПО работает на 1000 компьютеров. Стоимость компьютера примем за 1000 USD. На каждом компьютере должно быть установлено еще некоторое 3dparty ПО, лицензия на место стоит 5000 USD.
Мне удается оптимизировать на 1% всего. Ничтожно мало, по мнению многих. Но это значит, что вместо 1000 компьютеров хватит 990.
10 компьютеров * (1000 + 5000) = 60,000 USD.
Стоит ли дать мне возможность сделать это за месяц , заплатив от 30000 до 80000 рублей ( от 1000 до 3000 USD) ?
PD>>Если продукт не работает с минимально требуемой скоростью — он не продукт. G>Правильно. Какая скорость работы минимально требуется? И как её определить?
Как мы ее определяем — рассказывать не буду, но определяем, не беспокойся. А требуется — как можно больше. По причине, о которой я сказал чуть выше.
G>Для этого надо как минимум написать программу чтобы она была коректной
А мы не занимаемся некорректными программами. Но и писать их так. чтобы они изначально были медленными, тоже не хотим.
G>Определись для начала что такое скорость работы. Для пользователя это время отклика интерфейса, а не время полной обрабоки.
А если нет ни интерфейса с пользователем, ни пользователя в обычном смысле слова ? А есть просто обработка данных, поступающих из некоторого источника ?
G>Например в каком-нить ICQ, skype или jabber я предпочту сразу отправлять сообщения, не додижаясь сообщения о подтверждении (чтобы они приходили асинхронно), чем ждать пока сообщение будет доставлено (синхронно).
При чем это тут ? Это совсем другой вопрос.
G>Кроме того визуальный feedback длительной операции уменьшает воспринимаемое время работы, хотя увеличивает реальное время работы.
И это тоже.
G>Про 80%/20% слышал? Максимум придется переписывать 20%, если тормоза не заложены в архитектуре (как с mutable строками).
Слышал.
G>>>А с чего ты взял что на С буждет потребляться меньше ресурсов (и каких ресурсов вообще)? PD>>Я это обосновывал не раз, новых аргументов нет. Прежние ты знаешь. G>Да ты ниче не обосновывал. Максимум приводил тривиальные примеры, которые вообще ничего не доказывают.
Ну не доказывают они тебе ничего, ну и ладно. Не могу же я специально для тебя годовой проект сделать, чтобы что-то доказать.
G>>>Напиши highload сайт полностью на С\C++. PD>>Что за чепуха ? Когда это я предлагал сайты на С/C++ писать ? Он совсем не для написания сайтов! G>А для чего? Если че — написание для веба на сегодня одна из самых востребованных областей.
Я не занимаюсь вебом и не предлагаю использовать там С++. И то, что эта область востребована в бизнесе, отнюдь не отменяет то, что есть другие области и там другие законы. Пойми это.
Здравствуйте, gandjustas, Вы писали:
N>>>>Для разнообразия предлагаю тебе, gandjustas, написать безопасное приложение, которое будет работать на видеокарте с CUDA SDK. Потренируйся, посмотри что это практически невозможно. (Даже стандартный пример с рекомендуемыми дровами, на рекомендованном оборудовании может вызвать синий экран.) G>>>Ну я писал такое, и что? N>>Не верю. G>Твое право.
То есть фактов не будет. Очень сильный ход с твоей стороны.
N>>Безопасности нет в самой платформе, следовательно нет и в твоём приложении. Всё просто, тут не поюлишь. Если не веришь мне, то поищи отзывы в интернете "лестные" отзывы о драйверах NVidia. G>Верю, в данном случае надежность не зависит от того что я напишу, поэтому меня не парит.
То есть написание небезопасных программ уже допускается. Хорошо!
G>Большинство — ускорение существующих программ. То есть приходим к тому же: сначала реализуется рабочее решение (желательно надежное), а потом оптимизируется, например с помощью cuda.
Не всегда. Ещё один пример из жизни: определение нарушений правил дорожного движения. По изображению с одной камеры определяются нарушения, а другая, снабжённая поворотным механизмом, должна успеть навестись на номер нарушителя и распознать его. Машины ездят быстро, всё надо делать очень быстро. Так вот, к чему всё это: медленный и надёжный вариант не подойдёт. Никак. Его даже на работоспособность не проверишь. Такой пример подойдёт?
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
N>>>Тут важнее именно производительность. G>>Производительность чего? G>>... G>>Быстродействие чего? G>>... G>>В итоге. Основная задача — быстро снять изображение. Обработка его быстрой быть не обязана, её вполне можно раскидать на кластер. А при желании ускорить с помощью CUDA.
N>Нет, надо в реальном времени распознать нарушение, предсказать положение нарушителя на время, в течение которого камера с поворотным механизмом сумеет навестись на номер, вычислить координаты, навести камеру, поймать изображение с номером. Иначе нарушитель-то уедет, он ждать не будет, пока его распознают. Вот тут производительность системы (быстродействие каждого этапа) очень важны.
Нарушитель все равно будет ждать когда штраф ему придет по почте. Поэтому надо снять изображение, а как быстро оно обработается уже неважно. Возможно после обработки окажется что нарушений нет. Даже если система зафиксирует выезд на встречку, то возможно это был объезд сломавшегося автомобиля (те нарушения нет), а это должен определить человек, который точно медленнее компьютера сработает.
Не надо приявзяваться к тяжелым расчетам для realtime реакции.
N>Не обязательно использовать CUDA, можешь всего достигнуть на процессоре — пожалуйста. Но все алгоритмы реализуются без оглядки на скорость разработки, тут главное, чтобы вся система успела отработать. Не успеет — твой медленный и надёжный продукт никому не понадобится. Будет падать иногда, но работать — поставят, дадут возможность доделывать и исправлять. Это всё на собственной шкуре пройдено: были неудачные попытки внедрения.
Вот на примере выше тебе архитектурная оптимизация. Просто перестановкой порядка действий можно добится что работа системы не будет зависить от скорости обработки изображений.
А если у тебя камеры будут срабатывать после определения номера, то тебе придется долго писать первую рабочую версию системы.
Здравствуйте, kochetkov.vladimir, Вы писали:
PD>>Нет, все как раз наоборот. У меня проблемы со стиркой белья, вода извне в машину не течет, а изнутри вытекает на пол, ротор не крутится и т.п, а тут ко мне приходят и говорят : "Мы знаем, что вам нужно, и именно сейчас! Мы решим все ваши проблемы. Самая лучшая кофеварка от фирмы Идиотекс!!! Только у нас!"
KV>А ты теперь поставь себя на их место: они к тебе приходят с классной кофеваркой и видят как чел варит кофе в стиральной машине...
А ты себе представь, как они приносят мне стриальную машину и говорят — в ней можно сварить и кофе.
Здравствуйте, gandjustas, Вы писали:
G>>>Я неправльно вопрос задал. На было так: Где использование cuda необходимо? CC>>Там, где надо ускорить вычисления, которые могут быть ускорены на CUDA G>Ну и парочку примеров где это необходимо, так что без cuda-ускорения не будут выполняться задачи.
Пример из жизни: пришел биг босс и сказал что заказчик хочет и платит.
Всё. Все остальные рассуждалки "да каму ета наааада" в сад.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, Sheridan, Вы писали:
LVV>> И устаканить в мозгах постулат: НАДЕЖОСТЬ ВАЖНЕЕ ЭФФЕКТИВНОСТИ!!!!!!!!! S>А вот здесь уже спорно... Надежность безусловно важна, но если программеры-профессионалы, то надежность будет и так.
Надежность "и так" — не будет! Если этим специально не заниматься в процессе разработки... S>Следовательно надо делать ставку на эффективность.
По этому поводу — читайте первоисточники.
Э. Йодан Структурное проектирование и конструирование программ.
Издательство: М.: Мир
Переплет: твердый; 415 страниц; 1979 г.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[6]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, LaptevVV, Вы писали:
LVV>Я писал бортовую ось, поэтому непосредственно знаю, сколько времени уделяется надежности системы. Достаточно сказать, что система с остояла из 4 эвм, один рабочий, два в горячем резерве и один — в холодном...
И совершенно недостаточно. На базе четырёх железок возможно целое стадо архитектур с разной степенью надёжности. Например, на "Ариан-5" у IRS тоже имелось резервирование, но так как все коробочки были идентичными, и софт был один и тот же, то и баг везде был один и тот же. В результате резерв подох аналогично основной системе, и весь космодром завалило обломками девайса
LVV>Но это как раз и говорит о том, что крах системы — это ЧП.
Вы опять путаете. Речь не о FCS самолёта, или там IRS ракеты — очевидно что их отказ фатален. Речь о компонентах типа рисовалки картографического модуля, рестарт которых ничего страшного не представляет. И нормальные люди такие вещи и не резервируют, и 100% надёжности в требованиях не ставят, бо смысла нет.
LVV>Ну, далеко ходить не будем, возьмем систему продажи билетов... Крах системы — ЧП. Хотя восстанавливается, да... Но лучше — без крахов...
Если консистентность данных сохраняет и рестартует за секунду — в чём проблема ?
Re[16]: Павлу Дворкину: о понимании того что делаешь и прост
Здравствуйте, Курилка, Вы писали:
К>Есть ощущение, что есть некоторое взаимное недопонимание
Угу
К>Я-то тебе как раз говорил, о том, что вариант с "причинами смерти" (в данном случае в Эрланге), скорее всего, будет выгодней, чем просто "заметание мусора под ковёр". Но, как бычно, абстрактно говорить смысла особого нет, всё определяет задача и её условия.
Конечно. Но вопрос то был можно ли с такой идеологией писать на C++, мой ответ да, но не так удобно как на средах специально под нее разработанных.
Re[2]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, VladD2, Вы писали:
VD>Что до свободы делать что хочет Дворкин, то у него просто довольно странные желания. Лично мне хочется побыстрее написать программу которая будет работать надежно, стабильно и при этом с приемлемой (а не максимально возможной) производительностью. И я не хочу траха. А вот люди вроде Дворкина считаю, что максимальная производительность — это главный приоритет перекрывающий все остальне. Плюс Дворкин фактически заперт в миру идеом С/С++ и просто не представляет как писать софт по другому. Так что от части его свобода только ему кажется свободой, а на самом деле — это клетка.
Хочу от себя подкорректировать — это зашоренность мышления, когда человек смотрит на мир сквозь какой-то ментальный аналог трафарета.
Здравствуйте, CreatorCray, Вы писали:
CC>Пример из жизни: пришел биг босс и сказал что заказчик хочет и платит. CC>Всё. Все остальные рассуждалки "да каму ета наааада" в сад.
Ну, значит написание драйверов устройств под Windows на Java — это очень важно и жизненно. Потому что может придти биг босс и сказать что заказчик хочет и платит.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что за нефункциональные требования у тебя там могут быть — не знаю и не хочу обсуждать. Я говорил именно о функциональных требованиях. Быстрее, черт возьми. Еще быстрее! А теперь еще быстрее.
Вообще-то бысрее-ещё-быстрее — это и есть нефункциональные требования. Ну да ладно.
PD>Покажи мне хоть одно место, где я предлагал изничтожить, к примеру, C#. Не найдешь.
Трудно найти хоть одно место, где ты вообще говоришь о C#. Похоже кроме C ты и знать ничего не желаешь. В этом проблема, особенно учитывая, что ты преподаватель.
PD>А вот что ты предлагал делать с теми, кто на С++ программирует, я не забыл. Напомнить ?
Изолировать от общества? Было дело. В следующий раз специально для тебя буду ставить смайлики, чтобы ты не принимал всё так близко к сердцу.
PD>Так кто из нас терпимее к чужим мнениям ?
IT>>А ты сам-то пробовал писать на чём-то другом кроме C? Или это всё теории? PD>C#, Java, Fortran, PL/1, VB,, Asm, ну и кое-что по мелочи.
И как, получалось?
IT>>Поможет пересмотр архитектуры. PD>А если ее нельзя пересмотреть ?
Архитектуру можно пересмотреть всегда. Вопрос упирается лишь в целесообразность.
IT>>Купи проц с 16-ю ядрами и сделай алгоритм многопоточным.
PD>Многопоточность тут не поможет, я уже объяснил почему, идет пакетная обработка, так что все равно — одну матрицу разбивать или несколько обрабатывать. А вот насчет 16 ядер — не лукавь. Я тебя спросил — как можно оптимизировать. А ты мне в ответ — купи более мощное железо. Почему бы в таком случае не посоветовать — купи 16 компьютеров ?
Купи 16 компьютеров.
PD>Мой вариант был тогда еще приведен, и в нем ничего не меняется. А вот в твоем время замерь. Без LinQ ты проиграл в 33 раза
Меня это не волнует. Где надо я выиграю, а где не надо у меня приоритеты совсем другие.
IT>>Потому что для решаемой задачи, а именно для файла размером в 120 байт, моё решение будет более чем приемлемым.
PD>А почему же ты тогда, предлагая свое решение (тогда еще, да и сейчас) не оговорился — оно хорошо будет работать для малых файлов, но для достаточно больших его применять не следует ? Если бы ты это сделал — я и возражать бы не стал, если там 120 байт — все равно, что делать. Но ты ведь предлагаешь свое решение как универсальное, не так ли ?
Это решение и для файлов побольше работает не плохо. Но самое забавное, что похожие реальные решения, а не высосанные из пальца, и на больших файлах работают приемлемо. В жизни мне вот никогда не надо было читать последнюю строчку из файла. А весь файл раскладывать на строки приходится периодически.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
LVV>>И даже если не устраивает — сначала ошибки убрать, а потом скорость повышать... PD>Например, неправильное форматирование строки в выходном документе — это, конечно, важнее, чем повысить скорость его генерации в 10 раз
Ну да, конечно — компьютер позволяет человеку очень быстро делать ошибки
Ты не описал даже, были ли требования к выходному документу или не были? Может "неправильное форматирование" вообще не является ошибкой?
Если разговор о результатах научных расчетов — то на вид выводных данных, скорее всего, жестких ограничений нет, и на неудачно отформатированные строки можно не обращать внимания. То есть это даже и не ошибка. Просто не очень аккуратный интерфейс. Если же речь о визуальном редакторе — то нахрена он мне нужен, если форматирует текст очень быстро, но неправильно?
Кстати, вполне нормальное решение для редактора, если текст форматируется быстро, правильно, но не очень качественно, т.е. определенная погрешность заложена изначально в алгоритме (как компромисс по быстродействию) и проявления этой погрешности понятны пользователям.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[5]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, LaptevVV, вы писали:
S>... то надежность будет и так.
LVV>> Надежность "и так" — не будет! Если этим специально не заниматься в процессе разработки... S>А кто говорил, что заниматься никто не будет?
Ты. "Надежность будет и так" понимается (мной) как "не надо ею заниматься". Или объясни, как надо понимать твое высказывание.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>М-да. Похоже, если ты это говоришь серьезно, это означает только одно. Мир программирования разошелся на разные квартиры уже настолько, что представителям разных кваритр не легче понять друг друга чем алеуту папуаса.
Я говорю это серьезно. И, Павел, тебе об этом давно говорят — твои задачи весьма узкие, не стоит обобщать на всех.
... << RSDN@Home 1.2.0 alpha 4 rev. 1284 on Windows 7 6.1.7600.0>>
Здравствуйте, fmiracle, Вы писали:
F>Здравствуйте, Pavel Dvorkin, Вы писали:
F>Быстрее и еще быстрее сделать что? А то может тебе не надо ничего писать а просто скачать Nada — она выполняет свои обязанности в режиме 24/7, с нулевыми затратами процессорного времени и оперативной памяти — просто идеальное решение!
Смотреть лень. Если можешь, расскажи, как там хотя бы суммировать матрицы 5000*5000 с нулевыми затратами процессорного времени.
F>Функциональные требования описывают, что должна делать система.
+1
>Нефункциональные — как она должна это делать. То есть ограничения, накладываемые при выполнении данных функций.
Эти ограничения тоже функциональны. Например, требование решать некую NP-полную задачу — это функциональное ? А если это требуют делать при N=1000, это уже нефункционально ? Сначала напишешь алгоритм полного перебора, а потом скажешь — ой, извините, ответ вы получите в 50 веке
>В том числе и ограничения по скорости выполнения заданных функций и потребляемым при этом ресурсам.
Дело в том. что решение, которое не укладывается в некий минимум по времени, в моих задачах не есть решение вообще. Он просто неприемлемо изначально, его никто и обсуждать не будет.
F>Причем, твое ограничение "Быстрее, черт возьми. Еще быстрее! А теперь еще быстрее" делается просто на раз, всегда бы такие задачи мне ставили. Решение очень простое — делаем очень медленную версию, потом немного улучшаем ее — и она "быстрее, черт возьми", потом еще раз улучшаем — и она "Еще быстрее!", а теперь опять оптимизируем — и теперь она "еще быстрее!". Ура, требования по быстродействию удовлетворены всего за 4 релиза, забираем деньги, идем радоваться.
Не спеши радоваться. Дело в том, что после того, как ты сделаешь очень медленную версию, тебя просто уволят. Она просто никому не нужна.
F>Почему-то чаще ограничения по быстродействию накладываются как-то иначе. Примерно так:
F>1. Сперва все функциональные требования F>2. Нефункциональные: F>2.1. Быстродействие:
Еще раз. Быстродействие входит в число функциональных требований. При недостаточно высоком — решение просто не рассматривается.
Вот представь себе ПО управления самолетом. Если оно будет реагировать на изменение обстановки очень медленно — его просто выкинут сразу. В функциональные требования такого ПО входит — реакция не медленнее, чем за такое-то время. Более того. Если окажется, что удовлетворить другим требованиям за это время не удастся — я вполне могу допустить, что часть других требований будет снята или ослаблена. А время — нет, потому что если реакция будет медленнее, чем ..., то управлять уже будет нечем.
У меня, конечно, не самолетное ПО, но идея та же самая. Риски там, правда, нулевые, ничего не грохнется, но недостаточно быстрые решения не рассматриваются. А для достаточно быстрого решения всегда макисма такая — сделайте еще быстрее, если можете.
F>А вот как доказать заказчику, что ты успешно выполнил функции "Быстрее, черт возьми" и, одновременно, "Еще быстрее"? Особенно, если система — что-то новое и раньше другой версии ее же не было? Тут можно только прогрузить его, что делается это на чистом С и использовалось 148 ассемблерных вставок, и, черт возьми, быстрее уже никто не будет, зуб даю. Короче — упражнение в красноречии.
Если нет совсем аналогов — может, и да. Но аналоги обычно есть. И если заказчик мне показывает коммареческую программу, которая делает это за 3 сек, а я ему сначала делаю за 500 мсек, а потом на CUDA за 100 — он будет (был) доволен, хотя не исключено, что попросит сделать за 50 мсек. А поскольку он меня давно знает и знает, что я делаю максимум из того. что могу, то дальше будет одно из двух — либо я сделаю за 50 мсек, либо заяввлю — все, предел, лучше не могу. Он мне поверит, не волнуйся . Впрочем, поверит и в случае, если ПО нне имеет аналогов.
F>А вот уболтать спецификацию с явно прописанной цифрой и секундомер, на котором высветилась совсем другая цифра — почему-то выходит с трудом.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Правда, для этого надо еще 2 маленьких изменения внести. Легким движением руки. За 10 секунд
IT>ЭТО ЖЕ НЕ ОПТИМАЛЬНО ДЛЯ ФАЙЛОВ РАЗМЕРОМ В 100 ГИГ!!! НИКАКОГО СВОПА НЕ ХВАТИТ!!!!
IT>Бред, блин.
Бред — это обсуждать решение, не зная ограничений и условий, а также не зная того, как это работает.
Если файл имеет размер в 100 Гб, то напрямую это решение не подходит, и вовсе не из-за своп-файла, а просто потому, что маппировать 100 Гб в адресное пространство 32-битного процесса никак целиком нельзя. Придется это делать по частям, размер части может быть не более 2 Гб (чуть меньше), что вполне в своп уместится. После этого придется view закрыть, в результате чего все модифицированные страницы будут освобождены и изменения потеряны. Таким образом, при файлах такого размера решение просто неприемлемо и надо найти другое. Проще всего файл скопировать. Фактически мы тут будем иметь то же самое, только копирование не на лету и не в своп-файл, а предварительно, и в другой файл. И там мне никто не мешает открывать view на последовательные куски файла и заменять CR на 0.
А вот если файл имет размер 100 Мб — решение очень даже хорошо подходит.
Вот в этом-то и разница между нами. Вместо того, чтобы любое некоторое решение объявлять гениальным или бредовым, надо давать свои советы применительно к конкретной ситуации. И тогда решение будет хорошим или плохим. Для данной ситуации.
Кстати, если уж на то пошло, не мог ли бы ты объяснить, как ты этот 100 Гб файл будешь на строки парсить ? Хоть какое-нибудь решение дай, а ? А то ведь если считать весь файл в буфер, а потом еще Split применить, тебе ведь 200 Гб (оперативной памяти + своп) понадобится. . В 32-битной ОС это просто невозможно, но и в 64-битной не пройдет тоже, пока не установишь на машине примерно так 256 Гб ОЗУ .
Я себе живо эту ситуацию представляю. Приглашают тебя и просят написать программу, которая 100 Гб текстовый файл на строчки парсит. На это ты отвечаешь — у меня есть замечательное решение, я его даже спросонок могу выдать за 10 сек, только, пожалуйста, купите мне машину с 256 Гб ОП
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, IT, Вы писали:
IT>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Правда, для этого надо еще 2 маленьких изменения внести. Легким движением руки. За 10 секунд
IT>>ЭТО ЖЕ НЕ ОПТИМАЛЬНО ДЛЯ ФАЙЛОВ РАЗМЕРОМ В 100 ГИГ!!! НИКАКОГО СВОПА НЕ ХВАТИТ!!!!
IT>>Бред, блин.
PD>Бред — это обсуждать решение, не зная ограничений и условий, а также не зная того, как это работает.
Ограничения порой меняются после того как решение предоставлено.
PD>Если файл имеет размер в 100 Гб, то напрямую это решение не подходит, и вовсе не из-за своп-файла, а просто потому, что маппировать 100 Гб в адресное пространство 32-битного процесса никак целиком нельзя. Придется это делать по частям, размер части может быть не более 2 Гб (чуть меньше), что вполне в своп уместится. После этого придется view закрыть, в результате чего все модифицированные страницы будут освобождены и изменения потеряны. Таким образом, при файлах такого размера решение просто неприемлемо и надо найти другое. Проще всего файл скопировать. Фактически мы тут будем иметь то же самое, только копирование не на лету и не в своп-файл, а предварительно, и в другой файл. И там мне никто не мешает открывать view на последовательные куски файла и заменять CR на 0.
Т.е. под 100 Гиг это решение нельзя адаптировать, а можно только перерешить заново.
PD>Кстати, если уж на то пошло, не мог ли бы ты объяснить, как ты этот 100 Гб файл будешь на строки парсить ? Хоть какое-нибудь решение дай, а ? А то ведь если считать весь файл в буфер, а потом еще Split применить, тебе ведь 200 Гб (оперативной памяти + своп) понадобится. . В 32-битной ОС это просто невозможно, но и в 64-битной не пройдет тоже, пока не установишь на машине примерно так 256 Гб ОЗУ .
Т.к. простое 10-секундное решение использует хорошую абстракцию (на сколько я помню решение), то подменить стандартную реализацию чтения строк на свою не составит труда. Это означает, что весь остальной код решения не изменится. Это особенно важно для задач, которые немного сложнее, чем считать последнюю строчку, или там через одну или еще как-то.
Итого, 10-секундное решение адаптируется к файлам любой длины без переписывания всего кода.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>А собственно операции перемножения матриц или взятия последней строки из файла — это уже отдельные подзадачи (методы, модули, задания кодерам), PD>Нет. это не подзадача. Это задача в целом. Поступают эти матрицы с входного устройства, и обрабатывай их как можно быстрее. Вот и все.
Да вот и не все? Сколько их поступает? Куда должен быть положен результат, зачем он должен быть положен именно туда, и может быть его можно с тем же успехом класть куда-то еще?
Тебе ведь предлагали сдлеать кластер из многих компов, ты отказался аргументировав это тем, что очень дорогое 3dparty ПО стоит. Но может быть можно на одном компе (с 3rdparty ПО) получать матрицы, а потом передавать их на кластер из сотен компьютеров для обработки?
Это так, например. И сразу проблемы становятся более другие чем обработка на одной машине.
>>- там, может быть, применят оптимизацию, и перепишут этот маленький кусочек кода в боле большой и умный. А может быть просто решат (по совокупности показателей всей задачи с файлом же наверняка делают и что-то еще, кроме взятия последней строки), что файл тут уже не оправдывает себя и надо вместо него использовать СУБД.
PD>Господь с тобой, какая тут СУБД. Чтобы взять из файла любой длины последнюю строчку, совсем не надо все остальное читать. Надо именно последнюю строчку.
Господь с тобой, Павел. Я не раз общался с заказчиками о требуемых им задачах. Поверь, ни разу никого из них не интересовало получить последнюю строчку из фала и ничего хоть сколько-то близкое к подобной постановке задачи. Их все больше интересует что-то типа "правильно склеить изображения снятые с разных камер" или "получать информацию о новых просроченных кредитах каждый понедельник". Интересуют сроки и стоимость решения (включая и разработку и железо). А используется там файл, СУБД или таз с гайками их вообще не интересует.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>немного посложнее, чем сложение, но по сути — тот же двойной цикл.
Павел, либо у тебя уникальный случай двумерного адресного пространства в отдельно-взятом компьютере, либо для сложения двух матриц хватит и одного цикла, вообще-то
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>немного посложнее, чем сложение, но по сути — тот же двойной цикл.
KV>Павел, либо у тебя уникальный случай двумерного адресного пространства в отдельно-взятом компьютере, либо для сложения двух матриц хватит и одного цикла, вообще-то
Это как ? Представить матрицы в виде линейных массивов и сложить? Разумееется, можно, но от этого алгоритм не перестанет быть O(n^2)
Здравствуйте, Pavel Dvorkin, Вы писали:
F>>Функциональные требования описывают, что должна делать система.
PD>+1
Еще бы, это же бородатый баян. Карл Вигерс, "Разработка требований к ПО". Вам по букварю отвечают, а вы с букварем спорите.
>>Нефункциональные — как она должна это делать. То есть ограничения, накладываемые при выполнении данных функций.
PD>Эти ограничения тоже функциональны. Например, требование решать некую NP-полную задачу — это функциональное ? А если это требуют делать при N=1000, это уже нефункционально ? Сначала напишешь алгоритм полного перебора, а потом скажешь — ой, извините, ответ вы получите в 50 веке
Требование решить NP полную задачу — функциональное, N = 1000 это допустимые входные данные. И если мне не сказали, что допустимые входные данные такие, то я волен решать ее как мне захочется.
PD>Еще раз. Быстродействие входит в число функциональных требований. При недостаточно высоком — решение просто не рассматривается.
Не хотите статью на rsdn написать? Это новое слово в разработке требований.
PD>Вот представь себе ПО управления самолетом. Если оно будет реагировать на изменение обстановки очень медленно — его просто выкинут сразу. В функциональные требования такого ПО входит — реакция не медленнее, чем за такое-то время. Более того. Если окажется, что удовлетворить другим требованиям за это время не удастся — я вполне могу допустить, что часть других требований будет снята или ослаблена. А время — нет, потому что если реакция будет медленнее, чем ..., то управлять уже будет нечем.
Производительность входит в нефункциональные требования.
PD>У меня, конечно, не самолетное ПО, но идея та же самая. Риски там, правда, нулевые, ничего не грохнется, но недостаточно быстрые решения не рассматриваются. А для достаточно быстрого решения всегда макисма такая — сделайте еще быстрее, если можете.
И что, всегда требования производительности более важны, чем функции системы? Ну, типа, если есть хоть малейший шанс увеличить производительность, то мы ее увеличиваем, а не добавляем новые фичи?
Здравствуйте, Flem1234, Вы писали:
PD>>Еще раз. Быстродействие входит в число функциональных требований. При недостаточно высоком — решение просто не рассматривается.
F>Не хотите статью на rsdn написать? Это новое слово в разработке требований.
Этому новому слову лет так 50. Почитай, к примеру, про real-time приложения, если нет реакции за фиксированное время — решения нет.
F>И что, всегда требования производительности более важны, чем функции системы?
А кто сказал, что функции не важны или менее важны ? Я ? Ссылку!
>Ну, типа, если есть хоть малейший шанс увеличить производительность, то мы ее увеличиваем, а не добавляем новые фичи?
Зависит от задачи. Иногда новые фичи просто не нужны, а надо ускорить обработку.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не знаю, что там буржуи делают, но если ты увеличиваешь ресурсы (железо и т.д.), то это называется именно увеличением ресурсов, а не оптимизацией программы. Покупая новые ресурсы, можно все что угодно усилить.
Типичное заблуждение. Всё что угодно усилить можно только бесконечно усиливая возможности одной единственной железки. Но эта величина у нас ограничена. Масштабирование — это как раз и есть оптимизация твоей программы для работы в распределённой среде.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
PD>>А также более эффективным способом используя эту самую железку. Или ты считаешь такое в принципе неверным путем ? А почему, собственно ? Если я смогу при том же железе вычислять в 2 раза быстрее, чем сейчас, то мне понадобится в 2 раза меньше железок. И что тут плохого ?
IT>Ну увеличил ты в два раза, что дальше?
А дальше ничего не надо. Можно купить в 2 раза меньше компьютеров, в 2 раза меньше заплатить за лицензии... Как ты сам любишь говорить, это решение — может быть достаточным
>После этого увеличишь в 0.2 раза
Увеличить в 0.2 раза — это как ? Уменьшить в 5 раз ?
>а потом в 0.02 раза, а потом в 0.002 раза? Каждое новое увеличение будет на порядок меньше, а стоить будет на порядок дороже.
Да зачем же мне потом еще увеличивать ? Дедо сделано, осталось стричь купоны.
>С масштабированием стоимость увеличения равна стоимости железа.
Верно. А с оптимизацией порой равно 0 (нулю)
Вот тебе простой пример.
Я от тебя советов насчет сложения матриц так и не получил, кроме как купить новое железо. Так что дам свой. Поучительный пример, кстати.
Конечно, ничего нового я тут не скажу, все это должно быть всем хорошо известно.
Сложить 2 матрицы можно, проходя их либо по строкам, либо по столбцам. Так вот
На абстрактной машине эти 2 варианта равноправны.
В MS-DOS для процессора 8088 — тоже.
А вот на C++ и C# надо — по строкам
А на Фортране для Windows — по столбцам.
И будет тебе в результате совершенно бесплатное увеличение скорости. Без покупки ресурсов.
Почему так — думаю, сам знаешь. Не знающих — отсылаю к поиску по вопросам "страничный механизм Windows, ошибки страниц, рабочее множество, кэш процессора".
PD>>Еще раз — я веду речь про оптимизацию при данных ресурсах. При увеличении числа ресурсов скорость возрастет, это ежу понятно, пусть не в N раз, но возрастет. Ты вот, не покупая новые ресурсы сделай, тогда и хвались.
IT>Я? Похвалиться? Да скока угодно. Смотрим внимательно сюда.
IT>На картинке результаты теста производительности ORM tools.
IT>Весь зелёненький, чемпион в лёгком и тяжёлом весе — BLToolkit, самый быстрый ORM в мире. Моя работа с сотоварищами. Как видишь инструменты от MS, NH и пр. тихо покуривают в сторонке.
Я тебя и твоих товарищей искренне поздравляю! Кроме всяких шуток.
Но все же это не то, о чем я спросил. Здесь сравнение с другими продуктами, а я говорил про увеличение быстродействия данного продукта без покупки новых ресурсов.
IT>А ты можешь чем нибудь похвалиться?
Могу. Честное слово. . Но я уже не раз писал — здесь я обсуждать тематику своей работы не буду. Так что извини.
PD>>Вот есть у тебя, к примеру, грузовик. На нем можно перевезти, скажем, домашнюю мебель. Если ее аккуратно поставить, то за одну поездку раз можно, а если валом валить, то за 3 поездки получится. А ты предлагаешь — давайте валом валить, но купим еще 2 грузовика.
IT>Тебе, конечно, виднее. Но я предпочитаю доверять перевозку моей мебели профессионалам, а не любителям.
Это я совсем не понял. Я же о профессионалах и говорю. Профессионалы разместят вещи в грузовике как следуют, и одной поездки будет достаточно. А полупрофессионалы или любители разместят по принципу "вали кулем, потом разберем", в результате чего и понадобится 3 поездки.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>Их все больше интересует что-то типа "правильно склеить изображения снятые с разных камер" или "получать информацию о новых просроченных кредитах каждый понедельник". Интересуют сроки и стоимость решения (включая и разработку и железо). А используется там файл, СУБД или таз с гайками их вообще не интересует.
PD>Заказчика , может, и не интересует, что там внизу, а вот скорость его очень даже интересует.
Судя по тому, как упорно вы настаиваете на этом — с заказчиками вы общаетесь крайне редко. Я не встретил в своей практике еще ни одного, который бы упоминал скорость в разговоре о требованиях к программе. Скорость всегда нужна достаточная. Не максимально возможная, а достаточная. Даже когда есть четкое требование по производительности, то оно формулируется четко, например: SLA сервиса — ответ в пределах 0,25 мс для 95% запросов. Если таких четких требований нет — значит у вас проблемы, потому что вы их сформулировать не в состоянии, работая с заказчиком.
Более того, нет смысла просто полировать один кусочек программы, скажем с 0,105 мс до 0,02 мс, если все упирается в коннект к базе данных, который занимает 0,9 мс. Даже сфереконические пользователи не оценят ваших потугов в полировке маленького кусочка, пока программа будет ждать ответа от БД.
Более того, производительность программы не дается бесплатно. Практически всегда более быстрый алгоритм в данном месте означает более запутанный и трудно-поддерживаемый код. Это означает что производительность нужно очень осторожно дозировать — есть риск резко снизить эффективность работы с кодом. Что дает отличный шанс конкурентам, которые могут быть гораздо умнее в этом плане.
Это же очень простые утверждения — как их можно не понимать?
Здравствуйте, Кэр, Вы писали:
Кэр>Ну так с этого и нужно было начинать. Собственно этим можно было и закончить. Если вы не утверджаете, что все ваши утверждения применимы к большей части разработки программного обеспечения, а только имеют смысл в рамках этого вашего конкретного проекта — то бог с вами.
Я бы так сказал — к некоторому множеству проектов. Поймите одну простую вещь — мир программирования не сводится ни к web-программированию, ни вообще к той его части, для которой Вы в предыдущем письме столь настойчиво проповедывали в общем-то, справедливые для этой части идеи. Мир большой, и в нем есть всякое — как то, что соответствует Вашим представлениям, так и то, что им безусловно противоречит. Ну а каково процентное соотношение этих частей — это не так уж важно. Сегодня оно одно, завтра другое, а послезавтра вообще что-то иначе будет
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, FR, Вы писали:
FR>>Для C++ тоже вполне реально, та же изоляция в системный процесс например. S>Это фантастика. Для классического неуправляемого приложения граница разрушения — это процесс. Взаимодействие процессов — очень дорогое. Поэтому реализация всех кирпичиков в виде отдельных процессов в большинстве случаев неприемлема по производительности. (Хотя, конечно, и возможна).
А интерпретирующий эрланг почему-то приемлем.
Взаимодействие процессов через ту же разделяемую память не так уж и дорого, правда их рождение в default ос конечно дороговато.
S>Именно поэтому управляемые среды представляют значительно больший интерес с точки зрения производительной надёжности. Там можно весьма гранулярно провести границы повреждённого состояния, и при этом не иметь накладных расходов при доступе через эти границы.
С этим я не спорю. Просто говорю что и на C++ возможна эрлангоподобная организация системы хоть и коряво.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>Рекомендую на досуге ознакомиться с определением IEnumerable и глупостей больше не писать.
Я, конечно, виноват, что перепутал IEnumerable с IEnumerator . В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны. Их на С/C++ нет и без них я до сих пор вполне обходился там и буду дальше.
PD>>Дело не в исчерпании пространства, а в том, что невозможно для больших файлов уложить их целиком в это АП. Поэтому придется это делать по частям, то есть иметь 2 view — один текущий, другой для конца. И текущий будешь переоткрывать и двигать. S>(Вздыхает).
Тебе только это и остается.
S>1. Павел, а кто тебе сказал, что всё АП принадлежит твоей функции?
О господи! Если уж АП начало принадлежать функциям... приехали.
>Поэтому слово "больших" тут не нужно. Речь идёт об исчерпании АП, и вовсе не обязательно иметь пятигигабайтный файл, чтоб на него нарваться.
М-да. Глубокая мысль. Как говорил Воланд, "без тебя мы никак бы не догадались"...
Поясняю. Работая с mmf файлами, вполне достаточно иметь на один view 4 Кбайта (регион будет, правда, 64 Кбайта). Независимо от длины файла. Передвигая это окно, можно пройти весь файл, не затратив больше ни одного байта.
S>2. Не вижу никакой причины иметь два view. IEnumerable во view вообще не нуждается. Иди посмотри, как он устроен.
Как устроен IEnumerable — мне сейчас не важно. Но для если для реализации Next и Last через mmf ты можешь обойтись без view — код в студию.
А теперь по существу. Если ты будешь иметь только один view, то для того, чтобы спозиционироваться на конец файла в то время, когда ты итерируешь его от начала и где-то внутри этого процесса, тебе придется этот view закрыть, переоткрыть его заново на конец файла, предварительно запомнив текущую позицию, а потом выполнить обратное действие. Это далеко не так дешево. Так что советую познакомиться еще раз с тем, как устроены memory-mapped файлы и как с ними работают. Хоть с IEnumerable, хоть без него — mmf эти примочки безразличны.
S>Логика действий — неумолимая. Я реализую класс, который предоставляет доступ к строкам файла как к коллекции.
Можно пример кода для 10 Гб файла ? С методами Next (следующая строка) и Last (последняя). На базе mmf.
S>И я могу сделать одинаково эффективный доступ как по очереди, так и с конца. Вот только логика чтения файла тут изолирована от алгоритма, который ею пользуется.
И что ? Ты упорно пытаешься вломиться в открытую дверь. Если мне это будет нужно, я сделаю то же самое, без всяких IEnumerable и т.д. Или ты уж впрямь думаешь, что на С++, где этого добра нет и в помине, так-таки невозможно сделать логику чтения файла независимой от алгоритма, который ею пользуется ? Если да — спешу тебя разочаровать. Это еще в 60-е год на Фортране умели.
S>Алгоритму важно сказать Last() и не париться — может, там все данные уже в памяти построчно сидят.
Ну вот и сделай для 10 Гб файла, чтобы там все данные построчно лежали. В x86
>Реализация при этом, как видишь, никак в эффективности не проигрывает.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, kochetkov.vladimir, Вы писали: PD>Ну спасибо. Чтобы мое имя прямо-таки профигурировало в названии топика — такого еще не было. Да и других тоже что-то не упомню, хотя были, наверное, но не часто.
А вот так. Шеридан например, уже привык.
PD>По существу отвечу завтра, надо и подумать, да и поздно уже. У меня как раз примерно час поездки домой, успею продумать.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Я вот сижу и думаю, а может ну ее нафиг эту свободу, а? CC>Давайте таки оставим программисту право выбора.
Ты так говоришь, как будто ее возможно у вас отобрать
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>"Суслика видите? А он есть..." GZ>Уважаемый. А вам не кажется что вышеописанное ортогонально языку, и подобное можно сделать практически на любом языке.
Ага, пример на .NET в студию.
GZ>Хотя для некоторых придется проявить выдержку, спокойствие и сообразительность?
Там где сборка мусора такое сделать почти невозможно.
Re[2]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>"Суслика видите? А он есть..." GZ>Уважаемый. А вам не кажется что вышеописанное ортогонально языку, и подобное можно сделать практически на любом языке.
Во-первых, исходным был посыл "может ну ее нафиг, эту свободу?" а не призыв уничтожать тот или иной язык. Во-вторых, таки-не кажется. Уязвимости связанные с разыименованиями указателей характерны, мягко-говоря, не для всех существующих языков. Правда, в случае с конкретным приведенным примером, там выбора-то особо и нет
GZ>Хотя для некоторых придется проявить выдержку, спокойствие и сообразительность?
Не, ну при желании можно переполнение буфера и на питоне изобразить, я ж не спорю. (Через внешний модуль, написанный на нативном языке, ага ) Мы ведь говорим о ситуации "недоглядел", а не о "намеренно напихал в свой код уязвимостей"?
Здравствуйте, gandjustas, Вы писали:
KV>>>"Суслика видите? А он есть..." GZ>>Уважаемый. А вам не кажется что вышеописанное ортогонально языку, и подобное можно сделать практически на любом языке. G>Ага, пример на .NET в студию.
Что то мне кажется что для Влада это не должно составить труда.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, AndrewVK, Вы писали:
G>>>Ага, пример на .NET в студию. CC>>Что то мне кажется что для Влада это не должно составить труда.
AVK>А при чем тут Влад?
Затупил. В янусе предыдущее непрочитанное было от Влада.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[2]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, Tilir, Вы писали:
T>Это ядро Linux. Ещё раз -- ядро. Операционной системы. То самое место, где любые "управляемые решения" с JIT, сборкой мусора и прочими подгузниками просто не роляют.
А с какой радости? Чем плох JIT в ядре? Чем плох realtime GC в ядре? Мало было в линухе утечек?
Все эти предрассудки против управляемых сред давно уже пора бы пресечь.
T> Ошибки? Их не бывает только у тех, кто ничего не делает. А свобода программиста, которую даёт C, ну да в том числе и свобода ошибаться, это самое ценное что у меня, например, есть.
PD>1. Иметь возможность делать все, что я хочу. Разумееется, в рамках того, что мне позволяет аппаратура и (возможно) операционная система, а также мои мозги. Слово "возможно" здесь не случайно. В определенных границах я могу изменить поведение ОС, добавив к ней свой модуль (драйвер)
И мне это надо. Но C++-ов мне при этом даром не надо.
PD>2. Чтобы это работало как можно более быстро и потребляло ресурсов как можно меньше. Я пишу не серверное ПО, а моя ОС не MS-DOS, так что работать это все будет в коммунальной квартире, а поэтому ванную занимать на 3 часа нечего и свет в туалете надо тушить.
Это точно не к C++.
PD>3. Чтобы в этом коде было как можно меньше ошибок. Говорить "чтобы не было ошибок" не буду, так как программа без ошибок есть абстрактное теоретическое понятие.
Ну тут вообще C++ не при делах.
PD>4. Чтобы я на это потратил как можно меньше своего времени.
C++ по части boilerplate-кода не имеет себе равных.
PD>Первый мой вопрос — а как с п.1 и 2 будет. Гарантируете ли вы, что я по-прежнему смогу делать все. что я умею делать, использовать все те возможности ОС, которые умею использовать ? И будет ли это работать столь же быстро и требовать ресурсов не больше ?
Например, с Ada? Ещё бы, как не гарантировать.
PD>Как только я этот вопрос задаю, так сразу мои оппоненты начинают юлить. Сможешь , наверное, только вот иногда тебе придется на неуправляемый код переходить, а иногда и вообще не получится.
Что плохого в "иногда на неуправляемый код переходить"? Особенно если он генерится в динамике из управляемого.
PD>И вот эти логические ошибки меня больше всего и беспокоят. Они у меня львиную часть времени съели. А не выходы индексов и прочая чепуха.
Сейчас thesz про Agda расскажет.
PD>Резюмирую. Готов ли я отдать свою свободу (в программировании, конечно, только там) за что-то ? Пока не дадите твердого ответа на п.1 и 2. — категорически не готов. А когда дадите — тогда поторгуемся по п.3. Пока хорошо не заплатите — тоже не отдам.
Какая же это на фиг свобода? Вот метапрограммирование, при наличии среди целевых языков и сколь угодно низкоуровневых — это свобода. А один примитивненький низкоуровневый язык — это не свобода, а фигня.
Здравствуйте, metaprogrammer, Вы писали:
M>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>И вот эти логические ошибки меня больше всего и беспокоят. Они у меня львиную часть времени съели. А не выходы индексов и прочая чепуха.
M> Сейчас thesz про Agda расскажет.
Здравствуйте, Odi$$ey, Вы писали:
OE>Проблема в том, что голова не безразмерная и чем больше думаешь про "мемори-лики", тем меньше про логику программы
Отчасти верно, только я о них слишком уж мало думаю, чтобы это всерьез повлияло.
PD>>С IndexOutOfRange я как-нибудь и так справлюсь, а вот с этим-то что делать ? Поможете ?
OE>ну и аргумент, охренеть — ваша кофеварка не умеет стирать бельё!??? в топку её!
Если меня больше всего интересует, как постирать белье , а ты мне предлагаешь кофеварку — в топку!
Здравствуйте, metaprogrammer, Вы писали:
M>Здравствуйте, Tilir, Вы писали:
T>>Это ядро Linux. Ещё раз -- ядро. Операционной системы. То самое место, где любые "управляемые решения" с JIT, сборкой мусора и прочими подгузниками просто не роляют.
M> А с какой радости? Чем плох JIT в ядре? Чем плох realtime GC в ядре? Мало было в линухе утечек?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В общем, лучше вертолет, чем автомобиль. Намного лучше. Но один недостаток у него есть. Серьезный. Иногда они падают. Не часто, но бывает. И последствия обычно тяжелые.
Только вертолеты на несколько порядков дороже сами по себе и в эксплуатации. Да и далеко на нем не улетишь. Ну 500 км. А что бы 1000-2000 надо уже или самолет, который тоже очень дорогой, да и взлететь/сесть можно далеко не везде. Или автомобиль. Поэтому в большинстве случаев именно автомобиль является оптимальным выбором.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[3]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Tilir, Вы писали:
T>>Это ядро Linux. Ещё раз -- ядро. Операционной системы. То самое место, где любые "управляемые решения" с JIT, сборкой мусора и прочими подгузниками просто не роляют. G>С чего ты взял?
T>>Ошибки? Их не бывает только у тех, кто ничего не делает. А свобода программиста, которую даёт C, ну да в том числе и свобода ошибаться, это самое ценное что у меня, например, есть. G>Тоже чушь, MS активно использует верификатор кода C, количество таких ошибок снижается на порядки.
G>Программирование уже давно не искусство, тут рулят надежные решения. На свободу насрать.
Ну уменьшается,но всё же не всё найдёт верификатор
Re[5]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, samius, Вы писали:
S>На РСДН уже видимо правило хорошего тона: если не разделяешь точку зрения человека — просклоняй его /*или фамилию, если доступна*/.
Склоняют тут не Дворкина-человека, а Дворкина-понятие, которое подразумевает непремиримую борьбу за низкоуровневую оптимизацию. Примерно как пойти погуглить — поискать чего-нибудь в поисковике. Пойти в дворкины — заняться выжиманием битов из байтов.
S>Пол беды, когда это делают пользователи, но от админа
Тут согласен. Погорячился, был не прав. Приношу свои извинения.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, A13x, Вы писали:
A>>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>... KV>>>Я вот сижу и думаю, а может ну ее нафиг эту свободу, а?
A>>А может тогда сразу нафиг программирование — и в дворники?
KV>Ну если эта типа свобода (проявление которой, бывает в форме, представленной в исходном сообщении) — это единственное, что держит человека в отрасли, то почему бы и нет?
Безусловно да.
Думаю все согласятся, что человеку свойственно ошибаться.
Ясно, что сборка мусора (и другие вкусности managed языков) позволяют избежать ряда проблем, но сводит ли она все проблемы на нет?
Пример: одно время я пользовался Microsoft Expression Blend-ом (когда разрабатывал UI для WPF приложения).
Казалось бы — написана на C# — управляемом языке программирования, не самыми глупыми людьми (Microsoft), однако более глючной IDE я не видел.
Крайне нестабильно и медленно работает, в ряде случаев падает без звука, естественно не давая сохранить данные.
Причем с простыми проектами из примеров работает сносно, но вот когда дело доходит до сложного...
То же самое могу сказать о KAXAML Editor-е.
Словом я уверен, что и C# не панацея.
No silver bullet.
А жаль.
Кстати, ядро линукса пытались переписать на C++. Даже из этой попытки не вышло ничего хорошего — хотя в этом контексте некорректно сравнивать C# и С++.
Здравствуйте, A13x, Вы писали:
A>Думаю все согласятся, что человеку свойственно ошибаться.
Да, причем безотносительно языка программирования, если мы говорим о программистах
A>Ясно, что сборка мусора (и другие вкусности managed языков) позволяют избежать ряда проблем,
GC есть не только в управляемых языках
A>но сводит ли она все проблемы на нет?
Нет конечно, иначе Брукс давно бы пустил себе упомянутую тобой пулю в лоб.
A>Словом я уверен, что и C# не панацея.
оспади, ну я же нигде, ну ровным счетом нигде, не упоминал в этой теме именно про шарп, а? Дело в том, что и на неуправляемых языках можно писать безопасный код. Сложнее, затратнее, но можно. Но много ли ты знаешь контор, где внедрен SDL? А ведь это весьма неплохой способ существенно повысить безопасность разрабатываемого кода малой кровью, безотносительно в т.ч. используемых языковых средств. Да фиг с ним с SDL, проблема не столько в том, что на си и плюсах можно легко огрести полный набор уязвимостей фон-Неймановской архитектуры
и не столько в отсутствии управления безопасностью в процессах разработки, сколько в отсутствии культуры разработки безопасного кода в серой массе разработчиков. Я сейчас имею неплохие шансы хватануть кучу минусов за предыдущее предложение от тех, кто не в курсе различий между безопасностью кода и безопасностью проекта, поэтому поясню: второе суть — результат совместных усилий всех членов команды, направленный на минимизацию всех, выявленных в проекте рисков по информационной безопасности. Это то, что начинается еще до написания кода и не заканчивается после того, как код написан и передан в продуктив. Это и спорные решения относительно архитектуры приложения и монотонное тестирование по безопаности и обязательные security-review, применения средств типа SAL в С++ проектах, принятие решений об уходе на управляемые платформы в ущерб производительнотсти, да много чего еще. Да, это — дорого, да, это — долго, да, это — оказывает существенное влияние на проект сразу в нескольких аспектах. И разворачивать подобную деятельность в проекте необходимо лишь тогда, когда есть четкое понимание того, что это даст и почему это, в долгосрочной перспективе, будет выгоднее, чем задвигание вопросов безопасности на второй план.
А вот второе — лежит целиком и полностью на совести каждого конкретного разработчика-индивидуума. Это просто набор правил о том, как надо (или не надо) писать код, причем большинство из них вообще не привязаны к какому-либо языку. Также, большинство их них не добавляют какой-либо особенной лишней работы программеру (разница в оверхеде между использованием строк с сплайсингом/конкатенацией и параметризованными SQL-запросами стремится к нулю, с учетом тех рисков, которые закрывает второй способ). Это — как правило не говорить во время еды — да, на протяжении всей жизни может доставить некоторые неудобства, но значительно снижает риск, что однажды, человек задохнется, подавившись принимаемой пищей (а кроме того, это еще и вежливо и считается признаком воспитанности ). Или — как правило мыть руки после посещения туалета. Можно и не мыть, и в большинстве случаев ничего не случится, однако одного раза заболевания геппатитом, думаю хватит, чтобы потом запомнить это правило на всю жизнь.
И вот когда это отношение смешивается в равных пропорциях с чуством свободы, которую дает программирование на тех или иных языках и начинаются локальные армагеддончики в кусках кода, написанного таким программером.
Так почему разработчики в большинстве своем, мало того, что не следуют этим правилам, так еще и пытаются убедить всех вокруг в своей правоте и вредности того, что лично я, например, считаю признаком профессионализма, при этом культивируя ништяки, получаемые от свободы, предоставляемой им теми или иными языками?
A>Кстати, ядро линукса пытались переписать на C++.
Да там и Линус изначально это не поддержал в силу своего специфического отношения к плюсам.
A>Даже из этой попытки не вышло ничего хорошего — хотя в этом контексте некорректно сравнивать C# и С++.
А вот из попытки написать ядро ОС на шарпе вышла сингулярити, переросшая в напрочь засекреченную под неблагозвучным названием Midori.
Здравствуйте, Tilir, Вы писали:
T>А свобода программиста, которую даёт C, ну да в том числе и свобода ошибаться, это самое ценное что у меня, например, есть.
А почему для тебя свобода "что хочу, то и ворочу" важнее чем "ворочу все, что можно"?
Здравствуйте, rfq, Вы писали:
M>> А с какой радости? Чем плох JIT в ядре? Чем плох realtime GC в ядре? Мало было в линухе утечек? rfq>Вот только и JIT и GC сами-то пишутся на C++.
Решение сократить плоскость реализации атаки сразу на целый класс уязвимостей до двух-трех модулей платформы, мне представляется более грамотным, по сравнению с отказом от их использования вообще.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нужна ли нам свобода ? Для того, чтобы ответить, надо задать другой вопрос — а что вообще надо ?
PD>Говорить буду от своего имени. Согласные могут присоединиться
PD>Мне надо
PD>1. Иметь возможность делать все, что я хочу. Разумееется, в рамках того, что мне позволяет аппаратура и (возможно) операционная система, а также мои мозги. Слово "возможно" здесь не случайно. В определенных границах я могу изменить поведение ОС, добавив к ней свой модуль (драйвер)
Т.е. тебе необходимо ощущение того, что ты можешь сделать все что захочешь под конкретной ОС (именно ощущение, т.к. меня терзают смутные сомнения о частоте возникновения потребности в написании драйвера при решении повседневных задач).
PD>2. Чтобы это работало как можно более быстро и потребляло ресурсов как можно меньше. Я пишу не серверное ПО, а моя ОС не MS-DOS, так что работать это все будет в коммунальной квартире, а поэтому ванную занимать на 3 часа нечего и свет в туалете надо тушить.
Знаешь, у меня был рабочий (конторский ноут) с одним ядром на полтора гигагерца и одним гигом оперативки. Однажды я подошел к коллеге, который отвечает в ИТ за апгрейды оборудования для рабочих мест и спросил, что нужно сделать, чтобы заменить себе ноут на более мощный? Он ответил, что по старой дружбе, правильного скриншота закладки "быстродействие" из диспетчера задач, на котором будет наглядно показано, как мне грустно работается на текущей конфигурации, будет более чем достаточно. Казалось бы, простая задача — занять проц на 70-80% (не на 100% — чтобы не палиться) и вызвать безудержный своп. Попробуй решить ее на C# (на самом деле, это легко, но тогда я еще не владел дао управления памятью в .net)... Мне это удалось минут через 15-20 борьбы с GC и при этом прога проработала около 5 минут, прежде чем началось то, что мне было нужно. С тех пор у меня двухядерный ноут на 2,5 гигагерца с 4 гигами оперативки
Намек, думаю понятен...
PD>Первый мой вопрос — а как с п.1 и 2 будет. Гарантируете ли вы, что я по-прежнему смогу делать все. что я умею делать, использовать все те возможности ОС, которые умею использовать ? И будет ли это работать столь же быстро и требовать ресурсов не больше ?
Я прямо сейчас, безотносительно языка, могу гарантировать, что это тебе не нужно в 80-90 процентах решаемых тобой задач
PD>Как только я этот вопрос задаю, так сразу мои оппоненты начинают юлить.
Они просто пугаются, т.к. думают что ты работаешь на оборонку и пишешь софт для ядерных боеголовок
PD>Сможешь , наверное, только вот иногда тебе придется на неуправляемый код переходить, а иногда и вообще не получится. Но ты мол, не огорчайся, если не получится, то это значит, что тебе такое и не надо, мы тебе другое предложим... И работать это будет быстрее. Ах, у тебя все же медленнее получается... Ну значит , ты неправильно меряешь, не на тех тестах , и вообще имей в виду — в светлом будущем наш код намного лучше будет. Светлое будущее обещать они очень любят.
А можно взглянуть на реальную (не надуманную задачу) где быстродействие, достижимое на управляемых платформах является неприемлемым, из твоей практики? А десяток таких задач?
PD>Я утрирую ? Нет.
Нет. Навскидку — усемеряешь.
PD>Ну насчет скорости — мы тут уже столько копий сломали, что вряд ли стоит еще одно ломать. А вот насчет возможностей... Никакой я не специалист в C# и .NET, я там просто дилетант, не более. Но тем не менее мне неоднократно доводилось давать советы в форуме по .NET, причем за эти советы я получал баллы в рейтинге.
*закадровый шепот* Павел, я тут за такую фигню, вообще не имеющую отношения к программированию, пол своего рейтинга заработал...
PD>Разумеется, мне и в голову не придет давать совет, когда речь идет о каких-то итераторах или замыканиях, но вот когда речь заходит о взаимодействии с Windows, об использовании ее механизмов — мои советы порой звучат для некоторых там как откровение.
Да, меня это тоже удручает. К сожалению, в .NET еще встречаются задачи, когда полностью абстрагироваться от окружающей тебя ОС не получится при всем желании
PD>Хорошо, конечно. Что я еще могу сказать! Вы предлагаете мне отказаться от свободы, но в ответ обещаете, что я смогу писать код без ошибок ? Да — мне в ответ. PD>Без любых ошибок ?
PD>И тут опять мои опппоненты юлить начинают. Мемори ликов у тебя не будет. Ладно, говорю, спасибо, хотя у меня их и так не много, инструменты для их обнаружения есть. Индекс у тебя за пределы массива не выйдет. Тоже спасибо, отвечаю я, он и так у меня как правило не выходит, если только я сам не хочу, чтобы он выходил. Что там еще ? Уничтоженные объекты не будешь использовать. Тоже спасибо, хотя и так попытка взятия по NULL определяется без особого труда.
Тебя это просто перестанет беспокоить с переходом на .NET А если это сейчас тебя и так не беспокоит, то и переходить на .NET, пожалуй не стоит. Но мне вот что интересно: можно чуть подробнее про поиск ликов (и его достоверность), про основу твоей уверенности в том, что индексы не выходят за предел и про то, как именно ты определяешь попытки использования нулевого указателя?
PD>А от логических ошибок вы меня оградите ? От ошибок алгоритма или его реализации ? От того, что я при вычислении корней уравнения вместо b*b-4*a*c написал b*b+4*a*c ? От того, что я понимал эту задачу так-то, а она, оказывается, выглядит совсем не так, но это проявляется в одном случае на миллион ? С IndexOutOfRange я как-нибудь и так справлюсь, а вот с этим-то что делать ? Поможете ? PD>А в ответ — либо тишина, либо рассуждения о светлом будущем, когда весь код будет верифицироваться (надо полагать, верификатор будет распознавать подпрограмму вычисления корней уравнения, знать этот алгоритм и подскажет мне — ты там плюс вместо минуса поставил Остается только понять — почему он в таком случае за меня программу сам не написал.)
Тут затрудняюсь что-либо прокомментировать, т.к. ничего подобного лично я не утверждал
PD>Тот код, который ты показал, при определенных условиях вполне безупречен.
Он не безупречен по одной лишь причине: у его разработчика не было ни малейших оснований предполагать, что указатель на пайп не может быть нулевым при входе в функцию, либо после входа в функцию, но до установки мьютекса.
PD>И вот эти логические ошибки меня больше всего и беспокоят. Они у меня львиную часть времени съели. А не выходы индексов и прочая чепуха.
Эта самая "чепуха" занимает 45% от всех уязвимостей, когда-либо публиковавшихся на secunia (один из наиболее авторитетных и полных источников подобной информации). Поэтому меня эта чепуха также беспокоит. Впрочем, как и логические ошибки, если быть честным.
PD>Резюмирую. Готов ли я отдать свою свободу (в программировании, конечно, только там) за что-то ? Пока не дадите твердого ответа на п.1 и 2. — категорически не готов. А когда дадите — тогда поторгуемся по п.3. Пока хорошо не заплатите — тоже не отдам.
Неужели оно того стоит?
P.S: Про вертолет, как я понимаю, это было в отместку за "простреленные ноги"?
Здравствуйте, Pavel Dvorkin, Вы писали:
OE>>ну и аргумент, охренеть — ваша кофеварка не умеет стирать бельё!??? в топку её! PD>Если меня больше всего интересует, как постирать белье , а ты мне предлагаешь кофеварку — в топку!
Угу, правда не понятно при этом, каким боком тебя интересует стирка белья в рамках процесса приготовления кофе
Здравствуйте, rfq, Вы писали:
rfq>Вот только и JIT и GC сами-то пишутся на C++.
Если мне не изменяет память, .NET'овский GC был написан на LISP'е, а код на C++ получился путём трансляции специальной тулзой. Которая вроде тоже вовсе не на C++ была сваяна
Re[2]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, minorlogic, Вы писали:
M>Не думаю что найдется большой процент програмистов на С++ или С которые откажутся от статического и динамического верификатора кода.
Э-э-э... А Вы точно уверены, что "большой процент програмистов на С++ или С" вообще знают что такое "статический и динамический верификатор кода" ?
M>Я не думаю что найдется много прогамистов которые бы отказались от снятия накладных расходов накладываемых JVM.
Ну вот лично меня эти самые накладные расходы беспокоили только на J2ME Там где на всё про всё было 100Кб хипа, а само приложение приходилось упихивать в 30Кб.
M>Зачем писать утилиту администрации ДБ на С++?
Именно! Но ведь того — пишут
Re[3]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, drol, Вы писали:
D>Э-э-э... А Вы точно уверены, что "большой процент програмистов на С++ или С" вообще знают что такое "статический и динамический верификатор кода" ?
Не знаю. Это не имеет значения.
D>Ну вот лично меня эти самые накладные расходы беспокоили только на J2ME Там где на всё про всё было 100Кб хипа, а само приложение приходилось упихивать в 30Кб.
И ?
D>Именно! Но ведь того — пишут
И ?
Здравствуйте, kochetkov.vladimir, Вы писали:
OE>>>ну и аргумент, охренеть — ваша кофеварка не умеет стирать бельё!??? в топку её! PD>>Если меня больше всего интересует, как постирать белье , а ты мне предлагаешь кофеварку — в топку!
KV>Угу, правда не понятно при этом, каким боком тебя интересует стирка белья в рамках процесса приготовления кофе
Нет, все как раз наоборот. У меня проблемы со стиркой белья, вода извне в машину не течет, а изнутри вытекает на пол, ротор не крутится и т.п, а тут ко мне приходят и говорят : "Мы знаем, что вам нужно, и именно сейчас! Мы решим все ваши проблемы. Самая лучшая кофеварка от фирмы Идиотекс!!! Только у нас!"
Я человек мирный, но если они со своей идиотековской кофеваркой попадутся мне под горячую руку, то я не ручаюсь, что не употреблю эту кофеварку не по прямому назначению
Здравствуйте, MichaelLa, Вы писали:
ML>Володя, вместо минусов лучше займись баг-фиксингом
Я вообще программингом на работе не занимаюсь, это у меня не более чем хобби
А минус — уберу легко, как только будут хоть какие-нибудь аргументы в пользу отминусованного утверждения Собственно, я не согласен не с самим утверждением, а с отсутствием каких-либо рассуждений на эту тему.
Здравствуйте, minorlogic, Вы писали:
PD>>Нет, просто эти приоритеты выстроены в соответствии с моими задачами.
M>Я об этом и говорю, вы используете критерии ваших задач на других задачах.
Наоборот. Я пытаюсь показать, что бывают иные критерии. Я согласен, что мои критерии не обязательны для всех, но мне же отвечают — они вообще почти никуда не годятся. Вот, например
IT> О решении бизнес и ряда системных задач можно сразу забыть навсегда.
Как же мне теперь всерьез относиться к высказыванию таких оппонентов, если я решал именно определенные бизнес-задачи (не сайты , правда), и исповедовал именно эти принципы. И мне именно за это и платили.
With best regards
Pavel Dvorkin
Re[5]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>Прикольно, а зачем по-твоему я тогда его сюда вставил? Но ок, буду ждать. PD>>У меня сейчас лекция, после нее отвечу.
KV>А у меня случился больничный , и под рукой ядра нет, а лазать по git'у через GPRS — долго и нудно. В общем, предлагаю перенести обсуждение конкретно этого кода на следующую неделю, ок?
OK. Жду то, о чем я писал чуть выше. Мне просто любопытно.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>С такими низкоуровневыми приоритетами можно решать только низкоуровневые задачи. Для узкой группы задач вроде ковыряния в железках это возможно будет работать. О решении бизнес и ряда системных задач можно сразу забыть навсегда.
PD>Бизнес (в твоем понимании) — пожалуй, да, так как там царит, похоже, принцип — хоть как, но быстрее, давай-давай. Впрочем, есть и другие бизнес-задачи, и там это вполне работает (в моей работало).
Это всё домыслы. В решении бизнес задач царит принцип эффективности. Писать сегодня код на C дорого, медленно, не эффективно. Тоже самое касается и системных задач, но в них требования к потреблению ресурсов могут оказаться приоритетнее. Там, где в системных задачах ресурсы мало кого интересуют, тоже используются более эффективные инструменты, чем C.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, IT, Вы писали:
PD>>>Бизнес (в твоем понимании) — пожалуй, да, так как там царит, похоже, принцип — хоть как, но быстрее, давай-давай. Впрочем, есть и другие бизнес-задачи, и там это вполне работает (в моей работало).
IT>>Это всё домыслы. В решении бизнес задач царит принцип эффективности.
PD>Эффективности чего ? Работы программиста или конечного кода ?
>>Писать сегодня код на C дорого PD>Да
Продолжай мысль: потратиться на железо дешевле, чем оптимизировать программу. Особенно это касается памяти.
>>медленно PD>Да
Продолжай мысль: надо раньше выпустить продукт, чтобы потом было время что-либо оптимизировать.
>>не эффективно PD>С точки зрения времени работы программиста — да. С точки зрения эффективности рабочей программы — наоборот.
Неверно, меньшие затраты на выпуск программы дают больше возможностей (финансовых и по времени) для оптимизации.
>>Тоже самое касается и системных задач, но в них требования к потреблению ресурсов могут оказаться приоритетнее. Там, где в системных задачах ресурсы мало кого интересуют, тоже используются более эффективные инструменты, чем C. PD>Да. Но только когда ресурсы мало кого интересуют.
А с чего ты взял что на С буждет потребляться меньше ресурсов (и каких ресурсов вообще)?
Напиши highload сайт полностью на С\C++.
>>>Писать сегодня код на C дорого PD>>Да G>Продолжай мысль: потратиться на железо дешевле, чем оптимизировать программу. Особенно это касается памяти.
Доказательства в студию.
>>>медленно PD>>Да G>Продолжай мысль: надо раньше выпустить продукт, чтобы потом было время что-либо оптимизировать.
Если продукт не работает с минимально требуемой скоростью — он не продукт.
>>>не эффективно PD>>С точки зрения времени работы программиста — да. С точки зрения эффективности рабочей программы — наоборот. G>Неверно, меньшие затраты на выпуск программы дают больше возможностей (финансовых и по времени) для оптимизации.
Вот это уж точно. Если сначала сделать как-нибудь, то возможностей потом улучшить будет точно больше. Ну, скажем, переписать все с нуля
>>>Тоже самое касается и системных задач, но в них требования к потреблению ресурсов могут оказаться приоритетнее. Там, где в системных задачах ресурсы мало кого интересуют, тоже используются более эффективные инструменты, чем C. PD>>Да. Но только когда ресурсы мало кого интересуют.
G>А с чего ты взял что на С буждет потребляться меньше ресурсов (и каких ресурсов вообще)?
Я это обосновывал не раз, новых аргументов нет. Прежние ты знаешь.
G>Напиши highload сайт полностью на С\C++.
Что за чепуха ? Когда это я предлагал сайты на С/C++ писать ? Он совсем не для написания сайтов!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
>>>>Писать сегодня код на C дорого PD>>>Да G>>Продолжай мысль: потратиться на железо дешевле, чем оптимизировать программу. Особенно это касается памяти.
PD>Доказательства в студию.
Месяц работы программиста — от 30000 до 80000 рублей. Гигабайт оперативки стоит меньше 1000р. За месяц работы программиста можно купить неплохой компьютер.
>>>>медленно PD>>>Да G>>Продолжай мысль: надо раньше выпустить продукт, чтобы потом было время что-либо оптимизировать.
PD>Если продукт не работает с минимально требуемой скоростью — он не продукт.
Правильно. Какая скорость работы минимально требуется? И как её определить?
Для этого надо как минимум написать программу чтобы она была коректной
Определись для начала что такое скорость работы. Для пользователя это время отклика интерфейса, а не время полной обрабоки.
Например в каком-нить ICQ, skype или jabber я предпочту сразу отправлять сообщения, не додижаясь сообщения о подтверждении (чтобы они приходили асинхронно), чем ждать пока сообщение будет доставлено (синхронно).
Кроме того визуальный feedback длительной операции уменьшает воспринимаемое время работы, хотя увеличивает реальное время работы.
>>>>не эффективно PD>>>С точки зрения времени работы программиста — да. С точки зрения эффективности рабочей программы — наоборот. G>>Неверно, меньшие затраты на выпуск программы дают больше возможностей (финансовых и по времени) для оптимизации.
PD>Вот это уж точно. Если сначала сделать как-нибудь, то возможностей потом улучшить будет точно больше. Ну, скажем, переписать все с нуля
Про 80%/20% слышал? Максимум придется переписывать 20%, если тормоза не заложены в архитектуре (как с mutable строками).
>>>>Тоже самое касается и системных задач, но в них требования к потреблению ресурсов могут оказаться приоритетнее. Там, где в системных задачах ресурсы мало кого интересуют, тоже используются более эффективные инструменты, чем C. PD>>>Да. Но только когда ресурсы мало кого интересуют.
G>>А с чего ты взял что на С буждет потребляться меньше ресурсов (и каких ресурсов вообще)? PD>Я это обосновывал не раз, новых аргументов нет. Прежние ты знаешь.
Да ты ниче не обосновывал. Максимум приводил тривиальные примеры, которые вообще ничего не доказывают.
G>>Напиши highload сайт полностью на С\C++. PD>Что за чепуха ? Когда это я предлагал сайты на С/C++ писать ? Он совсем не для написания сайтов!
А для чего? Если че — написание для веба на сегодня одна из самых востребованных областей.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Мне надо PD>1. Иметь возможность делать все, что я хочу. Разумееется, в рамках того, что мне позволяет аппаратура и (возможно) операционная система, а также мои мозги. Слово "возможно" здесь не случайно. В определенных границах я могу изменить поведение ОС, добавив к ней свой модуль (драйвер) PD>2. Чтобы это работало как можно более быстро и потребляло ресурсов как можно меньше. Я пишу не серверное ПО, а моя ОС не MS-DOS, так что работать это все будет в коммунальной квартире, а поэтому ванную занимать на 3 часа нечего и свет в туалете надо тушить. PD>3. Чтобы в этом коде было как можно меньше ошибок. Говорить "чтобы не было ошибок" не буду, так как программа без ошибок есть абстрактное теоретическое понятие. PD>4. Чтобы я на это потратил как можно меньше своего времени. PD>Замечу, что эти пожелания выстроены мной строго в соответствии с моими приоритетами. Иными словами, если мне предлагается нечто, резко улучшающее пункт i+1 за счет ухудшения в пункте i — меня это не устроит.
Приоритеты — понятны.
Но ИМХО их надо ставить в таком порядке:
3, 4, 1, 2. PD>Ты мне предлагаешь начать с пунктов 3 и 4. Обещаешь, что в коде будет меньше ошибок, и я смогу написать быстрее. Насчет второго не спорю, а первое еще обсудим, попозже.
Правильно предлагает. PD>Первый мой вопрос — а как с п.1 и 2 будет.
По мере возможности. PD>Гарантируете ли вы, что я по-прежнему смогу делать все. что я умею делать, использовать все те возможности ОС, которые умею использовать ? И будет ли это работать столь же быстро и требовать ресурсов не больше ?
Гарантировать никто не может. Но нужно искать компромисс...
В конце-концов, абсолютная свобода достигается только при написании в кодах и на голой машине...
Но это долго — поэтому надо искать компромисс.
А про эффективность — тут необходимо чувство меры... Ибо можно выжимать микросекунды, тратя на это ДНИ... PD>Резюмирую. Готов ли я отдать свою свободу (в программировании, конечно, только там) за что-то ? Пока не дадите твердого ответа на п.1 и 2. — категорически не готов.
Насчет свободы еще. Ленин же гениально сказал, что свобода — это ОСОЗНАННАЯ необходимость... Ею надо уметь пользоваться...
Проблема в том, что в отличие от тебя, огромное большинство программистов пользоваться свободой не умеют... Надо много пота и крови пролить, чтобы понять, как пользоваться свободой С++. Поэтому и предлагаются инструменты, ограничивающие НЕОГРАНИЧЕННУЮ свободу.
И в конце-концов, любая свобода — относительна.
Если свободы не хватает — "купи козу" и поживи с ней. А потом "продай козу" — и ТАКУЮ свободу ощутишь... Хотя фактически — ничего не изменилось...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Приоритеты — понятны. LVV>Но ИМХО их надо ставить в таком порядке: LVV>3, 4, 1, 2.
Ну вот от того, кто как ставить и возникают все разногласия. Я ставлю именно так.
PD>>Ты мне предлагаешь начать с пунктов 3 и 4. Обещаешь, что в коде будет меньше ошибок, и я смогу написать быстрее. Насчет второго не спорю, а первое еще обсудим, попозже. LVV>Правильно предлагает. PD>>Первый мой вопрос — а как с п.1 и 2 будет. LVV>По мере возможности.
А тогда у меня ничего не будет. От меня требуют максимум по п.1, и без него и говорить не о чем.
PD>>Гарантируете ли вы, что я по-прежнему смогу делать все. что я умею делать, использовать все те возможности ОС, которые умею использовать ? И будет ли это работать столь же быстро и требовать ресурсов не больше ? LVV>Гарантировать никто не может. Но нужно искать компромисс...
Это как ? Гибрид С++ с C# ? Можно
LVV>В конце-концов, абсолютная свобода достигается только при написании в кодах и на голой машине... LVV>Но это долго — поэтому надо искать компромисс.
Быстро хорошо не бывает.
LVV>А про эффективность — тут необходимо чувство меры... Ибо можно выжимать микросекунды, тратя на это ДНИ...
Чем я порой и занимаюсь. Только все же милли, а не микро.
PD>>Резюмирую. Готов ли я отдать свою свободу (в программировании, конечно, только там) за что-то ? Пока не дадите твердого ответа на п.1 и 2. — категорически не готов. LVV>Насчет свободы еще. Ленин же гениально сказал, что свобода — это ОСОЗНАННАЯ необходимость...
А кто-то хорошо сказал, что есть еще иная свобода, кроме осознанной необходимости
>Ею надо уметь пользоваться...
Ну я и пытаюсь.
LVV>Проблема в том, что в отличие от тебя, огромное большинство программистов пользоваться свободой не умеют... Надо много пота и крови пролить, чтобы понять, как пользоваться свободой С++. Поэтому и предлагаются инструменты, ограничивающие НЕОГРАНИЧЕННУЮ свободу.
Да бога ради. Кому нравится арбуз, а кому — свинячий хвостик (К. Прутков, если не ошибаюсь)
LVV>И в конце-концов, любая свобода — относительна. LVV>Если свободы не хватает — "купи козу" и поживи с ней. А потом "продай козу" — и ТАКУЮ свободу ощутишь... Хотя фактически — ничего не изменилось...
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
G>>>>Напиши highload сайт полностью на С\C++. PD>>>Что за чепуха ? Когда это я предлагал сайты на С/C++ писать ? Он совсем не для написания сайтов! G>>А для чего? Если че — написание для веба на сегодня одна из самых востребованных областей.
N>Меня поражают иногда такие споры. Оппонент практически в каждом сообщении описывает свой круг задач, но его никто не слушает и со своей колокольни начинают мучать сайтами и базами данных. Ей богу, Павлу надо подпись сделать: "Сайты не разрабатываю".
А что мелочиться, сразу написать — ничего не разрабатываю.
N>Для разнообразия предлагаю тебе, gandjustas, написать безопасное приложение, которое будет работать на видеокарте с CUDA SDK. Потренируйся, посмотри что это практически невозможно. (Даже стандартный пример с рекомендуемыми дровами, на рекомендованном оборудовании может вызвать синий экран.)
Ну я писал такое, и что?
Ты придумай сходу реальную задачу где такое понадобится.
Здравствуйте, gandjustas, Вы писали:
G>А что мелочиться, сразу написать — ничего не разрабатываю.
Это не КСВ, передёргивания и хамство не приветствуется.
N>>Для разнообразия предлагаю тебе, gandjustas, написать безопасное приложение, которое будет работать на видеокарте с CUDA SDK. Потренируйся, посмотри что это практически невозможно. (Даже стандартный пример с рекомендуемыми дровами, на рекомендованном оборудовании может вызвать синий экран.) G>Ну я писал такое, и что?
Не верю. Безопасности нет в самой платформе, следовательно нет и в твоём приложении. Всё просто, тут не поюлишь. Если не веришь мне, то поищи отзывы в интернете "лестные" отзывы о драйверах NVidia.
G>Ты придумай сходу реальную задачу где такое понадобится.
Для начала классика: Примеры внедрения NVIDIA CUDA
Из моей практики (системы видеонаблюдения): массовое разжатие видео, детектор движения.
Это самые что ни на есть реальные примеры.
Здравствуйте, Nuzhny, Вы писали:
N>Меня поражают иногда такие споры. Оппонент практически в каждом сообщении описывает свой круг задач, но его никто не слушает и со своей колокольни начинают мучать сайтами и базами данных. Ей богу, Павлу надо подпись сделать: "Сайты не разрабатываю".
А что, это идея. Подумаю
N>Для разнообразия предлагаю тебе, gandjustas, написать безопасное приложение, которое будет работать на видеокарте с CUDA SDK. Потренируйся, посмотри что это практически невозможно. (Даже стандартный пример с рекомендуемыми дровами, на рекомендованном оборудовании может вызвать синий экран.) Примени свои знания C#, .Net, храни текстуры в MS SQL и подгружай их запросами. А мы посмотрим.
Присоединяюсь, тем более что с CUDA дела имел.
With best regards
Pavel Dvorkin
Re[2]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, LaptevVV, Вы писали:
LVV>И устаканить в мозгах постулат: НАДЕЖОСТЬ ВАЖНЕЕ ЭФФЕКТИВНОСТИ!!!!!!!!!
Как постулат — не приемлю. Зависит от ситуации.
Например, сервисы Windows, и действия на случай их падения. Как там насчет эффективности — судить не буду, однако хочу отметить, что крах приложения вполне может быть допускаемым событием с предусмотренной реакцией.
With best regards
Pavel Dvorkin
Re[3]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, Pavel Dvorkin, Вы писали:
LVV>>И устаканить в мозгах постулат: НАДЕЖОСТЬ ВАЖНЕЕ ЭФФЕКТИВНОСТИ!!!!!!!!! PD>Как постулат — не приемлю. Зависит от ситуации. PD>Например, сервисы Windows, и действия на случай их падения. Как там насчет эффективности — судить не буду, однако хочу отметить, что крах приложения вполне может быть допускаемым событием с предусмотренной реакцией.
А можешь КОНКРЕТНО представить себе предприятие, в котором при эксплуатации ПО
крах приложения вполне может быть допускаемым событием с предусмотренной реакцией.
Я, например, не могу...
Во всех конторах, где я работал, крах... считался ЧП.
Только при разработке исследовательского проекта такое можно себе допустить. А в производстве ИМХО НЕЛЬЗЯ НИКОГДА!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, LaptevVV, Вы писали:
LVV>А можешь КОНКРЕТНО представить себе предприятие, в котором при эксплуатации ПО LVV>
LVV>крах приложения вполне может быть допускаемым событием с предусмотренной реакцией.
Могу. В проекте, в котором я участвовал, это было именно таковым. При крахе процесс просто автоматически перезапускался и продолжал работу.
LVV>Я, например, не могу... LVV>Во всех конторах, где я работал, крах... считался ЧП. LVV>Только при разработке исследовательского проекта такое можно себе допустить. А в производстве ИМХО НЕЛЬЗЯ НИКОГДА!
Это было (и есть) очень даже не исследовательский проект
Здравствуйте, gandjustas, Вы писали:
G>И что ты посчитал? G>Если дело касается большой распределенной сиситемы, то оптимизация в 1% может выйти гораздо дороже 60 килобаксов.
Дело касается именно большой системы, но вполне независимых машин. Какая еще другая оптимизация может выйти дороже 60,000 USD — не знаю, а вот такая , о которой я писал, может дать эти 60000 почти задаром.
А если все же не 1%, а хотя бы 10% ?
G>Кроме того, чтобы заниматься такой оптимизацией надо уже иметь рабочую систему. Если начинать писать на C, то до получения рабочей системы затраты будут гораздо больше
И та система, о разработке которой я говорю, писалась таки на С.
G>Ну так расскажи что ты имеешь ввиду под скоростью работы и как ты её увеличиваешь.
v = ds/dt. Количество обрабатываемых единиц работы в единицу времени.
А подробности того, что и как я увеличиваю — все описано в документации по проекту, которую я здесь публиковать не собираюсь
G>Да ты больше конкретики приводи
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
G>>А что мелочиться, сразу написать — ничего не разрабатываю. N>Это не КСВ, передёргивания и хамство не приветствуется.
N>>>Для разнообразия предлагаю тебе, gandjustas, написать безопасное приложение, которое будет работать на видеокарте с CUDA SDK. Потренируйся, посмотри что это практически невозможно. (Даже стандартный пример с рекомендуемыми дровами, на рекомендованном оборудовании может вызвать синий экран.) G>>Ну я писал такое, и что? N>Не верю.
Твое право.
N>Безопасности нет в самой платформе, следовательно нет и в твоём приложении. Всё просто, тут не поюлишь. Если не веришь мне, то поищи отзывы в интернете "лестные" отзывы о драйверах NVidia.
Верю, в данном случае надежность не зависит от того что я напишу, поэтому меня не парит.
G>>Ты придумай сходу реальную задачу где такое понадобится. N>Для начала классика: Примеры внедрения NVIDIA CUDA N>Из моей практики (системы видеонаблюдения): массовое разжатие видео, детектор движения. N>Это самые что ни на есть реальные примеры.
Большинство — ускорение существующих программ. То есть приходим к тому же: сначала реализуется рабочее решение (желательно надежное), а потом оптимизируется, например с помощью cuda.
Re[5]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, Pavel Dvorkin, Вы писали:
LVV>>А можешь КОНКРЕТНО представить себе предприятие, в котором при эксплуатации ПО LVV>>
LVV>>крах приложения вполне может быть допускаемым событием с предусмотренной реакцией.
PD>Могу. В проекте, в котором я участвовал, это было именно таковым. При крахе процесс просто автоматически перезапускался и продолжал работу.
Ага! Все же перезапускался!
А не скажешь, много ли данных при этом терялось и насколько это было критично? PD>Это было (и есть) очень даже не исследовательский проект
А конкретней нельзя? Секретно?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[6]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, LaptevVV, Вы писали:
PD>>Могу. В проекте, в котором я участвовал, это было именно таковым. При крахе процесс просто автоматически перезапускался и продолжал работу. LVV>Ага! Все же перезапускался!
Естественно. Просто падение одного процесса Windows — еще не повод для паники.
LVV>А не скажешь, много ли данных при этом терялось и насколько это было критично?
Честно сказать, не знаю, так как этой частью я не занимался. Немного, я полагаю. И уж во всяком случае некритично.
LVV>А конкретней нельзя? Секретно?
Нет, совсем не секретно, но я не рассказываю здесь подробностей о своих работах. Просто не хочу.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
G>>И что ты посчитал? G>>Если дело касается большой распределенной сиситемы, то оптимизация в 1% может выйти гораздо дороже 60 килобаксов.
PD>Дело касается именно большой системы, но вполне независимых машин. Какая еще другая оптимизация может выйти дороже 60,000 USD — не знаю, а вот такая , о которой я писал, может дать эти 60000 почти задаром.
PD>А если все же не 1%, а хотя бы 10% ?
Ну так если оно того стоит, то почему бы и не потратиться.
Тут же вопрос в другом. Можно сначала пытаться писать систему, которая будет пытаться работать быстро (зачастую такое получается в ущерб коррентности), а можно написать корректую систему и её оптимизировать.
Ты всегда предлагаешь первый вариант, тебе всегда предлагают второй.
Обычно первый варинт приводит или к повышенным затратам на разработку еще до оптимизации, или к жутко негибкому решению, которое требует больших затрат при поддержке.
G>>Ну так расскажи что ты имеешь ввиду под скоростью работы и как ты её увеличиваешь. PD>v = ds/dt. Количество обрабатываемых единиц работы в единицу времени.
А что за единицы, откуда они приходят, в чем заключается обработка, какова нагрузка и как она меняется, насколько связаны между собой обработки отдельных единиц, realtime или нет?
Здравствуйте, gandjustas, Вы писали:
G>Ну так если оно того стоит, то почему бы и не потратиться. G>Тут же вопрос в другом. Можно сначала пытаться писать систему, которая будет пытаться работать быстро (зачастую такое получается в ущерб коррентности), а можно написать корректую систему и её оптимизировать. G>Ты всегда предлагаешь первый вариант, тебе всегда предлагают второй. G>Обычно первый варинт приводит или к повышенным затратам на разработку еще до оптимизации, или к жутко негибкому решению, которое требует больших затрат при поддержке.
Всяко бывает. Давай закончим это обсуждение.
G>>>Ну так расскажи что ты имеешь ввиду под скоростью работы и как ты её увеличиваешь. PD>>v = ds/dt. Количество обрабатываемых единиц работы в единицу времени. G>А что за единицы, откуда они приходят, в чем заключается обработка, какова нагрузка и как она меняется, насколько связаны между собой обработки отдельных единиц, realtime или нет?
Все тебе расскажи
With best regards
Pavel Dvorkin
Re[2]: Павлу Дворкину: о понимании того что делаешь и просты
Приветствую, LaptevVV, вы писали:
LVV> Ну это примерно так же, как запретить кухонные ножи. Ведь дети могут порезаться! Да и вообще — мало ли ножами кухонными друг-друга режут!? LVV> ИМХО, нужно просто лучше готовить профессионалов. Чтобы любители с ними близко не стояли по квалификакции... Тогда и не будет таких ляпов...
Вот до этих пор было все супер.
LVV> И устаканить в мозгах постулат: НАДЕЖОСТЬ ВАЖНЕЕ ЭФФЕКТИВНОСТИ!!!!!!!!!
А вот здесь уже спорно... Надежность безусловно важна, но если программеры-профессионалы, то надежность будет и так. Следовательно надо делать ставку на эффективность.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
N>>>Безопасности нет в самой платформе, следовательно нет и в твоём приложении. Всё просто, тут не поюлишь. Если не веришь мне, то поищи отзывы в интернете "лестные" отзывы о драйверах NVidia. G>>Верю, в данном случае надежность не зависит от того что я напишу, поэтому меня не парит. N>То есть написание небезопасных программ уже допускается. Хорошо!
А причем здесь "написание" ? Ведь при таком раскладе программа будет ненадежной независимо от того как писать.
G>>Большинство — ускорение существующих программ. То есть приходим к тому же: сначала реализуется рабочее решение (желательно надежное), а потом оптимизируется, например с помощью cuda. N>Не всегда. Ещё один пример из жизни: определение нарушений правил дорожного движения. По изображению с одной камеры определяются нарушения, а другая, снабжённая поворотным механизмом, должна успеть навестись на номер нарушителя и распознать его. Машины ездят быстро, всё надо делать очень быстро. Так вот, к чему всё это: медленный и надёжный вариант не подойдёт. Никак. Его даже на работоспособность не проверишь.
Но ненадежный вариант тоже не пойдет
N>Такой пример подойдёт?
Отличный пример. Срабатывание системы долже обеспечивать радар, а не камера, иначе скорость определить не получится. А вот распознование выполнять в realtime не надо, надо что оно вообще хоть как-то выполнилось.
Опять получается что CUDA — бонус оптимизации к основной функциональности.
Вообще говоря в таких условиях система не будет гарантировать точного срабатывания. Например если на камере засветились две машины, которые двигаются с интервалом меньше чем время поворота камеры на нужную дистанцию.
Здравствуйте, gandjustas, Вы писали:
N>>Для разнообразия предлагаю тебе, gandjustas, написать безопасное приложение, которое будет работать на видеокарте с CUDA SDK. Потренируйся, посмотри что это практически невозможно. (Даже стандартный пример с рекомендуемыми дровами, на рекомендованном оборудовании может вызвать синий экран.)
G>Ты придумай сходу реальную задачу где такое понадобится.
Финансовые расчёты, аналитика. Не так давно лично занимался CUDA для финансов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
N>>>Для разнообразия предлагаю тебе, gandjustas, написать безопасное приложение, которое будет работать на видеокарте с CUDA SDK. Потренируйся, посмотри что это практически невозможно. (Даже стандартный пример с рекомендуемыми дровами, на рекомендованном оборудовании может вызвать синий экран.)
G>>Ты придумай сходу реальную задачу где такое понадобится. CC>Финансовые расчёты, аналитика. Не так давно лично занимался CUDA для финансов.
Да почти любые массовые расчеты можно с помощью cuda оптимизировать.
Я неправльно вопрос задал. На было так: Где использование cuda необходимо?
Здравствуйте, gandjustas, Вы писали:
N>>То есть написание небезопасных программ уже допускается. Хорошо! G>А причем здесь "написание" ? Ведь при таком раскладе программа будет ненадежной независимо от того как писать.
Так это же основной аргумент апологетов безопасных языков: "Безопасная платформа — безопасная программа". И никаких тебе переполнений буфера.
G>>>Большинство — ускорение существующих программ. То есть приходим к тому же: сначала реализуется рабочее решение (желательно надежное), а потом оптимизируется, например с помощью cuda. N>>Не всегда. Ещё один пример из жизни: определение нарушений правил дорожного движения. По изображению с одной камеры определяются нарушения, а другая, снабжённая поворотным механизмом, должна успеть навестись на номер нарушителя и распознать его. Машины ездят быстро, всё надо делать очень быстро. Так вот, к чему всё это: медленный и надёжный вариант не подойдёт. Никак. Его даже на работоспособность не проверишь. G>Но ненадежный вариант тоже не пойдет
Тут важнее именно производительность.
N>>Такой пример подойдёт? G>Отличный пример. Срабатывание системы долже обеспечивать радар, а не камера, иначе скорость определить не получится. А вот распознование выполнять в realtime не надо, надо что оно вообще хоть как-то выполнилось.
С помощью радара можно детектировать только превышение скорости, я же говорю про: выезд на встречную, пересечение сплошной, запрещённый поворот, неправильная парковка и т.д.
G>Опять получается что CUDA — бонус оптимизации к основной функциональности.
Нет, тут главное быстродействие. Не успеет твоя программа — никакого нарушителя не будет. В принципе.
G>Вообще говоря в таких условиях система не будет гарантировать точного срабатывания. Например если на камере засветились две машины, которые двигаются с интервалом меньше чем время поворота камеры на нужную дистанцию.
Тут точность важное, но не главное свойство. Протоколы в конечном случае подписывает сотрудник ГИБДД — он контролирует корректность. А при отсутствии протоколов (если нарушения были) как раз и начнутся проблемы.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
N>>>То есть написание небезопасных программ уже допускается. Хорошо! G>>А причем здесь "написание" ? Ведь при таком раскладе программа будет ненадежной независимо от того как писать. N>Так это же основной аргумент апологетов безопасных языков: "Безопасная платформа — безопасная программа". И никаких тебе переполнений буфера.
Это верно.
Это не коррелирует с безопасностью ос и драйверов, на котором программа работает.
А пока ядро и дрова пишутся на небезопасных языках будет такая ситауция как с CUDA.
G>>>>Большинство — ускорение существующих программ. То есть приходим к тому же: сначала реализуется рабочее решение (желательно надежное), а потом оптимизируется, например с помощью cuda. N>>>Не всегда. Ещё один пример из жизни: определение нарушений правил дорожного движения. По изображению с одной камеры определяются нарушения, а другая, снабжённая поворотным механизмом, должна успеть навестись на номер нарушителя и распознать его. Машины ездят быстро, всё надо делать очень быстро. Так вот, к чему всё это: медленный и надёжный вариант не подойдёт. Никак. Его даже на работоспособность не проверишь. G>>Но ненадежный вариант тоже не пойдет N>Тут важнее именно производительность.
Производительность чего?
N>>>Такой пример подойдёт? G>>Отличный пример. Срабатывание системы долже обеспечивать радар, а не камера, иначе скорость определить не получится. А вот распознование выполнять в realtime не надо, надо что оно вообще хоть как-то выполнилось. N>С помощью радара можно детектировать только превышение скорости, я же говорю про: выезд на встречную, пересечение сплошной, запрещённый поворот, неправильная парковка и т.д.
Ок, можно снимать любое движение в реалтайме, а потом фильтровать без требований реалтайма.
G>>Опять получается что CUDA — бонус оптимизации к основной функциональности. N>Нет, тут главное быстродействие. Не успеет твоя программа — никакого нарушителя не будет. В принципе.
Быстродействие чего?
G>>Вообще говоря в таких условиях система не будет гарантировать точного срабатывания. Например если на камере засветились две машины, которые двигаются с интервалом меньше чем время поворота камеры на нужную дистанцию. N>Тут точность важное, но не главное свойство. Протоколы в конечном случае подписывает сотрудник ГИБДД — он контролирует корректность. А при отсутствии протоколов (если нарушения были) как раз и начнутся проблемы.
В случае ненадежного срабатывания часть протоколов также будет отсуствовать.
В итоге. Основная задача — быстро снять изображение. Обработка его быстрой быть не обязана, её вполне можно раскидать на кластер. А при желании ускорить с помощью CUDA.
Здравствуйте, gandjustas, Вы писали:
G>>>Ты придумай сходу реальную задачу где такое понадобится. CC>>Финансовые расчёты, аналитика. Не так давно лично занимался CUDA для финансов. G>Да почти любые массовые расчеты можно с помощью cuda оптимизировать.
Далеко не любые.
G>Я неправльно вопрос задал. На было так: Где использование cuda необходимо?
Там, где надо ускорить вычисления, которые могут быть ускорены на CUDA
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
G>>Я неправльно вопрос задал. На было так: Где использование cuda необходимо? CC>Там, где надо ускорить вычисления, которые могут быть ускорены на CUDA
Ну и парочку примеров где это необходимо, так что без cuda-ускорения не будут выполняться задачи.
Здравствуйте, gandjustas, Вы писали:
N>>Тут важнее именно производительность. G>Производительность чего? G>... G>Быстродействие чего? G>... G>В итоге. Основная задача — быстро снять изображение. Обработка его быстрой быть не обязана, её вполне можно раскидать на кластер. А при желании ускорить с помощью CUDA.
Нет, надо в реальном времени распознать нарушение, предсказать положение нарушителя на время, в течение которого камера с поворотным механизмом сумеет навестись на номер, вычислить координаты, навести камеру, поймать изображение с номером. Иначе нарушитель-то уедет, он ждать не будет, пока его распознают. Вот тут производительность системы (быстродействие каждого этапа) очень важны.
Не обязательно использовать CUDA, можешь всего достигнуть на процессоре — пожалуйста. Но все алгоритмы реализуются без оглядки на скорость разработки, тут главное, чтобы вся система успела отработать. Не успеет — твой медленный и надёжный продукт никому не понадобится. Будет падать иногда, но работать — поставят, дадут возможность доделывать и исправлять. Это всё на собственной шкуре пройдено: были неудачные попытки внедрения.
Нет, насколько я понял из обсуждений уязвимости, народ до сих пор не может разобраться, где именно и почему возникает гонка и в итоге пропатчили все pipe_*_open(), на всякий случай. Однако крэш по null-reference, обнаружили опытным путем только в pipe_rdwr_open(). Иными словами, вышедший патч, добавляющий проверку на NULL, борется со следствием, а не с причиной. Причину в дебрях сишного кода ищут до сих пор.
Однако, побродив по коду в окрестностях уявзимости, я так и не понял, откуда у разработчика была уверенность в том, что передаваемые в функцию указатели не могут быть NULLевыми, либо освободиться до захвата функцией мьютекса. Чел, нашедший уязвимость (некий Earl Crew), кстати, похоже — тоже.
Здравствуйте, AndrewVK, Вы писали:
AVK>Про АЭС забыл.
Вы ошибаетесь. Лично я ничего не забыл. Но если Вам хочется чего-то именно en masse — и их есть у меня. Например, системы мониторинга в промышленности/на транспорте.
Автономная коробка с девайсом может быть установлена у чёрта на куличках — самый глухой участок БАМа, автоматическая метеостанция на Крайнем Севере, газопровод в джунглях Амазонки, и т.п. Отказов, например, по питанию, или там из-за багов драйверов интеграции с Iridium — навалом. Рестарт в таких системах — норма жизни.
Могу и прямо из личного опыта — лет 5+ назад мы делали компонент диспетчерской системы для автотранспорта. В качестве терминалов у водителей — мобилы с GPS-приёмниками. Все те же самые аспекты — рестарт должен быть заложен в архитектуру, бо мобила (особенно Motorola), сами понимаете, тот ещё девайс даже и без background-приложений
*И при этом, заметьте, воплощено всё было на голимой Java, ни грамма натива
Здравствуйте, gandjustas, Вы писали:
G>Нарушитель все равно будет ждать когда штраф ему придет по почте. Поэтому надо снять изображение, а как быстро оно обработается уже неважно. Возможно после обработки окажется что нарушений нет. Даже если система зафиксирует выезд на встречку, то возможно это был объезд сломавшегося автомобиля (те нарушения нет), а это должен определить человек, который точно медленнее компьютера сработает.
G>Не надо приявзяваться к тяжелым расчетам для realtime реакции.
Да, нет никакого номера нарушителя на видео — надо сначала навести камеру на него. Иначе просто нечего будет отправлять по почте. Работа с должным быстродействием как раз и позволяет обойтись минимальными затратами оборудования: 1 поворотная камера на все виды нарушений на протяжённом участке дороги.
Здравствуйте, AndrewVK, Вы писали:
N>>Нет, надо в реальном времени распознать нарушение AVK>Радар на аппаратном уровне выдает конкретное число.
Радар приемлем только для определения скорости. Я же говорю про широкий спектр нарушений.
N>>, предсказать положение нарушителя на время AVK>Да, решение линейного уровнения это мегасложно.
С каких это пор все стали ездить по прямым с постоянной скоростью?
Но я и не говорю, что это такой вычислительно сложный этап, а лишь перечислил все действия, которые должны выполниться с максимальной скоростью. Не надо вырывать из контекста — некрасиво.
N>> Иначе нарушитель-то уедет, он ждать не будет, пока его распознают. AVK>А они и уезжают по факту. В реальном времени распознавать не нужно.
Надо успеть сделать снимок его номера.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
G>>Нарушитель все равно будет ждать когда штраф ему придет по почте. Поэтому надо снять изображение, а как быстро оно обработается уже неважно. Возможно после обработки окажется что нарушений нет. Даже если система зафиксирует выезд на встречку, то возможно это был объезд сломавшегося автомобиля (те нарушения нет), а это должен определить человек, который точно медленнее компьютера сработает.
G>>Не надо приявзяваться к тяжелым расчетам для realtime реакции.
N>Да, нет никакого номера нарушителя на видео — надо сначала навести камеру на него.
Да не рассказывай, камера довольно большой угол имеет. Инчаче никак не наведешь, ибо вектор направления движения автомобиля обычно неизвестен.
Здравствуйте, Nuzhny, Вы писали:
AVK>>Радар на аппаратном уровне выдает конкретное число. N>Радар приемлем только для определения скорости. Я же говорю про широкий спектр нарушений.
А про прочий спектр — берут меня сомнения.
N>>>, предсказать положение нарушителя на время AVK>>Да, решение линейного уровнения это мегасложно. N>С каких это пор все стали ездить по прямым с постоянной скоростью?
На интервале между измерением скорости и отработкой камеры — чуть более чем все.
N> Но я и не говорю, что это такой вычислительно сложный этап, а лишь перечислил все действия, которые должны выполниться с максимальной скоростью.
Максимальности не видно. Максимально нужно только снять картинку и прочие параметры и скинуть в устройство хранения.
N> Не надо вырывать из контекста — некрасиво.
Я не вырываю.
AVK>>А они и уезжают по факту. В реальном времени распознавать не нужно. N>Надо успеть сделать снимок его номера.
В некоторый дивайсах просто стоит видеокамера, они снимает все. И сделать снимок — это несколько не то, что ты перед этим расписал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1260 on Windows 7 6.1.7600.0>>
Больше i_pipe тут не встречается, так что я сказать пока что не могу.
Но между этим двумя есть такое
151 if (security_inode_alloc(inode))
152 goto out;
153
154 /* allocate and initialize an i_integrity */
155 if (ima_inode_alloc(inode))
156 goto out_free_security;
Может, кто-то из них ставит ->i_pipe ?
KV>Однако, побродив по коду в окрестностях уявзимости, я так и не понял, откуда у разработчика была уверенность в том, что передаваемые в функцию указатели не могут быть NULLевыми
Минуту. Указатели inode или же inode->i_pipe ?
За первое ручаться никогда нельзя. Да и не надо.
За второе при правильной постановке можно ручаться.
>либо освободиться до захвата функцией мьютекса.
Это я по-прежнему не пойму. Впрочем. я не знаю Юникса. В Win32 можно мютекс создать и захватить сразу атомарно — из 3 кольца, конечно. А в ядре, я так полагаю, спин-блокировка. Как тут — не знаю. Впрочем, не это главное. Меня более интересует, где и когда присвоили что-то i_pipe.
>Чел, нашедший уязвимость (некий Earl Crew), кстати, похоже — тоже.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>>>Я неправльно вопрос задал. На было так: Где использование cuda необходимо? CC>>>Там, где надо ускорить вычисления, которые могут быть ускорены на CUDA G>>Ну и парочку примеров где это необходимо, так что без cuda-ускорения не будут выполняться задачи. CC>Пример из жизни: пришел биг босс и сказал что заказчик хочет и платит. CC>Всё. Все остальные рассуждалки "да каму ета наааада" в сад.
Ну тогда вообще что угодно сделать можно. Даже ОС написать.
Но это совершенно не связано с быстродействием.
Здравствуйте, gandjustas, Вы писали:
G>Но это совершенно не связано с быстродействием.
Связано напрямую.
Надо посчитать большой объем аналитики за ограниченное время. Грубо говоря за ночь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
N>>Да, нет никакого номера нарушителя на видео — надо сначала навести камеру на него. G>Да не рассказывай, камера довольно большой угол имеет. Инчаче никак не наведешь, ибо вектор направления движения автомобиля обычно неизвестен.
Я рассказываю как раз о том, что знаю и что сам разрабатывал. Если угол обзора будет широким (фокусное расстояние небольшое), то качество распознавания номера будет очень низкое.
А положение автомобиля предсказывают на основании вида нарушения, характера предыдущего движения автомобиля + другие эвристики. Сейчас такая система проходит испытания в нашем городе.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
N>>>Да, нет никакого номера нарушителя на видео — надо сначала навести камеру на него. G>>Да не рассказывай, камера довольно большой угол имеет. Инчаче никак не наведешь, ибо вектор направления движения автомобиля обычно неизвестен.
N>Я рассказываю как раз о том, что знаю и что сам разрабатывал. Если угол обзора будет широким (фокусное расстояние небольшое), то качество распознавания номера будет очень низкое.
Да ну? Сам лично видел как статически висячая камера с углом в 45 градусов распозновала 99% номеров.
Учитывая что 100% снимков должны смотреть люди, то исключить все ошибки вполне возможно.
N>А положение автомобиля предсказывают на основании вида нарушения, характера предыдущего движения автомобиля + другие эвристики. Сейчас такая система проходит испытания в нашем городе.
А у нас тупо камер везде понавешали.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Радар на аппаратном уровне выдает конкретное число. N>>Радар приемлем только для определения скорости. Я же говорю про широкий спектр нарушений. AVK>А про прочий спектр — берут меня сомнения.
Многих берут, сейчас проводятся испытания. В случае их успеха, возможно, появится всё на улицах.
N>>С каких это пор все стали ездить по прямым с постоянной скоростью? AVK>На интервале между измерением скорости и отработкой камеры — чуть более чем все.
Нарушители чаще ездят с ускорением (особенно на запрещённых поворотах), причём по каждой из координат x и y ускорение разное.
N>> Но я и не говорю, что это такой вычислительно сложный этап, а лишь перечислил все действия, которые должны выполниться с максимальной скоростью. AVK>Максимальности не видно. Максимально нужно только снять картинку и прочие параметры и скинуть в устройство хранения.
Надо сначала обнаружить нарушение, навести камеру, а только потом снять картинку.
AVK>>>А они и уезжают по факту. В реальном времени распознавать не нужно. N>>Надо успеть сделать снимок его номера. AVK>В некоторый дивайсах просто стоит видеокамера, они снимает все. И сделать снимок — это несколько не то, что ты перед этим расписал.
Я и не описываю эти "некоторые девайсы". Есть конторы, которые предлагают решение, например для определения пересечения сплошной: ставится камера, наводится на сплошную и при обнаружении любого номера автоматически записывает его в нарушители. Всё просто и надёжно, но с "маленьким" недостатком: для охвата более-менее протяжённой территории необходимо ставить туеву хучу камер. Возможно ты видел на перекрёстках целые "ежи" из камер — это оно и есть. ГИБДД'шникам такой вариант не очень нравится. Я описываю совсем другой вариант: сложней по структуре, но требующий гораздо меньше оборудования.
Здравствуйте, gandjustas, Вы писали:
N>>Я рассказываю как раз о том, что знаю и что сам разрабатывал. Если угол обзора будет широким (фокусное расстояние небольшое), то качество распознавания номера будет очень низкое. G>Да ну? Сам лично видел как статически висячая камера с углом в 45 градусов распозновала 99% номеров. G>Учитывая что 100% снимков должны смотреть люди, то исключить все ошибки вполне возможно.
Если камера мегапиксельная, то очень может быть. В некоторых продаваемых библиотеках по распознаванию номеров есть возможность выделять зоны анализа, дабы не просматривать весь кадр. Но на расстоянии 100 метров вероятность распознавания номера будет всё равно очень мала. Поворотная камера с быстрым зумом тут выигрывает.
N>>А положение автомобиля предсказывают на основании вида нарушения, характера предыдущего движения автомобиля + другие эвристики. Сейчас такая система проходит испытания в нашем городе. G>А у нас тупо камер везде понавешали.
Подходов к безопасности много. Я описал один из них.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Это всё домыслы. В решении бизнес задач царит принцип эффективности. PD>Эффективности чего ? Работы программиста или конечного кода ?
Эффективность затрат, необходимых для получения конечного результата.
>>Писать сегодня код на C дорого PD>Да >>медленно PD>Да >>не эффективно PD>С точки зрения времени работы программиста — да. С точки зрения эффективности рабочей программы — наоборот.
Эффективной можно спокойно считать программу, эффективность которой приемлема. К тому же программа чаще всего — это комплекс алгоритмов. Бессмысленно, например, выжимать миллисекунды при построении текста SQL запроса, если потом сам запрос выполняется десятки минут. Такие оптимизации вредны, они усложняют приложение не давая ничего в замен. В данном случае гораздо полезней поработать над оптимизацией структуры и алгоритмов обработки данных. Но такие оптимизации не зависят от языка программирования... хотя я не прав — зависят. Зависят от того насколько выразителен и прост в обращении используемый инструмент. A здесь C сливает современным языкам со страшной силой.
>>Тоже самое касается и системных задач, но в них требования к потреблению ресурсов могут оказаться приоритетнее. Там, где в системных задачах ресурсы мало кого интересуют, тоже используются более эффективные инструменты, чем C.
PD>Да. Но только когда ресурсы мало кого интересуют.
До определённого момента они и не должны никого интересовать. Если же приложение слишком прожорливо, то здесь уже никакой C не поможет. Экономия ресурсов в разы и десятки раз никогда не достигалась с помощью низкоуровневых оптимизаций на C. Нужно пересматривать архитектуру и алгоритмы. Если сравнивать эффективное с точки зрения потребления ресурсов приложение, написанное на C и на C#, то на C можно сэкономить проценты, десяток процентов, но не порядки. А вот сложность решения будет в точности наоборот — код на C# будет на порядки проще кода на C при незначительном увеличении потребления ресурсов.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Nuzhny, Вы писали:
G>>Ну я писал такое, и что? N>Не верю. Безопасности нет в самой платформе, следовательно нет и в твоём приложении.
Это неверно. Если приложение изначально проектируется как безопасное, то его (я подчеркиваю: ЕГО — приложения) безопасность не будет зависеть от безопасности окружающей его платформы.
Здравствуйте, Pavel Dvorkin, Вы писали:
KV>>Намек, думаю понятен...
PD>Не очень. Честно говоря, я просто не понял, что ты хотел сказать. Если ты не зная .NET, сумел это сделать через 15 мин, то значит, это не так уж сложно.
Я хотел сказать, что даже на железе, которое сейчас считается не самым производительным, чтобы занять все доступные ресурсы памяти и проца, нужно постараться и потратить на это некоторое время.
PD>Ну а второе — что , не мог занять проц на 60% без написания своей программы ?
"Это не наш метод" (с)
KV>>Они просто пугаются, т.к. думают что ты работаешь на оборонку и пишешь софт для ядерных боеголовок PD>Упаси боже. Я человек совершенно мирный и занимаюсь совсем прозаической деятельностью. Просто те задачи, которыми я занимаюсь, едят процессорное время безбожным образом.
Насколько я понимаю, сами задачи — мне увидеть не судьба, поэтому остается лишь поверить на слово
PD>>>Сможешь , наверное, только вот иногда тебе придется на неуправляемый код переходить, а иногда и вообще не получится. Но ты мол, не огорчайся, если не получится, то это значит, что тебе такое и не надо, мы тебе другое предложим... И работать это будет быстрее. Ах, у тебя все же медленнее получается... Ну значит , ты неправильно меряешь, не на тех тестах , и вообще имей в виду — в светлом будущем наш код намного лучше будет. Светлое будущее обещать они очень любят.
KV>>А можно взглянуть на реальную (не надуманную задачу) где быстродействие, достижимое на управляемых платформах является неприемлемым, из твоей практики? А десяток таких задач? PD>Ничего себе заявление! Я, значит, должен был десяток задач решить на .NET, чтобы удовлетворить твое любопытство ?
Ну я же лазил пол-дня по git-у в поисках интересующих тебя определений
полученных производительности сравним с достаточными требованиями для данной задачи
PD>Э нет, не пойдет. Безопасность — дело серьезное, даже если специалист по ней не программист вообще.
Да я не безопасность имел ввиду. Ок, забыли
KV>>Да, меня это тоже удручает. К сожалению, в .NET еще встречаются задачи, когда полностью абстрагироваться от окружающей тебя ОС не получится при всем желании PD>И никогда не перестанут встречаться.
Это почему?
KV>>Тебя это просто перестанет беспокоить с переходом на .NET А если это сейчас тебя и так не беспокоит, то и переходить на .NET, пожалуй не стоит. PD>Так я это и утверждаю. Ты же меня на дискуссию вызвал, ну вот я и отбиваюсь
Дык я ж не предлагал переходить на .NET. Я говорил о добровольном ограничении свободы (например, в рамках того С++)
>>про основу твоей уверенности в том, что индексы не выходят за предел
PD>А вообще — не надо. Он и так выходить не должен.
Во-во. А потом указатели на пайпы в ядрах обнуляться начинают
PD>И вообще должен сказать, что до появления .NET этому вопросу (выход индекса), как бы это помягче сказать и никого не обидеть... не уделялось слишком большого внимания при обсуждении проблем программирования.
Ну конечно. А то, что перечислено хотя бы здесь — понапридумывали после выхода .NET?
PD>Да и вообще, что такое выход индекса ? Это логическая ошибка, это неверное вычисление функции (в широком смысле слова). Одна из многих возможных логических ошибок. Что в формуле для корней вместо минуса плюс поставить, что в массиве из n обратиться к n-му элементу.
Это одна из возможных ошибок, позволяющих изменить поток управления текущего процесса. Любая уязвимость — одна из возможных логических ошибок, разница лишь в уровне абстракции, на котором она совершается
>>и про то, как именно ты определяешь попытки использования нулевого указателя?
PD>Запусти
PD> char* p = NULL; PD> *p = 0;
PD>и все сам увидишь.
Попробовал: собралось, запустилось, крэшнулось на виндовом необработанном исключении доступа к нулевому адресу.
Потом попробовал переписать это в лоб на C#: не собралось с ошибкой "Указатели и буферы фиксированного размера можно использовать только в небезопасном контексте". Ок, добавим небозопасный контекст:
unsafe
{
char* p;
*p = 0;
}
— не собралось с ошибкой "Постоянное значение "0" не может быть преобразовано в "char"", ok, не вопрос, переделаем так:
unsafe
{
char* p;
*p = '0';
}
— не собралось с ошибкой "Использование локальной переменной "p", которой не присвоено значение", ok, я упорный по натуре, присвоим p null явным образом:
unsafe
{
char* p = null;
*p = '0';
}
ну слава богу... собралось, запустилось и упало с CLR'ным NullReferenceException.
Feel the difference, что называется.
PD>А я и не говорю, что ты утверждал. Я просто отмечаю, что те ошибки, от которых меня намерены защищать, есть 1-2% моих ошибок. А остальные 98% никакими тулзами и средствами не контролируются в принципе. И за эти 1-2% платить цену, о которой я говорил — не стоит, да и шум вокруг них поднимать такой уж нечего.
Наличие цифры 1-2% говорит о твоей осведомленности по части общего числа всех ошибок в твоем коде, включая необнаруженные, вообще-то
PD>>>Тот код, который ты показал, при определенных условиях вполне безупречен.
PD>А меня логические ошибки беспокоят, а безопасность — абсолютно нет. Ну какая может быть безопасность в задаче перемножения матриц, например ? Индексы пусть где попало не бегают, NULL вместо матриц не используй и не будет никаких угроз
Чисто в перемножении, действительно что-то придумать тяжело. Но оно же где-то используется? А тогда, навскидку, уязвимости арифметического переполнения еще никто не отменял Если на данные из результирующей матрицы завязана какая-либо логика, то только в путь. Просто как пример.
KV>>Неужели оно того стоит?
PD>Стоит.
полученных производительности сравним с достаточными требованиями для данной задачи
нужно читать как
Не надо их решать. Просто озвучь условия и решим ее каждый на своем языке. Полученные замеры производительности сравним с достаточными требованиями для данной задачи
Здравствуйте, IT, Вы писали:
PD>>Эффективности чего ? Работы программиста или конечного кода ?
IT>Эффективность затрат, необходимых для получения конечного результата.
Не уходи от ответа. Что, если затраты не столь существенны, а качество продукта на первом месте ?
IT>Эффективной можно спокойно считать программу, эффективность которой приемлема.
Это все слова. От меня требуют — как можно быстрее. Все остальное мне простят. И если тактовая будет 20 GHZ, то от меня все равно будет требовать то же. Иными словами, выжать из железа все, что можно. Ты допускаешь, что такая постановка вопроса возможна ?
>К тому же программа чаще всего — это комплекс алгоритмов. Бессмысленно, например, выжимать миллисекунды при построении текста SQL запроса, если потом сам запрос выполняется десятки минут.
Если запрос будет выполняться десятки минут, со мной перестанут разговаривать. А вот если запро выполняется 100 мсек, а остальное — 5 мсек, а я сделаю 4 — мне за это скажут спасибо.
>Такие оптимизации вредны, они усложняют приложение не давая ничего в замен. В данном случае гораздо полезней поработать над оптимизацией структуры и алгоритмов обработки данных.
В теории совершенно верно, а практически не всегда возможна. Например, обработка производится 3dparty lib, свою написать — годы понадобятся, да и будет ли лучше... а вот оптимизировать то, что от меня зависит, я могу. Даже если это 1-2%.
>Но такие оптимизации не зависят от языка программирования... хотя я не прав — зависят. Зависят от того насколько выразителен и прост в обращении используемый инструмент.
Не согласен. Они определяются тем, насколько инструмент близок по своему духу машинному языку. Чем ближе — тем больше у меня возможностей, не переходя или почти не переходя на асм, написать наилушим образом. Что же касается выразительных и простых конструкций иных языков, то эта простотоа и ясность, вполне приемлемые в иных случаях, здесь проигрывают. По той простой причине, что высокоуровненвые конструкции неизбежно компилируются неким стандартным образом, без учета конкретной специфики. Ее полностью можно учесть в идеале на асме, а в реальности — на очень низкоуровневом ЯВУ.
>A здесь C сливает современным языкам со страшной силой.
С точностью до наоборот.
PD>>Да. Но только когда ресурсы мало кого интересуют.
IT>До определённого момента они и не должны никого интересовать. Если же приложение слишком прожорливо, то здесь уже никакой C не поможет.
А что поможет ? Он же все-таки дает самый быстрый код. На асм перейти — возможно, будет быстрее, но не очень. Может, иногда и стоит.
>Экономия ресурсов в разы и десятки раз никогда не достигалась с помощью низкоуровневых оптимизаций на C. Нужно пересматривать архитектуру и алгоритмы.
Задачи разные бывают. И алгоритмы тоже. Пересмотри, например, алгоритм сложения матриц (только без разговоров о многопоточности, от этого ничего не изменится — мне проще разным потокам разные матрицы дать, и все дела). Что не делай, а складывать придется, и от двойного цикла никуда не денешься. И когда матрицы так примерно 5000 * 5000, то весело будет, я тебе обещаю. А заказчик говорит — давай-давай, матриц много, быстрее, быстрее, не успеваешь.
P.S. Это весьма похоже на одну мою работу. Только вместо сложения матриц там кое-что иное, но тоже матрицы и циклы.
>Если сравнивать эффективное с точки зрения потребления ресурсов приложение, написанное на C и на C#, то на C можно сэкономить проценты, десяток процентов, но не порядки.
Если не трудно, расскажи, как можно оптимизировать эти матричные сложения на порядок по скорости. Я тебе благодарен буду до предела.
>А вот сложность решения будет в точности наоборот — код на C# будет на порядки проще кода на C при незначительном увеличении потребления ресурсов.
Исходный код — будет, не спорю, а эффективность — наоборот. Тебе про чтение последней строки из файла напомнить ? . Кстати. если уж ты так ратуешь за использование эффективных алгоритмов, почему же ты там пошел на чтение файла целиком, если вполне достаточно прочитать маленький кусочек с конца, да даже и не читать (проблемы будут), а просто открытьт мэппинг — и задним ходом! Вот тебе и пример насчет эффективного алгоритма. Для того, чтобы его сделать, надо как можно пониже уровнем спуститься. Не оперировать абстракциями как-то реализованными, а использовать те средста, которые требуют минимальных действий. А для этого надо работать не с высокоуровневыми, а наоборот, низкоуровневыми средствами. Иными словами, Fine Tuning.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Это неверно. Если приложение изначально проектируется как безопасное, то его (я подчеркиваю: ЕГО — приложения) безопасность не будет зависеть от безопасности окружающей его платформы.
Согласен, получится безопасный колосс на глиняных ногах. Но разве это приемлемое решение? Тут скорее неправильный выбор платформы (если такой выбор существовал).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Исходный код — будет, не спорю, а эффективность — наоборот. Тебе про чтение последней строки из файла напомнить ? .
Напомни мне, плиз!
Re[5]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, drol, Вы писали:
LVV>>Я, например, не могу... D>Развивайте воображение Ну там в LEGO играйте, например LVV>>Во всех конторах, где я работал, крах... считался ЧП. D>Такие конторы значится А вот бортовое военное ПО специально проектируется исходя из требований мгновенного рестарта в случае отказа. Известнейший эпизод — F-16 и высота 0 футов над уровнем моря Ну деление на ноль, ну и что Рестарт, и через секунду всё опять работает. D>Более того, не редкость вообще построение системы на схеме с постоянным рестартом, например, у спутникового ПО. Менеджер памяти в таких штуках, например, умеет её только выделять. Когда же память заканчивается, то приложение сохраняет своё состояние в постоянную память, и рестартуется.
Я писал бортовую ось, поэтому непосредственно знаю, сколько времени уделяется надежности системы. Достаточно сказать, что система с остояла из 4 эвм, один рабочий, два в горячем резерве и один — в холодном...
Но это как раз и говорит о том, что крах системы — это ЧП. LVV>>А в производстве ИМХО НЕЛЬЗЯ НИКОГДА! D>Нельзя только в очень узком сегменте, например, в последней линии защиты исполнительных механизмов. Но там кода с гулькин нос, и его вполне реально сделать надёжным за разумные средства.
Ну, далеко ходить не будем, возьмем систему продажи билетов... Крах системы — ЧП. Хотя восстанавливается, да... Но лучше — без крахов...
Поэтому тут компромисс между эффективностью и надежностью должен быть... ИМХО это очевидно...
Сначала программа должна работать, а потом уж работать быстро...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Павлу Дворкину: о понимании того что делаешь и просты
Приветствую, LaptevVV, вы писали:
LVV> S>А вот здесь уже спорно... Надежность безусловно важна, но если программеры-профессионалы, то надежность будет и так. LVV> Надежность "и так" — не будет! Если этим специально не заниматься в процессе разработки...
А кто говорил, что заниматься никто не будет?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Эффективности чего ? Работы программиста или конечного кода ? IT>>Эффективность затрат, необходимых для получения конечного результата. PD>Не уходи от ответа. Что, если затраты не столь существенны, а качество продукта на первом месте ?
Я никуда не ухожу. Меня интересует прежде всего эффективность всего решения. Если к системе предъявляются серьёзные нефункциональные требования и заказчик за это готов платить, то он это получит, не переживай.
IT>>Эффективной можно спокойно считать программу, эффективность которой приемлема.
PD>Это все слова. От меня требуют — как можно быстрее. Все остальное мне простят. И если тактовая будет 20 GHZ, то от меня все равно будет требовать то же. Иными словами, выжать из железа все, что можно. Ты допускаешь, что такая постановка вопроса возможна ?
Конечно, возможна, я это вполне допускаю. Но как я уже сказал такое встречается довольно редко. Ты же пытаешься распространить свой крайний случай на всё программирование в мире.
>>К тому же программа чаще всего — это комплекс алгоритмов. Бессмысленно, например, выжимать миллисекунды при построении текста SQL запроса, если потом сам запрос выполняется десятки минут.
PD>Если запрос будет выполняться десятки минут, со мной перестанут разговаривать. А вот если запро выполняется 100 мсек, а остальное — 5 мсек, а я сделаю 4 — мне за это скажут спасибо.
А при чём здесь ты? Твои задачи — это капля в море и почему на эту каплю должно равняться всё море.
>>Такие оптимизации вредны, они усложняют приложение не давая ничего в замен. В данном случае гораздо полезней поработать над оптимизацией структуры и алгоритмов обработки данных.
PD>В теории совершенно верно, а практически не всегда возможна. Например, обработка производится 3dparty lib, свою написать — годы понадобятся, да и будет ли лучше... а вот оптимизировать то, что от меня зависит, я могу. Даже если это 1-2%.
Да сколько угодно. Только то, что ты оптимизируешь сегодня под имеющееся у тебя железо, не факт что будет работать быстрее на завтрашнем.
>>Но такие оптимизации не зависят от языка программирования... хотя я не прав — зависят. Зависят от того насколько выразителен и прост в обращении используемый инструмент.
PD>Не согласен. Они определяются тем, насколько инструмент близок по своему духу машинному языку. Чем ближе — тем больше у меня возможностей, не переходя или почти не переходя на асм, написать наилушим образом. Что же касается выразительных и простых конструкций иных языков, то эта простотоа и ясность, вполне приемлемые в иных случаях, здесь проигрывают. По той простой причине, что высокоуровненвые конструкции неизбежно компилируются неким стандартным образом, без учета конкретной специфики. Ее полностью можно учесть в идеале на асме, а в реальности — на очень низкоуровневом ЯВУ.
Под оптимизацию стандартных высокоуровневых конструкций, если ты не знал, затачиваются внутренности процессоров. Ещё год назад ты говорил о 5%, сегодня уже об 1-2%, а что будет ещё через пару лет?
>>A здесь C сливает современным языкам со страшной силой.
PD>С точностью до наоборот.
А ты сам-то пробовал писать на чём-то другом кроме C? Или это всё теории?
IT>>До определённого момента они и не должны никого интересовать. Если же приложение слишком прожорливо, то здесь уже никакой C не поможет.
PD>А что поможет ?
Поможет пересмотр архитектуры.
PD>Задачи разные бывают.
Это правда, только понимаешь ты это очень однобоко. Складывается впечатление, что они только у тебя разные бывают, а у остальных в точности такие как у тебя и другими быть не могут.
>>Если сравнивать эффективное с точки зрения потребления ресурсов приложение, написанное на C и на C#, то на C можно сэкономить проценты, десяток процентов, но не порядки.
PD>Если не трудно, расскажи, как можно оптимизировать эти матричные сложения на порядок по скорости. Я тебе благодарен буду до предела.
Купи проц с 16-ю ядрами и сделай алгоритм многопоточным.
>>А вот сложность решения будет в точности наоборот — код на C# будет на порядки проще кода на C при незначительном увеличении потребления ресурсов.
PD>Исходный код — будет, не спорю, а эффективность — наоборот. Тебе про чтение последней строки из файла напомнить ? .
Напомни. А тебя тем временем ещё больше огорчу. С появлением Linq сегодня этот код у меня выглядел бы вот так:
File.ReadAllLines("filename").Last();
Свой оптимизированный вариант можешь не приводить, мне он не интересен.
PD>Кстати. если уж ты так ратуешь за использование эффективных алгоритмов, почему же ты там пошел на чтение файла целиком, если вполне достаточно прочитать маленький кусочек с конца, да даже и не читать (проблемы будут), а просто открытьт мэппинг — и задним ходом! Вот тебе и пример насчет эффективного алгоритма.
Потому что для решаемой задачи, а именно для файла размером в 120 байт, моё решение будет более чем приемлемым.
PD>Для того, чтобы его сделать, надо как можно пониже уровнем спуститься. Не оперировать абстракциями как-то реализованными, а использовать те средста, которые требуют минимальных действий. А для этого надо работать не с высокоуровневыми, а наоборот, низкоуровневыми средствами. Иными словами, Fine Tuning.
Не надо никуда опускаться. Данная задачка не стоит выеденного яйца Пушкина ни по временным затратам, ни по производительности. Таких задачек в день я решаю мильён. Если оптимизировать каждую, то жизни не хватит.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Nuzhny, Вы писали:
N>Для разнообразия предлагаю тебе, gandjustas, написать безопасное приложение, которое будет работать на видеокарте с CUDA SDK.
Не совсем понял, разве нет враперра для CUDA SDK на дотнете?
Здравствуйте, olegkr, Вы писали:
N>>Для разнообразия предлагаю тебе, gandjustas, написать безопасное приложение, которое будет работать на видеокарте с CUDA SDK. O>Не совсем понял, разве нет враперра для CUDA SDK на дотнете?
В нём мало смысла просто. На карте-то выполняется небезопасный код.
Здравствуйте, Cyberax, Вы писали:
N>>>Для разнообразия предлагаю тебе, gandjustas, написать безопасное приложение, которое будет работать на видеокарте с CUDA SDK. O>>Не совсем понял, разве нет враперра для CUDA SDK на дотнете? C>В нём мало смысла просто. На карте-то выполняется небезопасный код.
Да и тормозной он. По крайней мере по состоянию на весну этого года.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Это неверно. Если приложение изначально проектируется как безопасное, то его (я подчеркиваю: ЕГО — приложения) безопасность не будет зависеть от безопасности окружающей его платформы.
N>Согласен, получится безопасный колосс на глиняных ногах. Но разве это приемлемое решение? Тут скорее неправильный выбор платформы (если такой выбор существовал).
Если информация, безопасность которой мы обеспечиваем, находится внутри этого колосса, то почему бы нет? В случае успешной атаки на платформу в нашем приложении будет реализована лишь угроза отказа в обслуживании, а остальные пять останутся девственно-нереализованными. Не так уж и плохо, хотя конечно не идеал и зависит от цены в которую нам обойдется недоступность инфы в конкретный промежуток времени.
Здравствуйте, drol, Вы писали:
LVV>>Я писал бортовую ось, поэтому непосредственно знаю, сколько времени уделяется надежности системы. Достаточно сказать, что система с остояла из 4 эвм, один рабочий, два в горячем резерве и один — в холодном... D>И совершенно недостаточно. На базе четырёх железок возможно целое стадо архитектур с разной степенью надёжности. Например, на "Ариан-5" у IRS тоже имелось резервирование, но так как все коробочки были идентичными, и софт был один и тот же, то и баг везде был один и тот же. В результате резерв подох аналогично основной системе, и весь космодром завалило обломками девайса
Да правильно все. В том — то и дело, что предполагалось разные оси ставитть. Да что-то не сложилось там у руководства. Видитмо не смогли доказать разработку трех одинаковых проектов в разных местах. LVV>>Но это как раз и говорит о том, что крах системы — это ЧП. D>Вы опять путаете. Речь не о FCS самолёта, или там IRS ракеты — очевидно что их отказ фатален. Речь о компонентах типа рисовалки картографического модуля, рестарт которых ничего страшного не представляет. И нормальные люди такие вещи и не резервируют, и 100% надёжности в требованиях не ставят, бо смысла нет.
В ваших рассуждениях только один минус — не видать что-то рисовалок, рестартующих после краха...
А мне, как пользователю, обидно терять почти нарисованный рисунок... Если такое произойдет несколько раз, я пошлю и рисовалку, и фирму-разработчика далеко и надолго... LVV>>Ну, далеко ходить не будем, возьмем систему продажи билетов... Крах системы — ЧП. Хотя восстанавливается, да... Но лучше — без крахов... D>Если консистентность данных сохраняет и рестартует за секунду — в чём проблема ?
И опять же — что-то не видать систем, которые бы падали...
Это ж простая логика — никому не нужна система, которая падает, хотя и восстанавливается быстро... Чисто психологически...
Такое поведение надо специально оговаривать с заказчиком...
...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[8]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, LaptevVV, Вы писали:
LVV>В ваших рассуждениях только один минус — не видать что-то рисовалок, рестартующих после краха...
Ну Вам конечно не видно Вы ведь на F-16, или там Eurofighter'е не летаете
LVV>А мне, как пользователю, обидно терять почти нарисованный рисунок... Если такое произойдет несколько раз, я пошлю и рисовалку, и фирму-разработчика далеко и надолго...
А почему Вы решили, что что-то потеряется ??? Более того, почему Вы решили, что вообще заметите крэш ??? Будет какой-нибудь секундный фриз, например, и всё поедет дальше.
LVV>И опять же — что-то не видать систем, которые бы падали...
Неправда. Я выше приводил примеры и вполне массовых систем. То что Вы не водитель-дальнобойщик — это Ваши проблемы
LVV>Это ж простая логика — никому не нужна система, которая падает, хотя и восстанавливается быстро... Чисто психологически...
Ерунда. Не нужна система которая валится каждую секунду.
LVV>Такое поведение надо специально оговаривать с заказчиком...
Про то и базар. Такие системы имеют специальные требования и специальную архитектуру. Поэтому с ними и нет проблем.
Re[8]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, LaptevVV, Вы писали:
LVV>Это ж простая логика — никому не нужна система, которая падает, хотя и восстанавливается быстро... Чисто психологически...
Ну идеология того же Эрланга именно на этом и построена, притом системы пишут на ней очень надежные.
Re[9]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, LaptevVV, Вы писали:
LVV>>Это ж простая логика — никому не нужна система, которая падает, хотя и восстанавливается быстро... Чисто психологически...
FR>Ну идеология того же Эрланга именно на этом и построена, притом системы пишут на ней очень надежные.
Так и есть, только вот C++ и fail fast имхо не очень дружат (e.g.: ошибка в 1 процессе не рушит весь эмулятор)
Re[10]: Павлу Дворкину: о понимании того что делаешь и прост
Здравствуйте, Курилка, Вы писали:
FR>>Ну идеология того же Эрланга именно на этом и построена, притом системы пишут на ней очень надежные.
К>Так и есть, только вот C++ и fail fast имхо не очень дружат (e.g.: ошибка в 1 процессе не рушит весь эмулятор)
Для C++ тоже вполне реально, та же изоляция в системный процесс например.
Re[11]: Павлу Дворкину: о понимании того что делаешь и прост
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
FR>>>Ну идеология того же Эрланга именно на этом и построена, притом системы пишут на ней очень надежные.
К>>Так и есть, только вот C++ и fail fast имхо не очень дружат (e.g.: ошибка в 1 процессе не рушит весь эмулятор)
FR>Для C++ тоже вполне реально, та же изоляция в системный процесс например.
Реально == используемый постоянно на практике подход?
Плюс — а что ты будешь делать с диагностикой падения программы на плюсах? Это ведь ключевой момент — понять, что же вылетело, ну и сделать какие-то корректирующие действия в результате (пусть даже это будет "отправить стектрейс разработчикам или в лог").
Понятное дело, что на плюсах можно всё нарисовать, но интересней было бы рассмотреть соотношение цена/качество на разных задачах. Хотя тут, я думаю, у участников дискуссии уже есть субъективные оценки этого, и основной сыр-бор из-за расхождений этих оценок, а также из-за перемешивания их (оценок) на разных задачах.
Re[12]: Павлу Дворкину: о понимании того что делаешь и прост
Здравствуйте, Курилка, Вы писали:
FR>>Для C++ тоже вполне реально, та же изоляция в системный процесс например.
К>Реально == используемый постоянно на практике подход?
Нет конечно, но используется хоть и редко.
К>Плюс — а что ты будешь делать с диагностикой падения программы на плюсах? Это ведь ключевой момент — понять, что же вылетело, ну и сделать какие-то корректирующие действия в результате (пусть даже это будет "отправить стектрейс разработчикам или в лог").
Если писать с прицелом на это дело, никаких проблем. И какой еще стектрейс если система спроектирована с ожиданием падения некоторых ее частей, я тут никакой разницы с эрлангом не вижу кроме того что там уже многое делает среда.
К>Понятное дело, что на плюсах можно всё нарисовать, но интересней было бы рассмотреть соотношение цена/качество на разных задачах. Хотя тут, я думаю, у участников дискуссии уже есть субъективные оценки этого, и основной сыр-бор из-за расхождений этих оценок, а также из-за перемешивания их (оценок) на разных задачах.
Зависит от задачи еще.
Re[13]: Павлу Дворкину: о понимании того что делаешь и прост
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
К>>Плюс — а что ты будешь делать с диагностикой падения программы на плюсах? Это ведь ключевой момент — понять, что же вылетело, ну и сделать какие-то корректирующие действия в результате (пусть даже это будет "отправить стектрейс разработчикам или в лог").
FR>Если писать с прицелом на это дело, никаких проблем. И какой еще стектрейс если система спроектирована с ожиданием падения некоторых ее частей, я тут никакой разницы с эрлангом не вижу кроме того что там уже многое делает среда.
Про стектрейс не понял (типа мы на него забиваем, т.к. нафиг не надо?), так и про некоторые части (в Эрланге считается, что упасть может всё, что угодно).
А по-моему как раз в среде и есть разница, т.к. в плюсах ты можешь получить недиагностируемый крэш, тогда как в эрланговом эмуляторе он практически всегда будет содержать информацию о том, что же случилось (хотя иногда даже её бывает недостаточно).
К>>Понятное дело, что на плюсах можно всё нарисовать, но интересней было бы рассмотреть соотношение цена/качество на разных задачах. Хотя тут, я думаю, у участников дискуссии уже есть субъективные оценки этого, и основной сыр-бор из-за расхождений этих оценок, а также из-за перемешивания их (оценок) на разных задачах.
FR>Зависит от задачи еще.
Дак я и пишу про "разные задачи", было бы странно получить на них совершенно одинаковые результаты, поэтому использовать совершенно одинаковые подходы не очень логично.
Re[14]: Павлу Дворкину: о понимании того что делаешь и прост
Здравствуйте, Курилка, Вы писали:
К>Про стектрейс не понял (типа мы на него забиваем, т.к. нафиг не надо?), так и про некоторые части (в Эрланге считается, что упасть может всё, что угодно). К>А по-моему как раз в среде и есть разница, т.к. в плюсах ты можешь получить недиагностируемый крэш, тогда как в эрланговом эмуляторе он практически всегда будет содержать информацию о том, что же случилось (хотя иногда даже её бывает недостаточно).
Просто ты меня не понял. В случае C++ потенциально падучая часть системы запускается как отдельный системный процесс, и нам дела нет до его стека, стек базовой программы он никак порушить не может.
Re[15]: Павлу Дворкину: о понимании того что делаешь и прост
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
К>>Про стектрейс не понял (типа мы на него забиваем, т.к. нафиг не надо?), так и про некоторые части (в Эрланге считается, что упасть может всё, что угодно). К>>А по-моему как раз в среде и есть разница, т.к. в плюсах ты можешь получить недиагностируемый крэш, тогда как в эрланговом эмуляторе он практически всегда будет содержать информацию о том, что же случилось (хотя иногда даже её бывает недостаточно).
FR>Просто ты меня не понял. В случае C++ потенциально падучая часть системы запускается как отдельный системный процесс, и нам дела нет до его стека, стек базовой программы он никак порушить не может.
Есть ощущение, что есть некоторое взаимное недопонимание
Я-то тебе как раз говорил, о том, что вариант с "причинами смерти" (в данном случае в Эрланге), скорее всего, будет выгодней, чем просто "заметание мусора под ковёр". Но, как бычно, абстрактно говорить смысла особого нет, всё определяет задача и её условия.
Re[8]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, LaptevVV, Вы писали:
SC>>Джон Бентли. Жемчужины программирования. 2-е изд. стр. 248 перевода (в пункте 6, вверху):
SC>>"В этой программе, как в любой другой большой системе, есть ошибки. На данный момент их известно 10 штук, они все не слишком серьёзны. В следующем месяце, возможно, будет обнаружено ещё 10 таких же ошибок. Если бы вы могли выбирать между устранением 10 известных на данный момент ошибок или увеличением скорости работы программы в 10 раз, что бы вы выбрали?" LVV>Устранение ошибок.
См выделенное мной выше. И тратить на это время , м.б. не стоит, потому что
Если скорость увеличить в 10 раз — это позволит сэкономить кучу денег.
Если ее сэкономить — можно нанять людей, которые будут эти ошибки исправлять
А может быть, нанять людей, которые пересмотрят вообще всю структуру , так что этих ошибок там просто не сможет оказаться.
LVV>Если скорость заказчика устраивает — то и нефиг ее повышать.
Заказчик и не догадывается, что это могло бы в 10 раз быстрее работать. Откуда ему знать ? Хорошо, если аналогичный продукт есть, а если нет. AuthoCad — он расчеты проводит максимально быстро ? Или могло бы быть раз в 5 быстрее ? Поди скажи... А за ПО с теми же возможностями, но в 5 раз быстрее работающим, озолотили бы.
LVV>И даже если не устраивает — сначала ошибки убрать, а потом скорость повышать...
Например, неправильное форматирование строки в выходном документе — это, конечно, важнее, чем повысить скорость его генерации в 10 раз
LVV>>В ваших рассуждениях только один минус — не видать что-то рисовалок, рестартующих после краха... PD>А Word восстанавливает документ после краха. Open Office тоже. И более или менее успешно. FireFox после краха восстанавливает все табы.
Это как раз из той оперы, что на безрыбье и рак — рыба... По мне так лучше бы он вообще не падал... Ну а раз упал, тогда чтоб не было потерь...
В общем, понятно, что требования и к надежности, и к эффективности определяются при разговоре с заказчиком.
При этом, очевидно, заявления типа"чтоб работало максимально быстро" — требованиями не являются...
И еще одно соображение по эффективность...
Сначала занимаются скоростью. Памятью занимаются только тогда, когда ее не хватает...
Но и скорость может иметь обратный психологиченский эффект (об этом писали), когда слишком быстрый ответ системы у простого пользователя вызывает эффект комплекса неполноценности из-за разница в скорости коммуникаций...
Поэтому резюме ИМХО.
Твой приоритет эффективности определен не твоими вкусами и предпочтениями, а постоянными требованиями заказчика или характером задачи....Если б не требовали, то и упираться б в эффективность слишком не стал бы... А вот ошибки б — исправлял бы всегда...
Если б писал лично для себя...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, kochetkov.vladimir, Вы писали:
PD>>Нет, все как раз наоборот. У меня проблемы со стиркой белья, вода извне в машину не течет, а изнутри вытекает на пол, ротор не крутится и т.п, а тут ко мне приходят и говорят : "Мы знаем, что вам нужно, и именно сейчас! Мы решим все ваши проблемы. Самая лучшая кофеварка от фирмы Идиотекс!!! Только у нас!"
KV>А ты теперь поставь себя на их место: они к тебе приходят с классной кофеваркой и видят как чел варит кофе в стиральной машине...
Самое печальное, что, однако, очень часто случается в IT (тут я ни на кого пальцем не показываю), это когда человек в стиральной машине варит кофе, но при этом твердо убежден, что он стирает белье... В этом случае предложение воспользоваться кофеваркой просто в принципе не может найти понимания.
IT>Вообще-то бысрее-ещё-быстрее — это и есть нефункциональные требования. Ну да ладно.
Ну-ну... Не сталкивался ты с такими задачами...
PD>>Покажи мне хоть одно место, где я предлагал изничтожить, к примеру, C#. Не найдешь.
IT>Трудно найти хоть одно место, где ты вообще говоришь о C#. Похоже кроме C ты и знать ничего не желаешь. В этом проблема, особенно учитывая, что ты преподаватель.
Неужели ? А мне кажется, что хотя бы одно место ты бы смог без труда найти. Именно то место, где ты так успешно читал строку из файла и где я тебе показал, что из этого получится. Там именно о С# речь и идет.
Ну а если этого мало, то учись пользоваться поиском
407 результатов. Не все, конечно, по существу. И уж конечно, не об особеннстях языка. Впрочем , об особенностях языка ты моих сообщений немного и по С++ найдешь — не люблю я эти дискуссии.
PD>>А вот что ты предлагал делать с теми, кто на С++ программирует, я не забыл. Напомнить ?
IT>Изолировать от общества?
Нет, там пожестче было.
>Было дело. В следующий раз специально для тебя буду ставить смайлики, чтобы ты не принимал всё так близко к сердцу.
Не поможет. На определенном уровне никаким смайликом не извинишься.
PD>>Так кто из нас терпимее к чужим мнениям ?
IT>
IT>>>А ты сам-то пробовал писать на чём-то другом кроме C? Или это всё теории? PD>>C#, Java, Fortran, PL/1, VB,, Asm, ну и кое-что по мелочи.
IT>И как, получалось?
Представь себе, да. Только все время хотелось поскореее закончить (Fortran и PL/1 исключаю, я с ним работал до С)
IT>Архитектуру можно пересмотреть всегда. Вопрос упирается лишь в целесообразность.
Пересмотри архитектуру сложения матриц, я тебе уже несколько раз предложил это сделать
PD>>Многопоточность тут не поможет, я уже объяснил почему, идет пакетная обработка, так что все равно — одну матрицу разбивать или несколько обрабатывать. А вот насчет 16 ядер — не лукавь. Я тебя спросил — как можно оптимизировать. А ты мне в ответ — купи более мощное железо. Почему бы в таком случае не посоветовать — купи 16 компьютеров ?
IT>Купи 16 компьютеров.
И 16 дополнительных лицензий на 3dparty софт на каждый компьютер, при том, что каждая лицензия в несколько раз дороже компьютера.. Замечательные советы ты даешь. Успехов в их применении!
PD>>Мой вариант был тогда еще приведен, и в нем ничего не меняется. А вот в твоем время замерь. Без LinQ ты проиграл в 33 раза
IT>Меня это не волнует. Где надо я выиграю, а где не надо у меня приоритеты совсем другие.
Тебя не волнует — твое дело, а других — тоже ? Зачем же ты такой совет даешь другим — а вдруг их это волнует ?
IT>Это решение и для файлов побольше работает не плохо. Но самое забавное, что похожие реальные решения, а не высосанные из пальца, и на больших файлах работают приемлемо. В жизни мне вот никогда не надо было читать последнюю строчку из файла.
Так не моя же задача. Ее кто-то там предложил, значит, ему и нужно. А ты свой совет дал.
>А весь файл раскладывать на строки приходится периодически.
Ну я же тебе показал, что твое приемлемое решение в 33 раза медленнеее возможного. Но тебе это все равно. Вот в итоге все и работает в N раз медленнее, чем могло бы.
Ну а если говорить о разложении файла на строчки — зачем ? Он и так разложен, своей структурой. Остается только отмэппить его в память, сделать массив указателей на строчки, и все. Ни один байт исходного текста ни копировать, ни двигать не надо. Вообще не надо. Ничего.
Здравствуйте, AndrewVK, Вы писали:
PD>>Например, неправильное форматирование строки в выходном документе — это, конечно, важнее, чем повысить скорость его генерации в 10 раз
AVK>Безусловно. И улыбки тут не уместны, чаще всего дело обстоит именно так.
М-да. Похоже, если ты это говоришь серьезно, это означает только одно. Мир программирования разошелся на разные квартиры уже настолько, что представителям разных кваритр не легче понять друг друга чем алеуту папуаса.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>М-да. Похоже, если ты это говоришь серьезно, это означает только одно. Мир программирования разошелся на разные квартиры уже настолько, что представителям разных кваритр не легче понять друг друга чем алеуту папуаса.
AVK>Я говорю это серьезно. И, Павел, тебе об этом давно говорят — твои задачи весьма узкие, не стоит обобщать на всех.
Да и не обобщаю я. Я просто говорю — бывает и иначе.
Ну а насчет узких и широких задач — тут надо статистику приводить.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Вообще-то бысрее-ещё-быстрее — это и есть нефункциональные требования. Ну да ладно. PD>Ну-ну... Не сталкивался ты с такими задачами...
Откуда тебе знать с какими задачами я сталкивался? Или у тебя начинает появлятся синдром первого парня на деревне, и ты думаешь, что ты один занимаешься чем-то уникальным и высокотехнологичным?
PD>>>А вот что ты предлагал делать с теми, кто на С++ программирует, я не забыл. Напомнить ? IT>>Изолировать от общества? PD>Нет, там пожестче было.
Изолировать-изолировать от общества?
>>Было дело. В следующий раз специально для тебя буду ставить смайлики, чтобы ты не принимал всё так близко к сердцу. PD>Не поможет. На определенном уровне никаким смайликом не извинишься.
Да уж.
IT>>И как, получалось? PD>Представь себе, да. Только все время хотелось поскореее закончить (Fortran и PL/1 исключаю, я с ним работал до С)
Жаль, ты не застал программирование на тумблерах, наверняка ты по этому скучал бы больше всего.
IT>>Архитектуру можно пересмотреть всегда. Вопрос упирается лишь в целесообразность. PD>Пересмотри архитектуру сложения матриц, я тебе уже несколько раз предложил это сделать
Пересматривать нужно архитектуру решаемой задачи в целом, а не твоего частного решения. Тебе, кстати, об этом постоянно напоминают, когда ты пытаешься предложить улучшить какой-нибудь код на C. Устранять нужно причину, а не последствия.
IT>>Купи 16 компьютеров. PD>И 16 дополнительных лицензий на 3dparty софт на каждый компьютер, при том, что каждая лицензия в несколько раз дороже компьютера.. Замечательные советы ты даешь. Успехов в их применении!
Тогда купи один компьютер с 16-ю ядрами.
IT>>Это решение и для файлов побольше работает не плохо. Но самое забавное, что похожие реальные решения, а не высосанные из пальца, и на больших файлах работают приемлемо. В жизни мне вот никогда не надо было читать последнюю строчку из файла.
PD>Так не моя же задача. Ее кто-то там предложил, значит, ему и нужно. А ты свой совет дал.
И что плохого в моём совете? То, что я могу свой код даже ночью спросонья без проблем воспроизвести за 10 секунд. Вот ты можешь своё решение воспроизвести за 10 секунд? А я могу.
PD>Ну я же тебе показал, что твое приемлемое решение в 33 раза медленнеее возможного. Но тебе это все равно. Вот в итоге все и работает в N раз медленнее, чем могло бы.
Я тебе в 33-й раз повторяю. Моё решение в большинстве случаев работает со вполне приемлемой скоростью. Если оно будет работать даже на 3 порядка быстрее, то этого всё равно никто не заметит. А насчёт "вот в итоге все и работает" — это твои домыслы. Там где надо мой код работает быстро, очень быстро, ещё быстрее и оптимизациям уделяется достаточно внимания. Но растрачивать свою жизнь на оптимизации всего и вся просто глупо.
PD>Ну а если говорить о разложении файла на строчки — зачем ? Он и так разложен, своей структурой. Остается только отмэппить его в память, сделать массив указателей на строчки, и все. Ни один байт исходного текста ни копировать, ни двигать не надо. Вообще не надо. Ничего.
Ну да, только не забудь переводы строк нулями забить в своём файле.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>>Вообще-то бысрее-ещё-быстрее — это и есть нефункциональные требования. Ну да ладно. PD>>Ну-ну... Не сталкивался ты с такими задачами...
IT>Откуда тебе знать с какими задачами я сталкивался? Или у тебя начинает появлятся синдром первого парня на деревне, и ты думаешь, что ты один занимаешься чем-то уникальным и высокотехнологичным?
Глупо.
PD>>>>А вот что ты предлагал делать с теми, кто на С++ программирует, я не забыл. Напомнить ? IT>>>Изолировать от общества? PD>>Нет, там пожестче было.
IT>Изолировать-изолировать от общества?
IT>А тех, кто на нём пишет при наличии выбора в... хотя нет, психов жалко, они не виноваты, нужны какие-то отдельные учреждения типа концентрационных лагерей по перековке мозгов
IT>>>И как, получалось? PD>>Представь себе, да. Только все время хотелось поскореее закончить (Fortran и PL/1 исключаю, я с ним работал до С)
IT>Жаль, ты не застал программирование на тумблерах, наверняка ты по этому скучал бы больше всего.
М-да. Аргументы просто сверхубедительные.
IT>Пересматривать нужно архитектуру решаемой задачи в целом, а не твоего частного решения.
Еще раз внятно объясняю — задача про сложение матриц есть демо решаемой задачи в целом. Понмаешь, вся задача очень проста. Надо взять 2 матрицы и кое-что с ними сделать. Вот и вся задача. И матрицы такое идут одна за другой с внешнего устройства. И их надо обработать. Обработка немного посложнее, чем сложение, но по сути — тот же двойной цикл. И никакой более общей "задачи в целом" здесь просто нет. Вот и скажи, как мне это оптимизировать.
>Тебе, кстати, об этом постоянно напоминают, когда ты пытаешься предложить улучшить какой-нибудь код на C. Устранять нужно причину, а не последствия.
Вот и скажи, как устранить — на примере этого демо по сложению матриц.
А вообщеи забавно. Ничего по сути не зная о моей задаче, кроме того, что я сказал, ты берешься давать общие советы о том, как их надо оптимизировать. Курам на смех.
IT>>>Купи 16 компьютеров. PD>>И 16 дополнительных лицензий на 3dparty софт на каждый компьютер, при том, что каждая лицензия в несколько раз дороже компьютера.. Замечательные советы ты даешь. Успехов в их применении!
PD>>Так не моя же задача. Ее кто-то там предложил, значит, ему и нужно. А ты свой совет дал.
IT>И что плохого в моём совете? То, что я могу свой код даже ночью спросонья без проблем воспроизвести за 10 секунд. Вот ты можешь своё решение воспроизвести за 10 секунд? А я могу.
Было бы чем гордиться! Пусть качество решения будут каким угодно, зато я могу записать его за 10 сек. А зачем за 10 сек , если качество такое ?
Я — не могу я за 10 сек воспроизвести.
И вообще, проснувшись, я предпочитаю умываться и пить кофе, а не воспроизводить код.
Зато потом работать оно будет не 10 сек, а 0.1 сек.
Быстро хорошо не бывает, сто раз уже сказано.
PD>>Ну я же тебе показал, что твое приемлемое решение в 33 раза медленнеее возможного. Но тебе это все равно. Вот в итоге все и работает в N раз медленнее, чем могло бы.
IT>Я тебе в 33-й раз повторяю. Моё решение в большинстве случаев работает со вполне приемлемой скоростью. Если оно будет работать даже на 3 порядка быстрее, то этого всё равно никто не заметит. А насчёт "вот в итоге все и работает" — это твои домыслы. Там где надо мой код работает быстро, очень быстро, ещё быстрее и оптимизациям уделяется достаточно внимания. Но растрачивать свою жизнь на оптимизации всего и вся просто глупо.
Всего и вся — конечно, согласен. Но давать советы такого рода, не зная, какова у автора вопроса ситуация, что ему нужно в действительности и каковы требования — не есть хорошо.В итоге это и будет работать в 33 раза медленнее — может, не у тебя, но по твоему рецепту.
PD>>Ну а если говорить о разложении файла на строчки — зачем ? Он и так разложен, своей структурой. Остается только отмэппить его в память, сделать массив указателей на строчки, и все. Ни один байт исходного текста ни копировать, ни двигать не надо. Вообще не надо. Ничего.
IT>Ну да, только не забудь переводы строк нулями забить в своём файле.
Зачем ? Если для работы со <string.h> — да, придется. А для других дел — меня вполне и CR/LF в конце устроит.
Здравствуйте, IT, Вы писали:
PD>>Ну а если говорить о разложении файла на строчки — зачем ? Он и так разложен, своей структурой. Остается только отмэппить его в память, сделать массив указателей на строчки, и все. Ни один байт исходного текста ни копировать, ни двигать не надо. Вообще не надо. Ничего.
IT>Ну да, только не забудь переводы строк нулями забить в своём файле.
Кстати, можно забить их нулями, а файл при этом и не пострадает . Берем мой пример
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Откуда тебе знать с какими задачами я сталкивался? Или у тебя начинает появлятся синдром первого парня на деревне, и ты думаешь, что ты один занимаешься чем-то уникальным и высокотехнологичным? PD>Глупо.
Чем дольше общаюсь с тобой, тем больше прихожу к выводу, что я был таки прав.
IT>>Пересматривать нужно архитектуру решаемой задачи в целом, а не твоего частного решения.
PD>А вообщеи забавно. Ничего по сути не зная о моей задаче, кроме того, что я сказал, ты берешься давать общие советы о том, как их надо оптимизировать. Курам на смех.
У тебя с логикой всё в порядке? Это не я бурусь давать советы, ничего не зная о твоей задаче. Это ты требуешь у всех выдать тебе решения не давая при этом ни какой информации. Точнее информация такая — двойной цикл, но это всё равно не то, что вы можешь себе там понапридумывать, это гораздо круче, не для вашего ума. Информации выше крыши.
Тебе рассказать как параллелить обработку двумерных массивов, рассказать про пул потоков и операцию деления 5000 (или сколько у тебя там) на 16? У вас в вашем учебном заведении читают курс по параллельным вычислениям? Может тебе стоит посетить несколько вводных лекций?
IT>>И что плохого в моём совете? То, что я могу свой код даже ночью спросонья без проблем воспроизвести за 10 секунд. Вот ты можешь своё решение воспроизвести за 10 секунд? А я могу.
PD>Было бы чем гордиться! Пусть качество решения будут каким угодно, зато я могу записать его за 10 сек. А зачем за 10 сек , если качество такое ?
Качество приемлемое. Ты вообще понимаешь смысл слова приемлемо? Может стоит ешё и лекции по русскому языку посетить.
PD>Я — не могу я за 10 сек воспроизвести.
Кто бы сомневался.
PD>И вообще, проснувшись, я предпочитаю умываться и пить кофе, а не воспроизводить код. PD>Зато потом работать оно будет не 10 сек, а 0.1 сек. PD>Быстро хорошо не бывает, сто раз уже сказано.
Запишись ещё на лекции по менеджменту. Там тебе расскажут почему проваливаются проекты, в которых некоторые умники вместо быстрого написания гибкого и простого кода медленно и сложно прибивают гвоздями к проекту преждевременные оптимизации.
PD>Всего и вся — конечно, согласен. Но давать советы такого рода, не зная, какова у автора вопроса ситуация, что ему нужно в действительности и каковы требования — не есть хорошо.В итоге это и будет работать в 33 раза медленнее — может, не у тебя, но по твоему рецепту.
Точный совет можно дать только зная точные приоритеты решаемой задачи. А об этом позаботиться, если ты всё ещё не понял, должен тот, кто спрашивает совета. Если человека волнует в первую очередь производительность, то об этом должно быть оговорено в самом начале. Если такого требования нет, то в современном софтостроении на первый план выходят совсем другие приоритеты. И таких случаев на порядок больше.
PD>>>Ну а если говорить о разложении файла на строчки — зачем ? Он и так разложен, своей структурой. Остается только отмэппить его в память, сделать массив указателей на строчки, и все. Ни один байт исходного текста ни копировать, ни двигать не надо. Вообще не надо. Ничего. IT>>Ну да, только не забудь переводы строк нулями забить в своём файле. PD>Зачем ? Если для работы со <string.h> — да, придется. А для других дел — меня вполне и CR/LF в конце устроит.
Т.е. твоё решение предполагает отказ от использования стандартных библиотек? А что вместо?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Именно. Глупо себя мнить самым умным, особенно среди студентов.
Это ты себя студентом считаешь ?
IT>У тебя с логикой всё в порядке? Это не я бурусь давать советы, ничего не зная о твоей задаче. Это ты требуешь у всех выдать тебе решения не давая при этом ни какой информации.
Не увиливай. Я тебе конкретно задачу дал (демо) — сложение двух матриц. Тут все и полностью определено.
>Точнее информация такая — двойной цикл, но это всё равно не то, что вы можешь себе там понапридумывать, это гораздо круче, не для вашего ума. Информации выше крыши.
Тебе алгоритм сложеняи матриц привести ? Пожалуйста
c[i,j] = a[i,j] + b[i,j] для i = 0, N-1; j = 0,M-1
IT>Тебе рассказать как параллелить обработку двумерных массивов, рассказать про пул потоков и операцию деления 5000 (или сколько у тебя там) на 16?
Я тебе ясно сказал — смысла параллелить нет, так как гораздо проще одновременно обрабатывать несколько матриц, по одной на ядро. Возьмем 16 матриц (в предположении, что они одного размера), поставим их рядом и будем считать это большой матрицей. Сложение двух таких матриц можно распараллелить по ядрам, но это просто и будет сложение каждой пары исходных матриц на каждом ядре. И об этом я уже говорил. Можешь объяснить, чем это лучше распараллеливания каждой малой матрицы на все ядра ?
>У вас в вашем учебном заведении читают курс по параллельным вычислениям? Может тебе стоит посетить несколько вводных лекций?
Ну да, конечно. Сказать-то нечего по существу, вот и приходится на личности переходить.
IT>Качество приемлемое. Ты вообще понимаешь смысл слова приемлемо? Может стоит ешё и лекции по русскому языку посетить.
М-да. Если тебе приходится такие аргументы приводить — значит, уже никаких серьезных аргументов у тебя не осталось.
PD>>Я — не могу я за 10 сек воспроизвести.
IT>Кто бы сомневался.
Ну и ну.
PD>>И вообще, проснувшись, я предпочитаю умываться и пить кофе, а не воспроизводить код. PD>>Зато потом работать оно будет не 10 сек, а 0.1 сек. PD>>Быстро хорошо не бывает, сто раз уже сказано.
IT>Запишись ещё на лекции по менеджменту. Там тебе расскажут почему проваливаются проекты, в которых некоторые умники вместо быстрого написания гибкого и простого кода медленно и сложно прибивают гвоздями к проекту преждевременные оптимизации.
О господи! Сколько ценных советов и все в одном письме.
PD>>Всего и вся — конечно, согласен. Но давать советы такого рода, не зная, какова у автора вопроса ситуация, что ему нужно в действительности и каковы требования — не есть хорошо.В итоге это и будет работать в 33 раза медленнее — может, не у тебя, но по твоему рецепту.
IT>Точный совет можно дать только зная точные приоритеты решаемой задачи. А об этом позаботиться, если ты всё ещё не понял, должен тот, кто спрашивает совета. Если человека волнует в первую очередь производительность, то об этом должно быть оговорено в самом начале. Если такого требования нет, то в современном софтостроении на первый план выходят совсем другие приоритеты. И таких случаев на порядок больше.
Если это даже и так, то человек, который берется давать советы, должен в первую очередь поинтересоваться требованями и ограничениями. Ничего такого ты не сделал, а прямо с лету дал свое решение, не зная ничего о задаче. А чуть выше ты написал — "Это не я бурусь давать советы, ничего не зная о твоей задаче". Мягко выражаясь, некоторое противоречие. И все потому, что тебе очень хотелось показать, какое там красивое однострочное решение. Об остальном ты и не думал.
PD>>>>Ну а если говорить о разложении файла на строчки — зачем ? Он и так разложен, своей структурой. Остается только отмэппить его в память, сделать массив указателей на строчки, и все. Ни один байт исходного текста ни копировать, ни двигать не надо. Вообще не надо. Ничего. IT>>>Ну да, только не забудь переводы строк нулями забить в своём файле. PD>>Зачем ? Если для работы со <string.h> — да, придется. А для других дел — меня вполне и CR/LF в конце устроит.
IT>Т.е. твоё решение предполагает отказ от использования стандартных библиотек? А что вместо?
А это сильно зависит от того, что делать надо. Кстати, и отказываться совсем не обязательно. В стандартной библиотеке масса функций типа strncpy и т.д., которые вполне работают со строками, не заканчивающимися нулем, так как копируют и т.д. не более чем указанное количество символов.
Здравствуйте, fmiracle, Вы писали:
F>Хуже того — считать последнюю строку файла (как и перемножить две матрицы) — это не задача реальной жизни. Это может быть задача только в универе на занятиях. В реальной жизни задача более глобальна и формулируется по бизнес-требованиям, которые она должна решить.
Взять строчку — не моя задача, отсылаю к автору.
Сложить матрицы — моя. В реальности "чуть" посложнее, чем сложение. Но это и есть реальная задача. Никаких дополнительных бизнес-требований там нет и быть не может. Ну не нравится тебе сложение — на тебе ближе к реальности. Антиалиасинг картинки 5000*5000. Тут матрица, правда, одна.
>А собственно операции перемножения матриц или взятия последней строки из файла — это уже отдельные подзадачи (методы, модули, задания кодерам),
Нет. это не подзадача. Это задача в целом. Поступают эти матрицы с входного устройства, и обрабатывай их как можно быстрее. Вот и все.
>и совершенно не факт, что наиболее узкие места будут именно в них.
Других мест нет .
F>В реальной задаче, столкнувшись с проблемой, что файлы стали уже по 500Гб и кусочек кода от IT с получением последней строчки жутко тормозит
Он не тормозит. Он просто вообще не может работать — не хватит адресного пространства.
>- там, может быть, применят оптимизацию, и перепишут этот маленький кусочек кода в боле большой и умный. А может быть просто решат (по совокупности показателей всей задачи с файлом же наверняка делают и что-то еще, кроме взятия последней строки), что файл тут уже не оправдывает себя и надо вместо него использовать СУБД.
Господь с тобой, какая тут СУБД. Чтобы взять из файла любой длины последнюю строчку, совсем не надо все остальное читать. Надо именно последнюю строчку.
PD>>Бред — это обсуждать решение, не зная ограничений и условий, а также не зная того, как это работает. S>Ограничения порой меняются после того как решение предоставлено.
Несомненно. Тем более надо о них спросить в начальный момент, и более того, спросить о возможности расширения. Если это файл настроек — это одно, сейчас 10, будет 30. Если это файл пользователей в городе — о, тут уже другой разговор. А если мне при этом скажут, что со временем не только в городе, а в целом регионе или вообще в России — тут надо крепко задуматься.
PD>>Если файл имеет размер в 100 Гб, то напрямую это решение не подходит, и вовсе не из-за своп-файла, а просто потому, что маппировать 100 Гб в адресное пространство 32-битного процесса никак целиком нельзя. Придется это делать по частям, размер части может быть не более 2 Гб (чуть меньше), что вполне в своп уместится. После этого придется view закрыть, в результате чего все модифицированные страницы будут освобождены и изменения потеряны. Таким образом, при файлах такого размера решение просто неприемлемо и надо найти другое. Проще всего файл скопировать. Фактически мы тут будем иметь то же самое, только копирование не на лету и не в своп-файл, а предварительно, и в другой файл. И там мне никто не мешает открывать view на последовательные куски файла и заменять CR на 0.
S>Т.е. под 100 Гиг это решение нельзя адаптировать, а можно только перерешить заново.
Еще раз — истина конкретна. Под 1 Кб — нечего огород городить. Под 100 Мб — самый раз. Под 100 Гб — да, лучше иначе.
PD>>Кстати, если уж на то пошло, не мог ли бы ты объяснить, как ты этот 100 Гб файл будешь на строки парсить ? Хоть какое-нибудь решение дай, а ? А то ведь если считать весь файл в буфер, а потом еще Split применить, тебе ведь 200 Гб (оперативной памяти + своп) понадобится. . В 32-битной ОС это просто невозможно, но и в 64-битной не пройдет тоже, пока не установишь на машине примерно так 256 Гб ОЗУ .
S>Т.к. простое 10-секундное решение использует хорошую абстракцию (на сколько я помню решение), то подменить стандартную реализацию чтения строк на свою не составит труда.
Ничего ты не понял. Их читать некуда. Хоть как реализуй, а выделить память в 100 Гб в 32 битном процессе невозможно. В x64 — можно, но если у тебя и впрямь не стоит 256 Гб RAM на машине, то это пойдет в своп, а своп не может быть 100 Гб. Да еще двойной размер из-за Split. Хоть что тут делай — нельзя их читать целиком. Никак. Ни на каком языке. Ни при каких абстракциях. Только по частям можно.
S>Итого, 10-секундное решение адаптируется к файлам любой длины без переписывания всего кода.
Запусти это решение для начала для файла в 10 Гб, потом расскажешь, что получилось
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Ограничения порой меняются после того как решение предоставлено.
PD>Несомненно. Тем более надо о них спросить в начальный момент, и более того, спросить о возможности расширения. Если это файл настроек — это одно, сейчас 10, будет 30. Если это файл пользователей в городе — о, тут уже другой разговор. А если мне при этом скажут, что со временем не только в городе, а в целом регионе или вообще в России — тут надо крепко задуматься.
Бывает нужно адаптировать к измененным требованиям код, который писался под другие требования. В этом случае изначальный момент безвовзратно упущен.
S>>Т.к. простое 10-секундное решение использует хорошую абстракцию (на сколько я помню решение), то подменить стандартную реализацию чтения строк на свою не составит труда.
PD>Ничего ты не понял. Их читать некуда. Хоть как реализуй, а выделить память в 100 Гб в 32 битном процессе невозможно. В x64 — можно, но если у тебя и впрямь не стоит 256 Гб RAM на машине, то это пойдет в своп, а своп не может быть 100 Гб. Да еще двойной размер из-за Split. Хоть что тут делай — нельзя их читать целиком. Никак. Ни на каком языке. Ни при каких абстракциях. Только по частям можно.
А я не говорил, что подменяя стандартную реализацию я буду использовать свою реализацию, в точности соответствующую стандартной, т.е. читать весь файл в память одной строкой.
Я говорил о том, что File.ReadAllLines можно заменить на что-то вроде
IEnumerable<string> MyFileUtilities.ReadAllLines(string fileName);
S>>Итого, 10-секундное решение адаптируется к файлам любой длины без переписывания всего кода.
PD>Запусти это решение для начала для файла в 10 Гб, потом расскажешь, что получилось
Вижу только одну причину, по которой это решение не отработает — наличие слишком больших строк в файле.
Но в этом плане оно не сильно хуже решения считать символы перевода строки с конца. Последняя строка тоже может не поместиться в адресное пространство или в RAM.
Здравствуйте, samius, Вы писали:
S>Я говорил о том, что File.ReadAllLines можно заменить на что-то вроде S>IEnumerable<string> MyFileUtilities.ReadAllLines(string fileName);
Я все же не понял. IEnumerable (то есть чтение по одной строке, так ?) — конечно лучше, но зачем вообще все строки читать, если нужна последняя ?
S>Вижу только одну причину, по которой это решение не отработает — наличие слишком больших строк в файле.
S>Но в этом плане оно не сильно хуже решения считать символы перевода строки с конца.
Ничего себе не хуже! Чтобы получить одну последнюю строку, ты считал файл целиком, пусть и построчно. Кстати, чтобы считать построчно, есть там у вас что-то вроде gets ? ReadLine не пойдет ? Ну и читай себе построчно, не надо никакие IEnumerable в ReadAllLines засовывать. Но ведь читать-то не надо.
>Последняя строка тоже может не поместиться в адресное пространство или в RAM.
Если последняя строка не поместится в АП (RAM тут не совсем к делу относится) — задача не имеет решения. Нельзя же, в самом деле, разместить в АП строку в 3 Гб размером! (x86) . Но я это определю без труда. Открою мэппинг на конечный кусок файла размером в примерно 2 Гб и пойду с конца (собственно, всегда так и буду делать, разве что если размер файла меньше 2 Гб, то будет меньше) и буду символы считать с конца. Если счетчик подойдет к 2 млрд , а CR/LF так и не нашелся — приехали.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Я говорил о том, что File.ReadAllLines можно заменить на что-то вроде S>>IEnumerable<string> MyFileUtilities.ReadAllLines(string fileName);
PD>Я все же не понял. IEnumerable (то есть чтение по одной строке, так ?) — конечно лучше, но зачем вообще все строки читать, если нужна последняя ?
Когда встанет задача обеспечить адаптацию уже написанного кода, который читает все строки, к большим файлам, я возьму и адаптирую его (а не перепишу заново).
S>>Вижу только одну причину, по которой это решение не отработает — наличие слишком больших строк в файле.
S>>Но в этом плане оно не сильно хуже решения считать символы перевода строки с конца.
PD>Ничего себе не хуже! Чтобы получить одну последнюю строку, ты считал файл целиком, пусть и построчно. Кстати, чтобы считать построчно, есть там у вас что-то вроде gets ? ReadLine не пойдет ? Ну и читай себе построчно, не надо никакие IEnumerable в ReadAllLines засовывать.
Да, есть StreamReader.ReadLine(). Но он мне не совсем подходит, т.к. первоначальное решение использовало массив строк из File.ReadAllLines(). Безболезненно я ее могу заменить только на IEnumerable<string>. Потому StreamReader.ReadLine() придется обернуть в IEnumerable, чтобы не переписывать все решение.
PD>Но ведь читать-то не надо.
У меня некоторые пробелы на тему кодировок. Я вот не уверен, что при чтении файла задом наперед, или какими-то кусками не с самого начала, можно гарантированно идентифицировать символы конца строки. Это еще одна причина, по которой я бы текстовый файл читал только последовательно.
Здравствуйте, fmiracle, Вы писали:
F>Да вот и не все? Сколько их поступает?
Много
>Куда должен быть положен результат
В файл.
>, зачем он должен быть положен именно туда, и может быть его можно с тем же успехом класть куда-то еще?
А собственно, какое тебе дело до того, что я потом с этой матрицей делаю ? Это ведь на скорость обработки матриц не влияет.
F>Тебе ведь предлагали сдлеать кластер из многих компов, ты отказался аргументировав это тем, что очень дорогое 3dparty ПО стоит. Но может быть можно на одном компе (с 3rdparty ПО) получать матрицы, а потом передавать их на кластер из сотен компьютеров для обработки?
Все там намного сложнее. Получают их вообще на других компьютерах, здесь только обработка.
F>Это так, например. И сразу проблемы становятся более другие чем обработка на одной машине.
Не уходи в сторону. Есть некая задача, вот ее и нужно оптимизировать. Она — вполне самостоятельный процесс. Все остальное сейчас не к делу, и детали я рассказывать не буду.
>>>- там, может быть, применят оптимизацию, и перепишут этот маленький кусочек кода в боле большой и умный. А может быть просто решат (по совокупности показателей всей задачи с файлом же наверняка делают и что-то еще, кроме взятия последней строки), что файл тут уже не оправдывает себя и надо вместо него использовать СУБД.
PD>>Господь с тобой, какая тут СУБД. Чтобы взять из файла любой длины последнюю строчку, совсем не надо все остальное читать. Надо именно последнюю строчку.
F>Господь с тобой, Павел. Я не раз общался с заказчиками о требуемых им задачах. Поверь, ни разу никого из них не интересовало получить последнюю строчку из фала и ничего хоть сколько-то близкое к подобной постановке задачи.
Слушай, ради всех богов, не приставай ко мне с этой последней строкой. Еще раз — не я эту задачу выдумал, я лишь прокомментировал решение IT. Найди автора этой проблемы и спроси его, зачем ему это понадобилось. Я тут ни при чем.
>Их все больше интересует что-то типа "правильно склеить изображения снятые с разных камер" или "получать информацию о новых просроченных кредитах каждый понедельник". Интересуют сроки и стоимость решения (включая и разработку и железо). А используется там файл, СУБД или таз с гайками их вообще не интересует.
Заказчика , может, и не интересует, что там внизу, а вот скорость его очень даже интересует.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Именно. Глупо себя мнить самым умным, особенно среди студентов. PD>Это ты себя студентом считаешь ?
Всё время учиться — неотъемлемая часть моей профессии, так что можно и так сказать. Но в данном случае я имел ввиду твоих студентов.
IT>>У тебя с логикой всё в порядке? Это не я бурусь давать советы, ничего не зная о твоей задаче. Это ты требуешь у всех выдать тебе решения не давая при этом ни какой информации.
PD>Не увиливай. Я тебе конкретно задачу дал (демо) — сложение двух матриц. Тут все и полностью определено.
"Полностью определено" из тебя пришлось щипцами вытягивать.
IT>>Тебе рассказать как параллелить обработку двумерных массивов, рассказать про пул потоков и операцию деления 5000 (или сколько у тебя там) на 16?
PD>Я тебе ясно сказал — смысла параллелить нет, так как гораздо проще одновременно обрабатывать несколько матриц, по одной на ядро.
А это разве называется не распараллеливание?
PD> Можешь объяснить, чем это лучше распараллеливания каждой малой матрицы на все ядра ?
Дворкин, я сейчас умру со смеху. На твоё предложение ускорить твой алгоритм в 10 раз, я тебе сразу предложил взять 16 ядер и распараллелить твой алгоритм. То ли это распараллеливание одной матрицы, то ли потока — это детали. Если бы у меня было больше информации, я бы тебе предложил что-то более конкретное.
IT>>Качество приемлемое. Ты вообще понимаешь смысл слова приемлемо? Может стоит ешё и лекции по русскому языку посетить.
PD>М-да. Если тебе приходится такие аргументы приводить — значит, уже никаких серьезных аргументов у тебя не осталось.
Ты всё же поразмысле на досуге над смыслом слова 'приемлемо'.
IT>>Точный совет можно дать только зная точные приоритеты решаемой задачи. А об этом позаботиться, если ты всё ещё не понял, должен тот, кто спрашивает совета. Если человека волнует в первую очередь производительность, то об этом должно быть оговорено в самом начале. Если такого требования нет, то в современном софтостроении на первый план выходят совсем другие приоритеты. И таких случаев на порядок больше.
PD>Если это даже и так, то человек, который берется давать советы, должен в первую очередь поинтересоваться требованями и ограничениями.
Ты опять не понял. Если человек спрашивает совета или предлагает решить задачу, то он либо должен уточнить условия, либо должен дальше уже сам выбирать наиболее подходящий вариант из предложенных. На твой вопрос "как ускорить обработку матриц" (именно так, без дополнительных условий), ты получил ответ — возьми 16 ядер и распараллель свой алгоритм. Что в этом ответе не понятного?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я себе живо эту ситуацию представляю. Приглашают тебя и просят написать программу, которая 100 Гб текстовый файл на строчки парсит. На это ты отвечаешь — у меня есть замечательное решение, я его даже спросонок могу выдать за 10 сек, только, пожалуйста, купите мне машину с 256 Гб ОП
Повторенье — мать ученья. Давай сначала.
Когда меня 'приглашают и просят написать программу, которая 100 Гб текстовый файл на строчки парсит', то мне уже задают вполне конкретые условия, от которых зависит реализация. Вот так и надо делать, если ты хочешь получить ожидаемое решение. Ты же обычно в своих постановках задачи эти важные детали только подразумеваешь. А ещё чаще твоя вая твоя постановка задачи сводится к 'приглашают и просят написать программу'. Пока ты не научишься чётко ставить перед человеком проблему, ты будешь получать решения, вполне приемлемые в условиях, которые тебя не устраивают. Так научись чётко ставить задачу и всё у тебя получится.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, fmiracle, Вы писали:
F>В реальной задаче, столкнувшись с проблемой, что файлы стали уже по 500Гб и кусочек кода от IT с получением последней строчки жутко тормозит — там, может быть, применят оптимизацию, и перепишут этот маленький кусочек кода в боле большой и умный.
При этом вся оптимизация может свестись к замене методов GetAllLines().Split() на версию с перечислителем, которая внутри исползует потоковый или какой другой эффективный доступ к файлу. И овцы сыты и волки как говорится. Но это очень сложно объяснить товарищам, жаждущим оптимизаций в каждой строчке кода.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>>Именно. Глупо себя мнить самым умным, особенно среди студентов. PD>>Это ты себя студентом считаешь ?
IT>Всё время учиться — неотъемлемая часть моей профессии
Это правильно
>так что можно и так сказать. Но в данном случае я имел ввиду твоих студентов.
Они тоже учатся.
IT>>>У тебя с логикой всё в порядке? Это не я бурусь давать советы, ничего не зная о твоей задаче. Это ты требуешь у всех выдать тебе решения не давая при этом ни какой информации.
PD>>Не увиливай. Я тебе конкретно задачу дал (демо) — сложение двух матриц. Тут все и полностью определено.
IT>"Полностью определено" из тебя пришлось щипцами вытягивать.
Пусть даже так, хотя я и не согласен. Вытянул ? Давай решение. Только без разговоров о распараллеливании.
IT>>>Тебе рассказать как параллелить обработку двумерных массивов, рассказать про пул потоков и операцию деления 5000 (или сколько у тебя там) на 16?
PD>>Я тебе ясно сказал — смысла параллелить нет, так как гораздо проще одновременно обрабатывать несколько матриц, по одной на ядро.
IT>А это разве называется не распараллеливание?
Безусловно да. Но к делу отношения не имеет.
PD>> Можешь объяснить, чем это лучше распараллеливания каждой малой матрицы на все ядра ?
IT>Дворкин, я сейчас умру со смеху
Постарайся все же остаться в живых
>На твоё предложение ускорить твой алгоритм в 10 раз, я тебе сразу предложил взять 16 ядер и распараллелить твой алгоритм. То ли это распараллеливание одной матрицы, то ли потока — это детали. Если бы у меня было больше информации, я бы тебе предложил что-то более конкретное.
Ты даже простую вещь не понимаешь. Взять 16 ядер — это не ускорение алгоритма. Это использование дополнительных ресурсов при неизменной (а то и хуже) скорости алгоритма. С таким же успехом можно предложить вместо Pentium 100 взять Pentium 4 3000 и сказать — мы ускорили в N0 раз. Ничего тут не ускоряется и нет никаких заслуг программиста в этом.
Я поэтому тебе и сказал про 16 компьютеров. Велика мудрость — взять вместо одного компьютера 16 (или 16 ядер) и сказать — мы ускорили в 16 раз. К оптимизации алгоритма это вообще отношения имеет очень мало. Ты вот на одном ядре сделай, чтобы он работал быстрее, вот это будет результат.
IT>Ты опять не понял. Если человек спрашивает совета или предлагает решить задачу, то он либо должен уточнить условия, либо должен дальше уже сам выбирать наиболее подходящий вариант из предложенных. На твой вопрос "как ускорить обработку матриц" (именно так, без дополнительных условий), ты получил ответ — возьми 16 ядер и распараллель свой алгоритм. Что в этом ответе не понятного?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я себе живо эту ситуацию представляю. Приглашают тебя и просят написать программу, которая 100 Гб текстовый файл на строчки парсит. На это ты отвечаешь — у меня есть замечательное решение, я его даже спросонок могу выдать за 10 сек, только, пожалуйста, купите мне машину с 256 Гб ОП
IT>Повторенье — мать ученья. Давай сначала.
IT>Когда меня 'приглашают и просят написать программу, которая 100 Гб текстовый файл на строчки парсит', то мне уже задают вполне конкретые условия, от которых зависит реализация. Вот так и надо делать, если ты хочешь получить ожидаемое решение.
Слава богу, хоть в чем-то я могу с тобой согласиться. Только вот именно это я везде и твержу — решение надо давать применительно к условиям. А не советовать ReadAllLines + Split, не зная этих условий.
>Ты же обычно в своих постановках задачи эти важные детали только подразумеваешь.
Ладно, пусть я подразумеваю. Но зачем все же ты с этим чтением последней строки так упорствуешь в своем решении ? Задача там не моя, но ты почему-то у автора не стал спрашивать этих деталей, а сходу выложил свое универсальное однострочное решение, да еще и сейчас его отстаиваешь, аргументируя тем, что за 10 сек его можно написать.
Давай прямо — для хотя бы 500 Мб файла — ты по-прежнему утверждаешь, что твое однострочное решение годится ? Да или нет ?
>А ещё чаще твоя вая твоя постановка задачи сводится к 'приглашают и просят написать программу'. Пока ты не научишься чётко ставить перед человеком проблему, ты будешь получать решения, вполне приемлемые в условиях, которые тебя не устраивают. Так научись чётко ставить задачу и всё у тебя получится.
А с чего ты решил, что у меня что-то не получается ??? . До сих пор все получалось.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, fmiracle, Вы писали:
F>>В реальной задаче, столкнувшись с проблемой, что файлы стали уже по 500Гб и кусочек кода от IT с получением последней строчки жутко тормозит — там, может быть, применят оптимизацию, и перепишут этот маленький кусочек кода в боле большой и умный.
IT>При этом вся оптимизация может свестись к замене методов GetAllLines().Split() на версию с перечислителем, которая внутри исползует потоковый или какой другой эффективный доступ к файлу. И овцы сыты и волки как говорится. Но это очень сложно объяснить товарищам, жаждущим оптимизаций в каждой строчке кода.
да оставьте вы в покое тов. Дворкина. Никто в здравом уме не хочет миллионов оптимизаций в миллионах строк кода. Речь идет о том что некоторые отрасли имеют типичные ожидания пользователей, закрепленные многими реализациями. И если платформа под них не не адаптирована, то никакой разумной заменой методов это не сделать. В качестве примера (как можно дальше от своей отрасли где даже опенсорс под нда) могу привести блог разработчиков Unity, которые были не очень счастливы когда выяснилось что большую часть стоимости портирования моно на яблофон им придется заплатить самим Причем это успешный пример тк они это сделали и это было дешевле. (вброс) А теперь добавьте-ка им туда linq и все фичи 3.5 или 4.0
а какой вывод ? топегстартера интересовала секьюрити. Обсудили: часть народа интересовала свобода, а часть минимизация усилий и всем было плевать на секьюрити, кроме случаев когда юзеры ее специфицировали и не отвертеться. Предложенная замена языка реализации не заинтересовала никого тк писать на специально "обезопасенном" языке добровольно никто не захочет.
PD>>Я все же не понял. IEnumerable (то есть чтение по одной строке, так ?) — конечно лучше, но зачем вообще все строки читать, если нужна последняя ? S>Когда встанет задача обеспечить адаптацию уже написанного кода, который читает все строки, к большим файлам, я возьму и адаптирую его (а не перепишу заново).
Его — перепишешь. Просто тот вариант не пройдет в принципе, поэтому придется сменить алгоритм. Ну хотя бы с IEumerable.
PD>>Ничего себе не хуже! Чтобы получить одну последнюю строку, ты считал файл целиком, пусть и построчно. Кстати, чтобы считать построчно, есть там у вас что-то вроде gets ? ReadLine не пойдет ? Ну и читай себе построчно, не надо никакие IEnumerable в ReadAllLines засовывать. S>Да, есть StreamReader.ReadLine(). Но он мне не совсем подходит, т.к. первоначальное решение использовало массив строк из File.ReadAllLines(). Безболезненно я ее могу заменить только на IEnumerable<string>. Потому StreamReader.ReadLine() придется обернуть в IEnumerable, чтобы не переписывать все решение.
Хм... А стоит ли ? Обернуть, конечно, можно, но, честно говоря, сделать просто замену кода — работы на полчаса. Кстати, никакого IEnumerable пока что в варианте IT нет, это тоже надо делать. Так не проще ли выкинуть его решение и сделать чтение по строкам(я сейчас абстрагируюсь от того, что это тоже не хорошо, временно допустим, что хорошо), чем насильно пытаться то решение адаптировать. Зачем ?
PD>>Но ведь читать-то не надо. S>У меня некоторые пробелы на тему кодировок. Я вот не уверен, что при чтении файла задом наперед, или какими-то кусками не с самого начала, можно гарантированно идентифицировать символы конца строки.
По крайней мере для ASCII-8, UTF-8 и Unicode 0D0A всегда на месте (для юникода, конечно, short). Что касается всех возможных на свете форматов — как говорится. я вам не скажу за всю Одессу. Но тут опять же истина конкретна. Если речь идет о возможности чтения всех и всяческих форматов — тогда стоит подумать. Ну а если ясно, что никаких экзотических форматов не будет — вперед и с песнями.
>Это еще одна причина, по которой я бы текстовый файл читал только последовательно.
Слишком дорогая плата. Ты обеспечишь, что программа будет корректно работать с экзотическими форматами, но заткнется на файле в 5-10 Гб (с IEnumerable по времени, в варианте IT — по нехватке памяти ). Я этот файл обработаю, но проблемы будут с экзотикой . ИМХО второе лучше.
Здравствуйте, samius, Вы писали:
S>Две строчки скорее всего перепишу. Но если речь пойдет о задаче большей — буду пытаться адаптировать.
+1. Вообще-то граница между адаптацией и переписыванием несколько размыта. В любом случае — изменять, больше или меньше.
S>>>Да, есть StreamReader.ReadLine(). Но он мне не совсем подходит, т.к. первоначальное решение использовало массив строк из File.ReadAllLines(). Безболезненно я ее могу заменить только на IEnumerable<string>. Потому StreamReader.ReadLine() придется обернуть в IEnumerable, чтобы не переписывать все решение.
PD>>Хм... А стоит ли ? Обернуть, конечно, можно, но, честно говоря, сделать просто замену кода — работы на полчаса. Кстати, никакого IEnumerable пока что в варианте IT нет, это тоже надо делать. S>Нет? А что там есть? Массив строк? Если честно, я его в точности не помню.
ReadAllLines в буфер + Split
PD>>Так не проще ли выкинуть его решение и сделать чтение по строкам(я сейчас абстрагируюсь от того, что это тоже не хорошо, временно допустим, что хорошо), чем насильно пытаться то решение адаптировать. Зачем ? S>Конкретно в этой задаче может и проще. В других случаях будет проще адаптировать, даже не разбираясь в сути алгоритма.
Все может быть. Я тоже не любитель переделывать все заново, но еще меньше люблю за уши притягивать. Стройность системы страдает.
S>>>У меня некоторые пробелы на тему кодировок. Я вот не уверен, что при чтении файла задом наперед, или какими-то кусками не с самого начала, можно гарантированно идентифицировать символы конца строки.
PD>>По крайней мере для ASCII-8, UTF-8 и Unicode 0D0A всегда на месте (для юникода, конечно, short). Что касается всех возможных на свете форматов — как говорится. я вам не скажу за всю Одессу. Но тут опять же истина конкретна. Если речь идет о возможности чтения всех и всяческих форматов — тогда стоит подумать. Ну а если ясно, что никаких экзотических форматов не будет — вперед и с песнями. S>UTF-16 — экзотика? Нет, там символы перевода строки не кодируются, но это уже будет не 0D0A!
Точно не кодируются ? В классическом Юникоде кодируются, только , естественно, wchar_t, а не char. А UTF-16 вроде как отличается лишь наличием суррогатных пар.
>>>Это еще одна причина, по которой я бы текстовый файл читал только последовательно.
PD>>Слишком дорогая плата. Ты обеспечишь, что программа будет корректно работать с экзотическими форматами, но заткнется на файле в 5-10 Гб (с IEnumerable по времени, в варианте IT — по нехватке памяти ). Я этот файл обработаю, но проблемы будут с экзотикой . ИМХО второе лучше.
S>Потом заказчик решит, что 5-10Гб текстового файла — слишком жестко для диска (или передачи по сети). И предложит зазиповать тексты. S>Вот тогда мы с IT изменим одну строчку, а тебе придется опять переписать все!
А чем ты гордишься ? Если бы ты сказал, что сумееешь вытащить эту строчку из архивированного файла без его распаковки — вот это было бы да! А так вы просто используете тот факт. что в .NET библиотеке есть (явно или неявно- не важно) этот распаковщик, а в С++ RTL его нет. Найду его — тоже в виде одной строчки напишу .
Ну а то, что библиотека .NET по своему составу очень даже неплохая — кто бы спорил. Ее бы неуправляемую версию сделать, да кое-что внутри переписать как следует, да внешний интерфейс несколько изменить (например, IEnumerable вместо (или хотя бы вместе) с методами, возвращающими коллекцию целиком) — вообще прелесть бы получилась
S>Но это все к теме о выдумывании условий, чтобы коню в вакууме скучно не было.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
PD>>>Хм... А стоит ли ? Обернуть, конечно, можно, но, честно говоря, сделать просто замену кода — работы на полчаса. Кстати, никакого IEnumerable пока что в варианте IT нет, это тоже надо делать. S>>Нет? А что там есть? Массив строк? Если честно, я его в точности не помню.
PD>ReadAllLines в буфер + Split
Вообще File.ReadAllLines читает строки последовательно из StreamReader-а и Split не делает и делать его незачем.
File.ReadAllLines("data.txt").Last();
Вернет последнюю строку если хватит памяти чтобы затолкать все строки. Единственная проблема ReadAllLines в том, что он читает все строки файла за раз и возвращает массив. Возвращал бы IEnumerable через yield return — не было бы проблем.
S>>>>У меня некоторые пробелы на тему кодировок. Я вот не уверен, что при чтении файла задом наперед, или какими-то кусками не с самого начала, можно гарантированно идентифицировать символы конца строки.
PD>Точно не кодируются ? В классическом Юникоде кодируются, только , естественно, wchar_t, а не char. А UTF-16 вроде как отличается лишь наличием суррогатных пар.
UTF-16 кодирует 16-битными словами как минимум. т.е. паттерн 0d0a будет означать единый символ.
S>>Потом заказчик решит, что 5-10Гб текстового файла — слишком жестко для диска (или передачи по сети). И предложит зазиповать тексты. S>>Вот тогда мы с IT изменим одну строчку, а тебе придется опять переписать все!
PD>А чем ты гордишься ? Если бы ты сказал, что сумееешь вытащить эту строчку из архивированного файла без его распаковки — вот это было бы да! А так вы просто используете тот факт. что в .NET библиотеке есть (явно или неявно- не важно) этот распаковщик, а в С++ RTL его нет. Найду его — тоже в виде одной строчки напишу .
К своему решению — нет, не получится. Если только не умеешь распаковывать зип с хвоста
PD>Ну а то, что библиотека .NET по своему составу очень даже неплохая — кто бы спорил.
нет, речь не о библиотеке .NET, а о высокоуровневых конструкциях vs чтению файла с конца.
Здравствуйте, samius, Вы писали:
S>Вообще File.ReadAllLines читает строки последовательно из StreamReader-а и Split не делает и делать его незачем.
Ну это к IT. Он там Split употребил.
S>Вернет последнюю строку если хватит памяти чтобы затолкать все строки. Единственная проблема ReadAllLines в том, что он читает все строки файла за раз и возвращает массив. Возвращал бы IEnumerable через yield return — не было бы проблем.
Это, кстати, хроническая болезнь .NET — вернем все вместо того, чтобы вернуть IEnumerable
S>UTF-16 кодирует 16-битными словами как минимум. т.е. паттерн 0d0a будет означать единый символ.
Гм. При чем тут 0d0a ? Там должно быть 000D 000A. В классическом Юникоде именно так. Раз символы двухбайтные. то и CR/LF тоже, они же тоже символы, причем из 0-127. которые совпадают с ASCII, только 2 байта.
S>>>Потом заказчик решит, что 5-10Гб текстового файла — слишком жестко для диска (или передачи по сети). И предложит зазиповать тексты. S>>>Вот тогда мы с IT изменим одну строчку, а тебе придется опять переписать все!
PD>>А чем ты гордишься ? Если бы ты сказал, что сумееешь вытащить эту строчку из архивированного файла без его распаковки — вот это было бы да! А так вы просто используете тот факт. что в .NET библиотеке есть (явно или неявно- не важно) этот распаковщик, а в С++ RTL его нет. Найду его — тоже в виде одной строчки напишу . S>К своему решению — нет, не получится. Если только не умеешь распаковывать зип с хвоста
Не понял. Ты будешь читать из GZipStream (так вроде) Но он же натравлен на файл, а значит, внутри себя будет распаковывать. Может, и не в файл, а в память (где он ее возьмет...). Ну а я найду функцию распаковки в файл, остальное как прежде.
PD>>Ну а то, что библиотека .NET по своему составу очень даже неплохая — кто бы спорил. S>нет, речь не о библиотеке .NET, а о высокоуровневых конструкциях vs чтению файла с конца.
Чтение файла хоть с начала, хоть с конца, хоть с середины , хоть как еще — дело вполне банальное. fseek в С++ или FileStream.Seek в .NET. А в конечном счете — SetFilePointer. В конечном счете — все одно и то же, потому как делает это ОС.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>UTF-16 кодирует 16-битными словами как минимум. т.е. паттерн 0d0a будет означать единый символ.
PD>Гм. При чем тут 0d0a ? Там должно быть 000D 000A. В классическом Юникоде именно так. Раз символы двухбайтные. то и CR/LF тоже, они же тоже символы, причем из 0-127. которые совпадают с ASCII, только 2 байта.
А откуда мы об этом узнаем если в условии нет ничего о кодировке? В конце файла об этом не написано.
S>>>>Потом заказчик решит, что 5-10Гб текстового файла — слишком жестко для диска (или передачи по сети). И предложит зазиповать тексты. S>>>>Вот тогда мы с IT изменим одну строчку, а тебе придется опять переписать все!
PD>Не понял. Ты будешь читать из GZipStream (так вроде) Но он же натравлен на файл, а значит, внутри себя будет распаковывать. Может, и не в файл, а в память (где он ее возьмет...).
GZipStream натравливается на стрим же и является стримом. Т.е. это просто декоратор. Клиенту, читающему из стрима (в данном случае StreamReader-у) фиолетово, откуда читать, из FileStream или из GZipStream. Кстати, не везде в дотнете это фиолетово. Например, System.Drawing.Bitmap из GZipStream-а не умеет грузиться.
PD>Ну а я найду функцию распаковки в файл, остальное как прежде.
Оу. Так это чтобы прочитать последнюю строчку из зазипованного файла, нужно будет распаковать его, а это означает на диске должно быть адекватное свободное место... Да и долго!
Нет, разжимать в файл только для того чтобы прочитать последнюю строчку — плохая идея.
PD>Чтение файла хоть с начала, хоть с конца, хоть с середины , хоть как еще — дело вполне банальное. fseek в С++ или FileStream.Seek в .NET. А в конечном счете — SetFilePointer. В конечном счете — все одно и то же, потому как делает это ОС.
Да я не спорю. Речь о том, что высокоуровневое решение может оказаться гибче и быстрее при изменении требований, гораздо дешевле адаптироваться чем низкоуровневое.
Здравствуйте, samius, Вы писали:
S>А откуда мы об этом узнаем если в условии нет ничего о кодировке? В конце файла об этом не написано.
Верно. Но написано в начале. Придется еще пару байт из начала взять
S>>>>>Потом заказчик решит, что 5-10Гб текстового файла — слишком жестко для диска (или передачи по сети). И предложит зазиповать тексты. S>>>>>Вот тогда мы с IT изменим одну строчку, а тебе придется опять переписать все!
S>GZipStream натравливается на стрим же и является стримом. Т.е. это просто декоратор.
Это все на врехнем уровне. Не святой же дух там распакрвывает, а функция. Она создает там распакованный файл и подсовывает его. Я тоже могу сделать наследник от fstream, делающий внутри себя то же самое.
>Клиенту, читающему из стрима (в данном случае StreamReader-у) фиолетово, откуда читать, из FileStream или из GZipStream.
И мне тогда будет фиолетово. Ну согласись сам, не открыл же .NET что-то новое в плане доступа к архивам. Он просто внутри код содержит.
PD>>Ну а я найду функцию распаковки в файл, остальное как прежде. S>Оу. Так это чтобы прочитать последнюю строчку из зазипованного файла, нужно будет распаковать его, а это означает на диске должно быть адекватное свободное место... Да и долго!
А ты думаешь, твой GZIpStream вернет тебе эту строчку без распаковки ? Как это вообще можно сделать ?
S>Нет, разжимать в файл только для того чтобы прочитать последнюю строчку — плохая идея.
класс GZipStream. Выделено мной
public override IAsyncResult BeginRead(byte[] array, int offset, int count, AsyncCallback asyncCallback, object asyncState)
{
if (this.deflateStream == null)
{
throw new InvalidOperationException(SR.GetString("ObjectDisposed_StreamClosed"));
}
return this.deflateStream.BeginRead(array, offset, count, asyncCallback, asyncState);
}
Provides methods and properties for compressing and decompressing streams using the Deflate algorithm
Так что, как видишь, там внутри просто еще один — распакованный — поток. В файле или в памяти — не знаю, мне все равно.
Чудес не бывает.
PD>>Чтение файла хоть с начала, хоть с конца, хоть с середины , хоть как еще — дело вполне банальное. fseek в С++ или FileStream.Seek в .NET. А в конечном счете — SetFilePointer. В конечном счете — все одно и то же, потому как делает это ОС. S>Да я не спорю. Речь о том, что высокоуровневое решение может оказаться гибче и быстрее при изменении требований, гораздо дешевле адаптироваться чем низкоуровневое.
Черт его знает. Вот я взял в примере для IT и сделал так, что 0D на 0 заменяется, а файл при этом не страдает. Фишка — WRITECOPY механизм NT. Изменения коснулись 2 параметров, все. А с высокоуровневым решением придется копировать файл, это уже серьезнее.
Адаптировать проще при постройке из кирпичей, хотя строить из кирпичей намного медленнее. Захотел заказчик круглую стенку — будет круглая. А из крупных блоков не получится, если нет таких блоков.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>GZipStream натравливается на стрим же и является стримом. Т.е. это просто декоратор.
PD>Это все на врехнем уровне. Не святой же дух там распакрвывает, а функция. Она создает там распакованный файл и подсовывает его. Я тоже могу сделать наследник от fstream, делающий внутри себя то же самое.
Именно святым духом!!! Никакой файл там не создается. BaseStream разжимается по мере чтения данных из декорирующего стрима, т.е. по мере того как StreamReader будет запрашивать очередную порцию чтобы заполнить буфер.
>>Клиенту, читающему из стрима (в данном случае StreamReader-у) фиолетово, откуда читать, из FileStream или из GZipStream.
PD>И мне тогда будет фиолетово. Ну согласись сам, не открыл же .NET что-то новое в плане доступа к архивам. Он просто внутри код содержит.
Соглашаюсь
S>>Оу. Так это чтобы прочитать последнюю строчку из зазипованного файла, нужно будет распаковать его, а это означает на диске должно быть адекватное свободное место... Да и долго!
PD>А ты думаешь, твой GZIpStream вернет тебе эту строчку без распаковки ? Как это вообще можно сделать ?
Нет, он мне все распакует, но накапливаться хозяйство не будет ни в файле, ни в памяти. Лишние строки соберет GC, а у StreamReader-а буфер фиксированный.
S>>Нет, разжимать в файл только для того чтобы прочитать последнюю строчку — плохая идея.
PD>класс GZipStream. Выделено мной
PD>
PD>public override IAsyncResult BeginRead(byte[] array, int offset, int count, AsyncCallback asyncCallback, object asyncState)
PD>{
PD> if (this.deflateStream == null)
PD> {
PD> throw new InvalidOperationException(SR.GetString("ObjectDisposed_StreamClosed"));
PD> }
PD> return this.deflateStream.BeginRead(array, offset, count, asyncCallback, asyncState);
PD>}
PD>
PD>Так что, как видишь, там внутри просто еще один — распакованный — поток. В файле или в памяти — не знаю, мне все равно.
DeflateStream делает основную работу. GZipStream — обертка. Распакованных данных нет в полном объеме. Они извлекаются по требованию Stream.Read(byte[], int, int).
PD>Чудес не бывает.
Да это не чудо а ловкость рук.
PD>Адаптировать проще при постройке из кирпичей, хотя строить из кирпичей намного медленнее. Захотел заказчик круглую стенку — будет круглая. А из крупных блоков не получится, если нет таких блоков.
S>Именно святым духом!!! Никакой файл там не создается. BaseStream разжимается по мере чтения данных из декорирующего стрима, т.е. по мере того как StreamReader будет запрашивать очередную порцию чтобы заполнить буфер.
Завтра посмотрю по рефлектору. Может, ты и прав. Но сути дела это не изменит — для последней строки все равно придется распаковать все.
>>>Клиенту, читающему из стрима (в данном случае StreamReader-у) фиолетово, откуда читать, из FileStream или из GZipStream.
S>Нет, он мне все распакует, но накапливаться хозяйство не будет ни в файле, ни в памяти. Лишние строки соберет GC, а у StreamReader-а буфер фиксированный.
Хм. Интересно. То есть при фиксированном буфере они решают проблему перехода от одной строки к другой ? При распаковке куска можно ведь и на середине строки оказаться...
S>>>Нет, разжимать в файл только для того чтобы прочитать последнюю строчку — плохая идея.
PD>>класс GZipStream. Выделено мной
PD>>
PD>>public override IAsyncResult BeginRead(byte[] array, int offset, int count, AsyncCallback asyncCallback, object asyncState)
PD>>{
PD>> if (this.deflateStream == null)
PD>> {
PD>> throw new InvalidOperationException(SR.GetString("ObjectDisposed_StreamClosed"));
PD>> }
PD>> return this.deflateStream.BeginRead(array, offset, count, asyncCallback, asyncState);
PD>>}
PD>>
PD>>Так что, как видишь, там внутри просто еще один — распакованный — поток. В файле или в памяти — не знаю, мне все равно. S>DeflateStream делает основную работу. GZipStream — обертка. Распакованных данных нет в полном объеме. Они извлекаются по требованию Stream.Read(byte[], int, int).
PD>>Чудес не бывает. S>Да это не чудо а ловкость рук.
PD>>Адаптировать проще при постройке из кирпичей, хотя строить из кирпичей намного медленнее. Захотел заказчик круглую стенку — будет круглая. А из крупных блоков не получится, если нет таких блоков.
S>Если нет блоков, то и спора нет.
Если и есть блоки , но не круглые. то и ничего не будет
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Нет, он мне все распакует, но накапливаться хозяйство не будет ни в файле, ни в памяти. Лишние строки соберет GC, а у StreamReader-а буфер фиксированный.
PD>Хм. Интересно. То есть при фиксированном буфере они решают проблему перехода от одной строки к другой ? При распаковке куска можно ведь и на середине строки оказаться...
Все немного не так. GZipStream подсаживается на FileStream, который создан над упакованным файлом и ведет себя как обычный стрим, но с ограничениями: только чтение и только последовательно (Никаких Seek, Length и пр.). Но операцию Read он обеспечивает с точностью как если бы мы читали напрямик из незажатого файла.
А проблему с серединой строк решает именно StreamReader, которому на вход подается стрим, чьи данные УЖЕ распакованы (точнее распаковываются по мере обращения к методу Read, но возвращаются распакованные).
Здравствуйте, samius, Вы писали:
S>Все немного не так. GZipStream подсаживается на FileStream, который создан над упакованным файлом и ведет себя как обычный стрим, но с ограничениями: только чтение и только последовательно (Никаких Seek, Length и пр.). Но операцию Read он обеспечивает с точностью как если бы мы читали напрямик из незажатого файла.
А... Ну тогда посмотри в Win API LZRead и иже с ними. Правда, я уже лет 10 их не использовал.
S>А проблему с серединой строк решает именно StreamReader, которому на вход подается стрим, чьи данные УЖЕ распакованы (точнее распаковываются по мере обращения к методу Read, но возвращаются распакованные).
Ладно, пора, я думаю в этой ветви .next = NULL делать
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Давай прямо — для хотя бы 500 Мб файла — ты по-прежнему утверждаешь, что твое однострочное решение годится ? Да или нет ?
И да и нет. Первым делом я попробую написать версию GetAllLines через перечислитель. Это снимет проблему перегруза памяти, оставит исходный алгоритм практически в неизменном виде и даст мне универсальный экономичный способ построчной обработки файлов. Далее, если результат меня не удовлетворит я займусь менее универсальными оптимизациями типа обработки файла с конца.
Теперь я тебе задам вопрос. Давай прямо — для файла с заранее известным небольшим размером в пределах нескольких десятков килобайт и в местах не критичных по производительности — ты по-прежнему утверждаешь, что будешь заниматься выжиманием производительности? Да или нет ?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Полировка алгоритма даст тебе в лучшем случае проценты, а наращивание железа даёт легко разы. Но алгоритм при этом должен быть заточен для работы в таких условиях. Буржуи такое свойство алгоритма называют иностранным словом scalability — масштабируемость, расширяемость. И это свойство именно алгоритма, а не дополнительных ресурсов, как ты изволил выразиться.
Не знаю, что там буржуи делают, но если ты увеличиваешь ресурсы (железо и т.д.), то это называется именно увеличением ресурсов, а не оптимизацией программы. Покупая новые ресурсы, можно все что угодно усилить.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Давай прямо — для хотя бы 500 Мб файла — ты по-прежнему утверждаешь, что твое однострочное решение годится ? Да или нет ?
IT>И да и нет. Первым делом я попробую написать версию GetAllLines через перечислитель.
А зачем это делать-то ? Есть же просто ReadLine, вызывай ее в цикле до конца файла.
>Это снимет проблему перегруза памяти
так while — ReadLine это и так даст.
>оставит исходный алгоритм практически в неизменном виде
Во имя чего ?
>и даст мне универсальный экономичный способ построчной обработки файлов. Далее, если результат меня не удовлетворит я займусь менее универсальными оптимизациями типа обработки файла с конца.
Вот с этим соглашусь. И если бы ты с самого начала написал бы что-то вроде "при небольшом файле можно ReadAllLines, а иначе надо...", я бы просто сразу согласился, и не было бы темы дискуссии.
IT>Теперь я тебе задам вопрос. Давай прямо — для файла с заранее известным небольшим размером в пределах нескольких десятков килобайт и в местах не критичных по производительности — ты по-прежнему утверждаешь, что будешь заниматься выжиманием производительности? Да или нет ?
Конечно, нет, даже странно такой вопрос от тебя получить. Я же об этом сто раз писал. Вот, например
PD>Еще раз — истина конкретна. Под 1 Кб — нечего огород городить. Под 100 Мб — самый раз. Под 100 Гб — да, лучше иначе.
И в других местах писал, просто искать лень. Ты берешься опровергать мои высказывания, а ведь ты даже не поянл мою концепцию. А она проста
Я не сторонник универсальных решений. Я за то, чтобы решения принимались с учетом конкретной ситуации. Одна и та же задача (тот же парсинг файла, к примеру) может потребовать разных решений в зависимости от объема обрабатываемых данных, возможности или невозможности распараллеливания, требований к памяти, времени и т.д. И именно с учетом всех этих факторов ее и надо решать.
Да и вообще, если уж на то пошло
string GetLastLine(string fileName)
{
// ...
}
Вот тебе универсальное решение . Внутренности — по ситуации и задаче. Хочешь написать там ReadAllLines + Split — пиши. Надо иначе — перепишем ее иначе, остальной код никак не пострадает, даже если там внутри сначала появится энумератор, потом аккумулятор, а в конечном итоге трансформатор . Из-за чего шум-то весь ? Из-за чего такая гордость однострочным 10-секундным решением ? Только из-за того, что я еще одну строку написал и две фигурные скобки ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Еще раз. Быстродействие входит в число функциональных требований. При недостаточно высоком — решение просто не рассматривается.
F>>Не хотите статью на rsdn написать? Это новое слово в разработке требований.
PD>Этому новому слову лет так 50. Почитай, к примеру, про real-time приложения, если нет реакции за фиксированное время — решения нет.
Ухты! real-time приложения! Круто! Если "решения нет за фиксированное время — решения нет" верно, значит быстродействие входит в число функциональных требований. Если "я сегодня не завтракал" верно, то 2*2=5! Еще круче!
F>>И что, всегда требования производительности более важны, чем функции системы?
PD>А кто сказал, что функции не важны или менее важны ? Я ? Ссылку!
В том, что вы написали разобраться трудновато, то все же
PD>>У меня, конечно, не самолетное ПО, но идея та же самая. Риски там, правда, нулевые, ничего не грохнется, но недостаточно быстрые решения не рассматриваются. А для достаточно быстрого решения всегда макисма такая — сделайте еще быстрее, если можете.
Ну, вот перед вами 3 функции и требование чтобы никакая из них не выполнялась медленнее 2х секунд. Максима всегда такая, сделайте быстрее, если сможете. Т.е. пока вы окончательно не уперлись в предел своей квалификации, вы их не закончите? Заказчик спрашивает: "когда закончишь", а вы ему: "у нас есть еще 5 способов, которые могут повысить производительность на 2%". Заказчик: "О чём речь, делайте!"
>>Ну, типа, если есть хоть малейший шанс увеличить производительность, то мы ее увеличиваем, а не добавляем новые фичи?
PD>Зависит от задачи. Иногда новые фичи просто не нужны, а надо ускорить обработку.
А не могли бы отдельным постом в корне форума написать, как у вас обычно происходит разработка нового проекта, от идеи до развертывания? Видимо у вас очень специфический опыт, который идет в разрез с опытом подавляющего большинства
Здравствуйте, Flem1234, Вы писали:
F>Ухты! real-time приложения! Круто! Если "решения нет за фиксированное время — решения нет" верно, значит быстродействие входит в число функциональных требований. Если "я сегодня не завтракал" верно, то 2*2=5! Еще круче!
М-да... Если человек не хочет понять , что ему говорят — тут уже ничем не поможешь.
F>В том, что вы написали разобраться трудновато, то все же
PD>>>У меня, конечно, не самолетное ПО, но идея та же самая. Риски там, правда, нулевые, ничего не грохнется, но недостаточно быстрые решения не рассматриваются. А для достаточно быстрого решения всегда макисма такая — сделайте еще быстрее, если можете.
Все верно.
F>Ну, вот перед вами 3 функции и требование чтобы никакая из них не выполнялась медленнее 2х секунд. Максима всегда такая, сделайте быстрее, если сможете. Т.е. пока вы окончательно не уперлись в предел своей квалификации, вы их не закончите? Заказчик спрашивает: "когда закончишь", а вы ему: "у нас есть еще 5 способов, которые могут повысить производительность на 2%". Заказчик: "О чём речь, делайте!"
Похоже . Именно этим мы и занимаемся. Просто тебе не доводилось иметь дело с проектами такого рода, вот тебя и удивляет.
F>А не могли бы отдельным постом в корне форума написать, как у вас обычно происходит разработка нового проекта, от идеи до развертывания?
Нет, не буду .
>Видимо у вас очень специфический опыт, который идет в разрез с опытом подавляющего большинства
Да, это очень непохоже на разработку сайтов и т.п.
KV>Здесь Павел прав, если я правильно его понимаю. Требования к максимальному отклику тех или иных компонентов системы вполне могут быть внесены в функциональные требования в том случае, если их невыполнение делает ничтожными значительную часть функционала системы, либо если этот параметр определяет непосредственно функциональность системы (например, если система предоставляет функционал по взаимодействию сторонних систем в режиме реального времени).
Это даже и для realtime может быть верно. В сущности, требование по скорости присутствует практически всегда. Программа, решающая NP-полную задачу при N=1000, нефункциональна, что бы она не делала, так как увидеть ее функциональность никому не дано. Но и сайт, который дает ответ через 5 минут, тоже в большинстве случаев нефункционален, так как на него пользователь зайдет только один раз. А в других случаях вполне функционален. Вполне возможен web-севис, которому ставят в очередь задания, а он дает ответы через часы, потому что быстрее там не посчитаешь. Сам как-то принимал участие в такой разработке.
Другое дело, что это требование может быть не очень высоким , а поэтому незаметным для разработчика (все сойдет
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не знаю, что там буржуи делают, но если ты увеличиваешь ресурсы (железо и т.д.), то это называется именно увеличением ресурсов, а не оптимизацией программы. Покупая новые ресурсы, можно все что угодно усилить.
Это не так просто, как ты думаешь. Для интереса — можешь сам попробовать.
Здравствуйте, fmiracle, Вы писали:
F>Это не так просто, как ты думаешь. Для интереса — можешь сам попробовать.
А я и не говорил, что это просто. И пробовать мне не надо — я этим (распараллеливанием) в том числе и занимаюсь. Но это не имеет отношения к оптимизации алгоритма как такового. К примеру, мне удалось повысить его примерно в 3 раза, избавившись путем аналитических преобразований от квадратного корня, стоявшего в двойном цикле. Вот это решение — не зависит от ресурсов.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Еще раз. Быстродействие входит в число функциональных требований. При недостаточно высоком — решение просто не рассматривается. F>>Не хотите статью на rsdn написать? Это новое слово в разработке требований. PD>Этому новому слову лет так 50. Почитай, к примеру, про real-time приложения, если нет реакции за фиксированное время — решения нет.
Я тебе уже писал, что у тебя ошибка в том, что ты считаешь нефункциональные требования несущественными.
Это не так.
Система, не удовлетворяющая всему списку требований, не может быть принята в работу(*), вне зависимости от того, функциональные это требования или нефункциональные.
(*) — в некоторых случаях, если никак не удается уложиться в требования, могут быть пересмотрены требования, но сстема ве равно принимается когда она удовлетворяет всем требованиям.
Здравствуйте, fmiracle, Вы писали:
F>Я тебе уже писал, что у тебя ошибка в том, что ты считаешь нефункциональные требования несущественными. F>Это не так.
Где я такое утверждал ? Ссылку в студию.
F>Система, не удовлетворяющая всему списку требований, не может быть принята в работу(*), вне зависимости от того, функциональные это требования или нефункциональные.
Верно.
F>(*) — в некоторых случаях, если никак не удается уложиться в требования, могут быть пересмотрены требования, но сстема ве равно принимается когда она удовлетворяет всем требованиям.
Твое высказывание, если его перефразировать, звучит так. Система должна удовлетворять всем требованиям, но если она им не удовлетворяет, то требования иногда изменяют так, чтобы система им удовлетоворяла . Бывает, не спорю.
Выделено ниже — мной
'The 12 bugs of Christmas'
For the first bug of Christmas, my manager said to me
See if they can do it again.
For the second bug of Christmas, my manager said to me
Ask them how they did it and
See if they can do it again.
For the third bug of Christmas, my manager said to me
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the fourth bug of Christmas, my manager said to me
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the fifth bug of Christmas, my manager said to me
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the sixth bug of Christmas, my manager said to me
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the seventh bug of Christmas, my manager said to me
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the eighth bug of Christmas, my manager said to me
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the ninth bug of Christmas, my manager said to me
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the tenth bug of Christmas, my manager said to me Change the documentation
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the eleventh bug of Christmas, my manager said to me Say it's not supported
Change the documentation
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the twelfth bug of Christmas, my manager said to me Tell them it's a feature
Say it's not supported
Change the documentation
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>оставит исходный алгоритм практически в неизменном виде PD>Во имя чего ?
Во имя простоты и гибкости кода.
IT>>Теперь я тебе задам вопрос. Давай прямо — для файла с заранее известным небольшим размером в пределах нескольких десятков килобайт и в местах не критичных по производительности — ты по-прежнему утверждаешь, что будешь заниматься выжиманием производительности? Да или нет ?
PD>Конечно, нет, даже странно такой вопрос от тебя получить. Я же об этом сто раз писал. Вот, например PD>http://rsdn.ru/forum/philosophy/3605179.1.aspx
И как ты решишь задачу для небольшого файла.
PD>И в других местах писал, просто искать лень. Ты берешься опровергать мои высказывания, а ведь ты даже не поянл мою концепцию. А она проста
PD>Я не сторонник универсальных решений. Я за то, чтобы решения принимались с учетом конкретной ситуации. Одна и та же задача (тот же парсинг файла, к примеру) может потребовать разных решений в зависимости от объема обрабатываемых данных, возможности или невозможности распараллеливания, требований к памяти, времени и т.д. И именно с учетом всех этих факторов ее и надо решать.
Эта твоя концепция ущербна тем, что в ней не детерминирована величина объёма данных и каждый может это понимать по своему. Тем не менее универсальное решение найти можно для гораздо большего диапазана задач, чем тебе кажется, а для ещё большего диапазона универсальное решение может оказаться вполне приемлемым.
Мне доводилось в своё время заниматься обработкой гигабайтных файлов в реальных задачах. Так вот, по-быстрому написанный парсиг файла у меня занимал порядка 20 секунд. Медленно? Медленно. Но по-быстрому написанная последующая обработка полученных данных занимала больше суток. После всех оптимизаций удалось ужать это время до 40-ка минут. Как ты думаешь, если бы я занялся оптимизацией скорости парсинга, мне бы это сильно помогло?
PD>Да и вообще, если уж на то пошло
PD>string GetLastLine(string fileName) PD>{ PD>// ... PD>}
А теперь подумай, почему Майкрософт не вглючила такую замечательную функция во фреймворк.
PD>Вот тебе универсальное решение . Внутренности — по ситуации и задаче. Хочешь написать там ReadAllLines + Split — пиши. Надо иначе — перепишем ее иначе, остальной код никак не пострадает, даже если там внутри сначала появится энумератор, потом аккумулятор, а в конечном итоге трансформатор . Из-за чего шум-то весь ? Из-за чего такая гордость однострочным 10-секундным решением ? Только из-за того, что я еще одну строку написал и две фигурные скобки ?
А, вот ты о чём. Тогда понятно. Тебе нужно покурить хотя бы вот эту
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Pavel Dvorkin, Вы писали:
>>>оставит исходный алгоритм практически в неизменном виде PD>>Во имя чего ?
IT>Во имя простоты и гибкости кода.
Слишком дорогая плата. ИМХО.
IT>>>Теперь я тебе задам вопрос. Давай прямо — для файла с заранее известным небольшим размером в пределах нескольких десятков килобайт и в местах не критичных по производительности — ты по-прежнему утверждаешь, что будешь заниматься выжиманием производительности? Да или нет ?
PD>>Конечно, нет, даже странно такой вопрос от тебя получить. Я же об этом сто раз писал. Вот, например PD>>http://rsdn.ru/forum/philosophy/3605179.1.aspx
ReadAllLines, конечно, не будет, тем более что и ни к чему их все куда-то в ОП заносить. Читать до конца, взять последнюю строчку...
PD>>Я не сторонник универсальных решений. Я за то, чтобы решения принимались с учетом конкретной ситуации. Одна и та же задача (тот же парсинг файла, к примеру) может потребовать разных решений в зависимости от объема обрабатываемых данных, возможности или невозможности распараллеливания, требований к памяти, времени и т.д. И именно с учетом всех этих факторов ее и надо решать.
IT>Эта твоя концепция ущербна тем, что в ней не детерминирована величина объёма данных и каждый может это понимать по своему.
Если его квалификация высокая, то поймет правильно. А если нет — может, хоть задумается над своми универсальными решениями. Хоть мысль в голову придет — а не делаю ли я во много раз хуже, не подумав как следует, а применив универсальное решение, которое, может быть, именно здесь и не подходит.
>Тем не менее универсальное решение найти можно для гораздо большего диапазана задач, чем тебе кажется, а для ещё большего диапазона универсальное решение может оказаться вполне приемлемым.
Что мне кажется и что не кажется — ты знать не можешь . А по сущетсву —
1. Да, найти можно
2. Да, может оказаться приемлемым
Как видишь, я с тобой согласен. Но
3. Необходимо оценить, является ли оно приемлемым.
Если п.3 проходит, при любых (разумных) предположениях об изменениии данных — а почему бы и нет ? Но это доказать надо! Хотя бы самому себе.
IT>Мне доводилось в своё время заниматься обработкой гигабайтных файлов в реальных задачах. Так вот, по-быстрому написанный парсиг файла у меня занимал порядка 20 секунд. Медленно? Медленно.
Не знаю. Может, очень медленно, а может, очень быстро. Гигабайтные — это 1 Гб или несколько, это, как понимаешь, не все равно. Что за парсинг — ты не сообщил. Так что медленно или нет — судить не могу. Ты сам сказал, что медленно.
>Но по-быстрому написанная последующая обработка полученных данных занимала больше суток. После всех оптимизаций удалось ужать это время до 40-ка минут. Как ты думаешь, если бы я занялся оптимизацией скорости парсинга, мне бы это сильно помогло?
Скорее всего нет. Но опять же я прав — истина конкретна. Иногда нужно пренебречь неэффективностью из-за того, что писать эффективно здесь не имеет смысла по разным причинам. Иногда надо выжимать все, что можно.
PD>>Да и вообще, если уж на то пошло
PD>>string GetLastLine(string fileName) PD>>{ PD>>// ... PD>>}
IT>А теперь подумай, почему Майкрософт не вглючила такую замечательную функция во фреймворк.
Ну не смеши. Если бы уж включать, то
string GetLine(string fileName, int number)
Эта функция бы вполне могла пригодиться. А GetLastLine просто почти никому не нужна, кроме топикстартера в том топике.
Но и GetLine они не включили. А вот теперь к тебе вопрос — почему ? Вот есть TextReader, в нем ReadLine следующую есть, а по номеру — нет.
PD>>Вот тебе универсальное решение . Внутренности — по ситуации и задаче. Хочешь написать там ReadAllLines + Split — пиши. Надо иначе — перепишем ее иначе, остальной код никак не пострадает, даже если там внутри сначала появится энумератор, потом аккумулятор, а в конечном итоге трансформатор . Из-за чего шум-то весь ? Из-за чего такая гордость однострочным 10-секундным решением ? Только из-за того, что я еще одну строку написал и две фигурные скобки ?
IT>А, вот ты о чём. Тогда понятно. Тебе нужно покурить хотя бы вот эту
P.S. В институтах такому точно не учат. Ты еще пока не классик, чтобы твое личное мнение было необходимо изучать. Кстати, и рекомендовать свои собственные рассуждения для обязательного прочтения ("Тебе нужно покурить") как бы это сказать... не совсем этично. Рекомендовать можно что-то не свое, а твои статьи пусть кто-то другой порекомендует, если сочтет стоящим того.
With best regards
Pavel Dvorkin
Re[2]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, CreatorCray, Вы писали:
CC>Я совершенно разделяю возмущение по поводу описанной баги, но не вижу необходимости в тотальном запрете инструмента только потому, что далеко не все умеют им безопасно пользоваться.
Да бредовый пример, который конкретно к С/С++ никаким боком. Такой же ляп можно создать на большинстве современного мейнстрима и даже на обоих версиях VB.
Здравствуйте, IT, Вы писали:
IT>Типичное заблуждение. Всё что угодно усилить можно только бесконечно усиливая возможности одной единственной железки.
А также более эффективным способом используя эту самую железку. Или ты считаешь такое в принципе неверным путем ? А почему, собственно ? Если я смогу при том же железе вычислять в 2 раза быстрее, чем сейчас, то мне понадобится в 2 раза меньше железок. И что тут плохого ?
>Но эта величина у нас ограничена. Масштабирование — это как раз и есть оптимизация твоей программы для работы в распределённой среде.
Еще раз — я веду речь про оптимизацию при данных ресурсах. При увеличении числа ресурсов скорость возрастет, это ежу понятно, пусть не в N раз, но возрастет. Ты вот, не покупая новые ресурсы сделай, тогда и хвались.
Вот есть у тебя, к примеру, грузовик. На нем можно перевезти, скажем, домашнюю мебель. Если ее аккуратно поставить, то за одну поездку раз можно, а если валом валить, то за 3 поездки получится. А ты предлагаешь — давайте валом валить, но купим еще 2 грузовика.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Еще раз — я веду речь про оптимизацию при данных ресурсах. При увеличении числа ресурсов скорость возрастет, это ежу понятно, пусть не в N раз, но возрастет.
Ежу, конечно, понятно, но на самом деле это не так. Точнее — далеко не всегда так. Очень сильно зависит от того, как написана программа. Скорость может просто не увеличиться (очень распространенный случай), а может и (хо-хо) серьезно замедлиться.
Это если мы по-прежнему говорим про распараллеливание по различным машинам (или хотя бы процессорам в одной машине). В рамках нарастания мощностей одной однопроцессорной одноядерной машины все, конечно, шоколадно, но к потолку их возможностей мы уже подошли.
Здравствуйте, fmiracle, Вы писали:
PD>>Еще раз — я веду речь про оптимизацию при данных ресурсах. При увеличении числа ресурсов скорость возрастет, это ежу понятно, пусть не в N раз, но возрастет.
F>Ежу, конечно, понятно, но на самом деле это не так. Точнее — далеко не всегда так. Очень сильно зависит от того, как написана программа. Скорость может просто не увеличиться (очень распространенный случай), а может и (хо-хо) серьезно замедлиться.
Совершенно верно. Однако если программа написана так. что при увеличении количества ресурсов ее скорость не увеличивается — под сомнением компетентность автора. В N раз она может не увеличиться, но в общем, должна.
F>Это если мы по-прежнему говорим про распараллеливание по различным машинам (или хотя бы процессорам в одной машине). В рамках нарастания мощностей одной однопроцессорной одноядерной машины все, конечно, шоколадно, но к потолку их возможностей мы уже подошли.
Смотря где и смотря в чем. Все не так просто. Например, если скорость лимитируется работой с диском, и можно уменьшить объем обмениваемых данных за счет их более рациональной организации, то можно выиграть прилично. Можно косвенно влиять на количество page faults за счет более продуманного алгоритма, меньше будет свопинга. И т.д.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Во имя чего ? IT>>Во имя простоты и гибкости кода. PD>Слишком дорогая плата. ИМХО.
Ну здрасте. Слишком дорогая плата — это пол процента производительности за раздутый всеми возможными оптимизациями код. А простота и гибкость очень быстро окупаются.
IT>>И как ты решишь задачу для небольшого файла. PD>ReadAllLines, конечно, не будет, тем более что и ни к чему их все куда-то в ОП заносить. Читать до конца, взять последнюю строчку...
Т.е. цикл, проверка символа возврата коретки, сохранение последней найденной позиции, откат к ней, опять читаем до конца... В общем императивного кода на порядок больше. В 10 секунд не уложишься.
IT>>Эта твоя концепция ущербна тем, что в ней не детерминирована величина объёма данных и каждый может это понимать по своему. PD>Если его квалификация высокая, то поймет правильно. А если нет — может, хоть задумается над своми универсальными решениями. Хоть мысль в голову придет — а не делаю ли я во много раз хуже, не подумав как следует, а применив универсальное решение, которое, может быть, именно здесь и не подходит.
Ты говоришь об одном проценте случаев, причём эти случаи видны из далека, как правило ещё на этапе проектирования.
PD>Как видишь, я с тобой согласен. Но PD>3. Необходимо оценить, является ли оно приемлемым.
Ну оцени, в чём проблема? Это сделать совсем не сложно при условии внятной постановки задачи.
IT>>Мне доводилось в своё время заниматься обработкой гигабайтных файлов в реальных задачах. Так вот, по-быстрому написанный парсиг файла у меня занимал порядка 20 секунд. Медленно? Медленно.
PD>Не знаю. Может, очень медленно, а может, очень быстро. Гигабайтные — это 1 Гб или несколько, это, как понимаешь, не все равно. Что за парсинг — ты не сообщил. Так что медленно или нет — судить не могу. Ты сам сказал, что медленно.
Я тебе сообщил другую, гораздо более важную вещь — скорость в рамках решения всей задачи оказалась более чем приемлемой. Неужели это тебе до сих пор не понятно?
>>Но по-быстрому написанная последующая обработка полученных данных занимала больше суток. После всех оптимизаций удалось ужать это время до 40-ка минут. Как ты думаешь, если бы я занялся оптимизацией скорости парсинга, мне бы это сильно помогло?
PD>Скорее всего нет. Но опять же я прав — истина конкретна. Иногда нужно пренебречь неэффективностью из-за того, что писать эффективно здесь не имеет смысла по разным причинам. Иногда надо выжимать все, что можно.
Вообще-то, ты при любом удобном случае утверждаешь совсем другое — не иногда, а всегда надо выжимать всё, что можно. Но то, что ты сейчас сказал я занесу в избранное, как раз для того, чтобы тебе об этом в дальнейшем по-чаще напоминать.
PD>>>Да и вообще, если уж на то пошло
PD>>>string GetLastLine(string fileName) PD>>>{ PD>>>// ... PD>>>}
IT>>А теперь подумай, почему Майкрософт не вглючила такую замечательную функция во фреймворк. PD>Ну не смеши. Если бы уж включать, то PD>string GetLine(string fileName, int number) PD>Эта функция бы вполне могла пригодиться. А GetLastLine просто почти никому не нужна, кроме топикстартера в том топике. PD>Но и GetLine они не включили. А вот теперь к тебе вопрос — почему ? Вот есть TextReader, в нем ReadLine следующую есть, а по номеру — нет.
По той же причине, по которой я тебя рассмешил — это нафиг никому не надо, а кому вдруг ну очень сильно понадобиться делается за три минуты на коленке.
IT>>А, вот ты о чём. Тогда понятно. Тебе нужно покурить хотя бы вот эту
статью. Жаль, что этому в институтах не учат. В вашем наверняка тоже нет.
PD>Батенька, у тебя просто память отказывает. Мне ее курить не надо, я ее прекрасно помню и свои возражения на нее тоже.
PD>P.S. В институтах такому точно не учат. Ты еще пока не классик, чтобы твое личное мнение было необходимо изучать. Кстати, и рекомендовать свои собственные рассуждения для обязательного прочтения ("Тебе нужно покурить") как бы это сказать... не совсем этично. Рекомендовать можно что-то не свое, а твои статьи пусть кто-то другой порекомендует, если сочтет стоящим того.
Я не рекомендую, я даю ссылку и предлагаю хоть немного задуматься, т.е. "покурить" написанное. При вдумчивом, неспешном прочтении и длительном размышлении над прочитанным обещаю просветление, после которого советы оптимизировать всё и вся покинут тебя навсегда.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Типичное заблуждение. Всё что угодно усилить можно только бесконечно усиливая возможности одной единственной железки.
PD>А также более эффективным способом используя эту самую железку. Или ты считаешь такое в принципе неверным путем ? А почему, собственно ? Если я смогу при том же железе вычислять в 2 раза быстрее, чем сейчас, то мне понадобится в 2 раза меньше железок. И что тут плохого ?
Ну увеличил ты в два раза, что дальше? После этого увеличишь в 0.2 раза, а потом в 0.02 раза, а потом в 0.002 раза? Каждое новое увеличение будет на порядок меньше, а стоить будет на порядок дороже. С масштабированием стоимость увеличения равна стоимости железа.
PD>Еще раз — я веду речь про оптимизацию при данных ресурсах. При увеличении числа ресурсов скорость возрастет, это ежу понятно, пусть не в N раз, но возрастет. Ты вот, не покупая новые ресурсы сделай, тогда и хвались.
Я? Похвалиться? Да скока угодно. Смотрим внимательно сюда.
На картинке результаты теста производительности ORM tools.
Весь зелёненький, чемпион в лёгком и тяжёлом весе — BLToolkit, самый быстрый ORM в мире. Моя работа с сотоварищами. Как видишь инструменты от MS, NH и пр. тихо покуривают в сторонке.
А ты можешь чем нибудь похвалиться?
Впрочем, можешь не отвечать. Пиписькомерство мне не интересно. Даже делая самые производительные инструменты, я настаиваю на том, что преждевременные оптимизации, о которых ты не устаёшь повторять вновь и вновь — это зло.
PD>Вот есть у тебя, к примеру, грузовик. На нем можно перевезти, скажем, домашнюю мебель. Если ее аккуратно поставить, то за одну поездку раз можно, а если валом валить, то за 3 поездки получится. А ты предлагаешь — давайте валом валить, но купим еще 2 грузовика.
Тебе, конечно, виднее. Но я предпочитаю доверять перевозку моей мебели профессионалам, а не любителям.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, vdimas, Вы писали:
V>Да бредовый пример, который конкретно к С/С++ никаким боком. Такой же ляп можно создать на большинстве современного мейнстрима и даже на обоих версиях VB.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Pavel Dvorkin, Вы писали:
IT>Ну здрасте. Слишком дорогая плата — это пол процента производительности за раздутый всеми возможными оптимизациями код. А простота и гибкость очень быстро окупаются.
Полпроцента — да. Ну а как насчет 3300%, которые имели место в примере с чтением последней строки ?
IT>>>И как ты решишь задачу для небольшого файла. PD>>ReadAllLines, конечно, не будет, тем более что и ни к чему их все куда-то в ОП заносить. Читать до конца, взять последнюю строчку...
IT>Т.е. цикл, проверка символа возврата коретки, сохранение последней найденной позиции, откат к ней, опять читаем до конца...
Зачем ? Буфер фиксированного размера, превышающий разумный размер строки. Например, char a[1024]; Читаем fgets всю строку и проверяем, поместилась ли она. Скорее всего поместилась, если это нормальный человеком сделанный текстовый файл. Ну а если нет — расширяем буфер и дочитываем, если надо — повторяем.
>В общем императивного кода на порядок больше. В 10 секунд не уложишься.
В 10 секунд — не уложишься, верно. А зачем мне в 10 секунд ?
IT>>>Эта твоя концепция ущербна тем, что в ней не детерминирована величина объёма данных и каждый может это понимать по своему. PD>>Если его квалификация высокая, то поймет правильно. А если нет — может, хоть задумается над своми универсальными решениями. Хоть мысль в голову придет — а не делаю ли я во много раз хуже, не подумав как следует, а применив универсальное решение, которое, может быть, именно здесь и не подходит.
IT>Ты говоришь об одном проценте случаев, причём эти случаи видны из далека, как правило ещё на этапе проектирования.
Хорошо, если так.
PD>>Как видишь, я с тобой согласен. Но PD>>3. Необходимо оценить, является ли оно приемлемым.
IT>Ну оцени, в чём проблема? Это сделать совсем не сложно при условии внятной постановки задачи.
Проблема всегда конкретна. Когда будет задача — тогда ее и оценим. В чем проблема длдя сфероконя — я не знаю.
IT>Я тебе сообщил другую, гораздо более важную вещь — скорость в рамках решения всей задачи оказалась более чем приемлемой. Неужели это тебе до сих пор не понятно?
Да почему же непонятно, вполне понятно, и я тут с тобой согласен.
У меня такое впечатление, что дискутируешь ты не со мной, а каким-то вымышленным оппонентом, который требует оптимизировать все и вся, независимо от условий. Это не я. Я вовсе этого не предлагаю. Я именно предлагаю делать применительно к условиям, и именно поэтому мне твое решение с ReadAllLines не нравится как универсальное. В определенных частных случаях оно вполне сойдет.
IT> IT>Вообще-то, ты при любом удобном случае утверждаешь совсем другое — не иногда, а всегда надо выжимать всё, что можно. Но то, что ты сейчас сказал я занесу в избранное, как раз для того, чтобы тебе об этом в дальнейшем по-чаще напоминать.
Занеси. А также дай, пожалуйста, ссылку, где именно я предлагаю всегда выжимать все, что можно. А я тебе для начала контрссылку дам.
PD>Поймите меня правильно. Это вовсе не значит, что мы оптимизировали все и вся. Код, который работает 0.1 сек и занимает 100 байт, никто не оптимизировал. И то, что оптимизировать нужно самые внутренние циклы, мы прекрасно знали. Не об этом речь. А о том, что при написании программ была определенная культура, требовавшая памятью не сорить без надобности, первый попавшийся алгоритм не применять, а искать хороший, ну и т.д.
и с тех пор в этом плане мои воззрения не изменились.
PD>>>>Да и вообще, если уж на то пошло
PD>>Но и GetLine они не включили. А вот теперь к тебе вопрос — почему ? Вот есть TextReader, в нем ReadLine следующую есть, а по номеру — нет.
IT>По той же причине, по которой я тебя рассмешил — это нафиг никому не надо, а кому вдруг ну очень сильно понадобиться делается за три минуты на коленке.
Нет. Это как раз многим надо. Возможность читать из текстового файла строку с произвольным номером была бы вполне кстати.
А не включили они по другой причине. У этой задачи нет хорошего универсального решения. Прочитать следующую строку — это понятно, делается единственным способом. Прочитать все строки — это тоже понятно, раз уж все — так все, тут тоже вариантов нет. А вот прочитать строку по номеру — если они ReadAlLines с возратом одной бы написали, их бы на смех подняли. Другие способы — тоже не всегда хорошо.
IT>>>А, вот ты о чём. Тогда понятно. Тебе нужно покурить хотя бы вот эту
статью. Жаль, что этому в институтах не учат. В вашем наверняка тоже нет.
PD>>Батенька, у тебя просто память отказывает. Мне ее курить не надо, я ее прекрасно помню и свои возражения на нее тоже.
IT>Это не надо помнить, это надо понимать. Или хотя бы пытаться.
IT>Я не рекомендую, я даю ссылку и предлагаю хоть немного задуматься, т.е. "покурить" написанное. При вдумчивом, неспешном прочтении и длительном размышлении над прочитанным обещаю просветление, после которого советы оптимизировать всё и вся покинут тебя навсегда.
При внимательном чтении моих опусов я тебе тоже обещаю просветление на предмет того, что ты воюешь с воображаемым оппонентом, а вовсе не со мной.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Ну здрасте. Слишком дорогая плата — это пол процента производительности за раздутый всеми возможными оптимизациями код. А простота и гибкость очень быстро окупаются. PD>Полпроцента — да. Ну а как насчет 3300%, которые имели место в примере с чтением последней строки ?
Если чтение последней строки является вторичной функциональностью и никак не влияет на производительность приложения, то я выберу вариант, которые проще и гибче, а не быстрее.
>>В общем императивного кода на порядок больше. В 10 секунд не уложишься. PD>В 10 секунд — не уложишься, верно. А зачем мне в 10 секунд ?
А зачем мне в 33 раза быстрее?
IT>>Это не надо помнить, это надо понимать. Или хотя бы пытаться. PD>А ты вообще допускаешь, что у кого-то может быть иное мнение ?
Может, но в обсуждении я что-то других мнений не увидел. В основном претензии к названию статьи.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>С масштабированием стоимость увеличения равна стоимости железа.
PD>Верно. А с оптимизацией порой равно 0 (нулю)
Не нулю, а зарплате программистов умноженной на потраченное на разработку и сопровождение время. А теперь прикинь сколько это будет стоить, учитывая, что каждое следующее увеличение производительности в два раза займёт у тебя на порядок больше времени, чем в предыдущий.
PD>И будет тебе в результате совершенно бесплатное увеличение скорости. Без покупки ресурсов.
А что потом? Как дальше увеличивать производительность?
PD>Но все же это не то, о чем я спросил. Здесь сравнение с другими продуктами, а я говорил про увеличение быстродействия данного продукта без покупки новых ресурсов.
Так всё как раз началось с увеличения бысродействия данного продукта. Или ты думаешь он сразу таким уродился? Сначала была простая версия, написанная за неделю, работающая через рефлекшин. Оказалось медленно. Далее начались игры с генерацией кода, устранение боксинга, подгонка кода под jit onlining и т.п.
IT>>А ты можешь чем нибудь похвалиться? PD>Могу. Честное слово. . Но я уже не раз писал — здесь я обсуждать тематику своей работы не буду. Так что извини.
Ну да. Атомные станции, космические полёты, шпионские страсти. Понимаю.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
PD>>Полпроцента — да. Ну а как насчет 3300%, которые имели место в примере с чтением последней строки ?
IT>Если чтение последней строки является вторичной функциональностью и никак не влияет на производительность приложения, то я выберу вариант, которые проще и гибче, а не быстрее.
Вполне согласен.
>>>В общем императивного кода на порядок больше. В 10 секунд не уложишься. PD>>В 10 секунд — не уложишься, верно. А зачем мне в 10 секунд ?
IT>А зачем мне в 33 раза быстрее?
А не о тебе речь. Ты же не себе совет давал, а кому-то другому.
Здравствуйте, IT, Вы писали:
PD>>Верно. А с оптимизацией порой равно 0 (нулю)
IT>Не нулю, а зарплате программистов умноженной на потраченное на разработку и сопровождение время.
И чему же это равно в том примере с матрицами, который я привел и на который ты ответить не решился.
>А теперь прикинь сколько это будет стоить, учитывая, что каждое следующее увеличение производительности в два раза займёт у тебя на порядок больше времени, чем в предыдущий.
А о следующем речь не идет. Речь идет о том. что надо писать наиболее эффективно при данном железе. Взять от него то, что можно. Вот и все. А остальное само собой. Пусть эти матрицы складываются так быстро, как можно при этом железе. А потом посчитаем, сколько машин (ядер) надо для того, чтобы обеспечить нужную суммарную производительность. Может, и одной хватит, может, и 1000 понадобится.
PD>>И будет тебе в результате совершенно бесплатное увеличение скорости. Без покупки ресурсов.
IT>А что потом? Как дальше увеличивать производительность?
Естественно, возможности оптимизации имеют предел, определяемый возможностями железа. И никто не отменяет тот факт. что для решения той или иной задачи одной машины будет недостаточно. Может, придется купить много машин. Но это никак не оправдывает то, что возможности данной машины используются на 25%.
PD>>Но все же это не то, о чем я спросил. Здесь сравнение с другими продуктами, а я говорил про увеличение быстродействия данного продукта без покупки новых ресурсов.
IT>Так всё как раз началось с увеличения бысродействия данного продукта. Или ты думаешь он сразу таким уродился? Сначала была простая версия, написанная за неделю, работающая через рефлекшин. Оказалось медленно. Далее начались игры с генерацией кода, устранение боксинга, подгонка кода под jit onlining и т.п.
Понимаю. Наверное, ты прав.
IT>>>А ты можешь чем нибудь похвалиться? PD>>Могу. Честное слово. . Но я уже не раз писал — здесь я обсуждать тематику своей работы не буду. Так что извини.
IT>Ну да. Атомные станции, космические полёты, шпионские страсти. Понимаю.
Не угадал. Все намного прозаичнее и сугубо гражданское. Но все равно рассказывать не буду
Здравствуйте, IT, Вы писали:
PD>>Но все же это не то, о чем я спросил. Здесь сравнение с другими продуктами, а я говорил про увеличение быстродействия данного продукта без покупки новых ресурсов.
IT>Так всё как раз началось с увеличения бысродействия данного продукта.
Ты не понимаешь. Дворкин практически прямо заявляет, что ему важен процесс, а не результат. Та же история и с масштабированием по нескольким машинам — неважно, что результат достигнут, главное что оптимизациев нету.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
Здравствуйте, fddima, Вы писали:
KV>>>Ты так говоришь, как будто ее возможно у вас отобрать CC>>Просто не хочется очередной холивор "что-то vs C(или C++)" F> Вопрос стоял иначе, и отбирай-не отбирай — знай-не знай этот инструмент, — как показывает практика, подобные ошибки будут всегда. Вопрос наверное в том — как с ними бороться?
борцы с этим практически всегда начинают сетовать на кривые руки пользователей-разработчиков.
— мы сделали мега инструмент, но мы не виноваты что кривые руки...
Явно или не явно, такая мысль проскакивает например у адептов С++, Линукса и даже местных немерлистов.
С этим бороться не нужно, это будт борьбы с прогрессом.
Правильный инструмент он
1. увеличивает производительность девелопера
2. уменьшает требования к квалификации девелопера
3. позволяет ввести разделение труда
т.е. все сводится к трехвекторному удешевлению разработки через увеличение производительности, вовлечения необученых масс, вовлечении экспертов например по предметной области
Аргумент "кривые руки" появляет тогда, когда психика Творца или Адепта не выдерживает критики по п. 1, 2 и 3.
"Кривые руки" это такое неявное признание, что инструмент вобщем то слабоват.
Взять тот же Лисп. Почему он во все врема распространен на грани стат-погрешности ?
потому как
1. +
2. —
3. —
Почему, например, Лисп плохо распространяется ? потому что он требует для освоения довольно высокой квалификации. А это значит, что ВУЗам, предприятиям просто не хватит таковых. Ладно бы предприятиям. Такой язык можно преподавать только людям вроде Пола Грехема.
На примере физики — было бы очень интересно посмотреть на результаты школьников, если бы физику мог преподавать только Капица какой
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И вообще должен сказать, что до появления .NET этому вопросу (выход индекса), как бы это помягче сказать и никого не обидеть... не уделялось слишком большого внимания при обсуждении проблем программирования. Выходят у тебя индексы — исправь, что надо, а оповещать весь мир об этом как-то считалось дурным тоном и признаком невысокой квалификации. А тут из мухи сделали слона. Да и вообще, что такое выход индекса ? Это логическая ошибка, это неверное вычисление функции (в широком смысле слова). Одна из многих возможных логических ошибок. Что в формуле для корней вместо минуса плюс поставить, что в массиве из n обратиться к n-му элементу.
Тут проблема не в том, что переполнение буфера является логической ошибкой. Если бы это было просто логической ошибкой — то наоборот, чем быстрее проявится, тем лучше (быстрее поправят). Более важно то, что такие ошибки могут приводить к уязвимостям в программах, которые могут быть поюзаны злобными хакерами с целью вызвать Deny of service или выполнить шеллкод от имени программы.
Re: Павлу Дворкину: о понимании того что делаешь и простых п
Ну тут мы какбы имеем плохо написанную мультипоточность. Мультипоточность штука сложная, учиться ее программировать долго. Человек который это писал не очень хорошо умел программировать мультипоточность. Рейс он бы получил и на C#, и на Java. Это не зависит от используемый для разработки среды.
PD>Господь с тобой, какая тут СУБД. Чтобы взять из файла любой длины последнюю строчку, совсем не надо все остальное читать. Надо именно последнюю строчку.
а можно ссылку на оригинальное задание про последнюю строку?
Кэр>Судя по тому, как упорно вы настаиваете на этом — с заказчиками вы общаетесь крайне редко.
Ну это обсуждать не стоит.
>Я не встретил в своей практике еще ни одного, который бы упоминал скорость в разговоре о требованиях к программе.
Это лишь означает, что Вам не доводилось иметь дело с разработкой ПО такого рода.
>Скорость всегда нужна достаточная. Не максимально возможная, а достаточная.Даже когда есть четкое требование по производительности, то оно формулируется четко, например: SLA сервиса — ответ в пределах 0,25 мс для 95% запросов. Если таких четких требований нет — значит у вас проблемы, потому что вы их сформулировать не в состоянии, работая с заказчиком.
У меня никаких проблем нет, а требование максимальной скорости выдвинуто заказчиком, с которым я работаю почти 10 лет. Обсуждать характер моей работы я здесь не буду.
Кэр>Более того, нет смысла просто полировать один кусочек программы, скажем с 0,105 мс до 0,02 мс, если все упирается в коннект к базе данных, который занимает 0,9 мс.
Представьте себе, есть. Мне заказчик как-то выразил благодарность за то, что я ускорил быстродействие на 1%.
>Даже сфереконические пользователи не оценят ваших потугов в полировке маленького кусочка, пока программа будет ждать ответа от БД.
А пользователей (в обычном смысле) у ПО, которое я разрабатываю, нет вообще. Пакетная обработка в полностью автоматическом режиме.
Кэр>Более того, производительность программы не дается бесплатно. Практически всегда более быстрый алгоритм в данном месте означает более запутанный и трудно-поддерживаемый код.
А это в данном случае мало кого волнует. По крайней мере заказчик на это не жаловался и никаких требований на этот счет не выдвигал.
>Это означает что производительность нужно очень осторожно дозировать — есть риск резко снизить эффективность работы с кодом. Что дает отличный шанс конкурентам, которые могут быть гораздо умнее в этом плане.
А конкурентов нет и быть не может
Кэр>Это же очень простые утверждения — как их можно не понимать?
Надеюсь, я кое-что объяснил ? Если так и осталось неясным, то краткое резюме — задачи бывают разными. Из того факта, что Вам не приходилось сталкиваться с задачами и заказчиками, которые требуют совсем иного подхода, нежели привычный Вам — не следует, что таких задач нет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А конкурентов нет и быть не может
Ну так с этого и нужно было начинать. Собственно этим можно было и закончить. Если вы не утверджаете, что все ваши утверждения применимы к большей части разработки программного обеспечения, а только имеют смысл в рамках этого вашего конкретного проекта — то бог с вами.
Да не вопрос Но мое мнение от этого не изменится
PD>Я бы так сказал — к некоторому множеству проектов. Поймите одну простую вещь — мир программирования не сводится ни к web-программированию, ни вообще к той его части, для которой Вы в предыдущем письме столь настойчиво проповедывали в общем-то, справедливые для этой части идеи. Мир большой, и в нем есть всякое — как то, что соответствует Вашим представлениям, так и то, что им безусловно противоречит. Ну а каково процентное соотношение этих частей — это не так уж важно. Сегодня оно одно, завтра другое, а послезавтра вообще что-то иначе будет
Понятно, что есть не Евклидовы пространства и там параллельные прямые имеют свойство пересекаться. Просто подходы проповедуемые вами — загубят почти любой боевой проект. Да есть ненулевое подмножество проектов, где подобные принципы могут быть чем-то оправданы. Но размеры его будут очень небольшие. А причины обоснованности этих подходов почти всегда будут нетехническими (вот только не надо опять про сэкономленные лицензии — цена этой экономии слишком уж большая).
Но тогда к вашим утверждениям сформулированном в самой начале этой темы нужно добавить эти ограничения накладываемые на проект. Причем не припиской мелким текстом в подвале темы, а в самом начале большими красными мигающими буквами. Потому что изначально они выглядели как указания к разработке стандартных проектов, чем они являться не могут в принципе. Собственно из-за этого противоречия тут великий срач и поднялся.
Здравствуйте, Кэр, Вы писали:
Кэр>Понятно, что есть не Евклидовы пространства и там параллельные прямые имеют свойство пересекаться. Просто подходы проповедуемые вами — загубят почти любой боевой проект.
Из того множества проектов, о которых Вы так печетесь — может и да. Может, и нет. Но почему Вы решили, что я проповедую свой подход именно для них ?
>Да есть ненулевое подмножество проектов, где подобные принципы могут быть чем-то оправданы. Но размеры его будут очень небольшие.
Еще раз — не стоит в процентах измерять эти множества. Это как грибы — чтобы наполнить корзину, хватит десятка белых, а опят понадобятся сотни.
>А причины обоснованности этих подходов почти всегда будут нетехническими (вот только не надо опять про сэкономленные лицензии — цена этой экономии слишком уж большая).
Не знаю, какие там нетехнические причины, и чем отличаются технические от нетехнических, но причины были и есть.
Кэр>Но тогда к вашим утверждениям сформулированном в самой начале этой темы нужно добавить эти ограничения накладываемые на проект.
А я же и так не раз говорил — есть разные задачи, и для них разные принципы.
>Причем не припиской мелким текстом в подвале темы,
Мелким текстом — это как ? Я вообще-то размерами шрифта здесь не балуюсь
>а в самом начале большими красными мигающими буквами. Потому что изначально они выглядели как указания к разработке стандартных проектов
Здравствуйте, Cyberax, Вы писали:
C>В нём мало смысла просто. На карте-то выполняется небезопасный код.
Не понял проблемы. На CPU тоже выполняется "небезопасный код". Просто он порождается из безопасного, благодаря чему всё становится здорово. Не вижу никаких причин не применить это для КУДЫ.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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 будет обращаться к концу отмапленной области.
Основная сложность будет в том, чтобы аккуратно работать с файлами "слишком большого" размера, чтобы не исчерпать адресное пространство раньше времени.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали: C>Не получится. В КУДЕ точно так же идёт работа с указателями. С помощью них можно что угодно делать с карточкой, фактически. Но вот проверку на выход за диапазон ты просто поставить везде не сможешь — ветвления жутко дорогие без предсказателя переходов.
Поэтому нужна статическая верификация кода и устранение избыточных проверок. C>Основной метод борьбы с глючными ядрами (программами для КУДА) сейчас — это переинициализация карты по таймауту. Ну и ещё есть зачаточная виртуальная память.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: S>Поэтому самый простой вариант кода будет открывать файлмэппинг, GetEnumerator будет возвращать новый экземпляр IEnumerable<string>, который содержит в себе текущую позицию, а Last будет обращаться к концу отмапленной области.
При открытии файлмэппинга никакой IEnumerable получить нельзя, потому что нечего энумерировать. Есть только хэндл мэппинга, больше ничего. Всякая деятельность может начинаться только при открытии view (MapViewOfFile), а вот тут тебя проблемы и будут ждать.
S>Основная сложность будет в том, чтобы аккуратно работать с файлами "слишком большого" размера, чтобы не исчерпать адресное пространство раньше времени.
Дело не в исчерпании пространства, а в том, что невозможно для больших файлов уложить их целиком в это АП. Поэтому придется это делать по частям, то есть иметь 2 view — один текущий, другой для конца. И текущий будешь переоткрывать и двигать.
Но вопрос-то не в этом. Дело не в возможности, а в логике этих действий. Если мне нужна последняя строка — зачем это простое действие привязывать к IEnumerable ? Зачем создавать интерфейс, в котором, мягко говоря, нет логики ? Зачем мне тут IEnumerable, когда и без него хорошо ? Он ведь никак не поможет для собственно задачи получения последней строки — если, конечно, не вернуться к алгоритму перебора их по одной.
With best regards
Pavel Dvorkin
Re[12]: Павлу Дворкину: о понимании того что делаешь и прост
Здравствуйте, Sinclair, Вы писали:
FR>>Для C++ тоже вполне реально, та же изоляция в системный процесс например. S>Это фантастика. Для классического неуправляемого приложения граница разрушения — это процесс. Взаимодействие процессов — очень дорогое. Поэтому реализация всех кирпичиков в виде отдельных процессов в большинстве случаев неприемлема по производительности. (Хотя, конечно, и возможна).
Это в основном на виндовсе из за её богатой истории.
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Основная сложность будет в том, чтобы аккуратно работать с файлами "слишком большого" размера, чтобы не исчерпать адресное пространство раньше времени.
PD>Дело не в исчерпании пространства, а в том, что невозможно для больших файлов уложить их целиком в это АП. Поэтому придется это делать по частям, то есть иметь 2 view — один текущий, другой для конца. И текущий будешь переоткрывать и двигать.
Здравствуйте, Cyberax, Вы писали:
C>Хех. Тебе рассказать про то как извращаются с памятью для увеличения локальности? C>Вот пример: http://en.wikipedia.org/wiki/Z-order_(curve)
И чё?
Заводим функцию с сигнатурой что-то вроде
def ZOreder{n : nat | isPowOf2(n)}(x : nat | x < n, y : nat | y < n) -> (res : nat | res < n * n)
И вперед с песней.
Учитывая что я с ходу не придумал как ее эффуктивно реализовать через стандартные операции что-то мне подсказывает что есть аппаратная реализация этого дела.
Так что просто при компиляции заменяем это дело на вызов соответствующей комманды и все.
C>Чего-нибудь простое типа: http://developer.download.nvidia.com/compute/cuda/sdk/Projects/convolutionTexture.zip
А как реагирует tex2D на выход за приделы текстуры?
Ибо мне что-то подсказывает что там на краях текстуры индексы получаются за приделами текстуры...
__global__ void convolutionRowGPU(
float *d_Result,
int dataW,
int dataH
){
const int ix = IMUL(blockDim.x, blockIdx.x) + threadIdx.x;
const int iy = IMUL(blockDim.y, blockIdx.y) + threadIdx.y;
const float x = (float)ix + 0.5f;
const float y = (float)iy + 0.5f;
if(ix < dataW && iy < dataH){
float sum = 0;
#ifdef UNROLL_INNER
sum = convolutionRow<2 * KERNEL_RADIUS>(x, y);
#else
for(int k = -KERNEL_RADIUS; k <= KERNEL_RADIUS; k++)
sum += tex2D(texData, x + k, y) * d_Kernel[KERNEL_RADIUS - k];
#endif
d_Result[IMUL(iy, dataW) + ix] = sum;
}
}
C>Кстати, ты ещё не забывай, что в CUDA часто индексы — не целые, а float'ы. С аппаратной интерполяцией.
А чё? Данному механизму всеравно с чем работать. Он и то и другое прожует.
C>Да, а ещё я могу с помощью race condition'ов элементарно сделать невалидные указатели.
Так язык должен не позволять устраивать гонки.
C>И это ты НИКАК не проверишь — нет в CUDA сильной типизации.
За это разработчикам этой КУДЫ нужно отрывать голову. Ибо никаких причин для такого решения нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Чего-нибудь простое типа: http://developer.download.nvidia.com/compute/cuda/sdk/Projects/convolutionTexture.zip WH>А как реагирует tex2D на выход за приделы текстуры?
железо умеет автоматически WRAP или CLAMP. Не помню уже как в CUDA этим управлять.
C>>Да, а ещё я могу с помощью race condition'ов элементарно сделать невалидные указатели. WH>Так язык должен не позволять устраивать гонки.
Железо зато позволяет. А средства синхронизации очень дороги.
C>>И это ты НИКАК не проверишь — нет в CUDA сильной типизации. WH>За это разработчикам этой КУДЫ нужно отрывать голову. Ибо никаких причин для такого решения нет.
Есть. Аппаратная реализация была ДО того как появилась CUDA.
Грубо говоря, CUDA это API к уже имеющимся аппаратным решениям, которые архитектурно много лет затачивались для задач обработки графики.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
WH>>А как реагирует tex2D на выход за приделы текстуры? CC>железо умеет автоматически WRAP или CLAMP. Не помню уже как в CUDA этим управлять.
Раз железо не позволяет обращаться мимо текстуры то вообще никаких проблем.
CC>Железо зато позволяет. А средства синхронизации очень дороги.
Несколькими сообщениями выше Cyberax говорил тоже самое про проверки границ массивов.
Как видишь проверки легко устраняются статически.
С гонками можно сделать тоже самое.
CC>Есть. Аппаратная реализация была ДО того как появилась CUDA. CC>Грубо говоря, CUDA это API к уже имеющимся аппаратным решениям, которые архитектурно много лет затачивались для задач обработки графики.
И чё?
Разве нельзя было сделать нормальный язык, а не кошмарить и так кошмарный С++?
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
CC>>Железо зато позволяет. А средства синхронизации очень дороги. WH>Несколькими сообщениями выше Cyberax говорил тоже самое про проверки границ массивов. WH>Как видишь проверки легко устраняются статически.
Не вижу. Где смотреть? Ссылку на практику дай. Теории я и сам могу напридумывать.
Ты не забывай что кроме текстур есть еще и обычные массивы, для которых нет никакого wrap/clamp.
WH>С гонками можно сделать тоже самое.
Та ты шо? Где этот мегатул? Ссылку!
CC>>Грубо говоря, CUDA это API к уже имеющимся аппаратным решениям, которые архитектурно много лет затачивались для задач обработки графики. WH>И чё? WH>Разве нельзя было сделать нормальный язык, а не кошмарить и так кошмарный С++?
Дык сделай, раз так просто! На той ограниченной аппаратной реализации что есть сейчас реально работает очень покоцаный сабсет С.
С++ там и близко нет. Там и до полной поддержки С еще пилить и пилить.
Причем С как язык идеально подходит из-за минимального оверхеда. Будучи по сути высокоуровневым ассемблером он не генерит никакой автоматики, которая бы хавала львиную долю выигрыша скорости от использования CUDA.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Не вижу. Где смотреть? Ссылку на практику дай. Теории я и сам могу напридумывать.
Ссылку я уже давал.
Вот более прямая ссылка раз ты пару кликов сделать не можешь http://www.cs.cmu.edu/Groups/fox/people/fp/papers/pldi98dml.pdf
CC>Ты не забывай что кроме текстур есть еще и обычные массивы, для которых нет никакого wrap/clamp.
А ты ссылочку то прочитай... там какраз про массивы. Бенчмарки тоже имеются.
CC>Та ты шо? Где этот мегатул? Ссылку!
Это только не большая их часть. Смотри те где нет "obsrvable nondeterminism" The principal programming paradigms
WH>>Разве нельзя было сделать нормальный язык, а не кошмарить и так кошмарный С++? CC>Дык сделай, раз так просто!
Сколько заплатишь?
CC>На той ограниченной аппаратной реализации что есть сейчас реально работает очень покоцаный сабсет С. CC>С++ там и близко нет. Там и до полной поддержки С еще пилить и пилить.
А с каких это пор в С шаблоны появились?
CC>Причем С как язык идеально подходит из-за минимального оверхеда. Будучи по сути высокоуровневым ассемблером он не генерит никакой автоматики, которая бы хавала львиную долю выигрыша скорости от использования CUDA.
Тут наблюдается какаято вера в то что все что имеет более высокий уровень чем С вносит оверхед.
Это не правда.
Вот например http://www.impredicative.com/ur/ компилируется в С. ГЦ за собой не тянет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
S>>>Основная сложность будет в том, чтобы аккуратно работать с файлами "слишком большого" размера, чтобы не исчерпать адресное пространство раньше времени.
PD>>Дело не в исчерпании пространства, а в том, что невозможно для больших файлов уложить их целиком в это АП. Поэтому придется это делать по частям, то есть иметь 2 view — один текущий, другой для конца. И текущий будешь переоткрывать и двигать.
I>Это и есть "исчерпать АП раньше времени"
Не совсем. Во-первых, время тут вообще ни при чем. Во-вторых, большой файл нельзя уложить целиком в АП независимо от чего бы то ни было (ну кроме перехода в x64).
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>>>Основная сложность будет в том, чтобы аккуратно работать с файлами "слишком большого" размера, чтобы не исчерпать адресное пространство раньше времени.
PD>>>Дело не в исчерпании пространства, а в том, что невозможно для больших файлов уложить их целиком в это АП. Поэтому придется это делать по частям, то есть иметь 2 view — один текущий, другой для конца. И текущий будешь переоткрывать и двигать.
I>>Это и есть "исчерпать АП раньше времени"
PD>Не совсем. Во-первых, время тут вообще ни при чем.
"раньше времени" — это идиома русского языка, которая означает что некоторое нежелательное событие(исчерпание АП) может произойти до того, как случится ожидаемое событие(уложение большого файла в АП).
>Во-вторых, большой файл нельзя уложить целиком в АП независимо от чего бы то ни было (ну кроме перехода в x64).
"нельзя уложить целиком в АП" == "исчерпать АП раньше времени"
Здравствуйте, Ikemefula, Вы писали:
>>Во-вторых, большой файл нельзя уложить целиком в АП независимо от чего бы то ни было (ну кроме перехода в x64).
I>"нельзя уложить целиком в АП" == "исчерпать АП раньше времени"
Нельзя уложить целиком в АП — означает , что это вообще нельзя, независимо от времени.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Ikemefula, Вы писали:
>>>Во-вторых, большой файл нельзя уложить целиком в АП независимо от чего бы то ни было (ну кроме перехода в x64).
I>>"нельзя уложить целиком в АП" == "исчерпать АП раньше времени"
PD>Нельзя уложить целиком в АП — означает , что это вообще нельзя, независимо от времени.
Я в курсе. Просто сообщаю, то что ты хочешь сказать можно сказать иначе, с пом. идиомы русского языка "раньше времени".
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Еще раз — не стоит в процентах измерять эти множества. Это как грибы — чтобы наполнить корзину, хватит десятка белых, а опят понадобятся сотни.
Главное тут, как и в грибах, не перепутать, и не собрать десяток опят, игнорируя белые, угробив на это весь день и порадовавшись удачному результату.
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Складывается впечатление, что ты выигрываешь-то в этой области только оттого, что тщательно бережёшь её и заказчика от конкурентов.
PD>От заказчика беречь просто невозможно, а конкурентов нет.
Да не от заказчика, а его самого! А то так ляпнешь его название на форуме — и конкуренты и появятся. Я уже окромя нашего маркетолога могу порекомендовать гендиректора и пару аналитиков, которые воспоют такие дифирамбы умному JIT, что ассемблерные вставки покажутся каменым веком.
Ну а мы, как команда разработчиков, будем исправно увеличивать быстродействие от релиза к релизу.
Всю стену комнаты благодарностями увешаем!
А стена у нас длииииная...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Но вопрос-то не в этом. Дело не в возможности, а в логике этих действий. Если мне нужна последняя строка — зачем это простое действие привязывать к IEnumerable ? Зачем создавать интерфейс, в котором, мягко говоря, нет логики ?
А если предпоследняя? А если 7я с конца?
А если ровно 7 последних строк надо?
Один умный мужик, Бьерн Страуструп, в одной умной книжке — "Язык программирования С++", с которой я начинал свое знакомство с промышленным программированием (и которая до сих пор стоит у меня на полке, хотя я давно программирую на .NET), писал разное про обработку данных — и представь, активно призывал пользоваться именно стандартной библиотекой шаблонов и enumenator-ами (итераторами с терминологии stl), и в т.ч. приводил примеры обратных итераторов — т.е. когда файл может читаться енумератором с начала до конца, а может с конца до начала... Ну а може их середины к обоим концам, через четные строки, кратные пяти по четвергам и трем — по пятницам. А код, использующий этот итератор не меняется от изменения способа перебора входных данных ни на символ. Это преподносилось как достижение в переиспользуемости кода, гибкости, расширяемости, и сокращению издержек. На нативном С++, напоминаю.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[13]: Павлу Дворкину: о понимании того что делаешь и прост
PD>При открытии файлмэппинга никакой IEnumerable получить нельзя, потому что нечего энумерировать. Есть только хэндл мэппинга, больше ничего. Всякая деятельность может начинаться только при открытии view (MapViewOfFile), а вот тут тебя проблемы и будут ждать.
Рекомендую на досуге ознакомиться с определением IEnumerable и глупостей больше не писать.
PD>Дело не в исчерпании пространства, а в том, что невозможно для больших файлов уложить их целиком в это АП. Поэтому придется это делать по частям, то есть иметь 2 view — один текущий, другой для конца. И текущий будешь переоткрывать и двигать.
(Вздыхает).
1. Павел, а кто тебе сказал, что всё АП принадлежит твоей функции? Поэтому слово "больших" тут не нужно. Речь идёт об исчерпании АП, и вовсе не обязательно иметь пятигигабайтный файл, чтоб на него нарваться.
2. Не вижу никакой причины иметь два view. IEnumerable во view вообще не нуждается. Иди посмотри, как он устроен.
PD>Но вопрос-то не в этом. Дело не в возможности, а в логике этих действий. Если мне нужна последняя строка — зачем это простое действие привязывать к IEnumerable ? Зачем создавать интерфейс, в котором, мягко говоря, нет логики ? Зачем мне тут IEnumerable, когда и без него хорошо ? Он ведь никак не поможет для собственно задачи получения последней строки — если, конечно, не вернуться к алгоритму перебора их по одной.
Логика действий — неумолимая. Я реализую класс, который предоставляет доступ к строкам файла как к коллекции.
И я могу сделать одинаково эффективный доступ как по очереди, так и с конца. Вот только логика чтения файла тут изолирована от алгоритма, который ею пользуется.
Алгоритму важно сказать Last() и не париться — может, там все данные уже в памяти построчно сидят. Реализация при этом, как видишь, никак в эффективности не проигрывает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, FR, Вы писали:
FR>С этим я не спорю. Просто говорю что и на C++ возможна эрлангоподобная организация системы хоть и коряво.
Ну, в некотором смысле — да. То есть можно написать ядро ерланг-системы на C++, и исполнять на нём эрланг-программы. Но я не считаю это "эрлангоподобной организацией системы".
А на чистом C++ ничего близкого получить не удастся. Семантика языка не та.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны.
Аргумент.
S>>2. Не вижу никакой причины иметь два view. IEnumerable во view вообще не нуждается. Иди посмотри, как он устроен.
PD>Как устроен IEnumerable — мне сейчас не важно. Но для если для реализации Next и Last через mmf ты можешь обойтись без view — код в студию.
У рыбы чешуя, а не шерсть, поэтому у нее нет блох. А вот блохи это ...
... << RSDN@Home 1.2.0 alpha 4 rev. 1435 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны.
AVK>Аргумент.
При цитировании рекомендуется цитировать полностью, дабы не исказить высказывание оппонента. Поскольку ты это не сделал, сделаю за тебя.
PD>В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны. Их на С/C++ нет и без них я до сих пор вполне обходился там и буду дальше.
Так что, как видишь, аргумент вполне обоснованнный. Если не согласен — поясни, как их к обычному С++ прикрутить.
А вот твой способ дискутировать — вырвать часть фразы — я бы назвал не очень политкорректным.
PD>>В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны. Их на С/C++ нет и без них я до сих пор вполне обходился там и буду дальше.
PD>Так что, как видишь, аргумент вполне обоснованнный. Если не согласен — поясни, как их к обычному С++ прикрутить.
Да нормально они к C++ прикручиваются, я подобные классы еще когда NET не было использовал:
class Enum
{
public:
//.....bool Next();
void Reset(size_t Begin = 0);
bool End() const;
operator bool() const;
//..........
};
Часто они удобней чем STL итераторы или даже boost::range
Здравствуйте, FR, Вы писали:
PD>>Речь идет об интерфейсах. Их в языке С++ нет.
FR>В языке С++ есть чисто абстрактные классы, также есть шаблоны с утиной типизацией, так что не вижу FR>проблем чтобы прикрутить.
Еще раз — элемента языка под названием "интерфейс" в С++ нет. Моделировать можешь как угодно.
PD>>В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны. Их на С/C++ нет и без них я до сих пор вполне обходился там и буду дальше.
PD>Так что, как видишь, аргумент вполне обоснованнный.
Ну если твои личные сексуальные пристрастия это обоснованный аргумент ... Такими аргументами можно доказать все что угодно. Вот не использую я, к примеру IOCP, ну нафик оно на моих задачах не нужен. Значит IOCP бесполезное гавно. Вместо IOCP можно подставить по вкусу.
Да, в C++ итераторы таки есть, пусть и в несколько корявом виде.
PD> Если не согласен — поясни, как их к обычному С++ прикрутить.
Здравствуйте, AndrewVK, Вы писали:
PD>>Если у тебя кроме пошлости аргументов иных нет — остается только посожалеть о твоей невоспитанности.
AVK>По остальной части возражений нет? Я так и знал.
Высказывать их желания нет — неприятно с тобой дискутировать.
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Рекомендую на досуге ознакомиться с определением IEnumerable и глупостей больше не писать.
PD>Я, конечно, виноват, что перепутал IEnumerable с IEnumerator . В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны. Их на С/C++ нет и без них я до сих пор вполне обходился там и буду дальше.
А как же итераторы из STL от C++?
Та же ведь суть, только в профиль.
Ну и "я без них обходился" — вообще не аргумент. Некоторые люди всю жизнь писали программы в машинных кодах и отлично себя чувствовали. Но это совсем не значит, что никакие языки программирования никому не нужны.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Я, конечно, виноват, что перепутал IEnumerable с IEnumerator . В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны. Их на С/C++ нет и без них я до сих пор вполне обходился там и буду дальше.
>>Поэтому слово "больших" тут не нужно. Речь идёт об исчерпании АП, и вовсе не обязательно иметь пятигигабайтный файл, чтоб на него нарваться. PD>М-да. Глубокая мысль. Как говорил Воланд, "без тебя мы никак бы не догадались"...
Я вижу. Ничего — вы спрашивайте, если что.
PD>Поясняю. Работая с mmf файлами, вполне достаточно иметь на один view 4 Кбайта (регион будет, правда, 64 Кбайта). Независимо от длины файла. Передвигая это окно, можно пройти весь файл, не затратив больше ни одного байта.
Молодец. Вижу, ты наконец начинаешь понимать, как можно и нужно писать программы.
S>>2. Не вижу никакой причины иметь два view. IEnumerable во view вообще не нуждается. Иди посмотри, как он устроен. PD>Как устроен IEnumerable — мне сейчас не важно. Но для если для реализации Next и Last через mmf ты можешь обойтись без view — код в студию.
Павел, ты по прежнему демонстрируешь чудеса невнимательности и неумения читать. Я написал, что ненужно два view. Ты продолжаешь, тем не менее, жить в своём воображаемом мире и спорить с воображаемыми утверждениями.
PD>А теперь по существу. Если ты будешь иметь только один view, то для того, чтобы спозиционироваться на конец файла в то время, когда ты итерируешь его от начала и где-то внутри этого процесса, тебе придется этот view закрыть, переоткрыть его заново на конец файла, предварительно запомнив текущую позицию, а потом выполнить обратное действие.
Отвечаю специально для тех, кому "не важно, как устроен IEnumerable".
Cамое простое и очевидное (для тех, кто в курсе, как устроен IEnumerable) решение — это открывать отдельный view на каждый IEnumerator.
Таким образом, для кода типа
string s = new MMFEnumerable(filePath).Last();
будет открыто ровно столько view, сколько здесь енумераторов (то есть — ноль), плюс один view для выполнения Last.
Итого — один. PD>И что ? Ты упорно пытаешься вломиться в открытую дверь. Если мне это будет нужно, я сделаю то же самое, без всяких IEnumerable и т.д. Или ты уж впрямь думаешь, что на С++, где этого добра нет и в помине, так-таки невозможно сделать логику чтения файла независимой от алгоритма, который ею пользуется ?
Я верю тому, что ты пишешь. А судя по тому, что ты никак не в состоянии представить себе мало-мальски приличную реализацию разделённого алгоритма на шарпе, то ни плюсы, ни фортран тебе тоже не помогут.
S>>Алгоритму важно сказать Last() и не париться — может, там все данные уже в памяти построчно сидят. PD>Ну вот и сделай для 10 Гб файла, чтобы там все данные построчно лежали. В x86
Павел, в отличие от тебя, большинство программистов решают не одну и ту же задачу, а всё время разные. И файлы у них тоже будут разные. Иногда — 10кб, иногда — 10gb. Поэтому никого, кроме тебя, не интересует решение, которое вычисляет последнюю строку конкретного файла на конкретной архитектуре. Интересует возможность писать библиотеки повторно используемого кода.
И с этой точки зрения вот этот воображаемый MMFEnumerable — гораздо лучше любого из решений, которые ты сразу кинешься писать в теле функции main.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: S>>>2. Не вижу никакой причины иметь два view. IEnumerable во view вообще не нуждается. Иди посмотри, как он устроен. PD>>Как устроен IEnumerable — мне сейчас не важно. Но для если для реализации Next и Last через mmf ты можешь обойтись без view — код в студию. S>Павел, ты по прежнему демонстрируешь чудеса невнимательности и неумения читать. Я написал, что ненужно два view. Ты продолжаешь, тем не менее, жить в своём воображаемом мире и спорить с воображаемыми утверждениями.
Код в студию — без двух view. С одним. Мне просто интересно, что ты напишешь
S>Cамое простое и очевидное (для тех, кто в курсе, как устроен IEnumerable) решение — это открывать отдельный view на каждый IEnumerator. S>Таким образом, для кода типа S>
S>string s = new MMFEnumerable(filePath).Last();
S>
S>будет открыто ровно столько view, сколько здесь енумераторов (то есть — ноль), плюс один view для выполнения Last. S>Итого — один.
Не подменяй. Ты же обещал, что и для Last и для Next будет один view.
S>Павел, в отличие от тебя, большинство программистов решают не одну и ту же задачу, а всё время разные. И файлы у них тоже будут разные. Иногда — 10кб, иногда — 10gb. Поэтому никого, кроме тебя, не интересует решение, которое вычисляет последнюю строку конкретного файла на конкретной архитектуре.
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>будет открыто ровно столько view, сколько здесь енумераторов (то есть — ноль), плюс один view для выполнения Last. S>>Итого — один.
PD>Не подменяй. Ты же обещал, что и для Last и для Next будет один view.
Он такого не говорил — он говорил, что не нужно иметь 2 view, если работать придется либо с Next, либо с Last, можно обойтись и одним. В данном примере как раз Next же ни разу не дергали, его view просто и не создалось. Зачем его создавать заранее, если можно создать при первом вызове?
P.S. Лично я бы, кстати, не стал делать дополнительный редко нужный метод Last() в прямом энумераторе, а лучше бы сделал альтернативный енумератор, перечисляющий строки файла в обратном порядке. И пользовался бы им в случае если нужна последняя строка, или 5 с конца строка, или "последняя строка, удовлетворяющая условию", и прямым энумератором, если бы требовалось то же самое с началом файла.
И было бы уж, думаю, любому соверешнно очевидно, что там не более 1 view (0 до начала реальной работы с энемератором).
Здравствуйте, fmiracle, Вы писали:
F>Он такого не говорил — он говорил, что не нужно иметь 2 view, если работать придется либо с Next, либо с Last, можно обойтись и одним.
Исключительно глубокая мысль. Если придется работать либо только с Next, либо только с Last, то второй view прикрутить при всем желании некуда и незачем. А вот если в цикле по Next требуется дать возможность вызвать Last, то либо второй view, либо не очень приятный код с unmap и map опять и перевычислением адресов, так как гарантии, что получишь тот же адрес, нет никакой.
В данном примере как раз Next же ни разу не дергали, его view просто и не создалось. Зачем его создавать заранее, если можно создать при первом вызове?
F>P.S. Лично я бы, кстати, не стал делать дополнительный редко нужный метод Last() в прямом энумераторе, а лучше бы сделал альтернативный енумератор, перечисляющий строки файла в обратном порядке.
Да мне хоть так, хоть этак, хоть с энумератором, хоть вообще без него. Я просто говорю — если по ходу прямого перебора строк нужно вдруг получить последнюю, придется делать новый view. А обертку делай какую хочешь.
>И пользовался бы им в случае если нужна последняя строка, или 5 с конца строка, или "последняя строка, удовлетворяющая условию", и прямым энумератором, если бы требовалось то же самое с началом файла.
F>И было бы уж, думаю, любому соверешнно очевидно, что там не более 1 view
На каждый энумератор ? Если да — то это очевидно. Если на оба энумератора — код в студию.
>(0 до начала реальной работы с энемератором).
А вот это далеко не очевидно. ИМХО лучше view открыть до начала реальной работы. Если его будешь открывать при каждой энумерации — потратишь время на вызов ядра (Map/UnmapViewOfFile) при каждой энумерации.
Здравствуйте, fmiracle, Вы писали:
F>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Да мне хоть так, хоть этак, хоть с энумератором, хоть вообще без него. Я просто говорю — если по ходу прямого перебора строк нужно вдруг получить последнюю, придется делать новый view. А обертку делай какую хочешь.
F>Да, я в курсе, что ты любишь менять и усложнять задачу по ходу дела. Просто последнюю строку брать уже неинтересно (описали же уже не раз как это можно) — начит надо собеседникам подкинуть какое-угодно усложнение.
Вот оттуда.
PD>М-да... Если не секрет, объясни, как реализовать обращение к этому Last в процессе обычной энумерации. То есть идем себе и идем по коллекции, потом захотели Last, а потом продолжаем идти с того места, где остановились... Чудо, а не код получится.
Написано это 1 февраля. Из-за этого моего высказывания, собственно говоря, весь сыр-бор и разгорелся.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Код в студию — без двух view. С одним. Мне просто интересно, что ты напишешь
А мне — нет. PD>Не подменяй. Ты же обещал, что и для Last и для Next будет один view.
Нет, этого я нигде не обещал. Это ты себе придумал непонятно, вместо того, чтобы читать что тебе пишут.
Ну не понял ты, что создание IEnumerable не приводит к началу итерации — надо было так и написать. А не задавать десять постингов подряд глупые вопросы типа "зачем вам читать все строчки, если нужна одна".
Тебе уже четыре человека пытаются объяснить, что вот такой код:
var s = MyFileUtilities.ReadAllLines(string fileName).Last();
вовсе не означает никакого "чтения всех строк". Просто потому, что архитектуру придумывали адекватные люди. А ты упорствуешь, и пытаешься подменить задачу.
PD>Ну хоть одного человека интересует. PD>http://www.rsdn.ru/forum/java/2958448.1.aspx
Нет, Павел, его интересует последняя строка разных файлов. Если бы его интересовала последняя строка конкретного файла — он бы тупо открыл его в Far-е и нажал Ctrl-End.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Код в студию — без двух view. С одним. Мне просто интересно, что ты напишешь S>А мне — нет.
Ну вот и выяснилось. Это несколько сложнее, чем разглагольствовать об энумераторах.
S>Ну не понял ты, что создание IEnumerable не приводит к началу итерации — надо было так и написать.
Я и написал — что перепутал IEnumerable с IEnumerator. Еще 8 февраля. В письме к тебе.
А вообще скажу еще раз — меня эти фантики интересуют во вторую очередь. Меня алгоритм интересует
и его реализация. А не упаковка, в которую он заключен.
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Ну не понял ты, что создание IEnumerable не приводит к началу итерации — надо было так и написать. PD>Я и написал — что перепутал IEnumerable с IEnumerator. Еще 8 февраля. В письме к тебе.
Один фиг — простое создание Enumerator-а тоже еще не означает захват каких-либо ресурсов...
, подробности у него в ЖЖ.
Если нам не помогут, то мы тоже никого не пощадим.
