why is the latest QB64 so slow?

[Cobalt]

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?

[SMcNeill]

WIN 10 here, and it’s consistently slow with all versions of 32-bit QB64.

[Cobalt]

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.

[Cobalt]

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.

[Gets]

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.

[jack]

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

[bplus]

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?

[SMcNeill]

Sure.  Do an update and let’s see how it affects times.  :)

[jack]

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.

[Cobalt]

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.

[jack]

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

Code: QB64: [Select]

1. '' by [banned user]
2. CONST NumOfTests = 7
3. DIM x AS DOUBLE, y AS DOUBLE
4. DIM i AS LONG
5. DIM Time AS DOUBLE
6.  
7. PRINT
8. FOR ttt = 1 TO NumOfTests
9.     PRINT "START TEST #1:";
10.  
11.     'x = 1.234567
12.     'y = 2.345678
13.     x = 1.00000001234
14.     y = 1.00000002345
15.  
16.     Time = TIMER
17.     FOR i = 1 TO 100000000
18.         x = x * y
19.     NEXT
20.     Time = TIMER - Time
21.     PRINT "THE TEST TOOK"; Time; " seconds", "x = "; x
22. NEXT
23.  
24. PRINT
25. FOR ttt = 1 TO NumOfTests
26.     PRINT "START TEST #2:";
27.  
28.     'x = 1.234567
29.     'y = 2.345678
30.     x = 1.00000001234
31.     y = 1.00000002345
32.  
33.     Time = TIMER
34.     $CHECKING:OFF
35.  
36.     FOR i = 1 TO 100000000
37.         x = x * y
38.     NEXT
39.  
40.     $CHECKING:ON
41.     Time = TIMER - Time
42.  
43.     PRINT "THE TEST TOOK"; Time; " seconds", "x = "; x
44. NEXT
45.  
46. PRINT
47. FOR ttt = 1 TO NumOfTests
48.  
49.     PRINT "START TEST #3:";
50.  
51.     'x = 1.234567
52.     'y = 2.345678
53.     x = 1.00000001234
54.     y = 1.00000002345
55.  
56.     Time = TIMER
57.     $CHECKING:OFF
58.  
59.     i = 1
60.  
61.     WHILE i <= 100000000
62.         x = x * y
63.         i = i + 1
64.     WEND
65.  
66.     $CHECKING:ON
67.     Time = TIMER - Time
68.  
69.     PRINT "THE TEST TOOK"; Time; " seconds", "x = "; x
70. NEXT
71.  

https://randomascii.wordpress.com/2012/05/20/thats-not-normalthe-performance-of-odd-floats/

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.

[jack]

times before and after optimization

[xra7en]

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

[xra7en]

what is the ideal speed we are looking for... under 1? under .5?

[jack]

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