22 nm-es processzorok készítéséhez használható gyártástechnológiáról beszélt az IBM

 ( trey | 2008. szeptember 19., péntek - 11:06 )

Az IBM fellebbentette a fátylat a "computational scaling" névre hallgató technológiájáról, amely lehetővé teszi számára a közeljövőben, hogy 22 nanométeres gyártástechnológiával készítse chipjeit. Összehasonlításképpen, a Intel jelenlegi legfejlettebb processzorai 45 nanométeres technológiával készülnek és a vezető processzorgyártó csak 2009-ben tervezi bemutatni a 32 nm-es technológiát a CPU gyártásban. A gyártóknak jelenleg alapvető fizikai korlátok miatt problémájuk van a 22 nm-es gyártással. Az IBM új technológiája ezen segítene.

Bővebben itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

He ez azt vonna magautan, hogy az IBM nekiallna olcso, asztali gepbe szant PPC procikat tomegtermelesben gyartani, akkor lenne jo hir.
Mivel ez nem varhato, igy csak egy hir...

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Kíváncsi vagyok, hogy az AMD is kapna ebből, mint technológiai partner...

KAMI
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey

Szo volt rola, hogy a kovetkezo Power-ek Hypertransportot fognak hasznalni az alaplappal valo kommunikaciohoz. Ami persze nem kapcsolodik kozvetlenul ehhez a hirhez, de legalabbis mutatja, hogy tenyleg osszedolgozik/dolgozhat a ket ceg. Az a baj, hogy az IBM-nel sose tudni. Nyomatnak valamit fel evig, aztan fel ev mulva elkezdik a tok ellenkezojet csinalni... :/

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Az AMD nyilván kap belőle, ahogy az eddigi fejlesztésekből is, ezért hívják technológiai partnernek...

Pont a HyperTransport nem túl jó példa, mert az egy szabadon licenszelhető technológia, amivel azt szeretné elérni az AMD, hogy megjelenhessenek specializált processzorok amik HT-n és nem PCI-E-n kapcsolódnak az AMD-s szerverekhez.
Ebből adódóan akár az Intel is használhatná, amit persze nyilván nem tesz meg, inkább kifejlesztett valami nagyon hasonlót...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Meg aztán az IBM már azelőtt használt hypertransportot, hogy az AMD K8 megjelent volna. Az x440 és az x445-ös szerverek NUMA node-jait ennek valami korai implementációjával kötötte össze.
---
Linux is bad juju.

Semmi nem valtozna. Az szamit csak, hogy:

1. Kepes lenne-e az IBM sokat gyartani abbol az x86 killerbol?
2. Kepes lenne-e azokat eladni?

Jelenleg mindkettore nemleges a valasz.

Egyebkent meg nem a csikszelesseg az architekturak szent gralja.

jaja....meg kell csak nézni a CELL-t.

Mert a CELL egy általános célú processzor, amire hemzsegnek a desktop OS-k és a köré épített konfigurációk.

Gentoo legalábbis forog rajta.

Erezd az ironiat.

---
pontscho / fresh!mindworkz

biztos nem rossz a cell, de azert a benne levo ppc magok nem tul okosak (inorder, 2 issue). viszont az spe magok is ott vannak.

szerk: itt volt egy kis vita regebben, hogy a xenon ppc magja mennyire jo a core 2/hoz kepest is. most tobb helyen is latom, hogy az ugyanolyan buta mag mint a cell ppe magja. (erre fele volt errol szo a HUP-on)

- Use the Source Luke ! -

Ezert irtam, h erezze az ironiat, mert a gentoo nem a spe-n fut/fordul, hanem a benne levo ppe-n, az meg lofasz.

---
pontscho / fresh!mindworkz

Köszi a kiigazítást.

erről hosszan lehetne vitàzni, a legkülönbözőbb èrvekkel ès linkekkel dobàlòzva pro ès kontra. most erre sajnos nincs időm, pedig remek szòrakozàs:) igy legyen annyi elèg, amit koràbban irtam. a mainstream piac desktop nèvvel illetett de facto kategòriàja szàmàra ma a legfőb kihìvàst a nagyfelbontàsù HD videozàs jelenti. az IBM xenon processzoràval szerelt Xbox360 màr 2005 karàcsonya òta kèpes 1080as HD filmek lejàtszàsàra. az Intel csak 2èvvel kèsőbb volt kèpes előàllni hasonlò szàmitàsi kapacitàssal birò cpuval. itt ez a lènyeg, a többi mellèbeszèlès:)

