Announcement

**Chris Boss** · 27 Sep 2000, 09:12 PM

Here is the benchmark code :

First a DDT app with the Benchmark code !

Code:

' *************************************************************
'       Code Generated by EZGUI Freeware Dialog Designer
' *************************************************************

#COMPILE EXE
#REGISTER NONE
#DEBUG ERROR OFF
#DIM ALL          '  This is helpful to prevent errors in coding


#INCLUDE "win32api.inc"   ' Must come first before other include files !

' *************************************************************

DECLARE FUNCTION BMarkProc1(BYVAL N1&, BYVAL N2&) AS SINGLE
DECLARE FUNCTION BMarkProc2(BYVAL N1&, BYVAL N2&) AS SINGLE

' *************************************************************
'              Application Constants and Declares
' *************************************************************

%FORM1_COMMAND1           = 100
%FORM1_TEXT1              = 105

' --------------------------------------------------
DECLARE SUB ShowDialog_Form1(BYVAL hParent&)
DECLARE CALLBACK FUNCTION Form1_DLGPROC
' --------------------------------------------------
' ------------------------------------------------

DECLARE CALLBACK FUNCTION CBF_FORM1_COMMAND1()
DECLARE CALLBACK FUNCTION CBF_FORM1_TEXT1()


' *************************************************************
'            Application Global Variables and Types
' *************************************************************

GLOBAL hForm1&    ' Dialog handle


' *************************************************************
'                    Application Entrance
' *************************************************************

FUNCTION PBMAIN
    LOCAL Count&

    ShowDialog_Form1 0
    DO
        DIALOG DOEVENTS TO Count&
    LOOP UNTIL Count&=0

END FUNCTION


' *************************************************************
'                    Application Dialogs
' *************************************************************

SUB ShowDialog_Form1(BYVAL hParent&)
    LOCAL Style&, ExStyle&
    LOCAL N&, CT&        '  Variables used for Reading Data in Arrays for Listbox and Combobox
    '   hParent& = 0 if no parent Dialog
    Style& = %WS_POPUP OR %DS_MODALFRAME OR %WS_CAPTION OR %WS_MINIMIZEBOX OR %WS_SYSMENU OR %DS_CENTER
    ExStyle& = 0
    DIALOG NEW hParent&, "PowerBasic Benchmarks", 0, 0,  331,  128, Style&, ExStyle& TO hForm1&
    CONTROL ADD "Button", hForm1&,  %FORM1_COMMAND1,  "Run Benchmarks", 9, 13, 99, 18, _
        %WS_CHILD OR %WS_VISIBLE OR %BS_PUSHBUTTON OR %WS_TABSTOP CALL CBF_FORM1_COMMAND1
    CONTROL ADD TEXTBOX, hForm1&,  %FORM1_TEXT1,  "", 121, 13, 206, 108, _
        %WS_CHILD OR %WS_VISIBLE OR %ES_MULTILINE OR %ES_WANTRETURN OR %ES_LEFT OR %ES_AUTOVSCROLL OR %WS_VSCROLL , _
        %WS_EX_CLIENTEDGE CALL CBF_FORM1_TEXT1
    DIALOG SHOW MODELESS hForm1& , CALL Form1_DLGPROC
END SUB

' *************************************************************
'                             Dialog Callback Procedure
'                             for Form Form1
'                             uses Global Handle - hForm1&
' *************************************************************

CALLBACK FUNCTION Form1_DLGPROC
    SELECT CASE CBMSG
        CASE ELSE
    END SELECT
END FUNCTION


' *************************************************************
'  Application Callback Functions (or Procedures) for Controls
' *************************************************************

