m3x ha scritto:In alcuni casi si tratta di "riconfigurazioni" in altre però si tratta di "ottimizzazioni", vedi l'utilizzo del DMA in rtg.library, novità assoluta in AmigaOS4.1 e probabilmente non sono di ASO4...
Certamente la riscrittura di parti di librerie rientra nella categoria delle ottimizzazioni, ma i vari programmini di riconfigurazione delle cache di cui si parlava nel caso dei test come quelli in questione (Blender) sono appunto riconfigurazioni.
Al limite possiamo chiederci quale strategia commerciale c'è dietro la scelta di AMCC di vendere delle CPU per un certo target quando invece sono capaci di ben altro, come poi dimostrano le mie "scoperte"...
Questo non e' troppo strano. AMCC si rivolge a clienti industriali che acquistano in pezzature che si sperano siano nell'ordine delle decine/centinaia di migliaia di unita' (stampanti, NAS, router). In tali casi, il cliente si aspetta di attaccare il SoC sulla propria board, effettuare con successo una veloce verifica (in genere a sistema spento, perche' il tempo di boot, anche di una semplice stampante, spesso supera il tempo allocato per il test), e poter inscatolare il tutto. Poi gli tornano i pezzi difettosi in garanzia. Se ne tornano troppi, il cliente fa dei controlli approfonditi sui resi, e se vede che la colpa e' della CPU anche se usata come da specifiche, per AMCC diventa un problema. Quindi tutti quelli che commercializzano chip da usare in questi ambiti si tutelano garantendo le specifiche piu' prudenti, perche' il numero di parti che non rispettano tali specifiche deve rientrare entro poche decine di ppm (parti per milione).
Chiaramente per ACube e' accettabile avere una Sam ogni 1000 o ogni 100 che viene resa instabile da un programma che riconfigura le cache - infatti consigli sempre di verificarne la stabilita' dopo aver cambiato le impostazioni -, ma cio' sarebbe assolutamente inaccettabile per HW chiusi e con margini decisamente piu' piccoli e clienti decisamente piu' importanti.
In pratica la risposta sta sempre nella natura non consumer/desktop del prodotto.
Nello specifico, pero', le osservazioni di AmigaCori sono almeno parzialmente fuori luogo. Vuoi perche' mescola in parte terminologie da analogico con problematiche che in questo caso sarebbero digitali (il segnale/rumore e la banda vengono convertiti in altre figure di merito digitali), anche se i due mondi sono sicuramente meno divisi di quanto ci piacerebbe, vuoi perche' la causa primaria di invecchiamento dei dispositivi e' il riscaldamento, e questo chip da questo punto di vista non sembra essere problematico. Il limite saranno proprio strettamente i timing interni che sono piu' sistematici e meno soggetti a variazioni con il passare degli anni - a meno che non ci siano appunto fenomeni termici in gioco.
Infine tra cdimauro e NubeCheCorre, sono pienamente d'accordo con cdimauro: si risponda nel merito, anche contraddicendo in parte come giustamente fa m3x, perche' il dire "tu non hai i titoli per parlare" dimostra solo l'assenza di vere argomentazioni da parte di chi lo fa. Se dice castronate, dimostralo, non cercare di tappargli la bocca senza contraddirlo nei fatti.
Come ho appena detto, secondo me l'argomento e' sfuggito di mano, alcune delle tematiche citate da AmigaCori e cdimauro sono problemi concretissimi, che, per le ragioni brevemente esposte sopra, pero' non si applicano in questo caso. Secondo me, insomma, non ci sono rischi che le Sam muoiano come mosche a breve perche' si sono riconfigurati i bus, le cache e si e' proceduto a piccoli overclock. Infatti la mia osservazione partiva dal ragionamento: visto che ci sono vantaggi e non ci sono problemi evidenti, perche' non e' stato fatto dal giorno 1? Max ci ha spiegato che la documentazione di AMCC e', a riguardo, quanto meno lacunosa, e per me la cosa e' chiusa.
(non sarebbe il caso di tornare piu' strettamente ai benchmark, che tuttavia restano piuttosto impietosi per le Sam? Per quanto questo sviluppo laterale del thread sia stato davvero interessante, almeno per me)
Saluti,
Andrea