Interviu cu Peter Lawrey

Bună, tuturor! Sunt Attila, pentru Today Software Magazine și astăzi îl am cu mine pe Peter Lawrey. Peter, îți multumesc că ai acceptat să ne oferi acest interviu în care vom vorbi despre performanța Java. Te rog să te prezinți.

[Peter] Da. Mă numesc Peter Lawrey, sunt consultant Java în domeniul low latency. Am un blog bine cunoscut, numit "Vanilla Java", care are aproximativ 120.000 de accesări lunar; am de asemenea și o bibliotecă numită "Chronicle" pentru low latency persistence IPC și stocare de date și sunt al treilea din StackOverflow pentru Java.

Când oamenii se gândesc la low latency / performanță crescută, de obicei spun lucruri cum ar fi "C++ este mai bun", referindu-se în termenii limbajului de programare. Cât de important crezi că este limbajul de programare și ce alți factori influențează latency sau throughput al sistemului, în afară de limbajul de programare?

[Peter] Ceea ce am descoperit este că diferite limbaje de programare pot atrage diferite stiluri de dezvoltare și dezvoltări diferite și, în mod special, dacă ai un limbaj low level cum este C++ sau C și nu ai o înțelegere prea bună în legătură cu ceea ce se întâmplă cu exactitate, este ca și cum te-ai împușca singur în picior și ai învăța rapid să te descurci. Nu ai de ales. Pe când în Java, mulți dezvoltatori sunt în mod intenționat protejați și nu este nevoie să cunoască toate aceste detalii și, de aceea, nici nu o fac, ceea ce este în general un lucru bun, cu excepția momentului în care vrei să fi capabil să programezi în low latency și ai nevoie să înțelegi mai bine ceea ce face codul cu adevărat. Așa că nu putem spune că nu se poate cu Java, ci mai degrabă că nu există atât de mulți dezvoltatori Java care să aibă respectivul set de aptitudini, iar în C++ ești oarecum obligat să ai acel set de aptitudini - nu vei supraviețui dacă nu. Bibliotecile pot face de asemenea diferența, dar cel mai mare avantaj pentru Java este faptul că atât de multe dintre bibliotecile comune de care este posibil să ai nevoie, sunt încorporate, pe când în C++ trebuie să apelezi la biblioteci terțe pentru a face multe din aceleași lucruri.

Deci crezi că este fondată opinia generală conform căreia C++ este mai rapid sau că limbajele compilate sunt mai rapide decat Java, sau este doar un mit?

[Peter] În teorie, C++ este întotdeauna mai rapid. În teorie. Numai că, în practică, ai resurse limitate, ai timp limitat, expertiză limitată și ai cerințele care se schimbă și, într-un astfel de mediu, ceea ce se poate întâmpla este să nu ai suficient timp pentru a micro-optimiza fiecare bucățică mică. Nu poți regla fin totul, deoarece datele devin greu de gestionat. Deci, dacă avem la dispoziție o săptămână sau o lună, un dezvoltator care este la fel de competent în ambele limbaje, va produce oarecum aceeași performanță. Dar dacă, în schimb, dai aceluiași dezvoltator un an pentru a rezolva aceeași sarcina, va fi mai rapid în C++. Și când vezi bibliotecile care sunt în mod special mai rapide în C++ și C, sunt probleme ușor de înțeles, care nu se schimbă prea mult și care sunt tuned to death, lucruri precum procesarea video, operațiuni matrice, genul de operațiuni care au existat de foarte mult timp, care implică un impuls foarte mare, coduri simple repetate de multe ori, și în aceste situații vei găsi că C este mai rapid. Dar în cele mai multe aplicații comerciale, cantitatea de reglaj fin al codului pe care poți să o faci nu este așa de importantă precum performanța în ansamblu a aplicației tale și logica afacerilor tinde să se modifice în timp, iar apoi, tindem să ne gândim la mentenabilitate și rezistență și odată ce aceasta începe să se ivească și ai de înfruntat multe schimbări, atunci trebuie să dai înapoi în C++, oricum. Vei sfârși construind multe din protecțiile pe care Java ți le oferă deja, de exemplu, vei sfârși prin a avea un fel de sistem de brokering mesaje pentru a izola componentele sistemului tău, pentru a-l proteja împotriva distrugerii, de exemplu,toate acele lucruri pe care Java le va face pentru tine în mod eficient. Așa că nu există garanții că C++ ar fi mai rapid. Am lucrat într-un loc în care toate aplicațiile pentru clienți erau scrise în C++ și acestea erau less latency sensitive, pe când asigurarea tuturor fondurilor, codul sensibil la latency era scris în Java deoarece aveam un timp mai rapid de lansare pe piață și de fapt toate livrările rapide, multe dintre noile schimbări treceau în sistemul Java, pentru că pur și simplu C++ ajunsese la punctul în care era dificil de susținut. Și se tipăreau zilnic rapoarte de avarie. În loc să apară câte o excepție, întregul sistem se prabușea și repornea, iar aceste lucruri ar fi considerate inacceptabile în Java.

