Intel APO si aggiorna: supporto a 15 nuovi giochi e fino al 21% di prestazioni in più

L'HW evolve e si è complicato nel tempo. 1, 2, 4, 8, 16, 32 core, fisici, logici, con unità AVX o senza. Il non voler attivamente fare "più lavoro" (che in questo caso significa far capire all'OS che tipo di lavoro fa il thread, non è che serve fare un codice completamente diverso per ogni tipo di core) per sfruttarli al meglio significa solo giustificare chi non vuole lavorare come si deve.
Se avessimo detto le stesse cose con l'arrivo dei dual core oggi saremmo ancora con un solo core perché "hey richiede MOLTA più programmazione sfruttare 2 core!". Anzi direi che il passaggio dal mono-thread al multi-thead (che siano 2, 4 o 32) sia stato una delle difficoltà maggiori in assoluto che i programmatori hanno dovuto imparare a gestire. E l'hanno fatto!
Qui invece è solamente taggare dei thread per farli eseguire sul core appropriato.

I processori enterprise usano core omogenei (tutti p-core o tutti e-core) per il semplice motivo che il tempo di elaborazione deve essere conosciuto a priori perché tutta la gestione del chip sia ottimale sul tipo di carico di lavoro che svolgono. Tipo che una query non può metterci 3ms per un cliente se su P-Core o 6ms per un altro cliente su un E-core a seconda di dove si è fortunati ad essere stati allocati.
Su un processore desktop i carichi di lavoro sono differenti e l'usare un tipo o un altro di core ha il suo perché. Così come ha senso usare la NPU quando possibile invece che i normali core. Ma qui non ci sono carichi multi-client che concorrono alle stesse limitate risorse e a cui va giustamente garantito l'uso egualitario.


E quindi? Anche quando Intel ha introdotto il Pentium-D era necessario del codice supplementare per usare i 2 core. Questo rendeva le CPU mono-thread migliori? O la programmazione multi-thread è diventata bella e possibile e con zero fatica solo quando è arrivato l'Athlon X2 di AMD?
Non ho capito cosa state cercando di affermare... che una modifica che richiede il supporto da parte dello sviluppatore è una modifica negativa?
Quindi l'espansione al set 64-bit è stata una cosa abominevole perché ha richiesto un sacco di lavoro e supporto supplementare?

AMD va meno in alcuni contesti se sfruttati così come FX andava meglio degli i5 se saturavi tutti e gli 8 i threads, però poi sappiamo come è finita.

Non hanno bisogno di giustificazioni, continueranno a trascurare l'ottimizzazione, quindi spesso finisce che debba essere l'utente finale a venire incontro tramite l'uso di un hardware più prestante per sopperire alla mancanza di ottimizzazione.

Inasprire la complessità non paga, inutile ragionare per "ideali".

Sbagliato.

Con l'avvento dei 2 cores c'era il problema che veniva sfruttato solo il core 0.
Quì invece il problema è sfruttare quello corretto, che è diverso ma soprattutto spesso inutile ( nelle conversioni e l'editing video, con gli ultimi prodotti a far da padrona è l'accelerazione hardware fornito dalla GPU oramai )

Problema quello dello sfruttamento delle cpu che ancora oggi non è stato mica risolto, visto che buona parte delle applicazioni non sfrutta le potenzialità delle CPU. E Intel cosa fa ? Complica ancora di più.



Per questo AMD sta recuperando quote di mercato ovunque in barba al numero di cores.
Perchè diciamolo chiaramente, questo approccio nasce per cercare di recuperare performance su AMD e basta, anche attraverso specifiche pompate su carta ( proprio come fece AMD con FX ).

AMD ha recuperato market share perché Zen permette di avere una ottima soluzione di scaling, da 6 fino a 32 core. E il tam-tam mediatico oggi funziona esattamente come funzionava per Intel ieri: AMD è meglio perché fa i processori X3D. Allora sono meglio in tutto e per tutto anche gli altri, quando invece le prendono dai processori Intel. Testimonia questa cosa l'esplosione di vendita dei chip X3D anche là dove non sono abbinati a una GPU top gamma.
Ma non è tutto rosa e fiori quel che luccica anche in casa AMD.