' ------------------------------------------------
CALLBACK FUNCTION CBF_FORM1_COMMAND1
LOCAL D$, CT!
    IF CBCTLMSG=%BN_CLICKED THEN
        CONTROL DISABLE hForm1&, %FORM1_COMMAND1
        DIALOG DOEVENTS

        D$=CHR$(13) + CHR$(10) + "Benchmark 1 :" + CHR$(13) + CHR$(10) + STRING$(30, "-") + CHR$(13) + CHR$(10)

        CT!=BMarkProc1(1, 400)

        D$=D$+ STR$(CT!) + " Seconds" + CHR$(13) + CHR$(10)
        D$=D$+ CHR$(13) + CHR$(10) + "Benchmark 2 :" + CHR$(13) + CHR$(10) + STRING$(30, "-") + CHR$(13) + CHR$(10)

        CT!=BMarkProc2(1, 105)

        D$=D$+ STR$(CT!) + " Seconds" + CHR$(13) + CHR$(10)
        CONTROL SET TEXT hForm1&, %FORM1_TEXT1, D$
        CONTROL ENABLE hForm1&, %FORM1_COMMAND1
    END IF
END FUNCTION
' ------------------------------------------------

' ------------------------------------------------
CALLBACK FUNCTION CBF_FORM1_TEXT1
    IF CBCTLMSG=%EN_CHANGE THEN

    END IF
    IF CBCTLMSG=%EN_SETFOCUS THEN

    END IF
    IF CBCTLMSG=%EN_KILLFOCUS THEN

    END IF
END FUNCTION

' ------------------------------------------------

FUNCTION BMarkProc1(BYVAL N1&, BYVAL N2&) AS SINGLE
LOCAL CT!, X&, Y&, Z&, A#, B#
        CT! = TIMER
        FOR X& = N1& TO N2& STEP 2
            Z&=0
            FOR Y&=N1& TO X& STEP 3
                Z& = Z& + (Y& + 1) + (X& - 3) - (Y& * 5) + (X& * 7)
                B#=0
                FOR A# = N1& TO X& STEP 1.5
                    B# = B# + COS(A# + 1.01) + TAN(A# + 2.02) + SIN(A# + 3.03)
                NEXT A#
            NEXT Y&
        NEXT X&
        FUNCTION=TIMER-CT!
END FUNCTION

' ------------------------------------------------

FUNCTION BMarkProc2(BYVAL N1&, BYVAL N2&) AS SINGLE
LOCAL CT!, X&, Y&, Z&, D$, V$
        CT! = TIMER
        V$=""
        FOR X& = N1& TO N2& STEP 2
            Z&=0
            FOR Y&=N1& TO X& STEP 3
                Z& = Z& + (Y& + 1) + (X& - 3) - (Y& * 5) + (X& * 7)
                D$ = "AB DEFG"
                D$ = STRING$(10, MID$(D$, 3, 1)) + STRING$(50, "x") + STRING$(10, MID$(D$, 3, 1))
                V$ = V$ + D$
                D$ = LTRIM$(RTRIM$(STR$(Z&)))
                D$ = D$ + D$ + D$ + D$ + D$ + D$ + D$
                V$ = V$ + MID$(D$, 10, 20) + MID$(D$, 10, 20) + MID$(D$, 10, 20) + MID$(D$, 10, 20)
            NEXT Y&
        NEXT X&
        FUNCTION=TIMER-CT!
END FUNCTION

' ------------------------------------------------

------------------

**Chris Boss** · 27 Sep 2000, 09:14 PM

Now the VB version of the Benchmark:

(This is the code in FORM1 file for the app)

Code:

VERSION 5.00
Begin VB.Form Form1 
   Caption         =   "BenchMark - VB version"
   ClientHeight    =   3150
   ClientLeft      =   60
   ClientTop       =   345
   ClientWidth     =   7485
   LinkTopic       =   "Form1"
   ScaleHeight     =   3150
   ScaleWidth      =   7485
   StartUpPosition =   3  'Windows Default
   Begin VB.CommandButton Command1 
      Caption         =   "Test 1 - Simple"
      Height          =   435
      LEFT            =   210
      TabIndex        =   1
      Top             =   315
      Width           =   2220
   END
   Begin VB.TextBox Text1 
      Height          =   2640
      LEFT            =   2730
      MultiLine       =   -1  'True
      TabIndex        =   0
      Top             =   315
      Width           =   4635
   END
END
Attribute VB_Name = "Form1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False
FUNCTION BMarkProc1(BYVAL N1&, BYVAL N2&) AS SINGLE
        CT! = TIMER
        FOR X& = N1& TO N2& STEP 2
            Z& = 0
            FOR Y& = N1& TO X& STEP 3
                Z& = Z& + (Y& + 1) + (X& - 3) - (Y& * 5) + (X& * 7)
                B# = 0
                FOR A# = N1& TO X& STEP 1.5
                    B# = B# + COS(A# + 1.01) + TAN(A# + 2.02) + SIN(A# + 3.03)
                NEXT A#
            NEXT Y&
        NEXT X&
        BMarkProc1 = TIMER - CT!
END FUNCTION

FUNCTION BMarkProc2(BYVAL N1&, BYVAL N2&) AS SINGLE
        CT! = TIMER
        V$ = ""
        FOR X& = N1& TO N2& STEP 2
            Z& = 0
            FOR Y& = N1& TO X& STEP 3
                Z& = Z& + (Y& + 1) + (X& - 3) - (Y& * 5) + (X& * 7)
                D$ = "AB DEFG"
                D$ = STRING$(10, MID$(D$, 3, 1)) + STRING$(50, "x") + STRING$(10, MID$(D$, 3, 1))
                V$ = V$ + D$
                D$ = LTRIM$(RTRIM$(STR$(Z&)))
                D$ = D$ + D$ + D$ + D$ + D$ + D$ + D$
                V$ = V$ + MID$(D$, 10, 20) + MID$(D$, 10, 20) + MID$(D$, 10, 20) + MID$(D$, 10, 20)
            NEXT Y&
        NEXT X&
        BMarkProc2 = TIMER - CT!
END FUNCTION
              

Private SUB Command1_Click()

        Command1.Enabled = False
        DOEVENTS

        D$ = CHR$(13) + CHR$(10) + "Benchmark 1 :" + CHR$(13) + CHR$(10) + STRING$(30, "-") + CHR$(13) + CHR$(10)

        CT! = BMarkProc1(1, 400)
        
        D$ = D$ + STR$(CT!) + " Seconds" + CHR$(13) + CHR$(10)
        D$ = D$ + CHR$(13) + CHR$(10) + "Benchmark 2 :" + CHR$(13) + CHR$(10) + STRING$(30, "-") + CHR$(13) + CHR$(10)

        CT! = BMarkProc2(1, 105)

        D$ = D$ + STR$(CT!) + " Seconds" + CHR$(13) + CHR$(10)
        Text1.Text = D$
        Command1.Enabled = True
END SUB

------------------

**Chris Boss** · 27 Sep 2000, 09:18 PM

Now if some of you who can program in C could convert the
two benchmark procedures into C and run the test with a C
compiler, this would be enlightening.

The key to the benchmark is that the functions must be called
with the same values in the parameters. The parameters are
embeded into the loops, so the compiler can't do a fudge factor.

The functions return the actual TIME spent in running the
benchmark as well.

------------------

**Chris Boss** · 27 Sep 2000, 09:25 PM

My "Theory" about PB versus other compilers may possibly
prove true.

When the code is relatively simple (simple nested loops)
many compilers (like C and VB) can do all sorts of tricks
to speed things up. The compilers are down right intelligent
and they use all sorts of "sneeky" tricks.

But when the code gets more and more complex, the compiler
can't "cheat" and find shortcuts !

The Benchmark code I wrote seems to prove that when push comes
to shove, the PB compiler may actually be faster than other
compilers or it at least can stand its own with the big boys.

I was personally impressed by the results above.

------------------

**Guest** · 28 Sep 2000, 03:45 AM

Chris, you might to hold off on the celebration.

Test 1 - VB = 13.500 Seconds (Timer)
Test 1 - C (LCC) = 5.548 Seconds (GetTickCount)

test 2 in work... (debugging exploding code)...

------------------
Ron

**Chris Boss** · 28 Sep 2000, 04:07 AM

While I personally am not concerned with C
(or other non-Basic languages), it is good to
get a good comparison between PB and other
languages.

Ron, your comparison was between VB (not PB) and C.
Did you forget to add the times for PB or is VB
suppose to be PB in your message ?

Also, Ron you used LCC and not MS VC++. Can someone test
The code on a Microsoft product ?

Also a conversion to Delphi would be nice.

