Жарым-статикалык шарт (semi-static condition) — иштөө учурунда тандала турган аткаруу багытын өзгөртүү менен бирге кечигүүгө сезимтал код жолунда салттуу шарттуу бутакты баалоо зарылдыгын жок кылуу үчүн иштеп жаткан аткарылуучу файлдын машина кодундагы салыштырмалуу секирүү максатын өзгөрткөн C++ башкаруу агымынын түзүмү. Paul Alexander Bilokon, Maximilian Lucuta жана Erez Shermer иштеп чыккан ыкма кымбатка турган шартты баалоо жана машина кодун өзгөртүү операциясын аткарымдуулук боюнча критикалык эмес жолго жылдырып, критикалык жолдогу branch чакыруусун түз функция чакыруусуна жакын чыгымдагы салыштырмалуу секирүүгө айлантууну көздөйт.

Изилдөөнүн негизги идеясы заманбап процессорлор шарттуу бутактарды ар бир жолу жакшыраак божомолдосун деп аракет кылгандан көрө, айрым колдонуу сценарийлеринде божомолдоого тийиш болгон шарттуу бутакты критикалык аткаруу жолунан толугу менен алып салуу болуп саналат. Бул үчүн set_direction операциясы кайсы функция иштетилерин алдын ала аныктайт жана тиешелүү 32-bit салыштырмалуу секирүү офсетин иштеп жаткан коддун ичине жазат; андан кийин branch чакыруусу шартты кайра баалабастан ошол максатка багытталат.

Intel Core i7-10700 үстүндө жүргүзүлгөн микробенчмарктарда түз функция чакыруусунун медианалык баасы 9 CPU цикли, жарым-статикалык branch чакыруусунун медианасы 10 цикл жана экөөнүн тең стандарттык четтөөсү 1 цикл деп өлчөнгөн. Кокус жана божомолдоо кыйын болгон эки багыттуу HFT-тектүү ысык жол тестинде кэшти ысытпай салттуу шарттуу бутактануу 75 цикл медиана жана 10 цикл стандарттык четтөө көрсөткөн, ал эми жарым-статикалык шарттар 63 цикл медиана жана 3 цикл стандарттык четтөө көрсөткөн. Кэшти ысытуу менен көрсөткүчтөр тиешелүүлүгүнө жараша 68±8 жана 62±2 цикл болгон.

Артыкчылык шартсыз эмес. Иштеп жаткан машина кодун өзгөртүү self-modifying code (SMC) механизмдерин иштетиши мүмкүн. Assembly өзгөртүүсүнөн дароо кийин өзгөртүлгөн код аткарылган тестте SMC machine clear таасирлери аткаруу убактысын болжол менен 30–40 эсе көбөйтүп, болжол менен 100 циклдик кошумча жазалар байкалган. Ошондуктан ыкма branch багыты тез-тез өзгөртүлүп, андан дароо кийин аткарылган тыгыз циклдер үчүн ылайыктуу эмес. Изилдөө сунуш кылган колдонуу модели кымбат set_direction операциясын “муздак” жолго жылдырып, арзан branch операциясын кечигүүгө сезимтал “ысык” жолдо колдонуу болуп саналат.

Жарым-Статикалык Шарт Деген Эмне?

Жарым-статикалык шарт — шартты баалоону жана тандалган код бутактын аткарылышын эки өзүнчө убакыт операциясына бөлүп, тандалган бутакты кийин салыштырмалуу машина-код секирүүсү аркылуу чакырган программалык башкаруу агымынын түзүмү. “Статикалык” жагы критикалык branch чакыруусу учурунда максат алдын ала аныкталгандыгында; “жарым” жагы программа иштеп жатканда бул максатты set_direction аркылуу кайра өзгөртө ала тургандыгында.

Кадимки C++ шарттуу туюнтмасынын логикасы түшүнүк жагынан мындай: процессор шартты окуйт, салыштыруу жүргүзөт, шарттуу секирүү буйругуна жетет жана branch predictor кайсы жол аткарыларын божомолдойт. Божомол туура болсо чыгым аз; туура эмес болсо спекулятивдүү түрдө алынган жана жарым-жартылай иштетилген буйруктарды тазалоо талап кылынышы мүмкүн.

