[Thread Ufficiale] Aspettando ZEN

[sgrinfia]

Originariamente inviato da Mister D

Prima di tutto:

Buone feste e buon anno a tutti! Che sia un 2017 pieno di concorrenza

Poi vorrei portare alla luce questa questione:
http://www.agner.org/optimize/optimizing_cpp.pdf
da pag 133:
13.7 CPU dispatching in Intel compiler
Intel compilers have a feature for making multiple versions of a function for different Intel CPUs. It uses the dispatch on every call method. When the function is called, a dispatch is made to the desired version of the function. The automatic dispatching can be made for all suitable functions in a module by compiling the module with, e.g. the option /QaxAVX or -axAVX. This will make multiple versions even of functions that are not critical. It is possible to do the dispatching only for speed-critical functions by using the directive __declspec(cpu_dispatch(...)). See the Intel C++ Compiler Documentation for details. Note that the CPU dispatch mechanism in the Intel compiler works only for Intel CPUs, not for other brands of CPUs such as AMD and VIA. The next section (page 134) shows a way to work around this limitation and other flaws in the CPU detection mechanism.

The CPU dispatch mechanism in the Intel compiler is less efficient than the Gnu compiler mechanism because it makes dispatching on every call of the critical function. In some cases, the Intel mechanism executes a series of branches every time the function is called, while the Gnu mechanism stores a pointer to the desired version in a procedure linkage table. If a dispatched function calls another dispatched function then the dispatch branch of the latter is executed even though the CPU-type is already known at this place. This can be avoided by inlining the latter function, but it may be better to do the CPU dispatching explicitly as in example 13.1 page 130.

The Intel compilers and function libraries have features for automatic CPU dispatching. Many Intel library functions have several versions for different processors and instruction sets. Likewise, the compiler can automatically generate multiple versions of the user-written code with automatic CPU dispatching.

Unfortunately, the CPU detection mechanism in Intel compilers has several flaws:

- The best possible version of the code is chosen only when running on an Intel processor. The CPU dispatcher checks whether the processor is an Intel before it checks which instruction set it supports. An inferior version of the code is selected if the processor is not an Intel, even if the processor is compatible with a better version of the code. This can lead to a dramatic degradation of performance on AMD and VIA processors.

- Explicit CPU dispatching works only with Intel processors. A non-Intel processor makes the dispatcher signal an error simply by performing an illegal operation that crashes the program.

- The CPU dispatcher does not check if XMM registers are supported by the operating system. It will crash on old operating systems that do not support SSE.

Several function libraries published by Intel have similar CPU dispatch mechanisms, and some of these also treat non-Intel CPUs in a suboptimal way. The fact that the Intel CPU dispatcher treats non-Intel CPUs in a suboptimal way has become a serious legal issue. See my blog for details.

The behavior of the Intel compiler puts the programmer in a bad dilemma. You may prefer to use the Intel compiler because it has many advanced optimizing features, and you may want to use the well optimized Intel function libraries, but who would like to put a tag on a program saying that it doesn't work well on non-Intel machines?

Possible solutions to this problem are the following:

- Compile for a specific instruction set, e.g. /arch:SSE2. The compiler will produce the optimal code for this instruction set and insert only the SSE2 version of most library functions without CPU dispatching. Test if the program runs satisfactorily on a non-Intel CPU. If not, then it may be necessary to replace the CPU detection function as described below. The program will not be compatible with old microprocessors that do not have the selected instruction set.

- Make two or more versions of the most critical part of the code and compile them separately with the appropriate instruction set specified. Insert an explicit CPU dispatching in the code to call the version that fits the microprocessor it is running on.

- Replace or bypass the CPU detection function of the Intel compiler. This method is described below.

- Make calls directly to the CPU-specific versions of the library functions. The CPUspecific functions have names with suffixes such as e.g. .R. for AVX. These suffixes are listed in table 19 in manual 5: calling conventions. The dot in the function name is not allowed in C++ so you need to use assembly code or use objconv or a similar utility for modifying the name in the object file.

- Use another function library that works well on all brands of CPUs.

The performance on non-Intel processors can be improved by using one or more of the above methods if the most time-consuming part of the program contains automatic CPU dispatching or memory-intensive functions such as memcpy, memmove, memset, or mathematical functions such as pow, log, exp, sin, etc.

Overriding the Intel CPU detection function

In some cases, there are two versions of the CPU detection function, one that discriminates between CPU brands, and one that doesn’t.

