1. i Atari Falcon na 16MHz + DSP (procesori sa kraja 80tih) moze da pusta MP3 😉 (wow - koji argument :d)
Ne vidim cemu izrugivanje i *******cija.
genuine je rekao kako ARM7TDMI-S na 60MHz moze da pusta mp3. Ja sam samo konstatovao da ARM7TDMI-S moze samo to, a da je Pentium MMX terao citav OS sa GUI-jem, mrezom, itd.
2. zasto je x86 los po defaultu? zar nije losije ako moras da rasturas x86 na mikroinstrukcije... zar to nije visak, taj korak raasturanja x86>mikroinstrukcije?
Svaki procesor to radi u manjem ili vecem obimu. Sustina je u tome da ako imas dobar dekoder (pa jos vise njih) na jeftinom silicijumu u 45nm to moze da bude bolje i jeftinije od RISC-a. Da ne ulazimo sada u detaljnu raspravu RISC .vs. CISC, navescu samo par primera.
Ja sam dosta imao kontakta sa MC68k asemblerom u vreme Amige, i smatram da je CISC mnogo laksi za developere jer se skoro svaka komanda mapira na odgovarajucu instrukciju u hardveru. Zasto je to dobro? Evo podjimo od jednostavnog primera koda:
Kod:
typedef struct {
float x;
float y;
float z;
float w;
} Vec3D;
float dp(Vec3D &a, Vec3D &b)
{
return a.x*b.x + a.y * b.y + a.z * b.z + a.w * b.w;
}
Ovaj jednostavan kod za skalarni proizvod (dot product) generise sledeci masinski kod (Intel kompajler /O3 /Qax...):
Kod:
mov eax, DWORD PTR [esp+4]
mov edx, DWORD PTR [esp+8]
fld DWORD PTR [eax]
fmul DWORD PTR [edx]
fld DWORD PTR [eax+4]
fmul DWORD PTR [edx+4]
faddp st(1), st
fld DWORD PTR [eax+8]
fmul DWORD PTR [edx+8]
faddp st(1), st
fld DWORD PTR [eax+12]
fmul DWORD PTR [edx+12]
faddp st(1), st
ret
14 instrukcija ili 37 bajtova koda za nesto sto programer dozivljava kao jedinstvenu, relativno cestu operaciju. Hajde sada da promenimo taj kod malo:
Kod:
#include <smmintrin.h>
typedef struct {
float x;
float y;
float z;
float w;
} Vec3D;
float dp(Vec3D &a, Vec3D &b)
{
return _mm_cvtss_f32(_mm_dp_ps(_mm_load_ps((float*)&a), _mm_load_ps((float*)&b), 0xF1));
}
Sta sada dobijamo u asembleru (Intel kompajler, /O3 /QxS za SSE4.1)?
Kod:
sub esp, 8
mov eax, DWORD PTR [esp+12]
mov edx, DWORD PTR [esp+16]
movaps xmm0, XMMWORD PTR [eax]
dpps xmm0, XMMWORD PTR [edx], 241
movss DWORD PTR [esp], xmm0
fld DWORD PTR [esp]
add esp, 8
ret
9 instrukcija, od toga 4 protracene zato sto se kreira privremena varijabla na steku preko koje se presipa rezultat iz SIMD registra na FP stack (limitacija ABI-ja i calling konvencije, a ne kompajlera), i 32 bajta koda (14 otpada na te 4 instrukcije "viska").
I pored tog "viska" (koji se moze izbeci!) i kompleksne instrukcije (DPPS, 6 bajtova enkoding) imamo ~15% ustede u memorijskom prostoru.
Ako analiziramo to dalje, videcemo da u prvom slucaju imamo prosecno 2.64 bajta po instrukciji, dok u drugom slucaju imamo 3.55 bajtova po instrukciji. Znaci, moralo bi losije da radi zar ne?
E, sad dolazimo do zanimljivog dela, ova druga sekvenca se moze svesti na 3 instrukcije u najboljem slucaju, dok se prva moze svesti na 12 instrukcija ukoliko se koriste fiksne adrese za rezultat i za vektore umesto referenci ili pointera. Medjutim, okreni-obrni
brziniski rezultat je sledeci:
CISC (SSE4.1) : 3 takta za jedan skalarni proizvod
"RISC" (FPU) : 8 taktova za istu stvar
Sad cete reci da ARM moze da emulira SIMD. Mozda moze da se napravi preko VHDL identicna instrukcija. Mozda cak moze da se izvrsi za 1 takt -- evo nek' je ARM na 200Mhz to je opet 5ns, dok je 3 takta na 1GHz Penryn jezgru svega 3ns. Znaci, brze je i jeftinije raditi CISC i dekodirati kompleksne instrukcije koje pritom omogucavaju siru i jednostavniju primenu.
a zasto je x86 losiji procitaj od Dareka Mihocke...
Smorio sam se (tj smorio me je) na petoj strani.
Ukratko, neki od njegovih stavova su ispravni, medjutim zapeo je sa tim segmentima i ofsetima kao da je to ne znam kako dobar izum (meni licno se gadio).
Ne osporavam njegovo (ocigledno veliko) znanje, ali u pogledu bezbednosti i virtualizacije se sa njim ne slazem uopste.
Dalje, jasno je da VT i Pacifica trenutno imaju lose performanse, ali to nije slabost koncepta hypervisora, vec slabost tekuce hardverske implementacije i to moze samo da se poboljsa u buducnosti. Da bi se uocile slabosti u realnom radu, mora da se ima veliki i raznorodan uzorak, a to sto su svi implementirali hardversku virtualizaciju u svoj softver upravo to i omogucava. Ne kazem da nije moglo bolje, ali od neceg se moralo poceti.
3. ARM je i nastao zato sto ljudi iz Acorna nisu bili zadovoljni sa MC68K i x86 i napravili chip i ISA od 0 sa ciljem da bude bolji od ova dva navedena!
Od MC68K meni nema boljeg cipa!
😀
