Yarı-statik koşul (semi-static condition), çalışma zamanında seçilecek yürütme yönünü değiştirirken gecikmeye duyarlı kod yolunda geleneksel bir koşullu dal değerlendirmesine ihtiyaç bırakmamak üzere, çalışmakta olan yürütülebilir dosyanın makine kodundaki göreli atlama hedefini değiştiren bir C++ kontrol akışı yapısıdır. Paul Alexander Bilokon, Maximilian Lucuta ve Erez Shermer tarafından geliştirilen yaklaşım, pahalı olan koşul değerlendirme ve makine kodu değiştirme işlemini performans açısından kritik olmayan bir yola taşırken, kritik yoldaki branch çağrısını doğrudan fonksiyon çağrısına yakın maliyetli bir göreli atlama haline getirmeyi amaçlamaktadır.

Çalışmanın temel fikri, modern işlemcilerin koşullu dalları her seferinde tahmin etmesini daha iyi hale getirmeye çalışmak yerine, belirli kullanım senaryolarında tahmin edilmesi gereken koşullu dalı kritik yürütme yolundan tamamen çıkarmaktır. Bunun için set_direction işlemi hangi fonksiyonun çalıştırılacağını önceden belirler ve ilgili 32-bit göreli atlama ofsetini çalışan kodun içine yazar; daha sonra branch çağrısı koşulu tekrar değerlendirmeden bu hedefe yönelir.

Intel Core i7-10700 üzerinde gerçekleştirilen mikrobenchmarklarda doğrudan fonksiyon çağrısının medyan maliyeti 9 CPU çevrimi, yarı-statik branch çağrısının medyanı 10 çevrim ve her ikisinin standart sapması 1 çevrim olarak ölçülmüştür. Rastgele ve tahmini zor iki yönlü HFT-benzeri sıcak yol testinde, önbellek ısıtması olmadan geleneksel koşullu dallanma 75 çevrim medyan ve 10 çevrim standart sapma gösterirken yarı-statik koşullar 63 çevrim medyan ve 3 çevrim standart sapma göstermiştir. Önbellek ısıtmasıyla değerler sırasıyla 68±8 ve 62±2 çevrim olmuştur.

Avantaj koşulsuz değildir. Çalışan makine kodunu değiştirmek self-modifying code (SMC) mekanizmalarını tetikleyebilir. Assembly değişikliğinin hemen ardından değiştirilmiş kodun çalıştırıldığı testte SMC machine clear etkileri yürütme süresini yaklaşık 30–40 kat artırmış ve yaklaşık 100 çevrimlik ek cezalar gözlenmiştir. Bu nedenle yöntem, branch yönünün sık sık değiştirilip hemen ardından çalıştırıldığı sıkı döngüler için uygun değildir. Çalışmanın önerdiği kullanım modeli, pahalı set_direction işlemini “soğuk” yola taşımak ve ucuz branch işlemini gecikmeye duyarlı “sıcak” yolda kullanmaktır.

Yarı-Statik Koşul Nedir?

Yarı-statik koşul, koşulun değerlendirilmesi ile seçilmiş kod dalının çalıştırılmasını iki ayrı zamansal işleme ayıran ve seçilmiş dalı daha sonra bir göreli makine-kodu atlaması üzerinden çağıran programatik kontrol akışı yapısıdır. “Statik” tarafı, kritik branch çağrısı sırasında hedefin önceden belirlenmiş olmasıdır; “yarı” tarafı ise programın çalışma zamanında bu hedefin set_direction ile tekrar değiştirilebilmesidir.

Normal bir C++ koşullu ifadenin mantığı kavramsal olarak şöyledir: işlemci bir koşulu okur, karşılaştırma yapar, koşullu atlama komutuna ulaşır ve branch predictor hangi yolun izleneceğini tahmin eder. Tahmin doğruysa maliyet düşüktür; yanlışsa spekülatif olarak getirilen ve kısmen işlenen komutların temizlenmesi gerekebilir.

Yarı-statik yaklaşımda ise koşul kritik yol başlamadan değerlendirilir. Program, hangi fonksiyonun hedef olacağını belirleyerek branch giriş noktasındaki göreli jmp komutunun displacement alanını değiştirir. Kritik olay geldiğinde koşul tekrar okunmaz; kontrol akışı doğrudan önceden seçilmiş fonksiyona yönelir.

Neden klasik branch predictor yeterli görülmemiştir?