The undocumented Intel library function __intel_cpu_features_init() sets the variable __intel_cpu_feature_indicator where each bit indicates a specific CPU feature on Intel CPU’s. Another function __intel_cpu_features_init_x() does the same without discriminating between CPU brands and similarly sets the variable __intel_cpu_feature_indicator_x. You can bypass the check for CPU brand simply by setting these variables to zero and then call __intel_cpu_features_init_x().

In other cases, it is possible to replace the CPU detection function in Intel function libraries and compiler-generated code by making another function with the same name. In the Windows operating system, this requires static linking (e.g. option /MT). In Linux and Mac systems, this may work with both static and dynamic linking.

The file http://www.agner.org/optimize/asmlib.zip contains complete code examples for these methods.
If you are using an Intel compiler, then make sure the startup code and main() are compiled without any option that limits the CPU brand. Critical parts of the code can then be placed in a separate C or C++ file and compiled for the desired instruction set. If the CPU brand check is bypassed by any of these methods then the critical part can run optimally on any brand of CPU.

These methods also work when Intel libraries are used with other compilers. This includes the libraries named MKL, VML and SVML. The IPP library does not need any patch.

Note that these methods are based on my own research, not on publicly available information. They have worked well in tests on Intel compiler versions 7 through 14, with some changes for each version. The examples are intended to work in both Windows and Linux, 32-bit and 64-bit. They have not been tested in Mac systems.

Ma la FTC (Federal Trade Commission) non aveva preteso da Intel nel 2010 se ben ricordo di mettere a posto il proprio compilatore per evitare ciò?
Chiedo ai più esperti perché a leggere, se ho ben interpretato, sembra che delle penalità ci siano cmq usando senza correzioni l'intel c++ compilier con cpu non-intel. Ho capito male? Perché se fosse così saremmo da capo e non capisco perché, visto che intel con tutto il vantaggio che ha per me non avrebbe bisogno di tali pratiche.

Mi fermo sulle tue ultime parole, domanda: e se fosse questo il vantaggio di Intel?

[Mister D]

Originariamente inviato da sgrinfia

Mi fermo sulle tue ultime parole, domanda: e se fosse questo il vantaggio di Intel?

Bhe no, nel senso che se vai a rivedere il thread in questa stessa sezione mi pare di ricordare un massimo vantaggio del +20% circa per le cpu amd una volta tolte le penalizzazioni ergo ora il gap di ipc che ha intel è cmq più alto. Magari invece può essere determinante con Zen se questo avrà un IPC simile (non uguale) alle ultime cpu intel

[Emaximus]

http://cpugrade.com/amd-ryzen-thoughts/ <-- Da leggere

[Mister D]

Originariamente inviato da Emaximus

http://cpugrade.com/amd-ryzen-thoughts/ <-- Da leggere

Bell'articolo che riassume molto bene quello che è uscito fin'ora

[Ryddyck]

Mhm... ha preso come riferimento pure cinebench che fa 1188 dichiarato falso...
Per il resto lato prezzi ha buttato range un po' troppo elevati per gli sr3/sr5 e raven ridge

$150–300 — quad-core Raven Ridge APUs (Ryzen RR3).
$200–350 — quad-core Summit Ridge CPUs (Ryzen SR3).
$400–500 — hexa-core Summit Ridge CPUs (Ryzen SR5).
$500–650 — octa-core Summit Ridge CPUs (Ryzen SR7).
$650–800 — octa-core Summit Ridge CPUs with the highest stock core frequencies, and also a watercooling kit (Ryzen SR9).

[Mister D]

Originariamente inviato da Ryddyck

Mhm... ha preso come riferimento pure cinebench che fa 1188 dichiarato falso...
Per il resto lato prezzi ha buttato range un po' troppo elevati per gli sr3/sr5 e raven ridge

Sì ma lui scrive così:
and we assume it's a legitimate result of an octa-core AMD Ryzen sample at 3.30 GHz on all cores.

Quindi assume che potrebbe essere un valore plausibile per un es buggato su cache e smt ergo sottostima il valore reale ergo si mette dalla parte del sicuro. Mi sembra abbastanza facile come ragionamento

[Mister D]

Originariamente inviato da Ryddyck

Mhm... ha preso come riferimento pure cinebench che fa 1188 dichiarato falso...
Per il resto lato prezzi ha buttato range un po' troppo elevati per gli sr3/sr5 e raven ridge

