MT5 and speed in action - page 60

New comment
 
Anton:

Test code:

This code shows that the author does not understand the problem.

Prove it. 
// Классический SYMBOL_BID vs Альтернативный SYMBOL_BID.
// Запускать только на демо-счетах.

#include <MT4Orders.mqh> // https://www.mql5.com/ru/code/16006

#define  Ask SymbolInfoDouble(_Symbol, SYMBOL_ASK)

bool GetPosition( const int Type = OP_BUY )
{
  bool Res = false;
  
  for (int i = PositionsTotal() - 1; (i >= 0) && !Res; i--)
    Res = PositionGetTicket(i) && (PositionGetInteger(POSITION_TYPE) == Type) && 
                                  (PositionGetString(POSITION_SYMBOL) == _Symbol);
                                  
  return(Res);
}

// Альтернативный способ получения Bid-цены текущего символа.
// Запускать только на демо-счетах.
double GetBid()
{
  static const TICKET_TYPE Ticket = GetPosition() ? PositionGetInteger(POSITION_TICKET) : OrderSend(_Symbol, OP_BUY, 0.1, Ask, 0, 0, 0);
  
  return(PositionSelectByTicket(Ticket) ? PositionGetDouble(POSITION_PRICE_CURRENT) : 0);
}

#define  TOSTRING(A) ", "#A + " = " + (string)(A)