Modern branch predictor'lar birçok dalı çok yüksek doğrulukla tahmin edebilir. Çalışma özellikle geçmişle güçlü korelasyonu bulunmayan, girdi verisine bağlı olan veya nadiren çalıştığı için yeterli geçmiş üretmeyen dallara odaklanmaktadır. Bu problem HFT gibi düşük gecikmeli sistemlerde önemlidir; çünkü kritik yol sürekli çalışmak zorunda olmayabilir ancak çalıştığı anda mümkün olduğunca düşük ve öngörülebilir gecikme göstermelidir.

C++20'nin [[likely]] ve [[unlikely]] nitelikleri bu problemi doğrudan donanım branch predictor'ına “bu dalı tahmin et” komutu göndererek çözmez. Kaynakta açıklandığı biçimiyle derleyici, bu bilgiyi kod yerleşimini ve olası sıcak/soğuk yolların assembly düzenini değiştirmek için kullanır. Gerçek zamanlı koşul dağılımı daha sonra değişirse bu derleme zamanı tercihi dinamik olarak güncellenmez.

Yarı-Statik Koşullar Dal Tahmininden Nasıl Farklı Çalışır?

Yarı-statik koşullar, koşullu dalın sonucunu daha iyi tahmin etmeye çalışmak yerine kritik yoldaki koşullu dal komutunu programcı tarafından yönü değiştirilebilen doğrudan bir göreli atlamaya dönüştürür. Böylece execute aşamasında çözülen klasik koşullu-dal yanlış tahminlerinin yerini, hedef değiştirildiğinde daha erken aşamada ortaya çıkabilen BTB/BAC hedef düzeltmeleri alır.

BranchChanger yapısı

Prototipte ana soyutlama BranchChanger sınıfıdır. Sınıf başlangıçta iki fonksiyon adresi alır. set_direction(condition) çalışma zamanındaki koşula göre hangi hedefin etkin olacağını belirler; branch(...) ise seçilmiş hedefe gider.

Fonksiyonların argüman ve dönüş tipleri template deduction ile elde edilir. Böylece branch giriş noktasının imzası hedef fonksiyonların çağrı konvansiyonuyla uyumlu hale getirilir. Kaynakta normal üye fonksiyonun gizli this işaretçisi oluşturması nedeniyle başlangıçta karşılaşılan register kayması sorunu açıklanmakta ve temel prototipte branch metodunun statik yapılması tercih edilmektedir.

Göreli atlama ofseti

x86 mimarisindeki göreli jmp/call mekanizmasında hedef adres doğrudan tam adres olarak değil, mevcut komut konumuna göre bir displacement olarak kodlanır. Kaynağın kullandığı temel ilişki şöyledir:

Jump Offset, makine komutuna yazılacak göreli uzaklıktır. Target Address, yürütülecek if/else fonksiyonunun giriş adresidir. Entry Point, değiştirilmekte olan branch giriş noktasını; Size of Instruction ise göreli atlama komutunun uzunluğunu ifade eder. x86 uygulamasında çalışma, bir baytlık e9 opcode ve onu izleyen dört baytlık displacement alanı kullanmaktadır.

Bu matematik branch davranışının neden yalnız bir Boolean değişken değiştirmekten ibaret olmadığını gösterir. Program yürütülebilir kod segmentinin konumunu, hedef fonksiyonun adresini ve komut uzunluğunu dikkate alarak gerçek makine kodunu değiştirmektedir.

Çalışan kod nasıl değiştiriliyor?

Makine komutları normalde sanal adres alanındaki executable/text sayfalarında bulunur ve yazmaya kapalıdır. Prototip çalışma zamanında branch fonksiyonunun adresinden ilgili sayfayı bulur, Linux mprotect mekanizmasıyla sayfa izinlerini değiştirir ve göreli atlama displacement'ını yazılabilir hale getirir.

Adres Space Layout Randomization (ASLR) nedeniyle yürütülebilir kodun gerçek çalışma zamanı adresi önceden sabit varsayılmamaktadır. Bu nedenle adres çözümleme ve sayfa hizalama işlemleri program çalışırken yapılır.

Branch-Changing ve Branch-Taking Neden Ayrılıyor?