Aggiungo anche che però lui i suoi calcoli li prende dai dati di canard partendo dallo score più alto su hwbot di un fx8350 cloccato altissimo:
/* FX-8350 baseline */
PD_Score = 1196 cb
PD_MHz = 7649 MHz

/* FX-8350 performance-per-clock */
PD_Score ÷ PD_MHz = 0.156
PD_PPC = 0.156 cb/MHz

/* Zen performance-per-clock gain over FX-8350 */
ZN_GAIN = 1.992 -> QUESTO DATO viene da 209,6 (valore di quel ES zen cloccato a 4,10) diviso per 105.2 che viene esattamente = 1.99239....
PD_PPC × ZN_GAIN = 0.311
ZN_PPC = 0.311 cb/MHz

/* Zen CineBench R15 score @ 3300 MHz */
(PD_MHz ÷ ZN_GAIN) × ZN_PPC = 1194
ZN_3300 = 1194 cb

E guarda caso 1194 punti sono molti simili ai 1188 ergo chi ha fatto quel fake potrebbe non averlo fatto tanto a caso

[Ryddyck]

Già i rumor non sono affidabili, se poi si fanno previsioni su rumor dichiarati falsi non è che si vada tanto lontano.

Comunque da twitter di B&C:

[RUMOR] Silicon lottery incoming. Is your RyZen CPU made by GlobalFoundries or by Samsung?

[Mister D]

Originariamente inviato da Ryddyck

Già i rumor non sono affidabili, se poi si fanno previsioni su rumor dichiarati falsi non è che si vada tanto lontano.

Sì chiaramente ma uno si fa per parlare e due se si sottostima sicuramente ci si mette dalla parte del sicuro.
Tuttavia in tutto questo ipotizzare numeri, quello che dovrebbe risultare che ZEN sembrerebbe vicino come IPC a broadwell-e e che la frequenza potrebbe anche essere 100/200 MHz più alta del 6900k (che prendo come riferimento perché è la cpu intel bw-e da 8c/16th).

Se poi mettiamo prezzi con un range più basso degli attuali i7 2011 allora potrebbe essere un buon prodotto quello di amd.

[george_p]

Originariamente inviato da capitan_crasy

Le bestemmie sono ben altra cosa...
E comunque quoto il tuo post precedente!
Sinceramente avete rotto i tre/quarti con tutti sti OT!

Con la scusa della libertà di pensiero e di espressione (democrazia, questa abusata) tutto è lecito, idem compresi infiniti e ripetuti OT perché c'è chi ha bisogno di avere sempre l'ultima parola (leggi ragione, che poi sappiamo a chi appartiene da sempre) perché sono sempre gli altri che stuzzicano.

P.s.: Come è stato scritto in quel contesto la parola Madonna è semplicemente una esclamazione. Si bestemmia quando manca il rispetto del prossimo ad ogni costo.

[george_p]

Originariamente inviato da Mister D

Sì chiaramente ma uno si fa per parlare e due se si sottostima sicuramente ci si mette dalla parte del sicuro.
Tuttavia in tutto questo ipotizzare numeri, quello che dovrebbe risultare che ZEN sembrerebbe vicino come IPC a broadwell-e e che la frequenza potrebbe anche essere 100/200 MHz più alta del 6900k (che prendo come riferimento perché è la cpu intel bw-e da 8c/16th).

Se poi mettiamo prezzi con un range più basso degli attuali i7 2011 allora potrebbe essere un buon prodotto quello di amd.

Ricordami per favore, la cpu Broadwell è quella con il più alto ipc?
Cioè mi sembra di aver letto che le successive non lo aumentino di niente o quasi.
Perché un tempo si ipotizzava un ipc vicino ad Haswell.
E, soprattutto, parliamo di ST... o no?

[tuttodigitale]

Originariamente inviato da gridracedriver

per non dimenticare
http://www.hwupgrade.it/forum/showpo...postcount=1530

gridracedriver:
IPC ~90% BW (CineBench r11.5/r15) (simile a digieffe in effetti lui si riferisce a SL)
SMT +50% (CineBench r11.5/r15)
TDP 125w Zen 8c/16th Top
3.7ghz def
4.2ghz turbo



siamo gli unici ad aver azzardato sull'incremento SMT (anche se mi pare di ricordare che bjt2 disse anche lui +50%)

a onor del vero, ho detto tutto e il contrario di tutto, in questo thread ,un poco alla volta il mio pensiero si è allineato a quello di bjt2, (le sue argomentazioni sono state molto convincenti) abbassando leggermente la frequenza (bjt2 crede possibile ancora i 4GHz default e 5GHz turbo) e un pò più elevato non tanto l'ipc, ma lo scaling SMT.
Certo se il tutto fosse in 95W, sarebbe proprio il no-plus ultra, poichè sarebbe davvero un prodotto mainstream....aspettando i 12 core ZEN