Жарым-статикалык ыкмада шарт критикалык жол башталганга чейин бааланат. Программа кайсы функция максат болорун аныктап, branch кирүү чекитиндеги салыштырмалуу jmp буйругунун displacement талаасын өзгөртөт. Критикалык окуя келгенде шарт кайра окулбайт; башкаруу агымы түз эле алдын ала тандалган функцияга багытталат.

Эмне үчүн классикалык branch predictor жетиштүү деп эсептелген эмес?

Заманбап branch predictor-лор көптөгөн бутактарды өтө жогорку тактыкта божомолдой алат. Изилдөө өзгөчө мурунку тарых менен күчтүү корреляциясы жок, киргизүү маалыматтарына көз каранды же сейрек аткарылгандыктан жетиштүү тарых түзбөгөн бутактарга көңүл бурат. Бул маселе HFT сыяктуу төмөн кечигүү системаларында маанилүү; анткени критикалык жол үзгүлтүксүз иштебеши мүмкүн, бирок иштеген учурда мүмкүн болушунча төмөн жана алдын ала болжолдоого мүмкүн болгон кечигүүнү көрсөтүшү керек.

C++20дагы [[likely]] жана [[unlikely]] атрибуттары бул маселени аппараттык branch predictor-го түз эле “бул бутакты божомолдо” деген буйрук жөнөтүү менен чечпейт. Булакта түшүндүрүлгөндөй, компилятор бул маалыматты коддун жайгашуусун жана мүмкүн болгон ысык/муздак жолдордун assembly түзүлүшүн өзгөртүү үчүн колдонот. Реалдуу убакыттагы шарттардын бөлүштүрүлүшү кийин өзгөрсө, компиляция учурундагы бул тандоо динамикалык түрдө жаңыртылбайт.

Жарым-Статикалык Шарттар Бутакты Божомолдоодон Кантип Айырмаланат?

Жарым-статикалык шарттар шарттуу бутактын жыйынтыгын жакшыраак божомолдоого аракет кылбастан, критикалык жолдогу шарттуу бутак буйругун программист багытын өзгөртө ала турган түз салыштырмалуу секирүүгө айландырат. Ошентип execute баскычында аныкталуучу классикалык шарттуу-бутак туура эмес божомолдорунун ордуна максат өзгөргөндө андан эртерээк баскычта пайда болушу мүмкүн болгон BTB/BAC максат түзөтүүлөрү келет.

BranchChanger түзүмү

Прототиптеги негизги абстракция — BranchChanger классы. Класс башында эки функциянын дарегин алат. set_direction(condition) аткаруу учурундагы шартка жараша кайсы максат активдүү болорун аныктайт; branch(...) болсо тандалган максатка өтөт.

Функциялардын аргумент жана кайтаруу типтери template deduction аркылуу алынат. Ошентип branch кирүү чекитинин сигнатурасы максат функциялардын чакыруу конвенциясына шайкеш келтирилет. Булакта кадимки мүчө функция жашыруун this көрсөткүчүн жараткандыктан башында пайда болгон регистр жылышы көйгөйү түшүндүрүлүп, негизги прототипте branch методун статикалык кылуу тандалган.

Салыштырмалуу секирүү офсети

x86 архитектурасындагы салыштырмалуу jmp/call механизминде максат дареги түздөн-түз толук дарек катары эмес, учурдагы буйрук жайгашкан жерге салыштырмалуу displacement катары коддолот. Булак колдонгон негизги байланыш төмөнкүдөй:

Jump Offset — машина буйругуна жазыла турган салыштырмалуу аралык. Target Address — аткарыла турган if/else функциясынын кирүү дареги. Entry Point өзгөртүлүп жаткан branch кирүү чекитин, ал эми Size of Instruction салыштырмалуу секирүү буйругунун узундугун билдирет. x86 ишке ашыруусунда бир байттык e9 opcode жана андан кийинки төрт байттык displacement талаасы колдонулат.