az Intel csak 2èvvel kèsőbb volt kèpes előàllni hasonlò szàmitàsi kapacitàssal birò cpuval

ez nem igaz mivel ez inkabb szoftver kerdes, olyan dekoder kell ami rendesen tud parhuzamosan dolgozni tobb magon. pl. itt egy hd h.264 video ami kozel az az xbox360 altal tamogatott maximum bitrata szempontjabol (bar az fps csak 24 es nem az xbox altal tamogatott max 30), nezzuk ezt az ffmpeg az uj frame-level multithreading patchel - ez vegre egy jo szabadforrasu dekoder x86-ra - hogy dekodolja ket szalon core 2 3.0 GHz-cel:

 ./ffmpeg -threads 2 -i ~/jaj/big_buck_bunny_1080p_h264.mov -f yuv4mpegpipe - > /dev/null
FFmpeg version SVN-r14686, Copyright (c) 2000-2008 Fabrice Bellard, et al.
  configuration: --enable-pthreads
  libavutil version: 49.8.0
  libavcodec version: 51.65.0
  libavformat version: 52.20.0
  libavdevice version: 52.1.0
  built on Sep 22 2008 00:45:07, gcc: 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x2355550]negative ctts, ignoring
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/home/denes/jaj/big_buck_bunny_1080p_h264.mov':
  Duration: 00:09:56.48, start: 0.000000, bitrate: 9725 kb/s
    Stream #0.0(eng): Video: h264, yuv420p, 1920x1080, 24.00 tb(r)
    Stream #0.1(eng): Data: tmcd / 0x64636D74
    Stream #0.2(eng): Audio: mp4a / 0x6134706D, 48000 Hz, 5:1, s16
Output #0, yuv4mpegpipe, to 'pipe:':
    Stream #0.0(eng): Video: rawvideo, yuv420p, 1920x1080, q=2-31, 200 kb/s, 24.00 tb(c)
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
[h264 @ 0x2399b80]brainfart cropping not supported, this could look slightly wrong ...
frame=14317 fps=135 q=0.0 Lsize=43487971kB time=596.54 bitrate=597198.0kbits/s

mint latjuk a realtime 5,5-szorosevel tudja dekodolni egy 3.0 GHz-s core 2 ket maggal. Ez alapjan ezzel a dekoderrel gyakorlatilag barmelyik intel/amd tobb magos proci tudja dekodolni realtime (akar egy 2005-os dual pentium 4 is).

szoval itt az latszik, hogy a xenon mint hardver nem olyan nagy durranas, a szoftver viszont tenyleg megelozte a korat - legalabbis az open source rivalisokat nezve, amik csak most kezdik beerni.

- Use the Source Luke ! -

Az Athlon X2 3800+-m minden további nélkül megeszi CoreAVC codeckel a The KMPlayer az 1080p-t. Igaz, ez Windsor magos (2006 május 23.-n jelent meg), de a korábbi Manchester és Toledo (még S939, de 2005 első fele) magosok se lehetnek lassabbak.

Mplayer, VLC viszont elvérzik. (Win32)

Azert azt te sem gondolod komolyan, hogy ez a "legnagyobb kihivas" a mai desktopok vilagaban... Eloszor is szerintem gyakorlatilag 0% azoknak a usereknek a szama, akik 1080-as HD filmekkel foglalkoznak.
Masodsorban lehet, hogy a desktop procik 2005 kornyeken nem tudtak lejatszani ilyen cuccokat (akkoriban meg kevesebb embert erdekelt ez, mint ma), de hidd el, amint valodi igenykent megjelenik a HD visszajatszas, lesz olyan olcso desktop proci, ami kepes lesz ra. Sok minden miatt lehet szidni az x86-ot, konkretan alkalmazkodokepessegben es a piaci igenyek felismereseben nagyon jo az Intel.

szerintem gyakorlatilag 0% azoknak a usereknek a szama, akik 1080-as HD filmekkel foglalkoznak

Nem jol "szerinted".

---
pontscho / fresh!mindworkz

Konkretum?

Van ami nem publikus forumra valo.

---
pontscho / fresh!mindworkz

