Početnička pitanja (kako postati programer, Pascal, C++) pitajte slobodno!

[sali]

ruka-slave kaže:

Slučajno znam da ne zna.

A slučajno znam da ne zna jer sam potrošio par godina rada na optimizaciji kompiliranja programskih jezika u strojni kod.

mislim da je već barem 50 godina konsenzus da u 99,999 posto slučajeva čovjek nemož strojnim kodom parirati kompajleru, niti to iko pokušava, a u preostalih 0,0001 posto kompajler nemože parirati čovjeku (čak niti kao AI kompajler)

[sali]

capttawish kaže:

Okej, napraviš arena alocator, ali kakve to veze ima funkcijama, njihovim internim varijablama i parametrima?

Parametri funkcija i njihove interne varijable su stacku koji je već prealociran kad se program učitava, nema nikakve alokacije tu. Naravno, ako se radi objektima njegov konstruktor ili druge metode mogu raditi alokaciju memoriju. Ili ti objekti mogu biti veliki pa njihovo kopiranje (pass by value) može biti bottleneck. Ali sami prostor za taj objekt je već prealociran.

nije samo prealokacija, spremanje registara i kreiranje okruženja nove funkcije troši cikluse, za neke česte i jednostavne funkcije u C postoje makroi koji rade in-line, npr za string operacije, bez poziva funkcije, naravno header fajl na kraju odredi hoće li se makro dekomponirati u preprocesoru kao funkcija ili in-line kod

[ibm444]

pa naravno da je kompajler dobar.
ovi misle da kompajler ima osobnost. pa i kompajler je napravio čovjek.

programiranje je praksa a ne visoka filozofija.

[ruka-slave]

sali kaže:

mislim da je već barem 50 godina konsenzus da u 99,999 posto slučajeva čovjek nemož strojnim kodom parirati kompajleru, niti to iko pokušava, a u preostalih 0,0001 posto kompajler nemože parirati čovjeku (čak niti kao AI kompajler)

Zadnjih 20 godina ne bih znao, jer sam se zbog raznih "programera" ostavio ćorava posla, ali nije bilo tog kompajlera koji može konkurirati čovjeku koji zna što radi.

Ja sam slučajno nešto radio na optimiranju generiranja koda kompajlera, pa eto nešto sam i znao. Za one koji hoće nešto više, preporučam relativno tanahnu knjižicu "Kombinatorika" (autora iskopam)

Glede alokacije memorije. Ljudi općenito nisu svjesni koliko alokacija i dealokacija memorije troši resursa. Svaka lokalna varijabla koju alocirate u funkciji/potprogramu, svaki parametar koji proslijedite bilo kao pointer bilo kao varijablu, troši resurse. Da stvar bude gora, to je mem2mem transfer, koji je puno sporiji nego mem2reg ili ne daj bože reg2reg.

Uz to ubrojite range check, type check... koje obično izbacite u finalnoj kompilaciji, pa onda dobijete klasični zez da vam zbog nepostojanja range checka netko pregazi programski kod, iako to po ring0 ne bi smjelo biti moguće, ali eto.

Plus na koncu kod alokacije i dealokacije dolazi do fragmentacije memorije. Memorija se alocira u "chunkovima", slično prostoru na disku. Vrlo malo kompajlera zna to optimirati, tj napraviti subalokaciju više varijabli u jednom kontinualnom chunku, a da ne kažem napraviti kvalitetan reuse. Kad to sve dealociraš po izlasku iz potprograma, nastane ti hrpa malih fragmenata koje janitor/garbage collector vrlo teško konsolidira u jedan veći contiguous block, ako uopće može. Glupi programčić od par stotina bajta koji samo alocira i dealocira memoriju (bez leaka) može vam bukvalno uništiti raspoloživu memoriju. Uvođenjem multicore/multi procesorskog sustava plus "predictive queinga" se stvar dodatno komplicira, ali tu više nisam doma.

Prostor se po pravilu ne prealocira, to i jeste smisao dinamičkog alociranja memorije za funkcije. Stoga imate problem da vam se može desiti da vam program radi 99,9% vremena, ali kad pozovete jednom od 1.000 puta jednu funkciju, dobijete puf!

No ovo ionako nisu početnička pitanja, stoga, kao što rekoh, nije ni bitno.

[capttawish]

sali kaže:

nije samo prealokacija, spremanje registara i kreiranje okruženja nove funkcije troši cikluse, za neke česte i jednostavne funkcije u C postoje makroi koji rade in-line, npr za string operacije, bez poziva funkcije, naravno header fajl na kraju odredi hoće li se makro dekomponirati u preprocesoru kao funkcija ili in-line kod

Jel tebi jasno što znači riječ alokacija memorije?

ruka-slave kaže:

Z
Glede alokacije memorije. Ljudi općenito nisu svjesni koliko alokacija i dealokacija memorije troši resursa. Svaka lokalna varijabla koju alocirate u funkciji/potprogramu, svaki parametar koji proslijedite bilo kao pointer bilo kao varijablu, troši resurse. Da stvar bude gora, to je mem2mem transfer, koji je puno sporiji nego mem2reg ili ne daj bože reg2reg.

Uzmi projekt od 100k+ linija koda pa onda ti lijepo to ručno optimiziraj i govori kako je kompajler glup. Ili, hajdemo sav kod inlineati, dobit ćemo automatski 10x ubrzanje, a tebi možemo odmah dodijeliti Turingovu nagradu.

Da, funkcije, kao i svi ostali konstrukti u programiranju, uvode određeni overhead, ali ih prihvaćamo zato što omogućuju da nešto zapravo i napravio. Nismo u začecima da moramo paziti na svaki bajt, i svaki ciklus procesora, sad su stvari puno drugačije. Bez funkcija ne bi bilo modernog računarstva jer uopće ništa ne bi mogao reusati.

Neki programski jezici uvode više, a neki manje overheada u svoje konstrukte. Tvoj način razmišljanja (o tome koliki ti je overhead kod samog poziva funkcija) uopće nije primjenjiv na C# i Javu kad kod njih uopće ne radiš direktno s memorijom, i imaš još jedan korak između programskog i strojnog koda (npr. bytecode kod Jave), tako da ne znam kako ti to znanje što si naveo pomaže. Kad bi tako razmišljali u njima, oni uopće ne bi postojali.

[ruka-slave]

ruka-slave kaže: Pogledaj post

Glede alokacije memorije. Ljudi općenito nisu svjesni koliko alokacija i dealokacija memorije troši resursa. Svaka lokalna varijabla koju alocirate u funkciji/potprogramu, svaki parametar koji proslijedite bilo kao pointer bilo kao varijablu, troši resurse. Da stvar bude gora, to je mem2mem transfer, koji je puno sporiji nego mem2reg ili ne daj bože reg2reg.

capttawish kaže:

Uzmi projekt od 100k+ linija koda pa onda ti lijepo to ručno optimiziraj i govori kako je kompajler glup. Ili, hajdemo sav kod inlineati, dobit ćemo automatski 10x ubrzanje, a tebi možemo odmah dodijeliti Turingovu nagradu.

Nisam uzimao samo 100k+ linija koda, nego i par milijuna. I to se ne radi tako, a sigurno ne tako da sav kod "inlineaš", to je suludo. Jesam pisao dosta inline koda (heksa i asm) za pojedine najkritičnije funkcije, pogotovu ako se radi o periferiji. Ali to tek nakon što sam izolirao najkritičnije funkcije u normalnom kodu, zapravo vrlo formalno napisanom. Sam inline kod ne čini više od 1 promila teksta/bin koda, i obično se izbaci u poseban library.

A izolirao sam ih tako da sam prvo napisao hrpu koda koja kako-tako radi posao; dakle efektivno RAD.

Onda sam taj kod maksimalno uredio i odijelio u funkcije, pa maker se pozivale samo jednom; postigao da sve radi stabilno i po specifikaciji. To je inače jako problematično jer ti se počnu javljati problemi s memorijom, brzinom, diskovnim prostorom, timeoutom zbog predugačkog čekanja na povrat rezultata, pa sve do problema sa bugovitim kompajlerom i linkerom, librarijima, samim OSom...

Kad bih to sredio, onda bih sjeo na profiler i počeo gledati kako to stvarno radi, i koliko koja funkcija koristi koje memorije, koji kod se najviše koristi pa bi imalo smisla ga optimirati, koja funkcija nema smisla ako se pojavljuje samo jednom itd itd. To je generalno faza u kojoj uvodiš inline kod u najkritičnije dijelove. Korekcije koda postaju progresivno sve teže.

