Visualizzazione dei risultati da 1 a 8 su 8
  1. #1

    architettura interna athlon fx-55

    Salve ragazzi!
    Mi sto documentando o meglio sto cercando di documentarmi, per bene sul nuovo processore amd, l'athlon fx-55..
    Ho trovato svariate notizie sulle sue caratteristiche, però ci sono certe cose che, da pivello novellino quale sono, non capisco:
    - cos'è il Core di un processore.
    - le due cache L1 e L2 stanno nel processore entrambe oppure solo la L1?
    - In cosa si differenzia a livello fisico ed elettronico la nuova "configurazione" a 64 bit da quella a 32 bit.
    - Per i programmi di adesso ha senso prendere un processore a 64 bit oppure non conviene?

    Ecco.. dovrebbe essere tutto.. non nego che magari vi chiederò altro, ma per ora questo è quanto!

    Attendo vostre notizie!
    Grazie mille!
    C.

  2. #2

    Re: architettura interna athlon fx-55

    Originariamente inviato da Cool No.9
    - cos'è il Core di un processore.
    In parole povere, l'integrato principale, la fettina di silicio dove stanno i transistor che costituiscono il processore. Un core pero', da solo non potrebbe essere venduto (ne, praticamente, usato), in quanto le connessioni dei microcircuiti del core con l'esterno sarebbero estremamente difficili; il core viene quindi montato su una basetta di materiale ceramico/plastico/organico in modo da facilitare la connessione con l'esterno.
    Nel caso degli athlon64 la basetta e' relativamente piccola e il core e' coperto da una lastra metallica protettiva, cosi' puo' non essere facile distinguerli se non si sa dove guardare
    Con gli athlon XP/sempron si vede meglio, perche' il core e' scoperto e la basetta piu' grossa, in proporzione.
    - le due cache L1 e L2 stanno nel processore entrambe oppure solo la L1?
    Nel caso degli athlon64 si. Non ricordo la definizione esatta, ma mi pare proprio che neanche la L1 debba necessariamente stare nel processore (nello stesso integrato cioe'). Ovviamente di solito almeno la L1 si integra per questioni di efficienza
    - In cosa si differenzia a livello fisico ed elettronico la nuova "configurazione" a 64 bit da quella a 32 bit.
    Troppo specialistico, non so risponderti, a parte il fatto che un athlon64 ha piu' pin di un athlon
    Credo che per rispondere bene occorrano informazioni non in possesso del grande pubblico; comunque, se cerchi su siti come x86-secret.com o arstechnica.com dovresti trovare qualcosa.
    - Per i programmi di adesso ha senso prendere un processore a 64 bit oppure non conviene?
    Dipende da quel che usi, ci sono benchmark interessanti in giro. Povray mi pare guadagni il 25% solo ricompilando, alcuni database SQL tipo il 15%. E parlo solo di prestazioni pure, se uno ha bisogno di piu' di 4 giga di ram per processo c'e' poca scielta

    In generale, amd64 (x86-64) e' una buonissima architettura, sia per gli standard x86 sia, direi, in assoluto, e porta in quanto tale numerosi vantaggi: minor latenza sulla memoria, supporto NUMA, I/O velocissimo, risparmio energetico... Un athlon64 e' un'ottimo acquisto anche se lo si tiene a 32 bit.
    "Qualsiasi esperto ha paura di combattere usando la katana vera. Anch'io. Ma non ignoro la mia paura, riesco ad accettarla, e a metterla da parte accanto a me".

  3. #3
    forte... non pensavo ci fosse da sapere così tanto su un processore... comunque leggendo l'esauriente risposta mi sono spuntati altri dubbi:

    - cosa è il supporto NUMA.
    - da quel che ho capito sia AMD sia Intel utilizzano per i loro processori la famiglia degli x86. ora se volessi programmare in assembler con un processore intel utilizzerei il set di istruzioni che sono presentate su un libro che ho che tratta la programmazione dei microprocessori Intel, però ha senso utilizzare lo stesso set di istruzioni per un processore amd dal momento che entrambe le case produttrici si basano sull'architettura dell' x86?
    Cerco di spiegarmi meglio: il set di istruzioni dell'amd è lo stesso dell'intel o no?

  4. #4
    Originariamente inviato da Cool No.9
    forte... non pensavo ci fosse da sapere così tanto su un processore... comunque leggendo l'esauriente risposta mi sono spuntati altri dubbi:

    - cosa è il supporto NUMA.
    - da quel che ho capito sia AMD sia Intel utilizzano per i loro processori la famiglia degli x86. ora se volessi programmare in assembler con un processore intel utilizzerei il set di istruzioni che sono presentate su un libro che ho che tratta la programmazione dei microprocessori Intel, però ha senso utilizzare lo stesso set di istruzioni per un processore amd dal momento che entrambe le case produttrici si basano sull'architettura dell' x86?
    Cerco di spiegarmi meglio: il set di istruzioni dell'amd è lo stesso dell'intel o no?
    alcuni set sono uguali (mmx, sse, sse2, sse3 (quest'ultimo solo negli ultimi core a64)) altri no come per l'amd del 3dnow!

    preciso il discorso di prima dicendo che sia l1 che l2 sono sullo stesso silicio (se ritrovo qualche img le linko )

    Ciao!
    .:Notebook::ASUS A2546KUH::SO::WinXP Pro SP2 ENG + Firefox 1.5::FastWeb ADSL 6Mbit:.

  5. #5
    Originariamente inviato da Cool No.9
    - cosa è il supporto NUMA.
    Non sono molto ferrato in materia, devo ammettere.
    NUMA sta per Non Uniform Memory Access.
    In parole povere dovrebbe trattarsi di questo:
    In un sistema multiprocessore, i vari opteron sono connessi direttamente mediante link hypertransport ad alta velocita`.
    Ogni processore ha un proprio controller ram (single channel o dual channel), cosi` ogni processore ha un proprio insieme di memoria cui puo` accedere direttamente. Qualora pero` un processore abbia necessita` di accedere a dati che risiedono nella memoria controllata da un'altro processore, come si fa?

    Se il controller RAM fosse esterno, perche` un processore possa accedere ad una data area di memoria, gli basterebbe fare una richiesta al controllore della memoria (infatti questo dovrebbe essere UMA, Uniform Memory Access); ma cosi` non e`, e occorre trovare una soluzione...

    E questa soluzione se ben ricordo/a quanto ne so, consiste nel connettere i vari processori medianti collegamenti privati ad alta velocita` (si tratta di link hypertransport come quelli verso l'I/O), in modo da permettergli un'accesso indiretto alla memoria.
    Ora: non so come avvenga questo in pratica, se cioe` ci sia la mediazione del controller RAM del processore chiamato oppure altro (a logica direi che almeno il controller RAM dovrebbe essere interpellato), e anche quanto ho detto sopra deve essere preso cum grano salis
    Quel che conta e` che i numeri dicono che la soluzione funziona, la scalabilita` degli opteron e` li` a dimostrarlo

    Cerco di spiegarmi meglio: il set di istruzioni dell'amd è lo stesso dell'intel o no?
    Certamente, altrimenti il software cosi` com'e` non potrebbe funzionare, andrebbe come minimo ricompilato.
    Cambiano le estensioni disponibili e il modo in cui programmare per spremere prestazioni: del codice ottimizzato per athlon potrebbe non essere gradito ad un pentium4, e viceversa.
    "Qualsiasi esperto ha paura di combattere usando la katana vera. Anch'io. Ma non ignoro la mia paura, riesco ad accettarla, e a metterla da parte accanto a me".

  6. #6
    Originariamente inviato da Ikitt
    Non sono molto ferrato in materia, devo ammettere.
    NUMA sta per Non Uniform Memory Access.
    In parole povere dovrebbe trattarsi di questo:
    In un sistema multiprocessore, i vari opteron sono connessi direttamente mediante link hypertransport ad alta velocita`.
    Ogni processore ha un proprio controller ram (single channel o dual channel), cosi` ogni processore ha un proprio insieme di memoria cui puo` accedere direttamente. Qualora pero` un processore abbia necessita` di accedere a dati che risiedono nella memoria controllata da un'altro processore, come si fa?

    Se il controller RAM fosse esterno, perche` un processore possa accedere ad una data area di memoria, gli basterebbe fare una richiesta al controllore della memoria (infatti questo dovrebbe essere UMA, Uniform Memory Access); ma cosi` non e`, e occorre trovare una soluzione...

    E questa soluzione se ben ricordo/a quanto ne so, consiste nel connettere i vari processori medianti collegamenti privati ad alta velocita` (si tratta di link hypertransport come quelli verso l'I/O), in modo da permettergli un'accesso indiretto alla memoria.
    Ora: non so come avvenga questo in pratica, se cioe` ci sia la mediazione del controller RAM del processore chiamato oppure altro (a logica direi che almeno il controller RAM dovrebbe essere interpellato), e anche quanto ho detto sopra deve essere preso cum grano salis
    Quel che conta e` che i numeri dicono che la soluzione funziona, la scalabilita` degli opteron e` li` a dimostrarlo


    Certamente, altrimenti il software cosi` com'e` non potrebbe funzionare, andrebbe come minimo ricompilato.
    Cambiano le estensioni disponibili e il modo in cui programmare per spremere prestazioni: del codice ottimizzato per athlon potrebbe non essere gradito ad un pentium4, e viceversa.
    ecco un img dell'a64: link come si vede dall'img sia la cache l1 che l2 sono all'interno del core

    per il fatto delle istruzione ovviamente molte sono uguali altrimenti, come dicevi, sarebbe impossibile far girare gli stessi programmi sulle due cpu...ovviamente poi, come ho detto sopra, ci son istruzioni proprietarie che permettono appunto di ottenere e ottimizzare determinati prog per 'una e l'altra cpu (vedi ht dei p4).

    Ciao!
    .:Notebook::ASUS A2546KUH::SO::WinXP Pro SP2 ENG + Firefox 1.5::FastWeb ADSL 6Mbit:.

  7. #7
    ...(senza parole)...

    Ma come fate a sapere tutta 'sta roba??
    Comunque grazie ancora, siete MITICI!!

    Alla prossima!

  8. #8
    Originariamente inviato da Cool No.9
    ...(senza parole)...

    Ma come fate a sapere tutta 'sta roba??
    Comunque grazie ancora, siete MITICI!!

    Alla prossima!
    esperienza e molta lettura (sopratutto di forum e recensioni )

    Ciao!
    .:Notebook::ASUS A2546KUH::SO::WinXP Pro SP2 ENG + Firefox 1.5::FastWeb ADSL 6Mbit:.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2026 vBulletin Solutions, Inc. All rights reserved.