ebben nincs igazad. egyre nagyobb a HD video jelentősége, sőt a HDTV is egyre inkább teret nyer, köszönhetően annak, hogy a 90es évek analóg töketlenkedései után, ma már digitális útra tértek.
de kíváncsi vagyok, hogy szerinted akkor manapság milyen feladat jelent számításigényes kihívást home user/desktop userek világában?
természetesen széles kört érintő igényekre gondolok, nem egy apró szubkultúra hóbortjaira.
egyébként eredetileg az IBM Xenon és az x86 összehasonlításáról volt szó, amikor reagáltam. ezért függetlenül attól, hogy szerinted vagy szerintem mi az érdekes az emberek számára, az a tény, hogy a Xenon 2 évvel az x86ok előtt megbirkózott egy jelentősebb feladattal, elégséges érv a kiinduló állítás cáfolatára.
a fentebb említett Big Buck Bunnyval való kísérletezésre nem volt időm, de az tény, hogy egy valóban keményen kódolt H.264 1080as video nézhetetlen lesz 2Ghz körüli 2 magos bármilyen x86 CPUval. a BBB a fenti eredmények tükrében biztosan nem ilyen. linket sajnos nem adhatok, de aki már legalább látott ilyet, tudja miről beszélek.

akkor mondjal egy ilyen videot, es kiprobalom.
amiket probaltam - apple trailerek, meg amiket talaltam - legalabb 80 FPS-sel ment ffmpeg+frame level multithreading patch-csel core 2 3.0 GHz-n ket maggal. Pl. itt egy 18Mbps-es 30 fps-es video (amit elvileg a xenon nem is tud teljes sebesseggel lejatszani):

./ffmpeg -threads 2 -i forests.30.1080.mp4 -f yuv4mpegpipe - > /dev/null
FFmpeg version SVN-r14686, Copyright (c) 2000-2008 Fabrice Bellard, et al.
  configuration: --enable-pthreads
  libavutil version: 49.8.0
  libavcodec version: 51.65.0
  libavformat version: 52.20.0
  libavdevice version: 52.1.0
  built on Sep 22 2008 00:45:07, gcc: 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x1057550]edit list not starting at 0, a/v desync might occur, patch welcome
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'forests.30.1080.mp4':
  Duration: 00:00:17.90, start: 0.000000, bitrate: 18461 kb/s
    Stream #0.0(eng): Video: h264, yuv420p, 1920x1080, 30.00 tb(r)
Output #0, yuv4mpegpipe, to 'pipe:':
    Stream #0.0(eng): Video: rawvideo, yuv420p, 1920x1080, q=2-31, 200 kb/s, 30.00 tb(c)
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
[h264 @ 0x1071cb0]brainfart cropping not supported, this could look slightly wrong ...
frame=  539 fps= 89 q=0.0 Lsize= 1637216kB time=17.97 bitrate=746497.5kbits/s

mondom en, hogy te osszekeverted a szoftver kerdest a hardver kerdessel.

- Use the Source Luke ! -

The City of Lost Children/720p. A kep csak 5Mb/sec, de mplayer/ffmpeg keptelen lejatszani egy 1.83-as CD-n. Az egyel nagyobb teson mar eldocog, de csak azert mert gagyi 192kb-es DD hang van mellette. Egy normalisabb (ertsd 1.5Mb-es DTS) hangsavval mar az is keves.

A fent emlitett 3.0GHz-es Core2-on mar gond nelkul megy mind barmilyen lejatszoval, de tedd hozza azt a par ev differenciat is a ket CPU kozott van.

---
pontscho / fresh!mindworkz

The City of Lost Children/720p. A kep csak 5Mb/sec,

kiprobalnam, csak nem szoktam torrentezni. na majd meglatjuk.

A fent emlitett 3.0GHz-es Core2-on mar gond nelkul megy mind barmilyen lejatszoval, de tedd hozza azt a par ev differenciat is a ket CPU kozott van.

ezen a core2-n ket maggal durvan a realtime 3-szorosaval megy a dekodolas. Ez azt jelenti, hogy egy regi ket magos pentium 4 is valoszinuleg eleg a lejatszashoz a patchelt ffmpeg-gel, sot az 1.83-as CD is lehet, hogy eleg ezzel az ffmpeg-gel.

- Use the Source Luke ! -

