Az Intel vezérigazgatója bagatellizálta a „meglehetősen jelentéktelen” ARM PC kihívást

Intel

Egyesek szerint az ARM támadni fog a klasszikus Intel/AMD territóriumnak számító PC piacon is. Az Intel vezérigazgatója, Pat Gelsinger nem lát számottevő fenyegetést.

Csütörtökön a vállalat harmadik negyedéves (Q3) eredményközlőjén Gelsinger bagatellizálta a rivális chipgyártók ARM architektúrára épülő processzorai általi PC-k területén jelentett fenyegetést.

Mint mondta, az összes versenyüket komolyan veszik, de úgy gondolja, hogy a történelem az útmutató ebben a kérdésben és nem látja annyira jelentősnek a fenyegetést összességében. Elemzőknek tett kijelentései kissé ellentmondanak a Microsoftnak, amely múlt héten hivatkozott elemzői kutatásokra, amelyek szerint az ARM PC piaci részesedése jelenlegi 14 százalékról 2027-ig 25 százalékra nő majd.

Gelsinger fenyegetés helyett lehetőséget lát. 2023 áprilisában az Intel stratégiai partnerséget kötött az ARM-mal, amelynek értelmében ARM SoC-ok készülhetnek az Intel gyáraiban.

Míg Gelsinger nem látja az ARM-ot fenyegetésnek, azt mondta, hogy az Intel Foundry Services örömmel dolgozik együtt a chipgyártókkal az architektúrán alapuló chipek gyártásában. "Ha más alternatív architektúrákra gondol, mint például az ARM, azt mondjuk: "Hű, micsoda nagyszerű lehetőség öntödéink számára" - mondta.

A megjegyzések kevesebb, mint egy héttel azután érkeztek, hogy az Intel árfolyama zuhant mert kiderült: az NVIDIA titokban egy ARM-kompatibilis CPU-t fejleszt a PC-piac számára, amely akár 2025-ben meg is jelenhet.

A pletykákon túl a Qualcomm ezen a héten egy új SoC-ot mutatott be a PC-piac számára Snapdragon X Elite néven.

Részletek itt.

( zdesigner | 2023. 10. 27., p – 12:44 )

Remélem, hogy úgy járnak, mint a Nokia.

Az jobb lesz, ha két egymás tökét fogó óriás helyett lesz egy nagy, aki maga kezében tartja a szabadalmakat? Akkor már nem inkább a RISC-V-nek kellene drukkolni vagy hogy maradjon még az x86, mint alternatíva?

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Az x86 letezni fog. Ha mas nem, egy legacy piacon.

Kerdes, hogy a fopiac (amire a sok subscription modeles online cloud activationos adware-es szart leforditjak profitmaximalizalas tapasztaltabb modszereit alkalmazva - es mindezt egy eszkoz egy OS zart bootloader technikat alkalmazva) az mi lesz?

A Nokia Symbianon nem futtattak ennyi ertekes legacy kodot. Kezdetnek, hogy miert orok az x86, a 90s, 00s jatekokat hoznam peldanak. Ezek kezzel foghatoak, de a hires banki Fortran es Cobol penzt hozo legacy rendszerekrol se feledkezzunk meg - azok is van, hogy csak x86-ra fordulnak. Azok piacaert meg komolyan versenyben sem kell lenni, de valamit azert gyartani kell, mert a qemu frontendek is evtizedek ota nem tudnak egy minimalis felhasznalobaratsagot megugrani.

Az Apple-t meg ahogy ismerem, 2028-ban kijovo macOS-ben mar nem is lesz Rosetta2 x64 binarist futtatni kb.

de a hires banki Fortran es Cobol penzt hozo legacy rendszerekrol se feledkezzunk meg - azok is van, hogy csak x86-ra fordulnak.

Azok inkább System/390-re és hasonló architektúrákra íródtak, nem x86-ra. A Javaban megírt kódok meg hordozhatók, éltem át svájci banknál SPARC->X86 váltást, zökkenőmentes volt.

( x-daemon | 2023. 10. 27., p – 13:02 )

"az ARM PC piaci részesedése jelenlegi 14 százalék"

ez most mi is? mit lehet kapni ami armos pc? erdekelne mik ezek.

feltetelezem nem apple, mert az nem pc, ha jol ertelmezem.

neked aztan fura humorod van...

( DirtY_iCE | 2023. 10. 27., p – 13:10 )

Copy-paste ide a tegnapi Musk-os cikket