[paolo.oliva2]

Originariamente inviato da tuttodigitale

a onor del vero, ho detto tutto e il contrario di tutto, in questo thread ,un poco alla volta il mio pensiero si è allineato a quello di bjt2, (le sue argomentazioni sono state molto convincenti) abbassando leggermente la frequenza (bjt2 crede possibile ancora i 4GHz default e 5GHz turbo) e un pò più elevato non tanto l'ipc, ma lo scaling SMT.
Certo se il tutto fosse in 95W, sarebbe proprio il no-plus ultra, poichè sarebbe davvero un prodotto mainstream....aspettando i 12 core ZEN

Però, se sintetizziamo tutto e partiamo dalla dichiarazione di AMD +40% IPC su XV (leggi +65% su PD), alla fin fine cosa avrebbe decretato Zen un ottimo processore o meno?

Le frequenze operative, intese non in un super-silicio ma solamente un silicio che non avrebbe gambizzato l'architettura, ed il prezzo prestazioni che AMD avrebbe applicato, perchè, OVVIAMENTE, l'offerta AMD sul 14nm sarebbe salita ugualmente per potenza.

Ora... l'IPC dichiarato da AMD non solo sembra confermato, ma addirittura superiore a quanto dichiarato, le frequenze def pure, visto che i 3,4GHz+ sembrano un vecchio ricordo di alcuni giorni, e il prezzo stimato del top Zen X8+8, il più alto letto sinora, 800$, quasi un -50% secco sul 6900K.

+/- 5% IPC, +/- 5% di frequenze, quanto vorrebbero dire? NULLA!!!

[sgrinfia]

Originariamente inviato da Mister D

Bhe no, nel senso che se vai a rivedere il thread in questa stessa sezione mi pare di ricordare un massimo vantaggio del +20% circa per le cpu amd una volta tolte le penalizzazioni ergo ora il gap di ipc che ha intel è cmq più alto. Magari invece può essere determinante con Zen se questo avrà un IPC simile (non uguale) alle ultime cpu intel

Mi sono espresso un po'" corto", non volevo dire che il "vantaggio "Intel sia dovuto "tutto" su queste pratiche "discutibili"....., quello che mi fa più specie è il comportamento di "Microsoft" che avalla certi comportamenti perlomeno scorretti.

[paolo.oliva2]

http://cpugrade.com/amd-ryzen-thoughts/

Guradando l'articolo che avete postato, alla prima tabella si possono fare 2 conti.

Zen X8 ha il 1° turbo su 1-3 core vs 6900K 1-2 core.
E' vero che Zen X8+8 ha 16MB di L3 vs i 20MB del 6900K, però ha il doppio della L1 instructions (512KB vs 256KB) e il doppio di L2 (4MB vs 2MB), alla fine la differenza sarebbe quasi 21MB per Zen vs 22,5MB per il 6900K

Inoltre, siccome il turbo massimo è 1-3 core, AMD ha fatto come in BD, cioè in BD spegneva i moduli non utilizzati e in Zen il CCX non utilizzato. (ovviamente essendo un numero dispari (1-3 core), non può essere la somma di 2 CCX, perchè sarebbe sempre pari).

[the_joe]

Originariamente inviato da paolo.oliva2

............ e il prezzo stimato del top Zen X8+8, il più alto letto sinora, 800$, quasi un -50% secco sul 6900K.

Scusa commerciante, come li fai i conti? se il 6900K costa mediamente in ITALIA compresa IVA circa 1100Euro, il Top Ryzen 8/16 a 800Euro (probabilmente senza IVA ma diciamo che c'è anche l'IVA dentro) è un MISERO come diresti tu -27% circa

Buona fine anno e buon inizio 2017 a tutti.

[Wolfhang]

Originariamente inviato da paolo.oliva2

