ÖÖÖÖÖÖ...
szinte semmit?

Az alvástól megéhezek,az evéstől elálmosodok.Így Macskasztikus az élet.

Szokásos értelmetlen Intel stratégia. Egyik kezével letiltja azokon a termékeken amiböl a legtöbbet ad el a másik kezével meg reklámozza. Sose fogja senki sem komolyabban használni amíg ilyen értelmetlen hülyeségeket művelnek..

[ Szerkesztve ]

Hát első ránézésre megörültem a grafikont látva hogy negyed annyi idő alatt végzett, mondom emmán döfi, aztán mikor megnéztem jobban láttam hogy az nemúgyvan
Hát ez így elég karcsú

Oke, vegyuk az AMD-t. Az XOP es az FMA4-et nem tiltja le az AMD, ehhez kepest hol vannak azok a szoftverek, amik kihasznaljak ezeket az utasitaskeszlet kiegesziteseket? Nem lehet, hogy nem is az Intel vagy az AMD hibaja, hogy a fejlesztok nem foglalkoznak ezekkel a post-SSE utasitaskeszlet kiegeszitesekkel?

Hát gondolom hogy annyira nem szeretnének újitani a kódon és beleölni lóvét miközben a hardvergyártók is elég felemásan támogatják. Nincs egy egységes utasitás készlet lista, egyik gyártó letiltja másik épp beteszi a legújabb termékébe amint irtad is.

[ Szerkesztve ]

Hmm... többre számítottam, ez elég kevéske.
Kíváncsi lennék egy, az AVX és az SSE *.* (<256 bites) utasításkészletekkel elérhető sebességek közti összehasonlításra is.

[ Szerkesztve ]

Pont azt irtam, hogy nem a CPU-gyartok tehetnek a problemakrol. Boven eleg AVX/AVX2/FMA-képes PC van piacon ahhoz, hogy ebben fantaziat lassanak a szoftverfejlesztok. Persze me'g jobb lenne a helyzet, ha a Celeronokban es Pentiumokban is engedelyezve lennenek ezek a feature-ok, es esetleg az Atomok is tamogatnanak AVX-et, de nem gondolom, hogy attol a szoftverfejlesztok hirtelen megmozditanak az ujjukat a billentyuzeten Az AMD-nel me'g lehet arra hivatkozni, hogy tul kicsi a piac, de az Intelnel azert a Core i3+i5+i7 kombinalt piac eleg nagy ahhoz, hogy ne lehessen a piac nagysagara hivatkozva figyelmen kivul hagyni.

De egyebkent a szoftverfejlesztok szemszogebol nezve is erdekes ez az egesz. Ok nagyjabol a 2000-es evek eleje ota egyre inkabb mozdulnak a menedzselt, egyre magasabb szintu nyelvek iranyaba, es egyre kevesbe van idejuk ill. kedvuk szoszmotolni az alacsonyabb szintu megoldasokkal, me'g akkor sem, ha teljesitmenyben elorelepest lehetne azoktol varni. Valoszinuleg nincs eleg fejleszto ezekkel foglalkozni, es/vagy nincs akkora haszna egy AVX/AVX2/FMA optimalizacionak, hogy megerje honapokat veszodni vele. Ha a C/C++ compiler automatikusan megcsinalja a vektorizaciot, akkor nyilvan annak orul mindenki, de ez mar nem az SSE szintje, itt nehezebb kerdesrol van szo, nem tol mindent a programozo s***e ala a compiler.

Az Intel inkább azzal törődne, hogy olyan pasztát kenjen a kupak alá, amivel ki is bírja a proci az intenzív AVX használatot.

A számítógép rendkívül alkalmas olyan feladatok megoldására, amelyek számítógép nélkül nem is léteznének!

2000-es evek eleje ota egyre inkabb mozdulnak a menedzselt, egyre magasabb szintu nyelvek iranyaba, es egyre kevesbe van idejuk ill. kedvuk szoszmotolni az alacsonyabb szintu megoldasokkal, me'g akkor sem, ha teljesitmenyben elorelepest lehetne azoktol varni.

