[Thread Ufficiale] Aspettando ZEN

[paolo.oliva2]

Originariamente inviato da Pozhar

Ditemi quello che volete, ma io non ci darei troppo peso a questi ''bench''. nessuno può assicurarmi che in realtà il procio ce l'abbiano veramente. Ma può anche essere che in questi ultimi giorni stanno buttando giù dei confronti (senza avere in realtà la cpu) e poi creano quegli screen. Insomma, rifletteteci, a cosa stiamo dando valore? Al nulla e sia in un senso che nell'altro. Per me possono farmi vedere quello che vogliono, ma senza una metodologia di test certificata, che cacchio di valore possiamo darci a quella roba lì?

Questo come dicevo ammesso che chi posta quella roba abbia veramente la cpu e relativa mobo.

Per me sono dei bench fatti con un ES a suo tempo, bloccati da AMD.
Secondo me c'è caso che questa domenica AMD dia il via alla diffusione di qualcosa, bench o frequenze OC, a piacere.

Quello che le varie testate non possono fare, è valutare le prestazioni di Zen senza conoscere il funzionamento del turbo e dell'XFR, e per questo fanno delle valutazioni "matematiche", magari prendendo i valori dell'ES a 3,3GHz e facendo proiezioni a frequenze fisse. Però non sapendo quanto può incidere l'XFR, in St si potrebbe parlare pire di differenze del 5/10%.

Però c'è qualche cosa che non mi torna... ed è sempre sulle mobo AM4.
Va bene che BR non sia uscito perchè le mobo dovevano aspettare Zen ultimato... ma una volta che riporti Zen a marzo negli scaffali, che ci farebbe se mancassero le mobo? Quindi le mobo devono per forza uscire a giorni.
Poi a me non ha convinto il ritardo di Asus (evitare flame perchè su socket AM4 AMD).

[Pozhar]

@Paolo.

Concordo sulla questione mobo. Ok l'NDA e tutto, ma speriamo però che i produttori almeno una settimana prima dell'uscita delle cpu, mettano a listino i vari modelli. In modo tale che uno incomincia a spulciarsi le varie caratteristiche e specifiche. Almeno si inizia a scegliere la mobo e avere le idee più chiare sulla buid che si vuole assemblare.

[palia95]

Originariamente inviato da Roland74Fun

C'è anche il 1100!! Come quello che aveva mio suocero.....

A destra ci saranno le frequenze...

[robotx]

Originariamente inviato da Pozhar

@Paolo.

Concordo sulla questione mobo. Ok l'NDA e tutto, ma speriamo però che i produttori almeno una settimana prima dell'uscita delle cpu, mettano a listino i vari modelli. In modo tale che uno incomincia a spulciarsi le varie caratteristiche e specifiche. Almeno si inizia a scegliere la mobo e avere le idee più chiare sulla buid che si vuole assemblare.

Concordo sante parole:

[Roland74Fun]

Si ho capito NDA ma ormai sono in produzione. Ebbasta!!!
Questo é il momento di invadere giornali e riviste con bench di tutti i tipi, di produttività, bench di giochi, ecc.
Prove di forza,,prodotto messo in luce sotto i migliori aspetti.
É questo il momento del marketing.
In questo forum arriva gente a chiedere per un computer che non sa neppure che devono uscire processori AMD....
Aspettano a far vedere il processore al day TWO?
Incrociando le dita che la stampa specializzata dica che va benino?

[Amorph]

è noto il giorno della presentazione?

[Ryddyck]

Originariamente inviato da Bivvoz

adesso sono cazzi a capire cos'è il tdp sr3+ e il thermal group hs81

Chiedi e ti sarà dato

[palia95]

Originariamente inviato da Ryddyck

Chiedi e ti sarà dato

ma dove li trovi?
esci le frequenze

[Pozhar]

Roland74Fun