My tests indicate PB beats VB when the test is fair
and thats the most important to me. I doubt I would every use
C or Delphi. On the other hand it would be nice to see how PB
stacks up to C.

Another issue not addressed is whether the code is "optimized"
for a particular chip (CPU).

------------------

**Mark Newman** · 28 Sep 2000, 05:07 AM

While waiting for the coffee to kick in...here's the results on
my system (Pentium 3/400, NT 4):

PB6
---
Bench 1 = 2.205 seconds
Bench 2 = 2.413 seconds

VB6 - No compiler optimizations
-------------------------------
Bench 1 = 3.004 seconds
Bench 2 = 5.228 seconds

VB6 - Full compiler optimizations
---------------------------------
Bench 1 = 2.003 seconds
Bench 2 = 5.301 seconds

The string handling in VB5/6 is a well-known pile of smelly
stuff; any serious app affected would use a DLL and not VB's
functions.

Interesting results on Bench 1.

------------------
Mark Newman

**Guest** · 28 Sep 2000, 05:11 AM

AMD - P6-233 mmx

C vs VB - I did not do PB.

C (LCC-Win32)
Benchmark 1 : 5.54800000 Seconds
Benchmark 2 : 4.90700000 Seconds

VB5 - No Optimization
Benchmark 1 :
------------------------------
5.979172 Seconds

Benchmark 2 :
------------------------------
17.75566 Seconds

VB5 - Optimized all the Way
Benchmark 1 :
------------------------------
3.345969 Seconds

Benchmark 2 :
------------------------------
18.10431 Seconds

------------------
Ron

**Chris Roebuck** · 28 Sep 2000, 07:36 AM

I just wanted to add my $.02. Since VB evaluates a variable on the
next statement, it needs to be eliminated. I don't now if PB has the
same type of evaluation scheme. Of course, since VB uses Unicode
strings, the results for the second benchmark with VB being about
twice as slow as PB makes sense. Anyway, here is my results on a
PIII/600 running Win2K:

VB6 No Compiler Options

Benchmark 1 :
------------------------------
2.434688 Seconds

Benchmark 2 :
------------------------------
7.251094 Seconds

VB6 with compiler options

Benchmark 1 :
------------------------------
1.663969 Seconds

Benchmark 2 :
------------------------------
7.009906 Seconds

PowerBasic Benchmark

Benchmark 1 :
------------------------------
1.780219 Seconds

Benchmark 2 :
------------------------------
3.413969 Seconds

Here is the VB code that I used (Note, I didn't make any changes to the
PB code):

VERSION 5.00
Begin VB.Form Form1
Caption = "Form1"
ClientHeight = 3000
ClientLeft = 1245
ClientTop = 1935
ClientWidth = 6585
LinkTopic = "Form1"
ScaleHeight = 3000
ScaleWidth = 6585
Begin VB.TextBox Text1
Height = 2010
Left = 240
MultiLine = -1 'True
ScrollBars = 2 'Vertical
TabIndex = 1
Top = 135
Width = 6030
End
Begin VB.CommandButton Command1
Caption = "Command1"
Height = 495
Left = 2595
TabIndex = 0
Top = 2400
Width = 1215
End
End
Attribute VB_Name = "Form1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False
Option Explicit

Private Sub Command1_Click()
Dim sgTime As Single
Dim D As String
Command1.Enabled = False
D = Chr$(13) + Chr$(10) + "Benchmark 1 :" + Chr$(13) + Chr$(10) + String$(30, "-") + Chr$(13) + Chr$(10)
sgTime = BMarkProc1(1, 400)

D = D + Str$(sgTime) + " Seconds" + Chr$(13) + Chr$(10)
D = D + Chr$(13) + Chr$(10) + "Benchmark 2 :" + Chr$(13) + Chr$(10) + String$(30, "-") + Chr$(13) + Chr$(10)
sgTime = BMarkProc2(1, 105)
D = D + Str$(sgTime) + " Seconds" + Chr$(13) + Chr$(10)
Text1.Text = D
Command1.Enabled = True
End Sub

