Report a Confronto: 5 AI analizzano lo stesso problema

Cosa stiamo confrontando? Tutti i modelli hanno analizzato lo stesso benchmark: codice C (con e senza restrict) vs Fortran, compilato per ARM Cortex-M4/M7, guardando l'assembly generato. 5 funzioni matematiche (dot_product, matmul, matvec, saxpy, stencil_2d).

---

Classifica sintetica (per chi ha fretta)

Modello	Stile	Pregio principale	Difetto principale	Voto*
DeepSeek V4 Pro	Tecnico-ingegneristico	Dettaglio su pipeline M4/M7 e dual-core H755	Molto specialistico, serve base di assembly	9/10
Kimi K2.6	Analitico-strategico	Ottima analisi memoria/cache e strategie embedded	Meno approfondito sulle differenze di scheduling	8/10
MiniMax M27	Sintetico-pratico	Chiaro, diretto, buone tabelle riassuntive	Troppo breve, meno dettagli del dovuto	7/10
Qwen 3.6 Plus	Didattico-completo	Spiega il PERCHÉ di ogni differenza, chiarissimo	Forse troppo lungo per chi vuole solo il risultato	10/10
Old Qwen 3.6	Conciso-essenziale	Impatto visivo con ASCII art, rapido	Meno approfondito, solo l'essenziale	7/10

*Voto soggettivo basato su chiarezza + completezza + utilità per un non-esperto

---

Cosa dicono TUTTI all'unisono (i fatti oggettivi)

Prima delle differenze, ecco i punti su cui tutti e 5 i modelli concordano:

