Hirdetés

2024. április 23., kedd

Gyorskeresés

Hozzászólások

(#51) Xero válasza #95590400 (#47) üzenetére


Xero
nagyúr

Azért zsákszámra látja a requesteket, plusz amikor éppen nincsen diliszabin, akkor gyakorlatilag tejhatalmúlag dönthet is fölöttük. Márpedig, ha olyan eszeveszett sebességgel pörögne fel az igény, akkor a releváns cégek zsákszámra állítanák rá az embereiket, hogy reszeljék számukra megfelelőre a kernelt. Mondjuk ezt bárki megnézheti a levlistákon.

Az ARM jelenleg server fronton légüres térben lebeg. Akkor fog valóban ez nagyot változni, ha valaki (nem tartom kizártnak, hogy az Apple húzza meg, hogy leválassza a termékeit a többi gyártóról még inkább) consumer vonalon berántja az architektúrát. Persze lehet, hogy teljesen más irányból fog beindulni, de igenis van fantáziába benne skálázhatóság és perf/watt szempontjából.

Viszont ha van valakinek egy varázsgömbje, az legyen olyan jó tekintse bele és dobja már be az infokat ide, mert jelen állás szerint minimum arra lenne szükség.

(#52) Lacc válasza Xero (#51) üzenetére


Lacc
aktív tag

Törött varázsgomb: Az Amazon már felkaroltam az ARM szerver témát: AWS E2 A1.

(#53) hallador válasza #95590400 (#47) üzenetére


hallador
addikt

Végül is a világ legnépszerűbb operációs rendszerének a kernelét fejlesztette, senki a csávó, nem dobsz el a media marktba, de lassan az utcán sem semmit, hogy ne Linux fusson a cuccban. Bezzeg a hozzád hasonló megmondó emberek a rendkívül komoly, és felvilágosult újító szellemű orbanisztánban aztán vágják a témát, bármiben is.
Hiszem amikor megjelenik egy új technológia, akkor nem Linus-hoz meg a kernel hacker csapathoz mennek, hogy tegyék bele a kernelbe a cuccot, illetve nem a kernelhacker csapat áll kapcsolatban az AMD/Intel/Samsung/ARM meg pár száz céggel, hanem a PH Magyarországon élő megmondó emberei, akiknek kb annyi fogalmuk van a való világról, mint amit a béka meneten brekegett breki a kiskirály... Technológiában meg egyenesen a 19 században élnek, ami aztán mennyivel jobb mint az ezt fejlesztő tech cégek...

Jajj várj mégsem.... :)) Csodálom, hogy kisvasút kalauz bácsi még nem nevezett ki egy Technology Captain-t valami hasonló kaliberűt mint pl Te... :(

The further a society drifts from truth, the more it will hate those that speak it. (George Orwell) [Work Machines: HP EliteBook, HP ProBook & Linux Mint 20 ; Entertainment: Apple Macbook AIR M1]

(#54) Reggie0 válasza Lacc (#52) üzenetére


Reggie0
félisten

Amazonnak muszaj, oket rosszul erintette a specre/meltdown.

(#55) dabadab válasza Lacc (#52) üzenetére


dabadab
titán

"Törött varázsgomb: Az Amazon már felkaroltam az ARM szerver témát: AWS E2 A1."

Ez olyan sokat egyelőre nem jelent, csak azt, hogy kísérleteznek vele (egy gyors check alapján a 17 központjukból csak ötben vannak ARM szerverek), egyelőre nem látszik különösebb jele annak, hogy jelentősebb igény lenne ezekre vagy hogy az Amazon olyan nagyon bízna az ARM platformban.

DRM is theft

(#56) d4Y.187


d4Y.187
tag

maga az interjú nem fért volna el a cikkben?

.: 3o 62o 9282 :: wehaveit.hu :.

(#57) Xero válasza dabadab (#55) üzenetére


Xero
nagyúr

Ez részükről szerintem nem bizalom kérdése volt. Inkább kényszer menekülő utakat kerestek.

Amúgy pont a hetekben keresett az Amazon Zurichben linux deveket, majd feltűnt pár hirdetés IC designer és hasonló fura körökben. Mindegyik fejvadászon keresztül. Lehet nincs összefüggés, miért is lenne, csak mint érdekesség ide dobom. Bár azt azért kötve hinném, hogy az amazon beleszáll a chip fejlesztésbe.

(#58) Sinesol válasza schawo (#50) üzenetére


Sinesol
veterán

Szerintem 10 random PH tagból 9 tutira megmondta volna anno, hogy az ARM szerver terjedése elég döglött dolog, szóval lehet jobban értenek hozzá. :D
Anno amikor volt a hír, akkor is totál valószínűtlennek tűnt, rajta kívül senki sem igazán hitte el és nekik lett igazuk.

(#59) #95561216 válasza dabadab (#55) üzenetére


#95561216
törölt tag

Pedig kb ezen all vagy bukik az arm elterjedese, nem a kis es kozepvallalati max par tucat per ceg szerveren, de meg csak nem is a multik adatkozpontjain. A legnagyobb szervergyartok nem az IBM, HP, Dell, hanem a Google es az Amazon. Elobbi par eves markting anyagban azt alitotta, hogy a legyartott processzorok 20%-a hozzajuk kerul, es meg csak utanna indultak a tobb 10 milliard dollaros data center fejlesztesek, es meg igy is MS, Amazon boven elottuk jar. Ez a nagy piac, dolgoztam olyan projecten, amin csak a fejlesztoi/teszt kornyezet tobb ezer vm-en futott, es rohadtul nem erdekelt milyen proci futott alattunk, mert a hardver sok-sok absztrakcios reteggel odebb volt. Ha armra csereltek volna alattunk kb eszre se vesszuk, egy amazon eseten ha csak par szazalekot faragnak a koltsegekbol maris milliard dollarnal tartunk. Ha megeri, akkor sajat szolgaltatasok alatt pikk-pakk atalnak, x86 meg max marad az ec2-n valaszteknak.

(#60) schawo válasza Sinesol (#58) üzenetére


schawo
titán

Jó, de 10-ből 9 fórumozó bármiről képes azonnal megállapítani, hogy hülyeség.

evDirect villanyautós töltőhálózat

(#61) d4Y.187 válasza schawo (#60) üzenetére


d4Y.187
tag

sokan vagyunk sokfélék. néhányan viszont személyes támadásként élik meg, ha valakinek nem ugyanaz a véleménye, mint neki... szvsz ebből lesznek az értelmetlen sárdobálások.

[ Szerkesztve ]

.: 3o 62o 9282 :: wehaveit.hu :.

(#62) Ribi válasza #95561216 (#59) üzenetére


Ribi
nagyúr

Én valahogy úgy emlékszem, hogy ezek az ARM procik sem annyira takarékosak.
Amíg totál alulfeszelve mennek, addig jól néznek ki, de ha konstans akarja használni értelmes frekin akkor máris pont ott vannak mint a normál procik.
Van bármi teszt erről, hogy mennyivel energia takarékosabbak?

(#63) schawo válasza Ribi (#62) üzenetére


schawo
titán

Mitől lenne energiatakarékosabb?

evDirect villanyautós töltőhálózat

(#64) ecaddsell válasza Ribi (#62) üzenetére


ecaddsell
aktív tag

Az összes szerver proci így megy, alacsony frekin (mert ugye exponenciális a frekivel a fogyasztás emelkedés) és mivel kicsi a per mag fogyasztás sok maggal.

schawo
Kevesebb legacy cucc, kevésbé bonyolult utasításkészlet amivel kompatibilitást kell tartani (kevesebb, egyszerűbb mikrokód).

(#65) Ribi válasza schawo (#63) üzenetére


Ribi
nagyúr

Régebben ezt nagyon hajtogatták.
Mi a lényeges előnye ARMnak x86-hoz képest, ami miatt arra kellene menni?

(#66) t72killer


t72killer
titán
LOGOUT blog

Háát azért már mindenkinek ott lapul a zsebében egy ARM PC, csak épp nem fejleszt rajta, hanem az anyóst hivogatja vele - ami lehet nagyobb kihívás...

Mindig meglep milyen sokan hiszik el, hogy van ingyen ebéd.

(#67) #95561216 válasza Ribi (#62) üzenetére


#95561216
törölt tag

Fogalmam sincs, hogy megéri-e, és ha igen, akkor mire. Azt mondom, hogy ha megéri, akkor nem a SOHO szerverek meg céges adatközpontokba kell várni őket, hanem a nagy cloud providerekhez. AWS-en sem az az érdekes, hogy vehetsz armos EC2-t, jelenlegi áron nincs is sok értelme. Ami érdekes, hogy a színfalak mögött a másik 100 szolgáltatásukból - amik szintén ec2-re épülnek, de azt a felhasználó közvetlenül többnyire nem látja - hányat tesztelnek épp armon, és hogy mi lesz ezeknek a teszteknek az eredménye.

(#68) Ribi válasza #95561216 (#67) üzenetére


Ribi
nagyúr

Lehet inkább valami ASIC szerű cuccot kellene csinálni azokra a dolgokra amire szerver parkot akarnak.
Lehet az ARM is ebbe az irányba megy a variálhatóságával. Mostanában úgy is nagyon VM irányba megy minden, arra kellene csinálni egy hatékony procit és lehetne vele sokat keresni. Csak hát az elterjedés.

(#69) dabadab válasza t72killer (#66) üzenetére


dabadab
titán

"Háát azért már mindenkinek ott lapul a zsebében egy ARM PC, csak épp nem fejleszt rajta,"

Pont ez az. Mobilokra is crossdev megy meg Raspira is, nincs natív fejlesztői környezet, mert az elérhető ARM-os platformok túl gyengék hozzá.

DRM is theft

(#70) joysefke válasza dabadab (#69) üzenetére


joysefke
veterán
LOGOUT blog

Pont ez az. Mobilokra is crossdev megy meg Raspira is, nincs natív fejlesztői környezet, mert az elérhető ARM-os platformok túl gyengék hozzá.

Egyáltalán miért kéne natív fejlesztői környezet amin aztán egy halom megszokott dolog nem menne? Ott a PC, egy ablakban elfuthat az Android ARM-estől a másik 10 ablak mellett.

Az android appok jelentős része csak egy UI valamilyen webservice-hez, azt meg eleve PC-n fejlesztik. Még ha különböző csapat is csinálja az Android appot és a webservicet, nem érdemesebb egy hullámhosszon (PC) tartani a fejlesztőket?

[ Szerkesztve ]

(#71) #54625216 válasza dabadab (#69) üzenetére


#54625216
törölt tag

Ettől lesz az egész öngerjesztő folyamat: az ARM sosem éri el az x86 teljesítményszintjét, mert azzal együtt a fogyasztás és a hőtermelés is megugrana. Csakhogy desktopon a fogyasztás és a hő kezelhető, így viszont desktopon arm-ra váltani hülyeség, mert le kell mondani a teljesítmény jelentős részéről olyan előnyökért, amik nem számítanak.
Viszont amíg nincs arm desktop, addig natív fejlesztő környezet sincsen, úgy pedig a szerverek sem terjednek, hiába lenne olyan terület, ahol esetleg verhetnék az x86-ot.
Szvsz az arm-nak egyszerűen el kell érnie azt a teljesítmény szintet, ami desktopon már elég jó. Onnantól tök mindegy, hogy van-e x86 konkurenciája többszörös teljesítménnyel, ha az extra lóerőre amúgy sincs szükség.
Az apple pont azért nem vált még arm-ra desktopon, mert egyszerűen nincs meg az arm-ban az a kraft, ami legalább közép szinten elegendő lenne. Addig pedig nincs értelme a váltásnak, mert vagy végleg kiírja magát a desktop piacról (amivel a saját ökoszisztémáját veszélyeztetné, mert tartalomfejlesztő eszköz nélkül maradnának) vagy párhuzamosan két desktop vonalat kellene futtatnia, amivel több kárt okoznának maguknak, mint hasznot.

(#72) waveson válasza frescho (#8) üzenetére


waveson
tag

Ha a rack szekrény fogyasztásmérője viccel, akkor viccnek gondolom! :D
Sok HDD van benne, ennyi :)

(#73) dabadab válasza joysefke (#70) üzenetére


dabadab
titán

"Egyáltalán miért kéne natív fejlesztői környezet"

Mert a nemnatív fejlesztés mindig nagyobb szívás, mint a tisztességesen működő natív.

"Ott a PC, egy ablakban elfuthat az Android ARM-estől a másik 10 ablak mellett."

Ja, de milyen sebességgel? Ez nem egy x86 VM, ami majdnem pont úgy fut, mintha igazi vas lenne alatta, hanem a processzort is emulálni kell, az meg agyonlő minden sebességet, aztán lehet töprengeni, hogy ez most azért lassú, mert ennyit tud az emulátor, vagy azért, mert lassú a kód, de az tuti fix, hogy rettenetesen lassú lesz.

[ Szerkesztve ]

DRM is theft

(#74) Ribi válasza #54625216 (#71) üzenetére


Ribi
nagyúr

Hát néha kihoznak valami MAC gépet, de bőven nem ebből élnek, sokkal inkább a notebook szekcióból.
Elég sokszor írták, hogy váltani akarnak ők is Intelről saját ARM-ra.
Szóval nem teljesen értem írásod. :N

(#75) #95561216 válasza #54625216 (#71) üzenetére


#95561216
törölt tag

Na de webalkalmazásoknál mi a natív? Kb az, hogy tomcat, nginx, nodejs vagy python interpreter van-e alatta, hogy az alatt mi van a többséget nem érdekli, mert nem számít. Hogy exchange servert mire írják, az itt kerekítési hiba.

(#76) joysefke válasza dabadab (#73) üzenetére


joysefke
veterán
LOGOUT blog

Ha trollkodni akarnék, akkor azt mondanám, hogy ha fejlesztés közben nem akarnak szopni majd írnak olyan UI-t ami gyenge vason is jól elfut :))

De mivel nem akarok trollkodni, azt mondom, hogy lefordítja a kódot, USB-n hálózaton vagy valahogyan átküldi a futtathatót az Androidos fejlesztői telefonjaira és ott megnézi hogyan fut.

Egy ARM-es fejlesztői PC-n nyilván sokkal jobban futna natívan a dolog mint egy hasonló erősségű x64-en, de az is csak egy fejlesztő HW lesz és nagyon nem az a vas amin a tényleges userek futtatni fogják. 100W vs 2-5W, NVME SSD vs SD kártya stb.

Mondom ezt úgy hogy nincsen tapasztalatom azzal, hogyan fut egy Androidos emulátor. Mindenesetre nem sok együttérzésem van az Androidos fejlesztőkkel.

(#77) dabadab válasza joysefke (#76) üzenetére


dabadab
titán

Izé, alapvetően nem telefonról van szó, mint célplatformról, hanem szerverekről :)

És persze, az x86 szerver sem pont az, ami a fejlesztők asztalán van, de ott azért érzésre elég jól be lehet lőni azt, hogy mit fog bírni a szerver, mert a desktop gép alapján lehet extrapolálni - ARM-nál viszont ez nincs meg, tényleg fogalmam sincs, hogy mit fog csinálni egy MariaDB, ha egy ARM-ot kap maga alá.

Androidnál az emulátorban x86-os Android fut, mondjuk az is elég szenvedés.

[ Szerkesztve ]

DRM is theft

(#78) joysefke válasza dabadab (#77) üzenetére


joysefke
veterán
LOGOUT blog

Izé, alapvetően nem telefonról van szó, mint célplatformról, hanem szerverekről

Uhh tényleg. Ma szétfórumoztam az agyam, kicsit megkavarodtam. ;]

(#79) #54625216 válasza Ribi (#74) üzenetére


#54625216
törölt tag

Nem az a lényeg, hogy az apple miből csinálja a nagy eladásait, hanem hogy teljes ökoszisztémát árul ami független a többi piaci szereplőtől.
Ha leállnának a desktop vonallal, akkor nem lenne saját tartalomfejlesztő platformjuk az iOS-hez és így kiszolgáltatnák magukat a többieknek. Márpedig jelenleg az arm-ra átállás egyenlő lenne a tartalomfejlesztő platform feladásával. Tartalom alatt nem csak a kódolás, hanem a grafika és a videó is értendő, a VR/AR miatt jönnek fel a game enginek, tehát desktopban ha nem tartod a teljesítmény szintet a többiekkel, akkor kb. kiszálltál a játékból.

"Elég sokszor írták, hogy váltani akarnak ők is Intelről saját ARM-ra."

Kik írták elég sokszor? IT bulvár pletykagyárak. Ezek az un. "elemzők" információ töredékekre alapozva előállnak mindenféle hajmeresztő agyszüleménnyel, mert manapság ha egy címbe beírják, hogy Apple, akkor lehet az írás akármekkora baromság, kattint rá a nép vagy azért, hogy fikázza vagy hogy kajálja.
Ettől még lehetnek az Apple-nek hosszú távú tervei a desktop vonal ARM-ra állításával, de nem fogják magukat lábonlőni csak azért, mert "elég sokszor írták", hogy ezt fogják tenni.

(#80) robohw válasza #54625216 (#71) üzenetére


robohw
aktív tag

"az ARM sosem éri el az x86 teljesítményszintjét, mert azzal együtt a fogyasztás és a hőtermelés is megugrana."

Nem ugrana meg.
Az ARM egy nagyon jól tervezett proci, az Intel meg nem az.
Ráadásul az intelnek az életben maradáshoz magával kell vonszolnia a backward kompatibilitást, annak minden nyűgével.

Az ARM procik nem fogyasztanak sokat, mert RISC-ek és ráadásul, sok regiszterük van. Az Intel procik meg CISC-ek (jobbára) és kevés a regiszterük, emiatt az adatmozgató utasítások eszik el a CPU időt, fülüslegesen.
De az ARM procik ugyanazt a feladatot kevesebb tranzisztorral oldják meg mint az Intel, a kevesebb tranzisztor pedig kevesebb hőt termel.
Ezért is arat az ARM a mobil készülékek piacán, ott, ahol az intel csúfosan megbukott. :)

My own programming language: http://www.robomax.online

(#81) robohw válasza berVi (#1) üzenetére


robohw
aktív tag

"Az x86 meg velunk lesz par evtizedig, az mar biztos. "

Vagy nem.. :DD
Az intel már csak a múltjából él.
Az embereknek totál mindegy - ma már- , hogy milyen proci zörög a készülékükben, szerver fronton viszont erőteljes tényező a fogyasztás, ahogy a mobil eszközök területén is. Az Intelnek már annyi. Haldoklik egy jó ideje és nem vagyok benne biztos, hogy 2025-ben még létezik-e majd.

My own programming language: http://www.robomax.online

(#82) robohw


robohw
aktív tag

"it's a 32-core 64-bit Armv8 CPU clocked up to 3.3GHz in turbo mode, with a shared 32MB L3 cache.
It supports up to 1TB of DRAM from 16 DIMMS plugged into eight DDR4-2667 memory controllers, has 42 lanes of PCIe 3.0, draws up to 125W, and is a single-socket chip. It'll be made using 16nm TSMC FinFETs. The cores were designed by Silicon Valley-based Ampere, and the whole package is branded the eMAG."

My own programming language: http://www.robomax.online

(#83) Kansas válasza robohw (#82) üzenetére


Kansas
addikt

Ugyanez AMD-éknél: (Epyc)

EPYC 7601:
32C/64T
2TB RAM/socket
16 DIMMs 2666MHz DDR4
64MB L3 cache
128 PCIe lane
180W TDP

Igen, többet fogyaszt, de amit nem tudunk, az pl. az ARM proci teljesítménye - legutolsó emlékeim szerint mobileszközökben az Atom procik szintjén voltak, és a Core-U procik szintjét 2x annyi maggal se tudták hozni
Érdekelne némi új benchmark eredmény a szerverprocik kapcsán, ha tudnál linkelni...

(#80) robohw "De az ARM procik ugyanazt a feladatot kevesebb tranzisztorral oldják meg mint az Intel, a kevesebb tranzisztor pedig kevesebb hőt termel." csakhogy ugyanannyi órajelciklus kell nekik a végrehajtáshoz, vagy tovább szöszmötölnek vele és pörgetik a villanyórát?

[ Szerkesztve ]

Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.

(#84) robohw válasza Kansas (#83) üzenetére


robohw
aktív tag

"csakhogy ugyanannyi órajelciklus kell nekik a végrehajtáshoz, vagy tovább szöszmötölnek vele és pörgetik a villanyórát?"

Nem kell ugyanannyi. Téves elképzelés, hogy adott feladatot minden proci ugyanannyi órajelciklus alatt végez el. A különbség szemléltetéséhez elég ha két régi, de valaha nagy utat befutott procit hasonlítunk össze.

Az egyik a 6502, ami az apple gépekben és a commodore számítógépekben volt használatos. Jellemzően 1 Mhz környékén volt járatva, felépítését tekintve risc jellegű arcihetektúra, egyébként.
Nagyjából ugyanezt a teljesítményt hozta a z80 proci. Ez utóbbinak jellemzője a cisc utasításkészlet volt és az, hogy a teljesítményt, amit a 6502 tudott 1 Mz-en, a z80 csak 4 mhz környékén volt képes nyújtani.

Az sem véletlen, hogy a z80-at az Inteltől kivált mérnökök alkották, a 6502 pedig alapul szolgált a RISC acorn (ma ARM) processzorok tervezésénél.

My own programming language: http://www.robomax.online

(#85) Kansas válasza robohw (#84) üzenetére


Kansas
addikt

A kérdőjel("?") mint írásjel használatával látom nem vagy tisztában, vagy write-only üzemmódba kapcsoltál...

Önmagában az hogy egy proci CISC vagy RISC az ég volágon semmit nem mond a teljesítményéről, bármennyire szeretnéd is, hisz könnyen meglehet, hogy egy összetett CISC utasítás RISC megvalósításához(és/vagy végrehajtásához) több utasításra, több órajelciklusra van szükség, ami azonos órajelen lassabb végrehajtást eredményez.

Az ominózus mondattal arra akartam utalni, hogy hiába soroltuk fel mindketten a száraz adatokat, az utasításkészlettől függően azonos órajelen is drámaian eltérő teljesítményt nyújthat két, papíron hasonló paraméterekkel rendelkező proci.

Tehát plíz, üres lózungok és tautológiák helyett teljesítménymutatókat(GFLOPS, MIPS, stb.) de még inkább összehasonlító benchmarkokat linkelj, amik alátámasztják az ARM fölényéről szóló állításaidat. Én eltöltöttem tegnap este vagy egy órát gugliban és egy darabot sem találtam - stand-alone benchmarkot igen, de az viszonyítási pont híján semmi információt nem hordoz.

Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.

(#86) robohw válasza Kansas (#85) üzenetére


robohw
aktív tag

A mikroprogramozott vezérlés megjelenésének következtében növekedett az utasítások bonyolultsága. Ez azért következett be, mert a ROM-ban elhelyezett mikroprogram végrehajtása gyorsabb, mint a központi tárak által biztosított sebesség, másrészről befolyásolta az összetett utasításkészlet megjelenését a magas szintű programozási nyelvek széleskörű elterjedése is. Történelmileg a számítógépiparban a CISC architektúrájú gépek domináltak.
A piac nyomására, hogy megőrizzék a kompatibilitást, megtartva a régi utasításkészletet, egyre bonyolultabb gépi instrukciókat vezettek be a CPU családokon belül, ahol is a sokféle instrukcióval kényelmes gépi kódú programozás lehetséges, és megfelelő hatékonyságú kódot lehet generálni a magas szintű nyelveken írt programokhoz is. A nagy instrukciókészlet viszont nagy belső mikroprogramtárat igényel.

Újabb felfogás szerint a teljesítmény növelhető redukált instrukciószámú processzorokkal, ahol viszont a hardver és szoftver között sokkal kifinomultabb és igényesebb együttműködés lehetséges. A koncepció statisztikai felmérések alapján merült fel, amikori azt vizsgálták, hogy a szoftverek hogyan használják a processzor erőforrásait.
Kiderült, hogy az egyszerűbb instrukciók túlnyomórészt dominálnak még a CISC architektúrákban is. Hiába implementálták a komplex instrukciókat, azokat ritkán használják. Egy csökkentett utasításkészletű processzor, ami tipikusan 50-80 instrukciót jelent, és amelynél szemben a CISC felépítéssel az instrukciók dekódolására fix logikát alkalmaznak, nagyságrenddel nagyobb ütemezési sebességgel tud dolgozni. Az amúgy is domináló egyszerű instrukciók mellet a felmerülő komplexebb feladatok - kicsivel több kóddal, de optimált fordítással segítve - azért elvégezhetőek maradnak (!!!).
Valószínűleg hosszabb lesz a kód, de a cache memória ezen is segíthet, a háttértároló kapacitás pedig egyre kevesebb gond a fejlődés során. A RISC fejlődést teszi lehetővé az a tény is, hogy a gyorsító memóriák is fejlődnek, a processzor mikrokód helyettesíthető az egyre gyorsabb cache memóriákkal.

A benchmarkok ritkán nyújtanak valós képet. Az igazi megmérettetés maga a feladat, annak implementálása és a teljesítmény egzakt mérése, valós környezetben.

Ezért hoztam példának a 6502-t párhuzamba állítva a zilog z80-as processzorával. Szerintem megfogható a markáns előny a risc jellegű processzor (56 utasítás) javára, szemben a z80 194 utasításával, amely a 6502 órajelének négyszeresén hozza a 6502 teljesítményét, azonos feladat esetén.
Igaz, hogy a z80 ALU-ja csak 4 bites, míg a 6502-é nyolc, de az is sokat elárul, hogy az intel mai processzoraiban már van risc core, a cisc utasítások (legalábbis ezek egy része) fel van bontva risc-ekre még a végrehajtás előtt.

Azt még érdemes megemlíteni, hogy a szerver piac is fregmentált. Ahogy a nagy teljesítményű szerverekre, úgy a kisebbekre (kis terheltségű szolgáltató vagy adat-gyújtő szerverek, dedikált stream szerverek, pont-pont kiszolgálók) is konstans igény mutatkozik már egy jó ideje.
Az, hogy a szerverek piacán az intel alapú procik a keresettebbek, sokkal inkább a rögzült szokásoknak, mintsem az ésszerű, jól átgondolt döntéseknek tudható be. Legalábbis ma még.

My own programming language: http://www.robomax.online

(#87) Kansas válasza robohw (#86) üzenetére


Kansas
addikt

"Ezért hoztam példának a 6502-t párhuzamba állítva a zilog z80-as processzorával."

Szerintem meg a CISC procik(Intel/AMD/VIA) közt is van akkora teljesítmény és IPC különbség, hogy a 40 évvel ezelőtt tervezett procik teljesítményviszonyai totálisan irrelevánsak legyenek a kérdésben.

Konkrét, összehasonlítható mérési eredményeket, plíz, bemondásra nem hiszek el semmit.

Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.

(#88) #41095680 válasza Sinesol (#39) üzenetére


#41095680
törölt tag

Ne haragudj már meg, de le vagyok maradva mikor is voltak FX-ek 13 éve vagy a Phenom I.-et is FX-nek hívták? Jól leragadtunk a múltban a szerveres hírnél.

Copyright © 2000-2024 PROHARDVER Informatikai Kft.