What Happens When Apple Passes Microsoft In Value? Yes, When.

Ne mozes da tuzis Canonical npr za FOSS Ubuntu, ali ne mozes ni Microsoft za windows/office. Kad bi svako ko je iskusio BSoD mogao da tuzi MS za to gde bi tuziteljima bio kraj Cak iako imas neke zakonske garancije ceka te neizvesan sudki postupak za koji imas male sanse da dobijes.

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Još jedna poteškoća na koju je Ivan ukazao, ali nedovoljno jasno, je da za jedan takt na frekvenciji od 4GHz svetlost pređe samo 7,5cm.



Šta ćeš, svaki dan se ponešto nauči. Da, ako platiš garanciju, neko će snositi odgovornost za predmet garancije. Potpuno je nebitno što se sam kod distribuira besplatno. Garancija nikada nije besplatna.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Pogledajte chartove... ovo je bubble ljudi.. sta vam je :)

Svaki hype ima svoj kraj... mada je lepo dok traje.

Vi stvarno hoćete da se ekipa sa teme o TR pridruži i ovde? :-D

Potpis

"Ima jedna vračarija za taj strav od vampiri. Kad se nekoj mlogo plaši, ja mu malko prebajem. Uznem jedno perce od crnu kokošku, jednu rženu slamku i malko bosiljak. Toj držim u ruku, a taj čovek što ga strav, on se krsti a ja bajem: "Otud ide crna kvačka, vodi crni piliki, dovede gi na crno bunjište, tuj čeprljaše i raščeprljaše, s kljunice iskljucaše, i raznesoše i odletoše."

Brzina prostiranja informacija je tek jedan od X fizickih ogranicavajucih faktora.

Cak i tih 7.5cm su vise nego dovoljni u svetu gde se velicina tranzistora izrazava u nm.

Danas se max frekvencija odredjuje sumiranjem kasnjenja logickih kola duz kriticne putanje na najslozenijoj sekciji pipeline-a. Ta putanja je svakako dosta kraca od 7.5cm. Parazitne kapacitivnosti i induktivnosti su ono sto predstavlja pravi inzenjerski izazov u realizaciji, koji zaista usporava CPU.. no to je sve nebitno za prichu o finansijskom uspehu Apple vs MSFT.

Entuzijazam koji Steave Jobs ima nije ni prvi ni poslednji hype u IT industriji. Svi se oni manifestuju na isti nachin: u prvoj fazi postoji izuzetan (ne retko eksponencijalan) rast vrednosti akcija, nakon cega sledi lom u momentu gde se prenaduvani hype (preterane investicije) susretnu sa realnoscu (potraznjom). Desavalo se X puta.. pogledajte istoriju bilo kog IT giganta. Tu ne treba kriviti Jobs-ovu pozitivnu energiju. Covek radi ono sto dobar CEO i treba da radi, bodri ljude oko sebe i uliva nadu u uspeh. Ako uz to sledi rad i adekvatna organizacija ne postoji razlog da se uspeh i realizuje.

Sam Jobs kaze da glavna zamerka Microsoftu - nisu ni tehnicka resenja, ni uspeh ("uspeh je MSFT najvecim delom zasluzio" -- Jobs). Ono sto mu zamera je nedostatak stila. I to je svakako ono po cemu se Appleovi proizvodi razlikuju. Neko je tu ocigledno vodio racuna da proizvodi iz potrosackog ugla imaju ukusa. Imati Mac danas, pre svega predstavlja izraz stila, pa tek onda odraz tehnoloske potrebe. I cene su naravno u skladu sa time.

Softverska baza koju ima Apple ne moze se porediti sa MS ekosistemom. Postoje izgledi da ce se to promeniti, posto je npr. najveci rast tiraza O'Reilly-jevih knjiga upravo iz "Objective C" tematike. Takodje Tiobe indexi pokazuju dramatican rast popularnosti ObjC-a, tj. dostupnosti ObjC source-a na netu. Novo trziste za Apple se stvara, ali to je ipak pre 'fashion statement', koji se ne moze uporediti sa egzistencijalnom zavisnoscu small/medium buissnes kompanija od MS-a.

Pre ili kasnije trziste ce brutalno svesti stvari na pravu meru, masovna psihoza (hype) ce splasnuti i cene ce postati odraz realnih potreba - kao sto i treba da bude..