Бул математика branch жүрүм-туруму эмне үчүн жөн гана Boolean өзгөрмөсүн өзгөртүү эмес экенин көрсөтөт. Программа аткарылуучу код сегментинин жайгашуусун, максат функциянын дарегин жана буйруктун узундугун эске алып, чыныгы машина кодун өзгөртөт.

Иштеп жаткан код кантип өзгөртүлөт?

Машина буйруктары адатта виртуалдык дарек мейкиндигиндеги executable/text барактарында жайгашат жана жазууга жабык болот. Прототип аткаруу учурунда branch функциясынын дарегинен тиешелүү баракты табат, Linux mprotect механизми аркылуу барактын уруксаттарын өзгөртүп, салыштырмалуу секирүүнүн displacement талаасын жазыла турган абалга келтирет.

Address Space Layout Randomization (ASLR) себебинен аткарылуучу коддун чыныгы runtime дареги алдын ала туруктуу деп кабыл алынбайт. Ошондуктан даректи чечүү жана баракты тегиздөө операциялары программа иштеп жаткан учурда аткарылат.

Branch-Changing жана Branch-Taking Эмне Үчүн Бөлүнөт?

Бул эки операция бөлүнөт, анткени branch багытын өзгөртүү иштеп жаткан executable эс тутумга жазууну талап кылган салыштырмалуу кымбат операция; branch-taking болсо туура даярдалган абалда түз функция чакыруусуна кошулган кыска салыштырмалуу секирүүнүн чыгымына чейин азайтылышы мүмкүн. Булактын оптималдаштыруу стратегиясы кымбат операцияны кечигүүгө сезимтал эмес коддо амортизациялап, критикалык жолдо арзан операцияны гана калтыруу болуп саналат.

Self-modifying code жазасы

Процессорлор иштеп жаткан кодду өзгөртүүнү колдогону менен instruction cache, pipeline жана тиешелүү спекулятивдүү абалдар өзгөртүлгөн буйруктар менен шайкеш келбей калышы мүмкүн. Булактагы тесттер executable эс тутумга төрт байт жазуунун өзү кадимки эс тутумга төрт байттык memcpy операциясынан олуттуу кымбат эмес экенин көрсөткөн: эки учурда тең медиана болжол менен 9 цикл жана стандарттык четтөө 1 цикл.

Чыныгы жогорку чыгым өзгөртүлгөн буйрук өтө кыска убакыттан кийин аткарылганда пайда болгон. Мындай учурда процессор self-modifying code аныкталгандан кийин machine clear жаратышы мүмкүн; булак тестинде бул жүрүм-турум болжол менен эки тазалоо/итерация деңгээлине жетип, жалпы аткаруу убактысын болжол менен 30–40 эсе көбөйтүп, SMC таасири болжол менен 100 цикл деңгээлинде кошумча чыгым жараткан.

Бул табылга жарым-статикалык шарттар ар бир if туюнтмасынын ордуна коюла турган жалпы drop-in оптималдаштыруу эмес экенин көрсөтөт. set_direction жана branch дайыма удаа аткарылса, ыкманын негизги артыкчылыгы жоголушу мүмкүн.

BTB жана BAC таасири

Branch Target Buffer (BTB) процессорго белгилүү бир program counter позициясында бутак бар экенин жана максат кайда экенин божомолдоого жардам берген аппараттык түзүм. Branch Address Calculator (BAC) болсо максат дарегин текшерүүдө роль ойнойт. Жарым-статикалык шарттын салыштырмалуу jmp максаты өзгөртүлгөндө BTBде эски максат калышы мүмкүн.

Изилдөөдөгү тажрыйбаларда тынымсыз өзгөртүлгөн максаттар BAC түзөтүүлөрүн көбөйткөн. Эсептөө буфери кошулганда түзөтүүлөрдүн саны болжол менен эки эсе азайып, бир итерацияга болжол менен бирге түшкөн. Авторлор BAC түзөтүүсү үчүн болжол менен 2,2 ns, башкача айтканда колдонулган процессордо болжол менен 6 цикл кошумча чыгым өлчөшкөн. Бул чыгым шарттуу бутактын туура эмес божомолунан төмөн жана эң маанилүүсү — критикалык жол ишке кирерден мурда “warming” чакыруусу менен алдын ала төлөнүшү мүмкүн.