Tek kad to središ onda ideš na finalnu kompilaciju, u kojoj uklanjaš symbol table, range i type check, ideš na prljavije trikove i sl. što će sve dalje ubrzati rad i reducirati memorijski footprint, ali i vrlo značajno progresivno otežati kasnije korekcije u kodu.

Da, funkcije, kao i svi ostali konstrukti u programiranju, uvode određeni overhead, ali ih prihvaćamo zato što omogućuju da nešto zapravo i napravio. Nismo u začecima da moramo paziti na svaki bajt, i svaki ciklus procesora, sad su stvari puno drugačije. Bez funkcija ne bi bilo modernog računarstva jer uopće ništa ne bi mogao reusati.

Pa to sam i ja rekao.

Neki programski jezici uvode više, a neki manje overheada u svoje konstrukte. Tvoj način razmišljanja (o tome koliki ti je overhead kod samog poziva funkcija) uopće nije primjenjiv na C# i Javu kad kod njih uopće ne radiš direktno s memorijom, i imaš još jedan korak između programskog i strojnog koda (npr. bytecode kod Jave), tako da ne znam kako ti to znanje što si naveo pomaže. Kad bi tako razmišljali u njima, oni uopće ne bi postojali.

Nije poanta u tome, niti sam ja to rekao.

Svaki jezik uvodi određenu razinu apstrakcije. I asembler je razina apstrakcije u odnosu na binarni kod, pogotovu makro. Fortran primjerice je vrlo sličan asembleru, ali je već sljedeća razina apstrakcije.

Svi moderniji jezici su još apstraktniji, i udaljavaju te od razmišljanja o hardveru ili čak OSu na kojem se izvršavaju, kao npr Java. Ispod koda se nalazi niz layera koji prilagođavaju izvršenje koda konkretnom stroju na kojem se isti izvršava.

To nije nikakva novost, to je radio još Lisp 1960-te.

Možeš koristit i više različiih strojeva i OSa koji su umreženi i smješteni na različitim stranama svijeta, i čak ne znati u čemu je pisan library čije funkcije pozivaš.

Svaki je jezik, ugrubo, prilagođen određenoj platformi i razini apstrakcije. Pisanje koda u asembleru, pa makar i samo prepisivanje iz višeg prog.jezika, za nešto što je prilagođeno u npr.C++, pa i običnog C , stvar je čistog mazohizma, a pogotovu ako radiš reuse (a uvijek ga radiš). To čak i nije toliko teško, imaš masu kompajlera npr. Ca koji ti izbace umjesto binarnog koda neki asemblerski, pa ga možeš editirati do mile volje. Ali onda zaboravi profiler na višoj razini.

Programiranje u višim razinama apstrakcije je trade-off vremena utrošenog na pisanje koda, tj algoritma i vremena potrošenog na prilagođavanje algoritma specifičnim fizičkim ograničenjima. Svjesno žrtvuješ fizičke računalne resurse zato da bi dobio na brzini razvoja, jasnoći koda, lakoći korekcije grešaka, resuabilitiju, multiplatformnosti...

Poanta je koliko si kao koder, programer, dizajner ili projektant svjestan tih ograničenja kad pišeš u višem jeziku. Sintaktičke razlike relativno lako savladaš, ali razlika u razmišljanju je često nepremostiva. Stoga dobiješ tipičan bloatware.

[Zmijonosac]

I sto onda predlazete pocetnicima? Voditi racuna o optimizaciji prilikom pisanja koda ili nakon pisanja naci usko grlo i samo taj dio optimizirati?

[capttawish]

Zmijonosac kaže:

I sto onda predlazete pocetnicima? Voditi racuna o optimizaciji prilikom pisanja koda ili nakon pisanja naci usko grlo i samo taj dio optimizirati?

Moraš voditi računa o performansma kad pišeš program, ali ne na ovaj gore način. To su puno specifičnije stvari, kad tražiš bottleneck ili hot path pa se onda spuštaš na nižu razinu i optimiziraš.

Talk koji je malo napredniji, ali po meni dobro opisuje kako pristupiti tome: https://www.youtube.com/watch?v=fHNmRkzxHWs

[JohnWick7774]

Kakvo je vaše mišljenje o upisu programa Python developer na Algebri ?

[judolino]

JohnWick7774 kaže:

Kakvo je vaše mišljenje o upisu programa Python developer na Algebri ?

