Canvas is cool! - page 16

[Renat Fatkhullin]

At the current processor level you can forget about the brakes of double maths. There are no lags.

And the methods of optimisation by conversion to integer are already really outdated. You will lose many times more on conversion than you gain on maths.

Taking into account 64-bit code and our compiler, you should forget about integer in the class of tasks based on double calculations.

Here is a previous sample of Nikolai's optimization attempts: https://www.mql5.com/ru/forum/1111/page2164#comment_6796332

The compiler managed to combine calculations of two 64-bit double roots from different expressions into one 128-bit assembler command. When working with double maths it is strongly not recommended to jump/convert to integer types. There are wild CPU overheads on conversion (not ours).

[Renat Fatkhullin]

Nikolai Semko:

You don't have to round anything.

Here is a script as an example.

Run it first with default parameters (with antialiased circles and coordinates and dimensions of type double)

and then run it with parameter typ = not_smoothed_circles (with unsmoothed circles and coordinates and sizes of int type - from CCanvas class).

That worked out great.

I got 347 fps without antialiasing and 97 with antialiasing on canvas with 2100x550 pixels.

For information, we have a window update rate limiter of 500fps. This shows how much performance can be achieved in the graphics.

[fxsaber]

Renat Fatkhullin:

At the current level of processors you can forget about braking of double maths. There are no brakes.

And the methods of optimisation by conversion to integer are already really outdated. You will lose many times more on conversion than you gain on mathematics.

Taking into account 64-bit code and our compiler, you should forget about integer in the class of tasks based on double calculations.

Here is a previous sample of Nikolai's optimization attempts: https://www.mql5.com/ru/forum/1111/page2164#comment_6796332

The compiler has managed to combine calculations of two 64-bit double roots from different expressions into one 128-bit assembler command. When working with double maths it is strongly not recommended to jump/convert to integer types. There are wild CPU overheads on conversion (not ours).

I'm almost sure that if we make the ticks integer-based, the Tester will start working much faster.

[Алексей Тарабанов]

Artyom Trishkin:

No, that's not morphing. It's a stretch to call it morphing:

Actually, I was too lazy to make a real one myself - I found it in the example folders.

Morphing, literally - mortification.

[Алексей Тарабанов]

fxsaber:

It is almost certain that if you make the ticks integer, the Tester will start working much faster.

It's clear to the horse, as Elena Yurievna said.

[Renat Akhtyamov]

Nikolai Semko:

Based on Doom and on the advice of @fxsaber.

I used algorithm fromthis site with some slight modifications.

Really cool!

What do you use to make pictures, Nikolai?

[Renat Fatkhullin]

fxsaber:

It's almost certain that if you make the ticks integer, the Tester will start working much faster.

No.

For starters, realise that:

1. everything will have to be converted to ints.
2. get a lot of lags on data conversion
3. get wild memory consumption
4. get a 100% chance of overflows in each operation and complete death of the system
5. get a disregard of developers who are offered to read their indicators and work in ints instead of dubs
6. And ta da, there is no difference between dubs and ints in speed anymore. Hard to believe, but yes.

I didn't cite the evidence above for nothing. There Nikolai tried to apply the optimization method via pre-calculated root tables and lost out to rltime calculation of dabble roots on the proces.

[Artyom Trishkin]

Алексей Тарабанов:

Morphing, literally - death.

Not worth discussing here, but Morphing ( morphing) Where do you see dead people, sober up...

[Алексей Тарабанов]

Artyom Trishkin:

Not worth discussing here, but Morphing ( morphing- transformation) Where you see dead people - sober up...

Morphometric analysis is the analysis of dead cells. First we kill them, then we put them under the microscope.

[fxsaber]

Renat Fatkhullin:

No.

#define  BENCH(A)                                                              \
{                                                                             \
  const ulong StartTime = GetMicrosecondCount();                              \
  A;                                                                          \
  Print("Time[" + #A + "] = " + (string)(GetMicrosecondCount() - StartTime)); \
}  

template <typename T>
T Tester( const int Amount = 1 e7 )
{
  T Sum = 1;
  T Price = 1;
  
  for (int i = 0; i < Amount; i++)
  {
    Price = 1 - Price;
    
    Sum += (Sum > Price) ? 1 : 0;
  }
  
  Print(Sum);
  
  return(Sum);
}

void OnStart()
{
  BENCH(Tester<int>());
  BENCH(Tester<double>());
}

Double int is twice as fast as double

10000001
Time[Tester<int>()] = 25523
10000001.0
Time[Tester<double>()] = 51253