The MASM Forum
64 bit assembler => 64 Bit Assembler => Topic started by: Gunther on October 04, 2013, 10:07:16 PM
-
Attached is the file mc.zip. It contains the following files:
- b_mc.bat: batch file to build the application
- mc.asm: assembly language source
- mc.obj: object file
- mc.pdf: algorithmic background
- montecarlo.c: C source
- montecarlo.exe: application
- montecarlo.o: object file
A typical output of the program is:
Generating 200 Million random numbers with RDRAND.
That'll take a little while ...
Area = 0.250001985000000
Absolute Error = 0.000001985000000
Elapsed Time = 15.71 Seconds
Generating 200 Million random numbers with C.
That'll take a little while ...
Area = 0.250020340000000
Absolute Error = 0.000020340000000
Elapsed Time = 5.02 Seconds
A special thanks goes to Dave aka dedndave. :t He did the proof reading for the algorithmic background and he made an excellent job.
Gunther
-
turned out great, Gunther :t
something i didn't catch in the edit, though :(
in the table of contents, it says "Literature"
then, that section is named "References" (i like this one better) :P
sorry about that
-
Dave,
something i didn't catch in the edit, though :(
in the table of contents, it says "Literature"
then, that section is named "References" (i like this one better) :P
sorry about that
That's a bagatelle; no big deal. You were a great help.
Gunther
-
Hi Gunther,
Can't test it with my 32-bit OS but it looks good. Just one question: Is RDRAND really slower than the C implementation??
-
Hi Gunther !
Thank you for your work :t
Can't test it on my machine ... but it seems like RDRAND is doing a lot of work behind the scene
BTW What's the CPU / OS you ran your test on ?
-
Jochen,
Hi Gunther,
Can't test it with my 32-bit OS but it looks good. Just one question: Is RDRAND really slower than the C implementation??
yes, it tends to be slow.
Gunther
-
Any reason for doing this in 64-bit?
-
Any reason for doing this in 64-bit?
Yes. The generated random number is 64 bit wide.
BTW What's the CPU / OS you ran your test on ?
Windows 7 (64 bit), i7, Ivy Bridge.
Gunther
-
But you can use ax/eax/rax, would that change the time taken? No need for 64-bit Windows if it's 32-bit code.
-
RDRAND retrieves a hardware generated random value from the DRNG and
stores it in the destination register given as an argument to the instruction. The
size of the random value (16-, 32-, or 64-bits) is determined by the size of the
register given. The carry flag (CF) must be checked to determine whether a
random value was available at the time of instruction execution.
Note that RDRAND is available to any system or application software running on
the platform. That is, there are no hardware ring requirements that restrict
access based on process privilege level. As such, RDRAND may be invoked as
part of an operating system or hypervisor system library, a shared software
library, or directly by an application.
To determine programmatically whether a given Intel platform supports RDRAND,
the user can use the CPUID instruction to examine bit 30 of the ECX register.
i found a document that said it was 128-bits wide - lol
guess they were wrong - or they were testing the new 128-bit processor :P
-
Is that function CheckRdRand correct ?
In amd64 Win7 64-bit it crash when trying to use RdRnd.
In PellesC this function works:int CheckRdRandC(void) {
int r[4]; // EAX, EBX, ECX and EDX
_cpuid(r, 1);
if (r[2] & 0x40000000) return 1;
return 0;
}EDIT Thank's qWord !
-
push rbx ; ebx is affected by CPUID
mov eax, 1 ; get version information
cpuid
; check RDRAND support
bt ecx, 30 ; RDRAND supported?
jnc .failed ; no: jump
.done:
mov rax, 1 ; indicate success
pop rbx
ret
.failed:
sub rax, rax ; indicate failure
jmp short .done
little oops, there
mov rax, 1 ; indicate success
.done:
pop rbx
ret
even better
mov rax,1
push rbx
cpuid
xor rax,rax
bt ecx,30
pop rbx
rcl rax,1
ret
-
Is that function CheckRdRand correct ?
if ((r[2] & 0x40000000) == 0x40000000)
-
Hi TWell,
Is that function CheckRdRand correct ?
In amd64 Win7 64-bit it crash when trying to use RdRnd.
I think so.
Gunther
-
it has a slight bug, Gunther
see reply #11
the result is always set to 1
-
Dave,
it has a slight bug, Gunther
see reply #11
the result is always set to 1
yes, the lable was wrong. It's fixed in MC1.ZIP.
Gunther
-
Might not be very useful, but in the attachment a cute multithreaded x64 program that plots a map from the random numbers (64bit). For interpreting the map: as darker a pixel gets, has higher the corresponding "hit" count - because the scaling is relative to the map's minimal and maximal value it will never get monochrome.
jWasm, polink and WinInc is used for building (the paths in build.bat must be adapted of course).
regards, qWord
-
Hi qWord,
interesting idea. Thank you for providing the material. :t
Gunther