Link alla notizia: https://www.hwupgrade.it/news/cpu/intel-apo-si-aggiorna-supporto-a-15-nuovi-giochi-e-fino-al-21-di-prestazioni-in-piu_143103.html

Con il nuovo aggiornamento, Intel APO - una policy software all'interno del framework Intel Dynamic Tuning Technology che ottimizza lo scheduling dei thread - ha introdotto il supporto a 15 nuovi titoli per offrire prestazioni migliorate del 21%.

Click sul link per visualizzare la notizia.

La necessità di usare un'applicazione che faccia tuning indica il fallimento dell'architettura P-Core ed E-Core.

Se Intel e Microsoft non sono in grado di gestire un'architettura disomogenea, meglio allora buttare tutto via e tornare ai core tutti uguali.

La necessità di usare un'applicazione che faccia tuning indica il fallimento dell'architettura P-Core ed E-Core.

Se Intel e Microsoft non sono in grado di gestire un'architettura disomogenea, meglio allora buttare tutto via e tornare ai core tutti uguali.

Certo, se per ogni novità architetturale avessimo usato questo principio saremmo ancora con il set di istruzioni del 1975 senza FPU. E con una sola architettura, visto che le altre non sarebbero state così supportate/performanti alla loro introduzione.
E Apple non avrebbe mai fatto il salto di 4 architetture diverse, sarebbe ancora con il Motorola 68000 visto la quantità di aiuti, ottimizzazioni esterne, oltre agli emulatori, necessari per adattare un vecchio codice alle nuove architetture.

Gli unici ad aver problemi a ottimizzarsi sulle architetture ibride Intel sono i giochi. E lo sai perché? Perché molti di quelli sono pensati per essere usati sulle console che hanno solo core omogenei. Altri giochi che hanno come riferimento il mercato PC girano divinamente sulle architetture ibride perché sono stati aggiornati per sfruttarle. Il problema non è l'HW, è il supporto di alcuni sviluppatori che è rimasto al medioevo.
Le applicazioni di produttività hanno goduto parecchio del passaggio dai 10 core tutti uguali ai 24 nonostante questi siano di tipo differenti.

Certo, se per ogni novità architetturale avessimo usato questo principio saremmo ancora con il set di istruzioni del 1975 senza FPU. E con una sola architettura, visto che le altre non sarebbero state così supportate/performanti alla loro introduzione.
E Apple non avrebbe mai fatto il salto di 4 architetture diverse, sarebbe ancora con il Motorola 68000 visto la quantità di aiuti, ottimizzazioni esterne, oltre agli emulatori, necessari per adattare un vecchio codice alle nuove architetture.

Gli unici ad aver problemi a ottimizzarsi sulle architetture ibride Intel sono i giochi. E lo sai perché? Perché molti di quelli sono pensati per essere usati sulle console che hanno solo core omogenei. Altri giochi che hanno come riferimento il mercato PC girano divinamente sulle architetture ibride perché sono stati aggiornati per sfruttarle. Il problema non è l'HW, è il supporto di alcuni sviluppatori che è rimasto al medioevo.
Le applicazioni di produttività hanno goduto parecchio del passaggio dai 10 core tutti uguali ai 24 nonostante questi siano di tipo differenti.
Il punto della questione è che l'approccio di Intel è sbagliato.

Ci lamentiamo sempre della scarsa ottimizzazione su PC e poi cosa fanno ?
Tirano fuori un architettura che RICHIEDE programmazione supplementare per funzionare, e questo ALDILA' di AMD.

Dovrebbero fare il contrario semmai !
Ossia semplificare quanto più possibile il lavoro di ottimizzazione degli sviluppatori attraverso hardware che richiedano meno programmazione possibile !

Ad esempio la fantasticheria su un software reverse SMT sarebbe invece ottima.
Il programmatore avrebbe 1 solo core logico, punta tutti i task su quello e via.

Gli unici ad aver problemi a ottimizzarsi sulle architetture ibride Intel sono i giochi. Hai detto poco.

