Uvod

Za početak malo objašnjenje mojih akcija odnosno teme ovog članka. Cijela je priča počela jučerašnjim e-mailom u kojem me moj dragi urednik zamolio da odgovorim na e-mail jednog čitatelja i objasnim mu ovisnost između takta i dužine pipelinea procesora. Budući da sam jučer trebao napisati recenziju Logitechovih Z-3 zvučnika, odgovaranje na čitateljev e-mail je moralo pričekati. No sudbina (ali i moj kronični manjak koncentracije) me odvela u sasvim drugom smjeru. Taman kad sam se spremao navaliti na tekst o zvučnicima palo mi je na pamet pogledati što ima novog na našem forumu, kad tamo - moj znatiželjni čitatelj pokušava saznati što ga zanima alternativnim metodama. Budući da sam sa tugom u očima osvjedočio pokušaje kolega forumaša da temu ovog članka objasne pomoću jedne složene rečenice sa uporabom termina kao što je "šlauf", nije mi preostalo ništa drugo nego napisati ovaj ishitreni članak.

Bez daljnjeg filozofiranja "zagrizimo" u temu.

Pipeline = proizvodna traka

Svaki moderni procesor (onaj koji radi na principu pipelinea) obrađuje informacije na principu tvorničke proizvodne trake. Ako razdijelimo ovu "proizvodnu traku" na osnovne dijelove, operacije koje procesor izvodi pri obradi informacija možemo podijeliti na četiri stupnja, a te stupnjeve nazvati "Fetch", "Decode", "Execute" i "Write".

"Fetch" - dohvaća instrukciju iz cache memorije ili RAM-a

"Decode" - dekodira instrukciju (prevodi instrukciju u oblik razumljiv "Executeu")

"Execute" - izvršava dekodiranu instrukciju

"Write" - vraća rezultat operacije natrag u cache memoriju

Dakle imamo četiri osnovna koraka pri obradi informacija. Neki od ovih koraka se dijele na još manje korake, a zbroj svih koraka predstavlja dužinu pipelinea.

Vratimo se sad na princip proizvodne trake:

Recimo da se u cacheu procesora nalaze četiri instrukcije koje treba obraditi. Procesor ih, analogno proizvodnoj traci, u idealnim uvjetima obrađuje na slijedeći način:

1. "Fetch" dohvaća instrukciju no. 1 iz cachea. "Decode", "Execute" i "Write" ne rade ništa budući da još nisu dobile podatke od "Fetcha".

2. "Fetch" šalje instrukciju no. 1 na "Decode" i dohvaća instrukciju no. 2. "Decode" dekodira instrukciju no. 1. "Execute" i "Write" se dosađuju.

3. "Decode" šalje dekodiranu instrukciju no. 1 na "Execute" i počinje obrađivati instrukciju no. 2 koju je dobio od "Fetcha". "Fetch", shodno tome, dohvaća instrukciju no. 3. "Execute" obrađuje instrukciju no. 1. "Write" i dalje stoji.

4. "Write" napokon ima materijala za rad - dobija rezultat instrukcije no. 1 i zapisuje ga natrag u cache memoriju. "Execute" obrađuje instrukciju no. 2. "Decode" obrađuje instrukciju no. 3 dok "Fetch" dohvaća zadnju instrukciju, instrukciju no. 4. Cijeli se ciklus odvija dok se ne obrade sve instrukcije, odnosno dok se rezultat operacije koju je inicijirala instrukcija no. 4 ne zapiše u cache memoriju.