Function BMarkProc1(ByVal N1 As Long, ByVal N2 As Long) As Single
Dim sgStart As Single
Dim Z As Long
Dim X As Long
Dim Y As Long
Dim A As Double
Dim B As Double
sgStart = Timer
For X = N1 To N2 Step 2
Z = 0
For Y = N1 To X Step 3
Z = Z + (Y + 1) + (X - 3) - (Y * 5) + (X * 7)
B = 0
For A = N1 To X Step 1.5
B = B + Cos(A + 1.01) + Tan(A + 2.02) + Sin(A + 3.03)
Next 'A#
Next 'Y&
Next 'X&
BMarkProc1 = Timer - sgStart
End Function

Function BMarkProc2(ByVal N1 As Long, ByVal N2 As Long) As Single
Dim sgStart As Single
Dim X As Long
Dim Y As Long
Dim Z As Long
Dim D As String
Dim V As String
sgStart = Timer
For X = N1 To N2 Step 2
Z = 0
For Y = N1 To X Step 3
Z = Z + (Y + 1) + (X - 3) - (Y * 5) + (X * 7)
D = "AB DEFG"
D = String$(10, Mid$(D$, 3, 1)) + String$(50, "x") + String$(10, Mid$(D$, 3, 1))
V = V + D
D = LTrim$(RTrim$(Str$(Z)))
D = D & D & D & D & D & D & D
V = V + Mid$(D, 10, 20) + Mid$(D, 10, 20) + Mid$(D, 10, 20) + Mid$(D, 10, 20)
Next 'Y&
Next 'X&
BMarkProc2 = Timer - sgStart
End Function

------------------

**Don Dickinson** · 28 Sep 2000, 10:05 AM

Chris, any reason you're using #register none in your pb code. This is the equivalent of turning off an optimization (though sometimes necessary) .
Best Regards,
Don

------------------

**Steve Hutchesson** · 28 Sep 2000, 02:43 PM

Compliments guys, this type of benchmarking is useful stuff for many who
are interested in seeing performance comparisons.

Don's point is a good one, unless you are using inline assembler, you
should leave the default compiler performance running unless you run into
some other problem.

I have one suggestion for both Chris and Ron in the timing tests, timers
are harware access and there is a chance that this will mess up the
introduction to the code being benchmarked, what I would suggest is
putting the timer code outside the procedures that are being benchmarked
to avoid any wander in the test times.

==========================================================
--- the C program - CAUTION - not a pretty site!!! ---
==========================================================

Ron, I thought it looked great, the more I see of LCC-32, the more I like
it. I currently keep Microsoft VC6 C compiler on my box for testing the
compatibility of library modules written in MASM, with PowerBASIC as my
main compiler, I can't find much use for Microsoft C these days.

Regards,

[email protected]

------------------

**Enoch S Ceshkovsky** · 28 Sep 2000, 02:55 PM

VB is not even close to C. I dont know where you heard that VB compiled into C, but your sorely mistaken. It does compile into native ASM, but it still heavily leans on that runtime.
Porting to VC++ required changing all the UCHARs to CHARs and getting rid of warnings pp = (CHAR*)&v; etc
The first benchmark will see an improvement if the Intel C math library was used for the sin/cos/tan stuff.
Second benchmark, switching from CRT memset to winapi ZeroMemory & memcpy to MoveMemory might get better results.
The second benchmark will fair better if the big stack variable(v) is moved into the heap and the stack variables are ordered from largest to smallest. This allows for more efficient use of the L2 cache.

Intel P2-233 - VC++ 6.0 Debug
Benchmark 1 : 4.58600000 Seconds
Benchmark 2 : 0.61100000 Seconds

Intel P2-233 - VC++ 6.0 Release
Benchmark 1 : 3.10400000 Seconds
Benchmark 2 : 1.99300000 Seconds

------------------

**Tim Wisseman** · 28 Sep 2000, 06:43 PM

Visual Basic 5 and beyond uses the Microsoft C compiler to
make its obj files. The name of the second pass C compiler is
C2.EXE.

Visual Basic has very slow string handling because it
uses UNICODE for all strings. Because Visual C++ allows you to
avoid UNICODE it can handle strings much faster.

------------------

**Enoch S Ceshkovsky** · 28 Sep 2000, 10:29 PM