CPU intenzív alkalmazásnál még csak rámozdulnának, ha legalább lib-es támogatást kapnak hozzá és jelentősen gyorsít a programon... de enélkül és +10-20 % sebességért kevesen fogják alkalmazni.

Éppen olvasok egy érdekes könyvet az antigravitációról... képtelen vagyok lerakni.

Ha lenne epkezlab konkurencia, lenne "penz" pasztara is

Elvileg az x264 pl használja... legalábbis én úgy tudom. (changelog tele van vele)

Intel baromság a köbön.Szeretné hogy terjedjen,de azért a procik nagy többségéken le tiltja.

Jól látom, hogy az elérhető gyorulás ~ a kicsit odafigyelősebb optimalizációval elérhető gyorulás kaliberében van

Izé...

Anno valamikor az ezres PIII-ak idején volt egy elhíresült eset, amikor a nagy K7/P3 háborúban az egyik Inteles szoftveresnek egy (két?) álmatlan éjszakájába került előcsalogatni a bemutatóra az intel cucc hajszálnyi előnyét valamelyik szoftveren - történt mindez egy új ICC verzió kiadásával, mer' ugye a csóka fordító-berhelő volt...

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

hát ha ennyire képes, akkor lehet kukázni az avx2-t...

Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"

Itt az eredeti cikk.

Sajnos nem preciz a szoveg. A PH!-cikkben linkelt diagram ennek a kiegeszitesekent ertendo:

A PH!-cikkben linkelt diagram a cikkben sugallt SSE vs AVX2 helyett AVX vs AVX2 novekedest abrazol.

AIDA64.com

Az a baj, hogy a 2000-es évek elején lehetett "bután" egy szálra programot írni úgy, ahogy megtanították ált. isk. számtech órán a programozást. Begin...If... End.
Egyszerűen azért mert évente jött egy 2x gyorsabb cpu.
Mellé viszont kényelmesebb és jóval költséghatékonyabb meglévő libeket használni vagy pl. portolhatósággal foglalkozni. Ill. csak szimplán magas szintű nyelvvel nem vért izzadni a tervezésnél.

Most viszont egyrészt nem jön, másrészt jó ideje ha jött is, az inkább magszámban, teljesítmény/fogyasztásban lépett előre. Ezzel a hajukra kenhetik a rég bevált módszereket és kódokat.
Az algoritmizálás vagy csak simán a többszálúsítás meg nem az a műfaj amit egy compiler megold okosba'. Ehhez már másképp kéne gondolkodni a kód írásakor.

Ugyanez van szvsz az új grafikus apiknál és a gpgpu/HSA kapcsán is. Hogy mit használnak azt továbbra is nyilván bevétel/költség hányados határozza meg, de egy idő után átbillen a mérleg. Egy szart* foltozgatni rövid távon olcsó, de hosszú távon megfordul az arány, főleg ha nagyot lehet szakítani benne sebességben. A kérdés mikor és hol érik el ezt a kritikus pontot. Elég ha egy cég meglátja és az beindítja a dominót egy piacon.

*Értsd alatta a halálgagyi, abszolút nem hatékony, 15 éves x86 kódot amit olcsóbb bottal piszkálni 15 évig. De ha újraírtad volna már rég visszahozta volna az árát.

Az ujrairasnal a legnagyobb problema az, hogy nem jott me'g el az a pont, amikor az ujrairassal valoban oriasit lehet lepni teljesitmenyben. Kiveve persze, ha egy 1 szalas, nem-SIMD x86 kodrol van szo, amit lehet tobbszalasitani + SIMD optimalizalni is.

A masik problema meg sokszor a kod merete, ill. annak a bonyolultsaga, hogy hogyan emelsz ki a nagy kodbazisbol kisebb reszeket, azt hogyan viszed at mondjuk egy mas nyelvre, mas fejleszto kornyezetbe. Pl. egy Delphi 7.0 koddal nehez barmit is kezdeni, anelkul, hogy ne nyulnal hozza radikalisan -- ha mar a Begin ... End-et emlegetted

