CryptoRndIV

[deltarho[1859]]

@dodicat

With regard Win API whatever datatype MSDN uses then I use the same – no chance of confusion there.

[PaulSquires]

@dodicat,

Right you are. Using your code snippet there is indeed some weird behaviour going on.

The only big difference (that I can see so far) is that the Quick Run creates a temporary file and copies the code to it before it compiles. The kicker is that the temporary file is always created as UTF-16 because some Quick Runs may involve outputting visual designer code. I am not sure how the use of VAR impacts this unless it just so happens a corruption in the UTF16 file during the text conversion to UTF-8 and then storing to UTF-16 file is somehow signalling that the VAR line is the problem (this may have nothing to do with the actual use of VAR).

Anyway, looks like I have a nice joyful relaxing debugging session ahead of me.

I'll post back hopefully today with whatever progress I make on this.

[deltarho[1859]]

There are two things Paul dislikes doing: Writing Help files and writing code with bugs.

So, it will make a change for him to do some debugging.

As regards Help files, that isn't going to happen.

When I write Help files, I always get a prescription from my doctor; otherwise I would end up in a straight jacket.

[deltarho[1859]]

I am beaten.

The address of a UDT pointer with the address of BaseBuffer and its counter worked; thanks to coderJeff in this post Any Ptr woes.

However, the reason for doing that remained. That is the counter, for placing successful RdRands, should increment by 4,4,4,4 then 8,8,8,8 and so on in the four threads initially created, in 32-bit mode. It is all over the place and I could not fathom why that should happen.

By now, the number of code lines was exceeding the asm version by quite a margin. There was still a bit of asm with using RdRand. The RdRand flags were saved in BASIC to be read in BASIC. With the counter issue needing to be resolved I figured that there was no chance of beating the buffer fill of 27ms. I was looking then at a pointless exercise and decided to employ the adage "If it ain't broke, then don't fix it".

That is my story, and I am sticking to it. So, the FillBuffer procedure remains as is.

CryptoD has the most unreadable code we are ever likely to see. Coding that in BASIC was my next task. The code was written by Wilbert over at the PureBASIC forum. Sometime after using that, MrSwiss wrote a neat piece of code to concatenate two Ulongs into a UlongInt. I tried that, and it worked, but it could not get anywhere near the speed of Wilbert's code. CryptoD and CryotoDX will remain in their unreadable form.

Gauss was always BASIC only.

All the other procedures have had asm code removed.

So, we now have three procedures using asm and five which use BASIC only. I tried, srvaldez, but I could not win them all.

Measuring the throughput of random number generators using gcc is a headache.

Tests done so far using a variety of methods suggest that whilst CryptoRndIV is fast, it is not as fast as PCG32II. A decent percentage of PCG32II will do. Since random numbers are invariably used in statements, the execution time of statements are only reduced marginally when a faster generator is used. Using a generator of 500MHz, say, compared with a generator of 250MHz may not see much of a reduction in the execution time of a statement. That is something most people don't realize. I didn't at one time. The most important metric, to mind, is the quality of randomness.

CryptoRndII also appears to be faster than CryptoRndIV. CryptoRndII uses BCryptGenRandom whereas CryptoRndIV uses RDRand, so the buffers should fill faster with BCryptGenRandom. However, since the buffer filling is done in a separate thread of execution, I wouldn't have thought it mattered how the buffers were filled. Perhaps the CryptoRnd family of generators don't get into 'full throttle' until the next buffer to use has been fully populated when the buffer fill thread has completed its task. It may be using a separate thread of execution, but it is still using the CPU. When a buffer is fully populated, that thread ceases to use the CPU. Food for thought!

Meanwhile, I shall try to develop a robust way of timing. It could be that MHz timing with gcc is simply not possible and several 'real life' uses need to be used.

[dodicat]

I really wish that the forum could invite MrSwiss back, then he could argue the toss, I introduced the concatenation:
viewtopic.php?p=230916&hilit=mkulongint#p230916
If he used it before that date then he would surely say so.
Maybe some of the other members banned (for trivial reasons) could be brought back before World War 3 starts in earnest.
Maybe Albert has his compressor finally finished. jj2007 would need apologised to IMHO to get him back.
Anyway, PaulSquires, thanks for the reply and happy debugging this ( before World War 3 starts in earnest).

