I believe my post stands accurately for itself.
The first line in the second paragraph qualifies my first paragraph by beginning with, "The real problem for general application software". That's about as far as I will go as the comments were never intended for "other" applications, which were covered later in the post.
As for Image rendering, I believe I covered that issue, as does Tom's hardware by now including MPEG4 benchmarks.
As for large RDBMS testing, I would agree that this doesn't fit into the general office application arena. However, I believe anyone with common sense realizes that anyway.
As most RDBMS software is client/server, there are many more issues that are affected past than workstation configuration. Primarily the configuration and specifics of the deployment of the software on the server, it's use of Index buffers, cache buffers and RAID on the SERVER (not client), and too many other issues to list here.
As for the client side, I would agree that specifications should be beefier than a standard workstation; however, for any of these configurations you wouldn't be using ANY of the normal consumer configurations offered by most of Tom's reviews. You have to keep in mind what the largest audience is looking for, and it isn't a solution for crunching their 2Gig Oracle or Sybase RDBMS.
For these needs, you must automatically assume that the user would always be using Registered DIMMs and NOT unbuffered DIMMs. Secondly, serious CAD, MPEG4 and large RDBMS users should always be using SCSI drives and NOT IDE as this technology will provide better performance in LEAPS AND BOUNDS and as time is measured as the primary concern, the cost of these devices is always assumed in the purchase. Just ask anyone that does graphic design or CAD for a living and they'll tell you that they don't care that SCSI costs 3 times more, they spend that money because THEY MUST have the performance gains that it offers. TIME IS MONEY to them.
It should also be obvious to anyone with a 1gig+ Microsoft Access database that the 800/133 cap that I mentioned isn’t the best you could get; however, the 'general' user community doesn't have that scenario and therefor my comments would be accurate. They again, should find the existing benchmarks more than suitable.
Finally, I wouldn't assume (as you did) that gaming doesn't use databases. I think you'll find there are hundreds of programmers spending thousands of hour’s hunched over their keyboards writing number crunching db's that run those games. While the code may look different, you have to remember that every time you choose to turn right instead of left in Doom, you are enacting "If/Then" actions and there is some serious math going on in there. It's not all graphics, but even in that field there are major calculations being performed, not just some artists free hand drawing being sent up to your screen. Thus, again as mentioned, these benchmarks are VERY useful for measuring how the system will perform compared to other systems (including the one that the user has on his or her desk now!)
Again, I would qualify all of my remarks by stating that it appears as though the benchmarks used by Tom's Hardware are targeted toward the largest audience, which is general consumers. Specific application requirements (let's say for a 10Gig Oracle DB) should be addressed by satisfying the needs on a component by component basis as this is the only accurate way to satisfy the needs of that specific scenario. In other words, if you have a beefy DB requirement, you shouldn't even be wasting your time reading Tom's Review of a KT133 chipset with a 45 Gig IDE drive and 128MB of PC133 Crucial RAM.
I mean let’s talk common sense here. You guys have to take (and make) these posts using some HONEST common sense and be more practical. For Tom to satisfy every person that came to him and said, “I have this ‘xyz’ requirement and your benchmarks don’t cover that” would result in his benchmark section being 100 pages long and the testing would take him 200 more hours than he already spends. (Which is already a heck of a lot more than most!) This just isn’t realistic to ask, nor practical or realistically feasible to deliver. If you have a suggestion for a SPECIFIC standardized benchmark that accurately represents a clear picture of a vertical market to a large audience, I would suggest that you show it’s benefits to Tom in an email and maybe, just maybe (like us) he would include it in future testing.
Steve Benoit
Stable Technologies
'The way IT should be!'