Pa, ja sam jedan od učesnika te teme ;-)

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Hm, i Apple će se držati x86 do daljeg, tako da...
Poboljšanja u izvođenju x86, kao i forsiranje radnog takta i igra "na mišiće" svakako će održati x86 još... pa, videćemo koliko.

---

BTW, otkud vam to da je Balmer CEO? Nije taj baš ČITAV!

Intel je jos od 2005-te prestao da gura takt "na misice".

Vec 4 generacije procesora (Conroe -> Penryn -> Nehalem -> Westmere) nisu dozivele nikakvo dizanje takta, cak su svi oni na nizem taktu od nekadasnjih NetBurst baziranih procesora.

Njihova strategija je uvecavanje broja jezgara na istoj povrsini sa svakim smanjenjem procesa izrade. Inzenjerski zahtevi su vrlo strogi i ne sme se prebaciti zadati TDP limit i svaki novi feature mora ostati unutar TDP granice. TDP od 130W je vec 5 godina gornji limit.

Tako danas vec imamo consumer CPU-ove sa 6 jezgara (Core i7 980), koji staju na istu povrsinu kao nekadasnji dual-core procesori. To ce se nastaviti i dalje, sve dok je moguce smanjivati proces.

Takodje, usavrsavanjem arhitekture vec duze vreme povecavaju IPC - tako da jedan Nehalem zavrsava zadatke 15-tak% brze od Penryn-a na istom taktu. Gore pomenuti i7 980 je primer koliko im dobro ide - 6 jezgara umesto 4, a clock-for-clock 15% brzi od Penryn arhitekture - a isti TDP od 130W koji vam je u Penryn vreme davao 4-jezgra. Primetiti da su frekvencije ostale iste.

Sve u svemu - jos od Pentium M generacije i bacanjem NetBurst-a u zasluzeno djubre, Intel i te kako zna sta radi, i ima tehnologiju koja je prilicno ispred konkurencije.

Sledecu generaciju, Sandy Bridge radi izraelski tim koji je bio zaduzen za Conroe (kao i za Pentium M i prvu "Core" generaciju - Yonah) - tako da se moze ocekivati jos jedan poveci skok u performansama po vatu. Ta ekipa vraski dobro zna svoj posao.

Potpis

DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos: http://www.digicortex.net/node/17 Gallery: http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! - https://github.com/psyq321/PowerMonkey

^To sam nazvao "na mišiće"
E, sad, optimizacija izvršavanja x86 instrukcija - to je zanimljiva tematika. Kakav je "manevarski prostor" za dalje unapređenje i koliko se to "cimanje" isplati u odnosu na prethodne dve stavke koje daju dobitak na performansama.
Unapređenje mikrokoda (može li to uopšte?) Poboljšanje predikcije itd.
(Nije Advocacy baš za edukaciju, ali može da posluži ).

Izgleda da ciljaju za Sandy Bridge poboljsanje FPU performansi kroz neke njihove - e sad da me ubijes ne mogu da se setim, vektorske bla bla, cek... Advanced Vector Extensions (AVX) yep...

/edit: + TDP od 65W za dual core i 85W za quad core + sto ce imati Hyperthreading, AES-NI takodje (kao na i5), ali ja najvece poboljsanje ocekujem kod njihovog IGP-a, bice u istom proizvodnom procesu kao i CPU (32nm) i delice kesh sa CPU-om. Samo me planovi za chipset razocaravaju, nista posebno, nit USB3 cak ni SATA3 nece biti na svim chipsetovima - pfff. Release se ocekuje krajem godine, ne znam kome bi se sada isplatila kupovina ploca na 1156 socketu kada ce ovaj za sandy imati jedan manje i zadrzace se dosta duze na trzistu.

Potpis

make love - !war

@maksvel,

Pa ocigledno im dobro ide - jer svaka "Tock" generacija (promena arhitekture) donosi osetljivo veci IPC - Conroe je "clock for clock" bio prilicno brzi od NetBurst-a, isto kao sto je Nehalem bio prilicno brzi od Penryn/Conroe generacije.

Same x86 instrukcije su "makro" instrukcije za CPU, tako da se moze upotrebiti dosta pametnih trikova da se one brze izvrsavaju.

@combuster - yep, AVX ce jos vise ubrzati floating point operacije nad vektorima/matricama u poredjenju sa SSEx instrukcijama.

