1. Brain-scratcher: likely a bug - please help me confirm and fix. Seems to only affect exw.exe
- Posted by CladStone Jun 13, 2009
- 1019 views
While benchmarking some procedures, I noticed some crazy timings that didn't make sense of what I expected, so I reduced the complexity of the code while trying to maintain the problem, and got it down to just a few lines.
To help you try to duplicate my problem, here are some things you should know:
- I'm on Windows XP Home SP3, 2.8GHz Pentium 4, 2GB RAM, Intel Mobo, FAT32 hard drives.
- I reinstalled Euphoria 3.1.1 and got the same problem.
- I installed an earlier version (2.5) and got the same problem.
- I only reproduced the problem using exw.exe. EX.EXE runs both at the same slow speed.
- It's crazy, but the filename matters. Some filenames make the problem disappear. Others flip the problem in the opposite way. For now, name the file "euphbug.exw"
- I don't think the path matters, but to make sure, just put it at "C:\".
- Enter the following code exactly. Don't use any extra lines (yes, in many of my tests, the problem was affected by simply having or not having certain blank lines, unused constants/variables, extra comments, etc.)
constant p = machine_func(16, 1) constant f = machine_func(16, 24) poke(f, #C3) for i = 1 to #800000 do call(f) poke(p, 0) end for machine_proc(26, 0)
Code explanation:
- I start out by allocating two small buffers [machine_func(16, x) = allocate(x)].
- I poke in a program at the second buffer to call later. [#C3 = Return, about as short as it gets]
- To make the timing measurable, I put a couple lines of code in a for loop. Two simple lines of code that repeat.
- As soon as the loop completes, machine_proc(26, 0) generates a console window and waits for a keypress before closing.
The problem:
- Run the file with exw.exe
- The console window appears almost instantly, as expected.
- On line 2, change the 24 to 25, save and run it again.
- The console window is delayed about 2 seconds.
Next test:
- Rename the file "euphbug01.exw"
- Try with 24 and 25. Both make the console window appear immediately.
- Rename the file "euphbug01.ew"
- Try with 24 and 25. Now 24 is the one delayed a couple seconds, while 25 finishes immediately.
Other stuff:
- I've had the problem, in one form or another, regardless of "without type_check" and "without warning" statements.
- There's all sorts of things you can experiement with and manipulate in this file that will give you the fast or the slow running time, but I haven't been able to recognize a pattern to it.
Thanks in advance for the HELP!
2. Re: Brain-scratcher: likely a bug - please help me confirm and fix. Seems to only affect exw.exe
- Posted by DerekParnell (admin) Jun 13, 2009
- 1022 views
While benchmarking some procedures, I noticed some crazy timings that didn't make sense of what I expected ...
This won't help much, but using V4 I do not get the same results. In all cases, regardless of how I change things, the console appears instantly.
3. Re: Brain-scratcher: likely a bug - please help me confirm and fix. Seems to only affect exw.exe
- Posted by CladStone Jun 13, 2009
- 1042 views
Okay, I just downloaded eu40a3.zip, but there's no exw.exe. Is that still in development for v4? The new EX.EXE works the same as the old - it finishes after a second or two, rather than immediately. (Much slower than exw.exe when it's fast, but faster than exw.exe when it's slow.) It doesn't display the discrepencies that exw.exe does.
4. Re: Brain-scratcher: likely a bug - please help me confirm and fix. Seems to only affect exw.exe
- Posted by ne1uno Jun 14, 2009
- 1001 views
While benchmarking some procedures, I noticed some crazy timings that didn't make sense of what I expected,
[..]
The problem:
- Run the file with exw.exe
- The console window appears almost instantly, as expected.
- On line 2, change the 24 to 25, save and run it again.
- The console window is delayed about 2 seconds.
Next test:
- Rename the file "euphbug01.exw"
- Try with 24 and 25. Both make the console window appear immediately.
- Rename the file "euphbug01.ew"
- Try with 24 and 25. Now 24 is the one delayed a couple seconds, while 25 finishes immediately.
possibly the file associations are running *.ex with ex.exe vrs *.exw with exw.exe?
I also can't duplicate this on v4 w/eui.exe for all.
try using include machine.e and misc.e and replacing the machine_funct hardwired constants with the functions allocate and get_key or whatever they are. this probably won't impact the benchmark much but the program will be quite a bit more readable. that has probably been benchmarked already.
5. Re: Brain-scratcher: likely a bug - please help me confirm and fix. Seems to only affect exw.exe
- Posted by CladStone Jun 14, 2009
- 1002 views
Please excuse my ignorance - I found the appropriate file, which I'd managed to overlook earlier. I downloaded "euphoria_40a3.exe", and that of course does have exw.exe.
Something has changed with V4, such that my example did not produce the effects I'd said, but going back to some earlier code, I did manage to reproduce the problem with V4, so the problem is not fixed. I'll post a new example on this thread soon, but in my current testings I've found that:
- The filename AND path makes a difference.
- The exact method of running the file makes a difference (for example, whether or not the path of the file is included in the command string).
- The value of pretty much any numeric value in the program.
- Even the WAY that each numeric value is written, e.g. #C3 vs. 195, #0 vs. 0, etc.
I'll continue to do some testing, and I'll post a new example soon.
6. Re: Brain-scratcher: likely a bug - please help me confirm and fix. Seems to only affect exw.exe
- Posted by CladStone Jun 14, 2009
- 971 views
The file associations have nothing to do with it because in my tests, I either run exw.exe from a command prompt, or with a hotkey in my text editor set to run exw.exe, and you'll note in my example that I said to rename it "*.ew", not "*.ex".
As to using include files vs. machine_proc and machine_func, sorry for the unreadability, but that's why I explained the code lines. Since even the least little things affect the outcome, I was attempting to reduce the problem to as simple as possible. My next example, which I'll post soon, is even simpler, and will include just one hacked allocate() function.
7. Re: Brain-scratcher: likely a bug - please help me confirm and fix. Seems to only affect exw.exe
- Posted by bernie Jun 14, 2009
- 1103 views
Maybe this has something to do with your mystery ??
8. Re: Brain-scratcher: likely a bug - please help me confirm and fix. Seems to only affect exw.exe
- Posted by CladStone Jun 15, 2009
- 999 views
I don't figure it could be that exact Pentium bug, as my processor is newer than Nov 2000, when the article was written. I've also reproduced the situation on another PC with a Celeron CPU. (The exact parameters to reproduce were slightly different, for reasons I can't explain, but it definitely still produced the problem.) When I first encountered the delay, I wondered if it was just something I didn't understand about the way the CPU caches memory, and maybe it still is related to something like that, but given the level of reproduceability and the types of things which affect the outcome (e.g. the path/filename, the way exw.exe is invoked, very slight changes in numeric values, and even the way a number is written) all seem to defy that explanation.