Python možeš učiti i na drugim mjestima.
Algebri nije cilj da te nauči, nego da ti uruči uvjerenje da si prošao, pa da na temelju toga i dalje zarađuje lovu.
E sad: ako ti ne ide samostalno učenje uz poduku iz raznih knjiga, internetskih tečajeva i tako to, Algebra će ti uistinu pomoći da kreneš, pružit će ti materijale i osnovu za dalje - no dalje je na tebi.
A papir iz Algebre za Python developera je za guzicu obrisat, sumnjam da je to vrijedno truda.
Pazi: firme traže ljude koji znaju programirati, a ne ljude koji su svladali sintaksu nekog programskog jezika.
Radije si pogledaj na Gugletu CS50P, a vaučer sačuvaj za nešto bolje.
Sretno, prijatelju!

[JohnWick7774]

judolino kaže:

Python možeš učiti i na drugim mjestima.
Algebri nije cilj da te nauči, nego da ti uruči uvjerenje da si prošao, pa da na temelju toga i dalje zarađuje lovu.
E sad: ako ti ne ide samostalno učenje uz poduku iz raznih knjiga, internetskih tečajeva i tako to, Algebra će ti uistinu pomoći da kreneš, pružit će ti materijale i osnovu za dalje - no dalje je na tebi.
A papir iz Algebre za Python developera je za guzicu obrisat, sumnjam da je to vrijedno truda.
Pazi: firme traže ljude koji znaju programirati, a ne ljude koji su svladali sintaksu nekog programskog jezika.
Radije si pogledaj na Gugletu CS50P, a vaučer sačuvaj za nešto bolje.
Sretno, prijatelju!

Hvala na lijepim željama

[UrchinStar47]

Također pogledaj dokumentaciju na sajtu Pythona, imaju dosta materijala uključujući i solidne tutoriale.

[JohnWick7774]

UrchinStar47 kaže:

Također pogledaj dokumentaciju na sajtu Pythona, imaju dosta materijala uključujući i solidne tutoriale.

Budem pogledao

[GregogSamsaa]

želja mi je programirat software (aplikacije).
U moru tutoriala, ne znam kuda niti s čime počet.

Kao tabula rasa, želim naučit low level pa si sam "isprogramirati" što mi je potrebno. Pošto nemam pojma koliko je mukotrpno isprogramirati? library, eto čak i to bih volio znat, jer ovo danas je sve high level i čovjek defacto uči napamet tuđe metode.

oću li počet učiti assembly?
ili da počnem C u usranom VS (postoji li alternativa za to sranje? )

želim počet od temelja

nadam se da razumijete moje zbrčkano pitanje, hvala

[sali]

GregogSamsaa kaže:

želja mi je programirat software (aplikacije).
U moru tutoriala, ne znam kuda niti s čime počet.

Kao tabula rasa, želim naučit low level pa si sam "isprogramirati" što mi je potrebno. Pošto nemam pojma koliko je mukotrpno isprogramirati? library, eto čak i to bih volio znat, jer ovo danas je sve high level i čovjek defacto uči napamet tuđe metode.

oću li počet učiti assembly?
ili da počnem C u usranom VS (postoji li alternativa za to sranje? )

želim počet od temelja

nadam se da razumijete moje zbrčkano pitanje, hvala

tvoj tekst sadrži elemente provokacije, prvo napravi neku kakvu takvu aplikaciju u VS visual-basic, pa kad to riješiš, razmišljaj o narednom koraku, biće ti jasnije ...
sa basicom možeš sve raditi od nule ako hoćeš, a okruženje je prijateljsko

[GregogSamsaa]

sali kaže:

tvoj tekst sadrži elemente provokacije, prvo napravi neku kakvu takvu aplikaciju u VS visual-basic, pa kad to riješiš, razmišljaj o narednom koraku, biće ti jasnije ...
sa basicom možeš sve raditi od nule ako hoćeš, a okruženje je prijateljsko

VS je "mastan" treba mu pola sata da se upali, ali, hvala na odgovoru

[UrchinStar47]

GregogSamsaa kaže:

ili da počnem C u usranom VS (postoji li alternativa za to sranje? )

C se može pisati doslovno u bilo kojem editoru teksta, uključujući i notepad, notepad++ ili, u zemlji UNIX-oida nano, vi, vim, GNU Emacs, itd.

Puno ranog programiranja u C-u je rađeno u ed-u, na teleprinterima sa papirnatim ispisom.

Tako da ti VS tu nikako nije potreban.