Visual Basic Code...?

Hi all. I am making a CPU benchmark program in Visual basic Express 2010. I have everything I need except the actual STRESS TEST. :D Heres a BASIC look at what i'm thinking i'm going to need.

Private Function StressTest() As Integer
    'Complex math that will STRESS the CPU a lot
    math.math.math............................
    math math math.................
    'Complex math that will STRESS the CPU a lot
    return time-taken-to-run-test-in-mili-seconds
End Function

Please help me make this! I am SOOOOOO Close! All I need is to know how long the thing took, and the actual math that puts STRESS on the CPU!!! PLEASE HELP ME OUT!!! IT WOULD MAKE A 12 YEAR OLD'S DREAMS COME TRUE!!! THANKS!
    

sort by: active | newest | oldest
Ziviz6 years ago
Alternatively, you can use the System.Diagnostics.Stopwatch.

Example (based off of MSDN example)

Dim stopWatch As New Stopwatch()
stopWatch.Start()
/* Some code to time */
stopWatch.Stop()
Dim ts As TimeSpan = stopWatch.Elapsed

I have used the same class to time a render loop in C#. It proved very accurate.
orksecurity6 years ago
Capture the current system time down to the millisecond (or whatever accuracy your system will support). Run your testcase. Capture the current time again. Compute the difference between the two times and return that.

As far as what to use as your testcase: There's no simple answer. Different computations/operations/loops/whatever will test different parts of the system, and system performance really can't be reduced to a single number. The best answer is to run something as similar as possible to the critical section of whatever program(s) matter(s) most to you, since those are the ones which you really care about... but that may say very little about the performance of the programs your friends care most about.

Proper benchmarking is a field of study in itself, requiring an understanding of both computer architectures and of what operations matter most to a particular group of customers. For the compiler I'm working on, we use about 50 different benchmark loops -- some arbitary "this might be interesting" kernels, some derived from real-world customer examples. The latter are far more meaningful and useful; the microkernels are mostly useful for probing why the real-world code might not be doing as well as we would like it to.
sci4me (author)  orksecurity6 years ago
so.. how can i capture the time? lol... i knew all that stuff. :d
Read The Fine Manual. That's what it's for.
sci4me (author)  orksecurity6 years ago
ok.. i looked up lol. :D Heres wut i got so far:

Private Function StressTest() As Integer
Dim BeginTime As Date
Dim FinishTime As Date
Dim ElapsedTime As Long
BeginTime = Now

'Calculation

'Calculation

FinishTime = Now
ElapsedTime = DateDiff("s", BeginTime, FinishTime)
Return ElapsedTime
End Function

I just need the calculation part...
As I said, there are a near-infinite set of possible benchmarks to measure, depending on what aspect of the system's performance (and of Visual Basic's compilation efficiency, which will of course be inextricably entwined in the results) you're interested in. There is no single obvious answer.

Either do some research to look at what benchmarks have been used in the past, or figure out what operations matter to you and how to exercise them.

NOTE: To do this properly, you need to make sure that the Visual Basic compiler doesn't optimize away large portions of your test. Which means you're going to have to understand VB's code generation, and possibly look at the generated code at the assembler level to make sure it's actually doing what you think it's doing. Unless, as I said, the thing being tested is a portion of the actual VB program you're interested in, in which case it would presumably be optimized the same way in your own program as here.

It's easy to write a bad benchmark. It's harder to write one that's meaningful.

To give you an example of just how hard it can be to write a good test: Back in the early days of PCs, one of the standard benchmarks with the Sieve of Eratosthenes, which is a simple routine for computing prime numbers. It was a good test only until compiler developers started writing optimization hacks which specifically recognized this routine and swapped in a hand-coded, extremely optimized assembler version -- at which point the Sieve's performance stopped being a meaningful representation of how well the compiler, and computer, would handle anything else. And of course the Sieve only exercised a few aspects of the processor -- simple loops and integer math -- and thus told us very little about how other programs would run. It was useful back when computers and language implementations were primitive, but it has essentially outlived its usefulness now. The same is true of most of the simple ("microkernel") tests -- to take a more modern example, even a test which does a good job of exercising the CPU may tell you nothing about the performance of the graphics coprocessor, and for some tasks (games in particular) graphics speed may matter more than main processor speed.

Websearching for information about benchmarks will find many past attempts, and a lot of discussion of what's good and bad about them. If you're really interested in this topic, there's a lot of interesting reading out there.
VB ? Optimise ?
No reason it couldn't. Whether it *does* or not, I don't know and don't care since I don't go near it.