Infatti... Dico la verità: questo aspetto mi 'sta dando parecchio fastidio. Come già detto, ok se vuoi tenere ferrato l'NDA fino all'ultimo giorno o quasi, ma mi viene da pensare che AMD blocchi anche i produttori di mobo. Cioè lo fa su tutto quello che gli ruota attorno. Per chi sa di cosa parlo, giusto per fare un esempio sulla controparte Intel e nello specifico i Kaby Lake, i produttori di mobo, avevano messo sui rispettivi siti i vari modelli a listino con le caratteristiche e tutto già da parecchio tempo prima della presentazione e commercializzazione delle cpu.

E ripeto ok, tutto quello che volete... ma non voglio che mi si venga a dire che AMD non la si conosce bene ed ha fatto sempre così... perché c'è sempre una prima volta per fare una cosa nuova e soprattutto per cambiare. E specie in questo particolare e delicato periodo, personalmente lo trovo ingiustificato (per non dire altro) un simile comportamento.

[von Clausewitz]

non so se è stato già postato

[Hadar]

Originariamente inviato da von Clausewitz

non so se è stato già postato

Più o meno ma spiegata in modo differente, questo schemino è più immediato. Grazie :o

[von Clausewitz]

Originariamente inviato da Hadar

Più o meno ma spiegata in modo differente, questo schemino è più immediato. Grazie :o

prego

adesso nessuno potrà dirmi che non ho dato un contributo alla discussione se non battibeccare con paolo oliva

cmq schede madri boh
bench significativi idem
da un paio di mesi come già detto aspetto sto benedetto cinebench per un parametro di valutazione un po' più significativo del poco e in condizioni fumose mostrato sinora

[bjt2]

Comunque di la su anand, oltre a riportare questi screen dei dissipatori, un tizio ha dimostrato che il test Physics e quello database sono molto dipendenti dalla latenza della memoria. Con quei CAS è normale che vada piano (ha testato lui rallentando le sue memorie). Magari è stato fatto anche apposta...
Zen è comunque superiore su alcuni test...

Per la questione dissipatori: di la suppongono che le CPU X abbiano XFR attivato e che richiedano un dissipatore di qualità superiore altrimenti XFR non entra in funzione...

[paolo.oliva2]

Originariamente inviato da von Clausewitz

non so se è stato già postato

Perfetto.

Vorrei far notare una cosa, ultimo codice OPC

8 = 4MB L2 + 16MB L3 (ed ovviamente X8 con 2 CCX)
K = 2MB L2 + 8MB L3 (ed ovviamente X4 con 1 CCX)
H =16MB L2 + 64MB L3 (ed ovviamente X32 con 4 CCX)

Sembra che come proci X86 debbano avere la L3, forse quelli senza L3 faranno parte di altro.

Originariamente inviato da Ryddyck

Chiedi e ti sarà dato

O c'è un errore, o c'è qualcosa che non capisco.
Come fa un procio 65W TDP avere un Tcase max 71,3° e quelli a 95W TDP 72,4° e 59,9°?

Tcase max che è? Max temp package?

In teoria io vedrei 1700 65W e 59,9°, 1700X 95W 71,3° e 1800X 95W e 72,4°.

Tanto l'XFR dovrebbe parametrizzarsi sul Tcase max.
Mi viene da supporre che il 1700 abbia l'XFR solamente su 4 core (tanto per prezzo deve competere con un 7700K) e magari la selezione "prende" i die in cui 1 CCX va bene (XFR X4) e l'altro meno.

Il 1700X potrebbe avere un XFR limitato su 8 core, e il 1800X l'XFR più prestante sia come X4 che come X8. Costa quasi il doppio del 1700... una selezione buona la dovrà pur avere.

[cdimauro]

Avevo qualcosa arretrata, che recupero adesso.

Originariamente inviato da fabius21

Citando opencl , mi hai fatto ricordare di un articolo letto da qualche parte che affrontava le problematiche relative all'evoluzione di questa isa, non essendoci cooperazione in tal senso , e giudicandola da programmatore , faceva notare il comportamento "corretto" di intel, implentando la stessa funzione con qualche differenza a livello di registri, lunghezza et simil cose, e gli complicava la vita sta cosa, e spiegava anche che la motivazione per la quale amd creo le xop e non implementò la soluzione della controparte , solo perchè intel alla richiesta da parte di amd di poter aver assegnato un range di byte per evoluzioni future , la risposta che ha ricevuto è stata percui ha optato per crearsi le sue xop, l'unica cosa che non ha potuto ricreare per "rompere le balle" (siam schietti U.u ) son state le x86-64
Speriamo che l'accordo sulle gpu , cambi qualcosa sulla cooperazione anche riguardo il futuro dell'isa