I hate myself, because I'm not open-source.

( persicsb | 2023. 10. 27., p – 14:49 )

Szerkesztve: 2023. 10. 27., p – 14:50

Amíg a legtöbb ARM platform képtelen UEFI-ről vagy bármi más szabványos dologról bootolni, és minden lapkának külön bootloader kell, addig tényleg nincs félnivalója az Intelnek. Az x86 platformnak ez egy nagy előnye: UEFI, ACPI, PCI Express és társai alaplapfüggetlenné teszik a kerneleket, a bootfolyamatot, a perifériákkal való interfészelést.

Baromi nagy szívás, hogy ARM board esetén mindenhova külön BSP kell.

UEFI-ről biztos nem fognak az arm-os szarok bootolni, mert az UEFI-t az Intel írta a ratyi processzoraihoz, hogy el tudjanak egyáltalán indulni és ne szívjanak a 30éve kitalált bios szabványok miatt. ARM-on végülis nincs ilyesmire szükség mert a perifériák inicializálhatóak az első fázisú rendszerbetöltőből, de valóban jó lenne valami egységes dolog erre.

"UEFI-ről biztos nem fognak az arm-os szarok bootolni"

Akkor még nem láttál ilyet. Pedig van, csak nem ez az alap és még nem elterjedt. De az Arm tereli efelé a népet.

https://developer.arm.com/Architectures/Unified%20Extensible%20Firmware…

Arm-based systems that are compliant to the SBBR recipe of the Base Boot Requirements (BBR) specification are required to support some of the interfaces in the UEFI specification developed by the UEFI Forum.

UEFI-ről biztos nem fognak az arm-os szarok bootolni

Valóban nem "fognak", hanem már teszik (sajnos).

Az x86 platformnak ez egy nagy előnye: UEFI,

Tévedésben élsz. Az UEFI egyetlen célja, hogy M$ vendor lock-in legyen, de még csak erre sem képes. Minden más csak parasztvakítás meg marketing bullshit. Egyébként meg nem egységes, és csupa bug az egész. Hadd ne soroljam, mi mindenbe futok bele nap, mint nap.

ACPI

Több évtized után még mindig képtelenek a gyártók olyan AML-t adni a gépeikhez, ami ne lenne szar. Ez nem csak az ő hibájuk, az UEFI specifikáció és az ACPI specifikáció minősége a béka segge alatt van.
(Konkrétan abban a gépben, amiről ezt írom, egy olyan gyári DSDT van, ami definiálatlan változóra hivatkozik. Szar a spec, de azért ez nem a spec sara, hanem a gyártóé.)

PCI Express

Semmi köze a procihoz, PCIe van ARM-on is.

alaplapfüggetlenné teszik a kerneleket

De szép is lenne! A kernelek egyébként lófaszt sem tudnak kezdeni az UEFI nyújtotta interfészekkel, csak szólok (a legtöbb BootTime Service ugyanis). Az ACPI-t meg inkább ne is használd, ha jót akarsz, tele van 0day sebezhetőségekkel.

a bootfolyamatot

Hát nagyon nem.

Baromi nagy szívás, hogy ARM board esetén mindenhova külön BSP kell.

BSP minden SMP rendszerben van, Intel-en is. ARM-on legalább tudhatod, hogy mindig a 0-ás id-jű mag a BSP, míg intel szottynál matathatod az AML-t, leképzheted az lAPIC-ot, MMIO regiszter olvasás, csakhogy megtudd, melyik is az. x2APIC annyival jobb, hogy ott csak MSR-ekkel kell szarakodni... Már persze feltéve, ha a cpuid jól jelenti le, mert sokszor bugos az is.

valóban jó lenne valami egységes dolog erre

Jaja, az nem ártana. Meg Inteles gépeken se lenne baj, ha lenne ilyen. De a RISC-V esetében is egy kihagyott ziccer, hogy megfeledkeztek erről (az OpenSBI egy vicc, használhatatlan).

Aha, ha ezt érted alatta, na ilyenje az Intelnek sincs már (volt, mert a BIOS pont tudta ezt, az UEFI meg nem). És egyébként is, az a BSP egy szoftveres réteg, nem hardveres, szóval proci független.

A BIOS-nak sok nyűgje volt, nem vitatom, de az legalább tényleg egy egységes, gyártófüggetlen alapszintű kimenti / bemeneti interfészt adott, amit használhattak a kernelek (igen, az szopó, hogy valós módú, de ezt még a XFree86 is megoldotta egy nyúlfarknyi x86emu libbel, szóval annyira nem para. Egy AML bájtkód interpreter sokkal macerásabb, több helyet igényel, és azt is emulálni kell, mindenképp.)

( zaphodb v | 2023. 10. 27., p – 15:22 )

Szerkesztve: 2023. 10. 27., p – 15:40

ARM Market Cap 51B Revenue 2,6B, a 60-ra ugró IPO után 50 körül karistol, ez lehet feleennyi és dupla is, de nem egy erős nyitás. P/E egekben.

Intel 136B 54B, 1-Year Change 19.51%, 28-on vettem, nem adtam el most 38-ért, mert ha fizeti az 5% osztalékot, akkor majd 50-en, de így (csökkentették az osztalékot) már 40-ért is eladnám. Árfolyama historikusan kb féláron. Nagy kormány támogatással, ami talán 1-2 év alatt befut. CHIPS Act, Made in America vs Taiwan. Többihez képest sok részvénye forog. szerk.: Tegnapi jelentés után ugrott 10%-ot.

AMD 151B 22B (nagyobb kapitalizáció mellett kisebb bevétel, persze tudni kéne mellé a kiadást is), 1-Year Change 56.82%, jóval kevesebb részvény forog mint Intel, top árának inkább 2/3-ánál.

NVIDIA 996B 32B (~7x akkora mint Intel, de csak feleannyit termel, bár nyilván fejleszt is), 1-Year Change 212.7%, 5 éves grafikon "közel" (-20%) top áron.

nincs aláírásom

Ne a céget, hanem a technológiát hasonlítsd össze. Az Intel és AMD ugyanúgy x86-os, viszont az ARM, mint CPU architektúra, az Apple M és A szériás cpujától kezdve szinte minden okostelóban ott van Marvell, Samsung, Snapdragon vagy bármi hasonló ARM IP alapú történettel. Egyelőre a desktop (mint klasszikusan számítógépként használt notebook és macmini) fronton valszin az Apple tartja az ARM-os vonal jelentős részét.

Az Intel már egyszer lesajnálta az AMD-t, és most eléggé kapaszkodnak, pláne miután kaptak egy pofont az Apple-től, aki saját CPU design felé ment.

Az Intel elavult. Az utasitaskeszletuk regi, a cpu nagyon sok atalakitast vegez a kodon, de a rengeteg, utasitasok kozotti zavaros fugges miatt ez korlatozott. Az ARM64 uj, es nagyon jol atgondolt. Ez a gyakorlatban azt jelenti, hogy azonyos bonyolultsagi szinten az ARM nyer. Az Intelnek meg van par ev elonye, de a tovabbfejlodes irdatlan sokba kerul. Az ARMnak a fejlett utasitaskeszlet miatt toredekebe. Tehat azonos osszegbol az ARM messzebb jut, es idovel egyszeruen legyozi az Intelt. Hacsak nem dobja az Intel az x86-ot, es csinal egy uj utasitaskeszletet, ami emulalja a regit.

Az Intel elavult.

Miért is? Hogy lehetne már egy dinamikusan bővíthető utasításkészlet elavult?

a cpu nagyon sok atalakitast vegez a kodon, de a rengeteg, utasitasok kozotti zavaros fugges miatt ez korlatozott

Erre tudnál konkrét példát hozni? Akárhogy bújom az Intel Developer's Manual-t, nem látom ezt.

Az ARM64 uj, es nagyon jol atgondolt.

Ezt könnyedén meg tudom cáfolni. Írtál már ARM disassemblert? Én igen. Több, mint 1200 összevissza utasítás (8v2 esetén legalábbis), és a kódolásra sokminden mondható, csak az nem, hogy jól átgondolt.
Nézd csak meg a DecodeBitMasks eljárást! Majd szólj, hányadik olvasásra sikerült értelmezned az "imm" fejezetet a linken.

Such an immediate is a 32-bit or 64-bit pattern viewed as a vector of identical elements of size e = 2, 4, 8, 16, 32, or 64 bits.
Each element contains the same sub-pattern: a single run of 1 to e-1 non-zero bits, rotated by 0 to e-1 bits. This mechanism can
generate 5,334 unique 64-bit patterns (as 2,667 pairs of pattern and their bitwise inverse).
Hacsak nem dobja az Intel az x86-ot, es csinal egy uj utasitaskeszletet, ami emulalja a regit.