Активдүү branch warming

Булактын маанилүү сунуштарынын бири branch багыты өзгөртүлгөндөн кийин муздак жолдо жасалма же таасирсиз чакыруу менен branch методун иштетүү. Бул чакыруу учурдагы максатты BTBге үйрөтүүгө, керектүү instruction-cache маалыматтарын ысытууга жана SMC таасирлерин критикалык жолдон алыстатууга жардам берет. HFT мисалында изилдөө муну концептуалдык түрдө “dummy order” чакыруусу менен түшүндүрөт.

HFT системасындагы орду

Булактын 7-сүрөтүндөгү жөнөкөйлөштүрүлгөн HFT архитектурасында рыноктук маалымат тармак катмарынан каржы протоколуна, order book-ка жана атайын колдонмо логикасына жетет; изилдөө сунуш кылган оптималдаштыруу атайын колдонмо тарабындагы order-action критикалык жолуна багытталган. Ыкма тармак кечигүүсүн, exchange matching engine кечигүүсүн же FPGAнын өз иштетүү убактысын түздөн-түз оптималдаштырган техника эмес.

Коопсуздук

Иштеп жаткан executable барагын read/write/execute кылуу коопсуздук бетин кеңейтет. Булак бул тобокелдикти кабыл алып, set_direction_safe ыкмасында баракты өзгөртүү учурунда гана жазыла турган кылып, андан кийин кайра read/execute абалына кайтарууну сунуштайт. Мунун баасы эки системалык чакыруу жана жогорураак кечигүү/jitter. Демек, изилдөөдө коопсуздук менен эң төмөн кечигүүнүн ортосунда ачык инженердик компромисс бар.

Thread safety

Assembly максаты бардык чакыруулар бөлүшкөн коддун бир бөлүгү болгондуктан, бир thread максатты өзгөртүп жатканда башка thread branch чакыруусун аткара алат. Булактагы тесттер синхрондоштуруусуз туура эмес бутак сейрек болсо да аткарылышы мүмкүн экенин көрсөткөн. Mutex сыяктуу синхрондоштуруу туура жүрүм-турумду камсыз кылат, бирок аткарымдуулук артыкчылыгынын олуттуу бөлүгүн жок кылат.

Портативдүүлүк

Китепкана CMake колдонгон статикалык китепкана катары пакеттелген. Булактын шайкештик таблицасы Windows x86-64 жана Linux x86-64да GCC, MSVC жана Clang үчүн, ошондой эле Linux ARMда GCC жана Clang үчүн сыноодон өткөн/иштеген комбинацияларды билдирет. macOS комбинациялары иштейт деп белгиленген эмес. Өзгөчө Apple Silicon Hardened Runtime системасынын write/execute барак уруксаттарына болгон чектөөлөрү учурдагы ыкма үчүн маанилүү тоскоолдук катары көрсөтүлөт.

Изилдөөнүн Ыкмасы жана Жыйынтыктары

Изилдөө эки этап менен жүргүзүлгөн. Биринчи этапта C++ деңгээлинде BranchChanger прототиби, calling convention шайкештиги, template deduction, assembly түзөтүү, compiler оптималдаштырууларына каршы коргоо, relative jump жана портативдүүлүк механизмдери иштелип чыккан. Экинчи этапта branch-changing жана branch-taking компоненттери CPU циклдери, аткарымдуулук эсептегичтери жана жогорку деңгээлдеги микробенчмарктар аркылуу өлчөнгөн.

Иштеп чыгуу жана эксперименттик чөйрө

