QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: jack on December 20, 2018, 07:29:20 pm
-
I just downloaded both the stable and dev versions for Windows and run a simple test posted by [banned user] at the old Joyful Programmer/QB64 forum
since the forum is not available, I post his test here
the times were about 12+ seconds, I then downloaded SMcNeill's 64-bit build http://qb64.freeforums.net/thread/100/qb64-x64-10-17-2018 and the times were about 0.5 seconds
'' by [banned user]
FOR ttt
= 1 TO NumOfTests
x = 1.234567
y = 2.345678
x = x * y
PRINT "THE TEST TOOK"; Time;
" seconds"
FOR ttt
= 1 TO NumOfTests
x = 1.234567
y = 2.345678
x = x * y
PRINT "THE TEST TOOK"; Time;
" seconds"
FOR ttt
= 1 TO NumOfTests
x = 1.234567
y = 2.345678
i = 1
x = x * y
i = i + 1
PRINT "THE TEST TOOK"; Time;
" seconds"
-
My Copy of QB64's(32bit) test results.
-
I also have no problems with speed. The only option that comes to my mind is whether your tests have been run on a laptop where power management has reduced performance. My ThinkPad does this because it has a battery in a critical state of emergency (I did not have run this test on it).
-
please test with the latest QB64 version for Windows, either stable or dev, as that is the version with the speed problem.
-
Re-tested in latest development build 2018-12-02-23-33-01. Is up to .2 sec slower
-
don't understand why it's slow here
the second screenshot is from a version 2016-9-5
-
I can confirm Jack's results:
hmm... I tried to access Help > About for my version of QB64 x32 (not latest? but still crappy time) and that version refused to put up the Help > About window to display version with the results of the test like shown in last screen shot.
-
I get nearly identical run times, with in .05 seconds of each other, if I ran it a few hundred times they would probably be exact.
you guys have heck of a lot faster machines than mine from those screen shots. I only run windows, granted Windows VISTA.
Screen shot of slightly different times, and the build from 2018-12-2-23-33-01
-
man you guys are fast - whats the complaint about?
im on my thinkpad w530,16gb RAM i7 2.7GHz
and this is what I got.
-
man you guys are fast - whats the complaint about?
im on my thinkpad w530,16gb RAM i7 2.7GHz
and this is what I got.
the complaint is that this not normal, something is very wrong
-
man you guys are fast - whats the complaint about?
im on my thinkpad w530,16gb RAM i7 2.7GHz
and this is what I got.
the complaint is that this not normal, something is very wrong
Interesting.. I am a little confused then, if most here are getting a .xxx which is processing pretty fast, and then others are getting 10+.xx which is slow, are the results supposed to be a little more closer together?
-
if you are getting 10+.xx then it probably should be less than 0.5 seconds
please try SMcNeill's 64-bit build http://qb64.freeforums.net/thread/100/qb64-x64-10-17-2018
-
Yes xra7en, you are getting 10 secs with thinkpad where I am getting 12 secs with laptop (with newer defective? QB64 version).
I agree with Jack, try SMcNeill's 64-bit QB64 (if thinkpad does 64 bit) and watch times drop below .5 secs.
-
QB64x64 has always been marginally faster for me, but not by the difference specified. I don’t have a clue as to what might’ve changed to reduce execution speeds so greatly, but I’ll do some testing later and you you guys know what results I’m getting as well. ;)
-
BIG DIFF for me..
Rev 20180228/86
EDIT: ADDED SPECS
Core i7 3720QM - 16 GB RAM - 2TB HDD @2.70GHz (thinkpad w530 laptop)
-
I can confirm the same results: 8 seconds vs 0.4 seconds.
I guess the thing to do now is grab various older versions of QB64 and see when/what caused execytion times to drop so dramatically. It’s a 20 to 1 difference for me, in Win 10.
-
Running the test program on various versions of QB64 that I have on my machine, I get similar times all the way back to version 0.980 (the first official GL release). Testing QB64 v o.954 (the last SDL version), I get similar times.
Whenever the issue is, it’s not something new introduced into the language itself.
Windows just updated itself recently; I wonder if there was something in the update which affected 32-bit run times? Does anyone on Linux/Mac see these different speeds? It’s a huge difference with just some simple math...
-
no problem on macOS, latest dev version
-
Windows 10 32-bit version 1803, 10+ seconds
could it be the gcc toolchain?
-
If I read thru this entire thread, then I remember a discussion years ago on an Amiga related forum. Many people did speed tests with a very simple program, while most got acceptable results, some very few had timing peeks in the test, which were unusual high.
The issue turned finally out to be related to the processor's instruction cache, or more precise to wrong MMU table setups, which marked some memory areas as "not cachable". Whenever it did happen, that a program was loaded into such a non cachable memory region (and hence executed from there), then the program went extremly slow, as the processor didn't cache/prefetch the program's instructions, but always made a memory access to fetch the next instruction. This got most obvious in tight loops, which usually would fit into the instruction cache entirely, so that no further memory access (by instruction, not data) would be required until the loop exits.
Long text..., my best guess is a non-optimal BIOS/Firmware configuration (cache related settings) on that slow machines.
Another thought of my own, what's about faulty/defect hardware, anything which will (by error) throw lots of interrupt requests, which the processor must handle with high priority compared to the normal priority any programs usually run with.
-
Remember the recent BIOS updates related to Meltdown and Spectre? Those caused slow downs, even on tests Steve had posted on here some time ago. Could it be that?
May have to do with caching and predicting, nothing to do with qb64 itself?
https://www.bleepingcomputer.com/news/security/list-of-meltdown-and-spectre-vulnerability-advisories-patches-and-updates/
-
Windows just updated itself recently; I wonder if there was something in the update which affected 32-bit run times? Does anyone on Linux/Mac see these different speeds? It’s a huge difference with just some simple math...
Interesting, so how are Petr and Cobalt immune? Disabled updates or USA only affected?
-
I just tested another math intensive program and got a significant improvement to time since the last time I time tested it:
(version x32 2398884) was 21 secs now 4 secs!
-
Hi all,
BTW, how can I know what QB64 version (32 or 64 bit) runs on Linux when I'm on a 64 bit distribution since the About dialog does not specifies this information (that should be nice to add)?
TIA
-
Hi all,
BTW, how can I know what QB64 version (32 or 64 bit) runs on Linux when I'm on a 64 bit distribution since the About dialog does not specifies this information (that should be nice to add)?
TIA
When you start QB64, before you load a program, what’s the title say? QB64x32, or QB63x64?
-
Hi
LOL
I have a cavernman notebook... :-) see results of the test on my TOSHIBA
4GB RAM Celeron Win10 64bit
See the next time (Greek civilization?)
-
From his screenshot, Petr is running 64-bit qb64. That's why the ~0.5 sec execution times.
With the 32-bit qb64, Windows 10 version 1709, Core i5 laptop, got 13 seconds and change, on just about all of them. One just topped 14 seconds.
Also 32-bit qb64, Windows 10 version 1809, Core i7 desktop, I get 10 seconds and little change, like less than 10.3 seconds.
So, I have to believe, it's not so much the Windows version? Looks more like 32-bit vs 64-bit qb64, and then maybe something related to those BIOS updates, which affect the 32-bit way of doing things in 64-bit processors?
-
Hi SMcNeill,
When you start QB64, before you load a program, what’s the title say? QB64x32, or QB63x64?
Thank you for this information since I did not noticed that detail on the title bar before loading a source file (I mainly use QB64 with its command line and the -x -o parameters).
BTW, it could be nice to show that information in the About dialog.
Thanx again.
Fifi
-
I can confirm the same results: 8 seconds vs 0.4 seconds.
I guess the thing to do now is grab various older versions of QB64 and see when/what caused execytion times to drop so dramatically. It’s a 20 to 1 difference for me, in Win 10.
with windows VISTA I get a max of 1 sec test times. I am not seeing anything higher with any build I have. from the 82 build of Nov 2017 to a development build on 10\30 to the one I just downloaded today. all have very simular run times. just a slight change of less than .1 secs in the latest build. those test where all on the same machine so no change in hardware or OS.
-
@Cobalt
what are the specs of your PC?
-
Biostar mother board, 4gig ram, AMD Athlon 64 x2 dual core 2.4ghz, Nvidia Geforce 6100 nForce 405 onboard video with 1gig dedicated and 512meg shared. Running Windows Vista
this old woman is coming up on 10 years old and she wasn't top of the line even new. there is nothing, and I mean NOTHING, special about my desktop machine.
but I've shown you the test times, and they are reasonably close across the board, so something tells me its not necessarily QB64 that is at fault here.
All my machines run VISTA, save one laptop running Win 7 that is currently fritzed out, I can try on my other desktop and spare laptop to see if they pull similar times.
What version of Windows are you guys running?
-
WIN 10 here, and it’s consistently slow with all versions of 32-bit QB64.
-
Ran it on my spare laptop on every version of QB64 I have SDL, .954, .98, 1.0, 1.1, 1.2(build 82) and the current development build they all ran 11.1 secs. EVERY test #1, #2, and #3. there was no difference in speed. normally test #1 is slowest and test 2 a bit fast and test 3 a bit faster yet, NOT on my laptop they ran nearly the exact same 11 sec run time. but it didn't matter what version of QB64, ALL of them ran slow with this test.
HP Pavilion DV4, Intel Core 2 Duo T5800 2.0ghz, 4 gig, Mobile Intel 4 series express 1.7gig running Windows Vista 64bit
this machine is over 10 years old. and everything runs slow on it. Try my higher end desktop now.
gets worse with my higher end desktop, 12.7 - 14.5 second runtimes. again every version of QB64 I have though not just the latest build. Can't compile on the 64bit QB64 I just downloaded yet.
MSI board, Intel I5-2320 4-core 3.0gig, 16gig ram, AMD Radeon HD 6700 series 768meg running Windows Vista 64bit
so why on my other desktop with less power I get no speed change is interesting. HOWEVER I just realized my old desktop only has the 32bit version of VISTA while both the laptop and newer desktop have the 64bit versions. I don't have any other systems running a 32bit OS install to test I'm afraid. but might be something to check into.
-
I think I may have something, My kids game computers are Vista 32bit installs and I get fast run times, <.7 seconds, across the board. I believe it may have something to do with the 64 bit architecture in the OS. need a larger sample size, but every machine in my house running 32bit OS installs gives <1 second test times while all the 64bit OS installs are 12+seconds regardless of processor power. (forgot about trying their computers too)
one note, have no machines running anything above Win 7, so can't test further with Win 8 or Win 10. to see if the difference between 32bit OS and 64bit OS remains.
-
I have two 64bit Windows 8 machines.
One with a 3.1ghz AMD a8-7600 processor that has no speed issues
and a laptop with a 2.5ghz intel i7-4710HQ that is taking over 10 seconds per test.
Don't use the laptop for programming much, so it just has a copy of QB64 1.1 on it. It's usually several times faster than the AMD and that appeared to still be the case outside of the specific tests in this topic.
-
thank you Cobalt and Gets for the specs, I see that PC's with AMD CPU's have no speed issues whereas Intel CPU's do
could this be related to the Meltdown and Spectre CPU flaw?
perhaps some security patch causes the slowdown issue
https://www.pcworld.com/article/3245606/security/intel-x86-cpu-kernel-bug-faq-how-it-affects-pc-mac.html
and https://www.tomshardware.com/news/intel-chips-foreshadow-security-flaws,37608.html
-
Hi Jack,
To test your theory, I pulled out the dinosaur which is an AMD Dual core laptop running a non updated version of Windows 10. The times were better than 10 secs, 2 secs!! Man this thing is slow! (QB64 version 1.1 2017 1106/82)
Hmm... should I let Windows 10 update and see what happens?
-
Sure. Do an update and let’s see how it affects times. :)
-
Hi bplus
the times are not bad for an old laptop, but I agree with SMcNeill, update Windows to the latest and see what happens :)
however, I have a suspicion that the slowdown may be due to an Intel CPU firmware update, though a Windows update could also be the cause.
-
Win 7 64bit with an AMD gives out there results, from .8 to 5.9 seconds not consistent at all but faster than the Intel 64bit OS machines . It may be one of those GPU mix processors though cause DXDIAG give N\A on the processor. Its one of my kids school computers. Very well could be processor based, just happens to be all the 32bit machines I have access to(and have know processor types) are AMDs and 64bit machines are Intel powered. But its obviously not something within QB64 at fault.
-
I think I solved the mystery, at least partly, it seems that floating-point overflow/NaN's is expensive when in 32-bits
I knew that the product x = x * y would overflow, but never thought that it would impact the speed as it does for 32-bit
also, in 32-bit, floating-point is likely performed by the FPU whereas in 64-bit it's performed by SSE
more than likely handling overflow/NaN's is different between the two units, at least one is way slower
I rewrote the test with constants that won't cause an overflow
'' by [banned user]
FOR ttt
= 1 TO NumOfTests
'x = 1.234567
'y = 2.345678
x = 1.00000001234
y = 1.00000002345
x = x * y
PRINT "THE TEST TOOK"; Time;
" seconds", "x = "; x
FOR ttt
= 1 TO NumOfTests
'x = 1.234567
'y = 2.345678
x = 1.00000001234
y = 1.00000002345
x = x * y
PRINT "THE TEST TOOK"; Time;
" seconds", "x = "; x
FOR ttt
= 1 TO NumOfTests
'x = 1.234567
'y = 2.345678
x = 1.00000001234
y = 1.00000002345
i = 1
x = x * y
i = i + 1
PRINT "THE TEST TOOK"; Time;
" seconds", "x = "; x
Performance implications on the x87 FPU
The performance of Intel’s x87 units on these NaNs and infinites is pretty bad. Doing floating-point math with the x87 FPU on NaNs or infinities numbers caused a 900 times slowdown on Pentium 4 processors. Yes, the same code would run 900 times slower if passed these special numbers. That’s impressive, and it makes many legitimate uses of NaNs and infinities problematic.
-
times before and after optimization
-
WIN 10 here, and it’s consistently slow with all versions of 32-bit QB64.
thats because win10 is busy chatting with M$ with your daily activity :P
sorry could not help myself heheheh
-
what is the ideal speed we are looking for... under 1? under .5?
-
probably under 1 second, but the point is that the problem is/was doing arithmetic with NaN's, they are super slow with Intel FPU
-
In last days I have done a test using the code posted... and I got 22/23 sec for test on Toshiba celeron 4 Giga Ram win10 64bit
how hard is this code ! A good benchmark ?
:-)
-
in my opinion, the test is too simple to be considered good, though I certainly am no expert.
-
WIN 10 here, and it’s consistently slow with all versions of 32-bit QB64.
thats because win10 is busy chatting with M$ with your daily activity :P
sorry could not help myself heheheh
I usually keep my Win10 offline while running my QB64 programs, and they do run faster. I think MS should include a message alert: "We now return you to your regularly scheduled program..."
Pete