Ну те, про кого вы писали, что "Я - это 10 человек, которым что-то там не интересно".
Мне тоже уже интересно, кто эти 10 человек, и еще Вашу бы фамилию. Хочется уже навести резкость и проникнуться уровнем спора.
Программирование - это просто
- Автор темы Жадный КаБан
- Дата начала
Мне тоже уже интересно, кто эти 10 человек, и еще Вашу бы фамилию. Хочется уже навести резкость и проникнуться уровнем спора.
sami
Местный
Тогда я не понимаю, о чем мы спорим? Почему Вы считаете, что
Вы представляете о чем Вы говорите? Вообразите себе тупой метод поворачивающий снимок вложенным циклом. В этом методе уже условных переходов хватает. Оптимизация метода под кэш мало того что добавляет условных переходов, так она еще и увеличивает кол-во вызовов, делает более активным использование стека, кол-во выполняемого кода увеличивается. Так все становится плохо, но грубо оптимизированный под кэш код без распараллеливания на медицинских снимках (аки 40Мб) работает быстрее в 80 раз чем тупой вложенный цикл. Но это код не счетный. Это чистая нагрузка на обмен с памятью. Тем не менее, значительная часть алгоритмов, обрабатывающих массивы информации, замечательно оптимизируются под кэш с выигрышем по производительности в разы. Кстати, разработчики фотошопа об этом знают.
Целочисленная арифметика может дать выигрыш перед плавающей раза в полтора, не больше. И то при условии, что в программе кроме арифметики ничего нет. А любой обсчет физических моделей так или иначе связан с данными, причем большими данными, не мне Вам объяснять это. А работа с данными - это циклы, часто вложенные, адресная арифметика, работа со стеком, вызовы и т.п. Арифметика редко занимает значительную часть процесса, потому переход на целочисленную арифметику мало эффективен, пока не используются табличные функции. Но табличные функции это не целочисленная арифметика, это уже из разряда мемоизации.
Ну да правильно, SSE за 10 лет сменила 5 версий, а целочисленная арифметика как была так и есть. Удобно! На кой изучать технологии, они умрут, а таблички с операциями останутся.
Не очень-то Вы и занимаетесь оптимизацией. Если вдруг решите что-то пооптимизировать, то вот мой Вам совет:
Таблички с производительностью операций БЭСМ-а продайте в музей Адоба задорого! Только тсс!!!! чтобы режим не напрягся!
Вернусь к Вашему высказыванию:
Да Вы понимаете СКОЛЬКО стоит промах кэша? Это такая огромная задержка, что за время обновления кэша можно было бы выполнить сотни полезных операций. Сравните время подгрузки кэша с потерей на условном переходе, который якобы может сломать оптимизацию под кэш, и может быть Вы поймете, какую охинею написали!
Потому не важно, на чем Вы пишете, на ассемблере или на VB! Если вы написали критический код не по кэшу, то никакие трюки с регистрами или с целочисленной арифметикой Вас не спасут. Если используете массивы информации размером больше полмегабайта, то профайлер в зубы, руки в плечи и вперед!
Ой, да Вы же не знаете поди, что такое профайлер?
Понимаете ли в чем дело, оптимизированный под кэш код работает быстрее вне зависимости от того, запущен ли фотошоп али нет. А промахи кэша они тем дороже, чем больше программ активно используют кэш. Причем, если моя программа написана мимо кэша, то фотошоп от этого тоже будет страдать.
А Вы случаем, не путаете кэш со свапом? Чего Вы про фотошоп вспомнили?
Опять юлите. Вы сначала завели речь о графических примитивах и целочисленных алгоритмах, их рисующих, потом перекинулись на окна и их содержимое. Содержимое рисуется из примитивов, не так ли? Примитивы рисуются железом, Винда она только подает примитиву железу, если конечно же железо не VGA и в винде стоят дрова))). Оно конечно, алгоритмы растеризации не сильно изменились со времен Брезенхейма и Кармака, но графическое железо охотно хавает плавающие координаты и проецирует их с высоким качеством. Там работают толпы конвейеров, одни проецируют геометрию, вторые растеризуют, третьи занимаются шейдингом, четвертые маскируют по буферам, пятые делают постпроцессинг. И знаете, целочисленной арифметики в пайплайне GPU не густо.
Прошу прощения, это не 10 человек, это "коллектив в несколько десятков человек, каждый ОЧЕНЬ хорош в своей области, и НЕ желает НИЧЕГО знать о других" с Ваших слов. Хорошего же Вы о них мнения :huh: Уверены, что никто из них не знает, чем современные камни отличаются от БИС?
Intrinsic, SSE* тоже никто не слышал? Если так, то мне искренне жаль. Обновить парк машин и гнать оптимизаторов вшею, расходы на железо окупятся в пол месяца! Негуманно, разве что...
Да кто Вам сказал, что процессор разбирается в языках программирования? Ассемблерный код он тоже, кстати, не знает. Процессор разбирается в машинном коде, но выполняет он не его. Я уже писал, что он анализирует код, сам распределяет регистры для оптимального выполнения, самостоятельно принимает решения об изменении порядка команд, дабы повысить эффективность, выполняет за такт несколько операций. C2D, например, умеет выполнять до 4х операций за такт одним ядром. При этом, он выполняет предсказание переходов и подгружает соответствующий код загодя, чему мешают некоторые любители ручной оптимизации, складывающие адреса переходов в регистры.
Я бы послал Вас на сайт Intel-а, но Вы все равно ничего читать не будете, а будете рассказывать мне прописные истины 20-ти летней давности и удивляться, откуда я все выдумываю.
Подумайте хотя бы вот о чем: Если взять P4 и C2D с одинаковой тактовой частотой 3Ghz (это будет C2D E8400), то одно ядро C2D порвет P4 как тузик грелку. Это не предположение, это факт! Что на синтетике (чистый замер FLOPS), что на реальных задачах. Как Вы это объясните с позиций что камень тупой и делает только то, что ему компилятор предпишет? А P4 тоже не дурак!
Но только подумайте, сюда отвечать не надо.
Походу задета честь нескольких десятков человек, а то и целого подразделения. Только замечу, что не я их подписал под ограниченностью.
SCTRWD, современные процессоры общего назначения давно уже не выполняют ассемблерный код напрямую.
Программирование на ассемблере сейчас актуально только для простейших микроконтроллеров.
Процессоры сейчас являются микрокомпьютерами с десятком(и) RISC-вычислителями и блоками и микрокодом (операционной системой процессора), который разворачивает "элементарную" ассемблерную команду в цепочку внутренних RISC-команд. Оптимизация под кэш, предсказание вероятности ветвлений и предварительная подгрузка в кэш на основании этих предсказаний уже лет 10 являются реальностью. Оптимизация на уровне компилятора сейчас позволяет получить более быстрый код даже для плохо написанной программы на языке высокого уровня, чем у программы написанной на ассемблере без использования подобной оптимизации.
Вы правда не слышали об этом?
Ваши слова о целочисленных операциях и количестве тактов и т.п. доказывают что вы действительно этого не знаете.
"Ручная" оптимизация под процессор давно ушла в прошлое, если вы этим занимаетесь, вы впустую тратите время и деньги.
Программирование на ассемблере сейчас актуально только для простейших микроконтроллеров.
Процессоры сейчас являются микрокомпьютерами с десятком(и) RISC-вычислителями и блоками и микрокодом (операционной системой процессора), который разворачивает "элементарную" ассемблерную команду в цепочку внутренних RISC-команд. Оптимизация под кэш, предсказание вероятности ветвлений и предварительная подгрузка в кэш на основании этих предсказаний уже лет 10 являются реальностью. Оптимизация на уровне компилятора сейчас позволяет получить более быстрый код даже для плохо написанной программы на языке высокого уровня, чем у программы написанной на ассемблере без использования подобной оптимизации.
Вы правда не слышали об этом?
Ваши слова о целочисленных операциях и количестве тактов и т.п. доказывают что вы действительно этого не знаете.
"Ручная" оптимизация под процессор давно ушла в прошлое, если вы этим занимаетесь, вы впустую тратите время и деньги.
Ух, да я именно это и утверждаю, что программирование "под кэш" даёт резкое ускорение. Только при этом придётся забыть о динамических языках, ООП и прочих вкусностях. Придётся ВЕСЬ свой код строить вокруг этого. Тупо надееться на оптимизацию здесь уже не придётся.
До этого ещё не дошёл, знаете ли.
Они работают только в воображении. Реально работают целочисленные алгоритмы. Если Вам кажется что, например, современные фонты оперируют векторными данными, то Вы глубоко заблуждаетесь. Фонт True Type - это порядка 2500х2500 точек на символ(не хватайте меня за язык, я могу и ошибатсья в цифрах, иногда может быть и порядка 4600х4600), вектор - иллюзия.
Прошу прощения, это не 10 человек, это "коллектив в несколько десятков человек, каждый ОЧЕНЬ хорош в своей области, и НЕ желает НИЧЕГО знать о других" с Ваших слов. Хорошего же Вы о них мнения
Это так есть, и так было при моём устройстве на работу. И, уверяю Вас, так это в большинстве коллективов. И так будет, уверяю Вас, и слава Богу, иначе у нас останутся одни крутые программисты и только.
Да никто и не спорит, вопрос в том, насколько это хорошо у него получится. Объясню, как я это понимаю. Есть люди, которые свято верят в оптимизатор, и что можно писать как угодно, а потом отдать своё творение в оптимизацию компилера. При этом они ВЕРЯТ, что на выходе получили МАКСИМУМ возможного.
А есть люди, которые в это НЕ верят и знают, КАК работает, оптимизатор и конвейеры. И они кромсают свой код так, чтобы помочь оптимизатору сформировать гораздо более эффективный код.
Но при этом придётся забыть о переносимости, простоте понимания кода, универсальных языках и т.д.
Touareg
to kalon epieikes
О, я снова поймал нить беседы))
Примерно с этого я и начал, сейчас железо дешевое и быстрое, и самое время вспомнить о переносимости, простоте понимания кода, универсальных языках, а до кучи и о бессмертной фразе не помню кого: "Преждевременная оптимизация - корень всех зол".
Вот довод о "дешевом и быстром" железе никак не принимается, наши аппетиты ВСЕГДА растут быстрее, это аксиома. А насчёт "Преждевременная оптимизация - корень всех зол" - это действительно так для традиционных языков. Для программирующих под конретную архитектуру, кэш, конвейеры, GPU - это основополагающее
.
Touareg
to kalon epieikes
Может я старомоден, но хороший код пишется так - сначала красиво и правильно с точки зрения человека, потом выявляются ресурсоемкие фрагменты и уже они (по возможности локально с минимальным влиянием на общую архитектуру) подвергаются оптимизации (ассемблерные вставки, учет особенностей конкретной архитектуры, конвейеры, кэш, основополагающее вобщемВот довод о "дешевом и быстром" железе никак не принимается, наши аппетиты ВСЕГДА растут быстрее, это аксиома. А насчёт "Преждевременная оптимизация - корень всех зол" - это действительно так для традиционных языков. Для программирующих под конретную архитектуру, кэш, конвейеры, GPU - это основополагающее
).Если ты пишешь по-другому, я не хочу читать твой код, даже если он работает.
Может я старомоден, но хороший код пишется так - сначала красиво и правильно с точки зрения человека, потом выявляются ресурсоемкие фрагменты и уже они по возможности локально подвергаются оптимизации (ассемблерные вставки, учет особенностей конкретной архитектуры, конвейеры, кэш, основополагающее вобщем
Если ты пишешь по-другому, я не хочу читать твой код, даже если он работает.
Эх мечты-мечты. Дайте угадаю: так сказано в модных статьях по оптимизации? А вот в реальных задачах придётся переписывать ВЕСЬ код.
"Локально" - понятие растяжимое. И локальная оптимизация даст именно это, и только это, - "локальную" оптимизацию, ничего больше. А, между тем, зарядись Вы изначально на эту оптимизацию, начни изначально писать код с учётом этого - получите ГОРАЗДО оптимальней алгоритм.
Ну кто Вам сказал что код - это последовательность действий, среди которых МОЖНО выявить некие "УЧАСТКИ", поддающиеся оптимизации? Это иллюзия, поддерживаемая адептами теории: сначала мы напишем, а потом будем оптимизировать то, что получилось. Типа профилировщик в руки и вперёд. Типичный подход, но не выдерживающий никакой критики.
Touareg
to kalon epieikes
Правило Парето кстати никто не отменял, 20% кода занимают 80% времени исполнения (реально 10 на 90), эти 20% и нужно выявить и подвергнуть оптимизации, на остальных 80% кода оптимизация не только бесполезна, но и вредит!
Изначально заряженный на оптимизацию код - это код ориентированный не на человека, а на машину, возможно такой код работает быстрее, но вероятность повторного использования его близка к нулю. Ну и потом поколения машин сменяются одно за другим раз в полтора-два года, ориентация на машину чревата впадением в ретроградство.
А я оп чём, собственно и талдычу
Либо скорость - либо универсальность, переносимость, простота, понятность и сопровождаемость. Никому ещё не удалось совместить эти вещи
sami
Местный
Ну и с чего Вы это взяли? Догадки?
Вы так и не прочитали, что такое динамический язык?
5Mb один символ, нехило, удивили ))) Не смешно?
Вообще с этой позиции - конечно да, память компьютера - сплошные биты, они целые, плавающие форматы - иллюзия. Так чего же Вы паритесь за них?
Странная логическая цепочка ))
Опять странный вывод в конце. Откуда он? Опросы проводили среди коллег?
Только кромсая код со знаниями середины прошлого века, переносимость и простоту Вы потеряете, а в скорости не выиграете.
В Снежинске такие крутые мужики, что вместо оптимизации переписывают сразу ВСЮ программу, причем не заглядывая в профайлер.
Отправить надо в "Нашу Рашу" идейку)))
Touareg
to kalon epieikes
А я говорю о том, что время компромиссов прошло. При упоре на качество, универсальность, переносимость, простоту, понятность и сопровождаемость после локальной оптимизации достаточная скорость обычно достигается автоматически. А гонка за скоростью чревата плавающими глюками, катастрофическим ростом сложности, увеличением количества взаимозависимостей и ошибками времени исполнения. Это парадокс, но код надо писать для людей, если конечно не стоит задача поддерживать его до пенсии в роли незаменимого эксперта.
sami
Местный
И что Вы предпочитаете?
koala
Уже освоился
Выше написано много умного. Господа программисты, посоветуйте мне дураку. Я пишу программы на fortran95 для решения уравнений мат.физики (газодинамика, теплопроводность, кинетика реакций, перенос излучения с массивами размером в десятки мегабайт), использую опцию компилятора -O3. Как мне использовать обсуждающиеся здесь способы оптимизации (под кэш или чего-нибудь еще)? Распараллеливание не предлагать, поскольку это отдельная тема. Прошу объяснить на популярном уровне без использования слэнга.
Э..., взял ЧТО? Не понял, если честно.
Господи, ключевые точки описывающие этот символ задаются в этом формате. Где Вы взяли 5Mb?! Что не понятного то?.
Странно, что Вам это странно...
Да знаю я это, и вижу.
Да с чего Вы это так взяли. НИЧЕГО автоматически НЕ достигается! Бесплатных пирожных НЕ бывает!
ПОЛНОСТЬЮ с Вами согласен в этом. Именно та мысль, которую я и высказывал. Ну, блин, наконец то мы пришли к общему знаменателю <_< :lol: The war is over? Least, I hope so :lol:
Touareg
to kalon epieikes
Огласите текущую конфигурацию железа)
И если возможно пример фрагмента ресурсоемкого кода, с которым по Вашему мнению сейчас это железо не справляется.
Touareg
to kalon epieikes
Я так понимаю Ваши задачи характерны обильным использованием элементарных арифметических преобразований над достаточно большими массивами данных, были ли попытки самостоятельно выявить узкие места? Например если винт постоянно на подкачке заметный прирост в скорости может дать организация рэйд массива нулевого уровня.
Вобщем то диллема простая - вычислять или хранить (а также что вычислять, что хранить и где хранить <_<).
koala
Уже освоился
Программа полностью помещается в оперативной памяти. Кроме элементарных операций также при обработке массивов используются функции: sin, cos, exp, log и т.д. Одновременно в вычислениях используется несколько больших массивов (плотность, скорость, температура, давление, концентрации и т.д.). Также в циклах происходит обращение к логическим операциям и ветвление по результатам (if ... then ... else if ... then ... else ... end if )
sami
Местный
Для оптимизации под кэш никакие опции не нужны. Требуется сделать так, чтобы при обработке больших массивов данных, требовалось минимальное количество обновлений кэша. Пример я уже приводил - транспонирование большой матрицы. Вот его и рассмотрим:
сам алгоритм тупой до безобразия, нужно строку одной матрицы вписать в столбез другой. Беда в том, что при выполнении цикла переноса строки в столбец, потребуется прокачать через кэш всю вторую матрицу. Перенося вторую строку - требуется прогнать вторую матрицу через кэш еще раз. И так для каждой строки.
Будем переносить столбцы первой в строки второй - получим тот же эффект, но только с первой матрицей.
Если строки первой матрицы переносить не целиком, а кусками, причем такого размера, чтобы соответствующая часть второй матрицы полностью (лучше с большим запасом), то при переносе одного куска строки промахов мимо кэша не будет. При переходе к следующей строке, нужная часть второй матрицы все еще будет в кэше. Таким образом, транспонирование частями строк выгоднее транспонирования полными строками.
Алгоритм выбора размера части строки не обязательно должен быть адаптивным. Просто достаточно перейти от целой строки к части и при больших размерах матриц (не помещающихся целиком в кэше) Вы обязательно увидите ускорение.
Это пример, на котором я показал идею. Мне кажется, что уже он для Вас будет актуален, развороты массивов нередки в задачах моделирования.
На самом деле приходится выбросить из головы что Вы работаете с Random Access Memory и слегка приблизиться к машине Тьюринга, сделая допущение что читающая головка имеет возможность читать не один символ, а некоторый ограниченный диапазон. Для чтения вне этого диапазона требуется дорогостоящая операция перевода пленки.
Наверное, несколько грубая аналогия. Кэш штука хитрая. Представьте, что Вы работаете на одном мониторе с несколькими большими документами. И для удобства, чтобы видеть их одновременно, расположили окна мозайкой. Вся информация, что Вам видна, доступна мгновенно. Если требуется что-то другое, необходимо воспользоваться полосой прокрутки одного из документов. Остальные при этом останутся доступны. Т.е. в кэше не один сплошной кусок памяти. Но с другой стороны, кэшем пользуетесь не только Вы.
Есть более общие соображения: предпочитайте обходить матрицы по строкам, а не по столбцам (если требуется и то и другое, то ищите баланс, как в случае с транспонированием). Если есть возможность переиспользования старых массивов, лучше их переиспользовать, чем выделить новые. Уменьшите фрагментацию памяти, сосредоточите актуальные данные в более узком сегменте памяти.
Старайтесь выделять память под данные, работа с которыми будет вестись одновременно, единомоментно, даже если часть данных еще не доступна. Это уменьшит фрагментацию памяти, и уменьшит вероятность того, что данные будут раскиданы по разным углам памяти.