[deltarho[1859]]

That is strange. I have just done a variety of searches using a search engine – I don't use the forum search. I could not find MrSwiss being associated with either procedure. I found your post.

The other strange thing is that the procedures in my Notes.txt file are lower case and not mixed case; as your post is. So, I didn't copy & paste from your post. Perhaps MrSwiss 'pulled' a post, but he used mixed case as well.

Oh well, credit to you in future.

I really wish that the forum could invite MrSwiss back

coderJeff tried really hard to get MrSwiss to tone down his posts but he would have none of t. He really thought that there was no limit to how far he could push his luck but got it wrong. I thought that there was something seriously wrong with the man and should not be a member of any peer support community. There is someone at PowerBASIC who was equally rude to fellow members. He had been a member for many years and made some useful contributions, and he also thought there was no limit to how far he could push his luck. He got a permanent ban also, but was allowed back after two years. He does seem better behaved now, but I can sometimes sense him biting his lip on occasions.

[fxm]

Regarding the original Macro/union (concatenation)
This uses neither.
Seems OK 32/64 bit.

Code: Select all

Function mkulongint(n1 As Ulong,n2 As Ulong) As Ulongint
    Dim As Ulongint res
    Cast(Ulong Ptr,@res)[0]=n1
    Cast(Ulong Ptr,@res)[1]=n2
    Return res
End Function

Sub getulongs(n As Ulongint, Byref L1 As Ulong,Byref L2 As Ulong)
    L1=Cast(Ulong Ptr,@n)[0]
    L2=Cast(Ulong Ptr,@n)[1]
End Sub

'4294967295 max ulong


Dim As Ulongint u=mkulongint(4294967294,4294967295)
Print u

Dim As Ulong L1,L2

getulongs(u,L1,L2)
Print L1,L2


Print
Print
u=mkulongint(12,13)
Print u
getulongs(u,L1,L2)
Print L1,L2
Sleep  

Another variation, but without "cast" for fun:

Code: Select all

Function mkulongint(n1 As Ulong,n2 As Ulong) As Ulongint
    Union UDT field = 1
        Type
            ul1 As Ulong
            ul2 As Ulong
        End Type
        uli As Ulongint
    End Union
    Return Type<UDT>(n1, n2).uli
End Function

Sub getulongs(n As Ulongint, Byref L1 As Ulong,Byref L2 As Ulong)
    Union UDT field = 1
        uli As Ulongint
        Type
            ul1 As Ulong
            ul2 As Ulong
        End Type
    End Union
    L1 = Type<UDT>(n).ul1
    L2 = Type<UDT>(n).ul2
End Sub

'4294967295 max ulong


Dim As Ulongint u=mkulongint(4294967294,4294967295)
Print u

Dim As Ulong L1,L2

getulongs(u,L1,L2)
Print L1,L2


Print
Print
u=mkulongint(12,13)
Print u
getulongs(u,L1,L2)
Print L1,L2
Sleep

[deltarho[1859]]

I have some regrettable news to post, but I shall leave it a while so members can consider fxm's last post.

[srvaldez]

here's how I would do it

Code: Select all

Function mkulongint(n1 As Ulong,n2 As Ulong) As Ulongint
    Dim As Ulongint res=n2
    res shl=32
    res+=n1
    Return res
End Function

Sub getulongs(n As Ulongint, Byref L1 As Ulong,Byref L2 As Ulong)
    L1=n
    L2=n shr 32
End Sub

[dodicat]

Try macros

Code: Select all

#define concat(n1,n2) ValULng("&h"+hex((n2),8)+hex((n1),8))

#define low(n)  Culng("&h"+right(hex((n),16),8))
#define high(n) Culng("&h"+left(hex((n),16),8))

For n As Long=1 To 20
    Dim As Ulong a=Int(Rnd*4294967295),b=Int(Rnd*4294967295)
    Print "original ";a,b
    Var c=concat(a,b)
    Print "concatenated "; c
    Print "returned ";low(c),high(c)
    Print cbool(low(c)=a And high(c)=b)
    Print "----------"
    Print
Next

Sleep
 

[srvaldez]

the above can of course be written as macros

Code: Select all