Aligha, már konkrétan megpróbálta ezt (IA), hatalmas bukta lett belőle.

Ne érts fére, szerintem is jobb az ARM az x86-nál sok szempontból, csak épp nem azok miatt, amiket felsoroltál.

Mondjuk ez az imm IMHO teljesen ertheto, bar teny, hogy lehetne egyszerusiteni: '1 to e-1 non-zero bits'  -ben a non-zero helyett lehetne 1 -et mondani, vagy a 'rotated by' helyett az elterjedtebb 'followed by' -t hasznalni - de alapvetoen azert irjak igy, mert szakszavak ebben a niche market-ben.

Jogos. De elsősorban nem a megfogalmazásra gondoltam, hanem arra, hogy csupán ezen leírás alapján próbáld meg helyesen leimplementálni (mint ahogy nekem kellett volna a disassemblerhez)! Szerintem képtelenség.

Végül a DDI0487 egyik mellékletében találtam egy pszeudo-kódot, ami megvilágosított. Persze hibás volt az is, nem lehetett használni egy-az-egyben, de szerencsére kiadott az ARM egy errata-t, na végül azzal együtt a kettőből sikerült összehozni.
Az érdekesség kedvéért, ez egyébként a helyes eredményt adó DecodeBitMasks kód:

uint64_t disasm_dbm(int k, int j, int i) {
  int e=(k<<6)|(~j&0x3F), l=6;
  uint64_t m, r;

  while(l>=0 && !(e&(1<<l))) {
    l--;
  }
  if(l<1) return -1;
  e = 1<<l;
  l = e-1;
  j &= l;
  i &= l;
  if(j==l) return -1;
  m = ~0UL>>(64-(j+1));
  m = (m>>i)|(m<<(e-i));
  r = m;
  i = e;
  while(i<64) {
    r |= (m<<i);
    i += e;
  }
  return r;
}

Hát szerintem nagyon nem olyan, mint amire a fenti leírás alapján gondoltál volna.

