Обновить
14

Химик и программист.

32
Подписчики
Отправить сообщение
Не понял сравнения с ЯП.
Очевидно, что мне интересна тема оптимизации, иначе я бы не стал участвовать в данном обсуждении. Не понимаю только реакцию на мои вопросы по статье.
И что Вы хотите доказать? Что в матричной алгебре у квадратной матрицы одна диагональ, а в теории графов у этой матрицы две диагонали? Или что еще?
Если Вы каждый день делаете код, и если может пройти много времени, когда Вам будет нужна статья по оптимизации кода, то видимо Вы не каждый день делаете оптимальный код в понимании этой статьи. И я про это же самое.
Думаете в литературе по матричной алгебре не обсуждают алгоритмы? Под рукой книжка из смежной области: А.А. Зыков, Основы теории графов, М.: Вуз. книга, 2004. Посмотрите, например, алгоритм получения двоичного кода матрицы смежности на стр. 33.
См. статью и ссылку там: Weisstein, Eric W. Main diagonal (англ.) на сайте Wolfram MathWorld. А еще можно любой учебник по «линейке» открыть.
Embedded системы — это очень специфическая область. Там действительно каждый такт м.б. крайне важен.
И ускоряете весь код или только критические участки? Широко известны утверждения типа:
«обычно 90% кода тратят 10% общего времени работы программы». Для Ваших задач это утверждение справедливо? Если справедливо, то должен ли программист думать об иерархии памяти, когда работает над некритическим участком?
Поставили минусы за поправку терминологии? Интересно и за следующую правку минусы получу?

если представить матрицу визуально, то элементы (i, j) и (j, i) являются симметричными относительно диагонали.


В квадратной матрице две диагонали. Речь здесь идет о главной диагонали. В литературе по матричной алгебре не пишут, что матрицу нужно представлять визуально, а просто пишут, что матрица симметричная.
Интересно! Столько программистов написали восторженные отзывы на эту статью, но никто (может пропустил — поправьте, пожалуйста) не написал: эта статья помогла исправить провальный проект. У меня куча ссылок, статей и книг по оптимизации кода — коллекция аж с того века. Думаю: вдруг пригодится, но пригождается очень мало. Оптимизация — большое искусство, где очень трудно что-то новое и полезное предложить.
Да. Входит. Только такое бывает нечасто. В моей практике 90% программ ускорять не нужно, а 9% заметному ускорению не поддаются — такие переборные алгоритмы. Остается 1%, где ускоряем.
Читал. Представьте себе. И даже не придрался, что в графе обычно ребра, а не грани. Грань — это скорее из геометрии. Википедию бы посмотрели:
Объекты представляются как вершины, или узлы графа, а связи — как дуги, или рёбра
Совсем дикие?
Потому, что аксиома, что автор должен обосновать то, о чем он пишет. Т.о. задолжал автор — т.к. не доказал. Кто сказал, что клиенты недовольны моими прогами? Срабатывает за десятую секунды, убыстрить на 20% — никто не заметит. Вы читать умеете — впечатление что писать научились, а читать еще нет. М.б. у Вас все задачи экспоненциальной сложности и других не знаете — тогда сочувствую, но описанные в статье методы Вам с экспонентой не помогут.
Во сколько минусов отгреб! А за что? Кто бы объяснил: кому я тут задолжал? У кого 5 рублей до получки занял? :) ИМХО в большинстве случаев не должен программист задумываться о незаметных ускорениях кода, иначе это очень отрицательно скажется на продуктивности работы этого программиста. Но при этом согласен, что бывают не очень частые случаи, когда нужно сделать код быстрее. Автор и согласные с ним видимо считают, что программист всегда в любом случае должен думать про иерархию памяти. Т.к. автор первый это сказал, то пусть он (или кто с ним в этом согласен) приведет подтверждающую статистику. Тогда и только тогда мне придется согласится с тем, что и я должен это делать. Или у меня задачи такие специфические, никак у всех?
Зависит от круга решаемых задач. Может быть для какого-то типа задач этот случай очень частый, но и там, наверное, далеко не всегда этот участок кода оказывается критичным по скорости. Для разреженных матриц и для параллельных вычислений, наверное, нужны другие приемы и т.д. Впрочем я не настаиваю, просто высказал небольшое сомнение в практической полезности. Существует очень много рекомендаций по оптимизации кода, но, к сожалению, очень часто в этих рекомендациях приводят слишком искусственные примеры. Но, как сказал выше, думаю что в некоторых случаях
статья может помочь
.
Ok. А теперь сравним, автор статьи написал:
Как программист, вы должны

А Вы написали:
Если вам нужна максимальная производительность

Видите разницу? Я только об этом. Если моя программа работает недостаточно быстро, то мне нужно подумать, как ее ускорить. А если быстро, то не стоит тратить время на ненужное ускорение. Иногда авторы используют неподходящую форму и слова, получая нежелательный для автора эффект.
Первая функция читала элементы матрицы построчно и двигалась по памяти последовательно, будто обходила один большой одномерный массив.
Это убедительно. Но ведь это тривиальный случай.
А Вы уверены, что для другого компилятора на другой платформе выбранное направление обхода будет оптимальным. Как быть с переносимостью, если речь не о программах-однодневках?
Следовать своей интуиции лучше, чем следовать за стадом.

Мой друг Peter Wegner говорил в 60-х годах про мою книгу «Искусство программирования», что я не должен писать ее целиком. Сначала мне следует опубликовать краткое изложение, а затем углубиться в материал. Для него это было бы, возможно, лучше, но я работаю в совершенно ином ключе. Я должен до конца понять суть того, над чем работаю и полностью разобраться в предмете, прежде чем смогу писать об этом уверенно. Вот как-то так я пишу: я не хочу писать лишь о вершине айсберга, не увидев его целиком.

Книга без преувеличения очень значительная — на ней выросло несколько поколений программистов! Но и критики эта книга отгребла порядочно — прежде всего за ассемблер несуществующей машины MIX. То что энтузиасты потом сделали эмуляторы — дело не меняет. И не так уж много авторов последовали примеру Мастера изобретая свои Миксы для своих книг. М.б. и не нужно слепо «следовать за стадом», но и опыт мастера Кнута следует воспринимать не совсем слепо…
Как программист, вы должны понимать иерархию памяти, потому что она сильно влияет на производительность ваших программ. Если вы понимаете как система перемещает данные вверх и вниз по иерархии, вы можете писать такие программы, которые размещают свои данные выше в иерархии, так что процессор может получить к ним доступ быстрее.
Как программист, я не должен! Это компилятор должен оптимизировать мой код, и часто у современных компиляторов это не плохо получается. Но как программист имею право отказаться от решений компилятора и попробовать сделать код быстрее. В этом случае статья может помочь, но таких случаев небольшой процент от всех решаемых задач.
ОБЪЯВЛЕНИЕ
Сейчас готовлю интервью о будущем игры — присоединяйтесь к обсуждению!

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность