Programatorii ar trebui să aibă cunoștințe hardware?

Back in the glorious (Xerox PARC et al) days programmers had both hardware and software knowledge.

2 Likes

da, pentru ca erau 2-3 feluri de hardware.

1 Like

Check out the Xerox Alto restoration youtube series and then we’ll talk :slight_smile: We have it sooo easy we take it for granted.

Atunci îți dedicai câteva săptămâni căutând componente pentru că ăsta era job-ul tău. Procesoarele erau suficient de simple pentru a putea fi înțelese relativ ușor de oricine, la fel și legăturile între diversele componente.

În plus, ca programator, erai oarecum forțat să codezi la un nivel cât mai apropiat de bare metal, deci nu era ca și cum aveai de ales dacă vei știi sau nu despre hardware.

Atunci chiar erau extrem de puține opțiuni hardware dacă ne raportăm la ce găsim azi. Serios, uită-te doar la socket-urile procesoarelor. Dacă cercetezi un pic, o să vezi că există fix un singur fel de componente asupra cărora s-a căzut de acord și ești 99.99% sigur că se potrivesc mereu, indiferent de configurația ta: unitățile de stocare. Atât. Orice placă de bază are memorii care s-ar putea să nu meargă, memorii recomandate, plăci video etc.

Hai să nu mai facem cherry picking aiurea.

1 Like

TL;DR Mersi @iamntz pentru sumar, cam asta voiam sa scriu si eu.

Varianta lunga: suntem intr-un moment in care nu avem toti 20 ani si putine responsabilitati, sa citim la foc automat tot ce misca in secunda in care se intampla. Motiv pentru care research pe subiecte hardware (cel putin la mine in program) incape foarte greu. Prefer sa ma informez doar daca nu exista alta varianta, pentru ca timpul meu e pretios (prefer sa-l petrec cu piticul meu, jucandu-ne).

Chiar ca si persoana care ia decizii de achizitie hardware in micuta firma pe care o coordonez, nu am timp fizic sa imi bat capul cu hardware in cele mai mici amanunte. Consider pierdute ultimele 2 saptamani in care m-am concentrat pe gasirea unui laptop pentru a fi folosit exclusiv ca mediu de dezvoltare (pt ca am ajuns tot la mac).

Atunci cand discut de hardware pentru deployment pornesc de la un set de recomandari de baza, dar sustin intotdeauna ca nu am cum sa stiu ce va fi cel mai potrivit pentru cazul acela concret, si prefer varianta iterarii pe solutie pana o gasesc pe cea mai buna pt client si proiect.

1 Like

Zici de cherry picking in timp ce tu faci asta - nu esti fortat sa stii ASM sau cum functioneaza intern arhitectura unui procesor modern INSA de aici pana la:

este un pic cam mult - o investitie minima in cunostiinte de hardware te va ajuta destul de mult - plus in viitor poate vei evita bug-uri obscure precum memory-related-bit-rotting deoarece stii ca ZFS trebuie folosit cu memorii ECC iar tu ai ales corect configuratia laptop-ului sau acelui mic NFS in-house.

Alt exemplu clar sunt instructiunile unui CPU - am vazut diferente majore intre cloud providers care nu dau acces la toate instructiunile iar librarii precum OpenSSL vor suferi din cauza asta. Exemplu banal:

La fel cand alegi un VM si hab ar nu ai ce sunt IOPS si cum sa le masori iar aplicatia ta este IO bound … fuck yeah!

etc.

Eu am 22 de ani și pot să vorbesc până mâine seara despre hardware de orice fel. (cu excepția FPGA și PLC-urilor)

Profilul “programatorului” standard e oarecum diferit totuși in zilele noastre. Pentru aplicații line of business, web etc ești destul de departe de hardware propriu zis. Care nu înseamnă ca nu faci inginerie sau ca e treaba mai puțin “hard-core” decât cineva care lucrează pe embedded sau ingineri hardware. Îți pasa de el la mai mult ca profil de performanța: câte coreuri, ce viteza, câta memorie, ce IOPS și in ce condiții etc? Trebuie înțelese câteva chesti, dar zic eu la unnivel inalt. Intel e destul de freaked out tocmai de treaba asta pana una alta - atâta timp cât platforma îți oferă nivelul de performanța pe care-l vrei, nu contează dacă e x86 sau arm. Care-i un nivel destul de interesant de abstracție la care sa operezi ca programator.

Otoh, posterul inițial făcea referire la cum să-ți asambleze un PC din părți mai mult sau mai puțin. Care nu e chiar “the wisdom wise men revere”, dacă-mi permiți sa parafrazez.

1 Like

Cred ca ai inteles ca n-am facut 2 saptamani doar asta. In fiecare zi prestez tot ce urmeaza: paid work full-time, mentorship pt angajatii mei si ai altora, mers la conferinte, scris articole si carti, lucrat la PhD.
Da, sa imi descopar un nou hobby, hardware, ziceai?

My whole point is that I find it sad when programmers go with the I don't care at all about hardware attitude when most of our programming heroes dabbed into it and yes, excuses can be fabricated for anything, that’s it.

1 Like

Dap - cand mi-am luat ultimul laptop abia asteptam sa compilez un fork de Ruby cu suport pentru instructiunile TSX numai ca sunt disabled in Haswell deoarece Intel au descoperit un bug in ele - daca as fi fost un pic mai informat asteptam Skylake.

1 Like

Absolut.
Front end: trebuie sa optimizezi codul in funcție de device-ul utilizatorului.
In trecut animatiile erau procesate in browser de procesor. Acum sunt procesate mai mult de placa grafică.
La fel si in back end: dacă stii câteva informații despre procesorul si memoria serverului s-ar putea sa optimizezi codul astfel încât sa te coste hosting-ul mai putin. Sau sa nu se blocheze serverul.

Chiar am intalnit asta recent - optimizari front-end pt. mobile insa fara specificatii pe ce hardware animatiile si JS-ul respectiv ar trebui sa ruleze fluent - asta in timp ce optimizarea se realiza in Chrome pe un desktop cu N-ordine de magnitudine peste un device mobil i.e. 90 FPS-uri pe desktop s-ar putea traduce in 15 pe un mobil de acum doi trei ani.

Programatorii ar trebui să aibă cunoștințe hardware?

  • Da
  • Moderat
  • Nu

0 participanți

Depinde ce intelegem prin “hardware”. Consider ca este obligatoriu sa cunosti “hardware” la modul abstract: ce-i ala un registru, ce-i aia magistrala de adrese si de date, ce-i aia intrerupere, ce-i ala cache, ce-i aia big endian / little endian etc. Si conteaza putin spre deloc sa stii care e socket-ul la modă, la ce frecventa functioneaza memoriile la ora actuala samd.

3 Likes

Nici eu nu stiu pe de rost nr-ul pinilor socket-urilor curente sau fix viteza memoriilor - insa stiu diferentele intre DDR, dual vs quad channel, tipul lor, ce impact au in zonele care ma intereseaza etc.

IMO trebuie sa stii care sunt punctele slabe, cum functioneaza toate intr-un sistem specific sau/si ce componenta este mai importanta in functie de ce tip de aplicatie dezvolti sau/si stil de lucru ai etc.

De exemplu daca folosesti un IDE ar fi util sa stii ca un procesor cu SMT iti va aduce un spor in productivitate.

Plus partea teoretica mentionata de tine.


Ca sa fac o analogie foarte proasta e ca si cum ai dezvolta aplicatii pe automobile si tu nu stii aproape deloc cum functioneaza - atat la nivel conceptual cat si minim la partea de ce piese exista.

1 Like

Mi-am luat o carte in Decembrie de pe Packt


spre surprinderea mea discuta mai mult chestii care nu au legatura cu tehnologia asp.net, cum ar fi operatiile de I/O(timpul de acces la baza de date sau la sistemul de fisiere, latenta retelei, prin cate noduri trece un request ca sa ajunga la server), chestii care mi se pare destul de apropiate de partea hardware.

Initial tehnologia a aparut in mediul Business to Business, odata ce ea a patruns in mediu Business to Consumer, numarul de utilizatori a crescut exponential asa ca se incearca sa se faca optimizari, daca inainte predomina close source si dezvoltai o aplicatie pentru o companie, acuma predomina open source si cele mai cunoscute aplicatii se adreseaza mediului business to consumer, oricine are o idee, buget si skill-uri poate veni cu un produs nou pe piata asa a explodat mediul startups in afara .

3 Likes

Can you expand a bit on that? sounds quite interesting in the context of .NET ofc.

1 Like

OK. Urmatoare parere este oarecum subiectiva. Eu lucrez la companie care face hardware + system de operare (Syneto), deci am o perspectiva mai aparte. Dar lucrez si la un proiect web scris in Java (FeedXL) care are mai putina legatura de hardware.

Pe scurt, parerea mea este ca intelegerea hardware-ului este esentiala pentru aplicatii non-triviale. Incerc sa prezint cateva exemple / idei generale pe diferite tipuri de proiecte:

  1. Software gen ERP: Sa zicem ca lucrezi pentru o companie care produce software ERP si esti responsabil cu implementarea unui modul de emitere factura. Adica clientul va sta la ghiseu pana cand, dupa vanzare, vanzatorul (utilizaotrul ERP-ului) emite factura. Va trebui sa intelegi ce hardware (server, procesor, disk, ram si legatura de retea) ai la dispozitie sa tii clientul in asteptare cat mai putin. Iar rezultatul se poate traduce in bani aproape direct.
  2. Software gen system de operare / management: Noi la Syneto scriem un sistem de operare si management pentru echipamente de stocare date. Desigur, noi trebui sa stim intimitatile functionarii controllerelor si diskurilor. Dar hai sa nu mergem asa de jos, sa zicem ca scrii o aplicatie de automatizare taskuri pentru Android, gen E-Robot, va trebui sa intelegi cum functioneaza a groaza de modele de telefoane, ce fel de senzori au, ce servicii de system au, etc.
  3. Sofware gen web application: Sa zicem iti faci o aplicatie web. Decizi sa il rulezi pe Amazon AWS. Ai nevoie sa iti creezi masini virtuale EC2, sa iti setezi reteaua, etc. Pentru asta va trebui sa citesti si sa intelegi fiecare tip instanta ce hardware are (cpu, ram, diskuri/ssd-uri, IOPS, etc) si va trebui sa stii sa dimensionezi corect infrastructura ta pentru aplicatia ta si numarul tau de utilizatori.

Acum, desigur, in functie de tipul aplicatiei nivelul necesar de cunostinte hardware este diferit. Dar cred ca exista foarte putine cazuri in care poti ignora in totalitate acest aspect.

Ramane de vazut ce aduc technologiile noi cum ar Application As a Service si Serverless Architectures (like Amazon Lambda). In cazurile respective nu te va mai interesa direct configurarea hardware-ului. Dar probabil te va interesa consumul de resurse al aplicatiei tale pentru ca se va traduce dinamic in bani.

8 Likes

Cam asta scrie si in cartea pe care am postat-o desi ai totul intr-un datacenter asta nu inseamna ca ai toata infrastractura pe o masina, ca atunci cand dezvolti, de exemplu disk-urile pot fi virtuale si montate din alta parte, desigur vorbeste mult de arhitectura internetului cum e cablat, aceea schema cu structura de fibra optica pe sub ocean, si cum sa masori, optimizezi transferul de date folosind tool-uri de diagnostic bine cunoscute ca ping, traceroute.

Acuma specific pe .NET vorbeste despre importanta folosirii task-urilor asincrone in api-uri pentru a rula call-uri de api in paralel atunci cand acestea sunt independente. El mai zice ca atunci cand un call de api cheama alta call de api si asta se intampla pe mai multe niveluri acesta e un cod smell si ar trebui reactorizat.

Legat de acessul la baze de date vorbeste foarte mult de Dapper, si ca cine stie bine SQL poate optimiza foarte bine accesul la baze de date, fiindca Dapper e modelat apropiat de SQL, si desigur vorbeste cum ORM folosit gresit poate duce la issue-uri mari de performanta.

1 Like