Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Tak ono by stacilo kdyby byla zase desktopova verze opteronu :-)
Bylo by pěkné kdyby byl 6ti jádrový procesor 6x rychlejší než jednojádrový na stejné frekvenci. Vzhledem k časté SW nepodpoře vícejádrových procesorů, mi zvyšování počtu jader spíše připomíná marketingový tah.
zeus: On ti to nekdo nuti ? Na enkodovani videa z HD kamery se to hodi.
No to bude, az sa padavost desktopovych softwarov na jednom jadre umocni siestimi! :-D
zeus> to nie je marketing to je nutnost
platia totiz vztahy
1) pre spotrebu CMOS technologie
P=n*C*U^2*f
kde
P je spotreba chipu
n je pocet tranzistorov na chipe
C je parazitna kapacita dana vyrobnou technologiou
f je pracovna frecebcia
2) pre max. stabilitu chipu na CMOS-ke
U=k*f
kde K je konstanta dana vyrobou technologiou
z toho vyplyva
P=n*k*C*f^3
a teda ak zvysis freveneciu na 2 nasobok tak zvysis spotrebu 8x
ak zvysis pocet jadier z 0 na 4 tak u AMD zvysis pocet tranzistorov o 90% teda ani nie na dvojnasobok a teadf zvysis spotrebu ani nie na dvojnasobok
nova tovaren na 45 nm stoji 6 mld USD, pricom tovarem na 90 nm stale, v case ked to bolla novinka, za 3 mld USD...
lebo sa blizme teoretickej hranici 22 nm, kde by izolacna vrstva SiO2 mala jedinu molekulu... Preto sa uz pri 45 nm nepouziva SiO2 ale napr. Hafmium.... ale to zvysuje tie naklady na vyrobu a tovarne...
re fotoba: bez znalosti fyzikálních zákonů, jen z toho co jsi vyvozoval mi tam chybí k^2.
to zeus: čím více bude 4 a více jádrových procesorů, tím více vývojářů bude dělat svoje aplikace schopné pracovat s více vlákny současně protože kdyby ne, tak jim zisky pobere konkurence která to efektivně umí.....
fotoba: Jedna molekula SiO2 je menší než 3A (= 3.10-10 m pro SI fundamentalisty ;-)
Tvá "izolacna vrstva SiO2" proto bude tlustá spíš jako jedna "elementární krystalová buňka"
mikeczcom >> nebud naivny, programatori, ktori vedia programovat multitreadovo su velmi drahi a takych v dnesnej dobe nikto nekce platit.
NOX: Tak pouzijou normalni programatory a prelozi to necim inteligentnim, co si ty vlakna udela samo. Stejne se hlavne diky GPGPU bude muset zmenit mysleni programatoru, protoze se do budoucna tomu paralelizmu nevyhneme...
qee> to bude ako bojovat konskou jazdou proti tankom (Poliaci proti Nemcom v WW II)
tie kniznce nefunguju optimalne ani zdaleka, dobre napisany paraleny kod je na 4 jadre asi o 120% rychlesi ako kod napsiany pomocu tych kniznic...
Nejvetsi problem je s "lenosti"(v nadhledu, ona ta problematika je v soucasne podobe tak rozsahla a narocna ze to pro bezneho programatora je prilis vysoka casova zatez) programatoru, takze jedine ucinne reseni budou nova vyvojova prostredi primo zamerena na multithread a hlavne castecne vizualizovana(do zacatku alespon strom a jednoducha prace s celymi vetvemi, barevne rozlisovani pro to co jde paralelizovat a co ne a mraky dalsich pomucek aby byl multithread pochopitelny a prehledny i pro bezneho programatora a ne jen pro par vyvolenych) takze problemem dnesni doby s nedostatkem multithread aplikaci bych spise videl ve vyvojovych prostredich nez v programatorech... Mimochodem take si dovedu predstavit podstatne vetsi provazanost vyvojovych prostedi s CPUckama(vlastne i s GPUckama, me jako programatorovi bude jedno jestli cast kodu bude louskat GPU jde jen o dobre navrhnuty compilator co to bude umet) pomoci instrukcni sady ciste pro multithread atpdb., proste zatim je tento vyvoj na zacatku v plenkach to je cele proto se vsichni rozciluji na co maji 4jadra kdyz neni moc aplikaci...Ano, taky se mi zda jako by se vyvoj zastavil, ale neni to tak nektere firmy uz pracuji na multithreadovych vyvojovych prostredich.....
> Nebud naivny, programatori, ktori vedia programovat multitreadovo su velmi drahi a takych v dnesnej dobe nikto nekce platit.
Souhlasím, firmám jde především o zisk (náklady na vývoj vs. peníze za produkt).
> Čím více bude 4 a více jádrových procesorů, tím více vývojářů bude dělat svoje aplikace schopné pracovat s více vlákny současně, protože kdyby ne, tak jim zisky pobere konkurence která to efektivně umí.
Platilo by pouze v případě, že konkurence je ochotná investovat do vícevláknového vývoje. Jinak to dopadne jako s "konkurencí" ceny u benzínek, mobilních operátorů a v dalších odvětvích.
> Tak pouzijou normalni programatory a prelozi to necim inteligentnim, co si ty vlakna udela samo.
Hrozně se mi líbí, když se něco udělá samo :-)
> Stejne se hlavne diky GPGPU bude muset zmenit mysleni programatoru.
Hlavně se musí změnit myšlení jejich zaměstnavatelů, aby poslali programátory na školení a zaplatili jim více hodin na realizaci úkolů, aby to bylo vícevláknově.
> Mimochodem take si dovedu predstavit podstatne vetsi provazanost vyvojovych prostedi s CPUckama (vlastne i s GPUckama, mne jako programatorovi bude jedno jestli cast kodu bude louskat GPU...
To se již slučuje, Apple to představil v OS X 10.6 jako "Grand Central", ostatní firmy nebudou pozadu. Základem je dlouhofungující CUDA a z ní vycházející univerzální OpenCL.
Musel jsem reagovat, protože znám vedle průměrných programátorů i spoustu velmi nadaných. A vidím, jak je omezení ze strany zaměstnavatele, který chce jen za co nejmíň hodin (peněz) dobastlovat novou funkčnost do stávajících projektů, po čase dokonce donutí opustit firmu.
Aplikace u nichz je z multijadrovych CPU vypoctu jednoznacny prinost tu uz vetsinou jsou, o GPU vypoctech se zacina uvazovat nebo dokonce testovat. Viz nedavny clanek o V-Ray rendereru bezicim na CUDA. ( http://cdr.cz/a/27687 ) Donedavna na GPU rendrovalo jen firemni Gelato. Ale na to jak dlouho tu GPU jsou to jde docela pomalu. Snad to bude s OpenCL lepsi.
>> Ladis82 : > Čím více bude 4 a více jádrových procesorů ...
Nezbyva nez doufat, ze se toho casem chopi marketingova oddeleni, kdyz budou trebovat presentovat jak jsou hi. Ikdyz oni jsou schopni odpresentovat jako super-hyper- cokoliv, ze?
petrib: Ano, může to dopadnout tak, že jen malá část aplikace bude využívat více jader a zbytek pojede po staru. Je to stejné jako s většinou DX 10 her - jsou to DX 9 hry, které mají navíc 1-2 DX 10 efekty a marketing samozřejmě hlásá, že hra naplno využívá DX 10 ;-)
Momentalne maju 6-jadrovy CPU so spotyrebou 65W na 2.2GHz, takze v nasadeni do AM3 socketu nevidim problem, len ci ho budu chciet predavat za 300 eur.. asi nie..
marketing... ohurime blbcov jadrami ked uz ine nepomohlo, kedy to bude realne v predaji??
na buduci rok intel uvedie 12 jadro a nie zlepenec
diskuuze: IBM vyrabalo a mozno este vyraba nativne 180-jadrovy 32-bitovy procesor pre CISCO. Neviem ci tych jadier je 180 alebo 196... z tej fotografie ich vsetky prstom pocitat bolo tazke...
:P
>>Ladis82:
Ja jen rikam ze ani tak neni problem v programatorech, jako ve vyvojovych prostredich a compilatorech ktere by znacne usetrili cas a minimalizoval se tak rozdil mezi stejnou aplikaci napsanou v single a stejnou aplikaci napsanou v multi, proto se to nyni vyviji jako s pumpama, zadna firma zamestnavajici programatory nebude sypat svuj cash do multi aplikaci kdyz to nebude mit se svymi "marzemi" a proto nezbyva nez cekat az tech par solidnich firem jako Borland atpdb. udelaji plnotucna multithread (do zacatku alespon castecne vizualizovana) prostredi se kterymi bude programator uz srovnatelne casove efektivni jako kdyz pise single.....
Mimochodem castecne maji firmy zamestnavajici programatory pravdu jelikoz oni si plati vyvoj tech programatorskych prostredi tim ze jedou na ofiko licence takze firmy plati jine firmy aby pro ne dal vyvijeli sve produkty;)
PS: Je sice hezky ze Apple uz s tim zacal, ale MS co neukradne nebo nekoupi to nema a bohuzel pres 90% populace jede na "malyho mekkyho"....;) Malej mekkej uz by mel byt podle prijmu o nekolik generaci dal nez konkurence a realita je takova ze sotva drzi krok takze Tve aplikovani logiky a principu konkurencniho prostredi jsou tu zcestna resp. na hony vzdalena od reality, bohuzel.....:(
Ty asi nevíš, jak se dá zoptimalizovat single kód na multi. Na úrovni kompilátoru řešení existuje, má to přinejmenším Intel, ale není to efektivní (v těch relativně krátkých úsecích kódu, co je schopen zmultithreadovat, to zas brzdí komunikace mezi jádry a s cache). Pak jsou knihovny, které usnadňují zmultithereadování pro cykly apod., aby se člověk neupsal detailama - ale už tady je potřeba práce navíc od programátora oproti single. A ani tohle není zdaleka tak efektivní kód, jako ručně napsaný multi (viz příspevěk od fotoba). BTW1 vizualizace mutlithreaded kódu - to je nějaká blbost, ne? BTW2 Borland nás má zachránit? MSVC je mnohem dál a Borland už poněkolikáté dokonce neúspěšně zkoušel prodat svoji vývojovou sekci (nebo už se mu to podařilo prodat?). BTW3 MS kopíruje/kupuje, sice se zpožděním, ale jo, takže časem se dočkáme třeba i tam. Jinak ale nejde o nic světoborného, jde jen o marketingový název zastřešující skupinu technologií, které jsou i pro Windows a asi i Linux. BTW4 podle mě není nutné, aby masy používající Windows měly nutně mít tyhle technologie, pro mnoho lidí je dnes už Windows beztak jen game loader a na práci používaj něco jiného ;-)
btw rozdiely medzi opteron phenom
>>Ladis82:
"Ty asi nevíš, jak se dá zoptimalizovat single kód na multi. Na úrovni kompilátoru řešení existuje, má to přinejmenším Intel, ale není to efektivní (v těch relativně krátkých úsecích kódu, co je schopen zmultithreadovat, to zas brzdí komunikace mezi jádry a s cache). Pak jsou knihovny, které usnadňují zmultithereadování pro cykly apod., aby se člověk neupsal detailama - ale už tady je potřeba práce navíc od programátora oproti single. A ani tohle není zdaleka tak efektivní kód, jako ručně napsaný multi (viz příspevěk od fotoba)."
Prosim vice premyslej nad tim co pisi, v podstate se bavim o tom samem a to ze je problem s radoby prostredimi...;)
"BTW1 vizualizace mutlithreaded kódu - to je nějaká blbost, ne?"
Precti si jeste jednou muj prvni prispevek at vis o cem mluvim(pokud se programator neorientuje nemuze ani chapat problematiku multithreadu), dneska neni temer zadne(jedno znam ale jeste to zdaleka neni "ciste multithread", ale to je do prumyslu pro RT aplikace smaozrejme pod RT OS) vyvojove prostredi ciste pro multithread, vsechno to jsou jen nalepence a dodelavky do singlu....
"BTW2 Borland nás má zachránit? "
Borland jsem jmenoval jako priklad kvalitni firmy, ne jako adepta na nej ciste multithread vyvojove prostredi, z jeji kvality by si melo brat rada firem priklad ve sve dobe best, to ze zaspali o tom zadna...;)
"BTW3 MS kopíruje/kupuje, sice se zpožděním, ale jo, takže časem se dočkáme třeba i tam. Jinak ale nejde o nic světoborného, jde jen o marketingový název zastřešující skupinu technologií, které jsou i pro Windows a asi i Linux. BTW4 podle mě není nutné, aby masy používající Windows měly nutně mít tyhle technologie, pro mnoho lidí je dnes už Windows beztak jen game loader a na práci používaj něco jiného ;-)"
Vec nazoru, Widle uz se dostavaji do stavu kdy na domaci pouziti(tedy ne jen na hry) zacinaji stacit....
V praci to zdaleka jeste neni tak jak si myslis, kdyz delas aplikaci pro Widle(coz je 95% aplikaci resp. zakazniku) musis jet na widlich a spravnych SPkach abys to mel na cem otestit, a mit jednu pracovni a jednu testovaci masinu uz davno neni nutne vyjma special aplikaci pro ethernet kde se testum na vice strojich nevyhnes....
Proste porad jsi me nicim nepresvedcil ze bych mel zmenit svoji zakladni myslenku, a to ze ani tak neni problem s programatory jako je vetsi problem s vyvojovymi prostredimi....
PS: S tim fotobou, to je tak dobry do par stranek kodu, jakmile budes psat rozsahlou aplikaci tak koncis a budes se v tom prestavat orientovat a budes vic hledat nez dodelavat co jsi jeste chtel(a to je cely problem, pak razem ta casova efektivita hovori pro single), proste ty prostredi na multithread nejsou stavene...;)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.