ezen a core2-n ket maggal durvan a realtime 3-szorosaval megy a dekodolas. Ez azt jelenti, hogy egy regi ket magos pentium 4 is valoszinuleg eleg a lejatszashoz a patchelt ffmpeg-gel, sot az 1.83-as CD is lehet, hogy eleg ezzel az ffmpeg-gel.

Lehet. De amivel jatszottam az egy friss ffmpeg volt, finomabb jeleneteknel (pl. mikor minden pixel mozgott a kepen) berohogott. En meg toroltem. Nem a filmet. :)

Milyen patch-ekrol van szo?

---
pontscho / fresh!mindworkz

nincs meg a patch benne az ffmpeg-ben.
http://code.google.com/p/google-summer-of-code-2008-ffmpeg/downloads/list
Frame-based multithreading patch
van ujabb verzio is valami git faban vagy az ffmpeg-devel-en.

- Use the Source Luke ! -

Johat, a dolog igy kicsit maskepp hangzik.

---
pontscho / fresh!mindworkz

mert? annyit mondtam, hogy a xenon chip nem akkora durranas, csak a software volt jobb mint intelen. es lam, normalis software-rel intel/amd-n sem kunszt a hd video lejatszas.

- Use the Source Luke ! -

az összehasonlítás innen úgy lenne fair, ha ismernénk az Xbox360 lejátszójának a forráskódját. illetve tudnánk, hogy mennyi Xenonos processzormagot és milyen %os terheltséggel használ az Xbox360 lejátszója. a vita jelen állásánál minimum annyit kijelenthetünk, hogy a Xenon semmivel sem rosszabb, mint az x86 CPU társai. az eredeti itteni állítás, miszerint a Xenon csak arra képes mint a Cell PPE magja egyébként is erős tévedés. mellékszálon megjegyzem a Cell sem rossz CPU csak nem a PPE magja miatt szerezte a hírnevét.
a linkelt vitában már csak arról van szó, hogy az x86 CPUk jobbak, mint a Xenon, de a fentiek szerint legalább egyformák a képességeik. a linkelt ffmpeg kód eléggé friss, majd 3 évvel az xbox360 debütálása után jelent csak meg. kérdés, ha a Microsoftnak már 2005ben olyan jó H.264 lejátszó programja volt, vajon miért nem jelentette meg Windowsra is? igazán jól jött volna a Vista kampányához.
ha viszont az Xbox360 lejátszója kb ott tartott hatékonyságában mint az ffmpeg 3 éve, és erre jóval nagyobb az esély, akkor mégiscsak jobbnak kell lennie a Xenonnak.
az tény, hogy a gcc jelenleg nem produkál hatékony kódot Xenonra, ezért az Xbox360ra hackelt linuxok nem futnak olyan hatékonyan xbox360on, mint PCn. az 512Mb Nvidia GPUval megosztott memória sem sok manapság. de erről nem az IBM tehet. viszont a Microsoftnak és feltehetően az IBMnek is van egy igen jó és hatékony fordítója Xenonhoz.

vita jelen állásánál minimum annyit kijelenthetünk, hogy a Xenon semmivel sem rosszabb, mint az x86 CPU társai

nem egeszen, mivel az xbox h.264-et max 10Mbps-est jatszik le gond nelkul a faq szerint. Egy ilyen filmet viszont a core 2 3.0GHz realtime 3x-osaval dekodol (persze nyilvan a lejatszas kicsit lassabb, mert ki kell kuldeni a vga-ra).

az eredeti itteni állítás, miszerint a Xenon csak arra képes mint a Cell PPE magja egyébként is erős tévedés.

igen volt ilyen allitas. mibol gondolod, hogy tevedes? en abbol gondolom, hogy nem tevedes, mert
1.) tobb helyen ezt irtak szoszerint (akar a wikipedia-t is emlithetjuk)
2.) mindket mag - altalam olvasott infok szerint - in-order dual-issue ppc mag az IBM-tol 2005-bol.

a linkelt vitában már csak arról van szó, hogy az x86 CPUk jobbak, mint a Xenon

mondjuk szerintem nem egy kategoria a core 2 es a xenon (az elobbi javara), de teged hajt a te meggyozodesed ebben a kerdesben, - bar barmilyen benchmarkot eddig meg csak en csinaltam - ugyhogy hagyjuk

