tak pár roků přešlo a FB­-DIMM jsou realitou. bohužel bez masového nasazení zatím pouze v oblasti serverových­/workstationových řešení postavených na chipsetech řady 5000 od Intelu pro Xeony řad 5000, 5100 a chystané 5300. a jako relativní novinka jsou relativně drahé jak FB­-DIMM, ale i hi­-endové MB postavené na těchto chipsetech. neubránil jsem se pousmání při čtení pasáží o levnějších MB v jinak výborném článku.

nemuzou vam tam dat rovnou optiku kdy by sel kazdy pametovy modul obsluhovat solo a opticky kablik by vedl vzduchem=zadne ztesnane spoje na desce, to by uz nebylo co vylepsovat ;­-)

prave ze otazka nakolik je to vylepseni, kdyz jsou velke latence tak je potreba velka cache na procesoru ­(viz 2mb a vice u intelu­) takze penize, logika na pametovych modulech bude draha ­(dalsi penize­)...

Mno ja si take myslim ze reseni do budoucna bude hodit primo pametovy radic rovnou na desticku pameti. Kazda takova pamet s integrovanym radicem by pak byla komunikacne propojene samostatnym seriovym spojenim ­- kabelem a to asi jedine optika, tedy 2x tenucke vlakno s northbridgem dosky. Vyhoda: nejnizsi mozne latence ­(radic pameti je primo na pameti­), v pripade optiky zadne ruseni a ani limitujici vzdalenost. Napriklad pamet od chipsetu pripojena 20m optickym kabelem. Latence prevodem napriklad 32 paralelnich bitu do 32 seriovych svetelnych pulzu optiky v jednom taktu paralelniho rozhrani neni zadny problem, diky vlastnostem sireni svetla v optickem vlaknu se daji dosahovat neskutecne kapacity serioveho prenosu a hlavi vyhoda, v momente vyslani vysilacem jsou ­"prakticky hned­" na druhe strame u prijimace, takze zadne spozdeni, v budoucnu idealni synchronizace vzdalenych prvku. Mozna 2010 :)

1 PHP neni od MS
2 PHP je interpretovany jako basic, ten na osmibitech autor take nesnasel ?
3 PHP se DA zkompilovat do binarniho kodu a tim se veta o nejake vetsi narocnosti stava blabolem ;­-­)
4 jsou mnohem horsi zverstva
5 malokdo si to uvedomuje ale 8 bit potrebuje pro jednu instrukci 8 bitu 16 bit CPU 16....atd., tzn 64 bitove procesory potrebuji na to same co 32bitove jednou tolik pameti, a 32 bitove jednou tolik co 16 bitove ci 8 bitove proto je na PC tak velka spotreba ramek ale to uz autorovy clanku zrejme nedoslo, osmibity pro neho zustavaji dokonale ;­-)

A co třeba typová kontrola? To není potřeba? Když s proměnnými zacházíte jako s dynamickými, máte obrovský performance hit, protože procesory tahají celé bloky dat a ne jednotlivé proměnné. Jenže dynamické proměnné jsou roztroušeny po paměti, kdežto statické jsou pěkně u sebe. Pro přístup k dynamickým proměnným je potřeba mnohem více výpočetních zdrojů. Toť k efektivitě PHP.

Ad potřeba RAM ­- Vám zase nedošlo, že 64bit CPU umí pracovat i s 8bit, 16bit a 32bit proměnnými a že zaplácnuté místo závisí na použitém typu proměnných. Větší paměť je potřeba na pointery, to uznávám.

PS: Autor má rád jazyky jako C++.

Ale doslo jenomze 8bit a 16bit promenne se nepouzivaji z pohodlnosti a mnoha jinych duvodu ­(pokud se nedela konverze nebo loader z nejakeho oldshool formatu,­), a pokud se ma vyuzit sila 64 bit i promenne budou 64bitove, jinak s PHP nesla rec o zatezi CPU ale o pametove narocnosti a myslim ze zatec CPU zrovna v souvislosti s PHP moc % uzivatelu tohoto SKRIPTOVACIHO jazyka netrapi, kdo zpracovava statisice pristupu za hodinu nebo prehazuje gigabajty dat = chce­/potrebuje vykon muze si kod zkompilovat nebo radeji ­(musi­) pouzit C like program, pole taky nikdo neora s osobnim autem...

