[Thread Ufficiale] Aspettando ZEN

[Roland74Fun]

Originariamente inviato da Piedone1113

Il nuovo turbo AMD avrà un minimo garantito, ma la gestione può alzare le frequenze anche sopra il minimo ( come con le gpu nvidia) e possiamo trovarci con differenze di frequenze turbo sulla stessa serie di CPU ( un sr 7 be che busta a 4250 ed un altro che Boost a4300 contro i 4200 nominali)

Come nei thread delle schede video, vedo già la gente che farà il reso della CPU perchè quella del vicino di casa boosta 20 MHz in più...
C'èra uno che voleva fare RMA della 480 perchè GPU-Z mostrava un asics non elevatissimo....

[Pozhar]

Ormai è la moda e ben presto la pacchia finirà. ne sono convinto. E' che in quel caso, mi spiace che ci vanno di mezzo le persone perbene. quando avremo reale necessità, perché il pezzo è davvero difettoso, e magari ci ritroviamo con delle restrizioni applicate che comportano delle politiche più dure in caso di resi, rma etc...

ed è un peccato. come sempre manca il buonsenso. non per ultimo visto che parliamo di questo, ci son gente che dal solito shop, fanno resi degli smartphone poco prima che gli scade la garanzia e si fanno restituire indietro la somma e così si comprano un altro cell nuovo.

[digieffe]

Originariamente inviato da cdimauro

Sì. Ma anche di 64KB per cache codice e altrettanti per i dati.

infatti avevo il sospetto che la versione server avesse la necessità di una cache L1D più grande.

Il compilatore sarà pure intelligente, ma poi il decoder del processore ne decodifica al massimo 4 di istruzioni, e non 8.

Inoltre è la logica dello scheduler che si occupa di riorganizzare le uop (nemmeno istruzioni) opportunamente, per cui se intelligenza ci dev'essere nel processo di selezione delle istruzioni, è meglio che stia qui.

P.S. Sui compilatori intelligenti Intel e HP (= Itanium, detto anche Itanic -> Titanic), e mettiamoci in mezzo pure Transmeta, avevano puntato. La storia, però, gli ha dato sonoramente torto.

è stato un fallimento tecnico o commerciale?

Già. C'è pure questo, visto che il blocco "intero" e quello FPU sono separati.

Non credo fosse questo a cui si riferisse digieffe. Esistono singole istruzioni che operano contemporaneamente su registri GPR e dell'FPU.

E non pensare che siano roba esotica e poco comune: sono comodi per fare, ad esempio, velocemente una conversione di un valore intero, da GPR a SIMD o viceversa; oppure per controllare se un vettore sia tutto a zero settando l'apposito flag in R/D/FLAG.

In questi casi immagino che Zen debba suddividere quest'istruzione in due: una da spedire all'unità che funge da sorgente, e un'altra a quella che fa destinazione. Ovviamente schedulandole opportunamente.

fino a bd incluso, ho cercato in asm di trarre vantaggio dall'utilizzo dei registri GPR contemporaneamente agli xmm, ma questo veniva quasi sempre vanificato dalle latenze. L'unico modo che ho individuato per limitare le perdite è stato quello di utilizzare GPR e xmm per "thread" (no thread di OS, ma solo un mix di istruzioni interni al mio codice) separati.
Poi sarà stato un mio limite, possibile che qualcuno abbia trovato un modo migliore di sfruttare la combinazione di registri.

Comunque anche in kernel space si può usare l'FPU e/o l'unità SIMD. E lo si fa, se proprio serve. Però è un casino.

per la precisione lo fanno le routine per il calcolo delle parità raid, eventualmente se non si hanno istruzioni specifiche hashing e cifratura, ...

Con due soli test pubblicati, nemmeno replicabili, nonché accuratamente selezionati?

sinceramente non credo possano farla troppo sporca

Ma Zen su Cinebench non andava il doppio dell'8350, secondo una slide di AMD?

in base a quel po' che si è visto/potuto capire (zen >> 2x vs 8350) il doppio in CB ci dovrebbe essere, seppur questo sarà inferiore al 6900k.

E ora, a nanna. Buona notte a tutti.

notte anche a te

[paolo.oliva2]

Originariamente inviato da Pozhar

E' come un cane che si morde la coda. Sono rumor e basta e in quanto rumor non rispecchiano la realtà. aggiungici poi i vari teoremi su azioni, bolla speculativa etc...e ti rendi conto che stiamo punto e a capo e parliamo del nulla.

