Errori, bug, domande - pagina 816

[Renat Fatkhullin]

Secondo me, questa è solo un'ottimizzazione del primo caso di accesso diretto a un membro dell' oggetto.

Nel secondo caso c'è un accesso indiretto tramite riferimento, che in un corpo microscopico di loop richiede naturalmente la metà del tempo, raddoppiandolo.

[Renat Fatkhullin]

Il test è in qualche modo scorretto, essenzialmente confrontando la differenza tra una singola istruzione dell'assemblatore e due istruzioni dell'assemblatore collocate in cento milioni di loop.

[---]

Renat:
Penso che questa sia solo un'ottimizzazione del primo caso di accesso diretto a un membro dell' oggetto.

Nel secondo caso abbiamo un accesso indiretto tramite riferimento che naturalmente richiede la metà del tempo con un corpo microscopico di loop che lo aumenta di due volte.

Renat, in realtà c'è l'elaborazione di grandi matrici di dati. Ho già semplificato il test, solo per mostrare l'area del problema. Inizialmente l'ho creato usando i miei array e le mie classi. Poi l'ho ridotto a uno schema.

Vale a dire che in realtà non abbiamo un solo oggetto arr, ma un array di oggetti complessi (anche con array).

approssimativamente questo può essere scritto nello schema come

class A
{
  double prm1;
  int prm2;
  string prm3;
  char prm4;
}

class B
{
   A m_a[1000];
}

B _b[1000];

Ho pensato che se ottengo un riferimento a un particolare elemento dell'array A

А *item=GetPointer(_b[i]._a[j]);

Il lavoro con i parametri A::prmX sarà più veloce.

Ma si scopre che tirare fuori una salsiccia da nomi di array

_b[i]._a[j].prmX  

sarebbe almeno due volte più veloce che riferirsi a un elemento particolare.

Sono rimasto un po' sorpreso da questo, ed è chiaro che il kernel sta ricevendo una specie di pseudo-pointer.

C'è un modo per ottimizzare la velocità, che almeno riduca la differenza di velocità?

[mvk]

sergeev:

questo è come sarà senza errori

Non ci saranno errori in questo test. Ma questo metodo non risolve la questione principale: perché il compilatore salta la trasformazione di un riferimento costante di un oggetto in un riferimento non costante senza generare errori e/o avvertimenti? Se è una tale caratteristica, nessuna domanda, ma in questo caso si perde il significato del modificatore const per il tipo restituito nella firma dei metodi di classe.

[---]

mvk:
Non ci sarà nessun errore in questo modo in questo test. Ma questo metodo non risolve la questione principale: perché il compilatore salta la trasformazione di un riferimento costante di un oggetto in un riferimento non-const e non genera alcun errore e/o avvertimento? Se è una tale caratteristica, nessuna domanda, ma in questo caso si perde il significato del modificatore const per il tipo restituito nella firma dei metodi di classe.

tutto ha senso per me.

Le funzioni oggetto costante non dovrebbero cambiare l'oggetto stesso, quindi dovrebbero anche avere un modificatore const

e circa

   //Ошибки нет. Это НЕ правильно(CONST A* B::getA())!
   A* a2 = b.getA();

Beh, sì, questo non funziona in C++.

Scrivete a servicedesk.

[Renat Fatkhullin]

sergeev:

Ma si scopre che tirare fuori una salsiccia da nomi di array

sarà almeno due volte più veloce dell'accesso a un elemento specifico.

È davvero più veloce, o è una costruzione logica dell'output basata su altri casi più semplici?

A mio parere, una prova pulita basata sull'accesso presentato a un array multidimensionale non è ancora stata presentata. Soprattutto data la presenza della francamente costosa funzione aggiuntiva GetPointer.

Mi ha sorpreso un po', ed è diventato chiaro che c'è una sorta di pseudo-indicizzazione in corso nel kernel.

I puntatori in senso convenzionale non esistono in MQL5, sono handle, con tutte le loro conseguenze.

C'è un modo per ottimizzare la velocità, che ridurrebbe almeno la differenza di velocità?

Lavoriamo costantemente sull'ottimizzazione, ma nel caso dei riferimenti/handle c'è un overhead di sistema sull'accesso indiretto.

Comunque, guardiamo più da vicino l'ottimizzazione di tale accesso.

[---]

Renat:

È davvero più veloce o è una costruzione logica della conclusione basata su altri casi più semplici?

Sì, è abbastanza realistico. l'ho testato sul riempimento dei miei array. era sempre due volte più lento.

A mio avviso, una prova pulita basata sull'accesso all'array multidimensionale presentato non è ancora stata presentata.

Bene, ho esposto lo schema e un'immagine delle classi A, B e degli array.

Soprattutto con la funzione aggiuntiva GetPointer, francamente costosa.

viene chiamato una volta prima di entrare in un ciclo. ma in linea di principio, per un test più accurato, si può anche portarlo fuori da GetTickCount

In ogni caso, daremo un'occhiata più da vicino all'ottimizzazione di tale accesso.

Ok, grazie, è proprio quello che ci serve.

[Renat Fatkhullin]

sergeev:

viene chiamato una volta prima di entrare nel ciclo. ma in linea di principio, per un test più accurato, si potrebbe anche portarlo fuori da GetTickCount

E al di fuori del ciclo se il codice è come questo?

А *item=GetPointer(_b[i]._a[j]);

[Maxim Khrolenko]

Un suggerimento. La funzione di zoom del testo può essere inclusa nell'aiuto, per esempio + o - , o Ctrl+ruota del mouse.

[Rashid Umarov]

paladin800:
Un suggerimento. La funzione di zoom del testo può essere inclusa nell'aiuto, ad esempio + o -, o Ctrl+ruota del mouse.

Probabilmente non è possibile. La versione online non è adatta?

Ecco quello che ho trovato su internet sull'argomento - http://forum.ru-board.com/topic.cgi?forum=62&topic=20907

UPDate Più http://forum.ixbt.com/topic.cgi?id=23:39211