La storia è un po' diversa, e credo che l'articolo a cui ti riferissi fosse questo: Stop the instruction set war

Da cui estraggo una parte che parla dell'introduzione delle SSE5 e dell'opcode XOP da loro usato:

"The next important battle is going on right now. It's about instructions with more than two operands. The industry has recognized a need for fused multiply-and-add instructions (e.g.: D=A*B+C) and several other instructions with more than two operands. The current coding scheme supports only instructions with two operands, so a new coding scheme has to be invented in order to support instructions with more than two operands. AMD came first with a proposal. In August 2007, AMD announced a future instruction set called SSE5 with a new coding scheme. The early disclosure of AMD's intentions was a break with the previous policy where both companies had kept their intentions secret as long as possible. Intel's reply came in April 2008 with an early (probably premature) disclosure of their planned AVX instruction set. Intel's AVX coding scheme was much more flexible and future-oriented than AMD's SSE5 scheme, as I argued in a public discussion forum. Most importantly, the AVX scheme has room for future extensions of the size of the SIMD vector registers, while the SSE5 scheme has little room for any future extensions. It was pretty obvious that Intel had won this time, and thanks to the early disclosure of Intel's AVX instructions, it was not too late for AMD to change their plans. In May 2009, AMD published a revision of their plans where they modified the coding scheme for better compatibility with AVX. In addition to a full support of AVX, the revised AMD plan contains most of the original SSE5 instructions under the new name XOP and with the new coding scheme. Unfortunately, Intel had changed their plans in the meantime! In December 2008, Intel published a revision of their plans which involved a change of the coding of the fused multiply-and-add (FMA) instructions. Now it was too late for AMD to change their design once more, so the first AMD processors with FMA will follow the premature Intel specification rather than Intel's later revision. It is difficult to obtain compatibility when you are following a moving target.
[...]
It gets worse when we look at the code space defined by the VEX coding scheme. This scheme has room for 216 = 65536 instructions, so there is plenty of room for future instructions without adding extra prefix or suffix bytes. Yet, AMD has not used any of this code space for their new XOP instruction set. Instead, they have made another coding scheme which is very similar to the VEX scheme, but beginning with the byte 8F, where the VEX code begins with C4 or C5. We can only speculate whether the AMD engineers have asked Intel for permission to use part of the huge VEX space and got a no, or whether they have given up beforehand. All we know is that there are disadvantages to using a different coding scheme.

The bytes that follow after C4 or C5 in the VEX scheme are coded in a special ingenious way in order to avoid clashing with existing instructions. It is not possible to use exactly the same method with the XOP scheme beginning with 8F, hence there are small differences between the XOP scheme and the VEX scheme. It would have been possible to make the two schemes identical if AMD had used the initial byte 62 instead of 8F for the XOP scheme, but perhaps Intel have reserved the 62 code for future use. Arguably, it would be possible to use the codes D4 and D5 as well, though with some extra complications.

The small differences between Intel's VEX scheme and AMD's XOP scheme adds an extra complication to the instruction decoder in the CPU. This reduces the likelihood that Intel will copy any of the XOP instructions. If it turns out that some of AMD's XOP instructions are so useful that the software industry will ask Intel to copy them, then we may fear that Intel will choose a VEX encoding for these instructions rather than making their code compatible with AMD's."

