Endless loop.

[dodicat]

I get about 25 fps (The cylinder craft).
3 G.hz box showing 4 processors
-gen gcc -Wc -O3 with the packaged gcc (5.2).
This is all that is required to run the demo.
(25 fps- old movies), 25 is reckoned to be smooth to the human eyes.
My second demo (the circles) gets me the full 500 fps as set at regulate.
I made this demo because everybody was complaining about the speed of the first demo.
If I re-fabricate the craft from plane panels and use areas rather than an array of points it will get to warp factor 9, would that please the members who test I wonder?

[UEZ]

My regulate function regulates regardless of 1 or 15.625 milliseconds sleep.

Obviously.

If you have 15.625 as sleep 1 then it will regulate to about 60 fps or whatever the max fps the machine can achieve.

OK, so why when I am using '-fpu sse -arch 686 -gen gcc -Wc -O3' with gcc 8.3 (the fastest version with this code) on an i7 3.9GHz I am only getting 20fps?

When I use the parameters "-fpu sse -arch 686 -gen gcc -Wc -O3" using v8.3 x86 then I get approx. 333 fps (rotating cube). Slightly slower with x64.

Endless loop: 18 fps (32-bit / 64-bit). Using -gen gcc -Wc -Ofast -Wc -march=native -Wc -funroll-loops -Wc -mfpmath=sse with Freebasic v1.08 (2019-12-08): ~26 fps (x64). x86 is much slower ~16 fps.

My CPU: AMD Ryzen 5 PRO Mobile 3500U

[deltarho[1859]]

...would that please the members who test I wonder?

I don't have a problem with 20fps - I am not wishing for more.

I do have a problem with 'regulate(40,fps)' coming in with a value of '1' causing a request of 'Sleep 1' which will actually sleep for 15.625ms. Sleeping for longer than required will slow the frame rate.

Regulate works when the Do/Loop workload plus 'Sleep regulate(<whatever>,fps)' gives the required frame rate. Regulate fails when the Do/Loop workload itself stops us getting 60fps, for example. In this case adding Sleep at the end of the Do/Loop will make matters worse. Regulate also fails when we request a Sleep of 15.625ms when a 'proper' 3ms, for example, would do the job.

Regulate will have a better chance of working if we ensure that Sleep has a resolution of 1ms or, in some cases, not employed at all.

Regulate is a great idea. Someone with a much faster machine than mine will request a longer Sleep for a particular fps requirement. However, I think that the Regulate concept needs a little more work.

[dodicat]

Set regulate at a 5000, see what speed you get, that is your ceiling.
Regulate will do it's job between 1 and your ceiling.
My ceiling for the plane is about 25.
My ceiling for the discs is about 500.
That's all regulate does.
If you apply settimer/freetimer then your ceiling could be more than 60 fps (for some computers, my previous one for example).
Being online with google has the same effect as this settimer/freetimer (for some computers, my previous one for example).
This new computer I have is OK, the 60 fps barrier does not exist here.

Code: Select all

 Time of this report: 7/30/2020, 21:53:17
             Machine name: DESKTOP-80CLQHN
               Machine Id: {27107CC9-88DA-4633-83D4-422E3A46D157}
         Operating System: Windows 10 Pro 64-bit (10.0, Build 18362) (18362.19h1_release.190318-1202)
                 Language: English (Regional Setting: English)
      System Manufacturer: Hewlett-Packard
             System Model: HP Compaq 8200 Elite SFF PC
                     BIOS: Default System BIOS (type: BIOS)
                Processor: Intel(R) Core(TM) i5-2320 CPU @ 3.00GHz (4 CPUs), ~3.0GHz
                   Memory: 8192MB RAM
      Available OS Memory: 8080MB RAM
                Page File: 2739MB used, 7260MB available
              Windows Dir: C:\Windows
          DirectX Version: DirectX 12
      DX Setup Parameters: Not found
         User DPI Setting: 96 DPI (100 percent)
       System DPI Setting: 96 DPI (100 percent)
          DWM DPI Scaling: Disabled
                 Miracast: Not Available
Microsoft Graphics Hybrid: Not Supported
 DirectX Database Version: Unknown
           DxDiag Version: 10.00.18362.0387 64bit Unicode 

