Risposta Stile Testo Dimensione:  10 12 14 16 18 20 24 30 Colore:  Rosso Viola Verde Blu Giallo Grigio Arancio Rosa Allinea:  Centrato Giustificato Linea vuota A capo Altri comandi Emoticons Clicca per riportare il codice nell'area di testo oppure posizionati su un'immagine per vederne il relativo comando. Testo In risposta a Guruman [quote=Guruman] [quote=cgugl ha scritto]Questo perchè il GCC era fermo da millenni.[/quote] GCC è alla versione 9.2, uscita ad Agosto 2019 se non sbaglio. GCC per 68k ha progredito poco perché il 68k è un'architettura morta, e chi vuole provare a resuscitarla deve mettere in conto che o assegna risorse a cose come queste, o continuerà a ottenere codice compilato in maniera non ottimale... [quote]Gunnar proponeva di dare una valutazione alla routine non solo in base al numero teoretico di cicli macchina richiesti ma di usare una funzione complessa che tenesse conto di molte cose, cioè: - minor numero di cicli (cioè eliminare le istruzioni lente) - preferire le istruzioni scalari (quelle che più facilmente vengono eseguite in parallelo) - preferire le istruzioni con minor latenza (l'istruzione è veloce in termini di cicli ma non di accesso alla ram) - preferire le routine che operano su piccole aree di memoria (per ottimizzare le cache) POI, come se non bastasse, ha chiesto di creare una libreria con le routine più comuni ottimizzate dall'uomo da dove avrebbe pescato il compilatore , perchè l'uomo genera codice anche del 30-40% più snello....[/quote] GCC utilizza già delle valutazioni più complesse della sola valutazione del peso della singola istruzione, specie quando utilizzando le direttive per una maggior livello di ottimizzazione effettua più passaggi sul codice, ma un compilatore alla fin fine deve sempre applicare un algoritmo (o una successione di algoritmi) valido per tutti i codici sorgenti, non può ottimizzare ogni singola routine come potrebbe fare un essere umano. Del resto il problema delle ottimizzazioni è complesso e la conclusione è che qualsiasi sia l'architettura di destinazione e qualunque sia il livello di ottimizzazioni implementato, il codice ottenuto sarà sempre, per un motivo o per l'altro, sub-ottimo. Per farla breve, spesso Gunnar parla di cose di cui non sembra capire appieno le implicazioni e parte con voli pindarici che fanno più male che bene al suo progetto. In questo caso chiedendo a una sola persona di fare un lavoro che non è stato fatto da centinaia di persone che hanno lavorato a compilatori C e C++ negli ultimi oltre 30 anni... Saluti, Andrea [/quote] formattazione A sinistra Giustificata Nessuna

08 Settembre 2019 Postato da: Mak73 Compilatore GCC Ottimizzato

Volevo cercare di fare un po' di chiarezza, magari anche con il vostro aiuto, su cosa ha introdotto la nuova versione di questo compilatore. Anzitutto un preambolo su come funziona il 68060 e quindi anche il 68080 della Vampire. Questi due processori hanno un'unità in grado di prevedere i salti nell'esecuzione del codice, queste situazioni fanno perdere normalmente diversi cicli di clock, il 68040 ne impiega ben 11 per eseguire tale istruzione. Questa unità di predizione dei salti analizza il codice ed in base ad un certo algoritmo stabilisce o meno se sta per arrivare un'istruzione di salto o meno e di conseguenza predispone il tutto per eseguirla. Se tale predizione risulta essere giusta, l'operazione di salto viene eseguita in tempo zero, ricordo che il 68060 è in grado arrivare ad eseguire due/tre istruzioni per ciclo di clock, quindi eseguirà il salto e altre due istruzioni nello stesso ciclo, ovviamente nel caso ottimale. Se la predizione è sbagliata impiega cmq solo tre cicli per eseguire il salto. Una piaccola parentesi relativa al 68080 che molto probabilmente, sfruttando le conoscenze odierne, ha un'unità di predizione dei salti più efficiente di quella del 68060 che era il primo processore ad implementare questa cosa insieme al suo rivale il Pentium. Tornando a bomba sul compilatore GCC, quelli tradizionali si limitavano a compilare il codice usando il set specifico delle istruzioni del processore utilizzato, il nuovo compilatore fa una cosa in più, ordina le istruzioni in modo che l'unità di predizione dei salti interna al 68060 e 68080 abbia sempre successo, ed i salti vengano sempre eseguiti in tempo zero, creando così un enorme vantaggio. PS: Se ho sbagliato in qualcosa segnalatemelo pure.

Commenti: 15  Aggiungi  - Leggi

Blue-troll! Post inviati: 596	Commento Guruman 10 Settembre 2019    00:09:33
	cgugl ha scritto Questo perchè il GCC era fermo da millenni. GCC è alla versione 9.2, uscita ad Agosto 2019 se non sbaglio. GCC per 68k ha progredito poco perché il 68k è un'architettura morta, e chi vuole provare a resuscitarla deve mettere in conto che o assegna risorse a cose come queste, o continuerà a ottenere codice compilato in maniera non ottimale... Citazione Gunnar proponeva di dare una valutazione alla routine non solo in base al numero teoretico di cicli macchina richiesti ma di usare una funzione complessa che tenesse conto di molte cose, cioè: - minor numero di cicli (cioè eliminare le istruzioni lente) - preferire le istruzioni scalari (quelle che più facilmente vengono eseguite in parallelo) - preferire le istruzioni con minor latenza (l'istruzione è veloce in termini di cicli ma non di accesso alla ram) - preferire le routine che operano su piccole aree di memoria (per ottimizzare le cache) POI, come se non bastasse, ha chiesto di creare una libreria con le routine più comuni ottimizzate dall'uomo da dove avrebbe pescato il compilatore , perchè l'uomo genera codice anche del 30-40% più snello.... GCC utilizza già delle valutazioni più complesse della sola valutazione del peso della singola istruzione, specie quando utilizzando le direttive per una maggior livello di ottimizzazione effettua più passaggi sul codice, ma un compilatore alla fin fine deve sempre applicare un algoritmo (o una successione di algoritmi) valido per tutti i codici sorgenti, non può ottimizzare ogni singola routine come potrebbe fare un essere umano. Del resto il problema delle ottimizzazioni è complesso e la conclusione è che qualsiasi sia l'architettura di destinazione e qualunque sia il livello di ottimizzazioni implementato, il codice ottenuto sarà sempre, per un motivo o per l'altro, sub-ottimo. Per farla breve, spesso Gunnar parla di cose di cui non sembra capire appieno le implicazioni e parte con voli pindarici che fanno più male che bene al suo progetto. In questo caso chiedendo a una sola persona di fare un lavoro che non è stato fatto da centinaia di persone che hanno lavorato a compilatori C e C++ negli ultimi oltre 30 anni... Saluti, Andrea