In sintesi (ma consiglio di leggere tutto il pezzo, perché è molto interessante):
- AMD è stata la prima a tirare fuori una nuova ISA SIMD, con le cosiddette SSE5;
- non ha chiesto niente a Intel, e motu proprio ha utilizzato l'opcode 8F allo scopo;
- Intel ha risposto con AVX, che era una codifica oggettivamente migliore, e con parecchio spazio per future estensioni;
- anche Intel non ha (ovviamente, e come avviene al solito per qualunque produttore di processori x86. Vedi il pezzo che fa anche una cronistoria in merito) chiesto nulla ad AMD, e ha utilizzato due opcode completamente diversi, C3 e C4;
- a seguito di ciò AMD ha adottato AVX, e relegato parte delle sue estensioni SSE5 all'opcode XOP;
- ci sono soltanto speculazioni sul fatto che AMD possa aver chiedesto a Intel spazio nelle AVX per le sue SSE5, ricevendo un eventuale diniego;
- Intel ha poi cambiato la codifica per le FMA, e AMD s'è ritrovata fregata con queste estensioni già implementate per Bulldozer.

Dunque, come puoi vedere, sia Intel sia AMD hanno lavorato indipendentemente per le loro nuove unità SIMD, e usato opcode diversi (C3 e C4 per AVX, 8F per XOP) per le loro estensioni, che sono rimasti tali anche a prodotti finiti. Quindi dal punto di vista dell'estensione dell'ISA, non si sono pestati i piedi a vicenda: ognuno, tacitamente, utilizza gli opcode che s'è scelto.

Infine, è bene rimarcare che è da quando è nata IA-32 AKA x86 che i produttori di CPU hanno aggiunto le loro estensioni senza chiedere permesso a nessuno, visto che non c'è un ente allo scopo, e ognuno fa di testa propria, come si può vedere sempre dall'articolo di cui sopra. E non credo che le cose cambieranno.

Quindi il programmatore che t'ha rivelato quelle cose, mi sa che avesse le idee un po' confuse, su come fossero andati realmente i fatti.

Originariamente inviato da Bivvoz

Insomma Intel come Microsoft anni 90: EEE

Vedi sopra: assolutamente no.

E poi non ci sarebbero nemmeno i presupposti: con IA-32/x86 non c'è un comitato che definisce uno standard. Ci sono i produttori di processori che hanno fatto e fanno quello che vogliono.

A parte il fatto che IA-32 è... roba di Intel: sarebbe paradossale che proprio lei debba chiedere a qualcuno come estendere la sua ISA.

Ma secondo me hanno poco da fare i furbetti perchè da quel poco che ho capito HSA nel mobile ARM funziona bene e parecchi produttori di soc che fanno parte del consorzio ci stanno lavorando.

Ce ne sono alcuni importanti che non fanno parte del consorzio, e non sono interessati a supportarlo. E siccome si tratta di Intel e nVidia, dubito che possa cambiare qualcosa per il futuro: senza il loro supporto, almeno su PC, HSA difficilmente prenderà piede. Tant'è che, anche nello stesso consorzio, praticamente è AMD che si porta avanti, mentre dagli altri non noto segnali per spingere consistentemente HSA.

Che poi, con OpenCL che è uno standard, non vedo perché si dovrebbe supportare anche HSA.

Originariamente inviato da Roland74Fun

Ma cdmauro non si è più sentito? Dov'è finito?

Originariamente inviato da sgrinfia

Lo hanno visto in Viale Milanofiori , 4 20090 ASSAGO (MI) a verniciare le facciate

All'epoca ero impegnato per sbrigare ciò che serve per prendere la macchina aziendale (temporanea; a fine periodo di prova ne chiederò una personalizzata): BMW 330i M-Sport Touring (stesso colore e un po' di optional in comune con quella della recensione, tra l'altro).

Originariamente inviato da VanCleef

Intel Corporation Italia (S.P.A.)...
Ma è alla BMW ora...

Esatto.

[cdimauro]

Originariamente inviato da AkiraFudo

forse è il mio italiano ad essere poco comprensibile...permettimi di riprovarci...
[...]
E' l'utente xage che ho quotato, ad affermare che intel si è seduta sugli allori dando la colpa ad AMD. (non l'ho detto io)

Ho detto "SE" (ipotetico) Intel si è seduta sugli allori è forse più colpa di Intel che di AMD.

Ho scritto chiaramente che è una sua congettura. Io personalmente non sono d'accordo sul fatto che Intel si sia seduta sugli allori.

Purtroppo non aver colto il sarcasmo mi ha mandato fuori strada.

Dunque ciò che t'avevo scritto lo rigiro pari pari all'utente xage, e mi scuso per la cantonata presa nei tuoi confronti.

Per archittettura innovativa si intende in questo caso = Architettura che riesca a rendere soddisfatto l'utente Xage, cosa dove ha fallito sia Ryzen che Intel.

OK. Son problemi suoi, allora: se non gli piace può costruirsela da solo la (micro)architettura dei suoi sogni.

Originariamente inviato da bjt2

Infatti io ho detto che LUI afferma... Invece lui CREDE. Ok, ho sbagliato il verbo.

Penso che si sia fatto confondere dall'aura negativa del processo 14nm. Tutti dicevano che essendo low power, non avrebbe consentito clock alti, così si è tenuto conservativo. Troppo IMHO. Io ad esempio non ho avuto paura di dire fin dall'inizio il mio pensiero.
Ma se il FO4 è simile a XV e il processo è migliore, (leggi: più veloce), allora 3.2 non è una stima corretta... Quindi o è incoerente, o pensava che il processo GF facesse schifo e fosse solo più denso o comunque buono solo ai bassi clock...

Premesso che a questo punto del FO4 continuiamo a non avere informazioni definitive (inclusa la similitudine con XV), può anche darsi che abbia tenuto conto pure dei guadagni tutto sommato modesti che Intel ha avuto sia dal FinFET sia dalla miniaturizzazione, come ti ho riportato minuziosamente in un altro commento qualche giorno fa. E siccome GF è rinomata per avere problemi, magari Kanter avrà fatto una stima cautelativa, come dici tu.

Son tutte speculazioni alla fine. E questo è il thread giusto.

Comunque aggiungo una considerazione alla fine.

Non è questioni di voci. I calcoli sulle dichiarazioni si possono fare. Poi c'è la slide dove io ho notato il Vcore di 0.9 e basandomi sulle slide ufficiali di GF e sul clock di un vecchio XV ho provato a IPOTIZZARE il clock e il consumo di Zen (trovi i miei post completi su anand). Poi i valori mostrati da AMD sono quelli strettamente necessari ad eguagliare il 6900K in 2 bench selezionati. Al tempo non sapevamo se Zen potesse andare di più e ancora non ne siamo sicuri. Ma abbiamo una idea dell'IPC ed abbiamo una descrizione dell'XFR che in pratica è un AVFS 3.0, di cui ci sono PDF su ieeexplore che io ho letto ed analizzato, ma sono a pagamento e non credo che il contratto del CNR mi consenta di renderli pubblici. Ma ti posso assicurare che funziona così da Carrizo. E su Zen ipotizzo che abbiano eliminato i limiti di clock.
Da quella slide dove si vede il famoso 0.9v si capisce che la SMU decide il clock per i core (presumibilmente stesso clock) e poi in base alle statistiche, la temperatura, il carico, la SMU decide il Vcore ideale per ogni core... Mi pare una idea geniale...

Tutto questo mi da molta fiducia sul fatto che con l'XFR si possa salire parecchio e in automatico.

Sarebbe un vero peccato se le voci che vogliono l'XFR solo sui modelli X fosse vera...

Un attimo. Non volevo dire / arrivare a questo.

Semplicemente volevo far notare che da tutte le premesse / speculazioni / calcoli / etc. che porta(va)no a frequenze abbastanza elevata, SE le voci che sui modelli che circolano adesso dovessero risultare vere (come sai, sono e rimango scettico ), allora c'è qualcosa che non quadra in termini di FO4, tecnologie di risparmio energetico, ecc. ecc., visto che i risultati sono ben sotto le aspettative.

E riallacciandomi nuovamente al FO4, a questo punto ho non pochi dubbi sul tener conto di questa variabile nel calcolo della frequenza raggiungibile di un processore.

Mi spiego meglio. tuttodigitale, se non ricordo male, ha riportato il FO4 di alcun processori x86. Sarebbe interessante vedere quali frequenze massime hanno raggiunto i top di gamma di questi processori, a parità di consumi e/o (se possibile) processo produttivo. Il tutto ovviamente tenendo fisso un importante parametro, cioè il numero di core. Quindi roba tipo: prendiamo i quad core desktop top di gamma a consumi simili, e vediamo quale frequenza hanno raggiunto con l'FO4 stimato, per vedere se effettivamente quest'ultimo fattore comporta dei vantaggi reali (e in che misura) in quelli che saranno poi i prodotti commercializzati.

Originariamente inviato da bjt2

Su handbrake non possiamo sapere il clock, e quindi calcolare l'IPC, ma comunque c'è un vantaggio dell'8% di Ryzen...

Ma interessava l'IPC nello specifico. Handbrake, purtroppo, non aggiunge nulla di utile.

Originariamente inviato da Piedone1113

Se non ricordo male il consumo medio ponderato (quindi tolti gli estremi inf e sup) di un 6900 è 104W (non è che sia tanto diverso da 95w, ma per correttezza lo riporto).

Sarebbe più utile capire il consumo medio del processore in maniera del tutto separata: solo con applicazioni che usano le AVX e solo con quelle che non lo usano. In modo capire come si comporta nei due diversi scenari, e in particolare nel secondo sarebbe confrontabile direttamente con Zen, visto che in questi casi si fa uso (al massimo) soltanto di porte a 128 bit.

Per quanto riguarda il sysmark c'è da precisare che si utilizzano alcune routine di programmi di uso comune, ma scegliendo test con programmi differenti di uso comune (pe calc invece di excel o blender invece di maya, software a caso con i secondi forse nemmeno compresi) potremmo ritrovarci uncon un AMDmark che capovolge i risultati (se non sbaglio si usano anche alcuni filtri specifici di photoshop nel sysmark)
Quello che voglio dire è che se io uso freemake per una conversione su amd impiegando 30 min (35 su intel) per essa e tu nel tuo test usi FormatFactory che con amd fa 40 min (29 su intel) i risultati possono cambiare senza mostrare le reali prestazioni medie delle cpu (ma solo in un ristretto num di software).

Senz'altro, ma SYSMark rimane un benchmark non sintetico: niente a che vedere con roba come Passmark, Geekbench, ecc. e personalmente ci metterei pure SuperPI.

Per il resto i bench danno sempre risultati sintetici (sintetizzano in un numero il risultato di alcune azioni) e possono dare un'idea approssimata delle prestazioni in alcuni ambiti (vorrei vedere i risultati di un sysmark di 5 anni fa sulle attuali cpu se rimangono invariate le differenze relative tra le cpu, per dire)

Vero, ma è normale / ovvio: se vuoi un solo numeretto alla fine, hai necessità di sintetizzare i risultati, usando una media pesata per ogni sotto-benchmark.

Ma un conto è partire da risultati che sono loro stessi sintetici, e tutt'altra cosa partire da risultati (di applicazioni) reali.

Originariamente inviato da Grizlod®

Oppure...Intel non permette di implementarle 'paro-paro'... chi si metterebbe a programmare per AMD (senza compenso).

No, ormai da anni c'è un accordo di libero cross-licensing fra Intel e AMD.

Originariamente inviato da Pozhar

Ditemi quello che volete, ma io non ci darei troppo peso a questi ''bench''. nessuno può assicurarmi che in realtà il procio ce l'abbiano veramente. Ma può anche essere che in questi ultimi giorni stanno buttando giù dei confronti (senza avere in realtà la cpu) e poi creano quegli screen. Insomma, rifletteteci, a cosa stiamo dando valore? Al nulla e sia in un senso che nell'altro. Per me possono farmi vedere quello che vogliono, ma senza una metodologia di test certificata, che cacchio di valore possiamo darci a quella roba lì?

Questo come dicevo ammesso che chi posta quella roba abbia veramente la cpu e relativa mobo.

Considerato che si tratta di benchmark sintetici, io non capisco perché la ggggente dovrebbe essere interessata a questi risultati, e a perderci del tempo per discuterne.

Ciò che conta sono le applicazioni reali. E basta.

Originariamente inviato da paolo.oliva2

Per me sono dei bench fatti con un ES a suo tempo, bloccati da AMD.

No. L'ID della CPU mostrato è chiaramente di un prodotto finale e non di un ES. Basti vedere il diagramma riportato da von Clausewitz, e confrontarci le sigle riportate dai benchmark.

Quello che le varie testate non possono fare, è valutare le prestazioni di Zen senza conoscere il funzionamento del turbo e dell'XFR, e per questo fanno delle valutazioni "matematiche", magari prendendo i valori dell'ES a 3,3GHz e facendo proiezioni a frequenze fisse. Però non sapendo quanto può incidere l'XFR, in St si potrebbe parlare pire di differenze del 5/10%.

No anche qui. Turbo e XFR, se attivi, funzionano in maniera indipendente dall'applicazione. E non c'è motivo di ritenere che fossero disattivati, visto che normalmente / a default queste tecnologie sono attive, per l'appunto.

A meno che, come ho già detto in precedenza, non sia stato l'utente a disattivarle appositamente.

Però c'è qualche cosa che non mi torna... ed è sempre sulle mobo AM4.
Va bene che BR non sia uscito perchè le mobo dovevano aspettare Zen ultimato... ma una volta che riporti Zen a marzo negli scaffali, che ci farebbe se mancassero le mobo? Quindi le mobo devono per forza uscire a giorni.
Poi a me non ha convinto il ritardo di Asus (evitare flame perchè su socket AM4 AMD).

Infatti. Il dubbio è più che legittimo. Le schede madri DEVONO uscire ben prima della commercializzazione dei processori.

[street]

Originariamente inviato da paolo.oliva2

Perfetto.

Vorrei far notare una cosa, ultimo codice OPC

8 = 4MB L2 + 16MB L3 (ed ovviamente X8 con 2 CCX)
K = 2MB L2 + 8MB L3 (ed ovviamente X4 con 1 CCX)
H =16MB L2 + 64MB L3 (ed ovviamente X32 con 4 CCX)

Sembra che come proci X86 debbano avere la L3, forse quelli senza L3 faranno parte di altro.



O c'è un errore, o c'è qualcosa che non capisco.
Come fa un procio 65W TDP avere un Tcase max 71,3° e quelli a 95W TDP 72,4° e 59,9°?

Tcase max che è? Max temp package?

In teoria io vedrei 1700 65W e 59,9°, 1700X 95W 71,3° e 1800X 95W e 72,4°.

Tanto l'XFR dovrebbe parametrizzarsi sul Tcase max.
Mi viene da supporre che il 1700 abbia l'XFR solamente su 4 core (tanto per prezzo deve competere con un 7700K) e magari la selezione "prende" i die in cui 1 CCX va bene (XFR X4) e l'altro meno.

Il 1700X potrebbe avere un XFR limitato su 8 core, e il 1800X l'XFR più prestante sia come X4 che come X8. Costa quasi il doppio del 1700... una selezione buona la dovrà pur avere.

L'heathsink class 3 sarà più performante, magari a liquido (su un 6300 é piu o meno la temperatura che ho con h100i)

[Neverlost]

https://videocardz.com/65825/first-a...marks-are-here

[paolo.oliva2]

Originariamente inviato da Bivvoz

Quindi c'è una buona probabilità che avessi ragione io.
Tra X e pro cambia il Tcase e le frequenze saranno simili, anzi c'è possibilità che gli X abbiano frequenza di base più bassa e siano CPU per server e workstation.
I modelli più perforanti potrebbero essere i PRO e non gli X.

Però il 1800X ha socket AM4 ed è quello che costa di più....

Comunque non capisco perchè mettere lo stesso OPN su proci mobile/desktop/server... sembrerebbe che mettano l'OPN a livello di die e successivamente sul package... però mi devono spiegare quando fanno l'X32... ha 4 OPN?

[JosèGarciaBolivar]

Ragazzi io non capisco tutto questo casino che fate.
Circa 5% da Broadwell E, +43% IPC, costano il giusto. tutto in linea, tutto apposto.
Sempre casini sempre polemiche mi fate bestemmiare poi mi bannano