İki işlem ayrılır çünkü branch yönünü değiştirmek çalışan executable belleğe yazmayı gerektiren görece pahalı bir işlemdir; branch-taking ise doğru hazırlanmış durumda yalnız doğrudan fonksiyon çağrısına eklenen kısa bir göreli atlama maliyetine indirgenebilir. Kaynağın optimizasyon stratejisi pahalı işlemi gecikmeye duyarlı olmayan kodda amorti etmek ve kritik yolda yalnız ucuz işlemi bırakmaktır.

Self-modifying code cezası

İşlemciler çalışan kodun değiştirilmesini destekleyebilse de instruction cache, pipeline ve ilgili spekülatif durumlar değiştirilmiş talimatlarla uyumsuz hale gelebilir. Kaynaktaki testler, yalnız executable belleğe dört bayt yazmanın tek başına normal belleğe dört baytlık memcpy işleminden belirgin biçimde pahalı olmadığını göstermiştir: her iki durumda da medyan yaklaşık 9 çevrim ve standart sapma 1 çevrimdir.

Asıl yüksek maliyet, değiştirilmiş komut çok kısa süre sonra yürütüldüğünde ortaya çıkmıştır. Bu durumda işlemci self-modifying code tespiti sonrasında machine clear oluşturabilmekte; kaynak testinde bu davranış yaklaşık iki temizleme/iterasyon düzeyine çıkmış, toplam çalışma süresini yaklaşık 30–40 kat artırmış ve SMC etkisinin yaklaşık 100 çevrim mertebesinde ek maliyet oluşturduğu gözlenmiştir.

Bu bulgu yarı-statik koşulların her if ifadesinin yerine kullanılabilecek genel bir drop-in optimizasyon olmadığını gösterir. set_direction ve branch sürekli art arda çalışacaksa yöntemin temel avantajı ortadan kalkabilir.

BTB ve BAC etkisi

Branch Target Buffer (BTB), işlemcinin belirli bir program counter konumunda dal bulunduğunu ve hedefin neresi olduğunu öngörmesine yardımcı olan donanım yapısıdır. Branch Address Calculator (BAC) ise hedef adres doğrulamasında rol oynar. Yarı-statik koşulun göreli jmp hedefi değiştirildiğinde BTB'de eski hedef kalabilir.

Çalışmadaki deneylerde sürekli değiştirilen hedefler BAC düzeltmelerini artırmıştır. Hesaplama tamponu eklendiğinde düzeltme sayısı yaklaşık yarıya düşerek iterasyon başına yaklaşık bire inmiştir. Yazarlar BAC düzeltmesi için yaklaşık 2,2 ns, yani kullanılan işlemcide yaklaşık 6 çevrim ek maliyet ölçmüşlerdir. Bu maliyet koşullu dal yanlış tahmininden daha düşüktür ve en önemlisi kritik yol çalışmadan önce “ısınma” çağrısıyla önden ödenebilmektedir.

Aktif branch warming

Kaynağın önemli önerilerinden biri, branch yönü değiştirildikten sonra soğuk yolda sahte veya etkisiz bir çağrıyla branch metodunu çalıştırmaktır. Bu çağrı güncel hedefin BTB tarafından öğrenilmesine, gerekli instruction-cache verisinin ısınmasına ve SMC etkilerinin kritik yoldan uzağa taşınmasına yardımcı olur. HFT örneğinde çalışma bunu kavramsal olarak bir “dummy order” çağrısıyla anlatmaktadır.

HFT sistemi içindeki konumu

Kaynağın Şekil 7'sindeki sadeleştirilmiş HFT mimarisinde piyasa verisi ağ katmanından finansal protokole, order book'a ve özel uygulama mantığına ulaşmakta; çalışma tarafından önerilen optimizasyon özel uygulama tarafındaki order-action kritik yoluna yönelmektedir. Yöntem ağ gecikmesini, exchange matching engine gecikmesini veya FPGA'nın kendi işlem süresini doğrudan optimize eden bir teknik değildir.

Güvenlik

Çalışan executable sayfasının read/write/execute yapılması güvenlik yüzeyini büyütür. Kaynak bu riski kabul ederek set_direction_safe yaklaşımında sayfanın yalnız değişiklik sırasında yazılabilir hale getirilmesini, ardından tekrar read/execute durumuna döndürülmesini önerir. Bunun bedeli iki sistem çağrısı ve daha yüksek gecikme/jitter'dır. Dolayısıyla çalışmada güvenlik ile en düşük gecikme arasında açık bir mühendislik ödünleşimi bulunmaktadır.

Thread safety

