Yalnızca birkaç ortak için alfa modeller geliştiren küçük bir makine öğrenmesi laboratuvarı için, simülasyon döngüsü her deneyin doğruluğunu test eden kritik bir adımdı. Ancak bu süreç, Python ve Pandas kullanıldığında her pencere başına 900–1300 milisaniye süren bir hesaplama yüküydü. Bu da tek bir deneyin 6 ila 20 saat arasında tamamlanması anlamına geliyordu. Performans iyileştirme yolculuğumuzun ardındaki gerçek mühendislik hikayesi ve elde ettiğimiz sonuçlar işte burada.
Simülasyonun Gizli Yükü: Verimlilikten Önce Doğruluk
Tüm makine öğrenmesi yığınımız Python üzerine kurulu: özellik mühendisliği, hedeflerin belirlenmesi, eğitim, geriye dönük testler ve en önemlisi, simülasyon (önceden bakış önyargısını engelleyen katı bir süreç).
Simülasyon, hesaplama açısından son derece yoğun bir işlemdir. Yıllar boyunca 1 dakikalık ve 5 dakikalık mumlar üzerinde çalışırken, tek bir pencere için yapılan işlemler normal bir iş istasyonunda 6 ila 20 saat sürüyordu. Her pencere için yüzlerce özellik hesaplanıyor ve ardından çıkarım yapılıyordu. Veri → özellikler → çıkarım döngüsü bir pencere için 900–1300 milisaniye alıyordu.
Bu gecikmeyi ticaret açısından umursamıyorduk; umursadığımız şey, her deneyin bir gün sürmesi ve test edilecek çok sayıda hipotezimizin olmasıydı.
Adım 1: Pandas’tan NumPy’ye Geçiş — İlk Büyük İyileştirme
Python geliştiricileri olarak ilk hamlemiz açıkça görülüyordu: sıcak yolda Pandas’ı tamamen kaldırıp NumPy’ye geçmek. Bu değişiklik gerçekten de işe yaradı ve pencere başına yaklaşık 140 milisaniye performans elde ettik. Artık temel deneyleri çok daha geniş bir ölçekte yürütebiliyorduk.
Ancak kayan pencerelerin yeniden hesaplanması ve bellek tahsisindeki artışlar hâlâ performansımızın sınırını belirliyordu. 140 milisaniye, yalnızca basit deneyleri yürütmemize izin veriyordu.
Adım 2: Dilin Sınırlarını Kabul Etmek — Python’un Ötesine Geçiş Zorunluluğu
Yıllardır Rust programlama dilini kullanan bir arkadaşım sürekli olarak şöyle diyordu: “Python’unuz saçma, bunu Rust’ta yeniden yazın.” Yıllarca Rust’ın her durumda değerli olup olmadığı konusunda tartıştık.
Ancak bu kez anladım ki: ne kadar CPU kullanırsam kullanayım, Python’daki GIL ve yorumlayıcı yükü beni sınırlıyor. Artık yukarı doğru bir yol yoktu.
Adüm 3: Rust ve C++’ın Gücünü Birleştirmek — Mühendisliğin En Zorlu Dönemi
Hızlı ya da kolay olmadı — her bir özelliği Rust’a yeniden yazdık, böylece kayan pencerelerin yeniden hesaplanması yerine her fiyat adımı için O(1) artımlı durum kullandık. Bu tek değişiklik, hem bellek tahsisindeki artışı hem de gecikme değişkenliğini ortadan kaldırdı. Ardından modelleri, hedef CPU için AOT derlenmiş C++ motoruna aktardık ve FFI aracılığıyla çağırdık.
Sonuçlar, tam döngü, bir pencere başına:
| Aşama | Python / Pandas | Ucuz bulut sunucusu (vCPU) | Yüksek saatli AMD test makinesi | |-------|------------------|-----------------------------|---------------------------------| | Gecikme/pencere | ~140 ms | 1–5 ms | 4–40 µs |
Saatler süren simülasyonlar artık dakikalar içinde tamamlanıyor. Bellek sızıntısıyla mücadele de sona erdi.
Beklenmeyen Bir Sonuç: Deneylerin Önünü Açmak
Elde ettiğimiz en önemli kazanım üretimdeki hız artışı değildi; bunun deneylerimize kattığı esneklikti. Artık gerçek fiyat adımı simülasyonlarını (geriye dönük test değil) test edebiliyoruz — bu fikirleri Python’da yapmak imkansızdı; Rust’ta ise neredeyse sadece altyapımızın sınırlarıyla kısıtlıydı. Hatta Michael Levin’in çalışmalarından ilham alan bazı fikirleri de test ediyoruz (biyoelektrik ve kolektif davranışların ötesinde de faydalı olduğu ortaya çıktı).
Sonuçların Doğruluğunu Kendiniz Kontrol Edin
Canlı sinyalleri ham haliyle bir kamu panosuna aktarıyoruz. Her sinyal, üretim anında kamu S3’e yazılıyor — değiştirilemez ve mikrosaniye düzeyinde zaman damgasıyla. Böylece önceden bakış önyargısının olmadığını doğrulayabilirsiniz: signal_gen_time > bar_time her bir sinyal için geçerli. Demo sunucusu ayrıca gerçek çıkarım gecikmesini de raporluyor (gördüğünüz gibi milisaniye cinsinden — ucuz silikon, dürüst sayı).
Sınırlarımızı Kabul Etmek: Bu Bir HFT Sistemi Değil
Gerçek veri akışı gecikmemiz var ve hiçbir ko-lokasyon / kernel-bypass / borsa yakınlığı yok. Burada bahsettiğimiz şey, HFT masalarının aksine, yalnızca hızlı hesaplama. Başka bir iddiada bulunmuyoruz.
Açık Soru: Gerçekten Kullanılabilir Mi?
Eğer burada HFT / piyasa yapıcılığı alanında üretimde çalışan biri varsa: hızlı hesaplama avantajına rağmen ko-lo olmadan (gerçek veri akışı gecikmesiyle), bu iyileştirme üretimde kullanılabilir mi? Şimdiye kadar tek fikrimiz, piyasa yapıcılığı için ters seçim savunması — mikro yapıdaki hareketler öncesinde fiyat eğimini ve alıntıları çekmek. Belki de tamamen yanlış düşünüyoruzdur. Gerçekten deneyimli biriyle bir gerçeklik kontrolü yapmak isterdim.
Bu Bir Reklam Değil — Sadece Mühendislik Hikayesi
Perakende müşterilere satış yapmıyoruz ve okuyucularımızın çoğunun ilgisini çekecek alıcılar da olmadığımızı düşünüyorum. Bu hikayeyi yazmamın nedeni, bu topluluğun gerçek Rust yeniden yazma hikayelerini takdir etmesi ve kötü mühendisliği ortaya çıkarması — tam da benim istediğim şey bu.
Rust harika. İşte bu kadar.
Yapay zeka özeti
Python ve Pandas’tan Rust ve C++’ya geçişle piyasa simülasyonu performansı 140ms’den 1-5 mikrosaniyeye düştü. Küçük bir ML laboratuvarının performans krizine bulduğu çözüm ve getirdiği fırsatlar.