Oddio, proprio un rumor non direi, nel senso che come analista riporta nome e cognome, quindi se sbaglia, la faccia ce la perde, mentre un rumor è una cosa a parte, perchè riporti una voce, se vera o falsa o addirittura l'hai creata, non cambia nulla sulla credibilità della persona.

Il problema non è l'opinione che ha una persona, il problema è quando sulle stesse argomentazioni l'opinione della persona cambia a piacere.
Se per esempio hai seguito l'anteprima del 7700K, io non commento le aspettative e quant'altro, però mi urtano le opinioni che bisognava aspettare per avere un quadro più preciso perchè quell'esemplare poteva essere un ES (e non lo era), poteva essere sfigato (ma tutte le rece che hanno testato quel procio, avendo fatto l'articolo nei medesimi tempi, ovviamente avevano proci diversi, ma non è cambiato una virgola), e poi parli di un ES (e veramente ES) di Zen, e di colpo qui non ci sono santi, quello è un procio finito e quindi non cambierà una virgola quando si avrà la versione commerciale.
Questo è fanboismo o no?

[paolo.oliva2]

Originariamente inviato da Piedone1113

Paolo mi sa che non hai idea di come vengono selezionate le CPU.
Prendiamo l'8 core:
Se primo test:
Funzionamento elettrico di tutti i transistor.
Pass
8 core top di gamma frequenza max turbo singolo core 4 Ghz
Pass
Frequenza max alla core 4.6 Ghz
Pass.
Scrittura firmware ( e l'attrezzatura non legge la CPU per riconoscerla, il suo compito è quello di controllare il funzionamento dei transistor e non di adottare ottimizzazioni specifiche esterne ai path di funzionamento altrimenti non esisterebbero gli errata postuscita )
Se non passa il primo test si declassamento a 6 o 4 core.
Se non passa il secondo o terzo test si declassa la categoria.
Se non vengono mantenute le frequenze minime della categoria più bassa si declassa a 6 o 4 core .
Il nuovo turbo AMD avrà un minimo garantito, ma la gestione può alzare le frequenze anche sopra il minimo ( come con le gpu nvidia) e possiamo trovarci con differenze di frequenze turbo sulla stessa serie di CPU ( un sr 7 be che busta a 4250 ed un altro che Boost a4300 contro i 4200 nominali).
Nulla impedisce ad AMD di scrivere il firmware in un secondo momento ( e probabilmente la macchina di testing è diversa da quella di flash perché se per testare la CPU servono 2 ore e per il flash 2 minuti bastano pochi programmatori per flashare le CPU validate da molte macchine (e solo dopo verrà inviata al package, non avrebbe senso spendere soldi per il packing e l'his su un chip non funzionante).
Almeno credo sia così

Ma la macchina di test non può fare anche il flash? Era questo che intendevo.
Cioè, non ti metti a fare il test e poi parcheggi il procio per rifare nella stessa macchina il flash del filmware una volta che l'hai perfezionato... come sarebbe improbabile tenere i proci già prodotti in magazzino per aspettare il filmware per poi iniziare la trafila di test e flash.

Io interpretavo che il flash si faceva assieme al test semplicemente perchè una volta che hai fatto la selezione, sai già che tipo di flash impostare, anche perchè la dicitura del modello (tipo riportata da CPU-Z, il molti def, Vcore e quant'altro, sono comunque dipendenti dalla selezione e risultato precedente.

P.S.
Cacchio, siamo nell'era dell'automazione, la macchina per il test dovrebbe essere complessa mentre la macchina per il flash altro non sarebbe che tipo un programmatore di Eprom. Non mi sembra ottimizzato prendere il procio, toglierlo dalla macchina di test, metterlo in dei contenitori per poi riprenderlo e rimetterlo in un'altra macchina per fare il flash. Oltretutto, a parte il tempo, l'intervento dell'uomo può generare errore, perchè quando fai il test poi dovrai mettere il procio in almeno 7 parti distinte, a seconda se X8, X6 e X4, e i vari tagli di frequenza, quindi potrebbe capitare di mettere un X8 magari dove ci sono gli X4 e viceversa. Invece se fai tutto nella stessa macchina, e la stessa macchina sceglie il filmware da installare in base al risultato del test, l'errore non può esistere e si risparmia tempo.

[paolo.oliva2]

@Piedone1113.
Domanda...

Io sinceramente vedo che AMD è restia a comunicare le frequenze massime, ma non vedo un riscontro di tempo, nel senso che oramai per mantenere il 1° trimestre 2017 i proci se non sono già in produzione lo dovrebbero essere a breve.

Ora... o AMD non vuole diffondere la frequenza massima di Zen, o ancora non può conoscere quella finale (ma oramai i tempi sono stretti, quindi (per me) la dovrebbe conoscere).

La frequenza massima Turbo su pochi core non è assolutamente importante per l'X8, ma è VITALE in ottica Zen vs i7 X4. E' ovvio che un Zen X4+4 a 4GHz massimo non impensierisce Intel, diverso invece a 4,5GHz o addirittura di più. Notare che Intel non ha skylake-X a breve, ma potrebbe buttare in commercio i 7XXX X4 per anticipare Zen X4, come potrebbe essere che AMD non comunichi il turbo per far passare il periodo natalizio e poi dire che è max 4GHz. Insomma, è ingarbugliata la cosa... ma io sarei sicuro al 99% che AMD sa già tutto.

[Ubro92]

Originariamente inviato da paolo.oliva2

@Piedone1113.
Domanda...

Io sinceramente vedo che AMD è restia a comunicare le frequenze massime, ma non vedo un riscontro di tempo, nel senso che oramai per mantenere il 1° trimestre 2017 i proci se non sono già in produzione lo dovrebbero essere a breve.

Ora... o AMD non vuole diffondere la frequenza massima di Zen, o ancora non può conoscere quella finale (ma oramai i tempi sono stretti, quindi (per me) la dovrebbe conoscere).

La frequenza massima Turbo su pochi core non è assolutamente importante per l'X8, ma è VITALE in ottica Zen vs i7 X4. E' ovvio che un Zen X4+4 a 4GHz massimo non impensierisce Intel, diverso invece a 4,5GHz o addirittura di più. Notare che Intel non ha skylake-X a breve, ma potrebbe buttare in commercio i 7XXX X4 per anticipare Zen X4, come potrebbe essere che AMD non comunichi il turbo per far passare il periodo natalizio e poi dire che è max 4GHz. Insomma, è ingarbugliata la cosa... ma io sarei sicuro al 99% che AMD sa già tutto.

Io sono convinto che la scarsità di informazione serve solo per mantenere alto l'interesse e quindi per ragioni marketing se rilasciasse troppe info si perderebbe l'effetto "WoW" alla prima review dei sample commerciali, alla fine si tratta di attendere un mesetto e si saprà vita, morte e miracoli di queste cpu

[cdimauro]

Originariamente inviato da paolo.oliva2

Io continuo a non capire perchè tutto sto pessimismo su Zen in questo TH.

No, quello che non capisci è un'altra cosa.

Non è possibile che qui uno non si possa permettere di riportare la propria un'opinione senza che non venga messa in atto una sceneggiata napoletana (che peraltro apprezzo, eh! 'o zappatore forever! Ma non ogni santo giorno!!!) strappalacrime, condita da vittimismo spicciolo, da quelli che non la trovano allineata alla propria idea.

Questo a meno che, come già detto, non siate azionisti di AMD, o loro dipendenti. E finora mi sembra che l'unico titolato a fare (e che fa ampiamente) la continua e spassionata difesa a oltranza di quest'azienda sia Crysis90.

Ma, in mancanza di ciò, è così difficile pensare che siamo in un forum di discussione, e che sulla base delle informazioni che man mano arrivano sull'argomento, se tu dici la tua io dico la mia? ASETTICAMENTE intendo.

Se non ti piace quello che uno scrive, puoi benissimo replicare riportando la tua opinione. E ci mancherebbe che non sia così, ovviamente! Ma "semplicemente" senza condire continuamente il tutto da questo fastidioso vittimismo.

Perché, veramente, non ha assolutamente alcun senso questo comportamento che tu e altri qui tenete.

No, perchè quello che si dice qua, almeno da una parte, è l'esatto opposto di quello che si legge nel web.

Quando il webbbbe assurgerà al ruolo di dispensatore di patente di verità, ce ne faremo una ragione.

Nel frattempo io continuo a leggere, valutare, e a esprimere il mio parere, argomentando, sui dati disponibili a tutti, visto che non sono l'ultima ruota del carro soltanto perché non scrivo in qualche portale tecnologico.

Peraltro se proprio vuoi ricorrere ai titoli nobiliari, ho avuto per un bel po' di anni una rubrica settimanale squisitamente tecnica proprio qui su hwupgrade, in una delle sue "costole": Appunti Digitali.

Quindi dovrei avercelo abbastanza lungo per i tuoi gusti: 'o webbbe rullezz.

Originariamente inviato da gridracedriver

perché è la verità, non lo dovrei scrivere perché da fastidio a te?
è un bench che ha troppo valore sui forum,

Ce l'ha perché è Cinema4D è un'applicazione molto usata a livello professionale. Altrimenti Cinebench non lo prenderebbe in considerazione nessuno.

anch'io l'ho sempre preso come riferimento ma pare che ci si basi sull'IPC di un architettura solo in base a cinebench! follia pura...

Potresti riportare chi è che lo farebbe?

l'IPC è una fottuta MEDIA, non dice "l'IPC è aumentato in base a cinebench"...

L'IPC però si calcola sulla base di una precisa applicazione: è la media delle sue istruzioni, per ciclo di clock. E rimane ovviamente a essa legata.

Ma, come giustamente riporti, quando si parla di IPC lo si fa tenendo conto di diverse applicazioni.

Mentre qui mi pare che tanta gente abbia deciso di prendere i risultati di Blender e Handbrake come unici parametri per valutare la bontà di Zen. Peraltro tutte e due fortemente MT...

Originariamente inviato da Ryddyck

http://www.ftc.gov/os/adjpro/d9341/091216intelcmpt.pdf

Ma non è Intel che ha obbligato a usare i suoi compilatori. Questo dev'essere chiaro.

Intel ha avuto la sua bella causa per i suoi compilatori, ma per altri motivi: non riportava, nella documentazione per gli utenti, che il codice generato potesse essere ottimizzato soltanto per alcune (nemmeno tutte) sue (micro)architetture.

Questo per mettere in chiaro le cose.

Originariamente inviato da bjt2

Ci sono 2 spiegazioni possibili: le 2 titan in sli (magari qualche problema con il driver nvidia e non le manda in risparmio energetico completo) o anche il monitor è incluso nel consumo. L'uno non esclude l'altro.

Come già riportato da tuttodigitale, una Titan in idle consuma appena 10W. Mentre un sistema completo (senza monitor) con un 6900K, per giunta col doppio della memoria e in configurazione quad channel, consuma appena 62W.

Dunque anche tenendo conto dei 10W di un sistema SLI, saremmo LEGGERMENTE troppo distanti dai 106W misurati dal sistema usato da AMD per i suoi test.

Sì, ci potrebbe essere l'incognita monitor, ma la scarto perché il monitor viene collegato a un'altra presa. Certo, se avessero usato una ciabatta in cui erano collegati sia il monitor sia il PC, e dunque avessero misurato entrambi, sarebbe da prenderli a cinghiate col nervo bagnato, come direbbe mia madre.

Ma vista l'assurdità della cosa, tendo a escluderla.

Ciò detto, già non aveva senso utilizzare una Titan per benchmark del genere (che fa la GPU, a parte visualizzare i risultati?!?): farlo addirittura in configurazione SLI è da manicomio.

Per cui A ME appare evidente che siano state usate configurazioni artefatte con l'unico scopo di mettere in cattiva luce la concorrenza. E ovviamente esaltare il proprio prodotto.

Originariamente inviato da Pozhar

Cdimauro,
per le tue doti di: costanza, attenzione, precisione, esauriente, approfondito, completo etc...

sei una leggenda.

Danke!

Originariamente inviato da digieffe

infatti avevo il sospetto che la versione server avesse la necessità di una cache L1D più grande.

Scusami, non sono stato chiaro: era per sottolineare che il dato riportato dal Cern cozza con quelli ufficiali che sono stati poi pubblicati.

è stato un fallimento tecnico o commerciale?

Tutti e due.

fino a bd incluso, ho cercato in asm di trarre vantaggio dall'utilizzo dei registri GPR contemporaneamente agli xmm, ma questo veniva quasi sempre vanificato dalle latenze. L'unico modo che ho individuato per limitare le perdite è stato quello di utilizzare GPR e xmm per "thread" (no thread di OS, ma solo un mix di istruzioni interni al mio codice) separati.
Poi sarà stato un mio limite, possibile che qualcuno abbia trovato un modo migliore di sfruttare la combinazione di registri.

Allora intendevi la stessa cosa su cui aveva risposto bjt2.

Io, invece, avevo capito che parlassi delle (singole) istruzioni "miste", che operano contemporaneamente su GPR e SIMD.

per la precisione lo fanno le routine per il calcolo delle parità raid, eventualmente se non si hanno istruzioni specifiche hashing e cifratura, ...

Per il soft RAID, certo. Altrimenti con la sola CPU sarebbe troppo lenta.

sinceramente non credo possano farla troppo sporca

Ma non è sporca, in verità: hanno pubblicato due test favorevoli al proprio prodotto, e ci può stare benissimo. Marketing.

Farla sporca è prendere quei due soli risultati e pretendere di trarre conclusioni sulle prestazioni generali, con qualunque tipo di codice. E' questo che è intellettualmente disonesto.

in base a quel po' che si è visto/potuto capire (zen >> 2x vs 8350) il doppio in CB ci dovrebbe essere, seppur questo sarà inferiore al 6900k.

Infatti. Ed è singolare che doppio che abbiano usato CB in uno dei loro test (slide), alla fine non l'abbiano utilizzato.

notte anche a te

Buongiorno a tutti.

E adesso di corsa al corso di tedesco, e il resto della giornata con la famiglia.

[Piedone1113]

Originariamente inviato da paolo.oliva2

@Piedone1113.
Domanda...

Io sinceramente vedo che AMD è restia a comunicare le frequenze massime, ma non vedo un riscontro di tempo, nel senso che oramai per mantenere il 1° trimestre 2017 i proci se non sono già in produzione lo dovrebbero essere a breve.

Ora... o AMD non vuole diffondere la frequenza massima di Zen, o ancora non può conoscere quella finale (ma oramai i tempi sono stretti, quindi (per me) la dovrebbe conoscere).

La frequenza massima Turbo su pochi core non è assolutamente importante per l'X8, ma è VITALE in ottica Zen vs i7 X4. E' ovvio che un Zen X4+4 a 4GHz massimo non impensierisce Intel, diverso invece a 4,5GHz o addirittura di più. Notare che Intel non ha skylake-X a breve, ma potrebbe buttare in commercio i 7XXX X4 per anticipare Zen X4, come potrebbe essere che AMD non comunichi il turbo per far passare il periodo natalizio e poi dire che è max 4GHz. Insomma, è ingarbugliata la cosa... ma io sarei sicuro al 99% che AMD sa già tutto.

Paolo chiariamoci:
Sono pro AMD, ma anche verso il discorso logico.
Il mio vecchio account è stato bannato perchè qualche campione si mise a dire che gli ingegneri amd erano incompetenti ( ed allora mi inalberai di brutto in un'escalation di offese reciproche).
Preferisco non entrare più in discussioni troppe animate (e certe volte se fossi mod 24h di sospensione a te e a Cesare l'avrei data perchè tendete ad andare sul personale senza la volontà oggettiva di farlo) perchè meglio non commentare una news e seguire un th piacevole come questo, piuttosto che farsi bannare.

Tornando al discorso tecnico:
La macchina che fa il testing non dovrebbe firmare la cpu ed assemblarla.
La catena dovrebbe essere:
wafer, taglio laser, testing, montaggio su package, testing package, montaggio his e serigrafia dei codici.
il flash del firmware dovrebbe avvenire tra testing package e montaggio his

[bjt2]

Originariamente inviato da george_p

Mmh si, però oddio, ok che questo di amd è marketing, ma dare qualcosa di diverso dal blender?
Magari anche un render su 3DS, tanto per cambiare, se non vogliono proprio farne uno con cinebench.

Hanno fatto un handbrake e zen va il 10% in più... Non so perchè quasi nessuno ne parli...

[bjt2]

Originariamente inviato da Pozhar

Io ci terrei a vedere un super pi. Ma molto probabilmente non avverrà mai. e che almeno si incominciava a capire come si deve la reale situazione nell'st

Senza turbo attivo non faresti vedere comunque il max della CPU. Tutti i test ST, con turbo disattivato, non sarebbero rappresentativi della velocità finale... E se il turbo max fosse 4.5GHz? Capisci che testare il ST a 3.4GHz sarebbe penalizzante...

Originariamente inviato da Veradun

Non hanno anche mostrato handbrake?

Si. E Zen va il 10% in più...

Originariamente inviato da Pozhar

si, ma all'atto pratico ha poco senso. e un test fine a se stesso.

E' diverso da blender: l'uno è FP e l'altro è int. In uno pareggia, e in un altro lo supera. io sospetto che venga ingorato dai più proprio perchè supera INTEL. E se anche li scatta il turbo, siamo a +10% con 100 mhz di clock in meno...

[bjt2]

Originariamente inviato da george_p

Infatti io avevo capito 54 sec per amd e 59 per intel, ricordo così almeno.

Quello è handbrake...

[bjt2]

Originariamente inviato da cdimauro

Questo è chiaro. Ma il punto è che le istruzioni (uop, in realtà) di una coda devono essere anche indipendenti da quelle presenti in una delle altre 5 code.

Cosa tutt'altro che semplice da risolvere, su codice seriale, che in genere ha catene di dipendenze.

L'algoritmo di scoreboard è difficile da capire per noi umani, ma fidati... E' semplice... La prima volta che lo lessi sul Tanenbaum, mi venne il mal di testa... Ma sono semplicissime regole...

Originariamente inviato da cdimauro

No. Intel ha TRE porte a 256 bit, mentre Zen 4 a 128 bit.

Si, scusami... Avrei dovuto specificare 2 porte FP a 256 bit, perchè avevo in mente blender...

Guarda che carina questa immagine:

Originariamente inviato da cdimauro

Beh, no: almeno qui ci sarebbero in gioco le latenze addizionali dovute al fatto che Zen ha solo unità FMUL o FADD, e dunque deve simulare l'FMAC concatenando in sequenza due uop.

Vedremo quanto sarà, ma ho il sospetto che sia al max un ciclo...

Originariamente inviato da cdimauro

Ancora no: ha tre porte a 128 bit contro 4.

Intendevo in FP, come sopra.

Originariamente inviato da cdimauro

No: Intel ha 3 porte direttamente utilizzabili per 2 load + 1 store. Zen ha soltanto 2 porte (devi passare per forza dalle 2 AGU).

E di molto: a livello di load/store è 3 volte più capace.

Non so che senso abbia per AMD fare una cache 2+1 se poi può fare solo 2 operazioni. O lo stack non richiede le agu, oppure, visto che ora le agu sono disaccoppiate dalle ALU, per indirizzamenti semplici non servono...

Originariamente inviato da cdimauro

Il compilatore sarà pure intelligente, ma poi il decoder del processore ne decodifica al massimo 4 di istruzioni, e non 8.

Inoltre è la logica dello scheduler che si occupa di riorganizzare le uop (nemmeno istruzioni) opportunamente, per cui se intelligenza ci dev'essere nel processo di selezione delle istruzioni, è meglio che stia qui.

Hai ragione... Non ci avevo pensato... Però la uop cache può spararne 6 per ciclo, quindi 8 si può avere nei picchi soltanto, ma a regime si può avere più di 4 se la uop cache ha basso miss rate...

Originariamente inviato da cdimauro

Già. C'è pure questo, visto che il blocco "intero" e quello FPU sono separati.

Non credo fosse questo a cui si riferisse digieffe. Esistono singole istruzioni che operano contemporaneamente su registri GPR e dell'FPU.

E non pensare che siano roba esotica e poco comune: sono comodi per fare, ad esempio, velocemente una conversione di un valore intero, da GPR a SIMD o viceversa; oppure per controllare se un vettore sia tutto a zero settando l'apposito flag in R/D/FLAG.

In questi casi immagino che Zen debba suddividere quest'istruzione in due: una da spedire all'unità che funge da sorgente, e un'altra a quella che fa destinazione. Ovviamente schedulandole opportunamente.

Si, le istruzioni di conversione sono un casino...

Originariamente inviato da cdimauro

Python è già tanto se usa l'FPU: mai visto traccia d'uso delle SIMD.

Beh le vecint. Ma immagino che sia complicato fare un codice che al runtime impacchetti più operazioni in una simd, quindi hai ragione... Ma usare vecint come scalare e int si può...

Originariamente inviato da cdimauro

Comunque anche in kernel space si può usare l'FPU e/o l'unità SIMD. E lo si fa, se proprio serve. Però è un casino.

Si deve salvare lo stato e non lo fa il kernel perchè costa troppo. Forse succede in qualche driver kernel in linux, ma credo che in windows no. C'è l'user mode driver framework in windows e sono sempre meno i driver che lavorano in ring 3... Così scompaiono i blue screen...

Originariamente inviato da cdimauro

Ma Zen su Cinebench non andava il doppio dell'8350, secondo una slide di AMD?

Quella è una nostra deduzione contando i pixels... E poi non sappiamo se si riferisce all'8150, 8350, 8370 o al 9570 (o quello che è con clock 4.7/5)...

Originariamente inviato da cdimauro

Passando da 4 a 6 vie potrebbe anche aumentare, come già discusso diverse volte.

Beh ma uno è 1x4 vie e quindi deve controllare fino a 4x<profondità coda> uop per ciclo e l'altro sono 6 scheduler che devono controllare una sola istruzionex<profondità coda> per ciclo... Io credo che il compito sia più semplice... Non sto parlando del numero totale di transistors, che può anche essere superiore, ma del FO4. Una struttura complessa, contro 6 semplici. I transistors possono pure essere di più, ma non credo il FO4...

Originariamente inviato da cdimauro

Inoltre ho riflettuto sullo scheduler di Intel. Guardandolo meglio in certi, particolari aspetti, c'è qualcosa che mi fa pensare che sia molto più semplice di quello che sembri a prima vista.

Ma infatti ti ho detto che l'algoritmo scoreboard è una cavolata... Procurati il Tanenbaum "Structured computer organization", ad esempio, oppure online cercando scoreboard scheduling algorithm:

https://en.wikipedia.org/wiki/Scoreboarding
http://www.cs.umd.edu/class/fall2001...coreboard.html
http://euler.mat.uson.mx/~havillam/c...cs-323011.html

E' più difficile spiegarlo e capirlo, che eseguirlo... E gli automi sono bravissimi ad eseguire compiti ripetitivi senza capirli...

[Ubro92]

Originariamente inviato da bjt2

Quello è handbrake...

Infatti anche io avevo commesso l'errore di considerare i 54s per blender, e valutando i test con tempi di 54s per handbrake e 36s per blender, viene fuori che l'ipc è sicuramente parallelo a quello di intel da haswell in su, poi data la differente architettura ci saranno sicuramente contesti in cui intel spinge di piu e viceversa.

[bjt2]

Originariamente inviato da Ubro92

Infatti anche io avevo commesso l'errore di considerare i 54s per blender, e valutando i test con tempi di 54s per handbrake e 36s per blender, viene fuori che l'ipc è sicuramente parallelo a quello di intel da haswell in su, poi data la differente architettura ci saranno sicuramente contesti in cui intel spinge di piu e viceversa.

Io penso che su codice non 256 bit (e quindi tutti i legacy), siamo tra broadwell e skylake come IPC, e quindi si può recuperare con il clock.

Con AES dovremmo essere superiori, perchè Zen ha 2 unità AES per core nella FP e anche con minore latenza, mentre i core una sola per core.

Con codice a 256 bit non dovrebbe esserci storia: intel dovrebbe essere superiore e il distacco dipenderà da quanto complessi sono i calcoli e dall'hit rate della cache. Per calcoli semplici su molti dati, le unità si gireranno i pollici e tutto dipenderà dalla banda ram (es: sommare due vettori/matrici), quindi poco guadagno... Mentre con calcoli complessi con pochi dati, dovrebbe volare. Ricompilando blender per le 256 bit dicono, su anand, di aver ottenuto vantaggi dal 20 al 60% (!!!)

[paolo.oliva2]

Originariamente inviato da bjt2

E' diverso da blender: l'uno è FP e l'altro è int. In uno pareggia, e in un altro lo supera. io sospetto che venga ingorato dai più proprio perchè supera INTEL. E se anche li scatta il turbo, siamo a +10% con 100 mhz di clock in meno...

Quindi checchè si dica, AMD avrebbe fatto confronti con 2 programmi che mettono in risalto la parte INT e FP di un procio, oltre all'SMT perchè entrambi MT

Edit
Anche se evitando il discorso 256 bit vs 128, ma è da quantificare l'eventuale vantaggio Intel (che sarebbe solamente sulla parte FP)

Originariamente inviato da Ubro92

Io sono convinto che la scarsità di informazione serve solo per mantenere alto l'interesse e quindi per ragioni marketing se rilasciasse troppe info si perderebbe l'effetto "WoW" alla prima review dei sample commerciali, alla fine si tratta di attendere un mesetto e si saprà vita, morte e miracoli di queste cpu

Nessuno lo mette in dubbio questo, ma rendiamoci conto di una cosa:

Tu vedi fibrillazione dei fanboy AMD tipo Zen va di più di Intel e quindi i fanboy Intel si sentono attaccati e di qui che vanno in difesa?

Oppure vedi una situazione in cui Zen pompa e ai fanboy Intel gli tira e non vogliono assolutamente manco ipotizzare che Zen arrivi vicino? E di qui è tutto un corollario tra frequenze non veritiere, consumi idem, software partigiano e quant'altro.

E siccome TUTTI sappiamo che i prezzi Intel sono gonfiati, allora AMD NON PUO' applicare oltre un -20% sui prezzi rispetto a quelli Intel, ma siccome in tutto il WEB di tutto il mondo non c'è una persona che non riporti che AMD i prezzi li applicherà più bassi, ovviamente Zen DEVE andare meno del 6900K almeno nell'esatta proporzione di quanto costerà meno.

Giusto per essere imparziali... Qualcuno pensa che Zen X8+8 costerà a partire da 800$? Perchè già a 800$ sarebbe maggiore del -20%, ma nessuno qua penso che ipotizzi Zen X8+8 = 6850K.

Io sono filo AMD, non lo nego... ma faccio molta fatica a ipotizzare quanto ho scritto come di parte e invece razionale la critica.

[Ryddyck]

Originariamente inviato da george_p

Mmh si, però oddio, ok che questo di amd è marketing, ma dare qualcosa di diverso dal blender?
Magari anche un render su 3DS, tanto per cambiare, se non vogliono proprio farne uno con cinebench.

Dobbiamo farci bastare quella dimostrazione su zbrush...

Originariamente inviato da tuttodigitale

con k10, l' FX da 1000 euro era solo una versione di una cpu da 500 euro con 200MHz in più e molti sbloccato...che a sua volta era solo una versione con qualche MHZ e il doppio della cache di un prodotto da 200 euro...
e per restare in casa Intel, la differenza di prezzo tra un i7 960 e un i7 975 extreme era notevole: il primo costava 562 dollari, il secondo 999.
Per quello che si è visto in passato, 150 sono ampiamente giustificabili, se questo significa avere un prodotto bloccato con l'ottimo rapporto prezzo prestazioni, già a stock.

Ma hanno venduto pochissimo, poi ai tempi non è che ci fossero altre soluzioni alternative con più core/thread da giustificare il prezzo così alto.

Originariamente inviato da paolo.oliva2

La frequenza massima Turbo su pochi core non è assolutamente importante per l'X8, ma è VITALE in ottica Zen vs i7 X4. E' ovvio che un Zen X4+4 a 4GHz massimo non impensierisce Intel, diverso invece a 4,5GHz o addirittura di più. Notare che Intel non ha skylake-X a breve, ma potrebbe buttare in commercio i 7XXX X4 per anticipare Zen X4, come potrebbe essere che AMD non comunichi il turbo per far passare il periodo natalizio e poi dire che è max 4GHz. Insomma, è ingarbugliata la cosa... ma io sarei sicuro al 99% che AMD sa già tutto.

Ma se è già in preorder da qualche parte, ci sono mezze recensioni di testate di rilievo e già qualche utente normale ce l'ha tra le mani... Le mobo sono pure state presentate, fai un po' tu

[.338 lapua magnum]

Originariamente inviato da Ubro92

Ma in realtà questo test fatto con blender dipende da troppi fattori, io ho fatto il test con il mio 2500K e a conti non mi trovo...

Con Samples a 200 impiego 2:11.59 mentre con samples a 150 1:46.51 quindi non credo sia assolutamente affidabile come test

secondo amd il campionamento è 150

http://www.amd.com/en-us/innovations/new-horizon

"​​Try out the Ryzen Blender demo for yourself.
​ ​
Check system requirements to see if your system can run Blender.
If your system meets the requirements:
Download and instal Blender (Version Blender 2.78a 64bit installer)
​Download the Ryzen Blender Demo file
​​​Run Blender
Load the file by selecting File>Open at the top left of the application, and navigate to the RyzenGrap​hic_27.blend file you downloaded in the above step. Double-click this file to load it into Blender.
On the right-hand palette, make sure the camera icon (render palate) is selected. Below it in the Sampling section, make sure Samples: Render is set to 150.
Render the image by selecting Render>Render at the top left of the application. Wait for the image render to finish up.
The time to render will be listed at the top left, under the file menu."

[digieffe]

Originariamente inviato da bjt2

Senza turbo attivo non faresti vedere comunque il max della CPU. Tutti i test ST, con turbo disattivato, non sarebbero rappresentativi della velocità finale... E se il turbo max fosse 4.5GHz? Capisci che testare il ST a 3.4GHz sarebbe penalizzante...



Si. E Zen va il 10% in più...



E' diverso da blender: l'uno è FP e l'altro è int. In uno pareggia, e in un altro lo supera. io sospetto che venga ingorato dai più proprio perchè supera INTEL. E se anche li scatta il turbo, siamo a +10% con 100 mhz di clock in meno...

credo che una cosa sia certa: le frequenze reali (base+turbo varii) di zen NON saranno inferiori al 6900k.
Immagino anche che la prossima incarnazione intel EHDT di intel possa avere +200mhz su tutte le freq. (stile 7700k)

proprio sicuro che Handbrake sia solo int? e quale tipo di int: GPR o MM?

[digieffe]

@Cesare

peccato per la cache L1 di soli 32k. 64k avrebbero potuto, genericamente, velocizzare molto gli emulatori (più spazio per il codice ed i dati dell'arch. emulata).