Új hozzászólás Aktív témák
-
válasz Petykemano #993 üzenetére
most már biztos a 8 mag lesz a mainstream, az új i5.
Miért olyan biztos ez?
Ha a ZEN2 tényleg +15%IPC-vel és +10% órajellel és jobb energiahatékonysággal jön, akkor a 6c12t variáns kényelmesen hozni fogja a 8700K teljesítményét. Applikációkban gyorsabb lesz, játékokban mondjuk egál. A 8c16t ZEN2 pedig a 9900K-val lesz mindenhol legalább egálban.
Ha ez teljesül akkor fölösleges megint belemenni egy magszám-háborúba. A 6c12t ZEN2 a fent vázolt teljesítményszint mellett a jelenlegi 2600X, a 8c16t ZEN2 pedig a jelenlegi 2700X árán és az előd kategóriájában is több mint versenyképes tudna lenni.
Futnának ez emberek a boltba hat meg nyolcmagos AMD-t venni, mintha cukorka osztogatás lenne.
Magszám háborúnak akkor van értelme, ha a magszámon és az áron kívül nem tudod a termékedet valamivel a konkurencia elé emelni.
A 8c16t modell fölöttieket (12c24t, esetleg 16c32t bár az utóbbiban nem hiszek) pedig lehetne vaskos haszonnal adni legalább addig amíg nem jön a 10 magos intel....
[ Szerkesztve ]
-
válasz Petykemano #995 üzenetére
3700X visszakerülhet a $500 magasságba
3700 $400
3600X $300(-330) => ez még mindig elképesztő módon a 9900K alá ajánlás
3600 $250Ezek milyen légből kapott modellszámok?
Honnan tudod, hogy mi az hogy 3700x vagy 3600? -
válasz Petykemano #997 üzenetére
Ha fájna a kákán is csomó keresése, Te ordítanál
ezt hagyjuk.ez még mindig elképesztő módon a 9900K alá ajánlás
(Fenti árak az 1800X-1600X release áraiból származnak)Pont ennek nincsen szerintem értelme.
Miért adnának egy 250$-ért -ennyi most a 2600X- egy nyolc magos ZEN2-t, ami a 9900K-val van pariban.
A 9900K a 8700K és 9700K fölött van egy szinttel teljesítményben és árban is. Miért árazná az AMD a 9700K és 8700K alá a jelenlegi 6c6t core i5-ök szintjére a nyolc magos ZEN2-t? Mi értelme lenne akkor, ha a teljesítmény csakugyan olyan jó lesz, mint amit most pletykátnak (15%IPC, szűk 5GHz turbo)?350-400$-ért nem vinnék el az alacsonyabban clockolt, de szorzózár mentes i9-9900 szintű 8/16 ZEN2-t, de 250$-ért elvinnék? Ha mondjuk 350$-ba kerülne akkor inkább vennének helyette 500$-ért 9900K-t vagy 350-ért-ért jóval lassabb 8700K-t? :F
Ha a 6 magosok frekvenciája alacsonyabb, akkor ebből a kínálatból az elvileg 8magos, elvileg közel 5Ghz-et elérő elvileg magasabb IPC-vel rendelkező zen2 sku és elvileg 8magos, elvileg magasabb IPC-vel rendelkező zen2 procis, alacsonyabb az órajellel rendelkező skulenne a legkelendőbb (pont úgy, ahogy az 1600-1600X is az volt)
Szorzólockról még nem tudunk. Ha tényleg olyan jók lesznek a procik, akkor mondjuk meg lehetne fontolni a szorzólock bevezetését, hogy az X-modellek is jól eladhatóak legyenek, illetve hogy a userek több mint 10%-a számára is legyen valamilyen gyakorlati előnye a nagyobb (8+) magszámnak. Magszámméregetésen kívül is.
Az én tippjeim (ha minden unlocked marad és hozza a teljesítményt amit remélünk):
3950X => hely a számozásban
3900X - 12c24t (később) - 550-650$
3800X - 8c16t - 399-449$
3700 - 8c16t - 299$
2600X - 6c12t - 250$
2600 - 6c12t - 220$egy esetleges 10-magos intel gyors megjelenése ezt nyilván felrughatja
[ Szerkesztve ]
-
válasz #82819712 #1000 üzenetére
El tudod Te azt képzelni hogy konzol kijön 8 maggal egy durva SSDvel amivel sávszélességbajnok lesz.
Amennyiben a "durva SSD amivel sávszélességbajnok lesz" alatt egy 1TB-s QLC-s M.2 SATA valamit értesz, ami majd akkor 25E HUF lesz az iponban 27% Áfa+kisker árréssel, akkor igen. A PS5 konzol pedig jövő karácsonyra jön.
CPU-kba meg marad a 6 mag a mainstream-ban
A mainstream az LGA1151 vagy AM4-et jelent. Ezekbe sok minden belemegy kétmagos hurka-gyurkától nyolc magos csodákig. A nyolc magos csodák pedig jelenleg sem ritkák.
Én azt mondom, ha jó lesz az egyszálas teljesítmény is (értsd leveri az intel@5GHz-t) akkor nem fogják a nagyobb magszámokat egy kategóriával lejjebb hozni, hanem az új, eddig nem létező magszámokat viszik egy kategóriával feljebb (R9). A többit pedig az azonos magszámú intel mellé árazzák, szimplán jobb ár/teljesítmény mutatóval. (kicsit gyorsabb kicsit olcsóbb alapon biztosítva, hogy objektíven lényegesen jobb vétel legyen)
Ehhez persze mint írtam döntő fontosságú lesz az egyszálas teljesítmény.
A közös fejlesztésekbe mi történne CPU limittel indít a PC és még a portból való lassulás
Ez viccesen naív.
[ Szerkesztve ]
-
Persze a dolog itt most annyit változik, hogy ez lehet az első AMD proci széria tizenpár év után, ami minden szempontból jobb lehet(!) az Intel ajánlatánál
Pontosan, és ez óriási különbség.
Ezen felül akkor még nem voltak "úgynevezett" ellátási nehézségei az intelnek, így valószínűbbnek látszott, hogy bele fognak menni egy árháborúba. Most viszont teljesen egyértelmű, hogy az intel piacvesztés ellenére sem fog belekezdeni egy desktop árháborúba.
Ergo elég minden AMD modellt a rivális megfelelő modellje alá árazni annyival, hogy aki nem fanatikus jó eséllyel AMD-t vegyen. Azoknál a modelleknél amelyiknek nincsen az intelnél párja pedig foghat vastagon a ceruza.
Fölösleges "megalázóan jó árakat" adni hiszen mind az intel mind az AMD elsődlegesen pénzt akarnak keresni.
-
válasz Petykemano #1050 üzenetére
Ez egy 16 magos RyZEN3000 ES lenne?
-
válasz Petykemano #1052 üzenetére
Most kezdek borúlátó lenni a desktop ZEN2 órajeleivel kapcsolatban.
Azt tippelem, hogy ha jók lennének a max órajelek, akkor nem mozdulnának el a 16 mag irányába AM4-en.
De ne legyen igazam...
-
Legyen igazad, de nem osztom a feltételezésed, illetve nem tudom pozitív megvilágításba helyezni
(értsd: minden rendben van a chiplet-tel, csak a GloFo pöcsöl az IO-die-jal)Ha tényleg az IO die gyártása a szűk keresztmetszet és ezért adott mennyiségű IO die hoz a legtöbb chipletet felhasználó termékeket preferálja az AMD (mert tulajdonképpen ezt mondod) akkor szerintem erre a legjobb megoldás a szerver platformot preferálni induláskor, azzal el lehet érni a chiplet/IO die arányának maximalizálását.
Egy olyan terméket (ZEN2@16c32t@dual channel) kihozni desktopra, ami potenciálisan elveszi a TR4 vevőinek egy részét ( 2950X a threadripper derékhada) mindezt úgy hogy nem is igazi threadripper és komoly limitációkkal küzd, potenciálisan összezavarva a felső szegmens vásárlóit, hát ezt nem tartom jó ötletnek.
Szerintem az lehet a háttérben, hogy nincs meg az órajel és megint belekényszerülnek egy magszám-háborúba...
-
-
-
válasz Petykemano #1087 üzenetére
Ami a naaagy leaket illeti, abból csak az nem jött be eddig, hogy ces.
És hogyan definiálod azt hogy bejött?
Mert az én definícióm szerint még semmi sem jött be. Majd akkor jön be valami, amikor feketén fehéren múlt idővé válik...
-
-
Budapest XIV ker "kocsma mint tranzakciós helyszín"-nel vállal valaki 1db sörre fogadást, hogy lesz-e 16 magos RyZEN bejelentve (konkrét dátummal) ?
-
-
-
-
válasz Petykemano #1313 üzenetére
JohnLook - Monday, June 10, 2019 - link
@Ian Cutress Are you sure the Io dies are on TSMC's 14 & 12 nm processes ?
all info so far was that they were on GloFo's 14 nm ...Reply
Ian Cutress - Monday, June 10, 2019 - link
Sorry, glofo 14 and 12. Matisse IO die is Glofo 12nm. We triple confirmed.https://www.anandtech.com/show/14525/amd-zen-2-microarchitecture-analysis-ryzen-3000-and-epyc-rome
-
-
-
válasz S_x96x_S #2470 üzenetére
Szvsz a legvalószínűbb forgatókönyv, hogy nem jön ki a ZEN3 2021Q1 előtt (erről volt is valami pletyka) és az intel ellátási problémái folyamatosak maradnak egész 2020-ban, ez utóbbit a napokban szerver és notebook gyártó partnerek vezetői is hangoztatták.
Lehet hogy lesz árcsökkentés-kategória eltolás, de én nem hiszem, hogy hirtelen nagy árverseny alakulna ki intel kezdeményezéssel.
[ Szerkesztve ]
-
válasz S_x96x_S #2477 üzenetére
vagy csak paper launch lesz ... vagy csak limitált launch lesz ...
Ilyet 2019-ben láttunk már párat az inteltől, az AMD is megcsinálhatja, de attól a paper launch még nem lesz igazi launch...
Egy kiállításon nagyot ígérni 3/4-1 évvel előre sokkal könnyebb, mint azt ténylegesen megvalósítani, de ettől még remélem, hogy neked lesz igazad, és év vége előtt ténylegesen elérhető lesz a ZEN3. Asztalon is.
Kéne egy felmérést csinálni, hogy aszimmetrikus-s az intel és AMD között migráló munkavállalók miatti tudás transzfer...
-
-
-
válasz Petykemano #2506 üzenetére
A 3800X-3600X versenyképes pozícióba kerülnek házon belül. Ilyen árak mellett, ha a 3700X-3800X között gondolkodnék, már az utóbbit választanám...
-
válasz S_x96x_S #2504 üzenetére
Ennek az AMD számára egy olyan pozitív hozadéka lehet, hogy a Cisco a meglehetősen komoly Cisco UCS szerverkínálatába beépít AMD-s gépeket is.
https://www.cisco.com/c/en/us/products/servers-unified-computing/index.html
-
-
válasz Petykemano #2581 üzenetére
A kérdés az, hogy dupla olyan jó termékekkel fél áron lehet-e negyed éves 0.2 százalékpontnál gyorsabban piacot szerezni, illetve ha majd az intel felzárkózik és mondjuk csak 30% lemaradása lesz másfélszeres áron, akkor az AMD meg tudja-e tartani a negyed évenként szerzett 0.2%-plusszát...
-
-
https://www.macrumors.com/2020/02/07/macos-catalina-amd-apu-references/
Simid: az eredmény
[ Szerkesztve ]
-
-
-
-
válasz S_x96x_S #2612 üzenetére
Minden olyan programnál, amit AVX-512 támogatással fordítottak
Feltételezem a gyakorlatban, ez leginkább csak bencsmárkokat jelent.
Az AMD-nek szerintem nem az lesz itt a baja, hogy az intel tud AVX512-t, ők meg csak 256 bites AVX-et, hanem a legtöbb problémás esetben az, hogy az intel procit a dispatcher ráviszi a legjobb AVX kódra, az AMD pedig a skalár kódot futtatja pedig tudna elég komoly órajel (és magszám előny mellett) mellett AVX2-t is. Az hogy az AVX kódot is az aktuális intelre felépítésre optimalizálták és nem AMD-re az már részletkérdés, ha az AMD ráfut a vektor kódra.
Ha ránézel a magszámokra, AVX-órajelekre, cache méretre és a teljes processzor memória sávszélességére, akkor szerintem nem az AMD-nek van szüksége AVX512-re, hogy pariban legyen az intellel, hanem az intelnek van szüksége az AVX512-re hogy egyrészt legyen valami marketingfegyvere illetve ne verje agyon a ZEN2/3, ha az éppen ráfut egy több szálon végrehajtott AVX2 kódra.
Mondom ezt úgy, hogy AVX512-vel még nem volt dolgom, és SSE/AVX-szel is csak pár egyszerűbb kódot írtam (önképzés jelleggel hobbiból), tehát ha valaki jobban rálát a dologra javítson ki
[ Szerkesztve ]
-
válasz joysefke #2618 üzenetére
Konkrétan ezekről az "anomáliákról" beszélek:
https://www.reddit.com/r/matlab/comments/dxn38s/howto_force_matlab_to_use_a_fast_codepath_on_amd/
-
válasz Cathulhu #2620 üzenetére
Az MKL az intel sajat, zart forrasu kodja, kb termeszetes, hogy bunteti a nem intel procikat, de ennek semmi koze az 512-hoz, hiszen a legtobb intel proci se tamogatja azt.
Pontosan erről beszélek. Amikor vektorkódnál hátrányban van az AMD akkor nem azért van hátrányban mert "csak" AVX2-t támogat és nem AVX512-t mint a legmodernebb szerver/ws intelek, hanem azért, mert az AMD-proci nem fog ráfutni a számára legoptimálisabb kódútra, hanem egy csomó szoftverben skalár kódot fog végrehajtani, pedig futtathatná az AVX2-es kódutat is. ez az igazi hátrány
Ezen a problémán nem egy esetleges AVX512 támogatás fog segíteni, hanem ilyen olyan módon rá kell bírniuk a szoftvergyártókat, hogy gondoskodjanak róla, hogy az AMD is az AVX kódot futtassa, ha ez nem megoldható MKL alapon, akkor más libraryt kell keresni.
Nemelyik fordito kepes skalar kodot automatikusan vektorizalt kodra optimalizalni, es ehhez nincs szukseg a programozonak explicit SIMD kodot irnia, a forditonak kell eleg intelligensnek lennie (es itt megint felmerul az ICC partatlansaga).
A fordító soha nem fog helyetted vektorkódot írni.
Egyszerű for ciklusokat fog automatikusan unrollolni, ha nem érzékel az egymás után következő ciklusok között függőséget/branchelést, illetve egy csomó alap fgv van még vektorizálva (pld egy némely stringművelet).
Egy "skalár megírt Cinebench"-ből semmilyen fordító nem fog CB20-at csinálni...
[ Szerkesztve ]
-
-
válasz Cathulhu #2620 üzenetére
Nem értem hogy egyáltalán min vitatkozunk. Azt sem értem, hogy mi a problémád az unrollingra írt két mondatommal.
Ha jobban tudod, hogy mi az unrolling, akkor kérlek írd le, hogy hol a probléma a kijelentésemmel és ne wikipediát idézz, mert én akkor meg a Mestert idézem: https://www.agner.org/optimize/optimizing_cpp.pdf (c.h 12.3)
Tehát még egyszer: A loop unrolling sok minden optimalizációra (lehet) jó, ezek közül az egyik, hogy lehetőséget ad(hat) automatikus vektorizálásra, mivel több (2-4-8-16 attól függően hogy mennyi adatelem fér egy vektorba) skalár adaton végzett ciklustörzset egyesít egy nagyobb ciklustörzzsé, ahol az egy-egy skalár adaton végzett műveletet helyettesíteni lehet nagyobb vektorműveletekkel.
Lehet hogy te arra gondoltál, hogy egy konstans hosszúságú loop
Ahhoz hogy ez a fordító által automatikusan megvalósítható legyen a kódnak egyszerűnek kell lennie: az egymás után következő ciklusok között csak könnyen feloldható függőség lehet. Bonyolult függőségeket és branchelést nem fog tudni magától feloldani/kezelni a fordító.
Attól függetlenül, hogy a compiler bizonyos egyszerű skalár kódrészleteket (pld for ciklussal egyenként végiggyalogolok egy tömb összes elemén és hozzáadok az aktuális elemhez valami konstansot) hatékonyan tud vektorizálni, ennek még zéró köze van egy SIMD- utasításokat használva kézzel optimalizált kódhoz.
Erre mondtam azt, hogy ha Pistike ír mondjuk egyszerű képmanipulációs szoftvert skalár műveletekkel, mondjuk egy Sepia filtert, ami ugye az egyik legegyszerűbb RGB adatokon dolgozó algoritmus, a compiler nem fog tudni a skalár kódból érdemi SIMD kódot generálni.
Az ok pedig annyi, hogy a hatékony SIMD kódhoz elengedhetetlen, hogy a bemeneti és köztes adatok struktúráját hozzáigazítsd a vektoros feldolgozáshoz. Ez nagy munka. Az RGBA adatokat pld transzponálni kell, hogy a bemeneti [RGBARGBARGBARGBA] helyett kapj valami ilyet:
[RRRR] [GGGG] [BBBB] [RRRR] [GGGG] [BBBB] stb stb (az A alapvetően nem kell a szépiához).Aztán ott van a branchelés. Ha a módosított képen valamelyik színkomponens nem 0-255 közé esik, akkor csonkolni kell. Ezt sem fogja tudni érdemben automatikusan skalárról vektorra fordítani a compiler.
stb stb stbAz MKL az intel sajat, zart forrasu kodja, kb termeszetes, hogy bunteti a nem intel procikat
Nem, nem természetes. Itt arról van szó, hogy ha a dispatcher nem intel procit detektál, akkor rá sem engedi az AVX2 kódra, akkor sem, ha a proci egyébként támogatja azt.
Ennyi erővel az intel fgv könyvtárak akár az x86-os kódot is tilthatnák AMD-n.
Egyébként attól, hogy egy kódot AVX2 -t használva írtak meg, az még nem lesz önmagában ideális egyszerre Skylakere és mondjuk ZEN2-re.
Az intel nyilván a saját AVX2-t tudó processzoraira fogja az AVX2 -t használó kódrészletet optimalizálni. Figyelembe veszi az L1/L2 cache méretét asszociativitását, adott SIMD utasításból hányat tud egyszerre végrehajtani a mag és mekkora az utasítás késleltetése stb. A sebességet mérik is, és nyilván úgy csiszolják, hogy a legjobb legyen a saját procijuknak. Tehát az AMD proci itt is hátrányban lenne, de legalább nincsen szándékosan kigáncsolva. (mintha skalár kódot futtatna enyhén szuboptimális vektorkód helyett)Tehát én azt várnám el az ilyen gyártói fgv könyvtáraktól, hogy ha a konkurens processzor tudja a szükséges utasításkészletet, akkor az is fusson rá az optimalizált útvonalra.
A fenti hosszú irományom lényege pedig az, hogy semmilyen compiler nem fog saját kútfőből skalár kódból vektor kódot csinálni eltekintve pár low hanging fruit leszedésétől.
[ Szerkesztve ]
-
válasz joysefke #2626 üzenetére
disclamer:
mielőtt valaki azt hiszi, hogy valami SIMD veterán vagyok: csak a .NET Core 3.0 kapcsán játszottam vele (unsafe c# +intrinsics) illetve olvastam el pár könnyedebb SIMD/assembly optimalizációs könyvet. Pld a fenti linken
De amiket leírtam alapvetően alapvetések.[ Szerkesztve ]
-
válasz Petykemano #2630 üzenetére
semmit
-
3. Has your child asked for new hardware?
Computer hackers are often limited by conventional computer hardware. They may request "faster" video cards, and larger hard drives, or even more memory. If your son starts requesting these devices, it is possible that he has a legitimate need. You can best ensure that you are buying legal, trustworthy hardware by only buying replacement parts from your computer's manufacturer.
If your son has requested a new "processor" from a company called "AMD", this is genuine cause for alarm. AMD is a third-world based company who make inferior, "knock-off" copies of American processor chips. They use child labor extensively in their third world sweatshops, and they deliberately disable the security features that American processor makers, such as Intel, use to prevent hacking. AMD chips are never sold in stores, and you will most likely be told that you have to order them from internet sites. Do not buy this chip! This is one request that you must refuse your son, if you are to have any hope of raising him well.[ Szerkesztve ]
-
válasz S_x96x_S #2679 üzenetére
de pl. a leendő konzolos célhardvernél : PS5 APU-ja ( ahol a pc-s szűk keresztmetszeteket kezelték és minimális szoftveres overhead van ) már elég jó a helyzet - szerintem lesz pár olyan játék, aminél leesik az állunk.
A PS5 vagy Next-Box APU-ja nem azért lesz gyors mert "minimális szoftveres overhead van" vagy mert a PC-s overhead számottevő vagy lényegesen nagyobb lenne (ezt is kötve hiszem) hanem azért mert egy R5 3600-nál erősebb CPU mellé kerül egy bika GPU sok és gyors memóriával ráadásul az első években jó ha nullszaldós lesz a hardware.
Magyarul azért mert relatíve erős hardver kerül az új konzolokba, ennek köze nincsen semmilyen "kisebb overheadhez"
[ Szerkesztve ]
-
válasz Cathulhu #2719 üzenetére
Itt van egy másik, dupla akkora gép ugyanennek a hétnek a termése:
https://www.computerbase.de/2020-02/hpe-apollo-9000-hawk-supercomputer-24-petaflops-amd-epyc-rome-7742/ -
válasz Petykemano #2731 üzenetére
Elsősorban azért mert AMD. Egyébként ez a most üzembe helyezett gép Németország leggyorsabb szuperszámítógépe és 5-ik a toplistán.
Nyilván ha intel lenne az az intel hatalmas részesedését a sz.számgép piacon figyelembe véve nem lenne hír.
Egyébként most nyert egy intel alapú pályázat egy német szuperszámítógép tenderen a legnagyobb áramzabáló Xeonokra alapozva. Van némi felzúdulás, "hogy ezt hogyan"...
Erről van szó: https://insidehpc.com/2020/01/intel-powers-hlrn-iv-supercomputer-at-zib-in-germany/
Hát mégis léteznek az 56-magos Xeonok[ Szerkesztve ]
-
válasz Petykemano #2740 üzenetére
Fene se tudja, lehet az OEM gyártók előre lefoglalnak notebook és szerver chipeket a majdani termékpalettához. Ezt az AMD és TSMC már tényleges keresletként tudja elkönyvelni.
Az intel tavalyi bénázását és jelenlegi szállítási nehézségeit figyelembe véve elképzelhető, hogy néhány gyártó hosszú távra tervezhetővé akarja tenni ez ellástái láncot és nem ad hoc rendelgetni a legkritikusabb komponensből (processzor).
Aztán lehet hogy szimpla elírás és a "sima" 7nm ZEN-ről van szó...
[ Szerkesztve ]
-
válasz Petykemano #2756 üzenetére
Notably, for the first time, Intel is not inside. We are not using their hardware for any major server components such as the CPU, board, memory, storage, network interface card (or any type of accelerator). Given how critical Intel is to our industry, this would until recently have been unimaginable, and is in contrast with prior generations which made extensive use of their hardware.
Ilyet nem szoktak egy partnerről csak úgy írni: kicsit gúnyolódás szaga van a Cloudflare részéről -
Azért mert a világ komoly szoftvereinek jelentős része x86-on fut.
-
válasz Petykemano #2777 üzenetére
A kínaiak sosem volt jók új dolgok fejlesztésében. Viszont remekül másoltak.
A második mondat igaz, ez első színtiszta butaság.
A másolás legfőbb oka, hogy addig amíg nem jutottál el tudásban, technikában, designban (és egy kicsit szabadalmi jogban) oda ahol az aktuális élvonal van, addig sokkal egyszerűbb, olcsóbb és hatékonyabb másolni mint eredetit tervezni/gyártani.
[ Szerkesztve ]
-
válasz Petykemano #2799 üzenetére
Ugyan. A szó ingyen van még a topmanager szájából is, a munkaóra pedig pénzbe kerül még ha csak a konyhát kell felmosni.
Majd ha ez valami kívánatos dologban tényleg lényegesen jobb lesz mint az x86, akkor elgondolkodnak rajta. Addig megy a szócséplés meg a diák.
[ Szerkesztve ]
-
válasz Petykemano #2804 üzenetére
Az hogy az Apple már sikeresen váltott architektúrát kétszer, az még nem jelenti azt, hogy az harmadszorra is sikerülni fog. a lényeges különbség a PowerPc -> x86 és a jelenleg lebegtetett x86 -> ARM váltás között, hogy az első váltás nem csak elsődlegesen az Apple, hanem a userek számára is kívánatos volt: lényegesen magasabb üzemidő, jóval gyorsabb gép.
A jelenlegi váltás elsősorban az Apple-nek lenne hasznos (drága x86 chipek helyett saját tervezés/gyártás és ezzel lényegesen magasabb haszonkulcs és nem lennének az intelnek kiszolgáltatva). A user a jelenlegi váltásnak csak minimális előnyét látná: minimálisan kitolt üzemidő (a jelenlegi elég jó üzemidőről még egy picit jobb üzemidőre) ami nem lesz akkora durranás mint amikor az x86-tal elérték a már használható üzemidőt. Cserébe valószínűleg lassabb lenne mint az x86 és jönnének a szoftver kompatibilitási problémák.
Én egy lyukas garast nem tennék rá, hogy a lifestyle laptopok kivételével elfogadja a vásárlóközönség az architektúra váltást (illetve annak következményeit). Azoknak a felhasználói pedig aligha fognak olyan szoftvereket írni ami majd pont a szerver vonalat mozdítja át x86-ról ARM-re...
[ Szerkesztve ]
-
válasz S_x96x_S #2814 üzenetére
Ezeknek pont nem kell. Mégpedig azért nem kell, mert a cloud ügyfeleknek (Azure, AWS, Google Cloud Platform, Digital Ocean ügyfelek) akik fizetnek a VM-ért/infrastruktúráért aligha fog mostanában ARM kelleni.
És itt az, hogy az Amazon miket jelent be kb édesmind1 amíg nem tudnak fizető ügyfeleket keríteni. Sosem a nagy bejelentések a szűk keresztmetszet, hanem, hogy a nagy ötletekért kitől lehet pénzt elkérni.
Akiknek kellhet azok a nagy felhő app szolgáltatók (Google-Facebook-Twitter- CDN szolgáltatók ilyesmi) akik a saját x86 alapú infrastruktúrájukat cserélhetnék valami költséghatékonyabbra vagy olyanra amivel kevésbé vannak az intelnek kiszolgáltatva. A FB / Google használót aligha fogja érdekelni, hogy ARM vagy x86 masináról jön a szolgáltatás.
Az infrastruktúrát bérlő vállalati felhasználót viszont nagyon is fogja érdekelni, hogy milyen platformot bérel. Főleg ha saját pénzért kifejlesztett vállalati szoftverei is vannak (amelyek nyilván x86-hoz kötöttek)
[ Szerkesztve ]