ha a Microsoftnak már 2005ben olyan jó H.264 lejátszó programja volt, vajon miért nem jelentette meg Windowsra is?

ott kezdodik, hogy 2007 tavaszan jelent meg xbox360-on a h.264 tamogatas. es mar meg sem emlitem, hogy az ffmpeg-nel konnyu volt gyorsabbnak lenni, mert sokaig csak egy szalon mukodott a libavcodec h.264 dekodere (most is meg sok esetben, na nem a patch-csel).

az tény, hogy a gcc jelenleg nem produkál hatékony kódot Xenonra, ezért az Xbox360ra hackelt linuxok nem futnak olyan hatékonyan xbox360on, mint PCn

biztos azert, es nem az in-order dual-issue mag miatt. azert itt is jol jonne egy osszevetes a gcc es a titkos microsoft ppc szuperfordito kozott elobb.

- Use the Source Luke ! -

na letorrenteztem ezt a vackot, bar soha nem fogom megnezni, mert nem erdekel :)

szoval nem tudom mit ertesz a CD nagyobb tesojan (core 2? 2GHz-s CD?), de a core 2 3.0GHz-n 2 threaddel ez a helyzet:

Input #0, matroska, from '/home/denes/jaj/The.City.of.Lost.Children.1995.HDTV.720p.x264-McFly/The.City.of.Lost.Children.1995.HDTV.720p.x264-McFly/The.City.of.Lost.Children.(1995).HDTV.720p.x264-McFly.mkv':
  Duration: 01:47:37.48, start: 0.000000, bitrate: N/A
    Stream #0.0(fre): Video: h264, yuv420p, 1280x688 [PAR 1:1 DAR 80:43], 25.00 tb(r)
    Stream #0.1(fre): Audio: 0x0000, 48000 Hz, 5:1, s16
    Stream #0.2(eng): Subtitle: 0x0000
    Stream #0.3(tur): Subtitle: 0x0000
    Stream #0.4(scr): Subtitle: 0x0000
Output #0, yuv4mpegpipe, to 'pipe:':
    Stream #0.0(fre): Video: rawvideo, yuv420p, 1280x688 [PAR 1:1 DAR 80:43], q=2-31, 200 kb/s, 25.00 tb(c)
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
[matroska @ 0x1ae8550]Unknown entry 0x1C53BB6Bme=6305.36 bitrate=264193.2kbits/s
[matroska @ 0x1ae8550]Unknown entry 0x114D9B74
frame=157691 fps=121 q=0.0 Lsize=203422314kB time=6307.64 bitrate=264193.2kbits/s
video:0kB audio:0kB global headers:0kB muxing overhead inf%

erdekes modon kozben a cpu terheles csak 130% korul volt (200% helyett), ugyhogy lehet, hogy ez az uj multithreading sem tokeletes meg. mindenesetre igy is a realtime 4-5-szorosevel ment, szoval akar a regi CD-den is lehet, hogy menne mar.

szerk: kivancsi vagyok valaki meg olvassa-e a szalat :)

- Use the Source Luke ! -

Mint emlitettem:
- ezzel a patch-csel mar ezen is elmegy, viszont ez meg egy honapja sem all rendelkezesre. Eddig per frame threadinget tudtommal csak coreav nyujtott (a pro valtozat) x86-on, a tobbi pedig slice based threadinggel barkacsolt. ffmpeg is.
- 3.0GHz-es C2D-n mar egy szalon futo player is gond nelkul viszi. Viszont az ket evvel ezelott, mikor a minimet vettem nem volt, ellentetben az ilyen kodolasu HD-vel.

---
pontscho / fresh!mindworkz

igen. en pusztan ellenoriztem, hogy egyes allitasod valoban igaz. igy tehat ez is lehet igaz.

- Use the Source Luke ! -

Nem arrol akarlak meggyozni, hogy a HD video rossz dolog, hanem arrol, hogy 1000 PS3/XBOX360 tulajdonosbol kb. 10 hasznalja arra, hogy dedikaltan HD tartalmat nezzen (a jatekok demoi nem szamitanak ide).

A Cell-el az a baj:
- A PS3-ba keszitett darab egyszeruen fostalicska desktop oprendszer futtatasara. Tudom, mert nekem itt van egy a nappalimban es telepitettem ra Linuxot. Jateknak jo, de erosen korlatozott a hasznalhatosaga.
- Masreszt a Cell nem eppen hatekony a (nem jatek) desktop alkalmazasokhoz. Browser, szovegszerkeszto, stb, stb.

