Здравствуйте, vdimas, Вы писали:
V>Да бредовый пример, который конкретно к С/С++ никаким боком. Такой же ляп можно создать на большинстве современного мейнстрима и даже на обоих версиях VB.
AVK>А хамло удалять нужно тем более. Товарищь получил совершенно заслуженный бан.
Да тут общая проблема в том, что русский язык (и не только) позволяет говорить/писать грубости и без перехода на личности, а этот момент не наказывается модераторами. От того многие "поднаторевшие" форумчане этим охотно пользуются для изливания безнаказанного неконструктива (некоторые весьма из популярных на этом ресурсе в т.ч.). Достаточно применнить аллегорию — и вот вроде уже никакой личности, а собеседник, извините, обгажен по полной.
Здравствуйте, 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>Я не рекомендую, я даю ссылку и предлагаю хоть немного задуматься, т.е. "покурить" написанное. При вдумчивом, неспешном прочтении и длительном размышлении над прочитанным обещаю просветление, после которого советы оптимизировать всё и вся покинут тебя навсегда.
При внимательном чтении моих опусов я тебе тоже обещаю просветление на предмет того, что ты воюешь с воображаемым оппонентом, а вовсе не со мной.
Здравствуйте, 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, Вы писали:
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>Господь с тобой, какая тут СУБД. Чтобы взять из файла любой длины последнюю строчку, совсем не надо все остальное читать. Надо именно последнюю строчку.
а можно ссылку на оригинальное задание про последнюю строку?
Здравствуйте, Pavel Dvorkin, Вы писали:
>>Их все больше интересует что-то типа "правильно склеить изображения снятые с разных камер" или "получать информацию о новых просроченных кредитах каждый понедельник". Интересуют сроки и стоимость решения (включая и разработку и железо). А используется там файл, СУБД или таз с гайками их вообще не интересует.
PD>Заказчика , может, и не интересует, что там внизу, а вот скорость его очень даже интересует.
Судя по тому, как упорно вы настаиваете на этом — с заказчиками вы общаетесь крайне редко. Я не встретил в своей практике еще ни одного, который бы упоминал скорость в разговоре о требованиях к программе. Скорость всегда нужна достаточная. Не максимально возможная, а достаточная. Даже когда есть четкое требование по производительности, то оно формулируется четко, например: SLA сервиса — ответ в пределах 0,25 мс для 95% запросов. Если таких четких требований нет — значит у вас проблемы, потому что вы их сформулировать не в состоянии, работая с заказчиком.
Более того, нет смысла просто полировать один кусочек программы, скажем с 0,105 мс до 0,02 мс, если все упирается в коннект к базе данных, который занимает 0,9 мс. Даже сфереконические пользователи не оценят ваших потугов в полировке маленького кусочка, пока программа будет ждать ответа от БД.
Более того, производительность программы не дается бесплатно. Практически всегда более быстрый алгоритм в данном месте означает более запутанный и трудно-поддерживаемый код. Это означает что производительность нужно очень осторожно дозировать — есть риск резко снизить эффективность работы с кодом. Что дает отличный шанс конкурентам, которые могут быть гораздо умнее в этом плане.
Это же очень простые утверждения — как их можно не понимать?
Кэр>Судя по тому, как упорно вы настаиваете на этом — с заказчиками вы общаетесь крайне редко.
Ну это обсуждать не стоит.
>Я не встретил в своей практике еще ни одного, который бы упоминал скорость в разговоре о требованиях к программе.
Это лишь означает, что Вам не доводилось иметь дело с разработкой ПО такого рода.
>Скорость всегда нужна достаточная. Не максимально возможная, а достаточная.Даже когда есть четкое требование по производительности, то оно формулируется четко, например: SLA сервиса — ответ в пределах 0,25 мс для 95% запросов. Если таких четких требований нет — значит у вас проблемы, потому что вы их сформулировать не в состоянии, работая с заказчиком.
У меня никаких проблем нет, а требование максимальной скорости выдвинуто заказчиком, с которым я работаю почти 10 лет. Обсуждать характер моей работы я здесь не буду.
Кэр>Более того, нет смысла просто полировать один кусочек программы, скажем с 0,105 мс до 0,02 мс, если все упирается в коннект к базе данных, который занимает 0,9 мс.
Представьте себе, есть. Мне заказчик как-то выразил благодарность за то, что я ускорил быстродействие на 1%.
>Даже сфереконические пользователи не оценят ваших потугов в полировке маленького кусочка, пока программа будет ждать ответа от БД.
А пользователей (в обычном смысле) у ПО, которое я разрабатываю, нет вообще. Пакетная обработка в полностью автоматическом режиме.
Кэр>Более того, производительность программы не дается бесплатно. Практически всегда более быстрый алгоритм в данном месте означает более запутанный и трудно-поддерживаемый код.
А это в данном случае мало кого волнует. По крайней мере заказчик на это не жаловался и никаких требований на этот счет не выдвигал.
>Это означает что производительность нужно очень осторожно дозировать — есть риск резко снизить эффективность работы с кодом. Что дает отличный шанс конкурентам, которые могут быть гораздо умнее в этом плане.
А конкурентов нет и быть не может
Кэр>Это же очень простые утверждения — как их можно не понимать?
Надеюсь, я кое-что объяснил ? Если так и осталось неясным, то краткое резюме — задачи бывают разными. Из того факта, что Вам не приходилось сталкиваться с задачами и заказчиками, которые требуют совсем иного подхода, нежели привычный Вам — не следует, что таких задач нет.
Здравствуйте, Alexey Voytsehovich, Вы писали:
AV>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Господь с тобой, какая тут СУБД. Чтобы взять из файла любой длины последнюю строчку, совсем не надо все остальное читать. Надо именно последнюю строчку.
AV>а можно ссылку на оригинальное задание про последнюю строку?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А конкурентов нет и быть не может
Ну так с этого и нужно было начинать. Собственно этим можно было и закончить. Если вы не утверджаете, что все ваши утверждения применимы к большей части разработки программного обеспечения, а только имеют смысл в рамках этого вашего конкретного проекта — то бог с вами.
Здравствуйте, Кэр, Вы писали:
Кэр>Ну так с этого и нужно было начинать. Собственно этим можно было и закончить. Если вы не утверджаете, что все ваши утверждения применимы к большей части разработки программного обеспечения, а только имеют смысл в рамках этого вашего конкретного проекта — то бог с вами.
Я бы так сказал — к некоторому множеству проектов. Поймите одну простую вещь — мир программирования не сводится ни к web-программированию, ни вообще к той его части, для которой Вы в предыдущем письме столь настойчиво проповедывали в общем-то, справедливые для этой части идеи. Мир большой, и в нем есть всякое — как то, что соответствует Вашим представлениям, так и то, что им безусловно противоречит. Ну а каково процентное соотношение этих частей — это не так уж важно. Сегодня оно одно, завтра другое, а послезавтра вообще что-то иначе будет
Если нам не помогут, то мы тоже никого не пощадим.
, подробности у него в ЖЖ.