Itt ne azt nezd hogy C/C++/pszeudokod/barmiben hogyan es mennyire bonyolultan tudod leprogramozni hanem azt hogy abbol a 13 bitbol (lasd: {N, imms[5:0], immr[5:0] }) hogyan, milyen kombinacios logikai halozattal tudod eloallitani a 64 bites kimenetet. Az lesz joval egyszerubb, mint amit gondolnal :) Eleve ezek a trukkok amik benne vannak (pl nem kell az "e" szelessegu mezoket egyesevel rotalnod majd utana osszeraknod, hanem osszepakolod a 64 bites kimenetet {K{N'b00...11111}} modon, majd azt rotalod, stbstb), plusz maga az imms-enkodolas is azt implikalja hogy egy prioritas-dekoderrel szedi szet a biteket es nem csak ugy durr bele a vakvilagba van ott az "e" erteke. Ez az egesz Verilogban kb 2-3 jol definialt sor lehet, ahol az ALU tobbi egyseget siman ujrahasznosithatja az RTL realizacio (akar ugy is hogy az egesz fenti decoding az 2 pipeline stage, es a masodik az csak egy rotator ami barmit megrotal, nem csak ezt). Na, ezt nyilvan nem kotik az orrunkra :) 

Kicsit forditva megfogalmazva: nem azert hangzik ilyen eroltetett bonyolultnak-bikkfanyelvunek ez a megfogalmazas mert teged akarnak szivatni, nem azert erthetetlenul hosszu a pszeudokod mert teged akarnak szivatni hanem azert mert az a 2-3 elemi logikai aramkor ami kibontja az adott inputot a megfelelo outputra az konkretan igy viselkedik. A maradek 8192-5334 = 2858 code point eseteben is valamit fog majd csinalni ez az egyszeru logika, de azt sem kotik az orrodra. Ezt hivjak ugy hogy "undefined behavior". 

azert mert az a 2-3 elemi logikai aramkor ami kibontja az adott inputot a megfelelo outputra az konkretan igy viselkedik.

Pontosan erről beszélek én is. Szó sincs jól átgondolt utasításkészletről, kényszerből lett olyan, amilyen, nem pedig elgondolás miatt. (Ellenben Intelnél mikrokód szolgáltatja az utasításokat, így ott lehet szó elgondolásról, mivel ott nem köti a kezüket direktben az áramkör. Pont emilatt nem lehet elavultnak nevezni az utasításkészletét se, hisz az dinamikusan bármikor bővíthető.)

Az is nyilvánvaló, hogy ezért az agyhalott és nyakatekert utasítkódolásért cserébe kevesebb tranzisztort igényel a megépítése, pont emiatt tud energiatakarékosabb és gyorsabb lenni egy ARM, mint az azonos órajelű konkurencia.

ps: ha akarná, az Intel egyetlen mikrokódfrissítéssel átállhatna ARM utasításkészletre (valószínűleg ez is állhat a cikkindító kijelentés mögött). Ami miatt mégsem teszik ezt meg szerintem: a) nem akarnak jogdíjat fizetni az ARM-nek, b) egy ilyen megoldás minden összehasonlításban és mérésben alulmaradna az ARM direktben huzalozott procijaival szemben.

ezért az agyhalott és nyakatekert utasítkódolásért cserébe kevesebb tranzisztort igényel a megépítése,.

Pedig pont ettol lett jol atgondolt ez az utasitaskeszlet! Egy ISA-nal csak ez szamit, mas nem. A dekodolast meg egy szög egyszerusegu assembler is meg tudja csinalni - nemhogy egy romma optimalizalt C/C++ fordito ami megjobban ki tudja hasznalni ezeket a bitfieldeket.

Nem mondom hogy nincsenek furcsa dolgok az ARM ISA-kban, de az nem ez. Az immediate encodig az minden architekturanal egy kulon muveszet/mufaj, by def nem lehet egyszerű. 

Pedig pont ettol lett jol atgondolt ez az utasitaskeszlet!

Tévedés! Logikai áramkör szintjén valóban jó, de utasításkészlet szintjén pont emiatt nem jó! Utasításkészletről volt szó.

A dekodolast meg egy szög egyszerusegu assembler is meg tudja csinalni

Szintén téves! A legismertebb ARM asszemblerek (pl. gnu-as 2,4M) és diszasszemblerek (pl. capstone, 2M) jellemzően több megányi kódmonstrumok (!). Még a legtutibb, direkt Assembly-ben kézzel írt asszembler, a fasm-arm is fél megás!

Nekem is csak úgy sikerült 60-70k-ba belezsúfolnom, hogy írtam egy programot, ami úgy generálja ki a diszasszembláló forrását egy utasítástábla alapján és közben mindenféle durva optimalizációkat hajt végre meg patterneket keres a bitmaszkokban hogy összevonja, amit lehet. Egyáltalán nem mondhati rá, hogy "szög egyszerűségű"!

nemhogy egy romma optimalizalt C/C++ fordito ami megjobban ki tudja hasznalni ezeket a bitfieldeket.

Csakhogy ez nem igaz! A fordító pont hogy bonyolutabb lesz emiatt nem egyszerűbb, és elfeledkezel arról is, hogy ennek vonzatai vannak. Az ELF formátumban például több, mint 130 féle relokációs rekorda van szükség a leírásához, ami jelentősen növeli a fordító (gcc, as), a linker (ld) valamint még a shared lib betöltő (vdso) összetettségét is! Az egész ökoszisztémára kihatással van. (Összehasonlításképp x86_64-nál sokkal kevesebb, kb. 40 féle van csak, ráadásul ennek kétharmada annyiban tér el, hogy relatív-e vagy sem, szóval egyetlen kivonás műveletben különböznek csak egymástól. ARM esetén a 130 alapjaiban eltérő relokációfajta, más felbontású, más bitmaszkú, ketteskomplemensű vagy néha negált, ráadásul még dinamikus cím relatív is lehet, nemcsak PC meg GOT relatív.)

Az immediate encodig az minden architekturanal egy kulon muveszet/mufaj, by def nem lehet egyszerű.

Megintcsak tévedés! Az x86 esetében nincs semmi, minden immediate bájt felbontású, egy egyszerű 16, 32 vagy 64 bites integer, mindenféle mahinálás nélkül.

Mindezek ellenére abban egyetértünk, hogy végső soron megéri ez a bonyolutság. Inkább a fordítási környezet legyen túlbonyolított, de aztán a lefordított programok hatékonyan, kevés energiafelhasználás mellett fussanak, semmint fordítva.
Őszintén megvetem azokat, akik bedőlnek annak a hazugságnak, hogy a fejlesztő ideje a drágább. Nagyon nem, jó esetben a programot egyetlen egyszer írják csak meg, majd évekig használják, így egyértelmű, hogy a működtetésre kell optimalizálni (ami folyamatos), nem pedig a fejlesztés lerövidítésére (ami egyszeri). Ha valaki nem azzal tervez, hogy a használatnak meg kell térítenie a fejlesztési költséget, az egyszerűen hülye. De ez más téma.

A legismertebb ARM asszemblerek (pl. gnu-as 2,4M) és diszasszemblerek (pl. capstone, 2M) jellemzően több megányi kódmonstrumok (!). Még a legtutibb, direkt Assembly-ben kézzel írt asszembler, a fasm-arm is fél megás!

Attól, hogy nagy valami, még nem lesz feltétlenül bonyolult. Csak éppen sok benne a tartalom. És amúgy nem mindegy, hogy egy assembler mekkora méretű? Nem befolyásolja az utasításkészlet milyenségét. Az utasításkészlet milyenségét az befolyásolja, hogy egy magasabb szinten definiált problémát (lehet ez struktogram, programozási nyelv, pszeudikód) milyen hatékonyan tudja végrehajtani az adott architektúra.

Senkit, de senkit nem érdekel, hogy hány megabyte-os egy assembler.

A fordító pont hogy bonyolutabb lesz emiatt nem egyszerűbb

Senkit nem érdekel ez, a lényeg, hogy a kód mennyire hatékonyan hajtódik végre. Fordítani sokkal kevesebbszer fordítunk, mint ahányszor végrehajtunk. Egy ISA-nak nem az a lényege, hogy triviális legyen hozzá fordítót írni, hanem az, hogy hatékonyan működjön.

Az ELF formátumban például több, mint 130 féle relokációs rekorda van szükség a leírásához, ami jelentősen növeli a fordító (gcc, as), a linker (ld) valamint még a shared lib betöltő (vdso) összetettségét is! 

Felőlem lehet benne 1300 rekord is, pont nem érdekel. Főleg, hogy ezek a dolgok legtöbb esetben automatikusan generálhatók magasabb szintű leírókból (mint ahogy hardvert se tranzisztor szinten terveznek, hanem generálnak leírókból).

Ami érdekel: alacsony fogyasztás mellett nagy számítási teljesítmény.

 

Mindezek ellenére abban egyetértünk, hogy végső soron megéri ez a bonyolutság. Inkább a fordítási környezet legyen túlbonyolított, de aztán a lefordított programok hatékonyan, kevés energiafelhasználás mellett fussanak, semmint fordítva.

Pontosan. Senkit, de senkit nem érdekel, hogy a fordító mennyire komplex.

Őszintén megvetem azokat, akik bedőlnek annak a hazugságnak, hogy a fejlesztő ideje a drágább. 

Nem hazugság ez a legtöbb esetben. Ugyanis a legtöbb kódot cégek számára, belső használatú szoftverekre írják. Sokszor az egész szoftvert kevesebb ember használja, mint ahányan a fejlesztésében részt vettek. Például egy középvezetők számára írt ügyviteli szoftvert lehet, hogy 10 ember használ, 1 számítógép szolgálja ki, és dolgoznak rajta 15-en, hogy elkészüljön. És itt egyszerűbb az, hogy az egy szem szerverbe teszünk még 32 GB RAM-ot, minthogy programozói órák százait égessük el arra, hogy szarráoptimalizáljuk a kódot.

Észre kell venni, hogy a szoftverek használati görbéje is long-tail mintát mutat: van nagyon kevés szoftver, amit nagyon-nagyon sok ember használ, és van nagyon-nagyon-nagyon sok olyan szoftver, amit meg pártucat ember. És ezt a nagyon-nagyon-nagyon sok pártucat felhasználós szoftvert nagyon-nagyon-nagyon sok fejlesztő készíti.

Az életemben a legtöbb szoftver, amin dolgoztam, ott a felhasználói szám 500 alatti volt, egyetlen egynek volt egymillió feletti felhasználója.

A szoftver készítése, főleg az ügyviteli szoftvereké, nagyon drága dolog, luxuskiadás - a hardver sokkal olcsóbb ilyen esetekben.

jó esetben a programot egyetlen egyszer írják csak meg

Tipikusan nem igaz ez a belső használatú, ügyviteli szoftverekre. Ezerféle oka van annak, hogy módosítani kell a szoftvert. Változik a céges ügymenet, változik a jogszabály, változik az interfészelés más ügyviteli rendszerekkel stb.

És amúgy nem mindegy, hogy egy assembler mekkora méretű? Nem befolyásolja az utasításkészlet milyenségét.

Fordítva ülsz a lovon. Az utasításkészlet milyensége befolyásolja az asszembler méretét.

Az utasításkészlet milyenségét az befolyásolja, hogy egy magasabb szinten definiált problémát (lehet ez struktogram, programozási nyelv, pszeudikód) milyen hatékonyan tudja végrehajtani az adott architektúra.

Hatalmas tévedés!!! Asszemblerről van szó, amiben nincs is semmiféle magasabb szint! Minden szöveges mnemoniknak van egy egyértelmű bájtkód megfelelője, ezeket konvertálják, ennyit csinálnak csak az asszemblerek, semmi több! Ez a sima szöveg-bináris konvertálás igényel több megás programokat ARM esetén, szó sincs semmilyen magas szintről.

Összehasonlításképp: egy x86-os asszembler kevesebb, mint fél mega, mint pl a flatassembler 275K, a netwide assembler 400K, de még a bloated GNU as is csak 800K.

Sokszor az egész szoftvert kevesebb ember használja, mint ahányan a fejlesztésében részt vettek.

Ja, számszerűen kevesebb ember, csakhogy ők éveken át, naponta többször is futtatják! Kit érdekel, hogy 10 felhasználó futtatja 100-szor, vagy egy felhasználó 1000-szer? Az összes végrehajtás száma fontos csak.

Ez meg simán önellentmondás:

És ezt a nagyon-nagyon-nagyon sok pártucat felhasználós szoftvert nagyon-nagyon-nagyon sok fejlesztő készíti.

Az életemben a legtöbb szoftver, amin dolgoztam, ott a felhasználói szám 500 alatti volt, egyetlen egynek volt egymillió feletti felhasználója.

És azokat a szoftvereket 500, ill. több, mint egymillió programozó készítette? Ugye, hogy nem. Te Magad bizonyítottad, hogy az első állításod nem felel meg a valóságnak (és garantálom, hogy a github/gitlab repók 99.999999999%-ra sem igaz, ott a regrosszabb eset az egy programozó - egy felhasználó - többszöri futtatás).

Ezzel meg sikerült megint önellentmondásba keveredned:

Fordítani sokkal kevesebbszer fordítunk, mint ahányszor végrehajtunk.

Tipikusan nem igaz ez a belső használatú, ügyviteli szoftverekre. Ezerféle oka van annak, hogy módosítani kell a szoftvert.

Semmi értelme ennek, miután Te Magad is beismerted, hogy SOKKAL kevesebbszer kell módosítani és fordítani, mint végrehajtani. Pont. (És ez alól a belső ügyviteli szoftverek sem kivételek!)

Továbbra is érvényes: a végrehajtási idő helyett a fejlesztési időre optimalizálni egyszerűen idiotizmus. Az a szoftver, ahol az összes felhasználó összes futattási ideje nem haladja meg az összes programozó összes ráfordított idejét, egy bukott projekt.

Asszemblerről van szó, amiben nincs is semmiféle magasabb szint!

Najo, de assemblert is azert csinalsz hogy elobb-utobb valami jol definialt problemat megoldj vele :) 