A Cell celszerszam jatekgepbe es HPC teruletre. Masra nem igazan hatekony.

Ez teljesen érthető, ugyanis a CELL-t játékra tervezték. Játék terén sokkal jobb, mint a core2duo procik.

Tevedes, a Cell debutalasa valoban a PS3 volt. De sem az IBM, sem a Toshiba nem azert szallt be a projektbe, mert szerettek volna egy konzolprocit kesziteni, ok kokemenyen erdekeltek a HPC architecturakban, es egy lehetseges jovobeni irany ez lehet.

mondjuk úgy intenzív lebegőpontos számításigényű alkalmazásokhoz készítették:) csak ezt mostanában egy blurayyel megspékelt játékkonzol belsejében lehet gazdaságosan eladni a tömegeknek.
elméletileg a jövőben megjelenő Cellre optimalizált speciális fordítókkal javulhat a desktop alkalmazások végrehajtásának a sebessége is. mivel az eredeti tervek ellenére mégsem lett hivatalos melléklete a gnu/linux a PS3nak a gcc cell optimalizálása vélhetően eléggé lassú folyamat lesz.
a PS3 256Mb ramja pedig egyébként sem sok ma desktopra.
természetesen egy Niagarán akármilyen superoptimalizált fordítóval sem fog túltenni a Cell, de a jelenleginél sokkal jobb eredményt lehet elérni desktop appoknál ha a nem túl gyors PPE mellett az SPE magok is érdemben részt fognak venni a kód végrehajtásában. ez viszont igen igen bonyolult feladat, és sokat kell még fejleszteni a jelenlegi fordítókon.

Azért arra ne várj hogy megjelenik egy csoda fordító, és rögtön működik minden. Már arra is csak gyenge próbálkozások vannak, azok is többnyire erre kifejlesztett nyelveken, hogy pc-n automatikusan párhuzamos kódot készítsen az egyforma magokra. A Cell még nagyobb falat...

Cell-re nem csak gcc van, IBM is ad fordítót (illetve ők turkálták a gcc-t is). Egész egyszerűen a PPE ennyit tud. Erre is lett tervezve.

A Cell egy speciális processzor speciális feladatokra. Általános alkalmazások nem fognak rajta rendesen futni...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

viszont ha az spe magokat bevonják a végrehajtásba, akkor már sokat javulhat az általános alkalmazások teljesítménye. ez így elsőre eléggé meredek, mivel az spek lényegében vectorprocesszorok. eddig nem kellett ilyen problémákkal foglalkozni, csak a fordítottjával. hogyan hajtsunk végre lebegőpontos egység nélküli cpun ilyen számításokat igénylő algoritmusokat? és természetesen jóval kisebb hatékonysággal lehet általános programkódot spe egységen végrehajtani, de ez is több mint az egy szál ppe, ráadásul speből van 6, 7, ill. 8 db van belőle. egyik lehetőség újraírni cellre minden fontos általános alkalmazást. már csak azért is, mert kicsit pazarlóan használják a mai általános rendszerek a CPUk erőforrásait, OS és alkalmazás szinten egyaránt. de mára átlépte azt a mennyiséget ezen alkalmazások száma, hogy ezt érdemes legyen megcsinálni. így marad a fordító képességeinek növelése. ez viszont azért gigászi feladat, mert a probléma komplex, ráadásul soha nem kellett eddig ilyen fajta feladatot megoldani.

Fordito erre valo optimalizalasa egy dolog. Mert ott van meg a hardware komplexitasanak kerdese is, leven pl. az SPE _nem_ eri el a memoriat, csak a sajat par szaz kilobajtos memoriajaval gazdalkodhat. Ez altalanos celu szoftvernel olyan nehezites, ami kb. ertelmetlenne teszi az erofeszitest, viszont nem okoz problemat egy adatfolyamon periodikusan elvegzett muveletsornal.

---
pontscho / fresh!mindworkz

Hat igen, mind az automatikus vektorizacio, mind az automatikus parhuzamositas gyerekcipoben jar...

Pedig mindkettővel foglalkoznak okos emberek vagy 20 éve.