First, don't be confused by filenames. VB compiles frm, cls, bas into a pseudo code that uses an older C2 then compiles into native code. It's the first compile that causes all the slowdowns.

Second, if you want ultra-high performance, Intel makes a C/C++ compiler & libraries that work with VC. AMD has created a set of includes for C that take advantage of 3DNow. But I feel its better to be plunking around with the SIMD stuff in ASM anyways.

PB is at the top for flexible & fast basic compilers out there. It creates the smallest EXE's of any compiler ive seen. However, it is not the fastest compiler. (excluding asm)

Unicode is faster on NT/W2K when going to APIs. Good reason to use typedefs for api's vs DECLARE in vb.

------------------

**Tim Wisseman** · 29 Sep 2000, 07:41 AM

Yes, VB generates a temporary intermediate files
that the C++ compiler turns into machine code.

VB's C++ compiler handles many different optimizations.

VB's calls to the C++ compiler looks like this:

C2 -il C:\WINDOWS\TEMP\VB917310 -f Form1 -W3 -Gy -G5 -Gs4096 -dos
-Zl -FoC:\TEMP\Form1.OBJ -Qifdiv -ML -basic

Switches used:
-W3 Warning level 3
-Gy Enables function-level linking
-G5 Optimize for Pentium
-Gs4096 Turn off stack probes
-Zl Removes default library name from OBJ file
-Qifdiv Performs Pentium FDIV erratum fix
-ML Creates a single-threaded executable file

You can use C2.EXE to compile Visual C++ 5.0 programs, just copy
over from VB 5 to VC++ C2.EXE and then copy MSPDB41.DLL to VC++'s
SharedIDE folder. (You do not have to copy the MSPDB41.DLL file
over if you just would like to invoke the compiler from a DOS Prompt)

VB 5 Will compile programs fine using the c2.exe C++ compiler from
VC++ 5.

The C2.EXE program that came with
Visual Basic 5 last alpha, had this information:

Version: 11.00

Compiler Description:
Microsoft 32-Bit C/C++ Compiler 80x86

Compiler Product Name:
Back End Microsoft 32-Bit C/C++ Optimizing Compiler

------------------

**Enoch S Ceshkovsky** · 29 Sep 2000, 10:36 AM

I'm not saying that VB doesnt use C2; im saying that VB's pseudo code is way way different from VC's pseudo code. Both are fed into C2 (vc6 combines c1 & c2 in cl.exe)
The reason is for alpha/intel support.

------------------

**Tim Wisseman** · 29 Sep 2000, 12:33 PM

The Microsoft C++ Compiler C2.EXE makes the machine code for
both VB 5 and VC 5.0.

Microsoft calls that program a:
Microsoft 32-Bit C/C++ Compiler 80x86

C2.EXE is a C++ Compiler.

The intermediant language is based on tokenized C++, the
output of VC is much cleaner and more optimized because the
source file is C++ code to start with.

VB.EXE makes a conversion from Basic code to an intermediant
language file based on tokenized C++ that adds a whole lot of
overhead and poorly optimized code.

So, sure, Visual C++ will in almost all cases produce smaller
faster EXE files than VB, using the very same C++ compiler.

Tim

------------------

**Guest** · 29 Sep 2000, 12:48 PM

And VB uses the monstrous RTL (DLL) with GOD knows what kind of performance penalty tacked on.
It would have been too easy to include static libraries with VB5/6 to link into the exe. Microsift
obviously saw a major problem in doing this. I also wonder what VB is doing with short Integers since they out-perform
Long Integers.

------------------
Ron

**Tim Wisseman** · 29 Sep 2000, 02:09 PM

Just think about what Visual Basic .NET and Visual C++ .NET
will be like.

They will both be using the same common runtime library. Which
is twice as big as the current Visual Basic run time.

It is odd, Microsoft is working on C# a language that is more
like Visual Basic (No header files, auto garbage collection, no
pointers) and they are working to make Visual Basic more like
C++ (100% OPP).

Microsoft C++ and Visual Basic on a merging path, Weird.

Tim

------------------

Announcement

PB Benchmark code !

PB Benchmark code !

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment