PB and VB.NET speed comparison

[Tenaja]

My results:
PB: 1469
VB.NET: 1375
VB.NET: 1266 (ByVal)
VB.NET: 922 (ByVal and compiler option "/removeintchecks" (Disables integer overflow checking))

It would be interesting to see the C results, since C is always used as "the benchmark."

7% & 16% penalties are not so noticeable, and a fair price to pay for true cross platform code. On the other hand, 59% slower is a big hit. Even if Mono is a slow beast, having VB 59% faster to start with sure makes it worth benchmarking Mono...

[Danilo]

It would be interesting to see the C results, since C is always used as "the benchmark."

Fibonacci() is always 0 with all compilers and FibonacciRecursive() can't be optimized that much: it is just 2 lines with recursion.

Anyway, my results:

Code: Select all

;
; FibonacciRecursive
;
; PB64:   1641
; PB:     1469
; VB.NET: 1375
; VB.NET: 1266 (ByVal)
; VB.NET:  922 (ByVal and compiler option "/removeintchecks" (Disables integer overflow checking))
; VC++:    891 (/Ox, /Ot)
; VC++64:  734 (/0x, /Ot)
; IC++:    922 (/O3, /Ot)
; IC++64:  953 (/O3, /Ot)

Test code:

Code: Select all

#include <iostream>
#include <windows.h>

using namespace std;

int FibonacciRecursive(int argx)
{
    if( argx <= 2 ) return 1;
    return FibonacciRecursive(argx-1) + FibonacciRecursive(argx-2);
}

int Fibonacci(int argx)
{
    int a,b,c;

    if( argx <= 2 ) return 1;

    a = 1;
    b = 1;
    while( argx > 2 )
    {
        c = a + b;
        b = a;
        a = c;
        argx--;
    }
    return c;
}

int main(int argc, char* argv[])
{
    int t, t1, t2, r1, r2;

    t = GetTickCount();
    r1 = FibonacciRecursive(40);
    t1 = GetTickCount() - t;
    t = GetTickCount();
    r2 = Fibonacci(40);
    t2 = GetTickCount() - t;
    
    cout << t1 << ": " << r1 << endl
         << t2 << ": " << r2 << endl;

    cout << endl;
    cout << "Break" << endl;
    cin;

    return 0;
}

I were interested in the 10 seconds PI calculation. My results:

Code: Select all

;
; Calculating PI for 10 seconds:
;
; PB64  : 31415926535897932384626433832795028841971693
; PB    : 31415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253
; C#    : 3141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093
; VC++  : 3141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938
; VC++64: 3141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938
; IC++  : 314159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211706798214808651328230664709384460955058223172535940812848111745028410270193852110555
; IC++64: 3141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644

Code:

Code: Select all

#include <iostream>
#include <windows.h>

using namespace std;

const int Scale   = 10000;
const int ArrInit = 2000;

void Pi()
{
    int carry=0, i, j, sum;

    const int digits = 24 * 1024 * 1024;

    static int arr[digits + 1];

    for (i = 0; i <= digits; i++)
        arr[i] = ArrInit;


    int t = GetTickCount();
    i = digits;
    while(i > 0)
    {
        sum = 0;
        j = i;
        while(j > 0)
        {
            sum = sum * j + Scale * arr[j];
            arr[j] = sum % (j * 2 - 1);
            sum /= j * 2 - 1;
            j--;
        }
        cout.width(4);
        cout.fill('0');
        cout << (carry + sum / Scale);
        carry = sum % Scale;
        i -= 4;

        if (GetTickCount() - t > 10000)
            break;
    }

}


int main(int argc, char* argv[])
{
    Pi();

    cout << endl;
    cout << "Break" << endl;
    cin;

    return 0;
}

EDIT: added my 64bit results.

[wilbert]

There seems to be something wrong with the PI code.
If you use a lower number of digits, for example
Pi(240)
the result is wrong.

[TI-994A]

That's solely your opinion. As I said before there are situations where PB is great and situations where PB is frustrating to work with. Unfortunately it seems your experience dealing with framework is not a success and this is where all the prejudice comes from. If you could point me to an established company using PB on large scale developments I would be really surprised. You're right .net software might not be suitable for wide-spread commercial development and distribution but so is PureBasic. Developers will rather opt for professional environments and faster run-times (e.g. C++). Based on my personal experience I can definitely say that trying to sell software made in .NET (especially when source code needs to be provided) one will be more successful than trying to promote the same software written in PB. So when it boils down to most important aspect of software development - whether you can sell your developments, at the moment I would say it is .NET right after the established C/C++.

Hi Olby. We're starting to sound like Paul Graham's "Blub" programmers, so let's stop. I'd concede that VB.Net is a good and powerful development tool, and my only contention with it is its post-release dependency on the massive framework. That's all.

Personally, after breaking free of p-code and runtimes with PureBasic, which has also opened up the OSX avenue for me, I may be a little biased when it comes to development platforms that seem intent on clipping these new-found wings.

BTW, cool tunes! And all the best with your future projects.

[Foz]

I were interested in the 10 seconds PI calculation. My results:

Code: Select all

;
; Calculating PI for 10 seconds:
;
; PB64  : 31415926535897932384626433832795028841971693
; PB    : 31415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253
; C#    : 3141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093
; VC++  : 3141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938
; VC++64: 3141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938
; IC++  : 314159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211706798214808651328230664709384460955058223172535940812848111745028410270193852110555
; IC++64: 3141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644

To be honest, this is EXACTLY the kind of result I would expect.

PB, for all it's raw power is running on the "lowest common denominator" when it comes to CPU tricks (that is none to barely any)
VB.net/C#, is running on the best CPU tricks it can manage, but at the end of the day, the JIT will claim some overhead.
VC++ uses the CPU tricks for your CPU, and is without a JIT.
IC++, well, it's Intel - they *know* all the tricks inside and out. For all the Microsoft cleverness, it will never match in-house knowledge.

It would be interesting to have all these run on a P1 and then see what the difference is then.

Actually - does anyone know (Fred?) what is the maximum CPU instruction level is used with PureBasic? 386, 486, Pentium, MMX?

[Thorium]

Actually - does anyone know (Fred?) what is the maximum CPU instruction level is used with PureBasic? 386, 486, Pentium, MMX?

It doesnt use any instruction extensions like MMX and runs on Win95 (which needs at least a 386). So it should be 386.

[Fred]

Yes, it's 386.

[Foz]

Well, there we go then, lets re-run the tests on a 386.

Anyone got a Bochs 386 system set up with Windows XP SP3?

[Fred]

that's not that relevant anyway, PB use the 386 instructions only for main code and there isn't much room for improvement in the loop or memory access with the new opcode. The PB libraries are compiled with VC++ will all optimizations activated so they benefit of all the VC++ power and speed (and most time is spent in libraries anyway, except if you do synthetic benchmarks or a very math intensive program).

[Foz]

And thus Fred spaketh the truth.

Lets face it, just use the best tool for the job in question.

[Olby]

Lets face it, just use the best tool for the job in question.

Bring in the champagne, I think this was a good and worthy discussion.

Paul Graham's "Blub" programmers

Haha, I just googled this up, so true.

BTW, cool tunes! And all the best with your future projects.

Thanks mate! Good luck with whatever you're up to now as well.