Tak to je opravdu vtipné ­- nepoužívají se z pohodlnosti. Možná v nějakém amatérském klubu, ale aspoň trochu solidní programátor volí proměnné podle toho, co do nich bude potřebovat dát. Síla A64 nespočívá jenom v 64bit proměnných, ale především ve více registrech. Ostatně násobení 64bit čísel trvá 4 cykly, kdežto 32bit čísel jenom tři cykly. Jenom blb by používal všude proměnné největších velikostí. Osobně jsem 64bit integer potřeboval jen málokdy, nevím, proč bych ho měl cpát všude. A k dynamickým proměnným ­- to si vážně myslíte, že vytvoření a následná destrukce dynamické proměnné je stejně paměťově náročná jako u statických?

Jezis chlape pochop ze narocnost behu nejakeho PHP criptu neni tak velka aby to pri dnesnim vykonu HW nekoho vedlo k myslenkam o dokoupeni dalsichho mudulu RAM nebo lepsiho CPU, kdyz chce delat narocne operace nebudes to skriptovat ne ?

Ad promenne, solidni programator potrebuje napsat program rychle a ne premejslet zdali jednou nebude potrebovat vetsi rozsah hodnot a kdy a jak velky chlivek teda volit, da maximum a neresi to stejne kdyz to neni pole houby vis kde to v pameti je a ze ti ten 8bit zabere treba vlastne chlivek vetsi 16 nebo 32bit podle toho jak ti to compiler zoptimalizuje na ­"rychlost­" nebo ­"velikost­" ... a co kolik trva cyklu bych neresil vubec protoze jaka je skutecnost vi pri vicestupnovem zpracovani jake je u modernich procaku jen panbuh

Dobrá, přejdeme k tykání.

Ad PHP ­- zvláštní, že řada diskuzních fór, které nejsou zrovna nenáročné ­(např. fórum na PCtuning zatěžuje procesor asi 2x víc než časopis jako takový­), pořád jede na PHP a o přechodu jinam se neuvažuje.

Solidní programátor musí udělat program, který vytvoří rychle, ale nebude přemrštěně náročný na hardware a bude spolehlivý. Jestli ty programuješ jinak, neznamená to, že každý se drží tohohle ­(Což mi připomíná našeho učitele na programování, který je zděšen odchovanci PHP, kteří mu v kursu C++ ani neumí udělat while cyklus... holt ne všichni umí při programování myslet­).

"stejne kdyz to neni pole houby vis kde to v pameti je­" ­- moc si toho evidentně nenaprogramoval, protože kdyby jo, věděl bys, že céčkový kompilátor ­(např. Visual C++­) dává statické proměnné na stejné úrovni kódu ­(globální, funkčně lokální­) v paměti ihned vedle sebe a to bez ohledu na to, zda je to pole nebo ne. Jestli nevěříš, tak se povídej na adresy pointerů. Nevím, jak bys chtěl data optimalizovat na velikost nebo rychlost. Optimalizuje se uspořádání a typ instrukcí, inlining funkcí, vektorování, uspořádání dat v paměti.

"a co kolik trva cyklu­ bych neresil vubec­" ­- naštěstí v Microsoftu i Intelu tohle řeší, takže jejich kompilátory produkují s každou verzí vždy o něco rychlejší kód.

V C++ jsem toho opravdu moc nenaprogramoval, nebyl duvod, taky se mi nechce hlidat kazdej camfor pameti co pouziju.

ad PHP no vidis ze je to v klidu ;­-­)

ad cykly, kompilatory to resi a pro ktere procesor prosim ? AMD, Intel, Crusoe, Cyrix ? a ktery typ ? kazdy vyrobce ma mnoho typu CPU ktere se muzou a taky lisi, protoze kazdy ma jine casovani, jene rozvrstveni zpracovani, jine cache atd., to je takove to reseni a optimalizovani na dve veci, vime ?

