illidan
- Bike Camper -
- Učlanjen(a)
- 02.02.2005
- Poruke
- 24,088
- Poena
- 2,605
Moja oprema
- CPU & Cooler
- amd 5800x3d, cm atmos 240 - phanteks t30
- Matična ploča
- asus rog strix b550-i gaming
- RAM
- g.skill trident z neo 32gb cl16 3600
- GPU
- nvidia rtx 4070super founders edition
- Storage
- samsung 980 pro 1tb, wd black sn770 2tb
- Zvuk
- ifi zen dac v2 - fosi audio za3 - kef q350, fiio ft1, all balanced
- PSU
- corsair sf750 platinum
- Kućište
- lian li a4 h2o
- Monitor
- gigabyte mo27q28g
- Miš & tastatura
- lamzu atlantis mini, kbd.fans tofu65 raw alu - cream soda switches - gmk serika 2 keycaps
- Pristup internetu
- Optički internet
Probajte novi benchmark sa adrese: http://www.sciencemark.org/frame.php?frame=01
Momci sa xtreme systema kazu da je jedan od najboljih benchmark testova.
"ScienceMark 2.0 has a benchmark included called "MemBench" which tests many different algorithms of copying integer data from one stream or vector (called "x" for instance) to another stream or vector (called "y" for instance). Memory latency and bandwidth are definitely important to programmers, however they are typically not the limiting factor in code performance. When people build a code to perform a preconceived function, thought must be given as to "how" they intend to achieve the goal at hand. This means taking into consideration access patterns to memory, how to minimize or localize these accesses through construction of the storage structures, and maybe even making algorithm changes that increase the fpu or alu computation in exchange for lessening memory consumption. The later tactic seems contrary to increasing code performance, however considering the great disparaging difference in the CPU clock speed vs. that of the memory bus, it often nets a sizeable increase in performance.
We do not purport that memory latency and bandwidth are not important, it is. However, we as authors of ScienceMark 2.0 believe in it's efficient use which isn't the case in a wide array of benchmarks today. Poorly written programs which give little thought as to code performance as they are constructed are simply not acceptable benchmarks. They are wasteful and do not reflect a platform's capacity to perform. Additionally, many of the commonly quoted benchmarks have been optimized to some degree with assembly coding so as to increase performance for a targeted platform. The assembly used in these benchmarks is not publicly available. The optimizations may only enable maximum performance on one cpu vendor's processor and not another's even though their processor's architecture has similar optimizations. In these circumstances the user does not know if the "ruler", or measure of a benchmark, is a true "unbiased" measure or or crooked one. Consequently, unless a benchmark is (i) well written to achieve maximum perfromance from an algorithm standpoint without the use of assembly and (ii) documents the use of assembly for the general public it is not a viable ruler upon which to measure code performance.
ScienceMark 2.0 is different from other benchmarks, in the sense that (i) we test a series of different memory bandwidth algorithms, and allow the platform to choose that which suits it best and (ii) the assembly source for these copy routines is available on line, to assure the community that we are not biased towards any one platform in particular. We as authors of ScienceMark 2.0 provide the assembly source to you to assure that our tests are "truly" unbiased, and give all platforms an equal opportunity to achieve maximum performance without handicapping others.
These copy functions are provided below in their entirety and should be self explanatory. Again, the authors of ScienceMark 2.0 not only want to provide you a "truthful" memory bandwidth benchmark, we also want the others to learn from the assembly provided. Consequently, we have documented the routines thoroughly, we only wish other benchmarks on the internet did the same or were as truthful."
http://www.sciencemark.org/download/ScienceMark07FEB05EXECUTABLE.zip
Sada sam ga skinuo pa cu da ga pokrenem i vidim rezultate.
Momci sa xtreme systema kazu da je jedan od najboljih benchmark testova.
"ScienceMark 2.0 has a benchmark included called "MemBench" which tests many different algorithms of copying integer data from one stream or vector (called "x" for instance) to another stream or vector (called "y" for instance). Memory latency and bandwidth are definitely important to programmers, however they are typically not the limiting factor in code performance. When people build a code to perform a preconceived function, thought must be given as to "how" they intend to achieve the goal at hand. This means taking into consideration access patterns to memory, how to minimize or localize these accesses through construction of the storage structures, and maybe even making algorithm changes that increase the fpu or alu computation in exchange for lessening memory consumption. The later tactic seems contrary to increasing code performance, however considering the great disparaging difference in the CPU clock speed vs. that of the memory bus, it often nets a sizeable increase in performance.
We do not purport that memory latency and bandwidth are not important, it is. However, we as authors of ScienceMark 2.0 believe in it's efficient use which isn't the case in a wide array of benchmarks today. Poorly written programs which give little thought as to code performance as they are constructed are simply not acceptable benchmarks. They are wasteful and do not reflect a platform's capacity to perform. Additionally, many of the commonly quoted benchmarks have been optimized to some degree with assembly coding so as to increase performance for a targeted platform. The assembly used in these benchmarks is not publicly available. The optimizations may only enable maximum performance on one cpu vendor's processor and not another's even though their processor's architecture has similar optimizations. In these circumstances the user does not know if the "ruler", or measure of a benchmark, is a true "unbiased" measure or or crooked one. Consequently, unless a benchmark is (i) well written to achieve maximum perfromance from an algorithm standpoint without the use of assembly and (ii) documents the use of assembly for the general public it is not a viable ruler upon which to measure code performance.
ScienceMark 2.0 is different from other benchmarks, in the sense that (i) we test a series of different memory bandwidth algorithms, and allow the platform to choose that which suits it best and (ii) the assembly source for these copy routines is available on line, to assure the community that we are not biased towards any one platform in particular. We as authors of ScienceMark 2.0 provide the assembly source to you to assure that our tests are "truly" unbiased, and give all platforms an equal opportunity to achieve maximum performance without handicapping others.
These copy functions are provided below in their entirety and should be self explanatory. Again, the authors of ScienceMark 2.0 not only want to provide you a "truthful" memory bandwidth benchmark, we also want the others to learn from the assembly provided. Consequently, we have documented the routines thoroughly, we only wish other benchmarks on the internet did the same or were as truthful."
http://www.sciencemark.org/download/ScienceMark07FEB05EXECUTABLE.zip
Sada sam ga skinuo pa cu da ga pokrenem i vidim rezultate.
Poslednja izmena: