32
-
coolbboy83 #1 Foteleket elő :-) Go Flame :-)...
Kezdem:
A HP-nál csak is hülyék és hűlyék dolgoznak :-D -
kvp #2 Minta a hp nem arulna mar most is tobble architekturat. Van x86-os es itanium-os szerver is, de az x86-osokban is mips alapu halozati segedprocesszorok vannak. Ezt regebben kiegeszitettek az nvidia vektoros gyorsitoival, most jon az arm is. Se nem meglepo, se nem tul erdekes. Egy linux-os szervernel nem igazan szamit, hogy x86-os vagy arm-os, esetleg sparc vagy powerpc, a programokat a legtobb esetben nem igazan erdekli vagy zavarja az adott architektura. Annyi valtozik, hogy a jovoben mar a windows-os szervereket sem fogja zavarni ha veletlenul arm-ra kerulnek. -
Komolytalan #3 "Egy linux-os szervernel nem igazan szamit, hogy x86-os vagy arm-os, esetleg sparc vagy powerpc, a programokat a legtobb esetben nem igazan erdekli vagy zavarja az adott architektura."
A programokat nem, csak azokat, akik szeretnék használni a szervert. Egy x86 vagy ARM teljesítményben nem igazán összehasonlítható per pill. Az ARM hurráoptimista becsélése szerint majd valamikor a távoli jövőben lesz az összes szerver feladat 10%-a olyan, amire az ő portékájuk megfelelő. -
kvp #4 Ha van egy x86-os, 4 magos processzor, az egyszerre 4 (hyperthreading-gel 8) feladatot tud vegezni. Ez a diszk i/o blokkolo hatasa miatt lehet akar 16 is. Ha van 64 felhasznalo a szerveren akkor ez 4-es load-ot fog jelenteni, tehat lassunak tunik a gep. Ezzel szemben ha van 64 felhasznalo es van ra 32 arm mag, akkor a szerveren i/o val egyutt 0.5-os load lesz, tehat a felhasznalo azt latja, hogy gyorsabb a gep. Egyebkent mivel egy high end arm-os cpu kepes kivaltani egy low end x86-ost, ezert mar desktop feladatokban is megkozelitik az x86-ok teljesitmenyet. A szerveres feladatok pedig tipikusan olyanok amiben a sok mag, kisebb orajel jobb mint a keves mag, magas orajel.
Egyebkent az meg mindig igaz, hogy egy egymagos x86-os core sorozatu cpu azonos orajelen kb. 3-4-szer gyorsabb mint egy modern arm. Egy 4 magos 1 Ghz-es arm kb. tudja hozni egy egy magos 1 Ghz-es core teljesitmenyet (amennyiben a felhasznalt szoftver kihasznalja vagy tobb dolog fut egyszerre). Mivel pl. az android multimedias kornyezete ugy van kitalalva, hogy sima hang lejatszasnal is 3 magot tud egyszerre hasznalni, videonal 4-et, ezert ha a programozo a gyari komponenseket hasznalja, akkor automatikusan tobbszalu programot irt. (ebbol 1 a normal program, 3 a hatterben futo rendszer szal)
ps: Arm-on futo android-hoz van x86 emulator. Mar eppen hasznalhato sebesseggel fut rajta az x86-os kod, pedig hardveres gyorsitas nelkul megy. Ha lenne jit is, akkor meg jobb eredmenyt hozna. Innentol x86-rol arm-ra valtani kb. olyan lenne mint amikor az apple ppc-rol x86-ra valtott. (egyebkent van ra esely, hogy a jovoben desktopon is atallnak arm-ra a nem profi /=consumer/ rendszereiknel) -
Komolytalan #5 "Ha van egy x86-os, 4 magos processzor, az egyszerre 4 (hyperthreading-gel 8) feladatot tud vegezni. Ez a diszk i/o blokkolo hatasa miatt lehet akar 16 is. Ha van 64 felhasznalo a szerveren akkor ez 4-es load-ot fog jelenteni, tehat lassunak tunik a gep. Ezzel szemben ha van 64 felhasznalo es van ra 32 arm mag, akkor a szerveren i/o val egyutt 0.5-os load lesz, tehat a felhasznalo azt latja, hogy gyorsabb a gep."
Juj-juj-juj... ezt a mellémagyarázást. Nézzük sorban:
- Egy x86 mag durván 10x gyorsabb mint egy ARM mag. Ez köszönhető az órajelbeli eltérésnek, a jóval magasabb cache mennyiségnek, és annak, hogy az x86 elemi műveletként bonyolultabbakat tud elvégezni, mint az ARM (pl lebegőpontos részt meg lehet nézni).
- Egy normális oprendszer legalabb ezredmásodpercenként 1x újraosztja a szálak között a processzort, mint erőforrást. Vagyis ha egy 4 magos processzoron 5 szál fut, akkor attól az még nem válik reakcióképtelenné. A load egy nagyon gyorsan számolható, és nagyon buta mérőszám. Csináltam média szervert, amely pikk-pakk 40-80-as loadra ugrasztotta a szervert, de a streaming ettől függetlenül folyamatos volt. Pedig a video streamingnél azért elég hamar látnom kéne a lassulást, akadozást.
- Arról az ARMnál mindig szemérmesen hallgatnak, hogy memória, az egy van ám. És egy memóriát legjobban egy mag tud használni - onnan kezdve hogy növeljük az erre akasztott magok számát az össz teljesítmény koránt sem lineárisan nő. Vagyis egy 64 magos ARM rendszer össz teljesítménye mondjuk egy 4 magoséhoz képest nem 16x lesz, de jó ha a 8x-et eléri.
"Egyebkent mivel egy high end arm-os cpu kepes kivaltani egy low end x86-ost, ezert mar desktop feladatokban is megkozelitik az x86-ok teljesitmenyet."
Létező processzorokról beszéljünk. A létező ARM procik egy eleve k.rva lassú, és évek óta nem fejlődő Atom proci sebességét se érik el. Lebegőpontos számításban pláne nem. Fogyasztásban jobbak, de ez az egyetlen előnyük.
"A szerveres feladatok pedig tipikusan olyanok amiben a sok mag, kisebb orajel jobb mint a keves mag, magas orajel."
Ez nem csak szervereknél, de sehol az ég világon nem igaz. A sok mag az állandó blokkolás, cache ürítés, memóriára várakozás. 4db 1Ghz-s mag felér 1 db 2Ghz-s maggal, de 1 db 3Ghz-s maggal már nem mindig. És itt még csak 1 vs 4-ről, nem 4 vs 64-ről beszéltünk.
"Egyebkent az meg mindig igaz, hogy egy egymagos x86-os core sorozatu cpu azonos orajelen kb. 3-4-szer gyorsabb mint egy modern arm."
"Arm-on futo android-hoz van x86 emulator. Mar eppen hasznalhato sebesseggel fut rajta az x86-os kod, pedig hardveres gyorsitas nelkul megy. Ha lenne jit is, akkor meg jobb eredmenyt hozna. Innentol x86-rol arm-ra valtani kb. olyan lenne mint amikor az apple ppc-rol x86-ra valtott."
Feltételezve hogy egy JIT fordító azért nem lesz olyan hatékony, mint egy AOT fordító, ráadásul a JIT fordító is prociidőt fogyaszt, mondhatjuk azt, hogy azonos órajel és magszám mellett 1/4 sebesség a max, ami elérhető (és szerintem ez durván hurrá optimizmus). Ezzel nagyjából el is veszne az "azonos teljesítményt, alacsonyabb fogyasztásból" című előny is - amely eleve csak nagyon alacsony teljesítményen él, mert magasat az ARM egyszerűen nem tud. Nekem ebből nem az jön le, hogy érdemes volna váltani. -
kvp #6 "- Egy x86 mag durván 10x gyorsabb mint egy ARM mag."
Azonos orajelen kb. 3-4-szer gyorsabb.
"Csináltam média szervert, amely pikk-pakk 40-80-as loadra ugrasztotta a szervert"
Akkor nem tudsz kodot irni. 80-as load azt jelenti, hogy 80-szor tobb szal vart futasra/futott mint ammenyi magja van a gepnek. A busy wait es az os task switcher-enek hasznalata blokkolo muveletek helyett a letezo leg pazarlobb megoldas, bar ha a task switch overhead alacsony vagy sok a cache, akkor nem tunik fel a felhasznaloknak, hogy folyamatosan 100%-on jar az osszes mag. (a villanyszamlat viszont jobb nem nezni) Ha nem akarunk allandoan kapcsolgatni, akkor viszont blokkolo muveletekkel sokkal optimalisabb rendszert lehet kesziteni, ami alacsoynabb orajelen es keves cache melett is jo teljesitmenyt ad. Kodolni tudni kell, mondjuk legalabb a 60-as/70-es evek szintjen, az mar eleg fejlett tudas az emlitett feladathoz.
"Arról az ARMnál mindig szemérmesen hallgatnak, hogy memória, az egy van ám."
Mivel hogy tobb van. Mar pc-kben is 2-3 fuggetlen memoiravezerlo van, videokartyak eseten van amikor 8 vagy 16 fuggetlen memoriamuvelet megy ki egyszerre. A megoldas hatranya, hogy neha akar 16 egyforma ram kartya/chip kell a mukodeshez, elonye, hogy teljesen fuggetlenek egymastol es ha jol van kialakitva az interleave es kozos az L3 cache, akkor kozel linearisan no a memoria teljesitmenye.
"Létező processzorokról beszéljünk. A létező ARM procik egy eleve k.rva lassú, és évek óta nem fejlődő Atom proci sebességét se érik el. Lebegőpontos számításban pláne nem. Fogyasztásban jobbak, de ez az egyetlen előnyük."
Letezo processzor van a telefonomban es megfelelo a sebessege. Egy netbook-ba eleg egy atom is vagy egy atlag mai 1-2 magos arm. Viszont egy 4 magos arm meg mindig kevesebbet fogyaszt mint egy 2 magos atom es kozel azonos a teljesitmenyuk.
A lebegopontos szamitasok az a terulet ami ma nem igazan szamit. Szerver oldalon nem nagyon hasznaljak, mivel uzleti logikanal bcd kell a penzugyek miatt (lasd pl. oracle number format), az alap szerver funkciokhoz (pl. webszerver) pedig eleg a sima integer aritmetika is, amiben az arm-ok ugyanolyan jok mint az x86-osok. Kliens oldalon a grafikahoz nem kell lebegopontos teljesitmeny, azt a videokartya kezeli, a media dekodolashoz vannak dedikalt (fixpontos) utasitasok, mig a os logika tovabbra sem igenyel csak sima integer aritmetikat. Minden egyes lebegopontos szamitasra jut par ezer integer/logikai/load/store muvelet.
"Feltételezve hogy egy JIT fordító azért nem lesz olyan hatékony, mint egy AOT fordító, ráadásul a JIT fordító is prociidőt fogyaszt, mondhatjuk azt, hogy azonos órajel és magszám mellett 1/4 sebesség a max, ami elérhető (és szerintem ez durván hurrá optimizmus)."
Mivel a mai rendszerekben a kod terulet ritkan valtozik (tobbnyire betoltes utan mar read only) es valtozo adatterulet nem hajthato vegre (lasd: data execute prevention), igy a jit gyakorlatilag a kod betoltesekor tortenik, tehat a program inditasakor. Innentol egy sima nativ kod fut. Android eseten ez az atallas 10x-es sebesseg novekedest hozott. Ez technologia a run time branch prediction hianya miatt kb. 50%-os emulacios sebesseget tud hozni altalanos uzleti logikanal, mig kozel 80%-ot vektoros integer feladatoknal (multimedia).
Valtani pedig annyiban eri meg, hogy olcsobban, kevesebb energiafelhasznalassal lehet ugyanazt a teljesitmenyt kapni. Ugyanugy ahogy megerte a processzoron zaljo szoftveres 3D renderelesrol atallni a videokartyak altal biztositott ugyancsak szoftveres, de proci fuggetlen 3D renderelesre. Vagy amiert a HP x86-os szervereiben mips-es halozati gyorsitok vannak (lebegopontos egysegek nelkul), mivel igy kis befektetes (arnovekedes) az adott feladatnal nagy teljesitmenynovekedest hozott. -
#7
Az ARM-nél nem szabad arról megfeledkeznünk, hogy ők egészen a netbook-ok megjelenéséig nem igazán a PC-s piacra gyártottak, hiszen procijaik nem a teljesítményükről, hanem az igen alacsony fogyasztásukról és piszok alacsony árukról lettek híresek.
Várható volt, hogy előbb vagy utóbb más piacra is bekacsintanak, bár azért a netbook-ok után kicsit nagy lépés egyből a szerveres piacra lépni, kihagyva a PC-s procikat.
Ez lehet egy igen nagy sikertörténet kezdete is de könnyen lehet egy hatalmas bukta előjátéka is. -
kvp #8 Az elso arm-os pc-t meg 1987-ben adtak ki, szoval nem eppen kezdok...
Egyebkent erdekes hir:
http://www.eetimes.com/electronics-news/4230166/AMCC-demos-64-bit-ARM-server-chip
Ez 64 bites, quad core, quad issue, 3Ghz, tehat egy core2 quad teljesitmenyet hozza, egy mobitelefon arabol egy fogyasztasaval. A rendszerbusza pedig 80 GByte/sec-es ami a jelenleg legjobb intel szerver procik 100 GByte/sec-jehez kepest jo. Egyebkent a ceg fo terulete a halozati chipek, tehat ez a cpu is inkabb router-ekben es cluster node-okban jelenhet meg a jovoben. (lasd: felho szolgaltatasok)
Egyebkent az arm nem tud nagyot bukni a dolgon, ok csak licenszelnek, tehat megtervezik aztan aki legyartja fizet nekik reszesedest a forgalmabol. Ha nincs forgalom akkor legfeljebb a polcon marad a design, de eddig mindet megvette jopar ceg, tehat eleg nagy hasznot hoztak. -
Doktor Kotász #9 Ha ez az egész nem arról szól, hogy csináljunk egy céget, aminek a sok balek bedőlve felhajtja az árfolyamát, amin kurva sokat kaszálunk, akkor valami lehet az ARM tarsolyában, amiről még nem tudunk.
Mert az kizártnak tartom, hogy sík hülyék lennének, meg azt is, hogy a kéziszémítógépekbe meg mobiltelefonokba szánt lófaszjóska procik lealáznák a szerverüzletágat.
Mert kábé ennek annyi értelmne van, mintha én megvenném a C64 jogait, és nagy mellénnyel a puklikum elé állva azt állítanám, hogy felépítek egy olyan szervert a 6501-es processzorokból (ez volt a C64-ben?), amiben 10 a hatszászhuszonnyolcadikon darab C64-es van, és ezzel három nap alatt kitudom számoltatni a gyökkettőt három tizedesjegyik, és most reszkessen az egész informatikai iparág, mert ez a jövő. -
Vers #10 :XD
lattal mar kozelrol armot? 100-szor gyorsabb egy intel proci mint egy arm szar
intel mag 5 ghz, hyperthread, 32MB cache , altalaban 4-6 mag
memoria atvitel 25GB/sec+
arm 1-2 mag 1 ghz , 1 MB cache,2-4 GB/sec memoria atvitel
se elagazasbecsles, se hyperthread, neha meg outorder sincs, 32 bites,a NEON vektor csoport 2 muvelet / orajel
ne rohogtesd ki magad :)
-
Vers #11 a mai szerverekben mar nvidia duborog, legalabbis a jobbakba, meg az intel sem versenykepes, arm b+ rohogogorcsot kapok komolyan
a sok idiota elhiszi hogy az ipad-ba pc szintu processzor van, meg ebbul lesz a szerver:XDDD -
Vers #12 a JITes elmeleted sem allja meg a helyet, sajnos napjainkban a jites mukodes joval lassabb mint 50%, ez a kodforditas, es memoria takaritas miatt van, igen nehezen parhuzamosithatoak ezek a folyamatok, probald megirni :), es emiatt magas frekvencia szukseges az elvezheto mukodeshez, a tobb mag nagyon nem alternativa
a gpu-s renderelesed sem allja meg a helyet, 1.5GB memoriaval rendelkeznek ezek a gpu-k, ami hamar betelik, es ha tulcsordul akkor a gpu-nak vege vanes lelassul processzor szint ala, csak erdekessegkeppen az avatarnal a renderelok meghaladtak az 1 exa byteot ami 1 millio terabyte
-
Komolytalan #13 ""- Egy x86 mag durván 10x gyorsabb mint egy ARM mag."
Azonos orajelen kb. 3-4-szer gyorsabb."
De nem azonos az órajel, nem azonos a cache méret - semmi se azonos. Ráadásul míg ARM architektúra kifullad 1Ghz környékén, addig az Intel már 3-4Ghz között jár.
""Csináltam média szervert, amely pikk-pakk 40-80-as loadra ugrasztotta a szervert"
Akkor nem tudsz kodot irni. 80-as load azt jelenti, hogy 80-szor tobb szal vart futasra/futott mint ammenyi magja van a gepnek."
Félreérthető voltam: a kód alapját nem én írtam, hanem az a fazon, aki a livejasmine szerver oldalát csinálta - nyilván nem ért hozzá. Egyébként meg de, mert 64K-s jar fájlból csinált rtmp szervert, ami azért nem sz.r a konkurensek méreteit és teljesítményét alapul véve. Egyébként a 80-as load papíron azt jelenti amit írsz, a gyakorlatban meg sajnos olyan processeket is beleszámol a load, amely csak "pár" utasítást hajt végre mondjuk 0.00001msec alatt, és utána elengedi a procit. Bár lehet hogy a jelenlegi kerneleknél ez már nem így van - 5 éve még így mutatta. 100-as loadnál még teljesen jól reagált ssh alatt a szerver, a max amit láttam putty-ban az valami 1002-es load volt (és ott még el tudtam indítani a lekapcsoló sh-t).
""Arról az ARMnál mindig szemérmesen hallgatnak, hogy memória, az egy van ám."
Mivel hogy tobb van. Mar pc-kben is 2-3 fuggetlen memoiravezerlo van, videokartyak eseten van amikor 8 vagy 16 fuggetlen memoriamuvelet megy ki egyszerre."
Na persze, és ha ugyanarra a memória területre hivatkozna 2 mag - mondjuk egy globális változó területre - akkor mi van? L1 biztos nem maradhat - piha, pár 1000 ütemciklus míg újratölti a szuper memória vezérlő. Márpedig a proci sebességéhez már az L3 is elég messze van, nemhogy a memória.
"A lebegopontos szamitasok az a terulet ami ma nem igazan szamit. Szerver oldalon nem nagyon hasznaljak, mivel uzleti logikanal bcd kell a penzugyek miatt (lasd pl. oracle number format), az alap szerver funkciokhoz (pl. webszerver) pedig eleg a sima integer aritmetika is, amiben az arm-ok ugyanolyan jok mint az x86-osok."
Minden adatbáziskezelőnek van fix pontos, lebegő pontos, és egész típusa. Ez durván semmit se bizonyít. Ami számítás igényes az nem egy számla összeg aggregálás, hanem pl egy üzleti szimuláció, amihez meg vastagon kell a craft, így lebegőpontosban számolnak.
"Kliens oldalon a grafikahoz nem kell lebegopontos teljesitmeny, azt a videokartya kezeli, a media dekodolashoz vannak dedikalt (fixpontos) utasitasok, mig a os logika tovabbra sem igenyel csak sima integer aritmetikat."
Sokmindent meg lehet csinálni egész számítással, mert pl egyenes rajzoláshoz se kell lebegő pontos, hiába hogy mondjuk a Bresenham algoritmust azt használ. Viszont egész számításból egy lebegőpontos kiváltásához sokkal több műveletet kell használni, mindig. Vagy pedig elveszik a pontosság.
"Minden egyes lebegopontos szamitasra jut par ezer integer/logikai/load/store muvelet."
Ez max 486-on volt így (még ott se 100-es nagyságrend volt az igaz, hanem a 100-as).
"Mivel a mai rendszerekben a kod terulet ritkan valtozik (tobbnyire betoltes utan mar read only) es valtozo adatterulet nem hajthato vegre (lasd: data execute prevention), igy a jit gyakorlatilag a kod betoltesekor tortenik, tehat a program inditasakor. Innentol egy sima nativ kod fut."
Na igen, de ha az az indítás 5 percig tart - ameddig ARMon egy közepes méretű alkalmazást fordítana egy AOT fordító - akkor azt lehet nem várja ki az user. Ezért kell a JIT fordítónak gyorsnak, és ezzel együtt nem túl hatékonynak lennie. -
coolbboy83 #14 Hol van az Intelnek 5 Ghz processzora ? Melyik model az ? -
Rotyoka #15 A felhúzott Celeron :D -
Komolytalan #16 Jó, de nézd meg miért olcsó egy ARM mag: mert olyan egyszerű, hogy kb 1 mm2 a területe. Nincs benne se cache, se komoly prefetch, se semmi, és mégis csak 1Ghz környékén mozog. -
Komolytalan #17 Na igen, de azt se felejtsd el, hogy az a csoda ARM 64 bit az elég komoly átb.szás. A magok 32 bites címzést tudnak, és az L2 cache vezérlőbe integrált külön egység mutatja meg nekik a memóriából az ő 4G-jukat (amúgy 40 bites az a 64 bites címzés valójában, de ez végül is tökmind1). Ez a megoldás hasonlít a linux PAE kerneles mókájához, ami elég komoly kalap sz.r volt anno. -
coolbboy83 #18 Honnan tudod, hogy átbaszás ? Náluk dolgozól ?
http://www.eetimes.com/electronics-news/4230166/AMCC-demos-64-bit-ARM-server-chip
Várjuk ki milesz, mert szerintem itthon ezt a szakmát senki nem tudja annyira, mint akik ezeknél dolgoznak, és elég nagy nevek vannak az ARM mögött...
Ki tudja miket varázsolnak elő, de azt sem tudhatjuk az Intel mit varázsol még elő... biztos vannak jó dolgok talomban még :-) -
#19
Ez a teljesítmény az eddigi felhasználási területeken bőven elég is volt, éppen ezért mondom, hogy nagy lépés ez számukra.
Egyébként kisebb feladatokhoz el tudnék képzelni egy ARM procis szervert, legfeljebb először a régi jó sok proci kis helyen is elfér módszer szerint kellene gondolkozniuk, míg valami komolyabb teljesítményű prockót ki nem fejlesztenek. -
#20
Megbocsáss, de elég nehezen adhattak ki '87-ben bármit is ARM procival, mikor a cég csak 1990-ben alakult meg, továbbá az első processzorukat csak 1994-ben adták ki ARM7 néven...
Ha nekem nem hiszel, nézd meg az ARM honlapját, ott ők maguk vezetik le a cég és a termékeik történetét. -
kvp #21 "Megbocsáss, de elég nehezen adhattak ki '87-ben bármit is ARM procival, mikor a cég csak 1990-ben alakult meg, továbbá az első processzorukat csak 1994-ben adták ki ARM7 néven..."
Az arm7 mar a 7. valtozata az arm csaladnak, de a wikipediat elolvasva:
"ARM is a 32-bit reduced instruction set computer (RISC) instruction set architecture (ISA) developed by ARM Holdings. It was named the Advanced RISC Machine, and before that, the Acorn RISC Machine. The ARM architecture is the most widely used 32-bit ISA in numbers produced. Originally conceived by Acorn Computers for use in its personal computers, the first ARM-based products were the Acorn Archimedes range introduced in 1987."
Szoval az, hogy a ceges honlapon elfelejtik megemliteni honnan jonnek nem jelenti azt, hogy a mult nem tortent meg.
"Félreérthető voltam: a kód alapját nem én írtam, hanem az a fazon, aki a livejasmine szerver oldalát csinálta - nyilván nem ért hozzá. Egyébként meg de, mert 64K-s jar fájlból csinált rtmp szervert, ami azért nem sz.r a konkurensek méreteit és teljesítményét alapul véve."
Sajnos volt szerencsem az emlitett kodhoz, tovabbra is azt allitom hogy nem tul jo megoldas, mivel az adott feladatra a tenyleges load joval alacsonyabban tarthato. Altalam keszitett hasonlo kismeretu szerver (http alapu mpeg stream-eleshez) kepes volt alacsony load-on maradni hasonlo user szamnal. A kulonbseg az i/o muveleteknel a blokkolo es a nem blokkolo muveletek hasznalata kozott van. Sehol nem erdemes busy wait-et vagy rovid blokkolast hasznalni, hanem tobb handle-os poll-al kell blokkolni a lehetseges esemenyekre (blockingqueue). A kod nem lesz hosszabb, de a szervert kevesbe terheli. Szemelyes velemenyem, hogy a sracok egyebkent nem mindig jarnak a legalitas talajan... (jogi es nem fejlesztoi szemszogbol)
"Na persze, és ha ugyanarra a memória területre hivatkozna 2 mag - mondjuk egy globális változó területre - akkor mi van? L1 biztos nem maradhat - piha, pár 1000 ütemciklus míg újratölti a szuper memória vezérlő. Márpedig a proci sebességéhez már az L3 is elég messze van, nemhogy a memória."
Az elso olvasasi muvelet atmegy a ram-ig, a tobbi mar a kozos cache-bol dolgozik. A cache koherenciara pedig tobb megoldas is van, a leggyakoribb a processor interconnect-en kimeno update uzenet, ami szinkronban tartja az L1 cache-eket is.
"Sokmindent meg lehet csinálni egész számítással, mert pl egyenes rajzoláshoz se kell lebegő pontos, hiába hogy mondjuk a Bresenham algoritmust azt használ."
Ezeket mar jo ideje nem a cpu szamolja, hanem a gpu. Tehat a cpu lebegopontos egysege gyakorlatilag az ido jo reszeben malmozik... Nem veletlen, hogy a mai x86-osokban sincs dedikalt lebegopontos hardver, hanem a vektoros egyseg kepes emulalni a regi hagyomanyos lebegopontos mukodest. (valamivel lassabban, mivel mikrokodbol megy)
"a gpu-s renderelesed sem allja meg a helyet, 1.5GB memoriaval rendelkeznek ezek a gpu-k"
Olvasd el a Carmack fele megatexture technologia leirasat. Arrol nem beszelve, hogy a szamitasi celra dedikalt nvidia gpu chipek joval tobb ram-ot tudnak kezelni. Csak ezek nem az otthoni felhaszalasra szant kartyakba kerulnek.
""Minden egyes lebegopontos szamitasra jut par ezer integer/logikai/load/store muvelet."
Ez max 486-on volt így (még ott se 100-es nagyságrend volt az igaz, hanem a 100-as)."
A 486-ok kora ota rengeteg dedikalt hardver kerult a gepekbe (pl. gpu-k), ezert a kozponti processzor manapsag mar sokkal kevesebb lebegopontos muveletet vegez, mivel nincs ra szukseg. Egyebkent meg anno is elvolt a gepek egy resze lebegopontos egyseg nelkul. (sx csalad)
"Na igen, de ha az az indítás 5 percig tart - ameddig ARMon egy közepes méretű alkalmazást fordítana egy AOT fordító - akkor azt lehet nem várja ki az user. Ezért kell a JIT fordítónak gyorsnak, és ezzel együtt nem túl hatékonynak lennie."
A forditas nagyobbik resze a szovegfeldolgozas es a szimbolumtabla kialakitasa. A tenyleges gepi kod leforditasa (az assembly fazis) nagyon rovid. Egy jit fordito eleve az egyik gepi kodbol fordit a masikba, tehat meg egyszerubb feladata van. Az android-os keszulekekben ujabban mar jit fordito van a java-hoz es pillanatok alatt tudnak a dalvik vm es arm kozott forditani. X86-rol arm-ra sem nagyobb feladat, bar az x86-os cpu-k altal mikrokodozott utasitasok relative sok ram-ot foglalnak, de a kod merete az adatokhoz kepest manapsag mar elhanyagolhato.
"sajnos napjainkban a jites mukodes joval lassabb mint 50%, ez a kodforditas, es memoria takaritas miatt van, igen nehezen parhuzamosithatoak ezek a folyamatok, probald megirni"
Az android jit-je betolteskor fordit, tehat programinditasonkent egyszer. A szemetgyujto pedig relative ritkan fut (neha csak tobb masodpercenkent), tovabba rengeteg elozetes info van a program file-okban, igy sok valtozo mar eleve lokaliskent mukodik, azaz nem szemetgyujtott teruletre kerul, hanem a szokasos c-s eletciklust koveti. (igen, pl. a jni mukodese e miatt par helyen elter a szabvany java-tol, viszont az egesz sokkal gyorsabb, bar igy kepes a java-s kod is vedelmi hibat okozni, ami biztonsagi szempontbol gond)
Az intel es az arm processzorok kozott az orajelelterest a gyartastechnologia okozza. Azonos technikval egy arm ketszer magasabb orajelre kepes mint egy x86-os, bar a modern x86-os cpu-k 3-4-szer tobb utasitast tudnak vegrehajtani azonos orajelen, ezert van meg mindig egy kb. 2-szeres elonyuk. Viszont az arm-ok olcso gyartasa, a tobb mag elhelyezese ugyanakkora mereten lehetove teszi hogy nyers eroben jobbak legyenek. Egy nvidia gpu kartya is erosebb egy x86-osnal, csak tul specializalt az altalanos celu mukodeshez. Egy arm valahol a ketto kozott van, tehat megvan a gyors mukodes lehetosege es a nyers ero, de megvan az altalanos cpu tudasa is. Egy arm alapu szerver valahol a ket szelsoseg kozott van teljesitmenyben, tehat egy altalanos x86-os szerver es egy specializalt nvidia gpu cluster kozott. Arban viszont joval mindketto alatt. Egyebkent jopar beagyazott szerver most is arm alapu, pl. a legtobb dedikalt video streaming szerver alapja is arm-os router hardver, csak az emberek altalaban nem tudjak mi van a dobozban. -
Komolytalan #22 Amiről én beszéltem arról nem egy gagyi újságban olvashatsz, hanem a "hogyan programozzunk arm8 chipet" című könyvben. -
Komolytalan #23 Na persze, csakhogy eddig kerestek megfelelő felhasználási területet a harmatgyenge chipjükhöz. És igen, szerver környezetben is elékpzelhető ARM processzor, mondjuk egy routerben. Aztán ezzel kb vége is a felsorolásnak. Ők maguk is arról beszélnek hogy majd 5-10 év múlva a feladatok 10%-ára lesz alkalmas az évente duplázódó sebességű(lol) ARM processzor. Ez így minden hurráoptimizmussal is elég gyenge ahhoz, hogy az Intel minimálisan is aggódni kezdjen. -
Komolytalan #24 "Sajnos volt szerencsem az emlitett kodhoz"
Utána meg beleért a kezed a bilibe, és felébredtél.
"Ezeket mar jo ideje nem a cpu szamolja, hanem a gpu."
A GPU az az, amire 2 vinyó tápkábelt is rá kell nyomni, az alaplapról nem tud elég energy-t felvenni? Így aztán megmarad a fogyasztásbeli előny...
Egyébként olyan régen nem számolja ám a GPU, mert mondjuk az általad emlegetett Oracle se használja azt (majd a 18.0-nál, talán, közvetlenül az autoincrement bevezetése után). SQL szerverből ami használ GPU-t az egyedül a PostgreSQL, de annak is csak egy alpha/beta változata, és csak tárolt eljárásban programozhatod a GPU-t, kifejezetten erre szolgáló utasításokkal. Vagyis a normál SQL lebegőpontos utasításokat a GPU egy mákszemnyit sem gyorsítja. Persze lehet hogy fogja, 2-3 windows meg 5 év múlva, talán. Addig azért én nem veszek ARM vasat 200W-ot zabáló GPU-val, ha nem gond.
"A 486-ok kora ota rengeteg dedikalt hardver kerult a gepekbe (pl. gpu-k)"
De hát a GPU programozása még inkább lassú, mint az FPU-é. Ott általában van közte valami busz is, nem tokon belül van a másik egység (kivétel AMD újabb procijai, amik GPU ide vagy oda, gagyik).
"ezert a kozponti processzor manapsag mar sokkal kevesebb lebegopontos muveletet vegez, mivel nincs ra szukseg."
Mert a programok már csak olyanok, hogy beraksz egy GPU-t a gépbe, és onnan kezdve majd azt fogják használni FPU helyett. Végül is csak egy betű különbség...
"Egyebkent meg anno is elvolt a gepek egy resze lebegopontos egyseg nelkul. (sx csalad)"
Persze, maradjunk az egész műveleteknél, és térjünk vissza a fillezett vektor grafikára textura nélkül, ami azokon a gépeken koproci nélkül ment.
"A forditas nagyobbik resze a szovegfeldolgozas es a szimbolumtabla kialakitasa. A tenyleges gepi kod leforditasa (az assembly fazis) nagyon rovid. Egy jit fordito eleve az egyik gepi kodbol fordit a masikba, tehat meg egyszerubb feladata van."
A szövegfeldolgozás az olyan szinten gyors, hogy ahogy gépelsz befelé, már parsolja és szét a legtöbb fejlesztő eszközben. A fordításban az a nehéz, hogy ne mov ax,0, hanem xor ax,ax-re fordítson. Illetve hogy ha van 5 egymást követő független gépi kódú művelet, akkor azokat olyan sorrendbe rakja, hogy azok legjobban ki tudják használni a párhuzamos végrehajthatóságot. Ez ARMnál pláne kritikus, mert ott erre a célra semmi processzorba épített okosság nincs.
"Az android jit-je betolteskor fordit, tehat programinditasonkent egyszer."
Ha nem így csinálná akkor nem is fordítónak hívnák, hanem értelmezőnek...
"A szemetgyujto pedig relative ritkan fut (neha csak tobb masodpercenkent)"
Ritkán is futhat sokáig. De nem is csak ez a gond, hanem a GC algoritmus bonyolultsága. GC algoritmusból is több féle van, mind másra jó, és az adott helyzet függvényében választ ezek közül egyet. Az azért általánosan elmondható hogy egy GC vagy blokkolhatja a kód futását, vagy ha ezt nem akarjuk akkor megszakíthatónak kell lennie, amelyből következik hogy lesz redundancia a munkájában, így összességében jóval kevésbé hatékony lesz, mint a blokkolós algoritmus.
"Az intel es az arm processzorok kozott az orajelelterest a gyartastechnologia okozza. Azonos technikval egy arm ketszer magasabb orajelre kepes mint egy x86-os, bar a modern x86-os cpu-k 3-4-szer tobb utasitast tudnak vegrehajtani azonos orajelen, ezert van meg mindig egy kb. 2-szeres elonyuk."
Hát igen, de miért is van ez így? Mert az ARM alap filozófiája az, hogy legyen egy kis fogyasztású, kvázi tökmind1 hogy milyen buta, de általános processzorunk. Nem baj hogy nincs benne FPU, nem baj hogy nincs benne elágazás előrejelzés, nem baj hogy nincs benne komoly prefetch, nem baj hogy feature listben ott tart mint egy 386-os - lényeg hogy olcsó, és keveset fogyaszt.
Az x86 filozófiája meg a teljesítmény mindenek előtt. Le van tojva a fogyasztás, le van tojva a méret, le van tojva a szükséges gyártástechnológia, le van tojva az ár - egy a lényeg: legyen k.rva gyors.
"Viszont az arm-ok olcso gyartasa, a tobb mag elhelyezese ugyanakkora mereten lehetove teszi hogy nyers eroben jobbak legyenek. Egy nvidia gpu kartya is erosebb egy x86-osnal, csak tul specializalt az altalanos celu mukodeshez. Egy arm valahol a ketto kozott van, tehat megvan a gyors mukodes lehetosege es a nyers ero, de megvan az altalanos cpu tudasa is."
Na és itt bukik el az ARM szerver. Mivel szerver szoftver nem sokféle van. Ami kevés féle van, ott átírják x86+GPU hegyekre a szoftvert, és onnan kezdve az ARM labdába se rúg. Hiába hogy ugyanazt a számítási teljesítményt tudja mondjuk 1/2 áramból, ha egy GPU 100x többet tud. Ha meg nem vektorműveletekről van szó, akkor meg ott van az x86 CPU, amely vezérlésben mérföldeket ver az ARMra a nagy cache méret, fejlett elágazás előrelátás, prefetch, stb miatt. -
#25
NAS szerverekbe kiválóan alkalmas, ma is ezeket használják, multimédia szerverekbe is megfelelő, szintén vannak már ma is ARM procisak belőlük és még sorolhatnám, hányféle szerverbe megfelelő és megtalálható már ma is az ARM proci.
Az ARM már ma is többféle szerverben müködik, bár tény, hogy komolyabb terheléshez nem alkalmas, csak ha több procit tesznek egy gépbe és a terhelést megosztják köztük. Kisebb, pl. irodai vagy otthoni mértékű terhelést gond nélkül tudnak kezelni, ráadásul ezekben a környezetekben elsősorban az ár az, ami elsődleges, a gyorsaság már nem annyira, a terhelhetőség pedig nem számít, mivel ilyen környezetben professzionális szintű terhelés általában nem keletkezik.
Tehát ahol olcsó, adott feladatra képes szerver szükséges, ott az ARM simán arathat, hiszen vetélytársai árainak töredékéért képes az eszközökbe CPU-t készíteni. -
#26
Az általad említett Wiki szerint is az első, ténylegesen alkalmazott önálló processzor 1991-ben jelent meg ARM6 néven az Apple Newton PDA-ban.
Korábbi típusok közül valóban volt egy, ami felhasználásra is került 1986-ban, csakhogy nem önálló prociként, pusztán koprocesszorként üzemelt.
Egyébként tényleges ARM prociról csak 1990 után beszélhetünk, addig ugyanis az architceturát más neveken illették (a rövidítés ugyan akkor is ARM volt, de azokat ma már nem ARM-ként, hanem vagy Advanced RISC Machine-ként, vagy pedig Acorn RISC Machine-ként emlegetik). -
sanyicks #27 "De hát a GPU programozása még inkább lassú, mint az FPU-é. Ott általában van közte valami busz is, nem tokon belül van a másik egység (kivétel AMD újabb procijai, amik GPU ide vagy oda, gagyik)."
Legalább tudnád miről beszélsz... Egyrész a zintelekben is van tokon belüli gpu(ráadásul mindegyikben ami nem szerver) vagy inkább viccPU mert akkora rakás szar, de van. Az amd gpu-s procijai miért is gagyik? Mert 20%-al lassabbak cpu-ban mint a lapka arányaiban 2x nagyobb területet cpu-val foglalaló intel, viszont az alig 2x akkora gpu területtel az amd gpu-ja sokkal gyorsabb(nem csak 2x)? Sajnos nem éppen az intel procijaival lehet viszonylag tűrhető grafikán külön gpu nélkül játszani, hanem az amd gpu-s procijain. Tényleg gagyi bizony :D
A kedvenc adatbázisozásodba meg pont hogy az arm lenne jobb, ugyanis ott nagyon jó dolog a sok szál. Egy rakat arm mag valószínűleg többet tudna mint negyedannyi de erősebb x86 mag.
Az a sok tápkábeles gpu meg "kicsit" nagyobb teljesítményre képes mint az ájhét, és az nem a gpu hibája hogy a balfasz adatbáziskezelő programozók képtelen kihasználni amikor már 3 féle api közűl válogathatnak/gpu gyártó... (opencl, c++ amp, stream/cuda).
A másik meg hogy a x86 fícsörjeinek fele az elavult szar x86 kompatibilitás kiszolgálására, gányolására való :D
Vajon miért csak pc-n ragadt be az x86... vajon miért nincs nagyszerverekben x86 sem konzolokban sem semmiben a wintel birodalmon túl. -
Komolytalan #28 "NAS szerverekbe kiválóan alkalmas, ma is ezeket használják, multimédia szerverekbe is megfelelő, szintén vannak már ma is ARM procisak belőlük és még sorolhatnám, hányféle szerverbe megfelelő és megtalálható már ma is az ARM proci."
Ezek nagyjából azok a területek, ahol proci csak azért van, hogy küldözgesse a commandokat a vezérlőknek, de jóformán semmit se csinál. Igen, erre jók. Ahogy megfelel egy 8000 Ft-os leggagyibb AMD, VIA, vagy akármi fatengelyes proci is. Mondjuk az tény, hogy az ARM szutyka még ezektől is kevesebbet fogyaszt.
"Tehát ahol olcsó, adott feladatra képes szerver szükséges, ott az ARM simán arathat, hiszen vetélytársai árainak töredékéért képes az eszközökbe CPU-t készíteni."
Más kérdés hogy ha nem kell számítási kapacitás egy gépbe - de mondjuk kell RAID - akkor a CPU ára az marginális (5eFt vs 3eFt, vagy valami hasonló lehet az arány). Mondjuk fogyasztásban is jobb az ARM, de ez megint csak nem sokat számít ha mondjuk RAID 1+0-ban 4 disk megy mellette. Szóval értem én hogy jó ez, de azért én kisebb irodába se ajánlanám. Mert ha eszébe jut a rendszergazdának és felrak rá egy vírus/spam szűrőt, akkor máris bedobja a törülközőt. -
Komolytalan #29 Te kötekedő kis pöcs.
Az AMD Buldozerek szerver procinak nem jók (mert intel gyorsabb), csúcs asztali procinak nem jók (mert intel gyorsabb), alsó kategóriás asztali procinak meg drágák (i5 ugyanannyiba kerül, és sebességben max azzal van partiban). Akkor mégis mi a tökömre jók? Van bennük GPU, ami hiába jobb mint az Intel által integrált, említésre se méltó fosadék, ha még így is kaka. Annyi haszna legalább van, hogy FPUból csak a fele fért bele a 125W-ba, amit csontra kihasznál. Így lett egy CPU(/FPU)nak lassú, GPUnak vicc, de legalább sokat zabáló gnóm förmedvény belőle.
Adatbázisozásba meg jó a sok mag, feltéve hogy 1-1 mag megfelelő sebességű. Meg esetleg tud lebegőpontos műveletet is. Mert az azért elég gáz lenne, hogy ha ki akarom számolni két oszlop arányát, és ez alapján mondjuk rendezni, akkor kiírja az adatbázis szerver hogy bocs, de most menj el ebédelni, mert ezt kb 100x lassabban tudom, mint az x86.
A GPU meg hiába hogy gyors, ha:
1. Csak vektor műveleteket tud, fel is kell programozni, komoly memória korlátja van, stb.
2. Nem használja jelenleg lóf.sz sem, adatbázis kezelők terén (ha már azt emlegeted).
Amit most veszek szervert azt arra veszem, amire most szükségem van. Nem fogok 2015-ös felhasználásra szervert vennem, mert majd akkor támogatni fogják az adatbázis kezelők.
Az x86 meg azért maradt meg, mert a többi világmegváltó procikkal ellentétben nem sz.rta le a visszafelé irányuló kompatibilitást. Nyilván sehol se alkalmazzák ma már, ezért is ugatsz te is róla. -
sanyicks #30 Mondtam én hogy fingod sincs semmiről mint mindig:
-Nem jók szerverprocinak? Teszt?
- ja gyorsabb a legcsúcsabb i7 összességben (i5 csak 1-2 tesztben) olyan alkalmazásokban amik még 4 magot sem tudnak kihasználni, szóval a 4 magos bulldozer árát és teljesítményét hasonlítsad desktopon ;)
- és lám hogy mennyire fingod sincs miről beszélsz: bulldozerben NINCS gpu, llano-ban van meg a brazosban(ugyanis ezeket szánják jelenleg külön gpu nélküli gépekbe), és ezekkel elég szépen el lehet játszogatni is, nem úgy mint az intel fos gpuival, ami kb a vindóz gui megjelenítésére elég.
"Az x86 meg azért maradt meg, mert a többi világmegváltó procikkal ellentétben nem sz.rta le a visszafelé irányuló kompatibilitást. Nyilván sehol se alkalmazzák ma már, ezért is ugatsz te is róla."
Ja ezért tudott rendes fejlődést is elérni más architektúra fogyasztás/teljesítményben, és árban is, és tényleg sehol sem alkalmazzák már mint lentebb írtam csak a begyepesedett wintel birodalomban. Nagyszerverekben sehol sincs, sem máshol a pc-ken kívül ;) konzolokban is powerpc, tabletekben telefonokban arm. -
#31
"intel mag 5 ghz, hyperthread, 32MB cache , altalaban 4-6 mag"
Miről beszélsz a 2-3Ghz közötti Xeonok is brutál áron vannak. Hol van az intelnek 5Ghz szerver CPU-ja? Hozod a szintedet vers az tuti :) -
#32
"a mai szerverekben mar nvidia duborog, legalabbis a jobbakba"
Milyen szerverben dübörög nvidia? Szerintem minden 100 eladott Xeon szerverre jut max 1 nvidias gép, de lehet hogy 1000:1 az arány inkább. Ráadásul szerver sokféle van sokféle feladatra sokféle áron. Nyilván nem a komplett feladatot tudja lefedni a HP de mivel többezer szervert ad el havonta, így gondolom pontosan látja hogy mire lenne igény a piacon. Azért annyira hülyék ott sem ülnek.