Amíg a gépek 90+%-a nemhogy AVX2-t, de AVX1-et se tud, nem fog senki se rá optimalizálni, elég elborultnak kell lenni ahhoz, hogy a célközönség 10%-ánál 3% sebességbónusz jó befektetésnek mondja valaki.

Amíg az eladott Intel procik 80%-a (és ez által az összes eladás 70%-a) nem támogatja, addig ne mondja nekem senki, hogy nem az Intel tehet róla.

Hülye kérdés, de DP mátrixszorzásra nem inkább GPU-t lenne érdemes használni?

Szerintem pont ezt látod a grafikonon a cikkben.

DP-ben elég kevés GPU tud virítani, bár igaz, hogy még mindig valószínűleg jobb, mint CPUn tolni ugyanazt. Csak hát ugye GPU programozás kicsit bonyolultabb, mint elővenni a 2x hosszabb vektorutasításokat.

Azért szerintem az se mindegy, hogy itt V2 és V3 xeon-okat hasonlítanak össze.

| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'

Tisztában vagyok vele, hogy gyakorlatilag kuka lenne egy régi kód és teljesen újra kellene írni.
És az is tiszta, hogy nyilván a legtöbb átlagszoftvernél ez teljesen felesleges. Egy pacman meg egy könyvelőprogram elfut ugyanazzal a kóddal amíg világ a világ. Nincs teljesítménykényszer, már annyi se, hogy mondjuk egy sticken is elfusson. Azt is megoldották kód helyett hw-ből.
Maximum a kompatibilitás miatt kell pár évente ránézni.

Viszont vannak komolyabb programok amiket csak foltozgatnak 10-20 éve és alaposan ráférne a kukázás és komplett újraírás, aminek kézzelfogható hozadéka is lenne.

Legalábbis amit én láttam kódokat (nem sok) ill. látok programokat kód nélkül ugyan, de nem nehéz elképzelni mögötte az évtizedes kódot a sok régi megoldással, gui-val, stb... Szerintem ez általános, nem véletlen, hogy ősrégi nyelvek és hozzáértők is vígan élnek évtizedek után is egy-egy spec programból.
Szóval ezekből az látom, hogy már egy sima x86 újraírásra is bőven megérettek volna, nemhogy az "új" feature-ök kihasználására: több mag, gpu, de akár csak ősrégen velünk lévő utasításkészletek.

De máshogy látjuk úgy néz ki. Nekem lesújtó a véleményem úgy általában az sw minőségről és szerintem nagyon sokat lehetne javulni. Az újraírás vs foltozgatás meg inkább ott vérzik el, hogy a nyereség/költség hányadost baromi nehéz kiszámolni. Előre-utólag, kb. mindegy, csak becsülni lehet.
És persze a kisebb egyszeri befektetés itt is a könnyebb út mindig.

A képaláírás szerint "az AVX2 előnye az AVX-es kódhoz képest"
Az eredeti cikk annyit ír, hogy AVX2 disabled/enabled. Kérdés, hogy a kódban milyen utasításkészletet használnak, ha az AVX2-t letiltják - erről, ha jól látom, nem ír az eredeti cikk, de föltételezem, hogy nem AVX előtti (SSE*.*), hanem "sima" AVX-et.
Ha nem így van, az még kevésbé kedvező képet fest az AVXről.

#32 kraftxld
"Azért szerintem az se mindegy, hogy itt V2 és V3 xeon-okat hasonlítanak össz"

Tényleg nem:
E5-2697 V2 V3
magok/szálak 12/24 14/28
órajel/turbó (GHz) 2,7/3,5 2,6/3,6
L3 cache (MB) 30 35

A különböző procikkal elérhető nagyobb növekedés látszik a #24-esben mutatott grafikonon; és hogy ebből mennyi köszönhető az AX2-nek, azt emeli ki az a kép, amit a prohardveres cikk mutat.

[ Szerkesztve ]

"De máshogy látjuk úgy néz ki."

