Интересно! Столько программистов написали восторженные отзывы на эту статью, но никто (может пропустил — поправьте, пожалуйста) не написал: эта статья помогла исправить провальный проект. У меня куча ссылок, статей и книг по оптимизации кода — коллекция аж с того века. Думаю: вдруг пригодится, но пригождается очень мало. Оптимизация — большое искусство, где очень трудно что-то новое и полезное предложить.
Да. Входит. Только такое бывает нечасто. В моей практике 90% программ ускорять не нужно, а 9% заметному ускорению не поддаются — такие переборные алгоритмы. Остается 1%, где ускоряем.
Потому, что аксиома, что автор должен обосновать то, о чем он пишет. Т.о. задолжал автор — т.к. не доказал. Кто сказал, что клиенты недовольны моими прогами? Срабатывает за десятую секунды, убыстрить на 20% — никто не заметит. Вы читать умеете — впечатление что писать научились, а читать еще нет. М.б. у Вас все задачи экспоненциальной сложности и других не знаете — тогда сочувствую, но описанные в статье методы Вам с экспонентой не помогут.
Во сколько минусов отгреб! А за что? Кто бы объяснил: кому я тут задолжал? У кого 5 рублей до получки занял? :) ИМХО в большинстве случаев не должен программист задумываться о незаметных ускорениях кода, иначе это очень отрицательно скажется на продуктивности работы этого программиста. Но при этом согласен, что бывают не очень частые случаи, когда нужно сделать код быстрее. Автор и согласные с ним видимо считают, что программист всегда в любом случае должен думать про иерархию памяти. Т.к. автор первый это сказал, то пусть он (или кто с ним в этом согласен) приведет подтверждающую статистику. Тогда и только тогда мне придется согласится с тем, что и я должен это делать. Или у меня задачи такие специфические, никак у всех?
Зависит от круга решаемых задач. Может быть для какого-то типа задач этот случай очень частый, но и там, наверное, далеко не всегда этот участок кода оказывается критичным по скорости. Для разреженных матриц и для параллельных вычислений, наверное, нужны другие приемы и т.д. Впрочем я не настаиваю, просто высказал небольшое сомнение в практической полезности. Существует очень много рекомендаций по оптимизации кода, но, к сожалению, очень часто в этих рекомендациях приводят слишком искусственные примеры. Но, как сказал выше, думаю что в некоторых случаях
Видите разницу? Я только об этом. Если моя программа работает недостаточно быстро, то мне нужно подумать, как ее ускорить. А если быстро, то не стоит тратить время на ненужное ускорение. Иногда авторы используют неподходящую форму и слова, получая нежелательный для автора эффект.
А Вы уверены, что для другого компилятора на другой платформе выбранное направление обхода будет оптимальным. Как быть с переносимостью, если речь не о программах-однодневках?
Следовать своей интуиции лучше, чем следовать за стадом.
Мой друг Peter Wegner говорил в 60-х годах про мою книгу «Искусство программирования», что я не должен писать ее целиком. Сначала мне следует опубликовать краткое изложение, а затем углубиться в материал. Для него это было бы, возможно, лучше, но я работаю в совершенно ином ключе. Я должен до конца понять суть того, над чем работаю и полностью разобраться в предмете, прежде чем смогу писать об этом уверенно. Вот как-то так я пишу: я не хочу писать лишь о вершине айсберга, не увидев его целиком.
Книга без преувеличения очень значительная — на ней выросло несколько поколений программистов! Но и критики эта книга отгребла порядочно — прежде всего за ассемблер несуществующей машины MIX. То что энтузиасты потом сделали эмуляторы — дело не меняет. И не так уж много авторов последовали примеру Мастера изобретая свои Миксы для своих книг. М.б. и не нужно слепо «следовать за стадом», но и опыт мастера Кнута следует воспринимать не совсем слепо…
Как программист, вы должны понимать иерархию памяти, потому что она сильно влияет на производительность ваших программ. Если вы понимаете как система перемещает данные вверх и вниз по иерархии, вы можете писать такие программы, которые размещают свои данные выше в иерархии, так что процессор может получить к ним доступ быстрее.
Как программист, я не должен! Это компилятор должен оптимизировать мой код, и часто у современных компиляторов это не плохо получается. Но как программист имею право отказаться от решений компилятора и попробовать сделать код быстрее. В этом случае статья может помочь, но таких случаев небольшой процент от всех решаемых задач.
Есть игра и есть не игра. Называть всё игрой очень выгодно тем, кто продвигает игровые методы. Но это приписывание чужих заслуг. На мой взгляд, это и не нужно, т.к. и без этого можно привести кучу примеров явной игры, которая способствует и бизнесу, и отношениям в коллективе. Например, где-то читал, что в одной конторе по продажам, кажется, оборудования для нефтепереработки, в предпраздничный день начальник устроил игру «базар». Четырем добровольцам заранее было предложено найти в сетке и распечатать какие-нибудь забавные картинки. Для остальных сотрудников напечатали «деньги». В четырех углах офисного помещения добровольцы зазывали покупать «живопись» — победил, кто набрал больше «денег». Ему подарили лучший на то время планшетник. Так начальник заодно решил проблему, кому из сотрудников отдать единственный планшетник, который дали их отделу, чтобы никого не обидеть. Вот это ИМХО явная игра, но очень полезная для целей трудового коллектива.
При внедрении геймификации можно проводить соревнования ежедневно по целому перечню разных параметров:
1. Кто больше звонков сделает;
2. Кто больше товара продаст за день суммарно;
Не понял, почему пункт 2 назван геймификацией? ИМХО это один из основных показателей и при правильной постановке дела за него нужно поощрять. В отличие от п.1: количество звонков мало что значит, можно формально звонить без всякого успеха.
Спасибо за ссылку, но это предварительное сообщение, в котором предпоследняя фраза:
Полное изложение работы исследователей будет озвучено на 22-ом симпозиуме, посвященном принципам работы операционных систем (SOSP).
Год сообщения 2009. Работу признали?
Работой по формулировке алгоритма математического доказательства в течение четырех лет занималась команда из 12 исследователей NICTA, аспирантов и техников. Они успешно проверили более 10 тыс. промежуточных теорем, изучив более чем 200 тыс. строк кода.
Провал искусственного интеллекта. Еще в 80-х была популярна область, называемая искусственным интеллектом, основной идеей которой было выяснить, как эксперты делают то, что делают, свести эти задачи к набору правил, потом запрограммировать компьютеры используя эти правила и эффективно заменить экспертов.
Уважаемый автор,
я понимаю, что IT — огромная сфера и не возможно быть специалистом во всех сегментах этой сферы, поэтому посмотрите, пожалуйста, про AI хотя бы в википедии — это не долго. Если Вы это сделаете, то не будете говорить об этой области в прошедшем времени, хотя бы потому, что туда входит и такое, нпр., направление, как распознавание образов. Это оцифровка книг и прочих бумажных источников, это и распознавание речи, и распознавание автомобильных номеров и т.д. и т.д. Может не все работает так хорошо, как хотелось бы, но работает!
Где-то читал, что что-то подобное М.Т. Калашникову говорили, когда он АК разрабатывал :)
ИМХО многое можно сделать простым, удобным, надежным, только нужно ли это делать? Если посмотрите другие мои комменты к этой статье, увидите, что я скептически отношусь к идее «умного» оружия. В частности, выше сказал:
В мире потребления легальный пользователь не ищет простых путей. Главное — купить самый новый гаджет, и не важно, что большинство функций не нужны и только усложняют жизнь
Если говорить о мат.модели отдельного алгоритма, нпр., алгоритма перемножения двух матриц, то построение такой модели особых проблем обычно не вызывает. А вот построение полной мат.модели ОС представляется трудновыполнимым, если вообще выполнимым. Тут, видимо, нужно говорить о наборе моделей, с неизбежными в этом случае конфликтами между ними. Не уверен, что даже микроядро (о котором говорится в статье) возможно адекватно смоделировать. Будет ли модель адекватной без моделирования CPU? — О проблеме моделирования CPU писал такой лидер, как Интел в своих публикациях.
Т.о. ИМХО можно говорить только о частичной и очень ограниченной верификации.
Совсем дикие?
А Вы написали:
Видите разницу? Я только об этом. Если моя программа работает недостаточно быстро, то мне нужно подумать, как ее ускорить. А если быстро, то не стоит тратить время на ненужное ускорение. Иногда авторы используют неподходящую форму и слова, получая нежелательный для автора эффект.
Книга без преувеличения очень значительная — на ней выросло несколько поколений программистов! Но и критики эта книга отгребла порядочно — прежде всего за ассемблер несуществующей машины MIX. То что энтузиасты потом сделали эмуляторы — дело не меняет. И не так уж много авторов последовали примеру Мастера изобретая свои Миксы для своих книг. М.б. и не нужно слепо «следовать за стадом», но и опыт мастера Кнута следует воспринимать не совсем слепо…
Сейчас готовлю интервью о будущем игры — присоединяйтесь к обсуждению!
Не понял, почему пункт 2 назван геймификацией? ИМХО это один из основных показателей и при правильной постановке дела за него нужно поощрять. В отличие от п.1: количество звонков мало что значит, можно формально звонить без всякого успеха.
При таких объемах возникают большие сомнения.
я понимаю, что IT — огромная сфера и не возможно быть специалистом во всех сегментах этой сферы, поэтому посмотрите, пожалуйста, про AI хотя бы в википедии — это не долго. Если Вы это сделаете, то не будете говорить об этой области в прошедшем времени, хотя бы потому, что туда входит и такое, нпр., направление, как распознавание образов. Это оцифровка книг и прочих бумажных источников, это и распознавание речи, и распознавание автомобильных номеров и т.д. и т.д. Может не все работает так хорошо, как хотелось бы, но работает!
ИМХО многое можно сделать простым, удобным, надежным, только нужно ли это делать? Если посмотрите другие мои комменты к этой статье, увидите, что я скептически отношусь к идее «умного» оружия. В частности, выше сказал:
Т.о. ИМХО можно говорить только о частичной и очень ограниченной верификации.