Здравствуйте, Ikemefula, Вы писали:
I>Люди из адмнресурса вероятно более стойкие в среднем по контингенту сайта, не отчаялись и не прекращают вернуть его на путь истинный.
Какой еще "истинный путь"? Не мели хоть ты ерунды.
Не заметил разве, что все выводы относительно Дворкина исключительно умозрительные? Никаких контретных примеров его неправоты я еще не видел, кроме обвинения в абстрактном "битовыжимании", стоит ему хоть раз оговориться, что оптимизация эффективности программ еще не потеряла свою актуальность. Вон, Влад2 тоже против "битовыжиманий" все годы выступал, я с ним тоже спорил, а потом посмотрел как-то его код, и увидел, что у него тех самых "битовыжиманий" гораздо поболе моего будет. Так каким образом, объясни мне, непонятливому, оппоненты Дворкина могут знать, насколько нужны или излишни его конкретные "оптимизации" и каков их реальный уровень?
Ну разумеется, эффективность программ еще не потеряла своего значения и долго еще не потеряет. Вот я это тоже сказал вслух, ату и меня, давай прополощи в набившем оскомину лозунге "про преждевременность..." Конечно, если сумеешь показать, что у меня "это" действительно преждевременно происходит.
Поверь человеку, наблюдающему эти безобразия несколько лет — там дальше вымышленных формулировок и додумываний за оппонента еще ни разу дело не дошло. НИ РАЗУ за многие годы. Вот пример из последнего: http://www.rsdn.ru/forum/philosophy/3720169.aspx
И это пишет человек, который когда-то начал разработку RFD (бывшее BLT) с задачи оптимизации быстродействия аксессоров и решил ее наиболее "битовыжимным" способом изо всех имеющихся. Что характерно, поступил вполне правильно, что лишь показывает, что задачи-то разные бывают.
В общем, бывает ситуации, когда стыдно за других людей. Здесь та самая ситуация, ибо налицо демонстрация косности мышления и склонности к развешиванию ярлыков.
Здравствуйте, Ikemefula, Вы писали:
I>Людей, которые понимают С++ на таком уровне раз-два и обчелся.
Да ладно, если разработчики пишут пишут typedef чего-то MyContainer, затем MyContainer::iterator и пользуют хотя бы std::char_traits<TCHAR>::length(str), то понимают, а раз понимают — могут использовать в собственных разработках.
I>Кроме того, напши ты хучь самый лучший код, через год-два его все равно придется рефакторить.
Мне почти ежедневно рефакторить приходится. Простой рефакторинг делает уже и VisualAssist, а от сложного убегаем через систему декларативных typedef. Опять же, явная или частичная специализация шаблонов — мега инструмент сам по себе. Я пишу довольно много и на С++ и на C#... так вот, в C# настолько не хватает явной специализации шаблонов (т.е. генериков), просто трындец (я уже молчу о частичной специализации). Абсолютно на ровном месте надо использовать тонну лишних, т.е. не относящихся к конечной цели задачи, паттернов, типа фабрик, адаптеров и прочих костылей. И что характерно, вот это все безобразие в дотнете зовется "исскуством дизайна".
Здравствуйте, vdimas, Вы писали:
V>Поверь человеку, наблюдающему эти безобразия несколько лет — там дальше вымышленных формулировок и додумываний за оппонента еще ни разу дело не дошло. НИ РАЗУ за многие годы. Вот пример из последнего: http://www.rsdn.ru/forum/philosophy/3720169.aspx
Сам по ссылке ходил?
V>И это пишет человек, который когда-то начал разработку RFD (бывшее BLT) с задачи оптимизации быстродействия аксессоров и решил ее наиболее "битовыжимным" способом изо всех имеющихся. Что характерно, поступил вполне правильно, что лишь показывает, что задачи-то разные бывают.
Он ещё буквально вчера закомитил самый быстрый в мире ObjectMapper
V>В общем, бывает ситуации, когда стыдно за других людей. Здесь та самая ситуация, ибо налицо демонстрация косности мышления и склонности к развешиванию ярлыков.
В том то и дело, что Дворкин похоже не понимает, что ситуации бывают разные. У него она одна — сложение матриц на C. Даже когда ему приводят пример чтения последней строчки небольшого файла, реализованного в пол строчки кода в ситуации, когда лишние 10 ms не имеют значения, он всё равно доказывает с пеной у рта, что решать задачу нужно наиболее эффективным способом, пусть даже у нас вместо одной строки кода будет две сотни. Бред.
А насчёт оптимизаций у меня или у Влада, то, конечно же, мы ими занимаемся и занимаемся серьёзно. И не только на уровне битовыжиманий, но и, главное, на уровне архитектуры. Но только приоритеты у нас сильно отличаются от приоритетов Дворкина. У него — оптимизация всего любой ценой. У нас — только там где она необходима.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
VI>>Люди из адмнресурса вероятно более стойкие в среднем по контингенту сайта, не отчаялись и не прекращают вернуть его на путь истинный.
V>Какой еще "истинный путь"? Не мели хоть ты ерунды. V>Не заметил разве, что все выводы относительно Дворкина исключительно умозрительные?
У меня, например, терпения на подобное не хватает, потому я сижу в КСВ а не здесь.
>Никаких контретных примеров его неправоты я еще не видел, кроме обвинения в абстрактном "битовыжимании", стоит ему хоть раз оговориться, что оптимизация эффективности программ еще не потеряла свою актуальность. >, объясни мне, непонятливому, оппоненты Дворкина могут знать, насколько нужны или излишни его конкретные "оптимизации" и каков их реальный уровень?
Проблемы с Дворкиным вобщем то в другой плоскости, посмотри пример что я дал.
V>Поверь человеку, наблюдающему эти безобразия несколько лет — там дальше вымышленных формулировок и додумываний за оппонента еще ни разу дело не дошло. НИ РАЗУ за многие годы. Вот пример из последнего: http://www.rsdn.ru/forum/philosophy/3720169.aspx
Это не пример, а ссылка на твое сообщение, в котором ты утверждаешь что люди несправедливы к Дворкину
V>И это пишет человек, который когда-то начал разработку RFD (бывшее BLT) с задачи оптимизации быстродействия аксессоров и решил ее наиболее "битовыжимным" способом изо всех имеющихся. Что характерно, поступил вполне правильно, что лишь показывает, что задачи-то разные бывают.
Вероятно, ты про ИТ ? Я вроде все прочел, но не могу найти конкретно то о чем ты говоришь. Дай более другую ссылку.
IT>Он ещё буквально вчера закомитил самый быстрый в мире ObjectMapper
Ну дык, заслуг никто не преуменьшает. Возникает ощущение, что ими скорее злоупотребляют, ибо (и сие факт) твоя позиция на этом ресурсе намного сильнее оппонентской еще до всякого обсуждения. Большая ответственность, панимашь.
V>>В общем, бывает ситуации, когда стыдно за других людей. Здесь та самая ситуация, ибо налицо демонстрация косности мышления и склонности к развешиванию ярлыков.
IT>В том то и дело, что Дворкин похоже не понимает, что ситуации бывают разные. У него она одна — сложение матриц на C. Даже когда ему приводят пример чтения последней строчки небольшого файла, реализованного в пол строчки кода в ситуации, когда лишние 10 ms не имеют значения, он всё равно доказывает с пеной у рта, что решать задачу нужно наиболее эффективным способом, пусть даже у нас вместо одной строки кода будет две сотни. Бред.
Вот, опять то самое преувеличение ерунды. На самом деле, конечно, налицо разный менталитет. Вот у меня тут логгер свежеразработанный, и у него по заданию ограничение на длину файла — это максимальный размер файла в используемой файловой системе (и такое значение за несколько недель достигается), и поиск с конца потом в этих логах тоже есть, угу.
Тут все-навсего надо пользоваться здравым смыслом, а он обязательно включает в рассмотрение степень известности параметров задачи, например:
1. Если заведомо известно, что файл будет адекватного размера, то сделать наипростейшим образом и забыть.
2. Если п.1. неизвестен, прикинуть стоимость разработки варианта, которому пофиг размер файла (для данной задачи — это, например, чтение страницами некоторого размера с конца файла). Если стоимость разработки гораздо меньше затрат на выяснение п.1, то однозначно сделать этот "эффективный вариант" и забыть.
3. Если стоимость после прикидки получается дороже, чем затраты на выяснение, то сделать "заглушку" в виде п.1. и добавить еще один вопрос к списку оных, требующих дальнейшего уточнения.
Вот и все! Ведь элементарно и достаточно включить здравый смысл... и на мой взгляд участие в обсуждении подобных вопросов — это или совсем в собственном соку надо было вариться, и чисто прикола ради.
Конкретно по этой задаче, если данных по предполагаемому размеру файла у меня нет, то однозначно выходит п.2., ибо там не 200 строк, а 10+/-, и времени — 5-10 минут всего (разработка+тестирование+замер скорости), что несоизмеримо меньше, чем все затраты на уточнение вопроса. А не уточнить и оставить "заглушечный" вариант в надежде на "авось" я тоже не могу, это как бы культура разработки, раскидывать коровьи лепешки по коду, над которым работаю не только я, порядочному человеку не пристало.
Почему 10 мин всего для такого числа операций? Есть наготове "рыбы" для всех задач (именно для того они и есть). Откуда взял, что десяток+/- строк, вот примерный псевдокод:
Спросишь, что делать с пустыми строками? Это ведь тоже часть знаний о задачи (не факт, что они допустимы в файле), в любом случае гоу ту вышеприведенный алгоритм, он поможет с выбором решения.
IT>А насчёт оптимизаций у меня или у Влада, то, конечно же, мы ими занимаемся и занимаемся серьёзно. И не только на уровне битовыжиманий, но и, главное, на уровне архитектуры. Но только приоритеты у нас сильно отличаются от приоритетов Дворкина. У него — оптимизация всего любой ценой. У нас — только там где она необходима.
Да он вроде всегда открещивается от твоего "оптимизация всего любой ценой" и говорит, что грошовые оптимизации его не интересуют, а лишь те, где выигрыш существеннен. Зачем же так игнорировать позицию оппонента? Если в этой задаче про последнюю строку в файле были бы заранее известны параметры, позволившие утверждать, что выигрыш грошовый, то он с тобой согласиться, и предмет спора как бы исчезнет сам собой.
Тебя не удивило, что я там проговорился насчет Yet Another Logger? Смешно да? Хочешь, еще смешнее сделаю? Мне надо было выиграть десятки-сотни микросекунд на одной операции логгирования, поэтому — очередной самописный. Ну вот попадаются задачи, где требуется выигрывать миллисекунды и меньше, это целые огромные сегменты софта, и там тоже полно разработчиков и есть свой устоявшийся менталитет, немного отличный от "однострочного чтения файла".
Я ее всю не осилил, ибо слишком много уже было подобных дискуссий, можно чуть конкретнее, чтобы было видно, что оппонент "загоняет"?
I>Это не пример, а ссылка на твое сообщение, в котором ты утверждаешь что люди несправедливы к Дворкину
Да, промахнулся, там ниже пост IT, который сравнивал "битовыжимание" с другими качествами преподавателя. Хотел показать как пример, где весь пост — суть игра терминов.
Мне, если честно, плохо понятен термин "битовыжимание". Я понимаю, что туда вкладывают много негатива, но хотелось бы достоверных доказательств, что весь этот негатив применим к оппоненту, т.е. что не используется банальное развешивание ярлыков. Мой поинт таков, что если задачи требуют "битовыжимания", значит закатили рукава и битовыжимаем. Например, в кодеках я "битовыжимаю" за счет чтения/записи потока байт в локальные переменные пословно, т.е. по 4 или 8 байт за раз, и затем уже чистая битовая арифметика в регистрах, и аналогичные приемы-приседания во многих местах. Понятное дело, что лишние строки кода и т.д., но это реально улучшает показатели кодека, 10-20% быстродействия на дороге не валяется, особенно на серверной стороне. Комплекс всех этих битовыжиманий позволил, по сравнению с начальным вариантом, каждой отдельной железке обслуживать в 2-3 раза больше клиентов (от используемых кодеков зависит), а это очень хорошее конкурентное преимущество, особенно в сравнении сценариев, когда достаточно одной железки или 2-х. Это для многих клиентов целая пропасть разницы в требовании к развертыванию, т.е. не столько отличается сценарий 2-х и более железок, как одной и более.
Поэтому, ключевое слово здесь не "битовыжимание", а "требуется/не требуется", только вот об этом и можно рассуждать. Полезные были бы рассуждения относительно критериев и практик принятия решений, а так же соотношения синтетических тестов и "боевых". К сожалению, 99% процентов обсуждений на эту тему — это спам о "высоком", который можно сразу в топку.
I>Вероятно, ты про ИТ ? Я вроде все прочел, но не могу найти конкретно то о чем ты говоришь. Дай более другую ссылку.
Ну, если не в курсе, разработка его BLT ORM (тогда еще RFD) началась с того, что IT экспериментировал с "битовыжиманием" относительно реализации аксессоров для полей и св-в в системе .Net. Эксперимент вышел более-менее удачный, и дальше пошло-поехало.
Здравствуйте, vdimas, Вы писали:
V>Ну, если не в курсе, разработка его BLT ORM (тогда еще RFD) началась с того, что IT экспериментировал с "битовыжиманием" относительно реализации аксессоров для полей и св-в в системе .Net.
Это скорее ты не в курсе.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
V>>Ну, если не в курсе, разработка его BLT ORM (тогда еще RFD) началась с того, что IT экспериментировал с "битовыжиманием" относительно реализации аксессоров для полей и св-в в системе .Net.
AVK>Это скорее ты не в курсе.
Как бы практически с первых версий использовал, c конца 2003-го, и могу сравнивать с тем, что сейчас. Ввиду ндостаточности функционала маппинга на тот момент мы встроенный маппинг не использовали вообще (и не только из-за лишнего боксинга каждого значения), так же как не использовали встроенную систему конфигурации. А вот автогенеренные аксессоры — аж бегом, остальное дописали сами.
Здравствуйте, vdimas, Вы писали:
V>Как бы практически с первых версий использовал
С первых публичных версий. Это во-первых. А во-вторых это совершенно никак не говорит о твоем знании мотивов, по которым RFD создавался.
V>Ввиду ндостаточности функционала маппинга на тот момент мы встроенный маппинг не использовали вообще
Какой встроенный маппинг? Ты о чем? RFD делался для замены прямой рукопашной выборки из DataReader. Ты переносишь свои личные мотивы его использования на IT.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
Кстати, по поводу битовыжимания. Жаль что C# компилятор с включенной оптимизацией не достаточно этим занимается.
Полезность LINQ to Objects значительно бы повысилась, если бы глубокая оптимизация была.
Некоторые итераторы с последующим использованием можно было бы вобще раскрывать к обычным циклам — не понятно в чем здесь сложности.
Может разработчики кодогенераторов тоже считают "битовыжимание" ругательным словом?
Слишком уж быстро код генерируется на C# с включенной оптимизацией — компилятор должен 2-10 минут работать над средним проектом, а не 2-5 секунд. (но не засчет Thread.Sleep() конечно)
А что касается студентов, им очень полезно в битовыжиманиях поупражняться.
Здравствуйте, vdimas, Вы писали:
AVK>>Какой встроенный маппинг? Ты о чем? RFD делался для замены прямой рукопашной выборки из DataReader.
V>Это не есть маппинг?
Встроенный маппинг, который тормознее BLT? Нет, это маппинг рукопашный. И RFD не для улучшения его производительности создавался, а для уменьшения количества ручной работы. И эмит (ты, видимо, его имеешь ввиду) там использовался как единственная альтернатива рефлекшену, для которого заранее было известно, что производительность его неудовлетворительная, а не для битовыжимания в качестве основной цели.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
Здравствуйте, Silver_s, Вы писали:
S_>Кстати, по поводу битовыжимания. Жаль что C# коппилятор с включенной оптимизацией не достаточно этим занимается. S_>Полезность LINQ to Objects значительно бы повысилась, если бы глубоуая оптимизация была.
Для этого не компилятор надо наворачивать, а CLR дорабатывать. Например, Эрик Мейер считает, что yield должен быть специальной инструкцией IL, а не раскрываться компилятором.
S_>Слишком уж быстро код генерируется на C# с включенной оптимизацией — компилятор должен 2-10 минут работать над средним проектом, а не 2-5 секунд. (но не засчет Thread.Sleep() конечно)
Скорость компилятора такая не из-за отсутствия оптимизаций, а из-за отсутствия замшелых принципов организации исходников. Сейчас все современные компилируемые языки компилируются на порядки быстрее С++.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Silver_s, Вы писали:
S_>>Кстати, по поводу битовыжимания. Жаль что C# коппилятор с включенной оптимизацией не достаточно этим занимается. AVK>Для этого не компилятор надо наворачивать, а CLR дорабатывать. Например, Эрик Мейер считает, что yield должен быть специальной инструкцией IL, а не раскрываться компилятором.
Это конечно некоторые возможности откроет. Но все же не все конструкции имеет смысл до IL доводить.
Например кто-то обкурится и напишет :
foreach (var i in Enumerable.Range(2, 200000))
...;
вместо
for (int i = 2; i <= 200000; i++)
Но тем не менее, имеет полное моральное право, ожидать чтобы код работал с такой же скоростью что и for(;)
Сейчас он раз в 10 медленнее. И не видно,вроде, каких-то принципиальных проблем чтобы это компилятором проинлайнилось.
(Не данный частный случай, а вобще подобные конструкции)
S_>>Слишком уж быстро код генерируется на C# с включенной оптимизацией — компилятор должен 2-10 минут работать над средним проектом, а не 2-5 секунд. (но не засчет Thread.Sleep() конечно)
AVK> AVK>Скорость компилятора такая не из-за отсутствия оптимизаций, а из-за отсутствия замшелых принципов организации исходников. Сейчас все современные компилируемые языки компилируются на порядки быстрее С++.
Ну 10 минут это допустимый предел чтобы пользователи компилятора плеваться не начали. Release не часто собирать приходится.
Здравствуйте, Silver_s, Вы писали:
S_>Сейчас он раз в 10 медленнее. И не видно,вроде, каких-то принципиальных проблем чтобы это компилятором проинлайнилось.
В случае компилятора как раз таки принципиальная проблема есть — компилятор не имеет права инлайнить код из других сборок. А вот JIT такое вполне может делать.
S_>Ну 10 минут это допустимый предел чтобы пользователи компилятора плеваться не начали.
Сильная оптимизация, оставаясь в рамках IL — не очень разумный подход. Скорее наборот — IL должен быть как можно проще, чтобы меньше проблем создавать оптимизатору JIT.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
Обалдеть, что и требовалось, спасибо.
AVK>Встроенный маппинг, который тормознее BLT? Нет, это маппинг рукопашный. И RFD не для улучшения его производительности создавался, а для уменьшения количества ручной работы. И эмит (ты, видимо, его имеешь ввиду) там использовался как единственная альтернатива рефлекшену, для которого заранее было известно, что производительность его неудовлетворительная, а не для битовыжимания в качестве основной цели.
Насчет заранее спасибо и насчет "основной цели" особенно. Скажи, ты всерьез веришь, что у разработчиков с опытом могут быть битовыжимания в качестве "основной цели", а не средства? Я вот не верю, и среди коллег ни разу таких не встречал за 17 лет работы. Поэтому оправданно, на мой взгляд, пессимистичен, когда подобное настойчиво пытаются кому-то приписать.
AVK>Сильная оптимизация, оставаясь в рамках IL — не очень разумный подход. Скорее наборот — IL должен быть как можно проще, чтобы меньше проблем создавать оптимизатору JIT.
А у того потенциально меньше времени, т.к. загрузку стараются ускорить.
Здравствуйте, AndrewVK, Вы писали:
S_>>Сейчас он раз в 10 медленнее. И не видно,вроде, каких-то принципиальных проблем чтобы это компилятором проинлайнилось. AVK>В случае компилятора как раз таки принципиальная проблема есть — компилятор не имеет права инлайнить код из других сборок. А вот JIT такое вполне может делать.
Да, неалгоритмические проблемы есть с этим делом, когда не доступны исходники при компиляции.
При том что пользователь компилятора, в большинстве случаев бы не возражал, если бы созданные бинарники навсегда бы привязались к конкретной версии внешнего бинарника(например System.Core). И на этом основании компилятор выдирал бы оттуда функции, произвольно их переделывал и вставлял их аналоги в создаваемые бинарники. (yield тогда нужен прямо в IL)
Здравствуйте, vdimas, Вы писали:
V>Насчет заранее спасибо и насчет "основной цели" особенно. Скажи, ты всерьез веришь, что у разработчиков с опытом могут быть битовыжимания в качестве "основной цели", а не средства?
Верю.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
Так каким образом, объясни мне, непонятливому, оппоненты Дворкина могут знать, насколько нужны или излишни его конкретные "оптимизации" и каков их реальный уровень?
Если нам не помогут, то мы тоже никого не пощадим.
Если в этой задаче про последнюю строку в файле были бы заранее известны параметры, позволившие утверждать, что выигрыш грошовый, то он с тобой согласиться, и предмет спора как бы исчезнет сам собой.