Intel si è inventata un modo per risparmiare transistor, o meglio mettere nello stesso numero di transistor più core possibili.
Che sia la soluzione migliore o meno non lo so, ma funziona. Là dove non funziona nativamente, bastano 10 minuti di aggiornamento del codice per farlo funzionare correttamente. Cosa che è stata fatta per TUTTI i SW di produttività ancora in sviluppo o comunque tenuti aggiornati.
Se il programmatore ha il cervello in ferie o il tool non è più mantenuto, Intel ha il thread director che aiuta. Non sarà la soluzione perfetta per il codice vecchio, ma per quello nuovo è palese che non vi siano problemi di supporto. Non siamo ai livelli di dover cambiare completamente approccio alla programmazione per usare più di un thread contemporaneamente. Non si parla neanche di adeguare gli algoritmi per l'uso di un set di istruzioni completamente nuovo.
Inoltre in un bilancio numero di thread/prestazioni Intel vince a mani basse perché bastano 24 thread (16 di cui lavorano su chippetti di dimensione minima rispetto al core più grande) per raggiungere le stesse prestazioni di un 32 core.
24 thread significa che l'applicativo e l'algoritmo che usa non deve gestire e sincronizzare più thread e relativa divisione dei dati su cui operano. Il che è una semplificazione, non una complicazione.

Il metodo inventato da Intel potrai definirlo sbagliato, ma nel frattempo ha obbligato AMD a creare i c-core e a modificare i CCD per accogliere 12 core invece che 8, altrimenti lo scaling ai futuri annunciati 48 core non ci arrivavi a cifre "umane". Quindi tanto sbagliato non è se ha indotto la concorrenza a modificare come poteva le sue architetture per poter competere.
Alla fine, dopo l'approccio multi-chiplet di AMD, abbiamo avuto una ulteriore accelerazione dell'aumento dei core integrati in un singolo chip, e checché tu ne dica, il consumo con l'architettura ibrida non è esploso.
L'ultima architettura AMD per aumentare le prestazioni è passata a consumare il 50% in più di energia, Intel l'ha diminuita.

Detto questo che è una discussione più filosofica che altro, parliamo del concreto.
Utile questa corsa all'ultimo core? Boh, io personalmente non lo so, trovo davvero difficile che un utente a casa propria usi applicativi che creano così tanti thread per fare un lavoro. Come hai ben detto tu ormai la conversione video si fa più velocemente e con meno dispendio di energia usando l'HW nelle GPU e chi fa rendering 3D è uno sparuto numero di persone. Chi usa un qualunque altro programma mega-thread (nominane pure alcuni che non siano benchmark, prego) ogni tanto, tipo per la de/compressione, frega nulla che ci metta 10 secondi invece che 5.
Io che uso spesso git, anche in locale, vedo che il supporto del processore a 1 o 32 thread cambia nulla, per cui il test sbandierato di compressione/decompressione fatto usando un tool che uso forse 2 volte al mese (7-zip o peggio WinRAR che credo ormai è usato solo dai dinosauri o sui siti di warez) su grandi archivi non ha alcun significato. Per me. Non giustifica avere 48 core.
Ho più di 8 core perché compilando, più ne hai prima finisci. Ma fino a un certo punto, perché il linker è mono-thread e fa da collo di bottiglia. Per cui se anche dimezzi i tempi di compilazione ma il linker impiega lo stesso tempo (ed è maggiore sui processori AMD che non sono così veloci con gli applicativi mono-thread) alla fine il ritorno dell'investimento nei core aggiuntivi è vanificato.

Se installi un qualsiasi applicativo di diversi giga, Windows usa un thread e mezzo, quindi il tempo di attesa non dipende se hai 4 o 32 core. Stessa cosa per la miriade di azioni che si compiono ogni giorno. Quindi superata una certa soglia di core a disposizione, direi 8 per chi usa il PC per attività "normali", il ritorno prestazionale rispetto al costo del processore piomba asintoticamente verso zero.

no recupera quote di mercato perché fa più fps nei giochi che è la cosa più triste di tutta la diatriba dato che ormai il pc consumer casalingo è diventato banalmente una console di lusso ad uso gheiming e stop...

al di là di questo l'architettura ibrida la usa Apple da anni con i chip M e nel mondo mobile (e non solo) l'architettura ARM domina da sempre quindi in realtà se vogliamo dirla tutta è AMD che è rimasta sull'approccio architettura vecchia con l'"accrocchio" per macinare più fps che è quello che vuole la massa

preciso che non lo sto dicendo in senso dispregiativo

Mi hai fatto venire in mente quel collega che si è preso un 9800X3D perché ha visto qualche video su YT che dice che è il migliore di tutti, quando lui il PC in questione lo userà solo per lavorare.