[RESOLVED] VB6 0xc0000005 on Windows 11 after calling *any* API

[taishan]

Niya, I didn't make myself clear, and I don't want to dis the choice of your programming language. I wasn't implying .NET had anything to do with P-Code. I didn't use VB5 because of P-Code. I still used QuickBasic, Pascal, or Delphi.

I don't do managed code. Period. The day I found out TwinBasic uses a CLR or anything similar I will drop that like a hot potato.

I was forced to use VB6 and SQL in the late 90s. I then fell in love with VB. I don't want to learn a new language ---VB.NET and C# are new languages. I'd rather spend that time learning Java, or force myself to build the pyramids with C++. It was hard enough for me to learn VB at the time. I am not a polyglot.

The other day when I tried 2kaud's advice and reinstalled VS2005, it had selected a .NET obfuscator by default. That's a red flag for me. I don't care if someone decompiles my code but I want them to have the Trick's abilities to do it, not just any script kiddie.

M$ could've made VB 7 with all the stuff Niya loves about .NET in 2003. They didn't. I spent a year playing with Delphi because of that.

This is about M$ having COMPLETE control over what you write and when and where it gets executed. They are not the programmer's friend. They proved it in 2003. I could go on and on about how anti-competitive M$ with EVERYONE, but remember what they pulled on Netscape? Java? Linux?

Peace.

[Niya]

Wanted to get back to this thread for a while. Was busy with some real life stuff.

Niya, I didn't make myself clear, and I don't want to dis the choice of your programming language. I wasn't implying .NET had anything to do with P-Code. I didn't use VB5 because of P-Code. I still used QuickBasic, Pascal, or Delphi.

I was taking issue with the fact that your statement implies that .Net is slower than VB6 which is quite wrong. I get that you don't like .Net and that's fine but claims of .Net being slower because of it's framework or it's bytecode is just flat out wrong. That's all I was trying to point out.

Actually x64 gives the quite performace boost so .NET exectuables will give the better performance i guess. Moreover .NET execuatebles have JIT compiler which makes the native code so the performance degrade should be only for the first run i guess. I'm not a .NET expert and i can be wrong.

I've observed this to be the case in a few instances.

I don't suppose you have numbers to back up this attitude... I'd bet that you have to go very far out of your way in .NET to match VB6, rather than the other way around. If you went out of your way in VB6, into the techniques on vbspeed and asm thunks, spanning and whatever else you want to do in .NET isn't coming within a gigaparsec of VB6.

This isn't even close to being true. Let's just at a classic favorite for benchmarking, summing vectors:-

Public Sub VectorSum(ByRef v1() As Long, ByRef v2() As Long, ByRef result() As Long)
    Dim i As Long

    For i = 0 To UBound(v1)
        result(i) = v1(i) + v2(i)
    Next i
End Sub

That is a very naïve implementation of a function that sums two equal size vectors and writes the result to a 3rd vector. When I compile this with all optimizations enabled and execute it to add two Long vectors with 300 elements it takes around 1300 nanoseconds to complete.

Now before I get to how .Net performs I just want to introduce the concept of a cold start. The .Net has runtime environment has a number of non-deterministic algorithms running in the background that tunes the way a .Net application runs. This includes the GC and JIT. This tends to negatively affect performance at the start-up of a .Net application. However, it quickly stabilizes into a stead state.

Here is a C# version of the same vector summing function:-

    public static void VectorSum(int[] v1, int[] v2, int[] result)
    {
        for (int i = 0; i < v1.Length; i++)
            result[i] = v1[i] + v2[i];

    }

With a 32 bit debug build cold start this takes around 1500 nanoseconds which is in the vicinity of the fully optimized VB6 version. With a 32 bit release build cold start, it takes about 700 nanoseconds which is about twice as fast. A 64 bit release build cold start took about 400 nanoseconds which is in the vicinity of 4x faster than the slowest times measure so far.

Using BenchmarkDotNet, I was able to measure it's actual performance unaffected by the noise of a cold start. Compiled as 64 bit release build and executed when the environment is stable it took around 160 nanoseconds.

So to recap:-

VB6 fully optimized release build	1600 ns
.Net 32 and 64 bit cold start debug build	1600 ns
.Net 32 bit cold start release build	700 ns
.Net 64 bit cold start release build	400 ns
.Net 64 bit "warm run" release build	160 ns

Just for fun I decided to throw in a C# Avx2 version of the vector sum function:-