#define  MACROS(A, B)                                              \
  const ulong StartTime##A = GetMicrosecondCount();               \
  const double A = B;                                             \
  const ulong Interval##A = GetMicrosecondCount() - StartTime##A; \
                                                                  \
  if (Interval##A > 100)                                          \
    Time##A += (long)Interval##A;  

long TimeBid1 = 0; // Суммарное время на длительный SYMBOL_BID
long TimeBid2 = 0; // Суммарное время на длительный GetBid()

const bool Init = EventSetTimer(10) && GetBid(); // Будем выводить статистику каждый 10 секунд.

void OnTimer()
{
  // На сколько отстает один вариант от другого по времени выполнения.
  Alert(TOSTRING(TimeBid1 - TimeBid2) + " mcs." + TOSTRING(TimeBid1) + TOSTRING(TimeBid2));
}

void OnTick()
{  
  const uint StartTime = GetTickCount();
  
//  return;
  
  while (!IsStopped() && (GetTickCount() - StartTime < 10000))
  {
    MACROS(Bid1, SymbolInfoDouble(_Symbol, SYMBOL_BID))
    MACROS(Bid2, GetBid())
      
//    if (Bid1 != Bid2)
//      Alert("Error!" + TOSTRING(Bid1) + TOSTRING(Bid2));
    
//    Sleep(0); // Специально убрал.
  }
}

This EA gets the Bid price of the current symbol in two ways. For each of them, it sums up the execution time of the long execution cases. And then shows the difference between the two.


Loaded 6/8 Agents. And ran this EA on six charts (different symbols) onRannForex-Server demo. Result.

2020.10.26 16:10:40.596 Test9 (EURNZD,H1)       Alert: , TimeBid1-TimeBid2 = 236507295 mcs., TimeBid1 = 246491044, TimeBid2 = 9983749
2020.10.26 16:10:42.596 Test9 (CAC40,H1)        Alert: , TimeBid1-TimeBid2 = 235249710 mcs., TimeBid1 = 241768964, TimeBid2 = 6519254
2020.10.26 16:10:44.267 Test9 (DAX30,H1)        Alert: , TimeBid1-TimeBid2 = 243552816 mcs., TimeBid1 = 253424672, TimeBid2 = 9871856
2020.10.26 16:10:44.382 Test9 (DJI30,H1)        Alert: , TimeBid1-TimeBid2 = 265778370 mcs., TimeBid1 = 272279313, TimeBid2 = 6500943
2020.10.26 16:10:44.623 Test9 (ASX200,H1)       Alert: , TimeBid1-TimeBid2 = 210921561 mcs., TimeBid1 = 219901110, TimeBid2 = 8979549
2020.10.26 16:10:44.732 Test9 (FTSE100,H1)      Alert: , TimeBid1-TimeBid2 = 226824499 mcs., TimeBid1 = 235809635, TimeBid2 = 8985136

We have a full proof that the total execution time(TimeBid1) of SYMBOL_BID is disastrously losing (TimeBid2) to alternative getting Bid price.


This crutch-type solution of obtaining the current prices beats the performance of the main MQL5 function itself. Do you agree with this proof?


I wish I had thought of this eloquent crutch before.


ZZZY For an EA to work, you need to allow algo trading. Therefore, only run it on demo accounts.

 
fxsaber:

This EA gets the Bid price of the current symbol in two ways.

POSITION_PRICE_CURRENT is snapped?

Then what are we comparing with? Getting the last stored (when?) price with getting the last price known to the terminal?

Well and about 6 out of 8 cores said straight up. Why such tests?

 
fxsaber:

This code shows that the author does not understand the problem.

Your statement proves that you don't want to see the obvious.

This code shows that there is no "SymbolInfoTick braking".

On more or less modern hardware, the SymbolInfoTick runtime is less than 1 MICROSecond.

This Expert Advisor gets the Bid price of the current symbol in two ways. For each of them, it sums up the execution time of the long execution cases. And then it shows the difference between them.

Loaded 6/8 Agents. And ran this EA on six charts (different symbols) onRannForex-Server demo. Result.

We have a full proof that the total execution time(TimeBid1) of SYMBOL_BID is disastrously losing (TimeBid2) to alternative getting Bid price.

This crutch-type solution of obtaining the current prices beats the performance of the main MQL5 function itself. Do you agree with this proof?

I wish I had thought of this eloquent crutch before.

ZZZY The EA needs to allow algo trading to work. Therefore, it may be useful to run it on demo accounts only.

No, that's not proof. An absolutely filthy test which cannot be taken seriously.

I won't even bother to go into details, the fact that you are again timing a single call using GetMicrosecondCount(), and again with "Loaded 6/8 Agents" on a 4 kernel CPU in the background.

I've already clearly shown above that it's possible to find imaginary brakes in "x++" execution this way too.

Your statement about "SymbolInfoTick brakes" is elementary checked and refuted by my code, very simple and obvious.

SymbolInfoTick's original implementation, though quite fast, did allow for sporadic execution time spikes on individual threads under stressful multithreading load.

In the latest builds, it doesn't have this drawback either.

It's just amazing that you keep arguing with someone who knows exactly what he's talking about, i.e. sees implementations and can profile them in different modes.

"Let's argue about the taste of oysters and coconuts with those who have eaten them".

 
Andrey Khatimlianskii:

POSITION_PRICE_CURRENT is snapped?

No. MT4Orders is only used to place a position.

Then what are we comparing with? Obtaining of the last saved price (when?) vs. obtaining of the last price known to the terminal?

We compare the duration of price getting from Market Watch and the position. The prices of course coincide.

And about 6 out of 8 cores said directly. Why such tests?

Only to make even a blind man see that there is a problem. It's nonsense, when Bid-price doesn't slow down via position and SymbolInfoTick lags horribly.


I feel this MQ-wall can't be broken without forum users support. The code is short, professionals should be able to grasp it quickly. There are no flaws in it. It is clearly shown that prices through positions are obtained much faster than from Market Watch. How MQs do not see the obvious - I do not understand.

 
Anton:

Your statement proves that you don't want to see the obvious.

This code shows that there is no "SymbolInfoTick braking".

On more or less modern hardware, the SymbolInfoTick runtime does not exceed 1 MICROsecond.

No, it's not a proof. An absolutely messy test that cannot be taken seriously.

I won't even bother to go into details, the fact that you're once again measuring time of a single call by GetMicrosecondCount(), and again on the background of "Loaded 6/8 Agents" on a 4-core CPU is enough.

I've already clearly shown above that it's possible to find imaginary brakes in "x++" execution this way too.

Your statement about "SymbolInfoTick brakes" is elementary checked and refuted by my code, very simple and obvious.

SymbolInfoTick's original implementation, though quite fast, did allow for sporadic execution time spikes on individual threads under stressful multithreading load.

In the latest builds, it doesn't have this drawback either.

It's just amazing that you keep arguing with someone who knows exactly what he's talking about, i.e. sees implementations and can profile them in different modes.

"Let's argue about the taste of oysters and coconuts with those who have eaten them".

You haven't looked at the code. I don't believe in incompetence.

  if (Interval##A > 100)                                          \
    Time##A += (long)Interval##A;

It's a condition where only if the execution lasted more than 100µs does it count. If you think it's a small value, make it an order of magnitude longer. The effect is the same.

Both functions being compared are in absolutely equal conditions. One is in the end braking, the other is not. Take another close look at what the code measures.


At the moment, replacing SymbolInfoTick in combat EAs with the suggested crutch removes almost all the lags associated with getting the current prices. It's delusional, but unfortunately it does.


HI Note the while in OnTick. It's deliberately made to catch ticks that came after OnTick was accepted. The code wasn't written out of the blue. It's not a completely artificial for-cycle measuring the average hospital temperature under ideal conditions.

 
fxsaber:

I feel that this MQ wall will not get through without the support of the forum members. The code is short, the pros should be able to figure it out quickly. There are no flaws there. It is clearly shown that prices through positions are obtained much faster than from Market Watch. How MQ can't see the obvious - I don't understand.

There are no errors in the code, so SymbolInfoTick is slower than getting the price of an open position

nice hack getting price from position, wouldn't have guessed or realized there could be such a difference
 
fxsaber:

Only to make even a blind person see that there is a problem. Well, it's nonsense when Bid price through position is not slow, but SymbolInfoTick is laggy in a terrible way.

Try to test SymbolInfoTick when there is only one symbol in the market overview and when there are dozens of symbols, but ask for a single symbol - like in your example

it's highly probable that the server has compressed traffic and that SymbolInfoTick has this intermittent lag when decompressing the data

i.e. when there are a lot of characters, there will be even more frequent or deeper dips in test time


so if this proves to be true, then redoing the whole architecture.... questionable pleasure

 
Igor Makanu:

try to test SymbolInfoTick when there is only one symbol in the market overview and when there are dozens of symbols, but ask for one tool - like in your example

there is a high probability that the server is sending compressed traffic and that SymbolInfoTick is experiencing this intermittent slowdown when decompressing the data

i.e. when there are a lot of symbols, there will be even more frequent or deeper dips in test time.

This hypothesis refers to this case when prices in the Market Watch lag behind the tumblr prices (and vice versa). But so far we are only talking about the braking of SymbolInfoTick itself inside the Terminal, without touching the issue of price relevance.

 
fxsaber:

The two functions being compared are in exactly the same conditions.

At least GetBid is called after SymbolInfoDouble. If we swap them, will the result be the same?

Something tells me thatPOSITION_PRICE_CURRENT takes the stored price, and not the fresh price.

Then again, I don't see the point in testing on an 80% loaded CPU. We're testing the CPU performance and resource allocation by the windup, not the features we need.

 
Andrey Khatimlianskii:

At least GetBid is called after SymbolInfoDouble. If you swap it, will the result be the same?

Experimented with it before publication. No, it does not affect the result.

Something tells me thatPOSITION_PRICE_CURRENT takes the stored price, and not the fresh price.

That's the point, MQL-programs need the last price that came to the terminal, not something else. When a tick comes into Terminal, it automatically updates all position/order tables.

Well and again, I don't see the point in testing on an 80% loaded CPU. We're testing CPU performance and resource allocation by the windup, not the features we need.

The main condition is that the environment is identical for both functions. CPU load is the more striking factor for discrepancy visibility.

Twenty EAs in parallel can sometimes make a SymbolInfoTick call at the same time, then there is a millisecond burst of load and lags. I only suggested to do it explicitly so that the problem is immediately noticeable.


Again, the test conditions are identical for both functions. Fact.

Forum on trading, automated trading systems and strategy testing

MT5 and Speed in Action

fxsaber, 2020.10.26 17:53

At the moment, replacing SymbolInfoTick in combat EAs with the proposed crutch removes almost all of the braking associated with getting current prices. It's delusional, but unfortunately it does.

1...535455565758596061626364656667...94
New comment