1. restrict è fondamentale per lo stencil_2d → senza, niente loop unrolling, fino al 37% più lento
2. Per dot_product, matmul, matvec, saxpy → restrict non fa quasi differenza (GCC deduce l'aliasing da solo)
3. Fortran è sempre più lento del C su questo benchmark → da +1 a +2 istruzioni extra per ogni iterazione
4. La ragione principale non è il linguaggio in sé, ma tre fattori strutturali:
   • Convenzione di chiamata (Fortran passa tutto per riferimento → ldr extra)
   • Indicizzazione 1-based (contatore esplicito → adds + cmp extra)
   • Column-major vs Row-major (pattern di accesso invertito per le matrici)
5. M4 e M7 generano assembly quasi identico → la differenza è l'hardware (M7 dual-issue ≈ 1.5-2x più veloce)

---

Modello per Modello: il loro "punto di vista"

DeepSeek V4 Pro — «L'ingegnere dei sistemi embedded»

Si concentra sugli aspetti pratici di implementazione su STM32: come sfruttare il dual-core H755 (M7 per calcolo, M4 per I/O), quali flag usare, come organizzare la memoria. È l'unico che analizza nel dettaglio la rotazione dei registri nello stencil (vmov.f32 s10, s12) e l'impatto del dual-issue sullo scheduling. Il suo verdetto: "C con restrict per firmware DSP, Fortran solo per codice legacy scientifico". Molto forte sulla parte H755 e toolchain.

Frase chiave: "C con restrict + tiling esplicito per sfruttare la D-cache del Cortex-M7 offre il miglior rapporto performance/complessità."

Target utente: Sviluppatori embedded che devono scrivere codice per STM32H7 oggi.

---

Kimi K2.6 — «Lo stratega della memoria»

Mette al centro l'analisi del pattern di accesso alla memoria. Spiega benissimo perché il column-major di Fortran peggiora le cose con la cache del Cortex-M7: "Ogni riga di A risiede in una linea di cache diversa, generando potenzialmente un cache miss per ogni iterazione". È l'unico che menziona esplicitamente il prefetcher hardware del bus AXI. Fa anche notare il flag -fipa-pta per l'analisi inter-procedurale dell'aliasing. Molto bravo a spiegare le conseguenze pratiche dei pattern di memoria.

Frase chiave: "Il codice Fortran non è più lento per forza a causa del numero di istruzioni, ma a causa della qualità degli accessi memoria."

Target utente: Chi vuole capire perché certe scelte di linguaggio impattano le prestazioni a livello di architettura hardware.

---

MiniMax M27 — «Il pragmatico»

Il report più corto e diretto. Va dritto al punto con tabelle chiare e concise. Sottolinea subito che -ffast-math da solo risparmia il 50% delle istruzioni (grazie a VFMA). Ha un approccio più pratico-operativo: dice cosa fare, non solo cosa succede. La tabella finale "Raccomandazioni Pratiche" è la più utilizzabile. È però meno approfondito degli altri sull'analisi fine dell'assembly.

Frase chiave: "restrict è obbligatorio per codice DSP di produzione su ARM Cortex-M."

Target utente: Chi vuole risposte rapide e operative senza perdersi nei dettagli dell'assembly.

---

Qwen 3.6 Plus — «Il professore»

Il report più completo e chiaro. Non solo dice COSA succede, ma spiega il PERCHÉ di ogni differenza con esempi, diagrammi ASCII e analogie. È l'unico che mostra le matrici in memoria per spiegare row-major vs column-major. Ha le tabelle con le stelline (★★★★★) che rendono immediata la lettura. Spiega perfettamente perché "più corto ≠ più veloce" (stencil_2d: 214 linee no-restrict è più lento di 287 linee restrict). Include anche consigli su linker script e posizionamento in memoria (ITCM/DTCM).

Frase chiave: "Più corto ≠ più veloce. Il caso di stencil_2d lo dimostra: C no-restrict (214 linee) è più corto di C restrict (287 linee) ma ~37% più lento."

Target utente: Chiunque, dal principiante all'esperto. È il report che consiglieresti a un collega per capire davvero la situazione.

---

Old Qwen 3.6 — «Il veterano»

Più breve e meno rifinito delle versioni successive, ma comunque efficace. Ha una versione .txt con tabelle ASCII molto leggibili a colpo d'occhio. La struttura è più cruda ma contiene tutte le informazioni essenziali. È interessante vederlo come baseline rispetto a Qwen 3.6 Plus: stesso modello, ma la versione "Plus" è decisamente più completa e chiara. Il .txt in particolare è un ottimo promemoria veloce da tenere aperto in terminale.

Frase chiave: "Non sempre più corto = più veloce."

Target utente: Chi vuole un ripasso veloce senza fronzoli.

---

Tabella: Cosa ha detto ogni modello su ogni funzione

Funzione	DeepSeek V4 Pro	Kimi K2.6	MiniMax M27	Qwen 3.6 Plus	Old Qwen 3.6
dot_product	C uguale a Fortran con leggero overhead	C vince, Fortran +1 istruzione	C 2x più efficiente	C 5 istruzioni, Fortran 6	C = 5, Fortran = 6
matmul	C + restrict per chiarezza, pareggio tecnico	Fortran 20-40% peggiore per stride	C ottimo, Fortran overhead indici	C 5 istruzioni, Fortran 6 + stride	C vince, Fortran stride su A
matvec	C più compatto	Fortran +40% istruzioni	Fortran overhead	C 5 istruzioni, Fortran 7 (+40%)	C vince nettamente
saxpy	C + restrict per scheduling load	Differenza minima scheduling	Leggero riordino, stesso costo	Differenza solo ordine load (ininfluente)	Stesso codice, ordine load diverso
stencil_2d	C + restrict: ~20% più veloce	C restrict: loop unrolling x2, ~37%	C + restrict vettorizzato, 30% meglio	C restrict: ~37% più veloce	C restrict unrolling x2, Fortran più lento

---

Chi ha ragione? Cosa cambia davvero nella scelta?

Tutti dicono la stessa cosa con parole diverse. Le differenze sono di enfasi:

• Se devi scrivere codice per STM32H7 oggi → leggi DeepSeek V4 Pro (consigli pratici su toolchain)
• Se vuoi capire perché il C è più veloce del Fortran qui → leggi Qwen 3.6 Plus (spiegazioni chiare)
• Se ti serve una risposta rapida → leggi MiniMax M27 (sintetico)
• Se ti interessa l'impatto su cache e memoria → leggi Kimi K2.6 (analisi memoria)
• Se vuoi uno schemino veloce da terminale → leggi Old Qwen 3.6.txt (ASCII tables)

---

Verdetto unificato (quello su cui tutti sono d'accordo)

Scenario	Scelta migliore
Filtri DSP, stencil, convoluzioni	C + restrict (differenza enorme)
Dot product, saxpy, operazioni semplici	C standard (restrict non serve)
Matmul su MCU embedded	C + restrict
Codice scientifico legacy	Fortran (ma con penalità 15-30%)
Driver, HAL, firmware	C standard
Prototipazione rapida	Fortran (poi porting in C)
Dual-core H755	C + restrict + tiling

Morale finale: Su STM32 con GCC, per codice numerico, C batte Fortran. La parola magica è restrict — ma solo per operazioni complesse. Per roba semplice (dot, saxpy), GCC è già abbastanza intelligente da solo.