Ono sto zeza Intel je sto nacin na koji se danas povecavaju performanse (ako izuzmemo IPC povecavanja koja ne donose vise od max. 15-20% ubrzanja) zahteva aplikacije koje su optimizovane za multi-core / multi threaded izvrsavanje. Pitanje je koliko vidnog ubrzanja mozete imati na necemu sto nisu igrice, AV editing/encoding i 3D modelovanje...

Windows, Linux i Mac OS X su radili jako lepo i na Conroe procesorima. Jedan matori Q6600 iz 2006 je i dan danas u stanju da se nosi sa najnovijim OS-evima. Dolazak SSD-ova je pokazao da su I/O performanse bile DALEKO kriticnije za subjektivni osecaj brzine od CPU-a.

Za prosecnu desktop upotrebu, jedan i7 980x sa 6 jezgara i izvrsenjem 12 niti odjednom, IPC-om koji je bar 15% veci od pomenutog Q6600 ne donosi ama bas nista vidno bolje... to je prilican problem.

Potpis

DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos: http://www.digicortex.net/node/17 Gallery: http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! - https://github.com/psyq321/PowerMonkey

Pa uvek gledas da prosiris bottleneck ako je to ikako moguce, SSD-ovi tu pomazu nenormalno. Jedinu prednost SATA3 cemo videti preko novije neke generacije SSD diskova. A sto se CPU-a tice, evo ja i dan danas na Linuxu ne vidim neki boljitak od ovog mog C2D osim kada kompajliram nesto (sto vrlo cesto radim btw pa bi mi lepo legao neki i3 sa HT-om ali cu sacekati Sandy definitivno), inace gomila aplikacija nije SMP optimizovana... A i videcemo sta ce biti posto sam nacuo da je Intel poceo zesce da se uvlaci u razvoj GCC-a, vrlo moguce da ce u skorije vreme vecina Linux aplikacija biti "nastimovana" za Intel CPU-ove. U stvari, makar cu ja moci da ih optimizujem preko CFLAG-ova.

Potpis

make love - !war

Eto zasićenja, slično kao s početka teme što se pisalo vezano za Windows.

Ima li 'leba da otvori svoj Linux compiler??

Pa i to sa SATA3 je pitanje...

Sa cime ces da opteretis desktop sistem pa da ti treba 600 MB/s ?

Evo ja imam 4 uvezana SSD-a u RAID0 na laptopu, i jos X25-E pride "da se nadje" kad treba mnogo IOPS-a ... iskreno, razlika u radu u poredjenju sa matorim Samsung SLC diskovima koji su nominalno 4x sporiji u sekvencijalnom i jedno 10x-30x u random IOPS-ovima je nikakva... ono, OS se butuje 1 sekundu krace, i aplikacije se umesto 0.8 sec ucitavaju za 0.5 sec...

Mlitavo :)

Mislim da je SATA3 daleko korisniji za jeftine servere i radne stanice, znaci opet se vracamo na video editing, 3D rendering i sl... Ali to su od davnina primene gde ces uvek moci da iskoristis dodatne resurse.



Mislim da taj film necemo gledati :)

Potpis

DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos: http://www.digicortex.net/node/17 Gallery: http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! - https://github.com/psyq321/PowerMonkey

Naravno da nece imati nikakvog efekta. Taj IPC se vidi pre svega u sintetickim testovima i tzv. streaming aplikacijama.

Klasican "event handling code" nece imati nikakvu korist. Dizanje broja instrukcija po kloku danas se radi uglavnom kroz statisticke predikcije.

Sta se moze statisticki zakljuciti o event handling kodu koji se sporadicno okida?

Gluposti.. sto je jos gore, promasaji u predikciji imaju svoju cenu po performanse.

Neko je prethodno pomenuo da dubina pipeline-a ima veze sa maksimalnom frekvencijom procesora. I ovo je notorna glupost. Max. frekvencija je uslovljena iskljucivo najvecom sekcijom u pipeline-u - ne njenom dubinom. Dubina pravi problem kada dodje do pipeline hazarda - npr. read-after-write konflikta u izvrsavanju. Vreme oporavka od hazarda je veliko ukoliko je pipeline dubok. Obzirom da je odnos ucestalosti pojavljivanja hazarda i vremena oporavka u realnom zivotu los - odustalo se od dubokih pipeline-ova za CPU-ove opste namene i krenulo ka plicim.

