Portatili ARM rivoluzioneranno il mercato con autonomie mai viste, secondo Microsoft

[s-y]

proprio perchè, potenzialmente, sarebbe un cambiamento epocale, probabilmente non si farebbero prigionieri. tutta da seguire per quanto mi riguarda.
alla fine può essere una specie di naturale evoluzione della 'crisi' del pc, che già di suo è un fattore in grado di spostare equilibri che potevano sembrare immutabili

[Piedone1113]

Originariamente inviato da CrapaDiLegno

Non so se hai capito l'articolo, ma il tema del discorso è l'emulazione.
I portatili con processore ARM ci sono già sul mercato, e si chiamano Chromebook. E il loro maggiore limite indovina qual è?
Già, la mancanza di applicazioni, che ovviamente a ruota impedisce di investire per creare portatili con ARM super carrozzati ma hanno invece uno scopo diverso.
Qui con l'emulazione si parla di aprire il vaso di Pandora e creare un nuovo marcato completamente. Lasciando stare Le opposizioni di Intel, MS è l'unica che può avviare questo processo (essendo a sua volta monopolista della parte OS su desktop che è in grado di far girare gli altri applicativi x86) e Qualcomm è in già da qualche tempo che cerca uno sbocco diverso dagli smartphone per i suoi prodotti.
Non stiamo parlando di Transmeta o una società che tenta un esperimento. Qui si parla di 2 colossi che stanno cercando di scassinare il cavò di Intel. Se ci riescono cambia la storia futura. Non il giorno dopo, non la settimana dopo, ma tra 4, 5 anni le cose potrebbero essere totalmente differenti.
Processori ARM con capacità vettoriali (a la AVX-512 o Xoen Phi) non sono mica fantascienza se il mercato va in quella direzione (che è la direzione che a quanto sembra ha preso Intel) e in quel campo l'emulazione non è un problema (si usano librerie per svolgere i calcoli complessi e queste possono essere riscritte ad hoc per l'HW a disposizione).

A come ho capito l'emulazione dovrebbe essere ibrida ( software ed hardware).
Qua c'è l'intimidazione di Intel vs qualcom e microsoft.
Un emulatore solo software sarebbe troppo lento ( difficilmente si potrebbero sfruttare più di un core) e si pensa ad uno strato hardware che rende trasparente in parte le chiamate x86.
Su questa questione intel suppone che si debba per forza infrangere qualche brevetto e/o parti delle licenze x86.
Da come ho capito Intel ha intimato ms-qualcom circa la cosa e ha minacciato un vero e proprio fuoco di sbarramento in caso di layer hardware in emulazione.

[giuliop]

Originariamente inviato da cdimauro

Mi riquoto:

Ah già, tu sei quello che va in loop: GOTO #52. Buon divertimento.

Originariamente inviato da nickname88

Clicca quì

Wow... link al messaggio sopra, con anche una parola sbagliata su due? Qui siamo a livelli di sagacia mai visti...

Originariamente inviato da emiliano84

Quoto

... anche tu però non scherzi, argomentazioni talmente ineccepibili è veramente difficile incontrarle.

[giuliop]

Originariamente inviato da CrapaDiLegno

E chi ha parlato di A11? E sopratutto, chissenefrega dell'A11?
Quando si parla di queste cose compaiono sempre questi confronti di mele con pere perché pensiamo che sia quello che ci mostrerà il futuro.
Vorresti comparare un SoC con una CPU, una nata per consumare 4W, l'altra 40 più e vedere se la prima batte (e di quanto) la seconda?

A me lo dici? Ma hai letto, prima di rispondere?

[giuliop]

Originariamente inviato da Piedone1113

L'A11 non è fatto per girare con un os esigente come windows desktop, è strutturato per eseguire quei pochi task che richiede ios e sono certo che una ricompilazione totale dell'os e scrittura ad oc di tutti i driver delle periferiche ci mostrerebbero elevate performance in alcuni test, ma scarsa pessimo rendimento energetico su strada.

Mi spiace ma dire "sono certo che" non dà alcuna veridicità alla tua affermazione, che senza prove reali, che non puoi portare, rimane campata in aria.

[giuliop]

Originariamente inviato da emiliano84

quoto

Ultimo messaggio a cui rispondo, perché anche questo è spreco di spazio: se devi dire il niente più assoluto ALMENO evita di quotare tutto il messaggio e fai risparmiare un po' di spazio su disco a HWUpgrade.

[fano]

Dai non ha senso pensare a Photoshop o a comprimere Film (porno) in 4K in H265 con sto nuovo tipo di portatili (posto che abbia senso in un normale portatile fare ste cose) io li vedo come un ritorno dei Netbook che sono stati uccisi mica perché andavano male, ma perché avevano un grosso problema: costavano troppo poco e per quello che la gente normalmente fa con un portatile erano più che sufficienti

L'emulazione che è solo Win32 avviene solo con le app Desktop quelle nello store sono o già funzionanti per ARM o essendo scritte in C# "portabili" con un colpo di mouse

[cdimauro]

Originariamente inviato da CrapaDiLegno

Però io questi confronti "innaturali" non li capisco.
Io il PC lo uso per fare del lavoro. Che usi la CPU, la RAM, il chipset, la GPU, una FPGA,le chiamate di funzione precompilate, quelle interpretate, il bytecode Java o quello .NET a me sinceramente interessa poco o nulla.
la mia necessità è avere un dispositivo a cui do del lavoro da fare e farglielo fare nel minore tempo possibile.
Quindi sinceramente a me non interessa quanto più veloce è x86 a fare una istruzione di moltiplicazione rispetto ad ARM.
Voglio elaborare il RAW di una foto (cosa per la quale ho preso questo PC "carrozzato") e vorrei sapere se usando un processore ARM il processo sarebbe più lento e quanto.
Se poi eventualmente Photoshop, Lightroom, ACDSee Studio o Paint .NET usano l'accelerazione della GPU per fare tutto e le differenze sono quindi minime, a me poco importa dire che "il test non è corretto": mi segno sulla tabella dei lavori possibili che i tempi di elaborazione di una foto su x86 rispetto a ARM sono i medesimi.
Quindi passo a risolvere un altro tipo di problema, chessò, la codifica H264/H265 con più applicazioni e vedo se e quale di questi mostrano differenze sostanziali. Poi passo ai render, poi a una suite office, poi magari anche a un Desktop Publishing (tipo Indesign) e faccio una tabella tra lavoro dato e tempo impiegato.
E su un portatile faccio anche le valutazioni della autonomia, che là è un aspetto tanto importante quanto il tempo di esecuzione di un bench.
Così, io utente, so se domani comprando un ipotetico PC con processore ARM da mille mila core/GHz/RAM/GPU so se vale la pena o no per il tipo di lavoro che devo fare.

Per fare un esempio, se negli anni la decodifica video la si è delegata a chip appositi, non ha senso che mi metta ad usare l'ultima applicazione esistente sulla terra che ancora usa esclusivamente la CPU per fare tale operazione. Perché avrei sì dei numeri che mi danno una differenza, m,a questo numero sarebbe inutile ai fini pratici.
Tanto vale usare Prime o Geekbench allora, per avere tanti numeri grezzi su cui discutere ma nulla che realmente mi dica se con una o l'altra architettura ho veramente un vantaggio o uno svantaggio a fare il lavoro che mi serve.

Non conosco utenti che non abbiano esigenze simili. Purtuttavia, i benchmark dei processori si fanno lo stesso. Un esempio è proprio l'elaborazione di fotografie, de/compressione di video, modellazione 3D usando OpenGL, ecc., che sono oggetto di recensioni e annessi test. Ovviamente certe prove si fanno a parità di scheda video integrata, in modo da lasciare la sola CPU come variabile da testare.

L'emulazione "non completa" la puoi fare se l'architettura nativa è simile a quella emulata. Altrimenti sei costretto a farla, perché l'accesso a registri, le istruzioni per la cache cache e ai flag di risultato delle istruzioni non possono essere astratti in altro modo se non emulandoli esattamente. E sono cose che possono complicare (rallentare) l'emulazione.

L'accesso ai registri e ai flag di risultato devono essere assolutamente e ovviamente implementati, altrimenti non ci sarebbe proprio emulazione.

Le istruzioni per la cache si devono emulare esclusivamente se si fa anche uso di compilatori JIT, in modo da intercettare i cambiamenti delle pagine che contengono codice, inclusi eventuali casi di codice auto-modificante.

Ma in entrambi i casi rientriamo perfettamente nell'emulazione "non completa": è, insomma, ciò che si fa normalmente con un emulatore.

E non serve assolutamente che l'architettura emulata sia simile a quella emulante.

L'emulazione completa serve soltanto in specifici casi, dove parliamo già di applicazioni non comuni (un esempio su tutti: le virtual machine). In questi casi emulare certe caratteristiche avrebbe un enorme impatto prestazionale.

Ma sono casi rari. La norma, in un s.o. moderno, è che certi dettagli non siano utilizzabili da una qualunque, normale applicazione.

E, dunque, è il caso delle normali applicazioni Win32/Win64, ma potremmo parlare anche di Linux, e altri s.o. moderni la cui user-land a basso livello funziona in un certo modo.

Il monopolio esiste, perché stiamo parlando di architettura x86 nel mercato desktop come l'unica presente da 2 decenni, non di chi la produce.
Quindi l'eventuale opposizione di Intel/ (o AMD) nel voler far entrare un concorrente con l'emulazione SW è un problema di monopolio architetturale.

Non esiste alcun monopolio proprio perché Intel è stata costretta a cedere licenze della sua ISA ad altre aziende, come già detto.

Inoltre la questione delle licenze assegnate non esula dalla questione monopolio + brevetti perché sai bene come è avvenuta l'assegnazione alle due suddette e come è stato il procedimento per rinnovarle. Che dimostra che l'architettura x86-32 è di proprietà esclusivamente Intel che ne può (o ha potuto) disporne come vuole fintanto che esiste AMD che le fa da contraltare.
Cosa che fino a ieri è equivalso a una manna per Intel non avendo alcun problema a tenerla nel suo 20% scarso di mercato ma che da quest'anno è diventata un problema, cui non credo voglia aggiungere quello di un concorrente che le rompe il mercato low based con un altra architettura che ha necessità fondamentale di eseguire il codice che già esiste.

Per essere precisi l'architettura di Intel si chiama IA-32. Quindi né x86 né tanto meno x86-32.

Poi che sia di proprietà di Intel è ovvio, visto che è roba sua. Ma ciò che importa è se ci sono aziende che hanno una licenza d'utilizzo, e tanto basta per evitare di parlare di monopolio.