Assembly hedefi tüm çağrılar tarafından paylaşılan bir kod parçası olduğundan, eşzamanlı bir thread hedefi değiştirirken başka bir thread branch çağrısı yapabilir. Kaynak testleri senkronizasyon olmadan yanlış dalın nadiren de olsa çalıştırılabildiğini göstermiştir. Mutex gibi senkronizasyon doğru davranışı sağlar fakat performans avantajının önemli bölümünü ortadan kaldırır.

Taşınabilirlik

Kütüphane CMake kullanan statik bir kütüphane olarak paketlenmiştir. Kaynağın uyumluluk tablosu Windows x86-64 ve Linux x86-64 üzerinde GCC, MSVC ve Clang için; ayrıca Linux ARM üzerinde GCC ve Clang için test edilmiş/işlevsel kombinasyonlar bildirmektedir. macOS kombinasyonları çalışır olarak işaretlenmemiştir. Özellikle Apple Silicon Hardened Runtime'ın write/execute sayfa izinleri üzerindeki kısıtları mevcut yaklaşım için önemli bir engel olarak belirtilmektedir.

Çalışmanın Yöntemi ve Bulguları

Çalışma iki aşamalı olarak yürütülmüştür. İlk aşamada C++ seviyesinde BranchChanger prototipi, calling convention uyumluluğu, template deduction, assembly düzenleme, compiler optimizasyonlarına karşı koruma, relative jump ve taşınabilirlik mekanizmaları geliştirilmiştir. İkinci aşamada branch-changing ve branch-taking bileşenleri CPU çevrimi, performans sayaçları ve daha yüksek seviyeli mikrobenchmarklarla ölçülmüştür.

Geliştirme ve deney ortamı

• İşletim sistemi: Linux, Ubuntu dağıtımı.
• Derleyici: GCC 13.1.
• Geliştirme dili: Kaynağın geliştirme bölümünde C++20.
• Temel benchmark CPU'su: Intel Core i7-10700, 2,90 GHz.
• Kaynakta bildirilen cache kapasitesi: 256 KB L1 instruction/data, 2 MB L2 ve 16 MB L3.
• Düşük seviye zaman ölçümü: RDTSC.
• Serileştirme: LFENCE.
• Performans sayaçları: Linux perf ve perf_event_open.
• Daha yüksek seviyeli testler: Google Benchmark.

RDTSC ölçümlerinde işlemcinin out-of-order yürütmesinin ölçüm aralığını bozmasını önlemek için LFENCE kullanılmıştır. Ölçüm altyapısının kendi maliyeti, boş ölçüm döngüsünün çok sayıda tekrarıyla belirlenip sonraki sonuçlardan çıkarılmıştır. Kaynak bazı instruction-level testlerde yaklaşık \(10^7\) tekrar kullanmıştır.

Temel benchmark sonuçları

Kaynağın Şekil 16'sında rastgele koşullarla yapılan iki yönlü testin conditional-branch dağılımı bimodaldir. Cache warming olmadan predicted ve mispredicted kümeler yaklaşık 65 ve 78 çevrim; warming ile yaklaşık 64 ve 80 çevrim merkezlerinde görülmektedir. Aradaki 13–16 çevrim farkı, çalışmanın kullandığı mimaride klasik yanlış tahmin cezasının büyüklüğünü göstermektedir.

Yazarların hesaplamasına göre yarı-statik koşullar bu deneyde ortalama yaklaşık 2–4 ns, dalın sürekli yanlış tahmin edildiği durumda ise yaklaşık 6 ns tasarruf sağlamıştır. Bu değerler genel C++ garantisi değildir; ölçülen işlemci, kod yerleşimi, cache durumu, compiler ve test senaryosuna özgüdür.

[[likely]] ve [[unlikely]] neden rastgele koşullarda yardımcı olmadı?

Rastgele üretilen Boolean koşullarda iki yön yaklaşık eş olasılıklı olduğundan derleyici tarafından yapılan statik kod yerleşimi gerçek çalışma zamanı davranışını tahmin edememiştir. Kaynak testlerinde [[likely]] ve [[unlikely]] kullanımı yanlış tahmin oranını düşürmemiştir. Bu sonuç yalnız bu test düzeninin koşulları altında geçerlidir; niteliklerin tüm programlarda etkisiz olduğu anlamına gelmez.

N-yollu dallanma