Kao što vidimo, u određenoj jedinici vremena svaki od ovih osnovnih dijelova pipelinea odrađuju svoj dio posla pa cijeli pipeline u određenoj jedinici vremena može obraditi jednu instrukciju. Da navedeni dijelovi pipelinea nisu povezani, za obradu svake instrukcije bi trebalo potrošiti četiri puta više vremena budući da tijekom aktivnog stanja jedne jedinice (misli se na "Fetch, "Decode"...) ostale jedinice ne bi imale što raditi.

Lako je zamijetiti da efikasnost ovog cijelog jednostavnog pipelinea ovisi o tome da li će svaki njegov dio odraditi svoj dio posla u jednakom vremenu. Ako bilo koji dio kasni, kasni i cijeli pipeline. Ako logički sagledamo naš jednostavni pipeline, jasno je da su dekodiranje i obrada dekodiranih instrukcija (dakle "Decode" i "Execute") imaju mnogo kompleksniju zadaću od "Fetcha" i "Write" pa zato "usporavaju" cijeli proces. Nakon što smo ovo konstaturali u cijelu shemu valja uvesti takt.

Ono što sam na prethodnoj stranici naveo kao "određenu jedinicu vremena" je zapravo ekvivalencija jednog otkucaja generatora takta procesora. Ako on kuca na 1 megaherc, naš će jednostavni pipeline obrađivati milijun instrukcija po sekundi. Ako procesor ima takt od 700 MHz, obrađivat će 700 milijuna instrukcija po sekundi. Naravno, ove brojke vrijede ako svaki dio pipelinea može odraditi svoj posao u jednom otkucaju generatora takta.

Na početku sam spomenuo da se neki (kompleksniji) dijelovi našeg osnovnog četverostupanjskog pipelinea dijele na više dijelova. Zašto? Zato što je kompleksnijim dijelovima pipelinea potrebno više vremena da odrade svoj posao. Ako npr. "Executeu" treba tri, "Decodeu" dva, a "Fetchu" i "Write" jedan otkucaj da obave svoj dio posla, jasno je da će brzina obrade informacija ovisiti o brzini nakomplesnijeg dijela pipelinea - u ovom slučaju "Executea". Rješenje problema je da se "Execute" i "Decode" razlome na više dijelova kojima je potreban samo jedan otkucaj da odrade svoj posao.

Sad smo iz četverostupanjskog pipelinea prešli u sedmerostupanjski pipeline u kojem svaki stupanj obrađuje svoj dio posla u jednom otkucaju. Ako ga usporedimo sa našim idealnim četverostupanjskim pipelineom (to je onaj s početka teksta čiji svaki stupanj "magično" obrađuje informacije u jednom taktu), sedmerostupanjski pipeline treba viši takt da bi obrađivao jednaku količinu informacija u jednakom vremenu.

Primjer:

Ako oba pipelinea rade na taktu od 4 Hz kraći pipeline u pri svakom otkucaju (nakon inicijalnog "punjenja" pipelinea sa instrukcijama) stigne obraditi jednu instrukciju. Duži pipeline zbog dužeg "punjenja" tijekom istog vremena ne stigne obraditi niti jednu intrukciju već mu za ovakav pothvat trebaju tri dodatna otkucaja generatora takta. Ako povećamo takt na 8 Hz, dugi pipeline stigne obraditi jednu instrukciju, ali kraći pipeline u istom vremenu stigne "srediti" dvije instrukcije.

Naravno, ako uzmemo u obzir kontinuiranu obradi podataka, dalo bi se zaključiti da ako zanemarimo period "punjenja" oba pipelinea jednako brzo obrađuju informacije no to nije točno. U cijeli proces moramo uključiti i mogućnost greški pri obradi informacija koje zahtijevaju da se jedan dio ili čak cijeli pipeline isprazni i ponovo napuni. U ovakvim realnim uvjetima kraći pipeline je i brži pipeline.

Ovakav bi vas primjer mogao navesti da zaključite da je pipeline pod svaku cijenu mora biti što kraći, ali to nije točno. Jedan od najvećih problema pri dizajniranju procesora je kako i na koliko dijelova razdijeliti onaj osnovni, idealni četverostupanjski pipeline. U idealnom ga slučaju želimo "razlomiti" tako da svaki pojedini stupanj ne usporava ostale stupnjeve. Logično, ovo je puno lakše napraviti ako si možemo priuštiti visoki takt procesora (koji je u velikoj mjeri ograničen kvalitetom i veličinom proizvodnog procesa - 130 nm, 90 nm i slično). S druge strane sa "lomljenjem" pipelinea na mnogo dijelova izlažemo se problemu anuliranja greški pri obradi informacija. Kada se greška dogodi (što je nije iznimka već pravilo) pipeline valja djelomično ili potpuno isprazniti. Ovdje na vidjelo izlazi jedna od prednosti kratkog pipelinea - lakše ga je napuniti i isprazniti budući da mu je za to potreban niži takt.

Premda je kratki pipeline zahvalniji što se tiče "punjenja" i ovisnosti o taktu, teže ga je implementirati s obzirom na finalni cilj održavanja jednake efikasnosti svakog stupnja pipelinea. Samim tim što je pipeline kraći svaki stupanj pipelinea je kompleksniji.

Zaključak

Zbog navedenih principa funkcioniranja procesora, AMD-ovi Athloni imaju kraći pipeline i niži radni takt u odnosu na Intelove Pentiume 4 koji imaju duži pipeline i viši radni takt. Sad se sigurno pitate zašto AMD, budući da korisiti 90-nanometarski proces izrade procesora kao i Intel, ne može napraviti procesore sa relativno kratkim pipelinom (npr. dužinom pipelinea procesora Athlon 64) koji rade na jednakom taktu ekvivalentnih modela Intelovih Pentiuma 4 (odnosno procesora sa dugim pipelineom). Problem je u tome što je kraći pipeline, zbog kompleksnosti pojedinih stupnjeva, osjetljiviji na povećavanje radne frekvencije nego dugi pipeline sa jednostavnim stupnjevima.