Interesant. Deci ce sfat ai da cuiva care este programator Java și de abia începe să fie interesat de performanța sistemului său? Poate că îi interesează pe ei personal sau poate există un motiv extern, de exemplu clientul spune că sistemul este prea încet. Care ar fi primii pași pe care ar trebui să îi facă?

[Peter] Cel mai folositor aspect este vizibilitatea. Ce se întâmplă în sistemul tău, unde se pierde timp, folosirea de lucruri cum ar fi profilers drept o primă etapă pentru a privi întreaga aplicație. Dar mai apoi, odată ce simți că ai înțeles ceea ce face aplicația ta, poți introduce indicatori de timp și îi poți nota, fie prin înregistrarea lor, fie folosind ceva ca și Cronica mea pentru a-i înregistra în modalitatea low latency. Aceasta iți va oferi vizibilitate cu privire la ceea ce face aplicația și iți permite să vezi unde se pierde timpul tău, cum este utilizat, iar apoi poți rezolva problemele simple, luându-le pe bucăți și făcându-le să meargă din ce în ce mai rapid. Cum am ajuns eu în spațiul low latency? Inițial am început cu o companie care nu era în mod special low latency, dar aveam acest țel de a face sistemul de zece ori mai rapid decât trebuia să fie, iar apoi, pentru următorul client și următorii oameni pentru care am lucrat, am făcut același lucru, și tot așa, iar și iar. Și cu timpul am știut de la sute de milisecunde la sute de microsecunde și în final la nivel de subunități de sute de microsecunde. Așa că o poți face pas cu pas, dar am descoperit că, dacă faci un sistem care face față unui volum de zece ori mai mare decât este de fapt necesar, acesta este de obicei și foarte stabil. Deci există beneficii dacă lucrezi așa, în loc să faci mereu numai minimul.

În regulă. Deci, Peter, care este lucrul tău preferat în legătură cu Java? Limbajul sau platforma?

[Peter] Ceea ce îmi place cel mai mult la Java este faptul că are încorporat foarte mult din ceea ce ai nevoie, iar setul de instrumente este foarte bun și matur. Există multe limbaje noi acum, dar nu au profilers și debuggers bune și nici seturi de instrumente care să te ajute să scrii codul și analiza codului. Setul de instrumente este cu adevărat ceea ce aduce Java la viață, ca să spun așa, mai degrabă decât limbajul în sine. Parte a motivului pentru care există un set atât de bun de instrumente este că Java este un limbaj foarte sărac în caracteristici, în sensul că este foarte economic în privința caracteristicilor pe care le adaugă, dar asta înseamnă că fiecare caracteristică este bine înțeleasă, interacțiunea dintre caracteristici este ușor de înțeles și este relativ ușor pentru o aplicație să le deducă, în termeni de verificare, profilare, analizare, privire la efectele secundare și așa mai departe. Deci, datorită faptului că este un limbaj simplu în sine, setul de instrumente este în general foarte bun și te poate salva de multă muncă. Așa că multe din nemulțumirile pe care oamenii le au în legătură cu Java, lucruri precum că "este foarte prolix", multe din ele pot fi înlăturate folosind seturi bune de instrumente. Și, cu siguranță aș recomanda oricui nu folosește un IDE cu profiler, să o facă. Și învățați să folosiți debugger-ul când încercați să vă devirusați programul și vă va salva de multe bătăi de cap.

Bun. Java 8 urmează să apară și ar trebui lansat în toamnă, cred. Există anumite caracteristici care iți plac în mod special?

[Peter] Cred că lucrul cel mai captivant este că sunt multe caracteristici adăugate, nu unele imense în sine, dar multe îmbunătățiri. Closures au primit cea mai mare atenție din partea presei, chiar dacă, tehnic vorbind, nu este decât o ajungere din urmă a C#. Nu s-au putut pune de acord cu privire la specificațiile pe care ar trebui să le aibă closures, așa că în final s-au mulțumit cu ceea ce face C#. Au adăugat extensii virtuale, care în interior sunt numite altfel, nu îmi amintesc, dar de ce le-au numit "extensii virtuale?" - Ei bine, așa le-a denumit C#. Deci, într-un fel, nu este decât o ajungere din urmă a ceea ce fac alte limbaje. Dar multe dintre celelalte caracteristici - există 66 de îmbunătățiri, dintre care 3 sunt legate de closures - multe dintre ele sunt îmbunătățiri mai mici, dar se pot vedea destul de multe progrese în evoluția JVM, lucruri precum introducerea în limbaj a JodaTime"s DateTime - probabil unul dintre accesoriile cele mai populare până acum, care iți permite să folosești un DateTime potrivit, iar pentru mine, la un nivel lower, lucruri precum a avea bariere de memorie discrete adecvate. Unsafe are o barieră de memorie de încărcare (force load)/ depozitare (force store) care este explicită. În trecut, trebuia să o realizezi într-un mod indirect, utilizând alte operațiuni care aveau de asemenea aceste caracteristici, pe când acum poți să te ocupi de ele în mod explicit. Dar aceasta este o caracteristică foarte low level.

