Quote:
Questa sarebbe camorra!! |
A quanto pare alcune CPU AMD permetterebbero di cambiare il CPUID. La guida qui: http://forum.pcstats.com/showthread.php?t=30446
Sarebbe bello se qualcuno con un AMD provasse a testare PCMARK prima con il procio con ID normale e poi modificato. Volontari? |
Quote:
Secondo questo link che solleva il problema dei compilatori http://www.programmazione.it/index.p...m&idItem=43608 "modifica del CPUID dei processori AMD usando le istruzioni di virtualizzazione della stessa AMD" si potrebbero rendere i test imparziali |
Quote:
Per quanto riguarda AMD, si può cambiare solo la stringa del nome del processore, difattti il "nome" al processore viene assegnato dal bios della scheda madre in fase di boot e lo si può cambiare in qualunque momento. Tuttavia l'identificativo AuthenticAMD non si può cambiare (mentre con i VIA si può cambiare) ne si possono cambiare le altre informazioni come famiglia, stepping, etc... ed è per questo che nel benchmark riportato sopra è stata usata una CPU VIA. |
I have already did such an investigation and even more . For example:
1) ABBYY Fine Reader 8.0's ScanMan.exe contains the CPU dispatcher which blocks the SSE2 code path (and chooses x87) on CPU with Vendor = "AuthenticAMD" and Base Family = 0Fh, i.e. on K8 & K10! 2) Several DivX 6.x versions contain similar CPU dispatcher which blocks SSE's (and chooses MMX) on CPU with Vendor != "GenuineIntel". What unfair play! preso da http://forums.amd.com/devforum/messa...VIEWTMP=Linear |
Quote:
|
Benchmarks beware
In many of not most benchmarks, the Intel compiler produces the fastest code of any F77/F90 compiler. However, care needs to be taken on non-Intel chips. Code compiled with -axW, for example, will not use ANY SSE or SSE2 instructions on non-Intel chips. This will almost certainly greatly impact performance. If the use of SSE2 is forced with -xW (which is what Intel sort-of-recommend for Opterons), then some SSE2 code will be used (as the code in the main program will use SSE2 instructions), but calls to the vectorised single-precision math instrinsics will use SSE, not SSE2. In most of not all cases, then, code compiled with the Intel Fortran Compiler (and presumably icc as well, although I haven't tested it) will run slower than it should on non-Intel CPUs due to deliberate targeting of non-Intel CPUs by the compiler engineers. Benchmarks comparing the performance of AMD and Intel CPUs should beware of using the Intel compilers for this reason. As an example, some (internal) code was compiled with ifc version 8.1.028 build 20050520Z twice. For the second compile, the Intel CPU check was patched out of the compiler and replaced with a no-op. The code is otherwise identical, compiled with '-O3 -fpp -tpp6 -ip -pad -w95 -cm -Vaxlib -static-libcxa'. The machines used are a dual-Opteron 248 and a P4 1.7 GHZ, values are seconds (lower is better, and note that the 'confs' test has a stochastic element and hence the times can vary by ~5% between runs). CPU Flags Code 'Clique' 'Simplex' 'Confs' Opteron -xW Original 15.6 54.4 92.2 Opteron -axW Original 26.7 123.4 114.2 Opteron -xW Patched 14.8 49.1 96.5 Opteron -axW Patched 15.1 49.7 91.4 P4 -xW Origina 25.7 78.4 171.2 P4 -axW Origin 26.3 79.7 171.2 P4 -xW Patched 25.8 78.9 172.6 P4 -axW Patched 26.4 78.1 169.9 The results for all unit tests of the software were identical between the original and patched versions. As can be seen, patching out the 'GenuineIntel' check makes no difference to the P4, but increases the performance of the Opteron by up to 10%. If the code was compiled with '-axW', then the Opteron really suffers: the 'Simplex' test is more than two times slower (it uses lots of exp() calls, and hence really benefits from vectorisation). Preso da http://www.swallowtail.org/naughty-intel.shtml li si legge bene la tabella. Sarebbe bello se hwupgrade si muoverebbe come testata a fare qualche test con i loro mezzi |
ragazzi è una caxxta questo programma?
http://www.softpedia.com/get/Program...-Patcher.shtml |
Quote:
Mo' guardo subito cosa dovrebbe fare, ma sembra promettente. edit: si, dal readme sembra decisamente promettente! Speriamo solo che non abbiano cambiato il modo in cui il compilatore fa i controlli negli eseguibili. |
Quote:
"Intel Compiler Patcher scans your hard drive for executable files compiled with the Intel C++ Compiler making it possible to disable the CPU dispatcher in detected files, thus, increasing performance of the software that uses these files with CPUs other than Intel. Give Intel Compiler Patcher a try to see what it's really capable of!" la prima cosa da fare è provare con i test sui quali si ha la certezza che avvengano disparità in termini di compilatore: - 3D mark - Cinebench |
non posso per ora provare se funziona perchè sono fuori col pentium-m, ma facendo uno scan per ora mi ha trovato silveright di ms
Found at pos: 000BBFC1 cmpl [ebp][-04],0756E6547 ;"Genu" Found at pos: 000BBFCA cmpl [ebp][-0C],049656E69 ;"Ieni" Found at pos: 000BBFD3 cmpl [ebp][-14],06C65746E ;"letn" |
Quote:
|
Quote:
Se funziona, facciamo partire immediatamente una segnalazione alla redazione per stimolare la scrittura di un articolo prova... Almeno per Cinebench... |
Quote:
Secondo il programma ci sono alcuni codec come il Dixv, alcuni dll di nero, praticamente tutta la cartella di PowerDVD 10. Naturalmente ha beccato subito i Cinebench 9.5/R10 e... PORCA TROTA!!!!! Ha beccato anche OpenSaurceMark V1 beta!!!:eek: :eek: :eek: :eek: |
Quote:
|
Quote:
|
Dal Readme:
La ricerca di file non è una replica coppie di registri - questo meglio essere spiegato in dettaglio. Di solito la procedura di controllo dei tipi di CPU nei compilatori Intel assume tre confrontare le istruzioni per verificare "Genu", "INEI", e "ntel" ogni essere nel registro della CPU stessa, ossia solo EAX o ecc EDX solo Tuttavia, ci sono eseguibili file per i quali il controllo sulla stringa venditore è fatto in diversi registri della CPU, per esempio: cmp eax, "Genu"; cmp ebx, "INEI"; edx cmp, "ntel" Tale algoritmo di confronto di solito è usato solo per l'identificazione della CPU e non dimostra che il programma controllata è stato compilato con il compilatore Intel. D'altra parte, il confronto di base del dispatcher Intel CPU (confronto con i registri della CPU stessa) può andare prima e in seguito alla fine non ci può essere il controllo di tipo CPU, inserita da uno sviluppatore. Per impostazione predefinita questo parametro è disabilitato. Non è raccomandato per consentire, se non sei completamente sicuro di quello che stai facendo. Tradotto con Google Traduttore Questo programma vede, se non ho capito male, se i programmi hanno una funzione per riconoscere le cpu e non se hanno la modalità per penalizzare le cpu non intel |
Allora ho fatto un test con cinebench r10 64 bit, ed effettivamente mi ha cambiato il risultato!! Solo che con l'eseguibile patchato le prestazioni sono calate di un buon 20%, sono passato da 3700 CB-CPU a 2900 CB-CPU.
Ma, perchè c'è una "ma", il mio è un Turion ZM-80 basato su unità esecutive K8, e i K8 con le SSE3 hanno sempre avuto brutte prestazioni. Bisognerebbe provare innanzitutto su un Intel, per vedere se il programma fa' si che venga eseguito il code path più lento in ogni caso, ed anche su un K10 per vedere se c'è un miglioramento o un peggioramento. edit: un altra cosa, per quanto riguarda cinebench è necessario includere anche un'altra estensione di file (mi pare cbl) e patchare anche quelli. Potete dare un'occhiata allo screenshot fornito nel programma . |
Quote:
|
Quote:
|
Tutti gli orari sono GMT +1. Ora sono le: 02:22. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Hardware Upgrade S.r.l.