Zajímavé, že AMD vstupuje do oficiálních statistik průmyslových testů s kódem kompilovaným pomocí Intel C++ Compiler. A taky zvláštní, že i u jiných zdrojáků produkuje Intel C++ Compiler nejrychlejší kód ze všech kompilátorů i v případě AMD. Něco na té optimalizaci asi bude...

"takove to reseni a optimalizovani­ na dve veci, vime ?­" ­- zjevně nevíš.

Me je uplne jedno cim si dela AMD reklamu me zajima v cem se prekladaji rogramy co pouzivam­/e a ze se vetsinou optimalizuje jen pro jeden procesor se vi, dobre je to videt na koderech videa kde jeden program jede rychle na intelu a pomalu na amd a druhy program kde je to opacne !

Nikde taky nepisu ze optimalizace jako takove jsou k nicemu, jenom si podle me nema cenu hrat s kazdou instrukci, mnohem ucinnejsi je vymyslet optimalnejsi algoritmus, nedelat to co opravdu neni potreba ­(treba vykreslovane elementy­) atd.

"Me je uplne jedno cim si dela AMD reklamu­" ­- ??? O jaké reklamě to mluvíš? Já tvrdím, že AMD vstupuje do oficiálních statistik uznávaných průmyslových benchmarků s kódem optimalizovaným konkurenčním Intel C++ Compiler, který optimalizuje pro procesory Intel. I v tomto případě tento kompilátor optimalizující pro jiné procesory je schopen vyprodukovat jeden z nejlepších kódů pro AMD.

"dobre je to videt na koderech videa kde jeden program jede rychle­ na intelu a pomalu na amd a druhy program kde je to opacne !­" ­- Tak to bohužel není. Procesory jsou si v mnoha ohledech velmi podobné a rozdíly výkonu jsou často dány pouze hrubým výpočetním výkonem ­- velikost a rychlost cache, organizace pipeline, podporovaný typ vektorizování, rychlost pamětí... Už jsem několik věcí zkompiloval, abych mohl s klidem prohlásit, že Intel C++ Compiler produkuje perfektní kód nejen pro Intel procesory, ale i pro AMD. Kdyby byla pravda, že procesory jsou zcela jiné, výsledkem by byl naopak pokles výkonu pro procesory AMD.

"jenom si podle me ne­ma cenu hrat s kazdou instrukci, mnohem ucinnejsi je vymyslet optimalne­jsi algoritmus­" ­- absolutní nesmysl. Správné řazení instrukcí je jeden z klíčových faktorů výkonu moderních superskalárních procesorů. Často je mnohem rychlejší vykonat paralelizovně více výpočtů než méně na sobě závislých. To samé platí pro threading a vektorizování ­(čtyřnásobná SIMD operace je mnohem rychlejší než čtyřikrát x86­). Dnes nelze programovat způsobem, jak se to dělalo pro 486ky. A jen pro zajímavost ­- Itanium 2 je silně vázáno na optimalizace kompilátoru, protože kompilátor u tohoto procesoru je určujícím prvkem paralelizace v rámci výpočetních jednotek.

Pekne si to prekrucujes, tak si tu pis dal...

Když tu diskuzi čtu, tak zjišťuji, že bych rád věděl, jak to vlastne s velikostí proměnné ve stutečnosti je. Pokud moderní procesoru používají linaární adresování, tak to funguje zjednodušeně asi takto : Adresa #0000>32­/64bit dle procesoru
#0001>opět 32­/64bit. Takže pokud short int ma v C velikost 8bit, int 16­/32 a long 32­/64 pak by se měl adresový prostor obsazovat takto:
8bit
#0000:>#xxxxxxff
#0001:>#xxxxxx9a
Pro­cesor na jeden paměťový cyklus načte všech 32b.
16bit
#0000:>#xxxx00ff
#0001:>#xxxx009a
Procesor na jeden paměťový cyklus načte opět všech 32b.
32bit
#0000:>#000000ff
#0001:>#0000009a­
Procesor na jeden paměťový cyklus načte také všech 32b.
x udává ignorované bity u kratších proměnných.
Pokud bych chtěl ušetřit paměť, pak by se data musela ukládat takto:
8bit + 16bit
#0000:>#ff #dd #00ff
#0001:>#009a a daší 16 bit proměnná nebo 2 8bit proměnné.