Există alte caracteristici pe care ai dori să le vezi în Java și nu sunt incluse în Java 8?

[Peter] Probabil cel mai important lucru pe care aș dori să îl văd îmbunătățit este, din cauză că folosesc Unsafe destul de mult, nu adăugarea unei caracteristici, ci de fapt includerea ei ca parte a specificației. Există multă funcționalitate în Unsafe care este utilizată în Chronicle și Disruptor și alte biblioteci care sunt în afara specificațiilor, așa că ele există în OpenJDK și HotSpot și alte JVM-uri compatibile, cum ar fi Jrocket sau Azul Zing, dar acestea nu sunt standarde. Deci, nu ar trebui să facă nimic în termeni de adăugare de funcționalitate, ci doar ar fi nevoie să transforme aceasta într-o caracteristică standard a tuturor platformelor Java. Astfel ai avea o modalitate standard de a te ocupa de accesul la memorie low level. Și asta, într-o manieră lipsită de amenințare.

Există resurse cum ar fi cărți, bloguri, video, cursuri de pregătire pe care le-ai recomanda programatorilor Java care sunt interesați de domeniul performanței? Există, bineînțeles, blogul tău, pe care l-ai menționat la început și vom face referire la el, dar ce alte resurse ai recomanda?

[Peter] Aș recomanda să se uite pe Performance Java User"s Group, deoarece acolo postez tot ceea ce consider a fi cele mai interesante video pe acest subiect și sper să încurajez și pe alții să posteze acolo, de asemenea. Deci, cred că acesta este cel mai bun loc de pornire. Mai sunt alte două blog-uri. Scuze, nu sunt chiar blog-uri, ci forum-uri, forum-uri de email la care merită să vă uitați, și anume "The Mechanical Sympathy", condus de Martin Thompson, care a fost CTO la L-MAX când Disruptor a fost dezvoltat, dar acesta este totuși foarte low level. Chiar cei mai mulți oameni interesați de performanța Java nu ar putea utiliza aproximativ 99% de acolo, dar este o discuție foarte interesantă, totuși. Mai există un forum numit "Friends" la jClarity, condus de niște tipi care au dezvoltat "Well Grounded Java Developer" pentru Java 7, și anume Benjamin Evans și Martijn Verburg. Ei se concentrează foarte mult pe GC și chestiuni conexe, dar sunt foarte practici și oferă sfaturi bune și de asemenea consultanță celor interesați. Mai au și câteva produse în acel spațiu, dar acel forum este foarte interesant dacă dorești să îți îmbunătățești GC-ul.

Bun. Vom include linkuri la toate acestea în secțiunea de comentarii la acest video. Mai este altceva ce ai dori să adaugi cu privire la acest subiect?

[Peter] Da. Urmează să apară o nouă versiune a Chronicle, care este adăugată la o nouă organizație pe GitHub, numită OpenHFT care este o librărie open source de trading pentru concurență ridicată. Și Chronicle în sine este divizată în secțiuni: memorie, manipularea memoriei și deserializare, separate de la înregistrare, astfel încât nu trebuie să folosești înregistrarea pe disc pentru a-i utiliza caracteristicile și de asemenea a fost făcută mai eficientă, de exemplu, pe acest laptop pot primi 80 de milioane de mesaje pe secundă, trecute de la un fir la altul și asta, cu fiecare mesaj persistând. De asemenea, va avea un suport pentru rolling logs, ceea ce puteai să faci în Chronicle 1, dar mulți oameni ar fi dorit ca biblioteca să facă asta în locul lor, așa că, aceasta va fi o caracteristică adăugată la Chronicle 2. S-au mai pus și bazele unei noi biblioteci, care va încerca stocarea unor cantități enorme de date off-heap. În special în fișierele hărții de memorie, așa că va oferi caracteristici similare cu ceea ce face Terracotta"s BigData, dar în schimb, va fi limitată numai de dimensiunea spațiului tău de pe disc, mai degrabă decât de memoria principală, astfel încât să poți introduce și scoate date mai rapid și totodată să utilizezi mai puțin spațiu. Și va fi open source. Și încă ceva care urmează să apară este FIX engine care va fi bazat de asemenea în jurul Chronicle, astfel încât să poți beneficia de derivare low latency și scriere de FIX messages. Va fi bazat în linii mari pe QuickFix, cu excepția faptului că este conceput pentru a fi mult mai eficient.