[deltarho[1859]]

@dodicat

I don't understand your logic.

If 'Sleep regulate(40,fps)' can only manage 20fps then increasing that 40 will have zero effect.

The ceiling is the Do/Loop workload without the Sleep.

[dodicat]

The code is pretty cpu intensive, My fastest is 25 fps, I set it to 40 so others might get a faster result, their ceiling may be more than 25, after all this computer is no gamer, The graphics is on the motherboard I believe

Code: Select all

  Display Memory: 1664 MB
    Dedicated Memory: 32 MB
       Shared Memory: 1632 MB
        Current Mode: 1680 x 1050 (32 bit) (60Hz)
         HDR Support: Not Supported  

So you can see it is no Red Rum.
Some cpu processors are up to 3.5 G.Hz. some with dedicated graphics on a pci card wither water coolers and a built in graphics cpu.
But I reckon many folk these days use a laptop which is usually pretty slow.
I didn't put much thought into 40 fps, it wasn't based on any particular theory other than I thought some testers may get up that high.

[deltarho[1859]]

@dodicat

You are missing the point.

This is what we have:

Code: Select all

<-------------------- 1/fps required ------------------->
<-------=---- Do/Loop workload -----=----><--- Sleep --->

Faster systems will see the 'Do/Loop workload' reduce and the Sleep component increase for the same 1/fps. If we increase fps then the Sleep component will reduce.

Common-sense dictates that Sleep should be as accurate as possible.

People reading this can decide for themselves whether to use timeBeginPeriod or not.

In situations where the 'Do/Loop workload' is high it may be better not to use Regulate at all. This is the case with my machine and the opening post.

[deltarho[1859]]

It is worth noting that we should not bracket settimer and freetimer like this:

settimer
<code>
freetimer

for Windows platforms before Windows 10 because it takes two system clock ticks for timeBeginPeriod to activate. It is better to use settimer at the head of our code. We don't actually need freetimer, timeEndPeriod, because timeBeginPeriod is revoked when the process terminates. We need not concern ourselves with a reduced timer interval for the process session. If we watch a Netflix film, for example, the timer interval will oscillate between 1ms and 15.6ms for the whole film.

With Windows 10 the above bracketing is OK - timeBeginPeriod activates immediately.

[dodicat]

This is about as close a measurement you can get to sleep 1
I get .002 whether or not I use settimer offline, I have no java runtime either (this has the same effect as settimer if it is active)
Just click off the console box after a few seconds.

Code: Select all

Declare Function settimer lib "Winmm.dll" Alias "timeBeginPeriod"(As Ulong=1) As Long
Declare Function freetimer lib "Winmm.dll" Alias "timeEndPeriod" (As Ulong=1) As Long

 dim shared as double t:t=timer
 dim shared as long counter
 do
   
     counter+=1
   
     settimer
    Sleep 1
    freetimer
     
 loop 
 
 sub show destructor
 print (timer-t)/counter," System Minimum ",1/1000
 sleep 10000
 end sub
 sleep
 

    
    

[deltarho[1859]]

With Windows 10 the above bracketing is OK - timeBeginPeriod activates immediately.

You cannot use close bracketing before Windows 10.

We have to use

Code: Select all

settimer
Sleep 16 ' timeBeginPeriod will now be active

I proved the need for Sleep 16 in 2014 at PowerBASIC with Win7.

[ShawnLG]

At first I thought this demo was a ray tracer. Closer inspection reveal it was not, or a poly fill type. After playing with it, I found out it is a voxel type. I see you are calculating dot products for every voxel. This is compute intensive. Most of the voxels share the same surface normal information such as the plate's surface. You can associate the voxels of the object's surface with one surface normal vector object. You then rotate transform these normals in your main loop before calculating the light. This should greatly reduce the number of dot products computations in the main loop. Hope this helps.

[dodicat]

Thanks ShawnLG
Yes I could do the plates as simple fill polygons with one normal for speedup.
The cylinder I would keep although I could use a long box.
But I wasn't really trying to go for total optimisations, It runs smoothly here, but members are having fps issues, maybe because they are using slow laptops.
I'll make a speedier version.
Thanks for testing.