Kaynak, rastgele seçilen n-yollu if/else veya switch yapısında seçenek sayısı büyüdükçe doğru hedefin tahmin edilmesinin zorlaştığını belirtmektedir. Beş durumlu switch testinde kaynak Şekil 18, geleneksel switch için 30 çevrim medyan ve 8 çevrim standart sapma; yarı-statik koşul için 8 çevrim medyan ve 1 çevrim standart sapma bildirmektedir. Bu deneyde kullanılan dalların boş fonksiyonlar olması, sonucu gerçek bir üretim iş yükünün doğrudan performansı olarak yorumlamayı engeller.

Tahmin edilebilir dallarda ne oldu?

Koşul her 1000 iterasyonda bir değiştirildiğinde conventional branch 64 çevrim medyan ve 3 çevrim standart sapma, yarı-statik yaklaşım 62 çevrim medyan ve 2 çevrim standart sapma göstermiştir; kaynak bu karşılaştırma için \(P<0.000001\) vermektedir. Yazarlar yaklaşık 2–3 çevrimlik küçük farkı compiler'ın ileri ve geri branch yollarında oluşturduğu farklı assembly düzenleriyle ilişkilendirmektedir.

Switch yapılarında söz konusu kod yerleşimi etkisi daha belirgin olmuş ve çalışmada bazı predictable-switch koşullarında yarı-statik yolun yaklaşık 5–6 çevrim daha hızlı olduğu raporlanmıştır.

Branch-changing maliyeti

Dört baytlık yön değişikliğinin izole maliyeti düşük görünmesine rağmen, yazılan adres daha önce instruction cache/pipeline yapılarında bulunduğunda SMC machine clear oluşabilir. Yakın zamanlı edit-and-execute senaryosunda kaynak yaklaşık 30–40 katlık yavaşlama raporlamıştır. Bu, yöntemin tasarımındaki en önemli kısıttır.

CLFLUSH ile ilgili instruction-cache satırlarının temizlenmesi ve assembly edit ile branch-taking arasına hesaplama tamponu yerleştirilmesi machine clear sayısını azaltmıştır; ancak maliyeti tamamen ortadan kaldırmamıştır. Kaynak bu nedenle yön değiştirme ile branch-taking arasındaki zamansal ve mikromimari uzaklığı kritik bir optimizasyon parametresi olarak ele almaktadır.

Güvenilirlik ve eşzamanlılık

Tek thread'li doğruluk testlerinde yön sürekli değiştirilip dal hemen çalıştırıldığında beklenen fonksiyonun yürütüldüğü doğrulanmıştır. Çok thread'li durumda assembly yazımı atomik bir yüksek seviye branch seçimi sağlamadığından race condition oluşabilmektedir. Senkronizasyon yanlış dal çalıştırma riskini önler, fakat kaynaktaki karşılaştırmalar performansın belirgin biçimde düştüğünü göstermektedir.

Bu Benchmarklar Gerçek Bir HFT Üretim Sisteminde Aynı Kazancı Kanıtlar mı?

Hayır. Çalışma gerçek piyasa verisini, üretim ağ altyapısını, exchange bağlantısını ve tam olarak ayarlanmış bir HFT kernel ortamını uçtan uca benchmark etmemiştir; sonuçlar CPU ve mikrobenchmark seviyesinde, kısmen üretim davranışını taklit eden testlerden elde edilmiştir. Bu nedenle nanosecond düzeyindeki avantajlar yöntemin potansiyelini gösterir fakat gerçek bir trading sisteminde aynı büyüklükte uçtan uca kazancı garanti etmez.

Yazarlar evaluation bölümünde root yetkisinin bulunmaması nedeniyle CPU scaling ve scheduler gibi kernel ayarlarının gerçek HFT sistemindeki düzeyde yapılandırılamadığını belirtmektedir. Ayrıca pseudo-realistic mikrobenchmarkların gerçek üretim trading sistemini eksiksiz temsil etmediğini açıkça kabul ederler.

Kaynağın son şekli, daha güçlü bir gelecek doğrulaması için ayrı bir market-data replay sunucusu, yüksek hassasiyetli timestamp özelliğine sahip ağ anahtarı, ölçülen üretim sistemi ve yanıt sürelerini hesaplayan ayrı bir ölçüm sunucusundan oluşan deney düzeni önermektedir.

Çalışmanın desteklediği sonuçlar