Minden szöveges mnemoniknak van egy egyértelmű bájtkód megfelelője

Valojaban ez sem igaz feltelten, egyreszt mert egy asm mnemonic is mar kodolhat tobb utasitast es kivalaszthatja a fordito hogy melyik a jobb (ez inkabb compressed RISC eseten fordul elo, x86-nal tenyleg kevesse eselyes hogy ilyesmivel talalkozol), masreszt meg az assembler gondoskodhat automatikusan olyasmirol hogy near/far branch-ok megkulonboztetese vagy az immediate value-k optimalizalasa, register ordering es ehhez kapcsolodo aliasok (pl csak a branch-if-less-than feltetelt tamogatja az ISA, de irhatsz bgt x1,x2-t is akar es ebbol blt x2,x1-et csinal az assembler), vagy egyeb hasonlo pseudo-instruction jellegu megoldasok kezelese (amik mar akar asm makroknak is tekinthetoek). 

 Asszemblerről van szó, amiben nincs is semmiféle magasabb szint!

 

Dehogy nincs. Maga a probléma, amit meg akarsz oldani. Ez lehet egy matematikai képlet kiértékelése (numerikus algoritmusok), lehet üzleti adatok tárolása, tranzakciók kezelése, OLAP, OLTP, lehet 3D rendering. Ez maga a probléma, amit a számítógépnek meg kell oldani. Ennek a hatékony megoldására fejlesztik az utasításkészletet.

