Idee ambiziose!!! - pagina 5
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
Vi sbagliate perché non conoscete le cose più semplici.
I dati di una qualsiasi matrice sono immagazzinati nella memoria in una sequenza lineare. Dal primo all'ultimo, e per indirizzare un elemento x[15], il compilatore calcolerà l'indirizzo dell'inizio dell'array più lo shift 15 per calcolare l'indirizzo di questa variabile. Con una matrice bidimensionale, per esempio, x[2][5], calcolate prima l'offset per la seconda riga e poi aggiungeteci l'offset per il quinto elemento, cioè il doppio delle operazioni.
x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]
x[15] --> x(+15)
questo è tutto a livello di compilatore, ma ArrayRange(x[0]) per un array statico è SEMPRE costante, non ha bisogno di essere calcolato tutto il tempo, solo una volta e salvato a tempo di compilazione
Stai praticando l'assembler? perché questi problemi? se stai facendo l'assembler, ahimè - non ho visto nessuna documentazione russa per il giusto caricamento della pipeline di istruzioni su processori più vecchi del Pentium-I, e il giusto caricamento del processore non è impegnato nemmeno dagli sviluppatori di compilatori, ma dagli sviluppatori del SO e dell'architettura del processore
Se siete preoccupati che un'operazione di addizione richieda più tempo per essere eseguita in cicli di clock del processore che un'operazione di addizione, ahimè, quella nave è salpata con il processore 486, il caricamento delle cache e delle pipeline di istruzioni richiede più tempo delle operazioni aritmetiche e logiche.
SZZY: mi appello ancora una volta - inizia a leggere le fonti primarie, qui https://www.mql5.com/ru/docs/basis/types/classes gli sviluppatori mql5 descrivono come organizzare l'allineamento dei dati, le stesse informazioni sono per tutti i compilatori, ci sono informazioni su come utilizzare correttamente le funzioni di sistema di chiamata di Windows, ecc. - Scrivo questo per dire che c'è poca documentazione russa che corrisponde alle capacità moderne del sistema operativo e dei processori, e la vecchia roba - quella che insegnano nei college e nelle università - non corrisponde alla realtà in questa fase di sviluppo del sistema operativo e dell'hardware
x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]
x[15] --> x(+15)
questo è tutto a livello del compilatore, ma ArrayRange(x[0]) per l'array statico è SEMPRE costante, non ha bisogno di essere calcolato costantemente, è sufficiente calcolare e salvare una volta a tempo di compilazione
Solo l'indirizzo del primo elemento è calcolato in fase di compilazione. Tutti gli altri elementi saranno contati in modalità di conteggio attraverso l'offset, che è diverso ogni volta.
Per un array bidimensionale, è necessario contare due offset per colonne e per righe moltiplicati per il numero di riga, e naturalmente anche nel processo di conteggio. Asembler e compilatore non hanno assolutamente nulla a che fare con esso, è solo un indirizzamento di memoria di base per un uso corretto delle risorse di calcolo in pratica.
Da questo si può facilmente vedere che anche se c'è una così grande perdita di prestazioni tra gli array monodimensionali e bidimensionali, i tempi di indirizzamento sono ancora più significativamente più lenti nei casi più complessi, ad esempio con gli oggetti.
Solo l'indirizzo del primo elemento è calcolato al momento della compilazione. Tutti gli altri elementi saranno contati in modalità di conteggio tramite un offset, che è diverso ogni volta.
Per un array bidimensionale è necessario calcolare due offset per colonne e righe moltiplicati per il numero di riga e anche nel processo di conteggio, naturalmente. Asembler e compilatore non hanno assolutamente nulla a che fare con questo, è solo un indirizzamento di memoria di base per un uso corretto delle risorse di calcolo in pratica.
Da qui si può facilmente vedere che anche se c'è una perdita di prestazioni così significativa tra gli array monodimensionali e bidimensionali, il tempo di indirizzamento è ancora più significativamente più lento per i casi più complessi, ad esempio gli oggetti.
successi nel capire cosa sta succedendo e la perdita di produttività
Non ho problemi a ottimizzare i compilatori e a scrivere i miei progetti di accesso ai dati
SZY: gli oggetti non sono casi complessi - tutte le manipolazioni per creare collegamenti - tutto a livello del compilatore, ahimè, al processore non importa oggetto o no, non ha problemi con il calcolo degli spostamenti relativi ai dati allineati, anche se il "programmatore miracoloso" risparmia memoria - scrive dati in array come byte, ma non guarda la documentazione al compilatore, l'efficacia di questo codice sarà visibile solo in un riflesso di una fisionomia compiaciuta del programmatore nello specchio, ma in realtà è un falso
tutto è a livello di compilatore, ahimè al processore non importa se è un oggetto o no, non ha problemi a calcolare gli offset relativi ai dati allineati
Sembra che vi sia stato appena spiegato su un semplice esempio quanto l'array bidimensionale rispetto a quello monodimensionale rallenti durante l'esecuzione del programma, non durante la compilazione. Non vedo il motivo di ripetermi. Così vedete che non prendete il compito di scrivere codice di calcolo più o meno ottimale troppo del vostro tempo, e forse non ne avete bisogno. In questo caso OOP è creato proprio per voi. :)
Stai pensando in categorie di amebe :).
" Dovremmo dimenticare le piccole efficienze, diciamo circa il 97% del tempo: l 'ottimizzazione prematura è la radice di tutti i mali. Eppure non dovremmo perdere le nostre opportunità in quel 3% critico".
È la quarta volta che vengo citato in questo forum.
Sembra che vi sia stato appena spiegato su un semplice esempio quanto sarà più lento un array bidimensionale rispetto a uno monodimensionale nel processo di esecuzione del programma, non di compilazione. Non vedo il motivo di ripetermi. Così vedete che non vi preoccupate di scrivere codice computazionale più o meno ottimale, e forse non ne avete bisogno. In questo caso OOP è creato proprio per voi. :)
Di che tipo di codice ottimale stiamo parlando? Non hai assolutamente idea di come funzionano i compilatori e le macchine virtuali
Il programmatore non ha bisogno di scoprire come viene fatto l'accesso e l'indirizzamento agli elementi di memoria fisica in ogni particolare compilatore (anche se in diagonale, non in colonna - qui non si può fare nulla) - è il compito degli sviluppatori, se il programmatore non è soddisfatto del codice - ottimizzerà il suo codice:
- aumentando la dimensione del codice e diminuendo la dimensione dei dati e perdendo velocità di calcolo
- aumentando la dimensione dei dati nel codice e ottenendo una maggiore velocità
- in alternativa, usa un compilatore diverso
Tutte le opzioni sono sparite!
OOP è un altro ramo per scrivere codice EFFICIENTE, l'efficacia di OOP è che il programmatore può creare un modello matematico sotto forma di qualche tipo di architettura - quindi raggiungere una grande versatilità del vostro codice, se pensate che le classi hanno un altro tipo di indirizzamento per l'accesso fisico ai dati - vi sbagliate, quella microscopica quantità extra di dati - una tabella di oggetti collegati non aumenterà in alcun modo il tempo di accesso ai dati fisici in memoria e i dati extra saranno più che compensati da più
Sono scioccato - hai iniziato a cagare su OOP, e poi sei passato ad argomenti sull'indirizzamento in array multidimensionali e monodimensionali - hai studiato questo da qualche parte, o solo - tutte speculazioni e fantasie?
Il lavoro con gli array multidimensionali è stato a lungo implementato a livello di ferro - lo stesso Z-buffer quando si lavora con le schede video, ah, sì, "le pecore, gli sviluppatori di ferro" - non vi hanno consultato e non hanno imparato quanto sia efficace l'indirizzamento degli array multidimensionali, e non consultandovi - tutti i programmatori usano gli array multidimensionali senza pensarci due volte, e non cercano la felicità nell'aumentare il codice per amore dell'efficienza immaginaria quando lavorano con array unidimensionali
L'affidabilità delle informazioni dipende da chi le presenta? Qualsiasi persona di buon senso dovrebbe capire che l'informazione è oggettiva, non soggettiva. :)
se il programmatore non è soddisfatto del codice, ottimizza il suo codice:
- aumentando la dimensione del codice e diminuendo la dimensione dei dati e perdendo velocità di calcolo
- aumentando la dimensione dei dati nel codice e guadagnando più velocità
- in alternativa usa un compilatore diverso
Tutte le opzioni sono sparite!
L'ottimizzazione del codice richiede che il programmatore abbia una comprensione minima di quanto un frammento di codice richieda risorse in termini di operazioni elementari eseguite (addizione, moltiplicazione, accessi alla memoria, calcolo degli indirizzi, ecc.) Senza questo, nessuna ottimizzazione è possibile in linea di principio, e anche il miglior compilatore sarà impotente contro questo povero programmatore. Sembra una cosa ovvia, ma vedo che questa può essere una grande novità anche per molti programmatori. :)
E chiunque si metta a capire la questione si renderà conto che l'informazione, come la quantità, è una cosa soggettiva, non oggettiva:))
Beh, bisogna confondere e mescolare in un mix di serpenti a sonagli diverse cose. :)
Uno è una fonte di informazione, che è oggettiva, e l'altro è un ricevitore, che è soggettivo perché non è sempre in grado di percepire tutte le informazioni, ma solo una parte di esse.