• Yarı-statik branch çağrısı incelenen mimaride doğrudan fonksiyon çağrısına çok yakın bir yürütme maliyetine indirilebilmiştir.
• Sık yanlış tahmin edilen branch'lerde, branch-changing kritik yol dışında tutulabildiğinde daha düşük medyan gecikme ve daha düşük latency variance ölçülmüştür.
• Koşullu branch misprediction maliyetinin yerine daha düşük maliyetli hedef düzeltme mekanizmaları kullanılabilmektedir.
• SMC machine clear, yaklaşımın başlıca performans sınırlarından biridir.
• Yön değişikliği ile branch-taking yeterince ayrılırsa pahalı değişim maliyeti çok sayıda ucuz branch çağrısına dağıtılabilir.
• Thread safety, güvenlik ve platform taşınabilirliği uygulamadaki temel sınırlılıklardır.

Çalışmanın desteklemediği sonuçlar

• Yarı-statik koşulların her C++ if veya switch yapısından hızlı olduğu gösterilmemiştir.
• Her CPU mimarisinde aynı çevrim veya nanosecond kazancının elde edileceği gösterilmemiştir.
• Gerçek bir borsada daha yüksek işlem kârlılığı ampirik olarak ölçülmemiştir.
• Gerçek üretim HFT sisteminde uçtan uca market-data-to-order latency deneyi yapılmamıştır.
• Thread-safe senkronizasyon eklenmiş kullanımın aynı performans avantajını koruduğu gösterilmemiştir.
• Assembly editing yaklaşımının standart C++ davranışı olduğu iddia edilmemektedir.
• Güvenli RWX yönetiminin performans maliyeti olmadan uygulanabildiği gösterilmemiştir.

Kaynak ve Yöntem Notu

Özgün başlık: Semi-static Conditions in Low-latency C++ for High Frequency Trading: Better than Branch Prediction Hints

Yazarlar: Paul Alexander Bilokon; Maximilian Lucuta; Erez Shermer.

Preprint afiliyasyonları: Paul Alexander Bilokon — Department of Computing ve Department of Mathematics, Imperial College London; Maximilian Lucuta — Department of Computing, Imperial College London; Erez Shermer — qSpark LLC, Wilmington, Delaware, ABD.

Yüklenen kaynak: arXiv:2308.14185v1 [cs.PF], 27 Ağustos 2023. Yüklenen dosya kendisini açıkça “A PREPRINT” olarak tanımlamaktadır.

Sonraki yayın durumu: Bibliyografik doğrulamada çalışmanın daha sonra Journal of Parallel and Distributed Computing, Cilt 196, Makale 105000 olarak yayımlandığı doğrulanmıştır. Dergi sürümünün DOI'si 10.1016/j.jpdc.2024.105000'dir. Bu Verianla metnindeki deneysel ayrıntılar yüklenen 2023 preprintinden çıkarılmıştır; sonraki dergi sürümünde yapılmış olabilecek editoryal veya bilimsel değişiklikler yüklenen kaynakla sessizce birleştirilmemiştir.

Yayınevi: Elsevier.

Yazılım artefaktı: Çalışma yarı-statik koşullar uygulamasını açık kaynak bir kütüphane olarak sunmakta ve kaynak kod deposunu maxlucuta/semi-static-conditions adıyla belirtmektedir.

Finansman / çıkar çatışması / CRediT: Yüklenen preprintte ayrı ve açık finansman, çıkar çatışması veya CRediT yazar katkı bildirimi tespit edilmemiştir; bu alanlar kaynakta bulunmadığı için tamamlanmamıştır.

Temel yöntemsel sınırlılık: Performans sonuçları mimari ve platform bağımlıdır. Ana benchmarklar Intel Core i7-10700 üzerinde yürütülmüş, gerçek bir tam ölçekli HFT üretim sistemi ve tam kernel/network tuning ortamı kullanılmamıştır. Çok thread'li kullanımın thread-safe hale getirilmesi senkronizasyon maliyeti doğurmaktadır. Assembly editing standart C++ kapsamında tanımlı güvenli davranış değildir ve executable sayfa izinleri güvenlik/taşınabilirlik sorunları doğurabilir.

Kaynak-içi teknik not: Geliştirme bölümü C++20/GCC 13.1 ortamını belirtirken usage örneğinde -std=c++17 kullanılmaktadır. Ayrıca göreli jump erişim sınırına ilişkin açıklama ile runtime hata mesajındaki 2 GiB ifadesi aynı biçimde yazılmamıştır. Bu farklılıklar Verianla tarafından sessizce düzeltilmemiştir.