Obávám se, že přínos je malý, protože takto uložená data by musel zpracovat program, což by se mohlo negativně promítnout v rychlosti.

Je li procesor 32 bitový tak registry jsou 32bit také a to znamená, že operace s 8,16 i 32 bit int budou trvat stejne stejně jako přesuny a bitové operace. Pokud se mýlím, tak bych rád věděl více. Pomohl by například odkaz někam, kde je to vysvětleno.

Co se tyče srovnání PHP a C++ myslím si, že postrádá jakýkoliv smysl. Každý jazyk má jiné určení.

Suhlas!!!. Pokial viem, tak najrychlejsie sa procesor dostane k datam, ked su zarovnane na urcity pocet bitov, t.j. ­- pre 32 bit procesor je to zarovnanie na 32 bitov.
Pravdaze je procesor schopny spracovat data aj mimo tohto zarovnania, ale vyzaduje to cas navyse, kedy si tieto data ­"dorovna­". Takze ci sa to niekomu paci alebo nepaci, tak v pevnej ciarke bude Aritmeticka operacia trvat rovnako dlho ci spocitavas 100+100 alebo 50000+5000000 ­(char vs. int­). Ak chces usetrit na pamati a vypnes spominane zarovnavanie, potom stracas na vykone, pretoze cisla sa nacitavaju vo viacerych pamatovych cykloch, transformuju do 32bit a potom sa v ALU spracuju.
Pri pohyblivej radovej ciarke je to zalezitost inej vypoctovej jednotky a ta ma presnost 4 alebo 8 bajtov a malo by tam platit podobne pravidlo.

mno ja nevim jak nekde jinde, ale dnes je moderni ­"zamestnat­" do softwarove spolecnosti ktera dela napr. ucetni programy a podobne co nejlevnejsi pracovni silu. Staci at maji zaklady v scriptovani JAVA, PHP a pod. Neco se ­"vizualne­" naprogramuje pres ­"vizualni­" tvorbu aplikaci systemem tady pretahnu tlacitko, tady pretahnu okno tady zmenim vypl barvy a nasledne se v JAVA ­(pripadne PHP­) a pdoobnem sciptovacim jazyce napisou k akcim bloky scriptu a hotovo. Aplikace vznika chvilicku a jiz se prodava. Zamestnavatel nema zajem aby programator tvoril aplikaci hodne cisteji, rychleji ale o dost zdlouhaveji v C++. To by nemohl byt zacatecnik ze skoly ale zkuseny programator C++ ktery skutecne chape souvyslosti HW a nejen blbe tuka naucene fraze scriptu. To jsou pro zamestnavatele jen zbytecne vyhozene penize ktere jeste vic prodrazi aplikaci ktera pak v konkurenci ­"scirptovanych aplikaci­" cenove nemuze obstat. A taky preci nakup silnejsiho HW zakaznika nejde z penez tvurce ­(prodejce­) aplikace. Takze i kdyz se to mne a i autorovi clanku take nelibi, je to bohuzel dnesni realita, a lepsi to uz asi nebude.

Mit SW fimu, tak te beru vsema deseti, ty se rozhodne vyplatis;­-­):­-D...

Sice nejsem programator, presto vas bych ani nahodou nezamestnal.Clovek ktery rekne ze na rychlosti programu nezalezi, kteremu je jedno ze jeho utilita, ci kod obecne je psan ­"prasacky­" neefektivne by se mel nad sebou zamyslet. Kdyz by si takove blaboly tvrdil kazdy programator, tak by ani ty nejvykonejsi procesory sveta nestihali to co stara 286tka.
SOLIDNI programator programuje efektivne, s myslenim do budoucna a hlavne premysli na co se bude program pouzivat a proto jsou mu nekdy 64bitove hodnoty zbytecne a zase 8bitove nedostatecne. Ono je neco jineho kdyz nekdo dela kvuli vykonu v 3D enginu 2bitovou pruhlednost a ve vasem pripade samozrejme 64bitovou. To aby se pruhlednosti pocitaly dva roky a hrac se ­"nenudil­" u tak ­"svizne­" hry :o)

no, záleží na tom jestli žigulík je osobní auto, každopádně na orání se použít dá a velice dobře :­-­)­))