Igaz, hogy a probléma mostanság mégjobban előtérbe került, így valószínűleg még többen foglalkoznak vele, de azt senki ne várja, hogy a probléma a következő 5-10 évben megoldódik.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Egy atlag desktop felhasznalasra (Office, Browser) boven sok lenne a Cell-ben levo PPE, ha a Linux, es meginkabb a glibc PowerPC optimalizacioja nem konvergalna a nullahoz. Mig x86-ra sok helyen assemblyben megirt optimalizalt rutinok vannak pl. a stringmuveletekhez, memoriamasolashoz, addig PPC-re a C-ben irt generic kod fordul, ami persze forciklussal bytecopy. Nana', hogy lassu.

Van egy arc, aki a FreeVec projekt kereteben azzal foglalkozik, hogy az altalanos, libc-ben es masutt talalhato fuggvenyeket PowerPC-n assemblyben ill. AltiVec optimalizalassal megvalositsa. Vannak benchmark grafikonok az oldalan a generic implementaciokhoz kepest, hat, csunya... Viszont eddig a glibc-s arcoknak irt levelei, amiben a kodja integralasat keri kb. suket fulekre talaltak, valaszra is alig meltattak. Na ezert lassu a Linux, PS3-on. (Meg amugy barmilyen PPC-n, Efikatol G5-os PowerMacig... :/ )

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Ezzel tobbe-kevesbe egyetertek. Csak megjelenik az a bizonyos "Ha". Es ha meg megcsinaljak a tisztesseges implementaciot, akkor meg mindig ott marad a PS3 eseten a 3d gyorsitas hianya (ezt ugye a gameOS reszere engedelyezi a hypervisor), masfelol a 256 mega memoria sajnos szuk tud lenni. Bar ez a ketto pont nem a PS3 hibaja.

Mindenesetre oda jutottunk, hogy edesmindegy milyen csikszelesseggel gyart az IBM. Nem igazan tudja novelni a volumenjet, amig a komplett rendszer nem valik hasznalhatova.

Az SPE-k tudtommal elerhetok Linux alol is... Ha a PPE normalisan birna futtatni magukat az alkalmazasokat, az 1-2 SPE foglalkozhatna a framebufferben torteno videogyorsitassal, alfas bitmapok szamitgatasaval, ilyesmivel. Szerintem meg a compiznak is ertelmes sebesseggel kene rajta mennie, ha normalisan meg lenne irva, es nem csak "leforditjuk GCC-vel -O3-al, oszt jovan" kategoria lenne... A 256MB RAM persze keves mindenkeppen, ebben egyetertek.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

PS3-ban van ám videókártya is, bízzuk tán arra a compizt...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

... ezt ugye a gameOS reszere engedelyezi a hypervisor...

---
pontscho / fresh!mindworkz

Node ha tenyleg van egy ilyen konyvtar, akkor fogom lebuildelem, aztan LD_PRELOAD-dal betoltom.... Aztan le van sajnalva mindenki...

Vagy rosszul latom a dolgot?

45 nm ---> kb. 1,6 V tápfeszültség
22 nm ---> 0,6-0,7 V tápfeszültség ?

Most képzeljétek el azt a kapcsolóüzemű tápegységet ami mondjuk 0,7 V feszültség mellett lead 160-200 A áramerősséget. :-/ Ha el akarnak érni valamilyen értelmes hatásfokot akkor szabad jógázni a teljesítmény FET-ek csatornaellenállásának csökkentésén. Ha csak egy ezred Ohm-ot sikerül elérni, 200 A-nél akkor is 0,2 V a feszültségesés és ezzel 40 W a veszteség.

A tápellátás szerintem MVP :-) (másvalaki problémája) ebben az esetben...

    250nm 180nm 130nm 90nm  65nm  45nm  32nm  22nm
VDD 2.0V  1.8V  1.6V  1.4V  1.3V  1.2V  1.1V  ?.?V

Zsiraf

p.s.: remeljuk a 115W-os processzorok mar nem ternek vissza...
a power-ek meg talan sohasem mozogtak ezen a szinten

Reméljük a legjobbakat. :-)
Vajon milyenek lesznek az optikai CPU-k?
Fogsz egy szentjános bogarat és megvan a tápellátás?
Esetleg fluoreszkáló gomba? :-))

Vizelet? :) (világító fehér foszfor)

:-)