As an industry, we are obsessed with benchmarking, almost to a fault.
Tutorial Details:
Projects regularly allocate significant chunks of time executing vendor "beauty contests" for hardware and software(application servers, JDKs, IDEs). In my opinion, we do this for three main reasons:
* The landscape changes so often that assertions we hold to be self-evident need to be revalidated about every 18 months.
* It can never be too fast. If I cut corners on application code, having fast hardware is an insurance policy to help meet performance or scalability service-level agreements that the nice salesman promised the customer, including the service credit clawback clause.
* We like doing it, especially when it means getting a new kit to test for free.
With the current proliferation of ever-more parallelized hardware, benchmarking is a hot topic again. In Part 1 of this article, I detailed the basic precepts behind parallel hardware. In Part 2, I want to move on and examine how to measure how effectively this hardware has been crystallized. This is a process fraught with difficulty—benchmarks, by their nature, are more often pilloried for what they don't measure, or what they measure inaccurately, than lauded for their impartiality. My benchmark will suffer the same fate. Nonetheless, after reading this article, you will see how I designed and implemented the framework, what I believe it measures (and doesn't), and its potential uses.
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Is your code ready for the next wave in commodity computing?
View Tutorial: Is your code ready for the next wave in commodity computing?
Related
Tutorials:
|
Integrating Databases