Изилдөө долбоорунун алкагында
Сыноо үчүн
Кийинки этапта, ошондой эле аппараттык платформанын өзгөчөлүктөрүн эске алуу менен процедуралар аралык RTL оптималдаштырууну өзүнчө жиптерге жылдыруу пландаштырылууда. Андан кийин биз чакыруунун өзгөчөлүгүнө карабастан функциянын ичиндеги кодго колдонулган процедура ичиндеги оптималдаштырууну (IPA) параллелизациялоону ишке ашырууну пландаштырып жатабыз. Азырынча чектөөчү шилтеме таштанды жыйноочу болуп саналат, ал көп жиптүү режимде иштеп жатканда таштанды чогултуу операцияларын өчүрүүчү глобалдык кулпуну кошту (келечекте таштанды жыйноочу GCCдин көп жиптүү аткарылышына ылайыкталат).
Өндүрүштөгү өзгөрүүлөрдү баалоо үчүн gimple-match.c файлын чогулткан тест топтому даярдалды, ал 100 миңден ашык код саптарын жана 1700 функцияны камтыйт. 5 физикалык өзөктүү жана 8250 виртуалдык (Hyperthreading) менен Intel Core i4-8U CPU менен системадагы тесттер 7 жипти иштеткенде GIMPLE ички оптималдаштырууларынын аткарылуу убактысынын 4 жипти иштеткенде 2ден 3 секундага чейин жана 4 иштеткенде 1.72 секундага чейин кыскарганын көрсөттү. жиптер, б.а. Каралып жаткан монтаждоо стадиясынын ылдамдыгын 2.52 жана XNUMX эсеге жогорулатууга жетишилди. Тесттер ошондой эле Hyperthreading менен виртуалдык өзөктөрдү колдонуу өндүрүмдүүлүктү жогорулатууга алып келбей турганын көрсөттү.
Жалпы куруу убактысы болжол менен 10% га кыскарды, бирок болжолдоолор боюнча RTL оптималдаштырууну параллелизациялоо кыйла олуттуу натыйжаларга жетишүүгө мүмкүндүк берет, анткени бул этап компиляция учурунда кыйла көбүрөөк убакытты талап кылат. Болжол менен RTL параллелдештирүүдөн кийин жалпы чогултуу убактысы 1.61 эсеге кыскарат. Андан кийин, IPA оптималдаштырууну параллелизациялоо аркылуу куруу убактысын дагы 5-10% кыскартууга болот.
Source: opennet.ru