• Иштетүү системасы: Linux, Ubuntu дистрибутиви.
• Компилятор: GCC 13.1.
• Иштеп чыгуу тили: Булактын иштеп чыгуу бөлүмүндө C++20.
• Негизги benchmark CPU: Intel Core i7-10700, 2,90 GHz.
• Булакта көрсөтүлгөн кэш сыйымдуулугу: 256 KB L1 instruction/data, 2 MB L2 жана 16 MB L3.
• Төмөн деңгээлдеги убакыт өлчөөсү: RDTSC.
• Сериализация: LFENCE.
• Аткарымдуулук эсептегичтери: Linux perf жана perf_event_open.
• Жогорку деңгээлдеги тесттер: Google Benchmark.

RDTSC өлчөөлөрүндө процессордун out-of-order аткаруусу өлчөө аралыгын бузбашы үчүн LFENCE колдонулган. Өлчөө инфраструктурасынын өз чыгымы бош өлчөө циклин көп жолу кайталоо менен аныкталып, кийинки жыйынтыктардан алып салынган. Булак айрым instruction-level тесттерде болжол менен \(10^7\) кайталоо колдонгон.

Негизги benchmark жыйынтыктары

Булактын 16-сүрөтүндө кокус шарттар менен жүргүзүлгөн эки багыттуу тесттин conditional-branch бөлүштүрүлүшү бимодалдуу. Cache warming жок кезде predicted жана mispredicted топтор болжол менен 65 жана 78 цикл; warming менен болжол менен 64 жана 80 цикл борборлорунда көрүнөт. Алардын ортосундагы 13–16 цикл айырма изилдөө колдонгон архитектурада классикалык туура эмес божомол жазасынын чоңдугун көрсөтөт.

Авторлордун эсебине ылайык жарым-статикалык шарттар бул тажрыйбада орточо болжол менен 2–4 ns, ал эми бутак дайыма туура эмес божомолдонгон учурда болжол менен 6 ns үнөм берген. Бул маанилер жалпы C++ кепилдиги эмес; алар өлчөнгөн процессорго, код жайгашуусуна, кэш абалына, компиляторго жана тест сценарийине мүнөздүү.

[[likely]] жана [[unlikely]] эмне үчүн кокус шарттарда жардам берген жок?

Кокус түзүлгөн Boolean шарттарда эки багыт болжол менен бирдей ыктымалдуу болгондуктан, компилятордун статикалык код жайгашуусу реалдуу runtime жүрүм-турумду божомолдой алган эмес. Булактагы тесттерде [[likely]] жана [[unlikely]] колдонуу туура эмес божомол көрсөткүчүн азайткан эмес. Бул жыйынтык ушул тест түзүлүшүнүн шарттарында гана жарактуу; атрибуттар бардык программаларда натыйжасыз дегенди билдирбейт.

N-багыттуу бутактануу

Булак кокус тандалган n-багыттуу if/else же switch түзүмүндө варианттардын саны көбөйгөн сайын туура максатты божомолдоо кыйындай турганын белгилейт. Беш абалдуу switch тестинде булактын 18-сүрөтү салттуу switch үчүн 30 цикл медиана жана 8 цикл стандарттык четтөө; жарым-статикалык шарт үчүн 8 цикл медиана жана 1 цикл стандарттык четтөө көрсөткөнүн билдирет. Бул тажрыйбада колдонулган бутактар бош функциялар болгондуктан, жыйынтыкты реалдуу өндүрүш иш жүгүнүн түз аткарымдуулугу катары чечмелөөгө болбойт.

Божомолдоого боло турган бутактарда эмне болду?

Шарт ар 1000 итерацияда бир жолу өзгөртүлгөндө conventional branch 64 цикл медиана жана 3 цикл стандарттык четтөө, жарым-статикалык ыкма 62 цикл медиана жана 2 цикл стандарттык четтөө көрсөткөн; булак бул салыштыруу үчүн \(P<0.000001\) берет. Авторлор болжол менен 2–3 циклдик кичине айырманы compiler алдыга жана артка branch жолдорунда түзгөн ар башка assembly жайгашуулары менен байланыштырышат.

Switch түзүмдөрүндө бул код жайгашуу таасири андан да көрүнүктүү болуп, изилдөөдө айрым predictable-switch шарттарында жарым-статикалык жол болжол менен 5–6 цикл ылдамыраак экени айтылган.

Branch-changing чыгымы

