Index
> Projects and Ideas > RANDOMGoto page Previous 1, 2, 3, 4 Next |
| Author |
|
|
bitRAKE 22 Oct 2007, 17:04
Yes, 100 000 000 is difficult!
With no special priority I'm getting 80 000 000+ in windows. (updates every half second) I've attached a little test program. It is important to note how large a period is needed to not repeat pattern at this fast rate. 32-bit seed is not sufficient - hence the larger state array and automata. (EDIT: Suppose it might be good to say something about the processor - since I did state my measurement. It's a 1.6Ghz Pentium M, Dothan. So, less than 10 cycles per DW, about 1.67 x 10^8 per second. The project I'm working on needs a random block of bits - up to say 1k to be cautious.)
Last edited by bitRAKE on 22 Oct 2007, 18:42; edited 1 time in total |
|||||||||||
22 Oct 2007, 17:04 |
|
|
edfed 22 Oct 2007, 18:07
good job bitrake!!
i cannot code for windows 
too much (c) for my brain can you make a bmp with the random numbers pleaseee! |
|||
|
22 Oct 2007, 18:07 |
|
|
vid 22 Oct 2007, 18:19
just wondering... what do you need so many random numbers per second for?
|
|||
|
22 Oct 2007, 18:19 |
|
|
bitRAKE 22 Oct 2007, 18:52
edfed wrote: i cannot code for windows Thomas Jefferson wrote: He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper [(candle)] at mine, receives light without darkening me. |
|||
|
22 Oct 2007, 18:52 |
|
|
bitRAKE 23 Oct 2007, 02:02
edfed wrote: can you make a bmp with the random numbers As you can imagine a BMP would not compress - it really is random. So I have attached a program that creates a colorful random display. If you'd like, press Alt+PrtScr keys to capture (to clipboard) a BMP and try to compress it - the EXE is smaller, lol. I've also done some graphical distribution tests. At the 32-bit scale there doesn't appear to be any correlation between consecutive numbers.
|
|||||||||||
|
23 Oct 2007, 02:02 |
|
|
edfed 23 Oct 2007, 22:20
is ramdom.exe made on the basis of PPalgorythm??
if it is, it shows that this algorythm is looping the time to loop is 5 seconds on my PIII 800Mhz WHAT IS DOING THIS CODE???? Code: process: .block: mov ebp, PPStateWidth/4 .one: mov eax,DWORD [PPState+ebp*4-4] dec ebp jne .one call PPRenew add [t_data],PPStateWidth/4 jmp .block the .one loop seems to be really unsefull ho i see it's a task and when we want a PRN, we just have to read the value of eax in tss ok!!!!! |
|||
|
23 Oct 2007, 22:20 |
|
|
bitRAKE 23 Oct 2007, 23:46
You are correct process: is just a thread. I like threads because there is no need to have a defined end - the parent process can just kill it, or slow it down - whatever is needed. Threads have there own stack (4k = local storage) and registers, so you can pretend the rest of the world does not exist when coding a thread.
We see here an example of this. The threads job is just to create random numbers and count how many it has created and moved into EAX. As you have noted, nothing is done with them beyond that. So, loading the value for use is also timed - which some people would concider not part of the algorithm. Next we have a timer triggered every ~500ms. This timer just determines how the count has changed from last time and updates the dialog text. The dialog gets everything going, displays numbers, and shuts everything down. I don't bother to suspend the thread opting just to kill it and create a new one - same with the timer. Some windows might not like this, but I think there is some recycling underneath - I hope! Can you run the windows program? How many for 500ms? I'm thinking less than 40 000 000, but not sure by how much. |
|||
|
23 Oct 2007, 23:46 |
|
|
edfed 24 Oct 2007, 00:27
27 138 686 for a PIII 800MHz
and this is the same if blender runs or not the way to read the PRN is a part of the algorythm now i will think about the thread design it seem's to be powerfull and permit to place the different layers of the code in different threads but the first problem is "what about the communication and the synchronisation between layers?? the 4K stack frame looks like the embeded ressources of a µC it is funny to realise that a PENTIUM is in fact a multi µC system each µC can easylly be a component of a system like real components on a PCB !!!! assembling takes all its meaning with this building a fasm code like an electronic board YEAH this is the revelation of the year ( for me ) so now we need, not a library, but a manner to interconnect modules like on a printed circuit board if anyone is agree, then lets go we need the notion of ship, bus, gate, mux, dmux etc etc... like in real electronics |
|||
|
24 Oct 2007, 00:27 |
|
|
bitRAKE 24 Oct 2007, 01:51
edfed wrote: but the first problem is "what about the communication and the synchronisation between layers? Ultrano has a good project here: http://www.codeproject.com/useritems/FastReadWriteLock.asp AFAIK, all the threads share the same address space. Since only one DWORD can be passed to the thread on the stack, maybe it should be an pointer to an array of all other threads at that level? Each thread could store it's stack pointer in the array, and other threads could access it's local data. (funny idea) I like the µC analogy. Hm...blender not doing anything? It was slower than I expected. |
|||
|
24 Oct 2007, 01:51 |
|
|
edfed 24 Oct 2007, 11:04
blender was rendering a scene
and the PRN number is closely the same with or without a big process it means that the PRN reader thread is a idle task no?? the prng needs more optimisation, thats all folks!!! _____________________________________ GLA GLA the winter is still there, ho shit so it's time to code now! |
|||
|
24 Oct 2007, 11:04 |
|
|
bitRAKE 27 Oct 2007, 06:54
Some more random bliss....
(file updated in later post) Last edited by bitRAKE on 31 Oct 2007, 00:38; edited 2 times in total |
|||
|
27 Oct 2007, 06:54 |
|
|
edfed 29 Oct 2007, 15:14
mybug.zip is really unusefull
give us at least the source code and then it will be usefull |
|||
|
29 Oct 2007, 15:14 |
|
|
bitRAKE 31 Oct 2007, 00:35
Here are the sources, but it might still be useless. As of now I am unable to determine why the main process thread will not terminate. All the other threads terminate without a problem, but WM_QUIT is never seen in main message loop.
From what OllyDbg is indicating only the process thread is active and pointing to some place in the kernel - CPU usage is 0%. If I kill the thread through OllyDbg then the process terminates. The number of auxillary threads created doesn't effect it. I'm using the default window PROCs to close and post the quit message - doing it manually didn't change anything either. Most the other problems have been solved. Can't set dialog as child in resource because it looses focus. There are compatiblity problems with Win9x, but I'm targeting Win2k+. Using Pelle C linker because MS link doesn't like all the changing object file flags FASM generates.
|
|||||||||||
|
31 Oct 2007, 00:35 |
|
|
LocoDelAssembly 31 Oct 2007, 00:50
|
|||
|
31 Oct 2007, 00:50 |
|
|
bitRAKE 31 Oct 2007, 01:04
Thank you, that worked.
For some reason I thought the default handler did that. (Actually, it wouldn't make much sense if it did.  ) |
|||
|
31 Oct 2007, 01:04 |
|
|
bitRAKE 31 Oct 2007, 17:42
I've always liked using the Chaos Game to look at random number generators. At these speeds it is quite entertaining, imho.
|
|||||||||||
|
31 Oct 2007, 17:42 |
|
|
edfed 16 Nov 2007, 04:16
i'va found a good random generator in a 256b demo from ³ Luks <-> luks@host.sk
Code: random: mov ax,123 imul ax,123 rol ax,5 mov [cs:random+1],ax ret |
|||
|
16 Nov 2007, 04:16 |
|
|
vid 16 Nov 2007, 07:58
Quote: i'va found a good random generator in a 256b demo from erm, good in which qualities, besides code size? |
|||
|
16 Nov 2007, 07:58 |
|
|
LocoDelAssembly 16 Nov 2007, 12:46
haha, funny way to store the seed. Anyway, this is one of the less random function ever, it always start with a 123 seed (or there is a randomize somewhere?), and the multiplicator (123), is not a prime number (people says that prime numbers are better but I never understood why an odd number is not just enough).
However surely it is good for the purposes of that demoscene |
|||
|
16 Nov 2007, 12:46 |
|
| Goto page Previous 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|