Lo splendore e la povertà dell'OLP - pagina 3
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
In realtà, non era il compilatore ad essere testato, ma due metodi per risolvere lo stesso problema. Non importa come ronza il frigorifero, ma come si congela.
È un problema da buttare ed è rumoroso...
Lefunzioni virtuali non sono mai in linea, quindi con l'ottimizzazione abilitata non ha senso confrontare con esempi semplici se il passaggio è fatto bene. Questo è uno.
Chi ha detto che OOP è più veloce? Più facile, più logico, ma difficilmente più veloce. Sono due.
Se non ti piace, non usarlo.
Dopo di che ci sono state altre due varianti di test, 2 - con funzioni non vuote, 3 - con funzioni uniche, i risultati sono stati simili. La variante 1 è stata ancora condotta in C#, ma il risultato è stato opposto.
Ho visto queste opzioni. E anche loro si inseriscono nello schema in linea e sono ben ottimizzati.
La variante con C# mostra un altro errore fuorviante dovuto al malinteso lavoro dell'ottimizzatore di codice. Il codice non è stato mostrato e il compilatore dotnet ha molti più metodi di ottimizzazione che possono decifrare casi degenerati di esempi di test come i dadi. Vi ho appena dato un esempio di un caso semplice di conversione di una funzione virtuale in una funzione regolare in casi semplici. Anche noi avremo questa ottimizzazione (in casi semplici come questo test) attivata e anche voi vedrete come un metodo "virtuale" supera improvvisamente un metodo diritto.
Un problema e un rumore gettato fuori asse...
Lefunzioni virtuali non sono mai in linea, quindi con l'ottimizzazione abilitata non ha senso confrontare con esempi semplici se il passaggio è fatto bene. Questo è uno.
Chi ha detto che OOP è più veloce? Più facile, più logico, ma difficilmente più veloce. Sono due.
Se non ti piace, non usarlo.
Beh, non è affatto un problema. È solo un esperimento con i risultati e una conclusione.
Mi piace, non mi piace. Usare lento invece di veloce non è logico.
Ho visto queste opzioni. E anche loro si inseriscono nello schema di inlining e sono ben ottimizzati.
La variante con C# mostra un altro errore fuorviante causato da un'incomprensione del lavoro dell'ottimizzatore di codice. Il codice non è stato mostrato e il compilatore dotnet ha molti più metodi di ottimizzazione che possono decifrare casi degenerati di esempi di test come i dadi. Vi ho appena dato un esempio di un caso semplice di conversione di una funzione virtuale in una funzione regolare in casi semplici. Anche noi avremo questa ottimizzazione (in casi semplici come questo test) attivata e anche voi vedrete come un metodo "virtuale" supera improvvisamente un metodo dritto.
Sembra che qualsiasi risultato che otterrò sarà sbagliato e fuorviante.
- Per cosa?
- Indiano, signore.
(xf Lone Ranger)
Per quanto ci abbia provato, non c'è modo di farlo funzionare più lentamente del metodo virtuale via switch. Ci ho provato, ma mi dispiace, non ha funzionato.
Qui nell'appendice c'è il primo test C#. Ecco i risultati
Le prove verranno dall'altra parte. O di nuovo solo parole.
In generale, mi interessano solo i fatti.
Anche se so già che OOP è più lento, ma fornisce convenienze abbastanza concrete
Le prove verranno dall'altra parte.
Prova di cosa?
Perché avete bisogno di OOP per scrivere giocattoli? )
In ogni caso, è bene che la questione sia stata sollevata.
Lavoriamo costantemente al miglioramento del compilatore e del suo ottimizzatore. Ora ci concentreremo sull'ottimizzazione delle chiamate ai metodi virtuali (molti metodi virtuali possono essere trasformati in metodi diretti).