Төрт байттык багыт өзгөртүүнүн изоляцияланган чыгымы төмөн көрүнгөнү менен, жазылган дарек мурда instruction cache/pipeline түзүмдөрүндө болгон болсо SMC machine clear пайда болушу мүмкүн. Жакын убакыттагы edit-and-execute сценарийинде булак болжол менен 30–40 эсе жайлоону билдирген. Бул ыкманын дизайнындагы эң маанилүү чектөө.

CLFLUSH аркылуу тиешелүү instruction-cache саптарын тазалоо жана assembly edit менен branch-taking ортосуна эсептөө буферин жайгаштыруу machine clear санын азайткан; бирок чыгымды толугу менен жок кылган эмес. Ошондуктан булак багыт өзгөрүшү менен branch-taking ортосундагы убакыттык жана микроархитектуралык аралыкты критикалык оптималдаштыруу параметри катары карайт.

Ишенимдүүлүк жана параллелдүүлүк

Бир threadдүү тууралык тесттеринде багыт тынымсыз өзгөртүлүп, бутак дароо иштетилгенде күтүлгөн функция аткарылганы тастыкталган. Көп threadдүү учурда assembly жазуу атомдук жогорку деңгээлдеги branch тандоосун камсыз кылбагандыктан race condition пайда болушу мүмкүн. Синхрондоштуруу туура эмес бутак аткарылуу тобокелдигин жоёт, бирок булактагы салыштыруулар аткарымдуулук олуттуу төмөндөй турганын көрсөтөт.

Бул Benchmarkтар Реалдуу HFT Өндүрүш Системасында Ошол Эле Утушту Далилдейби?

Жок. Изилдөө реалдуу рыноктук маалыматтарды, өндүрүштүк тармак инфраструктурасын, exchange байланышын жана толук жөндөлгөн HFT kernel чөйрөсүн end-to-end benchmark кылган эмес; жыйынтыктар CPU жана микробенчмарк деңгээлинде, өндүрүш жүрүм-турумун жарым-жартылай окшоштурган тесттерден алынган. Ошондуктан наносекунд деңгээлиндеги артыкчылыктар ыкманын потенциалын көрсөтөт, бирок реалдуу trading системасында дал ушундай көлөмдөгү end-to-end утушту кепилдебейт.

Авторлор evaluation бөлүмүндө root укугу жок болгондуктан CPU scaling жана scheduler сыяктуу kernel жөндөөлөрүн чыныгы HFT системасындагы деңгээлде конфигурациялай албаганын белгилешет. Мындан тышкары pseudo-realistic микробенчмарктар реалдуу өндүрүш trading системасын толук өкүлчүлүк кылбай турганын ачык кабыл алышат.

Булактын акыркы сүрөтү келечекте күчтүүрөөк текшерүү үчүн өзүнчө market-data replay серверинен, жогорку тактыктагы timestamp функциясы бар тармактык switchтен, өлчөнүүчү өндүрүш системасынан жана жооп убакыттарын эсептеген өзүнчө өлчөө серверинен турган тажрыйба түзүлүшүн сунуштайт.

Изилдөө колдогон жыйынтыктар

• Жарым-статикалык branch чакыруусу изилденген архитектурада түз функция чакыруусуна өтө жакын аткаруу чыгымына чейин азайтылган.
• Тез-тез туура эмес божомолдонгон branch'тарда branch-changing критикалык жолдон тышкары кармалганда төмөн медианалык кечигүү жана төмөн latency variance өлчөнгөн.
• Шарттуу branch misprediction чыгымынын ордуна төмөн чыгымдуу максат түзөтүү механизмдери колдонулушу мүмкүн.
• SMC machine clear ыкманын негизги аткарымдуулук чектөөлөрүнүн бири.
• Багыт өзгөрүүсү менен branch-taking жетиштүү бөлүнсө, кымбат өзгөртүү чыгымы көп сандагы арзан branch чакыруусуна бөлүштүрүлүшү мүмкүн.
• Thread safety, коопсуздук жана платформалык портативдүүлүк практикалык негизги чектөөлөр.