#macro makeulngint(res, n1, n2)
    res=(n2)
    res shl=32
    res+=(n1)
#endmacro

#macro mgetulongs(n, L1, L2)
    L1=n
    L2=n shr 32
#endmacro

Dim As Ulongint u
makeulngint(u,4294967294,4294967295)
Print u

Dim As Ulong L1,L2

mgetulongs(u,L1,L2)
Print L1,L2

Print
Print
makeulngint(u,12,13)
Print u
mgetulongs(u,L1,L2)
Print L1,L2
Sleep

deltarho[1859], I am waiting to read your bad report

[dodicat]

I have altered my string method to use string functions for the return values.(to make it look compatible)
The string method is not fast of course.

In the ulong help page (chm) it says that Ulong has the same size as Sizeof(any ptr)
Same further down in the culng page.
But sizeof(any ptr) can be 4 or 8 .

What is it Deltarho[] ?

[fxm]

In the ulong help page (chm) it says that Ulong has the same size as Sizeof(any ptr)
Same further down in the culng page.
But sizeof(any ptr) can be 4 or 8 .

These errors were corrected 10 years ago (last erroneous documentation: FB-manual-0.24.0-chm.zip) !
Please update your manual.chm or use the online manual.

[dodicat]

For some strange reason I have tagged FB-manual-0.23.0.chm to the latest build by SARG in fbide.
I have so many fb compilers around, I think I have that hoarding syndrome, and a poor admin system along with it.
Thanks fxm.

[PaulSquires]

Just use this:
64 bits windows.
var file= rtrim(command(0),".exe")+".asm" -- Doesn't work with WinFBE quick run'
dim as string file= rtrim(command(0),".exe")+".asm" -- Works with quick run
below:

Code: Select all

#cmdline "-exx -gen gcc -RR"
#macro errload
Print "Error handler active."
Dim errnum as long
On Error Goto ehandler
#endmacro

#macro errhandle
Goto skipover
	ehandler:
    Errnum = Err()
    Print "ERROR ";Errnum;"  ";
    Select Case as const Errnum
    case 0: Print " ... "
    Case 1 :Print  "Illegal function call" 
    Case 2 :Print  "File not found signal" 
    Case 3 :Print  "File I/O error" 
    Case 4 :Print  "Out of memory" 
    Case 5 :Print  "Illegal resume" 
    Case 6 :Print "Out of bounds array access" 
    Case 7 :Print  "Null Pointer Access" 
    Case 8 :Print  "No privileges" 
    Case 9 :Print  "interrupted signal" 
    Case 10 :Print  "illegal instruction signal" 
    Case 11 :Print  "floating point error signal" 
    Case 12 :Print  "segmentation violation signal" 
    Case 13 :Print  "Termination request signal" 
    Case 14 :Print  "abnormal termination signal" 
    Case 15 :Print  "quit request signal" 
    Case 16 :Print  "return without gosub" 
    Case 17 :Print  "end of file" 
    End Select
    Print "Function: " &__function__
    #ifdef __FB_LANG__
    #if __FB_LANG__ = "qb"
    Print "Module: " & *__Ermn
    #else
     Print "Module: " & *Ermn
    #endif
    #endif
    Print "Line: " & Erl
    Print "Press a key to exit"
    'Sleep
    'End 
skipover: 
#endmacro

errload

type tudt
		aaa as INTEGER
		bbb as INTEGER
End Type
dim as tudt udt
dim as any ptr ptrbuffer
dim as uinteger tempvar
asm nop '''added for an easy search
TempVar = *Cast(Uinteger Ptr, ptrBuffer)
asm nop
errhandle
'var file= rtrim(command(0),".exe")+".asm"
dim as string file= rtrim(command(0),".exe")+".asm"

shell "notepad "+file
kill file

sleep 

Hi dodicat,

I changed code in WinFBE's Quick Run to output the code to a UTF-8 file and it appears to have corrected the bizarre error that your code above produced.

I compiled new WinFBE32.exe and WinFBE64.exe executables and they can be found at https://github.com/PaulSquires/WinFBE You simply need to right click those filenames and "save link as" to download to your computer. Then, use those newly downloaded files to overwrite your existing WinFBE exe's. Once I know that everything is working okay then I will produce a full release package.

If you still experience and trouble with this then please let me know.