Io ho avuto 4 generazioni di mobile, Llano, Trinity, Intel X2+2 22nm e Intel X2+2 14nm Broadwell. Non li ho avuti contemporaneamente, quindi non li ho potuti confrontare, ma a naso Llano/Trinity e Intel X2+2 sul 22nm, non c'era gran differenza. L'ultimo che ho, 5500U, è più robusto dei 3 sicuramente... con poco carico frulla, è quasi sempre in turbo, la batteria dura abbastanza, però sulla carta sicuramente BR guadagna un tot sui modelli AMD miei anteriori, più di quanto guadagna Broadwell 14nm sul precedente 22nm e Skylake su Broadwell... quindi sta gran differenza prestazionale che giustifichi una spesa 3 volte superiore, boh... per me è inspiegabile.
Può darsi che Intel per gli OEM applichi forti sconti e che gli OEM prezzino il sistema in base al listino processori al pubblico, ovviamente guadagnandoci un tot. Ovviamente non sarebbe una sorpresa che gli OEM spingano il prodotto che (a loro) faccia guadagnare di più...
Comunque se Zen sarà competitivo e AMD lo prezzasse come i rumors, gli OEM dovranno obbligatoriamente rapportare il costo del mobile al costo dei PC desktop... cioè, non puoi vendere un mobile X2+2 ad un prezzo superiore rispetto ad un X8+8 desktop... , come non credo che da un Zen X4+4 APU ~200€, lo stesso procio ma mobile possa costare il doppio e più.

Te l'ho già detto l'altra volta, per il tuo utilizzo ti dovevi comprare un'altra tipologia di portatile, non una serie U:
http://www.trovaprezzi.it/prezzo_not...i7_6700hq.aspx
avresti prestazioni che pure Bristol Ridge desktop a 65W si sogna e anche una scheda grafica discreta che ti permetterebbe di giocare meglio di qualsiasi APU.

[paolo.oliva2]

http://cpugrade.com/amd-ryzen-thoughts/

Non ho capito una cosa....

Nella tabella dei consumi, hanno scritto che un Zen X8+8 @4,1GHz consumerebbe MENO di un 8370 a def, cioè 116W vs 118W di un 8370.

In basso c'è la nota che i dati sarebbero teorici... ma teorici fino ad un certo punto, perchè se non sai quanto scala il silicio in frequenza rispetto al TDP, non si potrebbe scrivere nulla, se lo hanno scritto, era su qualche dato?

Non è che voglia sollevare un bollirone, ma messo così sembra quasi che Zen X8+8 abbia frequenze/TDP alla Piledriver... perchè QUEL dato concorda con il rumors dei 5GHz ad aria...

[paolo.oliva2]

Originariamente inviato da Wolfhang

Te l'ho già detto l'altra volta, per il tuo utilizzo ti dovevi comprare un'altra tipologia di portatile, non una serie U:
http://www.trovaprezzi.it/prezzo_not...i7_6700hq.aspx
avresti prestazioni che pure Bristol Ridge desktop a 65W si sogna e anche una scheda grafica discreta che ti permetterebbe di giocare meglio di qualsiasi APU.

Ma io non gioco... e il mobile l'avevo preso per non restare a piedi (come purtroppo è successo).
Avevo preso quel modello perchè per 750€ pensavo fosse un altro livello... Per uno che assembla PC, abituato a scegliere i componenti, che ama metterci le mani dentro, cazzeggiare nel bios, perchè alla fine spendere di più per avere meno potenza di un modello equivalente desktop, oltretutto con le mani legate?
P.S.
Concordo con te che a livello di procio/potenza sia un'altra cosa.

[paolo.oliva2]

Inoltre:


My Final Conclusions of AMD Ryzen — Pricing

$150–300 — quad-core Raven Ridge APUs (Ryzen RR3).
$200–350 — quad-core Summit Ridge CPUs (Ryzen SR3).
$400–500 — hexa-core Summit Ridge CPUs (Ryzen SR5).
$500–650 — octa-core Summit Ridge CPUs (Ryzen SR7).
$650–800 — octa-core Summit Ridge CPUs with the highest stock core frequencies, and also a watercooling kit (Ryzen SR9).

BR X4/4TH APU è dato a 180$, perchè lo riporta 150/300$?

Non capisco come farebbe a vendere AMD un X4+4 NON APU ad un prezzo superiore al 7700K che è APU (350$)

Posso capire i modelli SR3 e 5 a prezzo alto per portare il cliente sull'SR7, ma non puoi schiaffare l'SR7 a partire da 500$, perchè nessun affezionato Intel spenderebbe 150$ in più per prendersi un Zen X8+8 base rispetto ad un 7700K.

800$ per l'X8+8 Zen ci può stare perchè lui specifica con il kit di raffreddamento a liquido... e procio selezionato e aperto.
Io ho idea che lui sbagli la sigla di Zen con la rispettiva Intel.
Inoltre... se