Да знаеш къде да поставиш Нула
Превод. Оригиналът е на Брус Доусън: „Knowing Where to Type ‘Zero’“
За някои оптимизации са нужни комплицирани структури от данни и хиляди редове сорс код. В други случаи напълно минималната интервенция дава сериозен приръст на продуктивността и от време на време е задоволително да знаеш къде да поставиш нула. Ситуацията много наподобява на историята за локомотивния ватман, който напълно тъкмо знае къде да удари стоманата и предлага забавен метод да му се заплаща за тази работа: $0,50 за един удар или $999,50, с цел да те научи къде да удряш. Идеята е, че можете да знаете доста, само че би трябвало да можете да прилагате в действителния живот това, което знаете.
Значението на вярното премерване
Във времената на истинската Xbox аз помогнах в оптимизацията на доста игри. В една от тях профилирането сподели функционалност за матрична промяна, която отнемаше 7% от ресурса на централния процесор. В показаната диаграма това е най-големият пик. Наложи се деликатно да прегледам и усъвършенствам тази функционалност.
Виждаше се, че не съм първият, който е правил това. Функцията бе пренаписана на асемблер. Намерих някои места за евентуално усъвършенстване на кода и се заех да меря резултата от тях. Това е значимо, тъй като елементарно можеш да се заемеш с „оптимизация“, която нищо няма да промени и даже може да утежни обстановката.
Но това премерване се оказа прекомерно мъчно. Пусках играта, по едно и също време с това се занимавах с профилиране, а по-късно изучавах профила. Стори ми се, че има известно възстановяване, само че напълно едва.
Тогава взех решение да употребявам научния способ. Създадох сбирка от проби за ръководство на остарялата и новата версия на кода, с цел да мога напълно тъкмо да измеря разликите в продуктивността. Това не лиши доста време и както чаках, новият код се оказа с към 10% по-бърз от остарелия.
Но бързо стана ясно, че 10% нищо не са.
Много по-интересно бе, че в моите проби кодът се извършва 10 пъти по-бързо. Ето това бе същинско изобретение.
След като за следващ път прегледах резултатите, известно време гледах в празното пространство, само че по-късно ме осени.
Ролята на кеширането
За да даде цялостен надзор на разработчиците и оптимално допустима продуктивност, конзолите дават опция за заделяне наизуст с разнообразни атрибути. Така да вземем за пример, истинската Xbox дава опция за заделяне наизуст, която няма да се кешира. Това е извънредно значимо, тъй като не би трябвало да се дава опция на играта да чете от некешираната памет. Този вид памет е потребен при записа на данни на графичния процесор. Понеже паметта не се кешира, данните незабавно се записват в оперативната памет без задръжки и замърсяване на кеша.
Некешираната памет е значима оптимизация, само че би трябвало да се употребява доста деликатно. Така да вземем за пример, доста е значимо играта в никакъв случай да не се пробва да чете от некешираната памет, тъй като продуктивността съществено ще падне. Дори и релативно бавният CPU с тактова периодичност едва 733 MHz има потребност от свои кешове, с цел да обезпечи задоволителна продуктивност при четенето на данни.
Сега излиза наяве, какво тъкмо се случва. По всичко си проличава, че данните на изследваната от мен функционалност се записват точно в некешираната памет и отсам идва ниската продуктивност. Беглата инспекция удостовери тази догадка и настъпи време да се оправи казуса. Намерих реда в сорс кода, където се заделя памет за тази функционалност, два пъти кликнах по смисъла на флага и сложих нула.
Вместо първичните 7% от от процесорния запас, в този момент функционалността стартира да употребява единствено към 0,7% и повече не създаваше проблеми.
Сериозно, моят доклад пред мениджмънта изглеждаше по следния метод: „39,99 часа изследване и проучване, 0,001 часа програмиране – съотношението е положително и това е един нелош успех“.
Обикновено, на програмистите и разработчиците не се постанова да мислят и да се безпокоят за инцидентно заделяне на некеширана памет: в множеството операционни системи тази алтернатива не е налична и няма по какъв начин да бъде достигната в потребителски акаунт посредством общоприетите способи. Но в случай че ви е забавно, до каква степен некешираната памет може да забави една стратегия, пробвайте флаговете PAGE_NOCACHE и PAGE_WRITECOMBINE във VirtualAlloc.
0 GB от време на време са по-добре от 4 GB
Още една история. Тя е за бъга, който открих аз, а го оправи различен. Преди две години забелязах, че дисковият кеш на моя преносим компютър прекомерно постоянно се почиства. Видях че това става навръх границата на 4 GB. Оказа се, че драйверът на моя напълно нов хард диск, който употребявам за архиви, инциализира SectorSize в 0xFFFFFFFF (или −1), при указване на незнаен размер на бранша. Ядрото на Windows интерпретира това значение като 4 GB и заделя съответния блок кеш памет. Това бе казусът.
Няма познати във Western Digital, само че мога да се обзаложа, че те са оправили тази неточност, като са заменили константата 0xFFFFFFFF (или −1) с нула. Един единствен въведен знак, а е решен сериозен проблем в продуктивността.
ОбобщениеИ в двата случая казусът е обвързван с кеширанетоРешаващо бе потреблението на подобаващ програмен продукт за профилиране на тъкмо избран проблемБих могъл да опиша редица сходни случаи, само че те или са секретни, или са скучниПравилното решение не е наложително да бъде комплицирано. Понякога напълно дребна смяна дава доста усъвършенстване. Трябва единствено да знаеш точното място
За някои оптимизации са нужни комплицирани структури от данни и хиляди редове сорс код. В други случаи напълно минималната интервенция дава сериозен приръст на продуктивността и от време на време е задоволително да знаеш къде да поставиш нула. Ситуацията много наподобява на историята за локомотивния ватман, който напълно тъкмо знае къде да удари стоманата и предлага забавен метод да му се заплаща за тази работа: $0,50 за един удар или $999,50, с цел да те научи къде да удряш. Идеята е, че можете да знаете доста, само че би трябвало да можете да прилагате в действителния живот това, което знаете.
Значението на вярното премерване
Във времената на истинската Xbox аз помогнах в оптимизацията на доста игри. В една от тях профилирането сподели функционалност за матрична промяна, която отнемаше 7% от ресурса на централния процесор. В показаната диаграма това е най-големият пик. Наложи се деликатно да прегледам и усъвършенствам тази функционалност. Виждаше се, че не съм първият, който е правил това. Функцията бе пренаписана на асемблер. Намерих някои места за евентуално усъвършенстване на кода и се заех да меря резултата от тях. Това е значимо, тъй като елементарно можеш да се заемеш с „оптимизация“, която нищо няма да промени и даже може да утежни обстановката. Но това премерване се оказа прекомерно мъчно. Пусках играта, по едно и също време с това се занимавах с профилиране, а по-късно изучавах профила. Стори ми се, че има известно възстановяване, само че напълно едва.
Тогава взех решение да употребявам научния способ. Създадох сбирка от проби за ръководство на остарялата и новата версия на кода, с цел да мога напълно тъкмо да измеря разликите в продуктивността. Това не лиши доста време и както чаках, новият код се оказа с към 10% по-бърз от остарелия. Но бързо стана ясно, че 10% нищо не са.
Много по-интересно бе, че в моите проби кодът се извършва 10 пъти по-бързо. Ето това бе същинско изобретение.
След като за следващ път прегледах резултатите, известно време гледах в празното пространство, само че по-късно ме осени.
Ролята на кеширането
За да даде цялостен надзор на разработчиците и оптимално допустима продуктивност, конзолите дават опция за заделяне наизуст с разнообразни атрибути. Така да вземем за пример, истинската Xbox дава опция за заделяне наизуст, която няма да се кешира. Това е извънредно значимо, тъй като не би трябвало да се дава опция на играта да чете от некешираната памет. Този вид памет е потребен при записа на данни на графичния процесор. Понеже паметта не се кешира, данните незабавно се записват в оперативната памет без задръжки и замърсяване на кеша.
Некешираната памет е значима оптимизация, само че би трябвало да се употребява доста деликатно. Така да вземем за пример, доста е значимо играта в никакъв случай да не се пробва да чете от некешираната памет, тъй като продуктивността съществено ще падне. Дори и релативно бавният CPU с тактова периодичност едва 733 MHz има потребност от свои кешове, с цел да обезпечи задоволителна продуктивност при четенето на данни.
Сега излиза наяве, какво тъкмо се случва. По всичко си проличава, че данните на изследваната от мен функционалност се записват точно в некешираната памет и отсам идва ниската продуктивност. Беглата инспекция удостовери тази догадка и настъпи време да се оправи казуса. Намерих реда в сорс кода, където се заделя памет за тази функционалност, два пъти кликнах по смисъла на флага и сложих нула.
Вместо първичните 7% от от процесорния запас, в този момент функционалността стартира да употребява единствено към 0,7% и повече не създаваше проблеми.
Сериозно, моят доклад пред мениджмънта изглеждаше по следния метод: „39,99 часа изследване и проучване, 0,001 часа програмиране – съотношението е положително и това е един нелош успех“.
Обикновено, на програмистите и разработчиците не се постанова да мислят и да се безпокоят за инцидентно заделяне на некеширана памет: в множеството операционни системи тази алтернатива не е налична и няма по какъв начин да бъде достигната в потребителски акаунт посредством общоприетите способи. Но в случай че ви е забавно, до каква степен некешираната памет може да забави една стратегия, пробвайте флаговете PAGE_NOCACHE и PAGE_WRITECOMBINE във VirtualAlloc.
0 GB от време на време са по-добре от 4 GB
Още една история. Тя е за бъга, който открих аз, а го оправи различен. Преди две години забелязах, че дисковият кеш на моя преносим компютър прекомерно постоянно се почиства. Видях че това става навръх границата на 4 GB. Оказа се, че драйверът на моя напълно нов хард диск, който употребявам за архиви, инциализира SectorSize в 0xFFFFFFFF (или −1), при указване на незнаен размер на бранша. Ядрото на Windows интерпретира това значение като 4 GB и заделя съответния блок кеш памет. Това бе казусът. Няма познати във Western Digital, само че мога да се обзаложа, че те са оправили тази неточност, като са заменили константата 0xFFFFFFFF (или −1) с нула. Един единствен въведен знак, а е решен сериозен проблем в продуктивността.
ОбобщениеИ в двата случая казусът е обвързван с кеширанетоРешаващо бе потреблението на подобаващ програмен продукт за профилиране на тъкмо избран проблемБих могъл да опиша редица сходни случаи, само че те или са секретни, или са скучниПравилното решение не е наложително да бъде комплицирано. Понякога напълно дребна смяна дава доста усъвършенстване. Трябва единствено да знаеш точното място
Източник: kaldata.com
КОМЕНТАРИ