Napredak u broju niti je vec druga pricha. Softver to jos uglavnom ne koristi, ali ako ste soft-dev nema razloga da se core-ovi ne upregnu. Problem je eventualno Amdahl-ov zakon, koji predvidja daleko sporiji progres od Moorovog.. ali, sta je tu je bolje nece biti.

@Ivan: Cestitam na pobedi u Eurosongu ;)

Zapravo ni u igricama ne mozes imati puno bolje performanse sa i7 980 .
Ustvari toliko beznacajno malo da je jedva nesto brze od i 5 750 ili amd phenom x4 9650 bukvalno nista sto bi se moglo primetiti . Tako da ostaje samo AV editing/encoding i 3D modelovanje i nista vise .

U igricama bi cak i moglo. Bar onaj deo koda koji grafiku nije out-source-ovao na GPU. Problemi vezanu za obradu slike i rendering su sto se kaze embaressingly parallel :)

http://en.wikipedia.org/wiki/Embarrassingly_parallel

Kod koji se bavi AI-jem i game logikom obicno obradjuje slozene strukture podataka rasute po memoriji, pa nema beneficije od tih ubrzanja u IPC-u.

Glavni hardverski bottleneck u projektima na kojim sam radio je bila brzina izmena kesh blokova ka operativnoj memoriji.

Problem je sledeci: projekat zahteva da koristite slozene (npr. stablo-like) strukture podataka koje imaju veliku dinamiku izmene. Nakon odredjenog vremena elementi strukture ce biti rasuti duz velikog adresnog prostora (defragmentisani). Tada operacije nad strukturom, npr. iteriranje kroz elemente izazivaju dosta promasaja u keshu - sto zahteva dovlacenje blokova iz operativne memorije. I eto bottlenecka. Drugi cest problem je sto se u C++-u programer stimulise da koristi dosta objekata. Ovakva praksa implicitno vodi ka velikom broju alokacija i dealokacija. Ove operacije pod windowsom verovali ili ne nisu thread safe. Win koristi globalni lock nad procesom da bi ih serijalizovao(!). Sto je tragicno za multithreaded aplikaciju.

Ova dva razloga su i izvor Javinih iznenadjujuce dobrih performansi u poredjenju sa C++-om. Javin garbage collector periodicno radi defragmentaciju memorije, a i priroda njegovog rada je takva da ocuvava prostorno-vremensku lokalnost koja pogoduje keshu. Osim toga se alokator se bolje ponasa u visenitnim scenarijima. Sva ova kompleksnost je ugradjena u jezik i dobija se besplatno&transparentno u odnosu na programera za razliku od C++-a.

No i Javin najveci problem je pristup memoriji. Ne posvecuje se dzabe po 50% prostora CPU die-a keshu...

Nazalost, posto kolicina kesha nije linearno proporcionalna ubrzanju, ni kesh nije silver bullet.

Tacno, BP miss nas kosta onoliko koliko je dugacak sam instrukcijski pipeline, gubi se mnogo vise CPU ciklusa ako je pipeline duzi. Mada su oni isli na to da usavrse BP, AMD se sa K6 procesorima svojevremeno hvalio uspesnoscu pri BP-u od 95%.



Inlining moze tu dosta da pomogne, mada ne treba preterivati kao i prefetch kod vrednosti za koje znas da ce se nenormalno mnogo potrazivati u kodu. Ono sto mene nervira je da je GCC postao mnogo pametan i koristi heuristiku za inlining pa ti sam inline-uje ili uninline-uje inline-ovanu funkciju od strane programera i na kraju kad ti naleti neki bug ne znas da li je bug u toj liniji koda ili onoj 1K linija iznad gde je definisana inline funkcija. Muke sam imao sa kernelom sa GCC 4.5 i opcijom CONFIG_OPTIMIZE_INLINING, jedno vreme sam mislio da je GCC puko (sto i nije daleko od istine).



Ja mislim da nema ali da su snimili koliko mizeran broj Linuxasha koristi njihov kompajler over GCC pa su krenuli da ucestvuju u razvoju GCC-a (pre toga se AMD tu bas bio zalozio).

Potpis

make love - !war

Cek zar i dalje, na linuxu se maksimalno iskoriscavaju spinlock-ovi, cak imamo i nekoliko varijanti:

http://www.mjmwired.net/kernel/Documentation/spinlocks.txt

Onda je i preempcija laksa ukoliko je locking mehanizam dobro implementiran unutar koda...

Potpis

make love - !war