|
|
 |
|
Redefining Speed (A look at In-House render tests) Added on: Fri May 17 2002 |
| Page: 1 2 3 4 5 6 7 |
Technology is evil. It lies, it cheats, it steals, and it punches below the belt. Try to race against it, and you'll lose every time.
Throw a punch, and it'll come back with an army of blistering price cuts, to tear you a new one. Technology is the badass mo-fo standing on the cliff edge, with your woman/man in its arms, shouting to the entire world "Who wants some?"
So what can you possible do to the unstoppable might, which is technology? Attacking it just encourages it. There is only one recourse...Take it apart,micron by micron, until it can be picked over no more, and becomes...your bitch. This is the desire of each and every hardware nut, geek, and nerd.
To fully analyze each piece of technology, to fully understand its potential, and to know, at any given moment in time, how much faster your computer is then your friends. This is what we are setting out to do today, as 3dluvr expands its benchmarking suite, to include more in depth render tests, and to fully comprehend, the might, the power, the beast, which is...technology.
The speed of machines has increased dramatically in the past few months requiring more expansive tests to categorize performance.
Originally 3dluvr set out to create a series of 3dsmax benchmarks, which were easily reproducible by the average max user.
All and all this was quite successful, gathering an enormous amount of data, and providing a general overview of Max system performance.
However over time a few jarring issues became apparent.
The Problems
Some of the user submitted results were off, really off. One gentleman submitted a 1.5 Gigahertz P4 system, which outperformed a Dual 2.4 Xeon.
Interesting. Must have been in some sort of time warp or multidimensional portal. Weird and estranged results poured in, and I had to start randomly verifying a variety of systems, to see which ones were correct, and which ones were�padded for the users pleasure. This takes additional time, and the amount of benchmarks growing on the website slowed down substantially. This gave me some time to look over the benchmarks and take a closer look at the results they were recording�
The second major problem was the tests were biased towards single processor systems. The main test, islands.max is over 60% single threaded (Unable to make use of the second CPU). Because of the time spent on this benchmark at film resolution, it threw the entire set of nine benchmarks to a single threaded bias.
|
 |
|
|