Ezért is van SSE/AVX/neon, TLS gyorsítás, ezért van az Arm procikban JavaScript végrehajtást segítő utasítás (FJCVTZS), ezért van az x86-ban is utasításszinten BCD támogatás, ezért van 386-tól kezdve string művelet támogatás, ezért van POPCNT. Mert ezek az utasítások jó, ha hardverben vannak, mert erre van szükség. 

Egy utasításkészlet akkor jó, ha minél több dolgot meg tud csinálni gyorsan és hatékonyan hardverből. Ez az a magasabb szint, amiről beszélünk.

Lásd az IBM mainframe-k utasításkészletetét, olyan dolgok vannak hardverben implementálva, amire nem is gondolna egy PC architektúrán nevelkedett ember. https://www.ibm.com/support/pages/sites/default/files/2021-05/SA22-7871…

Van kb. 1300 utasítása a processzornak, kb. 70-féle utasítás kódolás. És ez így van jól. Baromi bonyolult assemblere lehet, de a keletkező kódot a gép hatékonyan, és jól hajtja végre.

 

Összehasonlításképp: egy x86-os asszembler kevesebb, mint fél mega, mint pl a flatassembler 275K, a netwide assembler 400K, de még a bloated GNU as is csak 800K.

Pont nem érdekel senkit, hányszáz/hányezer kilobyte az assembler.

 

