Frågan var ju om C++ är mer effektiv än t.ex. Java, i "vanlig" kod är inte skillnaden relevant, men om template-meta programmering kan användas så kan det ge C++ en enorm fördel då en rad optimeringar kan göras vi kompilering som inte är möjligt i andra språk (inte ens i Lisp).
Jo, om vi talar om prestanda så är inte Lisp vidare bra exempel. Poängen med Lisp är att det är enkelt att programmera. Men att skriva C++ templates är inte vidare produktivt och väldigt svårt att få det helt korrekt. Jag hörde av Graham, Lisp gurun, att deras backenda som senare såldes till Amazon, gjordes i Lisp. Så när konkurrenterna pratade om en ny funktion, så kunde Graham implementera funktionen på en eftermiddag eller så. På så sätt var Graham alltid före konkurrenterna, och de begrep aldrig hur Graham kunde vara så snabba. Läs hans blogg, mycket intressant läsning. Det krävs typ 10x mer C++ kod än Lisp kod för att göra samma sak. Själv börjar jag bli mer och mer såld på funktionella språk, som faktiskt är eleganta till skillnad från C/C++/C#/Java, etc. Du kan utföra magi med Lisp.
Jobbar bl.a. med att utveckla OS-kärnor och nätverksstackar för högprestandasystem, så har hyfsad koll på tiderna det tar att processa paket. Jobbar däremot inte med börssystem, men som jag förstått det ligger man idag på latenser ner mot eller ibland till och med under 10µs.
Svarstiden på de snabbaste aktiebörssystemen som används, ligger kring 100µs, inte 10µs. Det finns experimentella system som har kring 10µs, men de är oanvändbara. Ett riktigt börssystem måste utföra massa kontroller och administration och sånt, innan en aktieorder accepteras. Dessa experimentella system gör inget sånt, de bara tar emot ordrar utan att kolla nånting. Det är inget man skulle kunna använda på riktigt.
Vid den latensen har man inte mer än 20k-30k CPU cykler på sig per paket och det inkluderar den tid paketet ska DMA:as in och ut från NIC då jag utgår från att den latens man specifierar är latens sett från en extern box. Windows behöver ganska exakt denna tid bara på att leverera och skicka paketet genom OSet (sist jag mätte, vilket var på Win7), Linux klarar detta på strax under 10k cykler och en specialdesignat TCP/IP stack kan komma ner till kanske 2k-3k cykler.
Alla snabba börssystem som ligger kring 100-200µs, använder UDP. Det går inte att få så låg latens med TCP/IP. Ett tips till er, är att ni börjar titta på UDP om ni behöver mera prestanda.
Som jag förstått det kör NASDAQ en "vanlig" Linux, så Java-delen kan max stå för ~50% av cyklerna i genomsnitt.
Jo, det stämmer att det är vanliga Linux som används. Men, de använder inte TCP/IP, så 50% av cyklerna kommer inte att gå åt till nätverkstrafiken.
Linux är inte ett RTOS, så man har inte garanterad svarstiden. Men det är ändå så att med Java inför du än mer jitter då GC sker vid tillfällen du inte kan kontrollera. I majoritet av fallen handlar det om några 10-tals eller i värsta fall 100-tals µs som GC tar och det kan vara ganska långt mellan dessa tillfällen, men GC kommer att hända.
Dessa snabba aktiesystem kör inte Realtime Linux. De kör vanliga Linux. Så man kan inte garantera svarstid.
Och GC kommer aldrig att inträffa på dessa system. De hanterar allt minne själv, de allokerar massa objekt i förväg som sedan återanvänds gång på gång. Så objekt destrueras aldrig. Så GC kommer aldrig att sparka igång. Det är hemligheten.
