Hello! I ran the same test suite a few times adding and removing the /usepmtimer option and rebooting the system.
The results were consistent: when the option switch is there, `benchmark` works correctly, otherwise it doesn't. When it didn't work it could measure an 80-second quotation and say that it ran in under one second. I was tempted to switch to the `now now swap time-` approach, but decided against it, seeing that the Boot.ini option has reliably fixed the `benchmark`. The GetTickCount is what I would normally use in Delphi, especially since I don't need a sub-second precision anyway for my use case, but in Factor I decided to go with the standard Factor library, and therefore the `benchmark` word. I don't think that's something to be fixed in Factor. That's a Windows (or maybe even BIOS or a CPU) problem, so there has to be the kind of fix that I implemented. It's on par with having the correct driver for the system hardware - you can't expect application software to compensate for that. And yes, let's hope newer Windows versions and PCs are not going to have problems like that. 30.07.2016, 02:31, "Björn Lindqvist" <bjou...@gmail.com>: > That is very interesting! I've looked at how Python does benchmarking > and it does not use QPC: > > On Windows, QueryPerformanceCounter() is not used even though it has a > better resolution than GetTickCount() . It is not reliable and has too > many issues. > > https://www.python.org/dev/peps/pep-0418/ > > So we could switch to use GetTickCount() instead but the drawback is > that that function has abysmal resolution. Then again, XP is a very > old operating system.. ---=====--- Александр ------------------------------------------------------------------------------ _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