Az a szoftver, ahol az összes felhasználó összes futattási ideje nem haladja meg az összes programozó összes ráfordított idejét, egy bukott projekt.

Nem így kell ezt mérni.

Lásd: https://xkcd.com/1205/

Ha valamin 1 másodpercet lehet spórolni, amit naponta használok, akkor 30 percnél többet nem érdemes foglalkozni a spórolás implementálásával, mert 5 év alatt sem hozza be az árát.

csak mondom, ez kb. minden evtizedben elojon, hogy az intelnek vege, mar a 90-es evektol kezdve.

az intel meg mindig itt van.

egyszeruen azert, mert az x86 nem szar, per se. az elavult / evolucios gepi kodnal sokkal fontosabb dolgok is vannak, amik meghataroznak egy procit.

BTW pont az Itanium, ami uj, masszivan parhuzamos vegrehajtast es uj gepi kodot kapott, az intel gyereke / otlete, csak koran kimult.

A masik: intel-nek mar volt ARM-je (strongarm remlik? kb. akkor lottek le, amikor az itanium kimult), es alapvetoen egy ilyen kvalitasu gyartonak par ev lenne felfuttatni egy arm alapu architekturat.

No és? Ott indulunk, hogy a klasszik PC bazira nehezen lesz bárhonnan kiszorítható, amíg a főablakos sztori azon megy, és a fő szuperalkalmazások szintén. Az Apple-ös vonal nem számít, mert ha már másik OS, akkor végülis a cpu arch sem akkora ugrás.

Hiába van technológiai főlény, már 20-30 éve is ezt hallgattuk, hogy hú a power, hogy az arm, (a RISC) az majd jön, lát és győz.  A helyzet látható. Az okos eszközökkel, és hathatós Linux hátszéllel sikerült széleskörben terjednie az ARM-nak, és most az Apple tolja. A szerveres vonal ugyan létezik ARM-ból, de marginálisnak tekinthető.

( dyra | 2023. 10. 29., v – 20:08 )

Hát pedig csak annyi kell hogy beinduljon a hype. Aztán desktopon annyi is van nekik. 10 év és réteg cucc lesz tökmindegy jók-e vagy sem. Mennyi ilyet láttunk az utóbbi években. Telefonoknál, autóknál, szoftvereknel, szolgáltatásokban. Jön valami új aztán elindul a közbeszéd ez sokkal jobb sokkal zöldebb szevasz is van nekik. 

Szerintem a Microsoft-on és a Windows-on fog múlni. Ahogy a bevezetőben linkelt cikk is írja, az Nvidia Windows-PC-be való ARM CPU-t fejleszt. Speciell ezt nem nagyon értem, mert szerintem minden eddigi ARM SoC-uk is alkalmas Windows futtatására, csak valakinek neki kéne esnie a portolásnak. Az lesz nagy durranás, amikor valaki egy komplett PC-t mutat be ARM-on futó Windows-zal. Gondolom, erre készül az Nvidia. Kérdés, hogy a Microsoft fogja-e támogatni őket.