| Вопрос: Разгоняем CHR : Почти в 2 раза! | Добавлено: 08.05.05 22:08 |
Автор вопроса:  Morpheus | Web-сайт: xury.zx6.ru
|
| Ответы | Всего ответов: 125 |
|
Номер ответа: 76 Автор ответа:  HOOLIGAN Вопросов: 0 Ответов: 1066 |
Профиль | | #76 | Добавлено: 12.05.05 15:17 |
| То, что память была заметно медленней регистра, было заметно на старых процессорах. На современных это уже не столь актуально. Операции с локальными переменными(память на стеке) практически так же быстры, как и с регистрами. | ||
|
Номер ответа: 77 Автор ответа: LamerOnLineICQ: 334781088 Вопросов: 108 Ответов: 2822 |
Профиль | | #77 | Добавлено: 12.05.05 15:18 |
| Да, жаль только что весь исполняемый код в регистры не запихивается. Посему приходится оптимизировать. Как я уже говорил, для VB этим типом оптимизации является использование типа long для переменных в циклах с большим числом итераций. | ||
|
Номер ответа: 78 Автор ответа: LamerOnLineICQ: 334781088 Вопросов: 108 Ответов: 2822 |
Профиль | | #78 | Добавлено: 12.05.05 15:20 |
| Да, заметно было особенно на однобанковых модулях. Хотя... отключи кэш и посмотри на разницу. | ||
|
Номер ответа: 79 Автор ответа: CyRax  Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229 |
Web-сайт: Профиль | | #79 | Добавлено: 12.05.05 15:24 |
|
То, что память была заметно медленней регистра, было заметно на старых процессорах. На современных это уже не столь актуально. Операции с локальными переменными(память на стеке) практически так же быстры, как и с регистрами. Регистр находится внутри процессора, а память на материнской плате. Расстояние - это один из факторов, другим фактором является то, что связь с памятью осуществляется не напрямую как с регистрами, а через шину. Это будет актуально всегда, ну разве что если озу не начнут встраивать в процессор. |
||
|
Номер ответа: 80 Автор ответа: LamerOnLineICQ: 334781088 Вопросов: 108 Ответов: 2822 |
Профиль | | #80 | Добавлено: 12.05.05 15:26 |
|
Да, но это верно только для старых процессоров. Сейчас это уже не актуально. Поясни каким образом это потеряло актуальность. в Window все адреса виртуальные (реальный линейный адрес лежит в сегментных регистрах). И выравнивание в виртуальном адресе не будет иметь никакого эффекта в реальном. При чем тут виртуальный адрес? Обращение к памяти идет по физическим адресам, и у 32-разрядной величины наибольшая вероятность оказаться выровненной по 4-кратному адресу. Последовательность 32-битных значений будет считана заметно быстрее чем то же количество 8-битных. Не смотря на крутизну нынешней оперативы обращение к ней до сих пор остается узким местом. |
||
|
Номер ответа: 81 Автор ответа: CyRax Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229 |
Web-сайт: Профиль | | #81 | Добавлено: 12.05.05 15:30 |
|
Да, жаль только что весь исполняемый код в регистры не запихивается. Посему приходится оптимизировать. Как я уже говорил, для VB этим типом оптимизации является использование типа long для переменных в циклах с большим числом итераций. В принципе то что ты сказал верно. Зная что компилятор в любом случае в качестве счётчика цикла будет использовать регистр, можно провести такую оптимизацию. Но это как бы и так ясно. И если счётчик цикла интуитивно можно проконтролировать, то весь остальной код тебе не подконтролен. |
||
|
Номер ответа: 82 Автор ответа: LamerOnLineICQ: 334781088 Вопросов: 108 Ответов: 2822 |
Профиль | | #82 | Добавлено: 12.05.05 15:39 |
| Ну, тут дело не только в счетчике. Большие циклы часто используются для повторяющихся вычислений. В таких случаях имеет смысл заменить на long все операнды, точнее Byte, Integer и Boolean. | ||
|
Номер ответа: 83 Автор ответа: CyRax Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229 |
Web-сайт: Профиль | | #83 | Добавлено: 12.05.05 15:43 |
|
Ну вот тебе.
http://www.codenet.ru/progr/optimize/pentopt/5.php |
||
|
Номер ответа: 84 Автор ответа: CyRax Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229 |
Web-сайт: Профиль | | #84 | Добавлено: 12.05.05 15:44 |
|
Вот ещё про оптимизацию.
http://www.codenet.ru/progr/optimize/asm_opt1.php |
||
|
Номер ответа: 85 Автор ответа: CyRax Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229 |
Web-сайт: Профиль | | #85 | Добавлено: 12.05.05 15:45 |
|
В то же время, если программе предстоит главным образом работать на компьютерах с процессорами 8086 или 80286, следует произвести выравнивание в границах WORD, а если она рассчитана на процессоры 80386DX, 80486DX - используйте выравнивание DWORD. (Для процессора 80486, в котором есть внутренняя кэш-память, лучше, когда позиции лежат на 16-байтовых границах, но тратить в среднем 8 байт на каждую метку мне кажется непозволительной роскошью.) |
||
|
Номер ответа: 86 Автор ответа: CyRax Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229 |
Web-сайт: Профиль | | #86 | Добавлено: 12.05.05 15:53 |
|
Ну, тут дело не только в счетчике. Большие циклы часто используются для повторяющихся вычислений. В таких случаях имеет смысл заменить на long все операнды, точнее Byte, Integer и Boolean. В конечном итоге алгоритм определяется компилятором и например 2 переменных типа Byte могут оказаться байтовыми частями регистра или Integer + 2 байтовых переменных. Если же ты будешь использовать везде Long, то наиболее вероятно что такая грубая оптимизация "под компилятор" приведёт к тому что все эти переменные и будут храниться в памяти. |
||
|
Номер ответа: 87 Автор ответа: HOOLIGANВопросов: 0 Ответов: 1066 |
Профиль | | #87 | Добавлено: 12.05.05 16:03 |
Каким образом потеряло актуальность? Щас попробую изложить, как я понимаю это 
Есть ОЗУ. Есть кэш первого уровня (L1), есть второго уровня (L2). Время доступа к этим областям возрастает в направлении L1->L2->ОЗУ. Это не секрет. При считывании данных из ОЗУ (например, локальных переменных, для примера пусть их будет 5-6 двордов), при считывании первой переменной, соответствующей вершине стека (esp), данные из памяти не поступают непосредственно в регистры. Они сначала попадают в L1. Причём при чтении первой переменной в кэш попадут все наши 5-6 переменных, т.к. процессор подгружает в кэш данные порциями по 32 (или 2х32, в зависимости от проца) байт. А кэш специально для того и служит, чтобы ускорить доступ к наиболее часто используемым данным (что чаще всего и относится к локальным переменным). Т.е. однажды, в самом начале "хапнув" из относительно медленного ОЗУ данные, в дальнейшем мы уже берем данные из быстрого кэша. Это примерно как я понимаю теоретическую сторону дела. Что касается практической, то наверное можно это проверить. Конечно, для этого VB не подойдёт, но проверить можно. Что касается сожалений по поводу того, что весь исполняемы код не загружается в регистры: код вообще в регистры не загружается Но можно организовать алгоритм таким образом, чтобы данные, используемые кодом, находились в регистрах. Очень наглядно это проявляется при компиляции C++ программ (смотрел работу компилятора VC++ 7.1 (.NET). При компиляции с ключём "макс.скорость" и без оного разница - небо и земля. При компиляции на скорость практически не используются переменные, только регистры. Эту разницу даже на глаз видно, насколько агрессивный получается код.
Может показаться, что это противоречит тому, что с памятью (кэшем) работает также быстро, как и с регистрами, но на мой взгляд, всё-таки компилятор должен учитывать, что используются не только новые, но и парк старых процессоров, поэтому он и вынужден избавляться от хранения данных в памяти в пользу использования регистров. В общем не знаю, понятно ли изложил свою точку зрения Или ещё больше запутал
Но можно попробовать и проверить это. |
||
|
Номер ответа: 88 Автор ответа: LamerOnLineICQ: 334781088 Вопросов: 108 Ответов: 2822 |
Профиль | | #88 | Добавлено: 12.05.05 16:04 |
|
Считаешь лучше гадать на кофейной гуще? Меня не устраивают такие пляски с бубном и надеятся на VBшный компилятор, думаю, не стоит. Тем более что практика показывает его "оптимизацию". Для разнообразия состряпай пример циклов с разной разрядностью переменных - сам увидишь разницу.
Кроме того, никто не говорит что это обязательное правило. Решать тут должен программист исходя из конкретной задачи. Как правило, разницы заметно не будет, по крайней мере на VB. В непустых циклах влияние типа данных ничтожно мало и им можно пренебречь (если это, конечно, не String или Variant), также как и лишними 20-30 байтами памяти, выделяемыми под long переменные из 2-3 мегабайт памяти программы. Такой выбор может возникнуть лишь в экстремальной ситуации. Иначе дело вкуса. |
||
|
Номер ответа: 89 Автор ответа: CyRax Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229 |
Web-сайт: Профиль | | #89 | Добавлено: 12.05.05 16:10 |
|
Наверное про устарелость выравнивания я погорячился. Хотя мне кажется я что то такое читал.
Вот ещё интересная инфа по выравниванию: Возникает закономерный вопрос: чем так плох адрес 455С01, что по этому адресу компилятор «не захотел» хранить данные. Ответ на этот вопрос лежит в недрах архитектуры x86. С незапамятных времен процессоры x86 выбирали данные, лежащие по четным адресам, немного быстрее, по сравнению с такими же данными, лежащие по нечетным адресам. Чуть позже процессорам стали «нравиться» адреса, кратные четырем. С совершенствованием процессоров список «хороших» адресов продолжал расширяться, появились «особенные» последовательности команд, которые выполнялись быстрее «обыкновенных» и в результате предельная оптимизация программ стала занятие настолько сложным, что стало проще доверить ее компилятору. Для достижения максимальной производительности программисты старались размещать часто используемые данные именно по таким «хорошим» адресам. А чтобы программисту не приходилось раскладывать данные по нужным адресам вручную, в компиляторы была введена такая опция, как «выравнивание данных». |
||
|
Номер ответа: 90 Автор ответа: MorpheusВопросов: 224 Ответов: 3777 |
Web-сайт: Профиль | | #90 | Добавлено: 12.05.05 16:14 |
|
А булеан та как заменять?! Это в смысле строку как
Bollean_1 = Not Boolean_2
как лучше заменить? Как Bolean_1 = 1 - Boolean_2
или как If Booiean_2 = 1 then
Boolean_1 = 0 Else Boolean_1 = 1 end if |
||