Lo stesso vale ovviamente anche per AMD, visto che x64 è parzialmente sua (per essere precisi, tutta l'estensione a 64 bit. Che però si basa pesantemente su IA-32, e questa appartiene a Intel).

Tornando ad un excursus storico a cui tu non hai mai voluto dare credito arrampicandoti su tutti gli specchi del mondo (ma oggi le prove di quel che dicevo ci sono e sono chiare), Intel si è vista portare via un mercato potenziale enorme da ARM che le ha segato praticamente la sua fascia super entry level che nonostante tutto Intel vendeva a buon prezzo, con buoni margini e permetteva di stampare molto ma molto silicio (che oggi le manca per tenere in piedi tutte le sue fabbriche in maniera autonoma come nel passato).

Su questo ti ho riposto nel thread di Articoli / Coffee Lake.

L'unico fattore che ha impedito ad ARM di traboccare verso il mercato desktop entry level è l'enorme argine chiamato compatibilità. Se tutto il SW del mondo fosse stato scritto in Java o in .NET oggi non saremmo qui a commentare questo articolo, ma (direi sotto un altro punto di vista, fortunatamente) non è così, esistono quintali (sì,sì, è peso reale dei bit ) di codice nativo compilato per l'unica architettura rimasta nel mercato desktop che crea un muro non scavalcabile per chiunque voglia entrare nel mercato libero del PC desktop senza una licenza x86.

La stessa cosa vale per Android, dove la stragrande maggioranza delle applicazioni native è compilata per ARM, e soltanto una sparuta minoranza anche per altre architetture (IA-32, nello specifico).

Android ha una quota di mercato dominante nel mondo del mobile, come dovresti sapere.

Ma è tutto nella norma. Stiamo parlando di ovvietà, visto che Java e .NET sono tecnologie recenti.

Parlare di "a ma il mercato libero permette di farti il tuo desktop come e quando vuoi" non ha senso se non esiste la parola compatibilità con il resto del mercato già esistente (fatti una società telefonica che non usa gli standard di oggi per interfacciarsi con il resto del mercato e vedi quanti telefoni vendi), e a parer mio, l'opporsi all'entrata di un concorrente per questo motivo equivale ad abusare della propria posizione dominante, perché il tempo di ingresso non deve essere discriminatorio e quindi l'essere arrivato prima e aver imposto certi standard non deve essere un vantaggio usato per tagliare fuori gli altri. Da cui l'idea di regolamentare la licenza x86 come fosse FRAND.

L'antitrust, che è competente in materia, ha deciso di risolvere il problema obbligando Intel a cedere ad altri produttori la licenza IA-32.

Tanto basta, anche perché rappresenta la norma nel campo dei microprocessori. E ovviamente ciò include anche l'accesso a brevetti FRAND nel caso in cui parte della tecnologia per realizzare una certa ISA sia coperta da brevetti che sono indispensabili per implementarne una micro-architettura.

Intel invece qualche mese fa ha minacciato che si sarebbe opposta con tutte le sue forze (cosa che non va d'accordo con quello che hai detto sulla regolamentazione delle licenze e che quindi la FTC e l'ente anti trust non possano essere tirati in causa da una o dall'altra parte).

Non vedo con cosa non vada d'accordo: è nel perfetto, legittimo interesse di Intel, e non c'è proprio nulla da regolamentare che non sia già stato fatto in passato. La situazione è piuttosto chiara.

Ovviamente Intel cerca di tenere su questo argine innaturale che se dovesse cadere sa che è l'equivalente di far entrare nella propria casa di legno uno sciame di tarme.

Non v'è nulla di "innaturale" in ciò, come già detto prima. Ogni produttore di processori si comporta così.

Prova a commercializzare un processore ARM senza acquisire una licenza e vedi un po' come ti finisce.

Non avrà ripercussioni sull'immediato, ma sarebbe un suicidio, con ARM che pian piano le mangerebbe sempre più fette di mercato partendo dal basso,

Guarda che ARM non c'entra proprio nulla in questa storia. Sono i produttori di processori ARM come Qualcomm che avrebbero problemi se mettessero a disposizione anche un emulatore x86, senza avere una licenza da Intel.

ARM, come altre case che hanno realizzato architetture (IBM -> PowerPC, POWER, Infineon -> MIPS, Freescale -> PowerPC, 68K, 680x, ecc. ecc.), cede in licenza le sue IP. Come, appunto, si usa fare in questo mercato.

con i creatori di quelle piattaforme che inizierebbero piano piano a investire sempre di più, con i programmatori che piano piano comincerebbero a scrivere codice "neutro" (quindi non usando specificatamente librerie ottimizzate per Intel) e (ahinoi, qui devo dirlo) compilare con codice macchina "agnostico" che deve essere interpretato (bytecode o CLI), processo iniziato tantissimi anni fa ma appunto per il fatto che esistendo solo x86 non aveva molto senso perseguirlo in maniera competa.

Compilare in codice nativo è una cosa che si fa da quando esistono i processori, e dunque da ben prima che nascesse x86.

Idem l'utilizzo di IL, che risale alla notte dei tempi informatici.

Nessuno dei due ha avuto la meglio, perché entrambi hanno pro e contro. E dubito che le cose cambieranno solo per l'eventuale diatriba fra Intel e Qualcomm.

Tutti investimenti che sia lato HW che SW arricchirebbero "la concorrenza" indebolendo la posizione oggi monopolistica dell'architettura x86 e presagendo un possibile problema anche per il mercato basso e medio dei server (il mercato dove Intel guadagna di più non essendoci in effetti alcuna alternativa a quei costi sia di HW che di sviluppo SW).

Premesso quanto scritto sopra sull'argomento, non esiste alcun monopolio di Intel. Non foss'altro per definizione di monopolio, ma in ogni caso il mercato del software "consumer" è stato già scardinato anno fa con l'arrivo di iPhone prima e iPad poi.

E sappiamo come il cambiamento pur minimo possa poi portare ad uno tsunami come è avvenuto con i processi produttivi con l'adozione di ARM per il mobile e la conseguente necessità di costruire miliardi di processori low cost con questa architettura abbia innescato una corsa agli armamenti che Intel non credeva sarebbe mai accaduto (e in effetti senza null'altro da produrre in grandi volumi per la concorrenza mai sarebbe avvenuta).
Quello di cui beneficiò Intel negli anni passati (il ciclo vendo di più, investo nel PP, faccio un prodotto migliore, vendo ancora di più, rinvesto nel PP, faccio un prodotto ancora "più migliore") è stato poi rivissuto da altri con il mobile portando conseguenze (anche repentine) che Intel non riteneva di certo possibili quando ha iniziato a produrre processori con architettura Core che ancora oggi usiamo (sintomo del fatto che per questi anni ha goduto di un immenso vantaggio a tutto campo rispetto al resto del mercato che boccheggiava nel trovare una alternativa per costi e investimenti insostenibili dalle quantità di venduto esigue).

Su questo t'ho già risposto nel thread Articoli / Coffee Lake.

La possibilità quindi che vi sia un alternativa a scrivere codice per la sua unica architettura può creare un altrettanto grande tsunami, perché aperta la porta ad una architettura, nessuno impedisce che nel futuro non ne vengano introdotte di nuove con la compatibilità verso il codice nativo x86 (l'argine di oggi) che diventerà sempre meno un vantaggio con SW nuovi scritti "per tutti". La definitiva morte del connubio Wintel che sarebbe uno svantaggio solo per Intel, visto che MS già da tempo sta cercando di entrare nei nuovi mercato dove Intel non è riuscita.

Ti svelo un po' di segreti: alternative a x86 ne sono sempre esistite.

E il connubio Wintel è già stato rotto da un bel pezzo, come ti ho riportato diverse altre volte in passato, ma a quanto pare non vuoi capire o soffri di amnesia.

D'altra parte è ben noto che Windows abbia girato e giri su architetture diverse da x86.

La domanda quindi è: potrà Intel impedire questo movimento di evoluzione o riuscirà a mantenere le sue posizioni congelandoci per almeno un altro decennio con la sua posizione dominante e il monopolio x86 del mercato desktop?

Come già detto, non esiste alcun monopolio.

La risposta alla tua domanda la puoi trovare nel passato di Intel, visto che non è la prima volta che capita una cosa del genere.

Ma soprattutto, il mercato server, è così difendibile o basta che qualcuno investa pesantemente per avere HW decente al giusto prezzo e mettere in crisi Intel anche quel settore?

Veramente è il contrario: è grazie alla presenza di Intel che i prezzi nel mercato server si sono abbassati. Prima di Intel c'erano IBM, Sun, HP, ecc. che si facevano pagare a peso d'oro le loro macchine. E ancora oggi IBM è alquanto cara.

Ma in ogni caso c'è sempre spazio per concorrenti in questo settore, poiché il legacy x86 non è affatto importante. Ad esempio Google già da parecchio tempo testa e fa girare i suoi server su architetture DIVERSE da x86.

Tutto è rimpiazzabile qui, per cui il problema riguarda soltanto la presenza o meno di concorrenti che possano realmente portare prodotti a buon mercato.

Tutte domande a cui avremo la risposta tra un po'. E' certo che sembra che oggi Intel sia un po' nel mirino di tutti i nuovi colossi che la vedono un po' come quella che sta tirando il freno a tutto il mercato.

Non da ora, ma già da tempo è nel mirino di tutti. D'altra parte ha tolto l'osso di bocca a parecchi giganti...

[cdimauro]

Originariamente inviato da CrapaDiLegno

E chi ha parlato di A11? E sopratutto, chissenefrega dell'A11?
Quando si parla di queste cose compaiono sempre questi confronti di mele con pere perché pensiamo che sia quello che ci mostrerà il futuro.
Vorresti comparare un SoC con una CPU, una nata per consumare 4W, l'altra 40 più e vedere se la prima batte (e di quanto) la seconda?

Si parlava di processori, e non di SoC, dunque niente confronti di mele con pere, ma degli stessi componenti.

Semmai il mercato desktop (oggi ormai dei portatili, il desktop quello con cassone fisso sembra destinato a morire per no so quali ragioni... ma è un altro discorso) vedesse l'introduzione di una architettura diversa da x86, credi che i processori ARM continueranno ad essere prodotti per consumare 4W? Credi che tutti continuerebbero ad usare la filosofia big.LITTLE? Che nessuno se ne salterebbe fuori con una CPU (non SoC) ARM da 40W dual o quad channel? Invece che con 4+4 core magari 8 core più grandi e potenti degli A72 di oggi?
Credi che chi può permettersi di customizzare l'architettura continuerà a a farlo con l'intento di risparmiare silicio e W?

Stiamo parlando di confrontare le mele con le pere per i prototipi di questo potenziale nuovo mercato per il mondo ARM, ma la sicurezza è che non vedremo solo l'adozione di SoC dei telefoni e basta.

Più che altro è insensato parlare di processori ARM da 40W & co., visto che quelli che ci sono adesso e pur arriveranno a breve sono realizzati con processi produttivi low-power, che limitano sia le frequenze sia i consumi massimi.

NON sono processori desktop, per essere chiari.

Originariamente inviato da Antonio23

*

che poi e' esattamente quello che viene fatto internamente per fare benchmarking e performance analysis.

Infatti.

Anche perché è ovvio che i produttori di processori si studino a vicenda, specialmente quando i relativi mercati s'intersecano o sono vicini.

Originariamente inviato da Piedone1113

Se poi vogliamo paragonare due cpu con architetture diverse ci sono i mezzi da laboratorio per farlo, dove si scrive codice per far eseguire tipi di calcolo consecutivi e interdipendenti cercando di simulare il funzionamento di un ambiente reale.

*

[cdimauro]

Originariamente inviato da CrapaDiLegno

Dimenticate sempre la questione compatibilità.
Se domani Apple presenta un dispositivo con processore diverso da x86, quale SW ci girerà sopra? Quello dei suoi servizi e.... La suite Adobe? I CAD? I SW di rendering?
Già, per farli funzionare è richiesto l'emulazione o che gli sviluppatori si sbattano a ricompilare tutto (se possono). E dopo il lavoraccio poi rimangono sempre con la spada di Damocle da parte di Intel che potrebbe mettersi di traverso (ricordo che Apple e Intel hanno una forte partnership con quest'ultima che fornisce processori ad hoc a Apple e aprire un contenzioso per un mercato piccolo come quello degli ultraportatili non è un vantaggio per Apple).

Già da tempo Apple impone agli sviluppatori di non compilare i loro software per una specifica architettura, ma per un IL. Dunque proprio Apple non dovrebbe avere problemi del genere.

Apple è già passata per 2 transizioni di architetture incompatibili. Sa molto bene quale sia l'impegno e il costo associato a questo tipo di cambiamenti.
Non si fa da un giorno all'altro, non costa 2 lire e sa quanto è pesante anche per i partner che sviluppano il SW (che devono necessariamente avere un periodo di transizione in cui compilare e distribuire per le architetture mentre convivono sul mercato insieme).

Infatti Apple c'ha pensato già da tempo: vedi sopra.

Non è un caso che MS ci sta pensando solo oggi alla cosa con Qualcomm che sta sviluppando il suo processore per server da un po' e di certo non ha le prestazioni di un SoC per smartphone come quelli che erano disponibili per far girare Windows ai tempi di RT) e tramite una soluzione radicale come l'emulazione, che degrada le prestazioni ma permette meno sbattimenti per gli sviluppatori durante il periodo di transizione er garantisce la compatibilità con il 100% del SW esistente.

Bisogna vedere di che tipo di emulazione farà uso: se completa o parziale (vedi precedente commento in merito).

L'idea che se non si è fatto prima (o non lo ha fatto Apple) allora non è una soluzione accettabile ricade nella incapacità di vedere che le cose sono cambiate e stanno cambiando rapidamente (e in futuro ancora di più) al punto di essere qui oggi a chiederci se davvero esiterà qualcosa che è in grado di emulare decentemente x86 sino al punto di poterne prendere il posto in determinati mercati.

Il problema sta, per l'appunto, nell'emulare decentemente x86. Cosa tutt'altro che semplice da ottenere, tant'è che Transmeta ha dovuto integrare alcune caratteristiche di x86 nei suoi processori VLIW per poter ottenere delle discrete prestazioni.

Con queste premesse, a me dell'A11 nato per girare in un apparato da 5x10x0.5 cm e con 4W di TPD sinceramente frega poco o nulla così come è inutile credere o sperare che il primo processore ARM sul mercato desktop possa battere x86 nei test di Cinebench o rendering (ma ci scommetto che sarà questo quello che si vorrà comparare e su quello che si discuterà... d'altronde la portata di questa cosa il 90% della gente non la capisce (no, nemmeno tra coloro che oggi sono qui a commentare) e si ferma al solito alla lunghezza della barretta colorata dei soliti inutili test).

Mentre dovresti capirlo tu che di architetture degli elaboratori non ne mastichi proprio né tanto meno di emulatori, come hai mostrato nel commento a cui ho replicato prima...

Non è quello lo scopo, non è quella la cosa importante, non è quello che determinerà se ARM acquisirà porzioni di mercato nel mondo del PC tradizionale, così come le prestazioni ridicole che aveva all'inizio del mondo smartphone rispetto ai prodotti Intel non hanno deciso il suo successo o meno in quel mercato.

E oggi si vendono qualche miliardo di processori ARM ogni anno, di cui un mezzo miliardo per i telefoni che nonostante "le prestazioni ridotte" possono svolgere molti lavori che fino a ieri erano di sola competenza dei PC, e quindi Intel.

Infatti la fortuna è stata quella di essere pioniera in ambito mobile, che è esploso con gli smartphone prima e i tablet poi.

P.S: non è un caso che Intel sta carrozzando i suoi processori con AVX-512 per permettere loro di svolgere quei compiti che ARM non potrà fare così facilmente (ma non è impossibile neanche per loro, teniamolo a mente).

Intanto le AVX-512 sono presenti esclusivamente in ambito server o HEDT. Dunque ben lontane dal settore desktop di cui si parla qui.

Secondo, e più importante, ti sarà sfuggito che lo scorso anno ARM abbia presentato una sua estensione vettoriale nuova di pacca, che consente di gestire in maniera automatica e trasparente vettore lunghi 128 (come adesso), 512 (come AVX-512), o 2048 bit (di gran superiore a qualunque ISA).

Per tutto il resto, Intel sa bene che dove non serve che il PC faccia computazione intensiva per ore un ARM basta e avanza... se può eseguire il codice x86 e così avere a disposizione tutta la storia dello sviluppo dei SW su PC.

Assolutamente falso. Non è certo necessario dover usare i processori per computazioni intensive per ore e ore, per poter trarre beneficio di certe micro-architetture.

Oggi basta aprire una pagina web per mettere alla frusta un processore, e sostanzialmente per un singolo core.

Tanto per fare un esempio concreto.

Se così non fosse, non ci si sbatterebbe nel cercare di aumentare le prestazioni in single-core/thread, che ancora oggi sono importantissime. E dove ovviamente Intel domina da tempo.

EDIT: aggiungo questo, visto che l'argomento l'ho trattato qui sopra.

Originariamente inviato da CrapaDiLegno

Processori ARM con capacità vettoriali (a la AVX-512 o Xoen Phi) non sono mica fantascienza se il mercato va in quella direzione (che è la direzione che a quanto sembra ha preso Intel)

Non è fantascienza per chi s'informa, e sa che ARM ha già presentato un anno fa la sua estensione vettoriale nuova di pacca.

e in quel campo l'emulazione non è un problema (si usano librerie per svolgere i calcoli complessi e queste possono essere riscritte ad hoc per l'HW a disposizione).

Questo non c'entra proprio niente: se ti serve emulare un processore che è dotato di unità vettoriali, la questione si complica ulteriormente, specialmente se l'architettura è emulata è quella Intel, che propone da tempo un'estensione SIMD molto diversa da quella messa a disposizione da altre architetture.

Per il software nativo il problema non si pone, ma la notizia, nonché il tema della discussione, è e rimane l'emulazione (x86), per l'appunto.

[cdimauro]

Originariamente inviato da s-y

proprio perchè, potenzialmente, sarebbe un cambiamento epocale, probabilmente non si farebbero prigionieri. tutta da seguire per quanto mi riguarda.
alla fine può essere una specie di naturale evoluzione della 'crisi' del pc, che già di suo è un fattore in grado di spostare equilibri che potevano sembrare immutabili

*

Originariamente inviato da Piedone1113

A come ho capito l'emulazione dovrebbe essere ibrida ( software ed hardware).

Dubito che il processore Qualcomm abbia specifiche estensioni per facilitare l'emulazione x86.

Non che non sia possibile, sia chiaro, visto che processori come Longsoon (basato su MIPS) hanno dimostrato che questa strada sia senz'altro percorribile (ma integrando quasi un centinaio di nuove istruzioni: praticamente è quasi una reimplementazione di x86!), ma è decisamente atipico per ARM e non sono mai circolate indiscrezioni in merito (anche perché Qualcomm dovrebbe realizzare SoC appositamente allo scopo, differenziandoli da quelli per altri mercati/dispositivi).

Qua c'è l'intimidazione di Intel vs qualcom e microsoft.
Un emulatore solo software sarebbe troppo lento ( difficilmente si potrebbero sfruttare più di un core)

In effetti l'emulazione x86 è abbastanza pesante, anche senza implementarne una completa di tutte le caratteristiche dell'ISA.

Un paio d'anni fa ho tenuto un talk alla PyCon Italia, presentando un emulatore 8086 scritto in Python, e in cui ho illustrato le difficoltà del progetto.

e si pensa ad uno strato hardware che rende trasparente in parte le chiamate x86.

No, per questo sarebbe sufficiente uno strato software, praticamente identico a quello che Microsoft ha già realizzato la XBoxOne per emulare i giochi della XBox 360.

Su questa questione intel suppone che si debba per forza infrangere qualche brevetto e/o parti delle licenze x86.
Da come ho capito Intel ha intimato ms-qualcom circa la cosa e ha minacciato un vero e proprio fuoco di sbarramento in caso di layer hardware in emulazione.

Esattamente (ma è per l'emulazione in generale).

Originariamente inviato da giuliop

Ah già, tu sei quello che va in loop: GOTO #52. Buon divertimento.

Tipico di chi l'ha sparata grossa, e non è più in grado di argomentare.

[CrapaDiLegno]

Avrei voluto quotare quello che quotavi in risposta giusto per far capire che rispondi pere con mele o rispondi tanto per far polemica, ma sono da cell e la cosa è impraticabile. E non ho tutto il giorno.

Originariamente inviato da cdimauro

Non conosco utenti che non abbiano esigenze simili. Purtuttavia, i benchmark dei processori si fanno lo stesso. Un esempio è proprio l'elaborazione di fotografie, de/compressione di video, modellazione 3D usando OpenGL, ecc., che sono oggetto di recensioni e annessi test. Ovviamente certe prove si fanno a parità di scheda video integrata, in modo da lasciare la sola CPU come variabile da testare.

Se vuoi dire le stesse cose che dico io, perché rispondi con banalità come questa mentre prima proponevi benchmark CPU bound per fare confronti?
Io ho detto solo come secondo me dovrebbero essere fatti i test per capire se un processore può prendere il posto di un altro.
Tu hai detto la tua.
Ma ovviamente la mia non va bene. Però non dici perché. Solo polemica sterile.

Originariamente inviato da cdimauro

L'accesso ai registri e ai flag di risultato devono essere assolutamente e ovviamente implementati, altrimenti non ci sarebbe proprio emulazione.

Le istruzioni per la cache si devono emulare esclusivamente se si fa anche uso di compilatori JIT, in modo da intercettare i cambiamenti delle pagine che contengono codice, inclusi eventuali casi di codice auto-modificante.

Ma in entrambi i casi rientriamo perfettamente nell'emulazione "non completa": è, insomma, ciò che si fa normalmente con un emulatore.

Emulazione "non completa" quando devi emulare accessi a registri e a fkagydi status non di cosa voglia dire.
Intendi emulazione della micro architettura con emulazione di porte logiche e bus?

Originariamente inviato da cdimauro

E non serve assolutamente che l'architettura emulata sia simile a quella emulante.

L'emulazione completa serve soltanto in specifici casi, dove parliamo già di applicazioni non comuni (un esempio su tutti: le virtual machine). In questi casi emulare certe caratteristiche avrebbe un enorme impatto prestazionale.

Ma sono casi rari. La norma, in un s.o. moderno, è che certi dettagli non siano utilizzabili da una qualunque, normale applicazione.

Eh? Sento dita scricchiolare tanto per dire qualcosa...

Originariamente inviato da cdimauro

E, dunque, è il caso delle normali applicazioni Win32/Win64, ma potremmo parlare anche di Linux, e altri s.o. moderni la cui user-land a basso livello funziona in un certo modo.

Non è il caso di Win32/64 che hanno base comune e non c'entra una cippa Linux che è un OS e che non necessita di emulare un bel niente se non a livello SW quando gira su x86. Prova a eseguire una "normale" applicazione x86 Linux su PPC.
Lo user-land che lavora in un certo modo... Utile per evitare che la funzione Move memoria-memoria non sia emulata su un processore che fa accesso solo ai registri da e per i registri.

Originariamente inviato da cdimauro

Non esiste alcun monopolio proprio perché Intel è stata costretta a cedere licenze della sua ISA ad altre aziende, come già detto.

E qui dimostri che la parola monopolio ti fa sbarellare completamente. Eppure c'è scritto che monopolio intendo. Eppure esiste quel monopolio. E tu stai parlando di altro giusto perché vuoi sprecare bit e il mio tempo.

Originariamente inviato da cdimauro

Per essere precisi l'architettura di Intel si chiama IA-32. Quindi né x86 né tanto meno x86-32.

Poi che sia di proprietà di Intel è ovvio, visto che è roba sua. Ma ciò che importa è se ci sono aziende che hanno una licenza d'utilizzo, e tanto basta per evitare di parlare di monopolio.

E siccome non hai nulla di intelligente da dire sull'argomento fai il puntiglioso per dimostrare che tu sai, però poi insisti a parlare di un monopolio che ti dà fastidio venga accennato, ma che qui proprio nessuno ne ha parlato.

Originariamente inviato da cdimauro

Lo stesso vale ovviamente anche per AMD, visto che x64 è parzialmente sua (per essere precisi, tutta l'estensione a 64 bit. Che però si basa pesantemente su IA-32, e questa appartiene a Intel).

Pere, mele,banane, venghino signori, venghino, che la fiera delle banalità che non c'entrano con il discorso intsvolato è aperta!

Originariamente inviato da cdimauro

Su questo ti ho riposto nel thread di Articoli / Coffee Lake.

Sì? Ah, boh, non credo di averlo letto. Dopo post come questi diventa un peso continuare a discutere di banalità e di roba che non c'entra nulla.

Originariamente inviato da cdimauro

La stessa cosa vale per Android, dove la stragrande maggioranza delle applicazioni native è compilata per ARM, e soltanto una sparuta minoranza anche per altre architetture (IA-32, nello specifico).

Android ha una quota di mercato dominante nel mondo del mobile, come dovresti sapere.

In verità la maggior parte delle applicazioni Android sono scritte usando la VM e solo pochissime (per lo più i giochi pesanti) usano il codice nativo.
Ed è solo tua questa idea che è stata la "non compatibilità" con arm ad aver ucciso il mercato mobile di Intel. La verità che ti brucia è che semplicemente il suo HW non era alla pari per costi / consumi con la concorrenza. Sotto Android x86 non mancavano certo le app.

Originariamente inviato da cdimauro

Ma è tutto nella norma. Stiamo parlando di ovvietà, visto che Java e .NET sono tecnologie recenti.

E quindi?
Poi recenti... Forse la copia di MS di Java, ma Java non è così tanto giovane.

Originariamente inviato da cdimauro

L'antitrust, che è competente in materia, ha deciso di risolvere il problema obbligando Intel a cedere ad altri produttori la licenza IA-32.

No. L'Antitrust ha obbligato Intel a continuare a dare la propria licenza x86 a un concorrente per esplicita richiesta di IBM, e la scelta cadde su un minuscola azienda che al tempo faceva della produzione di flash il suo core business (della serie, basta che c'è l'abbia qualcuno che mai potrà porre problemi di concorrenza reale).
Da quel momento in poi le cose sono profondamente cambiate, sua in termini di dipendenza tra le due aziende sua in termini di mercato.

Originariamente inviato da cdimauro

Tanto basta, anche perché rappresenta la norma nel campo dei microprocessori. E ovviamente ciò include anche l'accesso a brevetti FRAND nel caso in cui parte della tecnologia per realizzare una certa ISA sia coperta da brevetti che sono indispensabili per implementarne una micro-architettura.

Non vedo con cosa non vada d'accordo: è nel perfetto, legittimo interesse di Intel, e non c'è proprio nulla da regolamentare che non sia già stato fatto in passato. La situazione è piuttosto chiara.

Non v'è nulla di "innaturale" in ciò, come già detto prima. Ogni produttore di processori si comporta così.

È innaturale il fatto che l'ingresso di un concorrente non sia fatto sulla base della qualità dei suoi prodotti ma del dover necessariamente negoziare per permettersi la compatibilità con il pregresso. Se non lo hai capito, torna a leggere i bigini su cui hai studiato.

Originariamente inviato da cdimauro

Prova a commercializzare un processore ARM senza acquisire una licenza e vedi un po' come ti finisce.

Ma non hai capito che qui nessuno vuole fare un processore x86. Nessuno sano di mente investirebbe in tale cosa al giorno d'oggi. Si vuole solo essere compatibili con gli eseguibili già esistenti. Che è cosa ben diversa.
In più la differenza è che se paghi arm concede la sua licenza a tutti. Intel no. E quindi c'è un problema di accesso alla tecnologia.

Originariamente inviato da cdimauro

Guarda che ARM non c'entra proprio nulla in questa storia. Sono i produttori di processori ARM come Qualcomm che avrebbero problemi se mettessero a disposizione anche un emulatore x86, senza avere una licenza da Intel.

ARM, come altre case che hanno realizzato architetture (IBM -> PowerPC, POWER, Infineon -> MIPS, Freescale -> PowerPC, 68K, 680x, ecc. ecc.), cede in licenza le sue IP. Come, appunto, si usa fare in questo mercato.

Huh, e questo che c'entra con l'argomento? Chi ha mai parlato di arm come azienda licenzuataria? Ti è andato di traverso il neurone dopo aver letto tutte quelle frasi contenenti "monopolio"?
ARM qui è sempre stato inteso come architettura, non chi la fa.
Fai confusione tra architettura e azienda che la implementa.
Monopolio x86 non è monopolio Intel, ARM che avanza non è l'azienda Inglese che stampa sempre più processori.
Hai diversi problemi a comprendere i discorsi. Te l'ho già detto.

Originariamente inviato da cdimauro

Compilare in codice nativo è una cosa che si fa da quando esistono i processori, e dunque da ben prima che nascesse x86.

Idem l'utilizzo di IL, che risale alla notte dei tempi informatici.

Nessuno dei due ha avuto la meglio, perché entrambi hanno pro e contro. E dubito che le cose cambieranno solo per l'eventuale diatriba fra Intel e Qualcomm.

Di cosa parli? Del mondo informatico intero? O di quello desktop? Perché in quest'ultimo caso, nell'eventualità che entri una architettura diversa da x86 (che è monopolista, già) le cose possono cambiare radicalmente per davvero.

Originariamente inviato da cdimauro

Premesso quanto scritto sopra sull'argomento, non esiste alcun monopolio di Intel. Non foss'altro per definizione di monopolio, ma in ogni caso il mercato del software "consumer" è stato già scardinato anno fa con l'arrivo di iPhone prima e iPad poi.

Su questo t'ho già risposto nel thread Articoli / Coffee Lake.

Vedi sopra x monopolio e risposta ad altro in altro thread.

Originariamente inviato da cdimauro

Ti svelo un po' di segreti: alternative a x86 ne sono sempre esistite.

E il connubio Wintel è già stato rotto da un bel pezzo, come ti ho riportato diverse altre volte in passato, ma a quanto pare non vuoi capire o soffri di amnesia.

D'altra parte è ben noto che Windows abbia girato e giri su architetture diverse da x86.

Il connubio non si è mai rotto nonostante i tentativi di ms di trovare una alternativa a Intel nei mercati in cui quest'ultima ha fallito miseramente.
Dimmi, oggi, quanti dispositivi con Windows che non siano x86 sono in produzione?
E nonostante il fatto che ti arrampichi sugli specchi vale quello che ho detto io: se Intel non rintuzza questo attacco al suo ultimo argine composto al 100% dalla sola compatibilità, allora sì che il connubio Wintel muore e per Intel comincia una nuova era dove deve pesantemente innovare e innovarsi (= un sacco di soldi in più in R&D, e non da diluire in un secolo, ma in fretta, che gli altri non sono mica fermi come 10 anni fa).

Originariamente inviato da cdimauro

Come già detto, non esiste alcun monopolio.

Monopolio, monopolio, sì, esiste. Leggi meglio e ti viene detto quale. Sì, esiste, leggi meglio e ti viene detto quale. Sì, esiste, leggi meglio e ti viene detto quale.
Repetita juvant, poi se vuoi continuare a parlare da solo dell'unico monopolio che conosci, allora continua da solo.

Originariamente inviato da cdimauro

La risposta alla tua domanda la puoi trovare nel passato di Intel, visto che non è la prima volta che capita una cosa del genere.

Veramente è il contrario: è grazie alla presenza di Intel che i prezzi nel mercato server si sono abbassati. Prima di Intel c'erano IBM, Sun, HP, ecc. che si facevano pagare a peso d'oro le loro macchine. E ancora oggi IBM è alquanto cara.

In verità è il contrario di cosa se io non ho mai detto nulla di ciò che parli, ma dicendolo stai dandomi ragione sul fatto che il ciclo Intel vendo di più, produco di più, investo nel PP, taglio il prezzo rispetto alla concorrenza, quindi vendo di più, investo in nuovo PP, taglio il prezzo rispetto alla concorrenza, e via, con gli altri che boccheggiano perché hanno alti costi di sviluppo e sempre meno vendite?
Il contrario de che? Ma quando rispondi ti assucuri di aver compreso quello di cui si parla?

Originariamente inviato da cdimauro

Ma in ogni caso c'è sempre spazio per concorrenti in questo settore, poiché il legacy x86 non è affatto importante. Ad esempio Google già da parecchio tempo testa e fa girare i suoi server su architetture DIVERSE da x86.

Ma qui sfiori il ridicolo portando esempi di realtà diverse rispetto a quello di cui si parla. Di alternative vere finché c'è il monopolio dell'architettura x86 e dei suoi eseguibili non esisterà mai.
È come credere che finché MS non fosse stata obbligata a usare formati open, o non ci fosse il reverse engineering dei suoi formati proprietari potesse esistere una alternativa a Office.
Stai dimostrando che sei ancora attaccato alla vecchia maglia, e questo ti offusca il cervello.

Originariamente inviato da cdimauro

Tutto è rimpiazzabile qui, per cui il problema riguarda soltanto la presenza o meno di concorrenti che possano realmente portare prodotti a buon mercato.

Non da ora, ma già da tempo è nel mirino di tutti. D'altra parte ha tolto l'osso di bocca a parecchi giganti...

I concorrenti possono portare prodotti buoni o anche migliori nel momento in cui non devono partire un chilometro indietro in una gara dei 100 metri. Se e quando potranno eseguire codice x86 in maniera decente senza necessariamente dover investire nel costruire un processore con architettura x86 e quindi sottostare agli ovvi dinieghi di Intel, allora si avrà un radicale cambiamento che oggi, come nei 2 decenni passati, non è stato possibile.

Quello che ti sfugge in tutti questi discorsi riguardanti passato, presente d futuro di Intel è che tu parli sempre e solo con visione miope Intel centrica, in cui Intel non è un elefante in una vetreria che tiene lontani tutti gli altri che ovviamente non possono competere ad armi pari.

Ma io te lo dissi riguardo al mobile, che le cose stavano cambiando, e là dove un solo concorrente con PP vecchi non ha speranza, l'unione di un insieme di aziende che avrebbero investito tutte nella stessa cosa dando soldi ad altri, avrebbe innescato una onda bella alta.
Fatto sta che oggi non si parla di Motorola con 2 PP più vecchi, non si parla di Sun che vendeva 1000 processori al mese, non si parla di uno contro uno dove la forza del mercato di scala di Intel è riuscita a seppellire tutti i concorrenti.
Stiamo parlando di una serie di aziende che in totale investono quanto e più di Intel, che vendono in fatturato molto di più, che hanno invaso il mercato con prodotti non x86 dipendenti che ha permesso di investire in sistemi di sviluppo alternativi con ottimo supporto, che oggi si fanno anche i processori in casa (sì, anche Google, cosa assurda solo pensarlo 10 anni fa), che creano un indotto tale che permette investimenti duraturi su altro che non sia x86 che fanno diminuire i pezzi venduti x86, il silicio necessario, le fabbriche necessarie e i guadagni relativi. Ad Intel sta subendo quello che lei ha causato agli altri.
Con un vantaggio per lei dovuto al l'accumulata quantità di SW compilato per la sua architettura.
Tolto quell'ostacolo si apre una nuova era, dove al cambiamento di paradigma nella programmazione (non più solo nativa x86) si avrà davvero un mercato dove vince chi fa meglio è non chi è stato scelto 40 anni fa all'esordio dell'era del PC.

P.S: non sto qui a quotare anche la parte sulle avx, ma è ovvio che stai cercando di "barare" e di brutto.
Quel tipo di istruzioni sono immensamente complicate per fare in modo che un compilatore le usi nativamente estrapolandole dal codice. Perché vengano sfruttate veramente si devono usare funzioni prescritte e questo vuol dire che l'algoritmo ad alto livello può essere facilmente adeguato ad altre librerie che fanno riferimento ad altre implementazioni.
Nel mercato per cui questi mega complessi circuitali sono destinati l'implementazione proprietaria non conta nulla.
E ritornando al discorso di prima, se prima non c'era nessuno in grado di proporre SW e HW alternativo che fosse economicamente sostenibile (solo Nvidia lo ha fatto, e solo in contesti limitati), oggi molti altri possono.
La nuova corsa all'IA lo dimostra: gli storici big del silicio non sono più gli unici che possono giocare.

D'oh, ho i crampi alle dita.

[CrapaDiLegno]

Ah, dimenticavo... Per quanto riguarda "le avx sono solo sui prodotti server.. E bla bla bla, dico solo cose di ieri e di oggi che sanno solo i sassi che sostenere una discussione dove bisogna congiunge 2 punti extra nozioni accademiche (che sanno pure i sassi) non sono capace e mi limito a quello che so di oggi senza sapere nulla del domani.. Mapperò mi piace dire a chi è in grado di arrivare un po' più in là del suo naso che dice baggianate...tanto non ha prove del futuro (come nessun ha) e poi se ci azzecca tantomeno basta parlare ancora dei sassi e confondere quello che ho detto in passato per fare bella figura."

Il "se il futuro va in quella direzione" era riferito a questo :
https://www.anandtech.com/show/11928...nnon-lake-cpus

Buona lettura. Poi un puntino magari riesci a collegarlo anche tu. Un passetto alla volta.

[LMCH]

Originariamente inviato da CrapaDiLegno

No. L'Antitrust ha obbligato Intel a continuare a dare la propria licenza x86 a un concorrente per esplicita richiesta di IBM, e la scelta cadde su un minuscola azienda che al tempo faceva della produzione di flash il suo core business (della serie, basta che c'è l'abbia qualcuno che mai potrà porre problemi di concorrenza reale).
Da quel momento in poi le cose sono profondamente cambiate, sua in termini di dipendenza tra le due aziende sua in termini di mercato.

L'antitrust non c'entra.
La cosa risale ai tempi del primo pc IBM, quando IBM era ancora davvero Big Blue mentre Intel non era il colosso che poi diventò.

IBM aveva imposto nel contratto di fornitura delle cpu che vi fossero altri produttori second source per la produzione di cpu 8086/8088 e loro evoluzioni.
Se ricordo bene proprio per questo ci fu un accordo con AMD in tal senso.

[LMCH]

Originariamente inviato da fano

Dai non ha senso pensare a Photoshop o a comprimere Film (porno) in 4K in H265 con sto nuovo tipo di portatili (posto che abbia senso in un normale portatile fare ste cose) io li vedo come un ritorno dei Netbook che sono stati uccisi mica perché andavano male, ma perché avevano un grosso problema: costavano troppo poco e per quello che la gente normalmente fa con un portatile erano più che sufficienti

L'emulazione che è solo Win32 avviene solo con le app Desktop quelle nello store sono o già funzionanti per ARM o essendo scritte in C# "portabili" con un colpo di mouse

Inoltre le applicazioni win32 scritte in C/C++ dovrebbero essere ricompilabili per Arm senza grossi problemi (stesso byte order degli x86, solo i float ad 80bit richiedono un emulazione, ma anche per quelli esistono metodi di emulazione abbastanza efficienti).
Infine nel caso di codice x86 non automodificante (la maggior parte del codice user-mode scritto per win32 è "read only") è possibile ricompilare (trattando il codice x86 come se fosse un sorgente e ri-ottimizzato per ARM.

[cdimauro]

Originariamente inviato da LMCH

L'antitrust non c'entra.
La cosa risale ai tempi del primo pc IBM, quando IBM era ancora davvero Big Blue mentre Intel non era il colosso che poi diventò.

IBM aveva imposto nel contratto di fornitura delle cpu che vi fossero altri produttori second source per la produzione di cpu 8086/8088 e loro evoluzioni.
Se ricordo bene proprio per questo ci fu un accordo con AMD in tal senso.

Ricordi benissimo. E per aggiungere dettagli, fu proprio Intel a cercare AMD come second source, perché era un'azienda piccola e non poteva infastidirla.

L'antitrust non c'entra proprio una mazza, per l'appunto, perché all'epoca si trattò di accordi contrattuali.

Meno male che ci sei tu a riportare la verità storica. Qui con l'arrivo di gente che si fa "cultura" a colpi di internet è diventato lo schifo di cui parlava la buonanima di Umberto Eco...

Originariamente inviato da LMCH

Inoltre le applicazioni win32 scritte in C/C++ dovrebbero essere ricompilabili per Arm senza grossi problemi (stesso byte order degli x86, solo i float ad 80bit richiedono un emulazione, ma anche per quelli esistono metodi di emulazione abbastanza efficienti).
Infine nel caso di codice x86 non automodificante (la maggior parte del codice user-mode scritto per win32 è "read only") è possibile ricompilare (trattando il codice x86 come se fosse un sorgente e ri-ottimizzato per ARM.

Esattamente. Ma vaglielo a fare capire a chi non ha la minima idea di come funziona un processore/architettura, un s.o., e la user land delle applicazioni.

Aggiungerò ulteriori dettagli (già scritti questi) quando avrò tempo per completare la risposta al commento lunghissimo di CrapaDiLegno. Ma intanto rispondo velocemente a questo:

Originariamente inviato da CrapaDiLegno

Ah, dimenticavo... Per quanto riguarda "le avx sono solo sui prodotti server.. E bla bla bla, dico solo cose di ieri e di oggi che sanno solo i sassi che sostenere una discussione dove bisogna congiunge 2 punti extra nozioni accademiche (che sanno pure i sassi) non sono capace e mi limito a quello che so di oggi senza sapere nulla del domani.. Mapperò mi piace dire a chi è in grado di arrivare un po' più in là del suo naso che dice baggianate...tanto non ha prove del futuro (come nessun ha) e poi se ci azzecca tantomeno basta parlare ancora dei sassi e confondere quello che ho detto in passato per fare bella figura."

Il "se il futuro va in quella direzione" era riferito a questo :
https://www.anandtech.com/show/11928...nnon-lake-cpus

Buona lettura. Poi un puntino magari riesci a collegarlo anche tu. Un passetto alla volta.

Prima di scrivere sarebbe bene almeno leggere e comprendere quello che hanno scritto gli altri.

Io ho parlato al presente riguardo alle AVX-512, precisando lo status quo. Riguardo al futuro ho affermato che sono "ben lontane dal settore desktop", e infatti dal tuo stesso link:

"Intel originally promised to release Cannon Lake processors in 2016 – 2017 timeframe, but delayed introduction of its 10 nm process technology to 2018, thus postponing the CPU launch as well."

D'altra parte e come avevo già scritto nell'altro thread, di CannonLake ormai si sono perse le notizie e non c'è nessuna novità da tempo = ulteriore ritardo e non si sa più quando arriverà.

Infine, più volte ho già scritto qui che le AVX-512 arriveranno in ambito desktop proprio con CannonLake. Visto che la tua memoria è del tutto inaffidabile (vedi anche sopra), avresti potuto fareuna ricerchina sul forum per vedere cosa ne avessi scritto.

All'altro tuo commento risponderò appena completerò la risposta (che è già in lavorazione), visto che ne hai sparate in abbondanza. Ma nessuna novità, visto che non capisci nulla di architetture, funzionamento di processori, di s.o., applicazioni, e men che meno di come funziona un emulatore.

[nickmot]

Originariamente inviato da emiliano84

Pare che sara' lo stesso per le app .NET framework, almeno per quelle con codice moderno e compatibile, e' apparso qualche screenshot di visualstudio con compilazione per architettura ARM

Su VS puoi compilare per ARM da un po'.

[nickmot]

Originariamente inviato da emiliano84

mmm ho fatto un po' di confusione, le app .net framework hanno come target "any cpu", mentre le UWP (x86, x64, ARM) ... lo screenshot che avevo visto era un app .net framework che aveva come target ARM64

Potevi selezionare un'archiettura per codice .NET anche in passato.
Sono pieno di dll .NET compilate esplicitamente per Win32 e/o X64 (per le prime è douto al fato di avere alcune dipendenze unmanaged a 32bit)





Screen fatti ora sul mio PC, il primo è su VS2010

[nickmot]

Originariamente inviato da emiliano84

ah si, ma tu parli di quelle scritte in c++ giusto? io non ci ho mai lavorato con c++ in vs

Il primo screen è la configurazione di 2 applicazioni .NET che non puntano AnyCPU.

Il secondo è uno screen di un'applicazione MFC C/C++ con target ARM.

[cdimauro]

Originariamente inviato da CrapaDiLegno

Avrei voluto quotare quello che quotavi in risposta giusto per far capire che rispondi pere con mele o rispondi tanto per far polemica, ma sono da cell e la cosa è impraticabile. E non ho tutto il giorno.

La solita scusa del cellulare. Ti ho già detto nell'altro thread, ma anche altre volte, che nessuno ti obbliga a rispondere subito: prenditi il tempo che ti serve, e rispondi pure quando puoi. Che è quello che faccio io.

Se vuoi dire le stesse cose che dico io, perché rispondi con banalità come questa mentre prima proponevi benchmark CPU bound per fare confronti?
Io ho detto solo come secondo me dovrebbero essere fatti i test per capire se un processore può prendere il posto di un altro.
Tu hai detto la tua.
Ma ovviamente la mia non va bene. Però non dici perché. Solo polemica sterile.

Forse perché NON ho detto le stesse cose che hai detto tu? E non sono banalità, ma al limite ovvietà: è ovvio che ciò che chiedi è importante, e sottolineavo che, proprio per questo motivo, ci sono recensori che testano ANCHE quegli scenari d'utilizzo.

Vediamo se adesso l'hai capito o devo ripetertela un'altra volta.

Emulazione "non completa" quando devi emulare accessi a registri e a fkagydi status non di cosa voglia dire.

Perché hai fatto l'n-esimo errore di esporti su argomenti di cui sei completamente a digiuno, come risulta più che evidente, anche soltanto leggendo il modo in cui scrivi certe cose.

No, non mi riferivo a quello per emulazione "non completa". Perché l'accesso ai registri e ai flag di stato DEVE essere implementato, come ti ho già detto, e com'è lapalissiano.

L'emulazione "non completa" significa che, ovviamente, NON emuli TUTTE le caratteristiche dell'architettura (ISA), ma soltanto un sottoinsieme: quello che ti consente di coprire la stragrande maggioranza dei casi, e nella maniera più veloce possibile.

I casi particolari, per i quali l'emulazione di certe precise (ma NON comuni) caratteristiche farebbero mettere in ginocchio la velocità, sono quelli tagliati fuori, ma di cui in genere si può fare a meno per altrettanti ovvi motivi.

Intendi emulazione della micro architettura con emulazione di porte logiche e bus?

Quella non sarebbe emulazione, ma simulazione. A questo livello NON ci si arriva, ma ci si ferma MOLTO, MA MOLTO prima, perché altrimenti la potenza di calcolo richiesta sarebbe spaventosa elevata, ed è facile che si arrivi a far andare tutto in slow-motion.

A un livello più alto di questo c'è l'emulazione cycle-exact, dove viene emulato il funzionamento dei chip ciclo di clock per ciclo di clock, sostanzialmente in modo da riprodurre fedelmente l'accesso alla memoria e, dunque, consentire di sincronizzare perfettamente i vari chip presenti nel sistema.
Anche questo richiede parecchia potenza di calcolo (ma di gran lunga meno della simulazione di prima).
Ad esempio il MiniPC con l'ultimo Atom Apollo Lake che ho preso è in grado di far girare perfettamente in cycle-exact i giochi Amiga OCS/ECS, ma non quelli AGA (il frame-rate si assesta sui 42-45FPS a fronte dei 50 necessari per un'emulazione perfettamente fluida).

Ma l'emulazione "non-completa" di cui parlavo non ha nulla a che fare con tutto ciò: né con porte logiche et similia né col cycle-exact. Come ho già detto, è relativa a precise CARATTERISTICHE (lo evidenzio stavolta) la cui implementazione ucciderebbe le prestazioni.

Se uno conosce l'architettura x86/x64, sa già a cosa mi riferisco. E' veramente banale capirlo, visto che quest'ISA ha delle peculiarità che non sono presenti negli altri processori, sia moderni sia vecchi.
Aiutino: roba NON dell'8086, ma introdotta successivamente. Ed è roba che, come già detto, NORMALMENTE in user-land NON viene utilizzata dalle applicazioni.

Di elementi per capire di cosa parlo ce ne sono fin troppi. Qui si vedrà la differenza fra chi sa e parla con cognizione di causa, con chi la cultura se la fa googlando a destra e a manca, e non capendo argomenti che richiedono ben più della veloce lettura di qualche paginetta.

Eh? Sento dita scricchiolare tanto per dire qualcosa...

E solo quello ti resta, purtroppo per te, visto che non sei in grado di comprendere ciò di cui sto parlando.

Di indizi te ne ho messi abbastanza. Adesso tocca a te farci vedere cosa ne sai dell'argomento, tanto da indurti a intervenire parlando pomposamente in questo thread.

Non è il caso di Win32/64 che hanno base comune

Certo. Talmente comune che NON puoi mischiare arbitrariamente codice a 32 e 64 bit. E questo, al solito, lo sa chi ha studiato l'argomento. Mai sentito parlare di tunnelling? Di WOW64? Ecco qui, fatti una cultura: Running 32-bit Applications

"WOW64 is the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows.
[...]
The system isolates 32-bit applications from 64-bit applications
[...]
32-bit processes cannot load 64-bit DLLs for execution, and 64-bit processes cannot load 32-bit DLLs for execution"

Ma soprattutto: WOW64 Implementation Details

"The WOW64 emulator runs in user mode. It provides an interface between the 32-bit version of Ntdll.dll and the kernel of the processor, and it intercepts kernel calls
[...]
The thunks extract arguments from the 32-bit stack, extend them to 64 bits, then make the native system call.."

La chiave di tutto sta nell'ultima parte che ho evidenziato.

Il meccanismo, peraltro, è molto vecchio, e infatti è stato implementato già ai tempi dell'Itanium (che in comune con x86/x64 ha soltanto "Intel").

e non c'entra una cippa Linux che è un OS e che non necessita di emulare un bel niente se non a livello SW quando gira su x86. Prova a eseguire una "normale" applicazione x86 Linux su PPC.

Non hai capito nulla di quello che ho detto, e ovviamente la cosa non mi meraviglia.

Anche Linux usa un meccanismo come il WOW64, per far girare le applicazioni x86 in un kernel x64: How do 32-bit applications make system calls on 64-bit Linux?

Quello di cui parlavo prima è proprio questo. Ovviamente se l'hai capito. Se nemmeno dopo questi link e informazioni ti è chiaro, allora è un problema tuo:
la natura è stata matrigna.

Lo user-land che lavora in un certo modo... Utile per evitare che la funzione Move memoria-memoria non sia emulata su un processore che fa accesso solo ai registri da e per i registri.

Ma ancora parli di cose che ti sono completamente sconosciute? La MOVE mem-to-mem si chiama MOVS (ed è disponibile in 4 "tagli", dal byte alla quad word: MOVSB/W/D/Q), e FA uso di registri internamente. Quindi se vuoi implementarla correttamente dovrai per forza di cose aggiornare i registri utilizzati.

Ma la cosa ancora più importante è che si tratta di un'istruzione come un'altra (solo più complicata), e che qualunque emulatore x86/x64 DEVE ASSOLUTAMENTE implementare, visto che rimane ancora molto usata (sebbene sia un retaggio del passato: è presente fin dall'8086).

Dunque fa parte a pieno titolo del summenzionato user-land. Come QUASI tutte le istruzioni.

Il problema dell'emulazione "non completa" è di TUTT'ALTRA NATURA. Ma questo, ribadisco, lo sa chi ne capisce di architetture x86/x64, e di emulatori.

Quindi tu sei del tutto escluso, visto che continui a brancolare nel buio più completo, cercando di malamente di portare qualche straccio di argomentazione con dei termini che si sgama facilmente essere lontani anni luce da quelli che si usa in letteratura in merito.

Infatti uno che arriva a parlare addirittura di funzione Move quando non c'entra assolutamente (e nemmeno si chiama così, peraltro) con l'argomento di cui staremmo parlando, è come un ubriaco che si aggrappa al primo lampione che vede per non cadere giù (cit.).

E qui dimostri che la parola monopolio ti fa sbarellare completamente.

Qui dove? Non mi pare che la mia frase lasci intendere un qualche "sbarellamento", visto che si tratta di una precisazione, e il tono usato non lascia intendere altro.

A meno chi legge non soffra di manie di persecuzione, trovandosi costantemente sotto tiro.

Eppure c'è scritto che monopolio intendo. Eppure esiste quel monopolio. E tu stai parlando di altro giusto perché vuoi sprecare bit e il mio tempo.

Certo, adesso ridefiniamo anche il concetto di monopolio a tuo uso e consumo.

E siccome non hai nulla di intelligente da dire sull'argomento fai il puntiglioso per dimostrare che tu sai,

Diciamo che è poco intelligente parlare su un argomento di cui non si hanno conoscenze, con uno che invece ne ha, e pure in abbondanza. Sì, la differenza fra me e te è proprio quella che hai sottolineato: io so. Mentre tu non hai idea di quello che dici.

Si può dar credito a uno che non conosce nemmeno come si chiama un'architettura, inventandosi termini INESISTENTI al posto della nomenclatura ufficiale (e non)?

però poi insisti a parlare di un monopolio che ti dà fastidio venga accennato, ma che qui proprio nessuno ne ha parlato.

Ho semplicemente risposto sulla questione generale che era posta:

"Infine riguardo a monopoli, concorrenza, antitrust, ecc."

e in questi casi è facile che venga tirato in ballo il monopolio quando si parla di mercati chiusi (alla concorrenza), come peraltro hai ampiamente discusso tu. Dunque la mia era una mera elencazione di termini sull'argomento, come si può vedere qui sopra, dove ho riportato il pezzo di frase in questione.

Di quale fastidio parli, dunque? Al limite quello infastidito sei tu, visto che non ti va a genio essere ripreso anche su quest'argomento. Com'è ovvio, visto che non sai di cosa parli, e arrivi a inventarti anche un concetto di monopolio tutto tuo.

Pere, mele,banane, venghino signori, venghino, che la fiera delle banalità che non c'entrano con il discorso intsvolato è aperta!

Sei nella disperazione più cupa ormai, visto che la mia precisazione era perfettamente in topic. Si parlava di licenze e proprietà dell'architettura x86 o sbaglio? Ecco qui cosa TU avevi scritto:

"Che dimostra che l'architettura x86-32 è di proprietà esclusivamente Intel che ne può (o ha potuto) disporne come vuole fintanto che esiste AMD che le fa da contraltare"

Cosa assolutamente falsa, e che ho precisato in quella parte della mia replica, dove preciso come stiano esattamente le cose.

La fiera delle banalità? L'off-topic? Certo che hai una gran faccia tosta a cercare di mistificare, visto che TUTTO E' PARTITO DA TE!

La prossima volta invece di raccontare pure falsità, visto che dimostri di non sapere proprio il nulla assoluto degli argomenti che hai trattato, astieniti che fai meglio.

Vabbé, che uno che come nick ha CrapaDiLegno è già tutto un programma, e se continua ad accumulare figuracce non gliene frega nulla, ben protetto dall'anonimato.

Sì? Ah, boh, non credo di averlo letto. Dopo post come questi diventa un peso continuare a discutere di banalità e di roba che non c'entra nulla.

Continua pure ad arrampicarti sugli specchi, tanto hai ampiamente dimostrato quanto tu ne sappia (il nulla, appunto) di tutto ciò che s'è discusso finora.

Poi detto da uno che scrive papiri chilometrici col telefonino, ci credo proprio che non ha il tempo per leggere le repliche ai thread a cui ha partecipato.

Diciamo, piuttosto, che ne hai prese così tante, che non hai più voglia di ricevere altre mazzate. E, al solito, scegli di dileguarti e far affondare il thread nelle maglie del tempo, in modo da far sparire le tracce delle balle che hai raccontato. Ma tanto i commenti sono lì che aspettano di essere rispolverati alla prima occasione utile, sbattendoteli nuovamente in faccia.

In verità la maggior parte delle applicazioni Android sono scritte usando la VM e solo pochissime (per lo più i giochi pesanti) usano il codice nativo.

E qui dimostri di non capire nemmeno quello che scrivono gli altri. Ecco qui cos'avevo detto:

"la stragrande maggioranza delle applicazioni native è compilata per ARM"

Se sono native è OVVIO che non stavo parlando di quelle per la VM, ma quelle compilate con l'NDK di Android (indovina cosa significa la N).

E' ovvio, ma solo per chi sa ciò di cui sta parlando, ovviamente.

Ed è solo tua questa idea che è stata la "non compatibilità" con arm ad aver ucciso il mercato mobile di Intel. La verità che ti brucia è che semplicemente il suo HW non era alla pari per costi / consumi con la concorrenza. Sotto Android x86 non mancavano certo le app.

Non ho mai detto che la causa fosse soltanto quella. Al solito mistifichi, mettendomi in bocca cosa che non ho scritto.

La causa principale è quella del ritardo accumulato, come già detto. E dunque il supporto nativo a IA-32 era molto ridotto. A ciò si aggiunge che per le applicazioni esclusivamente ARM, ha dovuto sviluppare un emulatore, con tutte le conseguenze del caso.

E quindi?
Poi recenti... Forse la copia di MS di Java, ma Java non è così tanto giovane.

Java no, ma il concetto di IL è antidiluviano. E, come già detto, non ha certo preso il sopravvento da quand'è nato. Oggi, come ieri, c'è spazio sia per le applicazioni compilate appositamente per una certa architettura, sia per quelle che sono compilate facendo uso di uno degli IL.

Quanto a .NET, non è certo la copia di Java. Tutt'altro. Ma nulla di nuovo: continui a (s)parlare di cose che sconosci completamente.

No. L'Antitrust ha obbligato Intel a continuare a dare la propria licenza x86 a un concorrente per esplicita richiesta di IBM, e la scelta cadde su un minuscola azienda che al tempo faceva della produzione di flash il suo core business (della serie, basta che c'è l'abbia qualcuno che mai potrà porre problemi di concorrenza reale).
Da quel momento in poi le cose sono profondamente cambiate, sua in termini di dipendenza tra le due aziende sua in termini di mercato.

Su questo t'abbiamo già risposto LMCH e io: tu non hai la minima idea di come siano andate realmente le cose. E continui a inventarti cose che cozzano violentemente contro la storia. Quella ufficiale, non quella di CrapaDiLegno.

Informati invece di raccontare astronomiche balle come queste.

È innaturale il fatto che l'ingresso di un concorrente non sia fatto sulla base della qualità dei suoi prodotti ma del dover necessariamente negoziare per permettersi la compatibilità con il pregresso. Se non lo hai capito, torna a leggere i bigini su cui hai studiato.

E chi se ne frega che PER TE sia innaturale. Meno male che non sei tu a fare le leggi sulla concorrenza.

Invece di raccontar frottole sistematicamente dovresti, invece, DOCUMENTARTI prima di parlare di cose che sconosci del tutto, pretendendo di far passare il tuo inutile pensiero al posto della normativa consolidata in materia.

I compiti a casa fatteli tu. SE ne sei capace, ovviamente.

Ma non hai capito che qui nessuno vuole fare un processore x86. Nessuno sano di mente investirebbe in tale cosa al giorno d'oggi.

Ma non ne azzecchi proprio una, eh! C'ha provato proprio di recente la tua amata nVidia, col suo Project Denver, invece, che inizialmente doveva essere compatibile x86, e alla fine ha dovuto dirottare su ARM proprio perché non aveva una licenza e non poteva ottenerla da Intel.

Ecco qui: NVIDIA Project Denver “Lost in Rockies”, to Debut in 2014-15

"NVIDIA is developing Project Denver for better part of the past decade. The company acquired Colorado-based Stexar in 2006, with a plan to develop a binary compatible architecture with the x86 instruction set, with or without Intel's permission/license. The original architecture called for a similar approach used by Transmeta with a translation layer being the core part of the architecture. However, luckily for NVIDIA, then tiny ARM started its ascent into the contemporary computing with the new generation of smartphones. As such, NVIDIA's R&D shifted focus from being binary compatible with x86 into an extended ARM architecture. Needless to say, this practically required starting from scratch."

Quindi per te nVidia non sarebbe stata sana di mente. Ovviamente detto da uno che ne capisce di architetture & co., ha sicuramente un grande valore.

Si vuole solo essere compatibili con gli eseguibili già esistenti. Che è cosa ben diversa.

Ed è di questo che stiamo parlando, mi pare, ma bisogna vedere se è LEGALMENTE POSSIBILE oppure no.

Magari NON lo è, visto che pure nVidia è stata costretta a fare dietro front.

E' chiaro il concetto?

In più la differenza è che se paghi arm concede la sua licenza a tutti. Intel no. E quindi c'è un problema di accesso alla tecnologia.

Infatti, e bisogna prenderne atto. Ci sono cose che si possono fare, e altre no.

Intel ha tutto il diritto di NON fornire altre licenze IA-32. Se non ti piace, puoi benissimo rivolgerti ad ARM o altre aziende che vendono licenze per le loro IP.

Ma nel mercato x86 la situazione è quella: che piaccia o no. Ed è inutile strapparsi le vesti e discuterne. Ognuno con le proprie IP ci fa quello che vuole. Punto.

Huh, e questo che c'entra con l'argomento? Chi ha mai parlato di arm come azienda licenzuataria? Ti è andato di traverso il neurone dopo aver letto tutte quelle frasi contenenti "monopolio"?
ARM qui è sempre stato inteso come architettura, non chi la fa.
Fai confusione tra architettura e azienda che la implementa.
Monopolio x86 non è monopolio Intel, ARM che avanza non è l'azienda Inglese che stampa sempre più processori.
Hai diversi problemi a comprendere i discorsi. Te l'ho già detto.

Si è parlato di ARM come architettura, licenziataria, e azienda che la licenziano, per cui s'è fatto un gran calderone.

Comunque Intel NON ha più il monopolio di IA-32 da un bel pezzo, per cui inutile continuare a utilizzare questo termine.

Di cosa parli? Del mondo informatico intero? O di quello desktop?

Era un discorso generale, quindi che includeva anche il desktop.

Perché in quest'ultimo caso, nell'eventualità che entri una architettura diversa da x86 (che è monopolista, già) le cose possono cambiare radicalmente per davvero.

Sono già arrivate da un pezzo architetture diverse da x86. L'esempio più eloquente è rappresentato dai Chromebook di Google, che sono basati su ARM, e che ovviamente ricadono proprio nel settore desktop.

Vedi sopra x monopolio e risposta ad altro in altro thread.

Idem.

Il connubio non si è mai rotto nonostante i tentativi di ms di trovare una alternativa a Intel nei mercati in cui quest'ultima ha fallito miseramente.
Dimmi, oggi, quanti dispositivi con Windows che non siano x86 sono in produzione?

Quanti non lo, ma la XBox 360 ne è la prima dimostrazione, essendo questa console basata su PowerPC. Windows mobile (NON Windows Phone) è basato su ARM fin da quando è nato, e ci sono ancora dispositivi che vengono usati. Windows per Itanium non viene più sviluppato, ma c'è ancora. Windows RT è stato l'ultimo arrivato, ed era basato su ARM. Questo rimanendo in ambito Microsoft / Windows.

Viceversa, Intel già da anni s'è buttata in altri progetti che sono basati su Linux (ma supporta anche *BSD), a partire da Yocto (che è la "meta distro" per eccellenza usata in ambito embedded), a MeeGo, fino a Tizen.

Dunque di quali duopolio Winintel continui a parlare, visto che DA PARECCHI ANNI non è più così? Ma, soprattutto, dove vivi? Nascosto in una grotta, visto che queste cose si sanno da tempo immemore?

E nonostante il fatto che ti arrampichi sugli specchi vale quello che ho detto io:

Certo, sono io che porto FATTI e argomentazioni che mi arrampicherei, e la gente dovrebbe credere a te che sei un bugiardo nonché ignorante matricolato, che hai ampiamente dimostrato di non conoscere né capire nulla di architetture, micro-architetture, s.o., applicazioni, programmazione, e perfino la storia dell'informatica che era la cosa più facile da poter comprendere e ricordare.

Ma poi detto da un pinco pallino qualsiasi internettiano, senza arte né parte, che nella vita non ha fatto nient'altro che spararle grosse, nascondendosi dietro a un nick, sei proprio da prendere in fiducia... da credere sulla parola.

se Intel non rintuzza questo attacco al suo ultimo argine composto al 100% dalla sola compatibilità, allora sì che il connubio Wintel muore e per Intel comincia una nuova era dove deve pesantemente innovare e innovarsi (= un sacco di soldi in più in R&D, e non da diluire in un secolo, ma in fretta, che gli altri non sono mica fermi come 10 anni fa).

Certo che sei proprio una macchietta: vivendo nel tuo universo parallelo non ti sei ancora accorto che Wintel non esiste più da tempo.

E non sai nemmeno che Intel ha già diversificato (e continua continuamente a farlo) il suo business da tempo.

E', insomma, da tempo che Intel sta lavorando per non essere legata esclusivamente a IA-32. Questo chi s'informa lo sa già da tempo, ma ovviamente NON è il tuo caso.

Monopolio, monopolio, sì, esiste. Leggi meglio e ti viene detto quale. Sì, esiste, leggi meglio e ti viene detto quale. Sì, esiste, leggi meglio e ti viene detto quale.
Repetita juvant, poi se vuoi continuare a parlare da solo dell'unico monopolio che conosci, allora continua da solo.

Qui arrivi addirittura a livelli da infantilismo: ripetere a pappagallo delle cose, come se queste diventassero vere solo a forza di ripetizioni.

Direi che si commenta già da sé.

In verità è il contrario di cosa se io non ho mai detto nulla di ciò che parli, ma dicendolo stai dandomi ragione sul fatto che il ciclo Intel vendo di più, produco di più, investo nel PP, taglio il prezzo rispetto alla concorrenza, quindi vendo di più, investo in nuovo PP, taglio il prezzo rispetto alla concorrenza, e via, con gli altri che boccheggiano perché hanno alti costi di sviluppo e sempre meno vendite?
Il contrario de che? Ma quando rispondi ti assucuri di aver compreso quello di cui si parla?

Detto da te lo prendo un complimento. Specialmente il tuo "in verità", che è veramente esilarante da uno è che costantemente dedito alla menzogna.

Comunque fra i big del settore server c'è IBM, che è stata sempre leader in ambito dei processi produttivi nonché soluzioni per server, mainframe, e perfino HPC / Supercomputer.

Dunque Intel NON era l'unica ad avvantaggiarsi di nuovi processi produttivi. Nonostante questa concorrenza, però, è riuscita a imporsi anche in quegli ambiti. E soltanto negli ultimi anni IBM ha ceduto il passo, svendendo pure le sue fabbriche.

Ma il dominio di Intel era, però, già affermato.

Questo riportare un po' di FATTI nonché storia reale, e non le tue invenzioni.

Ma qui sfiori il ridicolo portando esempi di realtà diverse rispetto a quello di cui si parla. Di alternative vere finché c'è il monopolio dell'architettura x86 e dei suoi eseguibili non esisterà mai.

Si parlava di SERVER, e confermo quello che ho detto: NON c'è la stessa situazione che su desktop. La maggior parte delle macchine gira su Linux, usando software open source, e che può essere compilato tranquillamente per qualunque architettura.

È come credere che finché MS non fosse stata obbligata a usare formati open, o non ci fosse il reverse engineering dei suoi formati proprietari potesse esistere una alternativa a Office.

Ma quanta ignoranza. Continui ancora a parlare di cose di cui non hai la benché minima conoscenza.

Non c'è mai stato bisogno di alcun reverse engineering dei formati di Office, perché Microsoft ne ha pubblicato EONI fa le specifiche complete!

A tal proposito avevo scritto un articolo ben 8 anni fa (I formati “proprietari”: dalla contingenza alla forca), in cui ne riportavo anche il link: Technical Documents

Da quest'ultima pagina:

"Specifies the Word (.doc) Binary File Format, which is the binary file format used by Microsoft Word 97, Microsoft Word 2000, Microsoft Word 2002, and Microsoft Office Word 2003.
[...]
Specifies the Office VBA File Format Structure, which describes the Microsoft Visual Basic for Applications (VBA) File Format for Microsoft Office 97, Microsoft Office 2000, Microsoft Office XP, Microsoft Office 2003, and the 2007 Microsoft Office system. This specification also describes a storage that contains a VBA project, which contains embedded macros and custom forms for use in Office documents.
[...]
Specifies the PowerPoint (.ppt) Binary File Format, which is the binary file format used by Microsoft PowerPoint 97, Microsoft PowerPoint 2000, Microsoft PowerPoint 2002, and Microsoft Office PowerPoint 2003.
[...]
Specifies the Outlook Personal Folders File Format, which provides the necessary technical information required to read and write the contents of a Personal Folders File. Each Personal Folders File represents a Message store that contains an arbitrary hierarchy of Folder objects, which contains Message objects, which can contain Attachment objects. Information about Folder objects, Message objects, and Attachment objects are stored in properties, which collectively contain all of the information about the particular item.
[...]
Specifies the Excel Binary File Format (.xls) Structure, which is the binary file format used by Microsoft Excel 97, Microsoft Excel 2000, Microsoft Excel 2002, and Microsoft Office Excel 2003."

Questo per riportare quelli più noti e importanti.

Stai dimostrando che sei ancora attaccato alla vecchia maglia, e questo ti offusca il cervello.

Qui l'unica cosa chiara è che sei un emerito quanto arrogante ignorante, che si riempie la bocca di cose di cui non ha la minima conoscenza.

I concorrenti possono portare prodotti buoni o anche migliori nel momento in cui non devono partire un chilometro indietro in una gara dei 100 metri. Se e quando potranno eseguire codice x86 in maniera decente senza necessariamente dover investire nel costruire un processore con architettura x86 e quindi sottostare agli ovvi dinieghi di Intel, allora si avrà un radicale cambiamento che oggi, come nei 2 decenni passati, non è stato possibile.

Quello che ti sfugge in tutti questi discorsi riguardanti passato, presente d futuro di Intel è che tu parli sempre e solo con visione miope Intel centrica, in cui Intel non è un elefante in una vetreria che tiene lontani tutti gli altri che ovviamente non possono competere ad armi pari.

Ma quante balle che continui a riportare. QUI SI PARLAVA DI SETTORE SERVER! NON DESKTOP! Per cui non sta minimamente in piedi questa cialtronata che hai riportato, tentando malamente (nonché inutilmente) di cambiare discorso.

Ma io te lo dissi riguardo al mobile, che le cose stavano cambiando, e là dove un solo concorrente con PP vecchi non ha speranza, l'unione di un insieme di aziende che avrebbero investito tutte nella stessa cosa dando soldi ad altri, avrebbe innescato una onda bella alta.
Fatto sta che oggi non si parla di Motorola con 2 PP più vecchi, non si parla di Sun che vendeva 1000 processori al mese, non si parla di uno contro uno dove la forza del mercato di scala di Intel è riuscita a seppellire tutti i concorrenti.

C'è riuscita soltanto negli ultimi anni, perché realizzare o aggiornare fonderie è divenuto un business estremamente costoso, nonché rischioso. Ecco perché ormai sono rimasti soltanto QUATTRO fonderie al mondo.

Ed è il motivo per cui perfino IBM, che ancora oggi rimane un colosso, ha deciso di dismettere le sue fonderie e cederle a GlobalFoundries, PAGANDO quest'ultima pur di levarsele dai piedi, e consentendogli così di rimanere un'azienda di software e servizi.
Anche sull'architettura POWER ha capitolato, fondando il consorzio OpenPOWER e di fatto chiedendo aiuto a partner esterni per lo sviluppo di quest'ISA.

Stiamo parlando di una serie di aziende che in totale investono quanto e più di Intel, che vendono in fatturato molto di più, che hanno invaso il mercato con prodotti non x86 dipendenti che ha permesso di investire in sistemi di sviluppo alternativi con ottimo supporto, che oggi si fanno anche i processori in casa (sì, anche Google, cosa assurda solo pensarlo 10 anni fa), che creano un indotto tale che permette investimenti duraturi su altro che non sia x86 che fanno diminuire i pezzi venduti x86, il silicio necessario, le fabbriche necessarie e i guadagni relativi. Ad Intel sta subendo quello che lei ha causato agli altri.

Guarda che Intel è da anni che diversifica i suoi investimenti, e non è più legata mani e piedi a IA-32. Ma questo lo sa chi segue il mondo IT e s'informa, non uno che ha ampiamente dimostrato di vivere in un universo parallelo.

Con un vantaggio per lei dovuto al l'accumulata quantità di SW compilato per la sua architettura.

In ambito desktop, come già detto. Non in altri mercati, incluso quello server.

Se lo vuoi capire. Se non lo vuoi capire, vuol dire che la natura è stata matrigna con te.

Tolto quell'ostacolo si apre una nuova era, dove al cambiamento di paradigma nella programmazione (non più solo nativa x86) si avrà davvero un mercato dove vince chi fa meglio è non chi è stato scelto 40 anni fa all'esordio dell'era del PC.

Si vabbé, parole, parole, parole. Andiamo avanti.

P.S: non sto qui a quotare anche la parte sulle avx, ma è ovvio che stai cercando di "barare" e di brutto.
Quel tipo di istruzioni sono immensamente complicate per fare in modo che un compilatore le usi nativamente estrapolandole dal codice.

E qui arriva un'altra perla del solito CrapaDiLegno che di architetture ne capisce quanto io di bricolage.

L'hai mai aperto un manuale di Intel o AMD, nella parte relativa alle unità SIMD? Mi pare proprio di no.

Dunque, in cosa sarebbero "immensamente complicate" le AVX? Esponi e vai pure nel dettaglio quanto vuoi, visto che le conosco a mena dito. Così vediamo cos'altro t'inventerai.

Ah, dimenticavo: i compilatori sono così bravi nell'usare le AVX, che GCC genera codice abbastanza scarso, e se vuoi sfruttarle al meglio sei costretto a scrivere codice assembly o a usare appositi intrinsic. Cosa che fanno la maggior parte degli sviluppatori.

Ma qui abbiamo davanti il genio incompreso delle architetture, che ci spiegherà come funzionano nel suo universo parallelo.

Perché vengano sfruttate veramente si devono usare funzioni prescritte

Funzioni "prescritte"? E che sarebbero? Ma di cosa stai parlando, di verdura venduta al mercato?

T'inventi termini inesistenti in letteratura perché sei un emerito ignorante che pretende di dare maldestramente lezioni basandole su ciò che conosce: il nulla.

e questo vuol dire che l'algoritmo ad alto livello può essere facilmente adeguato ad altre librerie che fanno riferimento ad altre implementazioni.

E facci vedere come, allora. Tira pure fuori qualche esempio di codeste "funzioni prescritte", possibilmente con un software "di spessore" che ne faccia uso.

Non dovrebbe esserti difficile, no? Tanto sai tutto tu, qualunque sia l'argomento!

Poi mi dici pure in che modo un processore ARM si troverà ad emulare agevolmente le AVX (e qui non parlo nemmeno delle AVX-512, che sono un'ISA SIMD nuova di pacca, con peculiarità che non hanno altre architetture).

Considerato che perfino AMD, che offre una micro-architettura "nativa", ha le sue difficoltà con le AVX, visto che con questo tipo di codice le prestazioni dei suoi processori ne risentono anche di molto (i processori Intel arrivano a essere fino a TRE VOLTE più veloci), sono proprio curioso di vedere l'impatto di un emulatore x86 con codice SIMD moderno.

Nel mercato per cui questi mega complessi circuitali sono destinati l'implementazione proprietaria non conta nulla.

?!? Che vuoi dire? Sii chiaro.

E ritornando al discorso di prima, se prima non c'era nessuno in grado di proporre SW e HW alternativo che fosse economicamente sostenibile (solo Nvidia lo ha fatto, e solo in contesti limitati), oggi molti altri possono.

E infatti si vede proprio dove sia andata a finire nVidia: ritirata dal mercato. E s'è buttata sull'automotive. Ma tu guarda un po'...

La nuova corsa all'IA lo dimostra: gli storici big del silicio non sono più gli unici che possono giocare.

Questo dell'IA è un campo che è stato sempre oggetto di soluzioni proprietarie, invece, dove x86 ha fatto scarsamente presa.

Ma proprio Intel ha presentato nuove soluzioni per entrarci. In un settore nuovo per lei, dunque, che come dicevo sta diversificando sempre di più il suo business. E ovviamente a danno di altri che sono già presenti.

D'oh, ho i crampi alle dita.

Fagli un favore, allora: falle riposare. Se devi usarle per scrivere incommensurabili sciocchezze e falsità varie, come sai fare di solito visto che non sai fare altro, è meglio che risparmi loro una fatica inutile, visto che alla fine tutte le balle che racconti vengono sistematicamente smontate, e tu fatto a pezzi pubblicamente.