Brain-scratcher: New example of the delay
- Posted by CladStone Jun 15, 2009
- 1010 views
Okay, I'm hoping I can get someone else to reproduce this and offer some help with it. I've reproduced it on a second computer, but the parameters I had to use were slightly different, so I'm not sure exactly what all affects it.
Again, this seems to be an issue only with exw.exe. EX.EXE runs it a little slower, but it seems consistent, and not as slow as when exw.exe runs it slowly.
For this test, I've used the following. I think if you play around with it, you can reproduce it under whatever environment you normally use, but just so you know mine:
Filename: C:\b.exw
Euphoria version: exw.exe from euphoria_40a3.exe
Method of running:
- Copy exw.exe in root folder (C:\exw.exe)
- Open command prompt and navigate to the root directory (cd\)
- Enter this command: exw.exw b.exw
File format: ANSI text, CR-LF line endings, no extra lines or spaces at the end of lines.
Here's the code:
atom x = machine_func(16, 1000) poke(x, 195) for i = 1 to 8000000 do poke(x + 311, 0) call(x) end for ? {}
Code explanation:
- I start by allocating a 1000 byte buffer.
- I poke in the simplest machine-code program (RET).
- I run a couple lines of code a bunch of times to make the time evident.
- I use the print directive "?" to call up a console window, so you know when the code is finished.
- The program immediately ends, so you'll only see it flash on screen briefly.
Outcome:
- If it behaves like my computer, this program will run for about 2-3 seconds. You'll see the console flash on screen as soon as it's done.
- If the console appears immediately, replace "311" with a smaller number and try again. I'm sure you'll get it to delay before that number reaches zero.
- Now increase "331" to something higher. Before you get to 999, your program should finish immediately rather than delaying.
Check for strange behavior:
- By making half-way changes and running it repeatedly, you'll probably find some point at which it switches from slow to fast. The first fast number is always even. So, for example, you might find that 631 is slow and 632 is fast. Now comes the fun part:
- Convert your first fast number to hexadecimal, with Windows calculator or something. (e.g. 632 = #278)
- In your code, replace 632 with #278, and run it again.
- Do the same with the last slow number. (e.g. 631 = #277)
- You'll now find that instead of one number running fast and the other slow, they now either both run slow or both run fast, even though you're using the same numbers, just written differently. The cutoff point has now changed. If both fast, lower your hex values till you find the slow mode. If both fast, raise your hex value till you find the fast mode.
- Keep playing around with it. Change the numbers in loop, e.g. "1" to "0" or even "#1". Change the value of the number poked during the loop. Any little change like that should change the cutoff point of the offset where slow becomes fast.
Please tell me if you can reproduce this!
