Re: VB6 0xc0000005 on Windows 11 after calling *any* API
Quote:
Originally Posted by
PlausiblyDamp
@niya - not had chance to try this but I wonder if using a Span<int> instead of pointers would make any difference to performance.
In this particular case, I could not find a clean way to use a Span<int> that would have been beneficial. I used pointers so I could benefit from directly utilizing the Avx2 VMOVDQU instruction via the LoadVector256 function. This allows me to copy from the array to a vector register in a single instruction. This is the most direct way of doing it and any other way would add extra overhead.
Spans are very powerful performance enhancers when used correctly but when it comes to the Avx intrinsics, you wouldn't find much room for them. Many of these Avx functions in C# are mapped directly to Avx2 instructions in native code by the RyuJIT so it's lower level than Spans. A lot of these instructions take memory addresses as operands so you will be dealing with pointers quite a bit.
Re: VB6 0xc0000005 on Windows 11 after calling *any* API
Quote:
Originally Posted by
dz32
How’s the Bench marks for ide debug session startup to form display.
The time between startup to Form display has more to do with the IDE's performance than the actual code being executed. Visual Studio is a heavy IDE and it can be quite slow at times, especially to compile code. I think this is what actually contributes to a lot of myths about .Net being slow. Visual Studio is notorious for being sluggish and this affects how people perceive .Net as a whole a development platform.
Re: VB6 0xc0000005 on Windows 11 after calling *any* API
Quote:
Originally Posted by
Niya
Here is the full VB6 code I used for benchmarking in VB6. Please tell me if I got anything wrong or suggest a better way to benchmark if you can:-
After simplifying (unifying) the timing-approach and putting the whole VB6-stuff into a *.bas Module:
VB6-Version:
Code:
Option Explicit
Public Sub Main()
Const COUNT As Long = 300
Dim vecA(0 To COUNT - 1) As Long
Dim vecB(0 To COUNT - 1) As Long
Dim vecR(0 To COUNT - 1) As Long
Dim i As Long, t As Single
For i = 0 To COUNT - 1
vecA(i) = i + 1
vecB(i) = i + 1
Next
t = Timer
For i = 1 To 10 ^ 5
VectorSum vecA, vecB, vecR
Next
t = Timer - t
MsgBox "Timing: " & t * 10 ^ 9 / 10 ^ 5
End Sub
Public Sub VectorSum(v1() As Long, v2() As Long, result() As Long)
Dim i As Long
For i = 0 To UBound(v1)
result(i) = v1(i) \ v2(i)
Next
End Sub
VB.NET-Version (nearly identical, aside from the usual Long->Integer replacements):
Code:
Imports System
Public Module Program
Public Sub Main()
Const COUNT As Integer = 300
Dim vecA(COUNT) As Integer
Dim vecB(COUNT) As Integer
Dim vecR(COUNT) As Integer
Dim i As Integer, t As Double
For i = 0 To COUNT - 1
vecA(i) = i + 1
vecB(i) = i + 1
Next
t = Timer()
For i = 1 To 10 ^ 5
VectorSum( vecA, vecB, vecR)
Next
t = Timer() - t
MsgBox( "Timing: " & t * 10 ^ 9 / 10 ^ 5 )
End Sub
Public Sub VectorSum(v1() As Integer, v2() As Integer, result() As Integer)
Dim i As Integer
For i = 0 To UBound(v1)-1
result(i) = v1(i) \ v2(i)
Next
End Sub
End Module
VB6-native-build (all extended optimizations checked):
540ns
VB.Net-release-build (32Bit, to compare apples with apples):
347ns
And yes, the VB.NET-32Bit-assembly was "running hot" in this case -
(which I've ensured with the little extra-loop around the function-call).
So, VB6-native-binaries are a little bit slower in this case (but not nearly as much, as you claimed).
And this is mostly due to performing "3 extra-additions" in the inner-loop, to calculate the SafeArray-LBound-Offsets.
If I change (in both versions), the Operator to a BackSlash (aka "Integer-Division"),
these extra-additions on the SafeArrays are "less pronounced" -
and the two variants perform nearly identical with about 900ns.
IMO these "Micro-benchmarks" (super-simple, repetitive operations) are not really helping,
to make "educated decisions" with regards to different compiler-outputs.
A better picture give "real world apps" ...
...where I still find myself "cursing out loud" about 3 times every workday -
at the startup-performance of the .NET-based SSMS (aka SQL-Server-Management-Studio) -
which needs about 30-40 seconds on average, until the Login-Screen shows.
Same thing with Atlassian's SourceTree (when accessing our large BitBucket-Repo).
Olaf
Re: VB6 0xc0000005 on Windows 11 after calling *any* API
Quote:
Originally Posted by
dz32
How’s the Bench marks for ide debug session startup to form display.
During dev I have stop start debug sessions approximately 3578421679864226789 times
That’s probably the most meaningful benchmark to me anyway. Java used to kill me
Yeah, I hear you on that. In my current case, it isn't really the start debug sessions, it's getting to the form that I want to get to. I've even built fake routines that can get me there faster for testing some items, but it isn't always possible. Still an aggravation, though.
Re: VB6 0xc0000005 on Windows 11 after calling *any* API
Quote:
Originally Posted by
taishan
You were absolutely right, TRICK, it was the DEP. Chalk up another victory, you are definitely a mad scientist. I'm a fan of your music, as well.
I don't know how to mark this issue as [Resolved], but here's the path I took to fix the problem on Windows 11:
I had never heard of EMET, so at the start menu, typed EMET, and the last search result was "Exploit Protection" clicked that, and changed that to "Off by default" > Reboot
5. Start VB6, opened up my beautiful precious baby project, [F5] and... drumroll... [SHAZAM!]
//===== IT WORKS ! ! !
MODERATORS: I wanted to close this thread back at post #14, I do not know how to close the post, so I just re-edited the original post name.
Cheers
tai
Re: [RESOLVED] VB6 0xc0000005 on Windows 11 after calling *any* API
You can't close a thread yourself. What you can do is mark it RESOLVED on the Thread Tools menu, which doesn't close anything, it just lets people know that the question has been answered...or abandoned.
To close a thread, report it, which is the small black triangle with the exclamation point in it. Ask us to close the thread in the report, and we will.
