VB6 benchmark

[Elfshadow]

My friend who is a VB6 programmer is doing a benchmark against C
and the VB is running faster than the C but we know this isn't a reliable benchmark

Could you look at our benchmarks and tell us any thing that might be causing this.
MINGW

#include <stdio.h>
#include <time.h>

int main ()
{
  clock_t startt;
  int test;
  //int startt;
  int cur;
  test = 0;
  cur = 0;
  
  startt = clock();
  while(cur < 1000)
  {
      test = test + 1;
      cur = clock() - startt; 
  }
  printf (" %d loops in 1 second \n", test / 1000000);
  getchar();
 
  return 0;
}

VB6

Public Declare Function GetTickCount Lib "kernel32" () As Long

Public Sub Main()
Dim i As Long
Dim cur As Long
Dim start As Long
start = GetTickCount
i = 0
Do While cur < 1000
i = i + 1
cur = GetTickCount - start
Loop
MsgBox i / 1000000
'divide it by 1 million so we
'get a readable number
End Sub

PS he says the VB is running in module without a fourm in the project.

[Salem]

> startt = clock();
The first suggestion would be to use the same API in both programs. #include <windows.h> and unsigned long start = GetTickCount(); for example.

> MINGW
The second suggestion is to use a native compiler, not one which has a bloated compatibility layer to make it more Unix-like.

[TkTkorrovi]

> MINGW
The second suggestion is to use a native compiler, not one which has a bloated compatibility layer to make it more Unix-like.

I see that we can never agree, and i have already an experience that it makes no sense to argue, because there would be no rational explanations. By you, visual basic is then much better than c, because not only the compiler, but all the language, is made only for one operating system.

Yes it's right that compatibility layer may make certain system functions slower, on the same reason it may make all programs in a certain language slower, though this compatibility layer is very thin, and there should not be a big difference. But concerning that test, this is not a right way to benchmark a programming language. The benchmarking loop should not contain the system functions necessary for benchmarking. Instead, the program should go through some fixed number of iterations, which preferrably contain many different operations, and the time spent for running that loop should be measured. Then the benchmark would show more the speed of the programming language, and not the speed of the system functions.

[Salem]

If you want to argue that x is better than y based on one completely unrepresentative test, knock yourself out. I never made such a statement, and I can't see how you can infer that I did.

Whilst VB may be joined at the hip to the OS, C certainly isn't. Picking and choosing your C implementation to fit your prejudice doesn't wash.

But you're right that any benchmark should avoid any API calls as a means of attempting to compare the languages.

[Ancient Dragon]

The posted code is not really much of a benchmark program and will not adequately make the test you want with it because the programs are just too trivial.