Benchmark test - VB6/VC6/Delphi6/Java

[Nullware]

I have an emachines running a Pentium IV @ 1.99 GHz (not overclocked, not dual core) with 384 MB RAM. Given that, my computer should be a lot slower than yours.

I tried VC++ 2008 Express and I'm getting slightly better times but still slower than you, probably because of all the processes running the school has setup on this laptop.

k, and whats the difference between GetSystemTime and GetTicketCount?

I assume that since he mentioned it, it probably takes less resources and would thus take far less time.

 

[BrianTokyo]

Interesting stuff, I love trying out different methods etc to test speed.

I took a 10.000 sample for a more accurate result
Delphi2007/Vista/X2 6000+

200-250 ms

program Project2;

{$APPTYPE CONSOLE}

uses
  Windows;
var
i,j,start,endtime:Longint;
data: array[1..10000] of Byte;
procedure CvtInt;
asm
        OR      CL,CL
        JNZ     @CvtLoop
@C1:    OR      EAX,EAX
        JNS     @C2
        NEG     EAX
        CALL    @C2
        MOV     AL,'-'
        INC     ECX
        DEC     ESI
        MOV     [ESI],AL
        RET
@C2:    MOV     ECX,10

@CvtLoop:
        PUSH    EDX
        PUSH    ESI
@D1:    XOR     EDX,EDX
        DIV     ECX
        DEC     ESI
        ADD     DL,'0'
        CMP     DL,'0'+10
        JB      @D2
        ADD     DL,('A'-'0')-10
@D2:    MOV     [ESI],DL
        OR      EAX,EAX
        JNE     @D1
        POP     ECX
        POP     EDX
        SUB     ECX,ESI
        SUB     EDX,ECX
        JBE     @D5
        ADD     ECX,EDX
        MOV     AL,'0'
        SUB     ESI,EDX
        JMP     @z
@zloop: MOV     [ESI+EDX],AL
@z:     DEC     EDX
        JNZ     @zloop
        MOV     [ESI],AL
@D5:
end;
function IntToStr(Value: Integer): string;
asm
        PUSH    ESI
        MOV     ESI, ESP
        SUB     ESP, 16
        XOR     ECX, ECX       // base: 0 for signed decimal
        PUSH    EDX            // result ptr
        XOR     EDX, EDX       // zero filled field width: 0 for no leading zeros
        CALL    CvtInt
        MOV     EDX, ESI
        POP     EAX            // result ptr
        CALL    System.@LStrFromPCharLen
        ADD     ESP, 16
        POP     ESI
end;
begin
  start := GetTickCount();
  for i := 1 to 1000 do
  begin
        for j := 1 to 10000 do
        begin
                data[j] := Random(32767) mod 100;
        end;
  end;
  endtime := GetTickCount();
  WriteLn('That took ' + IntToStr(endtime-start) + ' milliseconds to finish.');
  sleep(1000);
end.

 

[Govind]

Nice work on writing your own int/str conversion functions, though I barely understand ASM

 

[BrianTokyo]

lol I didn't write them, just copied them over from SysUtils so I don't need to include the whole unit (smaller exe)

 

[Govind]

Oh, I see.

 

[BrianTokyo]

im still leet though

 

[Govind]

Pssh. Whatever.

 

[BrianTokyo]

I was quite shocked to see C# do so well btw, didn't expect that crap to be so close to c/delphi

 

[Govind]

Well clock speed varies, but the ratio between speeds of different languages will probably be identical (or close to identical) from computer to computer.

 

[Covey]

Honestly, this thread has been the most productive programming thread in a long time.

Just thought i'd add that random note.

 

[Larry]

Thank you for the efforts, still I think there something i cannot agree with:
1- The random thing, it would have been better to fill a random array first then test the transfer, as in the case you posted, the full benchmark is about testing the "rnd" function (which differs from implementation to another, and which is rarely a perf issue so none of the implementors looks forward optimizing it).
2- the timings are very very small, i think that upping the number of times you fill the array with a bigger array should bring the timings into more interpretable results like in seconds, timings in milliseconds cannot be used in benchmarks since the precision is already around 4 ms (so that's over 50% of imprecision in some cases ! ), and to show this easily, try reducing the number of elements and you can end up with negative benchmarks (ie the tests looks finishing before starting , and this is really hilarious).

I hope you see the logic behind what i wrote, and hope not getting flamed much !

 

[BrianTokyo]

That's why I upped the iteration x10, as we saw in the other tests the results were mostly 16 OR 31, not something in between, so it's clear the precission in ms by using gettickcount isn't very good. I often try to at least take samples of 5-10 seconds running several thousands of iterations until an acceptable timing when I test different methods for speed.

 

[Govind]

The only problem is that arrays that are 10000 elements long are too large for VB6.

 

[Covey]

The only problem is that arrays that are 10000 elements long are too large for VB6.

Use a "Long" instead of an "Integer" & it will be fine.

 

[Govind]

Sure, I"ll repost a better one later.

 

[BrianTokyo]

Here's a much better way than using GetTickCount (whose resolution is limited to min. ~17-20 ms)

var PF, PC0, PC1: Int64;
    i,j:Longint;
    data: array[1..10000] of Byte;


 QueryPerformanceFrequency(PF);
 QueryPerformanceCounter(PC0);
 for i := 1 to 10000 do
  for j := 1 to 1000 do
   data[j] := Random(32767) mod 100;
 QueryPerformanceCounter(PC1);
 ShowMessage(IntToStr(((PC1-PC0)*1000) div PF));