public unsafe static void VectorSumAvx(int[] v1, int[] v2, int[] result)
    {

        if (!Avx2.IsSupported) throw new Exception("Avx2 is not supported on this device.");

        Vector256<int> vec1;
        Vector256<int> vec2;

        //Make sure the lenth is evenly divisible by 8
        int len = (v1.Length / 8) * 8;
        int remainders = v1.Length % 8;


        fixed (int* pv1 = v1, pv2 = v2, pvrec = result)
        {

            // Might as well be writing x86 assembly here.
            // This code copies array values into the YMM registers
            // 8 at a time, adds them and write the sums back
            // to memory in the result array
            for (int i = 0; i < len; i+=8)
            {
                // Load 8 integers from each array
                // into YMM registers
                vec1 = Avx2.LoadVector256(pv1 + i);
                vec2 = Avx2.LoadVector256(pv2 + i);

                // Add all 8 pairs of integers in YMM registers 
                // simluntaneously using the VPADDD x86 instruction from
                // the AVX2 subset of SIMD instructions.
                var r = Avx2.Add(vec1, vec2);

                // Write the result of the additions
                // back to memory.
                Avx2.Store(pvrec + i, r);
            }

        }

        // Handle remainders normally.
        for (int i = len, x = 0; x < remainders; i++, x++)
        {
            result[i] = v1[i] + v2[i];
        }

    }

A 64 bit release build warm run of the above takes 37 nanoseconds, that a little more than 4x faster than the previous fastest speed and around 43x faster than a non-vectorized version executing in a fully optimized VB6 release build!

The .Net compiler I used for all these tests is from .Net 6 by the way, which might as well be a dinosaur. We are already on .Net 8 now. .Net 6 is outdated tech.

So what does this all mean? It means that .Net is fast, very very fast.

Now again, to be clear, this isn't to say that it's not possible to achieve a performance of 37 nanoseconds in VB6. I'm 100% certain you guys are more than talented enough to achieve it. My point is to dispel this persistent myth that .Net is a slow platform. The only real advantage VB6 developers have in terms of raw performance is that they don't have to content with cold starts. Outside of that very narrow scenario, .Net is blazing fast.

One more thing, I'm not a benchmarking expert, especially not with VB6 so I could have screwed up somewhere measuring in VB6. I'll post the full VB6 code in the next post, maybe you guys can tell me if I screwed something up that made this test unfair.

[PlausiblyDamp]

The .Net compiler I used for all these tests is from .Net 6 by the way, which might as well be a dinosaur. We are already on .Net 8 now. .Net 6 is outdated tech.

So what does this all mean? It means that .Net is fast, very very fast.

Just a quick one... .Net 7 special cases certain Linq operations, doing a .Sum or .Average over integers or longs utilises hardware intrinsics automatically. It even figures out the best available depending on the CPU architecture.

[Niya]

Just a quick one... .Net 7 special cases certain Linq operations, doing a .Sum or .Average over integers or longs utilises hardware intrinsics automatically. It even figures out the best available depending on the CPU architecture.

Wow. That is simply amazing. It's about time they did that.

This reminds me, I was sent a video on performance enhancements in the latest .Net iterations. I need to finish watching that video. Perhaps it was mentioned there.

but fortunately that has not happened in a time.

Well let's hope it stays that way. I specifically avoided any temptation to suggest that .Net is better or that it should be chosen over VB6. My opinions on this matter haven't changed. However, I've learned to recognize that perhaps even among Windows programmers everyone's needs don't necessarily overlap as much as I would like to believe. The people that have chosen to stick with VB6 might have good reasons to do so. As such, I try to stick with just facts and avoid straying into subjective discussions. Performance discussions are about as objective as it gets. It about hard facts so I see very little to fight about....hopefully

If I could do anything useful measured in nanoseconds I would be very happy...

Forgot to touch on this too. I'm quite surprise at your attitude here given your interest in deeper matters when it comes to programming. I didn't choose to measure in nanoseconds here for some arbitrary reason. This was very deliberate. Now as I said, I'm no benchmarking expert but I've learned a thing or two about the subject.

I'm trying here to measure the performance of compilers or more specifically, the code they produce. It's important not to fall into common traps. I chose vector summing algorithms for my tests which unavoidably involves memory access. A common pitfall in benchmarking scenarios is failing to account for overheads which can skewer results. In this particular case, memory accesses can seriously bottleneck performance. If I chose to sum say, a pair of vectors 10 million elements in size, then the vast majority of the time would actually be spent accessing memory, not actually performing the calculations. I don't want to measure how fast Windows handles memory. I want to measure the overall performance of summing vectors. I needed to choose a vector size suitable enough that the performance isn't dominated by memory reads and writes.

I chose a 300 element vector pair as a decent compromise. However, because of the small size here, the operation happens way too fast to measure in milliseconds using something like Timer. I needed to measure using a high resolution timer which is why I opted to use QueryPerformanceCounter to measure in nanoseconds.

Also, I should say that a lot of benchmarking in our field happens in the microsecond and nanosecond ranges specifically to lessen the impact of things like memory access on measurements. This is one of the reasons why functions like QueryPerformanceCounter exist.