Hai detto poco.

cosa ti cambia se un gioco ognitanto ti va 10% in meno realmente non ti cambia nulla di nulla magari ti fa 150fps invece di 160, nemmno li vedi

cosa ti cambia se un gioco ognitanto ti va 10% in meno realmente non ti cambia nulla di nulla magari ti fa 150fps invece di 160, nemmno li vediOgni tanto ?
Non si tratta di soli cali di frame rate ma di comparsa di stuttering.
Aldilà di ciò però è innegabile che richieda programmazione supplementare, c'è poco quindi da giustificare.


Sta porcheria quì va bene solo su mobile dove devi risparmiare batteria e nonostante ciò non fornisce vantaggi significativi.
Anche lato enterprise i prossimi chip saranno omogenei anche se formati unicamente da cores-E.

Anche lato enterprise i prossimi chip saranno omogenei anche se formati unicamente da cores-E.

da quel lato è normale che non si usino, noi parliamo di desktop

Il punto della questione è che l'approccio di Intel è sbagliato.

Ci lamentiamo sempre della scarsa ottimizzazione su PC e poi cosa fanno ?
Tirano fuori un architettura che RICHIEDE programmazione supplementare per funzionare, e questo ALDILA' di AMD.

Dovrebbero fare il contrario semmai !
Ossia semplificare quanto più possibile il lavoro di ottimizzazione degli sviluppatori attraverso hardware che richiedano meno programmazione possibile !

Ad esempio la fantasticheria su un software reverse SMT sarebbe invece ottima.
Il programmatore avrebbe 1 solo core logico, punta tutti i task su quello e via.

Hai detto poco.
Ottimizzazione è usare al meglio le risorse. Ci sono diversi livelli di ottimizzazione possibili.
Anche l'architettura HW può essere ottimizzata per sfruttare la meglio quello che ha a disposizione tipo i W e transistor. E non deve essere (e non è sempre stato) retro compatibile dal punto di vista della efficienza.
Quello che stai dicendo tu è che l'HW non deve migliorare/cambiare perché altrimenti il codice "vecchio" o quello creato da una scimmia con i tool automatici gira male e per ovviare a questo i programmatori devono usare più neuroni per fare in modo che il proprio SW giri al meglio sulle nuove soluzioni.

In verità chi programma ha ben a cuore che il proprio SW giri al meglio, soprattutto sulle architetture più diffuse, e infatti come detto i programmi di produttività sono aggiornati in tal senso. E vediamo nei benchmark come per questi programmi usare gli e-core non comporta un gran problema di prestazioni se sono in grado di sfruttarne il gran numero a disposizione.
Come lo è sempre stato l'adozione di un nuovo set di istruzioni (MMX, SSE, 3DNow, AVX e tutte le loro sotto varianti).
Anche il set di istruzioni x64 ha portato al dover ottimizzare meglio certo codice, o anche a renderlo incompatibile se non adeguatamente supportato dall'OS.

Chi ancora non ottimizza per le nuove architetture sono solo (alcuni) sviluppatori dei giochi perché hanno come target solo le console che sono 8 core SMT e quindi non gliene frega nulla definire quali siano i task low priority o taggarli per identificarne le caratteristiche e difficilmente usano più di 8 thread per evitare di dover gestire la concorrenza sui core logici delle CPU di questi baracchi.

Gli sviluppatori che invece hanno aggiornato i propri giochi per usare l'architettura Intel, e guarda caso sono quelli che non fanno delle console il loro target principale di vendita, dimostrano che l'HW Intel non è il problema e non serve essere degli Einstein per fare in modo che il supporto evolva verso soluzioni diverse da quelle usate per oltre 30 anni.