Az alapjan, amit ebben a postodban irtal, szerintem nem latjuk mashogy a dolgokat. Sajnos abszolut igaz az, hogy az archaikus kodot az esetek tulnyomo tobbsegeben nem eri meg radikalisan megvaltoztatni, mas nyelvre portolni, ujrairni, ujragondolni, az ugyanis nem csak rengeteg ido (es ezzel penz is, altalaban), hanem oriasi kockazat is. Ha pl. veszel egy 500 ezer soros forraskodot -- ami nem ritka a windowsos vilagban --, es atportolod egy masik nyelvre, masik fejleszto kornyezetre vagy csak ugy altalaban nagy reszet ujrairod, azzal potencialisan bugok sokasagat "hozod letre". Mint amikor az Apollo 11 startja elott arrol lamentaltak, hogy az parancsnoki modul 2 millio alkatreszbol all ossze, es ha sikerul 99,9%-os precizitassal legyartani es osszerakni, akkor is marad 2 ezer hibalehetoseg, amibol adott esetben egyetlen is a kuldetes (es esetleg az urhajosok eletenek) veget jelentheti. Nyilvan egy szoftver altalaban nem ennyire elet vagy halal kerdese, de ha egy cegvezetokent vagy "csupan" projekt vezetokent azt kell merlegelned, hogy rengeteg munkaval javitasz X %-ot a teljesitmenyen, es kozben kiteszed a QC csapatot is egy halom munkanak, es azt is kockaztatod, hogy me'g a rengeteg teszteles utan is egy sor potencialis uj bug keletkezik az "uj csoda edition"-ben; vagy maradsz a meglevo kodnal, ami lassabban fut ugyan, de amit a hosszu evek evolucioja soran viszonylag hibamentesre sikerult foltozgatni, akkor nem csoda, ha a legtobben az utobbi verziot valasztjak. Ez is az egyik oka annak, hogy sokan maradnak a regi Windowsoknal (hiaba jar(t) le a support), es hogy az x86 es a Windows me'g mindig ennyire tudja tartani magat a rengeteg uj operacios rendszer es CPU-architektura ostroma alatt is.

Vagy nezzuk a kerdest egy masik nezopontbol. Tegyuk fel, egy programozo vagy, akiknek a feladata az, hogy biztositsa, hogy a ceg altal fejlesztett szoftver minosege mindig magas szinten marad. Es ha az egyik ugyfel megis talal egy kisebb bugot, akkor kapsz abban a honapban 10 ezer Ft fizetes levonast; ha nagyobb bugot (show-stopper) talal valamelyik ugyfel, akkor pedig 50 ezer Ft fizetes levonast. Te mit valasztanal egy ilyen helyzetben? Foltozgatnal tovabb, vagy ujrairnad a felet a kodnak? Ami Neked 50 ezer Ft riziko, az a cegvezetonek 5 millio vagy 50 millio, esetleg 500 millio Ft riziko adott esetben. Nem csoda, ha senkinek sem all tulajdonkeppen erdekeben megbontani a "status quo"-t.

Két különböző dologról beszélünk.
- Én a kódok minőségéről és hogy előre lehet-e lépni benne, akár teljesítményben akár csak technológiailag és ez jár-e esetleg gazdasági előnnyel is. Ez tisztán szakmai kérdés.
- Te pedig arról írsz, hogy miért nem teszik ezt meg fejlesztők, cégek, vezetők. Ez az emberi, pszichológiai és (ál)gazdasági tényező.

Attól, hogy:
- félnek
- nem tudják felmérni milyen kockázatokkal jár
- milyen előnye lehet
- megéri-e (ezt nehéz belőni mert mozognak az igények, piac, versenytársak... és nem csak abszolút hozama lehet, hanem relatív is, amikor kevesebbet buksz, lásd Bici példáját...)
- vagy esetleg még látják is, hogy megéri hosszú távon, de leszrják és csak a rövid távú költségekre koncentrálnak, stb...
...még simán megérheti és indokolt lehet a váltás. Ezeknek nem sok köze van a szakmai/gazdasági kérdésekhez. Bár tény, hogy valós tényezők és igazad van abban, hogy ezek (is) számítanak. Sajnos.