My dissatisfaction to the strategy tester. to the MQL developers - page 7

[Maxim Kuznetsov]

(Continued)

I have made some simple programs of analetical understanding showing that the market has a strong influence on the Ask and Bid ticks.

has the marked already found its place in the forum citation ?

that's a HIT ... :-)

PS/ Tester is needed to check the performance of the robot. Optimizer to make sure the parameters are stable. The tester does not make strategies and the optimizer does not guess the market.

[fxsaber]

Forum on trading, automated trading systems and strategy testing

My dissatisfaction with strategy tester. to MQL developers

Renat Fatkhullin, 2017.12.02 15:23

And you compare how their zip on weak compression mode compresses. Maybe BMP files are like that.

Resource compression works.

It's not serious to say such things without proofs on the background of direct rebuttal.

Take this code. My EX5 is 1,717,722 bytes. ZIP at its weakest compression mode is 1,177,567 bytes.

[Renat Fatkhullin]

fxsaber:

Take this code. My EX5 is 1,717,722 bytes. ZIP in weakest mode - 1 177 567 bytes.

That's right, these particular files are weakly compressed and EX file size is reasonable.

Of course, inside the EX resources are compressed.

[fxsaber]

Renat Fatkhullin:

That's right, these particular files compress poorly and the EX file size is reasonable.

Of course, inside EX resources are compressed.

No, unfortunately.

void OnStart()
{
  uchar Data[];
  uchar Key[1];
  uchar Result[];
  
  FileLoad("thousands_rubies_galaxy.bmp", Data);  
  Print(CryptEncode(CRYPT_ARCH_ZIP, Data, Key, Result));
  
  ArrayFree(Data);
  
  FileLoad("space_wind.wav", Data);  
  Print(CryptEncode(CRYPT_ARCH_ZIP, Data, Key, Result));  
}

Result

826534
306648

Your ZIP compresses much better than EX5.

[Renat Fatkhullin]

Resources are compressed with the fastest possible lzss algorithm, not zipped.

We are not suicidal to zip for a very long time and then unzip for a long time.

[fxsaber]

Renat Fatkhullin:

Resources are compressed with the fastest possible lzss algorithm, not zipped.

We are not suicidal to zip for a very long time and then unzip for a long time.

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

void OnStart()
{
  uchar Data[];
  uchar Key[1];
  uchar Result[];
  
  FileLoad("thousands_rubies_galaxy.bmp", Data);  
  BENCH(Print(CryptEncode(CRYPT_ARCH_ZIP, Data, Key, Result)))
  
  ArrayFree(Data);
  
  FileLoad("space_wind.wav", Data);  
  BENCH(Print(CryptEncode(CRYPT_ARCH_ZIP, Data, Key, Result)))
}

Result

826534
Time[Print(CryptEncode(CRYPT_ARCH_ZIP,Data,Key,Result))] = 53334
306648
Time[Print(CryptEncode(CRYPT_ARCH_ZIP,Data,Key,Result))] = 29029

Is 80ms suicide?

[Renat Fatkhullin]

fxsaber:

Result

80ms is suicide?

Run it on a Celeron.

And then scale up to a larger file size variant in the project.

[fxsaber]

Renat Fatkhullin:
Run it on a celoron.

It's about relative time, of course. On my i7, compiling source code from KB takes

'demo_bitmapoffset.mq5' demo_bitmapoffset.mq5   1       1
0 error(s), 0 warning(s), compile time: 232 msec                1       1

When I comment on that.

//#resource "\\Files\\thousands_rubies_galaxy.bmp";
//#resource "\\Files\\space_wind.wav";

I get a reduction of 30ms.

'demo_bitmapoffset.mq5' demo_bitmapoffset.mq5   1       1
0 error(s), 0 warning(s), compile time: 202 msec                1       1

Total changeover to pure ZIP (80ms) would take 282ms. So slowdown would be 21.5%. And this is for the simplest source code.

If you take sources which compile in seconds, the slowdown will be about 1%. Seems like it's no big deal in this case.

[Renat Fatkhullin]

No, we believed and still believe that resources should be compressed and uncompressed as fast as possible across the entire zoo of processors. There are a lot of processors strangled by economy, including semi-vital atoms. There's a speed loss of a dozen times compared to today's powerful processors.

By the way, in the latest build of MT5 we have dramatically increased the launch speed of the terminal and the editor after a deep assessment of the impact of resource compression and initialization methods of protection. We have gained whole seconds on low-end processors.

What was unnoticeable on full-blown i7/xeon, was a disaster by seconds on atoms/celebrons and similarly powerful ones.

[fxsaber]

Renat Fatkhullin:

No, we believed and still believe that resources should be compressed and uncompressed as fast as possible across the entire zoo of processors. There are a lot of processors strangled by economy, including semi-vital atoms. There's a speed loss of a dozen times compared to today's powerful processors.

By the way, in the latest build of MT5 we have dramatically increased the launch speed of the terminal and the editor after a deep assessment of the impact of resource compression and initialization methods of protection. We have gained whole seconds on low-end processors.

What was imperceptible on full-blown i7/xeon, was a disaster by seconds on atoms/celebrons and similarly powerful ones.

Hats off to you for such a reserch! I would like the same thorough approach to CopyTicks and CustomSymbols. It's almost a disaster there.