Ottimizzazione è usare al meglio le risorse. Ci sono diversi livelli di ottimizzazione possibili.
Anche l'architettura HW può essere ottimizzata per sfruttare la meglio quello che ha a disposizione tipo i W e transistor. E non deve essere (e non è sempre stato) retro compatibile dal punto di vista della efficienza.
Quello che stai dicendo tu è che l'HW non deve migliorare/cambiare perché altrimenti il codice "vecchio" o quello creato da una scimmia con i tool automatici gira male e per ovviare a questo i programmatori devono usare più neuroni per fare in modo che il proprio SW giri al meglio sulle nuove soluzioni.

In verità chi programma ha ben a cuore che il proprio SW giri al meglio, soprattutto sulle architetture più diffuse, e infatti come detto i programmi di produttività sono aggiornati in tal senso. E vediamo nei benchmark come per questi programmi usare gli e-core non comporta un gran problema di prestazioni se sono in grado di sfruttarne il gran numero a disposizione.
Come lo è sempre stato l'adozione di un nuovo set di istruzioni (MMX, SSE, 3DNow, AVX e tutte le loro sotto varianti).
Anche il set di istruzioni x64 ha portato al dover ottimizzare meglio certo codice, o anche a renderlo incompatibile se non adeguatamente supportato dall'OS.

Chi ancora non ottimizza per le nuove architetture sono solo (alcuni) sviluppatori dei giochi perché hanno come target solo le console che sono 8 core SMT e quindi non gliene frega nulla definire quali siano i task low priority o taggarli per identificarne le caratteristiche e difficilmente usano più di 8 thread per evitare di dover gestire la concorrenza sui core logici delle CPU di questi baracchi.

Gli sviluppatori che invece hanno aggiornato i propri giochi per usare l'architettura Intel, e guarda caso sono quelli che non fanno delle console il loro target principale di vendita, dimostrano che l'HW Intel non è il problema e non serve essere degli Einstein per fare in modo che il supporto evolva verso soluzioni diverse da quelle usate per oltre 30 anni.

;)

Ottimizzazione è usare al meglio le risorse. Ci sono diversi livelli di ottimizzazione possibili.
Si possono fare ciò che vuoi ma resta il fatto che AMD non ha bisogno di righe di codice supplementari.
Gli sviluppatori come visto e rivisto non sono sempre così inclini all'ottimizzazione.

Ora aldilà che questa funzioni non so quanti giochi lo supporteranno e quanto tempo impiegheranno, alcuni non lo supporteranno, altri probabilmente ne introdurranno il supporto solo il seguito, in ogni caso è un handicap visto che non ha alcun pro.

Si esatto, solo che AMD non ha bisogno di righe di codice supplimentari.

vero ma ha anche meno core quindi alla fine in tanti contesti va meno delle cpu intel, la coperta è corta se tiri da una parte non lo puoi fare dall'altra ma questo non rende l'approccio intel inferiore è solo diverso e non è amd che deve fare il codice comunque ma chi sviluppa il software che gira sulle cpu.

Ogni tanto ?
Non si tratta di soli cali di frame rate ma di comparsa di stuttering.
Aldilà di ciò però è innegabile che richieda programmazione supplementare, c'è poco quindi da giustificare.


Sta porcheria quì va bene solo su mobile dove devi risparmiare batteria e nonostante ciò non fornisce vantaggi significativi.
Anche lato enterprise i prossimi chip saranno omogenei anche se formati unicamente da cores-E.

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.

Si esatto, solo che AMD non ha bisogno di righe di codice supplimentari.
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?

vero ma ha anche meno core quindi alla fine in tanti contesti va meno delle cpu intel, la coperta è corta se tiri da una parte non lo puoi fare dall'altra ma questo non rende l'approccio intel inferiore è solo diverso e non è amd che deve fare il codice comunque ma chi sviluppa il software che gira sulle cpu.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.

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.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".

E quindi? Anche quando Intel ha introdotto il Pentium-D era necessario del codice supplementare per usare i 2 core.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 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.

Per questo AMD sta recuperando quote di mercato ovunque in barba al numero di cores

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

no recupera quote di mercato perché fa più fps nei giochi che è la cosa più triste di tutta la diatriba

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. :cry: