Salah satu pertanyaan yang paling sering saya terima di kantong surat adalah
Pertama, komponen utama dari sistem perdagangan algoritmik akan dipertimbangkan, seperti alat penelitian, pengoptimalan portofolio, pengelola risiko dan mesin eksekusi. Selanjutnya, strategi perdagangan yang berbeda akan diperiksa dan bagaimana mereka mempengaruhi desain sistem. Khususnya frekuensi perdagangan dan volume perdagangan yang mungkin akan didiskusikan.
Setelah strategi perdagangan dipilih, perlu untuk membangun seluruh sistem. Ini termasuk pilihan perangkat keras, sistem operasi (s) dan ketahanan sistem terhadap kejadian langka, berpotensi bencana. Sementara arsitektur sedang dipertimbangkan, perhatian yang tepat harus dibayar untuk kinerja - baik untuk alat penelitian serta lingkungan eksekusi langsung.
Apa yang Dilakukan Sistem Perdagangan?
Sebelum memutuskan bahasa
Penelitian berkaitan dengan evaluasi kinerja strategi atas data historis. Proses evaluasi strategi perdagangan atas data pasar sebelumnya dikenal sebagai backtesting. Ukuran data dan kompleksitas algoritmik akan berdampak besar pada intensitas komputasi backtester. Kecepatan CPU dan concurrency seringkali merupakan faktor pembatas dalam mengoptimalkan kecepatan eksekusi penelitian.
Generasi sinyal berkaitan dengan menghasilkan serangkaian sinyal perdagangan dari algoritma dan mengirim pesanan tersebut ke pasar, biasanya melalui pialang. Untuk strategi tertentu, tingkat kinerja yang tinggi diperlukan. Masalah I / O seperti bandwidth jaringan dan latensi seringkali merupakan faktor pembatasan dalam mengoptimalkan sistem eksekusi. Dengan demikian pilihan bahasa untuk setiap komponen dari seluruh sistem Anda mungkin sangat berbeda.
Jenis, Frekuensi dan Volume Strategi
Jenis strategi algoritma yang digunakan akan memiliki dampak yang substansial pada desain sistem. Perlu dipertimbangkan pasar yang diperdagangkan, konektivitas ke vendor data eksternal, frekuensi dan volume strategi, trade-off antara kemudahan pengembangan dan optimasi kinerja, serta perangkat keras kustom apa pun, termasuk server kustom, GPU atau FPGA yang mungkin diperlukan.
Pilihan teknologi untuk strategi ekuitas AS frekuensi rendah akan sangat berbeda dari strategi arbitrage statistik frekuensi tinggi yang diperdagangkan di pasar berjangka.
Hal ini perlu untuk mempertimbangkan konektivitas ke vendor, struktur API, ketepatan waktu data, persyaratan penyimpanan dan ketahanan dalam menghadapi vendor offline. Hal ini juga bijaksana untuk memiliki akses cepat ke beberapa vendor! berbagai instrumen semua memiliki quirks penyimpanan mereka sendiri, contohnya termasuk beberapa simbol ticker untuk ekuitas dan tanggal kedaluwarsa untuk berjangka (belum lagi data OTC tertentu). Ini perlu diperhitungkan dalam desain platform.
Frekuensi strategi cenderung menjadi salah satu pendorong terbesar dari bagaimana tumpukan teknologi akan didefinisikan. strategi yang menggunakan data lebih sering daripada menit atau kedua bar membutuhkan pertimbangan yang signifikan dalam hal kinerja.
Strategi yang melampaui bar kedua (yaitu data tik) mengarah pada desain yang didorong oleh kinerja sebagai persyaratan utama. Untuk strategi frekuensi tinggi, sejumlah besar data pasar harus disimpan dan dievaluasi. Perangkat lunak seperti HDF5 atau kdb + biasanya digunakan untuk peran ini.
Untuk memproses volume data yang luas yang dibutuhkan untuk aplikasi HFT, backtester dan sistem eksekusi yang dioptimalkan secara luas harus digunakan. C / C ++ (mungkin dengan beberapa assembler) kemungkinan menjadi kandidat bahasa terkuat. Strategi frekuensi ultra tinggi hampir pasti akan membutuhkan perangkat keras kustom seperti FPGA, co-lokasi pertukaran dan kernel / jaringan interface tuning.
Sistem Penelitian
Sistem penelitian biasanya melibatkan campuran pengembangan interaktif dan skrip otomatis. Yang pertama sering terjadi dalam IDE seperti Visual Studio, MatLab atau R Studio. Yang terakhir melibatkan perhitungan numerik ekstensif atas berbagai parameter dan titik data. Ini mengarah pada pilihan bahasa yang memberikan lingkungan yang mudah untuk menguji kode, tetapi juga memberikan kinerja yang cukup untuk mengevaluasi strategi atas beberapa dimensi parameter.
IDE khas di ruang ini termasuk Microsoft Visual C ++ / C #, yang berisi utilitas debugging yang luas, kemampuan penyelesaian kode (melalui
Untuk backtesting numerik, semua bahasa di atas cocok, meskipun tidak perlu menggunakan GUI / IDE karena kode akan dieksekusi di latar belakang. Pertimbangan utama pada tahap ini adalah kecepatan eksekusi. Bahasa yang dikompilasi (seperti C ++) sering berguna jika dimensi parameter backtesting besar. Ingat bahwa perlu berhati-hati dengan sistem tersebut jika itu masalahnya!
Bahasa yang diinterpretasikan seperti Python sering menggunakan perpustakaan berkinerja tinggi seperti NumPy / panda untuk langkah backtesting, untuk mempertahankan tingkat daya saing yang wajar dengan setara yang dikompilasi. Pada akhirnya bahasa yang dipilih untuk backtesting akan ditentukan oleh kebutuhan algoritmik tertentu serta berbagai perpustakaan yang tersedia dalam bahasa (lebih lanjut tentang itu di bawah).
Konstruksi portofolio dan manajemen risiko
Komponen konstruksi portofolio dan manajemen risiko sering diabaikan oleh pedagang algoritmik ritel. Ini hampir selalu merupakan kesalahan. Alat-alat ini menyediakan mekanisme yang akan melestarikan modal. Mereka tidak hanya mencoba untuk mengurangi jumlah taruhan
Versi canggih dari komponen ini dapat memiliki efek yang signifikan pada kualitas dan konsistensi profitabilitas. Sangat mudah untuk membuat strategi yang stabil karena mekanisme konstruksi portofolio dan manajer risiko dapat dengan mudah dimodifikasi untuk menangani beberapa sistem.
Tugas sistem konstruksi portofolio adalah untuk mengambil seperangkat perdagangan yang diinginkan dan menghasilkan seperangkat perdagangan yang sebenarnya yang meminimalkan churn, mempertahankan eksposur terhadap berbagai faktor (seperti sektor, kelas aset, volatilitas dll) dan mengoptimalkan alokasi modal ke berbagai strategi dalam portofolio.
Konstruksi portofolio sering berkurang menjadi masalah aljabar linier (seperti faktorisasi matriks) dan karenanya kinerja sangat tergantung pada efektivitas implementasi aljabar linier numerik yang tersedia. Perpustakaan umum termasuk uBLAS, LAPACK dan NAG untuk C ++. MatLab juga memiliki operasi matriks yang dioptimalkan secara luas. Python menggunakan NumPy / SciPy untuk perhitungan tersebut. Portofolio yang sering direbalansikan akan membutuhkan perpustakaan matriks yang dikompilasi (dan dioptimalkan dengan baik!) untuk melakukan langkah ini, sehingga tidak menghambat sistem perdagangan.
Pengelolaan risiko adalah bagian penting lainnya dari sistem perdagangan algoritmik. Risiko dapat datang dalam berbagai bentuk: peningkatan volatilitas (meskipun ini dapat dilihat sebagai diinginkan untuk strategi tertentu!), peningkatan korelasi antara kelas aset, default counterparty, pemadaman server, peristiwa
Komponen manajemen risiko mencoba dan mengantisipasi efek dari volatilitas yang berlebihan dan korelasi antara kelas aset dan efek selanjutnya pada modal perdagangan. Seringkali ini berkurang menjadi seperangkat perhitungan statistik seperti tes stres Monte Carlo. Ini sangat mirip dengan kebutuhan komputasi mesin penetapan harga derivatif dan sebagai itu akan terikat CPU. Simulasi ini sangat paralel (lihat di bawah) dan, sampai batas tertentu, dimungkinkan untuk membuang perangkat keras pada masalah tersebut.
Sistem Eksekusi
Tugas sistem eksekusi adalah untuk menerima sinyal perdagangan yang disaring dari komponen konstruksi portofolio dan manajemen risiko dan mengirimkannya ke broker atau sarana akses pasar lainnya. Untuk sebagian besar strategi perdagangan algoritmik ritel ini melibatkan koneksi API atau FIX ke broker seperti Interactive Brokers. Pertimbangan utama saat memutuskan bahasa termasuk kualitas API, ketersediaan language-wrapper untuk API, frekuensi eksekusi dan slippage yang diharapkan.
Sebagian besar API akan menyediakan antarmuka C ++ dan / atau Java. Biasanya terserah kepada komunitas untuk mengembangkan wrapper khusus bahasa untuk C #, Python, R, Excel dan MatLab. Perhatikan bahwa dengan setiap plugin tambahan yang digunakan (terutama wrapper API) ada ruang untuk bug menyelinap ke dalam sistem. Selalu uji plugin semacam ini dan pastikan mereka aktif dipelihara. Pengukur yang bermanfaat adalah melihat berapa banyak pembaruan baru untuk basis kode yang telah dibuat dalam beberapa bulan terakhir.
Frekuensi eksekusi sangat penting dalam algoritma eksekusi. Perhatikan bahwa ratusan pesanan dapat dikirim setiap menit dan sebagai kinerja yang kritis. Slippage akan terjadi melalui sistem eksekusi berkinerja buruk dan ini akan berdampak dramatis pada profitabilitas.
Bahasa dengan tipe statis (lihat di bawah) seperti C ++ / Java umumnya optimal untuk eksekusi tetapi ada kompromi dalam waktu pengembangan, pengujian dan kemudahan pemeliharaan. bahasa dengan tipe dinamis, seperti Python dan Perl sekarang umumnya cukup cepat. Selalu pastikan komponen dirancang dengan modular (lihat di bawah) sehingga mereka dapat ditukarkan saat skala sistem.
Proses Perencanaan dan Pengembangan Arsitektur
Komponen-komponen dari sistem perdagangan, frekuensi dan kebutuhan volume telah dibahas di atas, tetapi infrastruktur sistem belum dibahas. Mereka yang bertindak sebagai pedagang ritel atau bekerja di dana kecil kemungkinan akan
Pembagian Perhatian
Salah satu keputusan paling penting yang harus dibuat pada awalnya adalah bagaimana untuk "memisahkan masalah" dari sistem perdagangan. Dalam pengembangan perangkat lunak, ini pada dasarnya berarti bagaimana untuk memecah berbagai aspek dari sistem perdagangan menjadi komponen modular terpisah.
Dengan mengekspos antarmuka pada masing-masing komponen, mudah untuk menukar bagian dari sistem untuk versi lain yang membantu kinerja, keandalan atau pemeliharaan, tanpa memodifikasi kode ketergantungan eksternal. Ini adalah "praktik terbaik" untuk sistem tersebut. Untuk strategi pada frekuensi yang lebih rendah, praktik tersebut disarankan. Untuk perdagangan frekuensi ultra tinggi, buku aturan mungkin harus diabaikan dengan mengorbankan tweaking sistem untuk kinerja yang lebih tinggi. Sistem yang lebih erat dapat diinginkan.
Membuat peta komponen dari sistem perdagangan algoritmik adalah artikel yang layak sendiri. Namun, pendekatan yang optimal adalah untuk memastikan ada komponen terpisah untuk masukan data pasar historis dan real-time, penyimpanan data, API akses data, backtester, parameter strategi, konstruksi portofolio, manajemen risiko dan sistem eksekusi otomatis.
Sebagai contoh, jika penyimpanan data yang digunakan saat ini berkinerja buruk, bahkan pada tingkat pengoptimalan yang signifikan, dapat diganti dengan minimal penulisan ulang ke data ingestion atau data access API.
Manfaat lain dari komponen terpisah adalah bahwa hal ini memungkinkan berbagai bahasa pemrograman untuk digunakan dalam sistem secara keseluruhan. Tidak perlu dibatasi untuk bahasa tunggal jika metode komunikasi komponen adalah bahasa independen. Ini akan terjadi jika mereka berkomunikasi melalui TCP / IP, ZeroMQ atau beberapa protokol bahasa independen lainnya.
Sebagai contoh konkret, pertimbangkan kasus sistem backtesting yang ditulis dalam C ++ untuk kinerja
Pertimbangan Kinerja
Performa adalah pertimbangan penting untuk sebagian besar strategi perdagangan. Untuk strategi frekuensi yang lebih tinggi, ini adalah faktor yang paling penting.
Kebijaksanaan yang berlaku seperti yang dinyatakan oleh Donald Knuth, salah satu bapak Ilmu Komputer, adalah bahwa
Profiling tools digunakan untuk menentukan di mana kemacetan muncul. Profil dapat dibuat untuk semua faktor yang tercantum di atas, baik dalam lingkungan MS Windows atau Linux. Ada banyak sistem operasi dan alat bahasa yang tersedia untuk melakukannya, serta utilitas pihak ketiga.
C++, Java, Python, R dan MatLab semuanya mengandung perpustakaan berkinerja tinggi (baik sebagai bagian dari standar mereka atau secara eksternal) untuk struktur data dasar dan pekerjaan algoritmik.
Satu pengecualian adalah jika arsitektur perangkat keras yang sangat disesuaikan diperlukan dan algoritma menggunakan ekstensi eksklusif secara luas (seperti cache kustom). Namun, seringkali
Latensi seringkali merupakan masalah dari sistem eksekusi karena alat penelitian biasanya terletak di mesin yang sama. Untuk yang pertama, latensi dapat terjadi di beberapa titik di sepanjang jalur eksekusi. Basis data harus dikonsultasikan (latensi disk/jaringan), sinyal harus dihasilkan (sistem operasi, latensi pesan kernel), sinyal perdagangan dikirim (latensi NIC) dan pesanan diproses (latensi internal sistem pertukaran).
Untuk operasi frekuensi yang lebih tinggi adalah perlu untuk menjadi akrab dengan kernel optimasi serta optimasi transmisi jaringan. ini adalah bidang yang mendalam dan jauh di luar ruang lingkup artikel tetapi jika UHFT algoritma yang diinginkan maka menyadari kedalaman pengetahuan yang diperlukan!
Caching sangat berguna dalam toolkit pengembang perdagangan kuantitatif. Caching mengacu pada konsep menyimpan data yang sering diakses dengan cara yang memungkinkan akses kinerja yang lebih tinggi, dengan mengorbankan potensi stabilitas data. Kasus penggunaan umum terjadi dalam pengembangan web ketika mengambil data dari database relasional yang didukung disk dan meletakkannya ke dalam memori. Setiap permintaan berikutnya untuk data tidak harus
Untuk situasi trading caching bisa sangat bermanfaat. Misalnya, status saat ini dari portofolio strategi dapat disimpan dalam cache sampai seimbang kembali, sehingga daftar tidak perlu diregenerasi pada setiap loop algoritma trading. Regenerasi tersebut kemungkinan merupakan operasi CPU atau disk I/O yang tinggi.
Namun, caching tidak tanpa masalah sendiri. Regenerasi data cache sekaligus, karena sifat volatile dari penyimpanan cache, dapat menempatkan permintaan yang signifikan pada infrastruktur. Masalah lain adalah dog-stacking, di mana beberapa generasi salinan cache baru dilakukan di bawah beban yang sangat tinggi, yang menyebabkan kegagalan kaskade.
Alokasi memori dinamis adalah operasi yang mahal dalam eksekusi perangkat lunak. Oleh karena itu, sangat penting bagi aplikasi perdagangan kinerja yang lebih tinggi untuk mengetahui dengan baik bagaimana memori dialokasikan dan dialokasikan selama aliran program. Standar bahasa yang lebih baru seperti Java, C # dan Python semuanya melakukan pengumpulan sampah otomatis, yang mengacu pada dealokasi memori yang dialokasikan secara dinamis ketika objek keluar dari ruang lingkup.
Pengumpulan sampah sangat berguna selama pengembangan karena mengurangi kesalahan dan membantu keterbacaan. Namun, seringkali tidak optimal untuk strategi perdagangan frekuensi tinggi tertentu. Pengumpulan sampah kustom sering diinginkan untuk kasus ini. Di Java, misalnya, dengan menyesuaikan pengumpul sampah dan konfigurasi heap, dimungkinkan untuk mendapatkan kinerja tinggi untuk strategi HFT.
C++ tidak menyediakan pengumpul sampah asli dan oleh karena itu perlu untuk menangani semua alokasi memori / deallocation sebagai bagian dari implementasi objek. Sementara berpotensi rentan terhadap kesalahan (potensi mengarah ke penunjuk menggantung) sangat berguna untuk memiliki kontrol butiran halus tentang bagaimana objek muncul di tumpukan untuk aplikasi tertentu.
Banyak operasi dalam sistem perdagangan algoritmik dapat disesuaikan dengan paralelisasi. Ini mengacu pada konsep melakukan beberapa operasi programatik pada saat yang sama, yaitu secara paralel. Yang disebut algoritma paralel yang membingungkan mencakup langkah-langkah yang dapat dihitung sepenuhnya independen dari langkah-langkah lain. Operasi statistik tertentu, seperti simulasi Monte Carlo, adalah contoh yang baik dari algoritma paralel yang membingungkan karena setiap penarikan acak dan operasi jalur berikutnya dapat dihitung tanpa pengetahuan tentang jalur lain.
Algoritma lain hanya sebagian saja yang dapat di paralelkan. Simulasi dinamika fluida adalah contoh seperti itu, di mana domain komputasi dapat dibagi, tetapi pada akhirnya domain ini harus berkomunikasi satu sama lain dan dengan demikian operasi sebagian berurutan. Algoritma yang dapat di paralelkan tunduk pada Hukum Amdahl, yang memberikan batas atas teoretis untuk peningkatan kinerja algoritma yang di paralelkan ketika tunduk pada proses NN yang terpisah (misalnya pada inti CPU atau thread).
Paralelisasi telah menjadi semakin penting sebagai sarana pengoptimalan karena kecepatan clock prosesor telah stagnan, karena prosesor yang lebih baru mengandung banyak core untuk melakukan perhitungan paralel.
Perangkat keras GPU tersebut umumnya hanya cocok untuk aspek penelitian keuangan kuantitatif, sedangkan perangkat keras lain yang lebih khusus (termasuk Field-Programmable Gate Arrays - FPGA) digunakan untuk (U) HFT. Saat ini, sebagian besar linguage modern mendukung tingkat paralel / multithreading.
Scaling dalam rekayasa perangkat lunak dan operasi mengacu pada kemampuan sistem untuk menangani beban yang terus meningkat dalam bentuk permintaan yang lebih besar, penggunaan prosesor yang lebih tinggi dan alokasi memori yang lebih banyak. Dalam perdagangan algoritmik, strategi dapat berskala jika dapat menerima jumlah modal yang lebih besar dan masih menghasilkan pengembalian yang konsisten.
Sementara sistem harus dirancang untuk skala, seringkali sulit untuk memprediksi terlebih dahulu di mana kemacetan akan terjadi. Logging, pengujian, profil dan pemantauan yang ketat akan sangat membantu dalam memungkinkan sistem untuk skala. Bahasa sendiri sering digambarkan sebagai
Salah satu cara untuk mengelola skala adalah dengan memisahkan perhatian, seperti yang disebutkan di atas. Untuk lebih memperkenalkan kemampuan untuk menangani "spikes" dalam sistem (yaitu volatilitas tiba-tiba yang memicu banyak perdagangan), berguna untuk membuat arsitektur "message queuing".
Sebagai gantinya permintaan yang hilang mereka hanya disimpan dalam tumpukan sampai pesan ditangani. Ini sangat berguna untuk mengirim perdagangan ke mesin eksekusi. Jika mesin menderita latensi yang berat maka itu akan mencadangkan perdagangan. Antrian antara generator sinyal perdagangan dan API eksekusi akan meringankan masalah ini dengan mengorbankan potensi seluncur perdagangan.
Hardware dan Sistem Operasi
Perangkat keras yang menjalankan strategi Anda dapat memiliki dampak yang signifikan pada profitabilitas algoritma Anda. Ini bukan masalah yang terbatas pada pedagang frekuensi tinggi juga. Pilihan yang buruk dalam perangkat keras dan sistem operasi dapat menyebabkan crash mesin atau reboot pada saat yang paling tidak tepat. Oleh karena itu perlu dipertimbangkan di mana aplikasi Anda akan berada. Pilihan umumnya antara mesin desktop pribadi, server jarak jauh, penyedia
Mesin desktop mudah dipasang dan dikelola, terutama dengan sistem operasi ramah pengguna yang lebih baru seperti Windows 7/8, Mac OSX dan Ubuntu. Sistem desktop memang memiliki beberapa kelemahan yang signifikan, bagaimanapun. Yang terpenting adalah bahwa versi sistem operasi yang dirancang untuk mesin desktop cenderung memerlukan reboot / patching (dan sering pada saat terburuk!).
Menggunakan perangkat keras di lingkungan rumah (atau kantor lokal) dapat menyebabkan masalah konektivitas internet dan waktu aktif daya. Manfaat utama dari sistem desktop adalah bahwa tenaga kuda komputasi yang signifikan dapat dibeli untuk sebagian kecil dari biaya server khusus jarak jauh (atau sistem berbasis cloud) dengan kecepatan yang sebanding.
Server khusus atau mesin berbasis cloud, meskipun sering lebih mahal daripada opsi desktop, memungkinkan infrastruktur redundansi yang lebih signifikan, seperti cadangan data otomatis, kemampuan untuk lebih mudah memastikan uptime dan pemantauan jarak jauh.
Pada Windows ini umumnya melalui GUI Remote Desktop Protocol (RDP). Pada sistem berbasis Unix baris perintah Secure SHell (SSH) digunakan. Infrastruktur server berbasis Unix hampir selalu berbasis baris perintah yang segera membuat alat pemrograman berbasis GUI (seperti MatLab atau Excel) tidak dapat digunakan.
Sebuah server co-located, seperti ungkapan yang digunakan di pasar modal, hanyalah server khusus yang berada di dalam pertukaran untuk mengurangi latensi algoritma perdagangan.
Aspek terakhir untuk pilihan perangkat keras dan pilihan bahasa pemrograman adalah platform independen. Apakah ada kebutuhan untuk kode untuk berjalan di beberapa sistem operasi yang berbeda? Apakah kode dirancang untuk dijalankan pada jenis arsitektur prosesor tertentu, seperti Intel x86/x64 atau apakah mungkin untuk dijalankan pada prosesor RISC seperti yang diproduksi oleh ARM? Masalah ini akan sangat tergantung pada frekuensi dan jenis strategi yang diterapkan.
Ketahanan dan Ujian
Salah satu cara terbaik untuk kehilangan banyak uang pada perdagangan algoritmik adalah dengan membuat sistem tanpa ketahanan. Ini mengacu pada daya tahan sistem ketika tunduk pada peristiwa langka, seperti kebangkrutan pialang, volatilitas berlebihan tiba-tiba, downtime di seluruh wilayah untuk penyedia server cloud atau penghapusan secara tidak sengaja dari seluruh basis data perdagangan. Tahun keuntungan dapat dihilangkan dalam hitungan detik dengan arsitektur yang dirancang dengan buruk. Sangat penting untuk mempertimbangkan masalah seperti debugging, pengujian, logging, backup, ketersediaan tinggi dan pemantauan sebagai komponen inti sistem Anda.
Kemungkinan bahwa dalam setiap aplikasi perdagangan kuantitatif khusus yang cukup rumit setidaknya 50% dari waktu pengembangan akan dihabiskan untuk debugging, pengujian dan pemeliharaan.
Hampir semua bahasa pemrograman baik dikirim dengan debugger terkait atau memiliki alternatif pihak ketiga yang dihormati. pada dasarnya, debugger memungkinkan eksekusi program dengan penyisipan titik putus sewenang-wenang di jalur kode, yang sementara menghentikan eksekusi untuk menyelidiki keadaan sistem. Manfaat utama dari debugging adalah bahwa dimungkinkan untuk menyelidiki perilaku kode sebelum titik crash yang diketahui.
Debugging adalah komponen penting dalam kotak alat untuk menganalisis kesalahan pemrograman. Namun, mereka lebih banyak digunakan dalam bahasa yang dikompilasi seperti C ++ atau Java, karena bahasa yang diinterpretasikan seperti Python sering lebih mudah untuk debug karena lebih sedikit LOC dan pernyataan yang kurang bertele-tele. Meskipun kecenderungan ini, Python dikirim dengan pdb, yang merupakan alat debugging yang canggih. Microsoft Visual C ++ IDE memiliki utilitas debugging GUI yang luas, sementara untuk programmer baris perintah Linux C ++, debugger gdb ada.
Pengujian dalam pengembangan perangkat lunak mengacu pada proses penerapan parameter dan hasil yang diketahui pada fungsi tertentu, metode dan objek dalam basis kode, untuk mensimulasikan perilaku dan mengevaluasi beberapa jalur kode, membantu memastikan bahwa sistem berperilaku seperti seharusnya. Paradigma yang lebih baru dikenal sebagai Pengembangan Terdiri dari Uji (TDD), di mana kode uji dikembangkan terhadap antarmuka yang ditentukan tanpa implementasi. Sebelum penyelesaian basis kode yang sebenarnya semua tes akan gagal. Karena kode ditulis untuk mengisi kekosongan, semua tes akhirnya akan lulus, pada saat itu pengembangan harus dihentikan.
TDD membutuhkan desain spesifikasi awal yang luas serta tingkat disiplin yang sehat untuk dilaksanakan dengan sukses. Di C ++, Boost menyediakan kerangka pengujian unit. Di Java, perpustakaan JUnit ada untuk memenuhi tujuan yang sama. Python juga memiliki modul unittest sebagai bagian dari perpustakaan standar. Banyak bahasa lain memiliki kerangka pengujian unit dan sering ada beberapa pilihan.
Dalam lingkungan produksi, logging yang canggih sangat penting. Logging mengacu pada proses output pesan, dengan berbagai tingkat keparahan, mengenai perilaku eksekusi sistem ke file atau database datar. Log adalah
Baik Microsoft Windows dan Linux dilengkapi dengan kemampuan sistem logging yang luas dan bahasa pemrograman cenderung dikirim dengan perpustakaan logging standar yang mencakup sebagian besar kasus penggunaan.
Sementara logging sistem akan memberikan informasi tentang apa yang telah terjadi di masa lalu, pemantauan aplikasi akan memberikan wawasan tentang apa yang terjadi sekarang. Semua aspek sistem harus dipertimbangkan untuk pemantauan. Metrik tingkat sistem seperti penggunaan disk, memori yang tersedia, bandwidth jaringan dan penggunaan CPU memberikan informasi beban dasar.
Metrik perdagangan seperti harga/volume yang tidak normal, penarikan cepat tiba-tiba dan eksposur akun untuk sektor/pasar yang berbeda juga harus terus dipantau.
Pemantauan sistem seringkali merupakan domain dari administrator sistem atau manajer operasi. Namun, sebagai pengembang perdagangan tunggal, metrik ini harus ditetapkan sebagai bagian dari desain yang lebih besar.
Backup dan ketersediaan tinggi harus menjadi perhatian utama dari sistem perdagangan. Pertimbangkan dua pertanyaan berikut: 1) Jika seluruh basis data produksi data pasar dan sejarah perdagangan dihapus (tanpa backup) bagaimana algoritma penelitian dan eksekusi akan terpengaruh? 2) Jika sistem perdagangan mengalami pemadaman untuk jangka waktu yang lama (dengan posisi terbuka) bagaimana ekuitas akun dan profitabilitas yang sedang berlangsung akan terpengaruh?
Hal ini sangat penting untuk menempatkan sistem untuk membuat cadangan data dan juga untuk menguji pemulihan data tersebut. Banyak individu tidak menguji strategi pemulihan. Jika pemulihan dari kecelakaan belum diuji dalam lingkungan yang aman, apakah ada jaminan bahwa pemulihan akan tersedia pada saat terburuk?
Demikian pula, ketersediaan yang tinggi perlu di
Memilih Bahasa
Sekarang telah diberikan detail yang cukup pada berbagai faktor yang timbul ketika mengembangkan sistem perdagangan algoritmik kinerja tinggi khusus.
Sistem Tipe
Ketika memilih bahasa untuk tumpukan perdagangan, perlu untuk mempertimbangkan sistem tipe. Bahasa yang menarik untuk perdagangan algoritmik adalah baik secara statis-atau dinamis-di-type. Bahasa yang di-type secara statis melakukan pemeriksaan tipe (misalnya bilangan bulat, float, kelas kustom dll) selama proses kompilasi. Bahasa tersebut termasuk C ++ dan Java. Bahasa yang di-type secara dinamis melakukan sebagian besar pemeriksaan tipe pada saat runtime. Bahasa tersebut termasuk Python, Perl dan JavaScript.
Untuk sistem yang sangat numerik seperti mesin perdagangan algoritmik, pengecekan tipe pada waktu kompilasi dapat sangat bermanfaat, karena dapat menghilangkan banyak bug yang sebaliknya akan menyebabkan kesalahan numerik. Namun, pengecekan tipe tidak menangkap segalanya, dan di sinilah penanganan pengecualian datang karena perlunya menangani operasi yang tidak terduga. Bahasa dinamis (yaitu yang diketik secara dinamis) sering dapat menyebabkan kesalahan run-time yang sebaliknya akan tertangkap dengan pengecekan tipe waktu kompilasi. Untuk alasan ini, konsep TDD (lihat di atas) dan pengujian unit muncul yang, ketika dilakukan dengan benar, sering memberikan lebih banyak keamanan daripada pengecekan waktu kompilasi saja.
Manfaat lain dari bahasa yang diketik secara statis adalah bahwa compiler dapat membuat banyak optimasi yang tidak tersedia untuk bahasa yang diketik secara dinamis, hanya karena jenis (dan dengan demikian persyaratan memori) diketahui pada saat kompilasi.
Open Source atau Proprietary?
Salah satu pilihan terbesar yang tersedia bagi pengembang perdagangan algoritmik adalah apakah akan menggunakan teknologi proprietary (komersial) atau open source. Ada kelebihan dan kekurangan untuk kedua pendekatan.
Microsoft.NET stack (termasuk Visual C++, Visual C#) dan MathWorks
Microsoft dan MathWorks keduanya menyediakan dokumentasi berkualitas tinggi yang luas untuk produk mereka. Selanjutnya, komunitas di sekitar setiap alat sangat besar dengan forum web aktif untuk keduanya. Perangkat lunak.NET memungkinkan integrasi kohesif dengan beberapa bahasa seperti C ++, C # dan VB, serta penghubung mudah ke produk Microsoft lainnya seperti database SQL Server melalui LINQ. MatLab juga memiliki banyak plugin / perpustakaan (beberapa gratis, beberapa komersial) untuk hampir semua domain penelitian kuantitatif.
Ada juga kelemahan. Dengan salah satu perangkat lunak biaya tidak signifikan untuk pedagang tunggal (meskipun Microsoft menyediakan versi entry-level Visual Studio secara gratis). alat Microsoft
MatLab juga tidak memiliki beberapa plugin kunci seperti pengelupasan yang baik di sekitar Interactive Brokers API, salah satu dari sedikit broker yang dapat melakukan perdagangan algoritmik berkinerja tinggi. Masalah utama dengan produk eksklusif adalah kurangnya ketersediaan kode sumber.
Perangkat sumber terbuka telah menjadi kelas industri untuk beberapa waktu. Sebagian besar ruang aset alternatif membuat penggunaan luas dari open-source Linux, MySQL / PostgreSQL, Python, R, C ++ dan Java dalam peran produksi berkinerja tinggi. Namun, mereka jauh dari terbatas pada domain ini. Python dan R, khususnya, mengandung banyak perpustakaan numerik yang luas untuk melakukan hampir semua jenis analisis data yang dapat dibayangkan, seringkali pada kecepatan eksekusi sebanding dengan bahasa yang dikompilasi, dengan peringatan tertentu.
Python dan R membutuhkan lebih sedikit baris kode (LOC) untuk mencapai fungsionalitas yang sama, terutama karena perpustakaan yang luas.
Mengingat bahwa waktu sebagai pengembang sangat berharga, dan kecepatan eksekusi sering kurang (kecuali di ruang HFT), layak untuk memberikan pertimbangan ekstensif untuk tumpukan teknologi open source. Python dan R memiliki komunitas pengembangan yang signifikan dan sangat didukung dengan baik, karena popularitas mereka. Dokumentasi sangat baik dan bug (setidaknya untuk perpustakaan inti) tetap langka.
Perangkat sumber terbuka sering mengalami kekurangan kontrak dukungan komersial khusus dan berjalan secara optimal pada sistem dengan antarmuka pengguna yang kurang memaafkan. Server Linux khas (seperti Ubuntu) seringkali sepenuhnya berorientasi baris perintah. Selain itu, Python dan R dapat lambat untuk tugas eksekusi tertentu. Ada mekanisme untuk mengintegrasikan dengan C ++ untuk meningkatkan kecepatan eksekusi, tetapi membutuhkan beberapa pengalaman dalam pemrograman multi-bahasa.
Sementara perangkat lunak proprietari tidak kebal dari masalah ketergantungan / versi, jauh lebih jarang harus berurusan dengan versi perpustakaan yang salah di lingkungan seperti itu.
Saya akan berani pendapat pribadi saya di sini dan menyatakan bahwa saya membangun semua alat perdagangan saya dengan teknologi open source. Secara khusus saya menggunakan: Ubuntu, MySQL, Python, C ++ dan R. Kematangan, ukuran komunitas, kemampuan untuk
Baterai Termasuk?
Header dari bagian ini mengacu pada
C++ terkenal dengan Standard Template Library (STL) yang berisi banyak struktur data berkinerja tinggi dan algoritma
Di luar perpustakaan standar, C++ menggunakan perpustakaan Boost, yang mengisi
Python memiliki kombinasi perpustakaan analisis data berkinerja tinggi NumPy/SciPy/Pandas, yang telah mendapatkan penerimaan luas untuk penelitian perdagangan algoritmik. Selanjutnya, plugin berkinerja tinggi ada untuk mengakses database relasional utama, seperti MySQL++ (MySQL/C++), JDBC (Java/MatLab), MySQLdb (MySQL/Python) dan psychopg2 (PostgreSQL/Python). Python bahkan dapat berkomunikasi dengan R melalui plugin RPy!
Salah satu aspek yang sering diabaikan dari sistem perdagangan saat dalam tahap penelitian dan desain awal adalah konektivitas ke API broker. Sebagian besar API secara native mendukung C ++ dan Java, tetapi beberapa juga mendukung C # dan Python, baik secara langsung atau dengan kode wrapper yang disediakan komunitas ke API C ++.
Kesimpulan
Seperti yang sekarang jelas, pilihan bahasa pemrograman untuk sistem perdagangan algoritmik tidak mudah dan membutuhkan pemikiran yang mendalam. Pertimbangan utama adalah kinerja, kemudahan pengembangan, ketahanan dan pengujian, pemisahan masalah, keakraban, pemeliharaan, ketersediaan kode sumber, biaya lisensi dan kematangan perpustakaan.
Manfaat dari arsitektur terpisah adalah bahwa hal itu memungkinkan bahasa untuk dihubungkan untuk aspek yang berbeda dari tumpukan perdagangan, sebagai dan ketika persyaratan berubah.