Изилдөө колдобогон жыйынтыктар

• Жарым-статикалык шарттар ар бир C++ if же switch түзүмүнөн ылдамыраак экени көрсөтүлгөн эмес.
• Ар бир CPU архитектурасында ошол эле цикл же наносекунд утушу алынары көрсөтүлгөн эмес.
• Реалдуу биржада жогору соода кирешелүүлүгү эмпирикалык өлчөнгөн эмес.
• Реалдуу өндүрүш HFT системасында end-to-end market-data-to-order latency тажрыйбасы жүргүзүлгөн эмес.
• Thread-safe синхрондоштуруу кошулган колдонуу ошол эле аткарымдуулук артыкчылыгын сактай турганы көрсөтүлгөн эмес.
• Assembly editing ыкмасы стандарттык C++ жүрүм-туруму деп ырасталбайт.
• Коопсуз RWX башкаруусу аткарымдуулук чыгымысыз ишке ашырылары көрсөтүлгөн эмес.

Булак жана Ыкма Жөнүндө Эскертүү

Түп нуска аталышы: Semi-static Conditions in Low-latency C++ for High Frequency Trading: Better than Branch Prediction Hints

Авторлор: Paul Alexander Bilokon; Maximilian Lucuta; Erez Shermer.

Preprint аффилиациялары: Paul Alexander Bilokon — Department of Computing жана Department of Mathematics, Imperial College London; Maximilian Lucuta — Department of Computing, Imperial College London; Erez Shermer — qSpark LLC, Wilmington, Delaware, АКШ.

Жүктөлгөн булак: arXiv:2308.14185v1 [cs.PF], 27 август 2023. Жүктөлгөн файл өзүн ачык түрдө “A PREPRINT” деп мүнөздөйт.

Кийинки жарыялоо абалы: Библиографиялык текшерүүдө изилдөө кийин Journal of Parallel and Distributed Computing, Том 196, Макала 105000 катары жарыяланганы тастыкталган. Журнал версиясынын DOI'си 10.1016/j.jpdc.2024.105000. Бул Verianla текстиндеги эксперименттик маалыматтар жүктөлгөн 2023 preprintинен алынган; кийинки журнал версиясында болушу мүмкүн болгон редакциялык же илимий өзгөрүүлөр жүктөлгөн булак менен унчукпай бириктирилген эмес.

Басма: Elsevier.

Программалык артефакт: Изилдөө жарым-статикалык шарттарды ишке ашырууну ачык булактуу китепкана катары сунуштап, баштапкы код репозиторийин maxlucuta/semi-static-conditions деген ат менен көрсөтөт.

Каржылоо / кызыкчылыктардын кагылышы / CRediT: Жүктөлгөн preprintте өзүнчө жана ачык каржылоо, кызыкчылыктардын кагылышы же CRediT автордук салым билдирүүсү табылган эмес; бул талаалар булакта болбогондуктан толтурулган эмес.

Негизги методологиялык чектөө: Аткарымдуулук жыйынтыктары архитектурага жана платформага көз каранды. Негизги benchmarkтар Intel Core i7-10700 үстүндө жүргүзүлүп, реалдуу толук масштабдуу HFT өндүрүш системасы жана толук kernel/network tuning чөйрөсү колдонулган эмес. Көп threadдүү колдонууну thread-safe кылуу синхрондоштуруу чыгымын жаратат. Assembly editing стандарттык C++ алкагында аныкталган коопсуз жүрүм-турум эмес жана executable барак уруксаттары коопсуздук/портативдүүлүк көйгөйлөрүн жаратышы мүмкүн.

Булактын ичиндеги техникалык эскертүү: Иштеп чыгуу бөлүмү C++20/GCC 13.1 чөйрөсүн көрсөткөнү менен usage мисалында -std=c++17 колдонулат. Мындан тышкары салыштырмалуу jump жетүү чеги боюнча түшүндүрмө менен runtime ката билдирүүсүндөгү 2 GiB туюнтмасы бирдей формада жазылган эмес. Бул айырмачылыктар Verianla тарабынан унчукпай оңдолгон эмес.