Aiuto con OOP - pagina 7
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Confronto errato, poiché non tiene conto del tempo per la rimozione automatica degli oggetti.
Modificato.
Da dove vengano 123 megabyte dopo la V3, non lo so.
No, è corretto. E questa è una questione di principio. La cancellazione automatica non è nel thread principale, dove il costo del tempo è estremamente costoso. Potete iniziare una nuova esecuzione senza aspettare che il thread parallelo restituisca la memoria usata. Sì, sarà anche chiamato e consumerà anche risorse della CPU, ma sarà un'operazione secondaria eseguita in background. Con qualsiasi ottimizzazione, anche la più aggressiva, una parte delle risorse della CPU sarà disponibile per altri thread, perché questo è il modo in cui funzionano tutti i sistemi operativi moderni. Mettere un carico del 100% sulla CPU nei processori moderni è quasi impossibile.
--
Mettiamola in un altro modo. Supponiamo che ci sia un compito da eseguire in 5 unità di tempo. Potete eseguirlo sia con un thread in 5 unità, sia con due thread in 3 e 2 unità rispettivamente. Ovviamente, il tempo totale di esecuzione sarebbe lo stesso: 5 unità, ma il tempo fisico necessario nel secondo caso sarebbe di 2 unità in meno poiché il compito è concorrente nel secondo caso e non nel primo. C'è un controargomento che l'ottimizzazione occupa tutti i core fisici disponibili della CPU. Ma questo non è vero. Qualsiasi ottimizzazione assegnerà al massimo un numero di thread pari al numero di core del sistema operativo. Tuttavia, oltre a questi compiti, centinaia di altri compiti saranno eseguiti nel sistema operativo, e tutti gli 8 core del processore (se ce ne sono otto) saranno divisi tra centinaia di thread del sistema, invece degli 8 thread assegnati dall'ottimizzatore. Quindi, allocare un thread in più in modalità 8+1 o 8+8, è sempre più ragionevole che pensare ingenuamente che una volta che un'applicazione ha allocato 8 thread, userà tutte le risorse della CPU al 100%.
--
In generale, è divertente sentire argomenti come"non contiamo questo tempo, perché il tempo totale dell'intero sistema lo include". "O l'argomento che"i metodi degli oggetti creati tramite new sono chiamati più lentamente" - Se è così, probabilmente dovremmo scontare il benchmark a questo punto, perché è ingiusto quando i metodi sono chiamati più lentamente in un modo e più velocemente nell'altro )))))) Beh, in questo caso, perché fingere di affogare nelle prestazioni? Ammettiamolo, siamo degli anni 90 e non ammettiamo altro che i falsi slogan "l'assembler è più veloce comunque!" o "quando lavoro con i puntatori, controllo tutto".
--
Secondo punto. Prestare attenzione alla V2. Non c'è nessuna cancellazione di oggetti e una perdita di memoria diretta viene commessa di proposito. Anche così, l'allocazione degli oggetti richiede 1,4 secondi contro 1,2 secondi in V1, anche se non viene speso alcun tempo per la cancellazione.
Non so da dove vengano 123 Mbyte dopo la V3.
È difficile da dire. È necessario conoscere le specifiche della macchina virtuale mql. Ma nessuno lo sa, tranne gli sviluppatori. A giudicare dall'analisi in ProcessHacker, sembra che gli oggetti selezionati attraverso * new siano allocati individualmente in un posto in qualche modo complicato e poi spostati in un'altra area di memoria come grandi array. Cioè potrebbe essere qualche oggetto temporaneo o qualcos'altro.
No, corretto. E questa è una questione di principio. La cancellazione automatica non avviene nel thread principale, dove il costo temporale è estremamente costoso. Potete iniziare una nuova esecuzione senza aspettare che il thread parallelo restituisca la memoria usata. Sì, sarà anche chiamato e consumerà anche risorse della CPU, ma sarà un'operazione secondaria eseguita in background. Con qualsiasi ottimizzazione, anche la più aggressiva, una parte delle risorse della CPU sarà disponibile per altri thread, perché questo è il modo in cui funzionano tutti i sistemi operativi moderni. Mettere un carico del 100% sulla CPU nei processori moderni è quasi impossibile.
--
Mettiamola in un altro modo. Supponiamo che ci sia un compito da eseguire in 5 unità di tempo. Potete eseguirlo sia con un thread in 5 unità, sia con due thread in 3 e 2 unità rispettivamente. Ovviamente, il tempo totale di esecuzione sarebbe lo stesso: 5 unità, ma il tempo fisico necessario nel secondo caso sarebbe di 2 unità in meno poiché il compito è concorrente nel secondo caso e non nel primo. C'è un controargomento che l'ottimizzazione occupa tutti i core fisici disponibili della CPU. Ma questo non è vero. Qualsiasi ottimizzazione assegnerà al massimo un numero di thread pari al numero di core del sistema operativo. Tuttavia, oltre a questi compiti, centinaia di altri compiti saranno eseguiti nel sistema operativo, e tutti gli 8 core del processore (se ce ne sono otto) saranno divisi tra centinaia di thread del sistema, invece degli 8 thread assegnati dall'ottimizzatore. Quindi, allocare un thread in più in modalità 8+1 o 8+8, è sempre più ragionevole che pensare ingenuamente che una volta che un'applicazione ha allocato 8 thread, userà tutte le risorse della CPU al 100%.
--
In generale, è divertente sentire argomenti come: "Beh, non contiamo questo tempo perché il tempo totale dell'intero sistema lo include. "O l'argomento che"i metodi degli oggetti creati tramite new sono chiamati più lentamente" - Se è così, probabilmente dovremmo scontare il benchmark a questo punto, perché è ingiusto quando i metodi sono chiamati più lentamente in un modo e più velocemente nell'altro )))))) Beh, in questo caso, perché fingere di affogare nelle prestazioni? Ammettiamolo, siamo degli anni 90 e non ammettiamo altro che i falsi slogan "l'assembler è più veloce comunque!" o "quando lavoro con i puntatori, controllo tutto".
--
Secondo punto. Prestare attenzione alla V2. Non c'è nessuna cancellazione di oggetti e una perdita di memoria diretta viene commessa di proposito. Anche allora, l'allocazione degli oggetti richiede 1,4 secondi contro 1,2 secondi in V1, anche se non viene speso alcun tempo per la cancellazione.
È difficile da dire. È necessario conoscere le specifiche della macchina virtuale mql. E nessuno lo sa tranne gli sviluppatori. A giudicare dall'analisi in ProcessHacker, sembra che gli oggetti selezionati attraverso * new siano allocati individualmente in un posto in qualche modo complicato e poi spostati in un'altra area di memoria come grandi array. Cioè potrebbe essere qualche oggetto temporaneo o qualcos'altro.
Quindi, se la cancellazione non è nel thread principale, che differenza fa se è inclusa nella misurazione o no? Non è come se stesse andando a influenzare )))) Allora perché non includerlo per vedere la verità?
E a proposito Vasily, c 'è una domanda che ti aspetta (ultima riga).
... O l'argomento che"i metodi degli oggetti creati con new sono chiamati più lentamente"...
Non hai il coraggio di misurarlo? Sei un guscio vuoto, Vasya, serpente a sonagli.
Non hai il coraggio di misurare?
Vuoi dormire un po'!
Basta dormire!
Sogno... e battere i piedi...
Quindi, se la cancellazione non è nel thread principale, che differenza fa se è inclusa nella misurazione o no? Non è come se stesse andando a influenzare )))) Allora perché non includerlo per vedere la verità?
Bene quindi includere nel benchmark il tempo totale trascorso da Explorer, telegram, Chrome in esecuzione durante l'ottimizzazione. Anche se li uccidete tutti, e lasciate solo MT, ci saranno un centinaio di altri thread di sistema che sprecheranno il tempo della CPU, compresi loro.
Bene quindi includere nel benchmark il tempo totale trascorso da Explorer, telegram, Chrome in esecuzione durante l'ottimizzazione. Anche se uccidete tutto questo, e lasciate solo MT, ci saranno un centinaio di altri thread di sistema che faranno perdere tempo alla CPU, includeteli.
È in threads paralleli))) (© Vasya)
Vasya, sei davvero stupido!
Ma continuate, continuate a persistere.
E a proposito, Vasily, c 'è una domanda che ti aspetta (ultima riga).
Puoi dimostrare che sei una testa vuota e un codificatore nullo in pochissimo tempo. Ma chi e perché ne avrebbe bisogno quando lo stai dimostrando anno dopo anno, sporcando letteralmente ogni thread di questo forum. Ho trascorso due anni senza postare nulla qui, solo occasionalmente guardato - e ogni volta, in ogni thread è stato tu, con il tuo "parere autorevole" nello stile di "siete tutti idioti, non capiscono nulla, e come fare - non dirò. Sei una carogna, Dima.
Puoi dimostrare che sei un idiota e un codificatore nullo in pochissimo tempo. Ma chi ne ha bisogno quando lo dimostri anno dopo anno, cagando letteralmente su ogni thread di questo forum. Ho trascorso due anni senza postare nulla qui, solo occasionalmente guardato - e ogni volta, in ogni thread è stato tu, con il tuo "parere autorevole" nello stile di "siete tutti idioti, non capiscono nulla, e come fare - non dirò. Sei un uomo marcio, Dima.
Il problema è che non ti dico come fare, giusto?
Sì, e hai già dimostrato qualcosa molto bene qui))
E sono io quello marcio? Tu sei quello che ha sia la diarrea che la scrofola quando scrivo il codice.