# architettura dual core a 64 bit: amd o intel?

## dema

ho intenzione di passare ad una architettura dual core a 64 bit ma sono un pò confuso... avrei intezione di prendere un intel core 2 duo ma non ho capito se poi questa scelta comporti delle limitazioni relative al software disponibile...

mi sembra di aver capito che se acquistassi un intel core 2 duo dovrei seguire l'installazione per amd64, giusto? se si tutto il software disponibile per amd64 dovrebbe essere disponibile anche per l'architettura di intel, o sbaglio?

in definitiva, ai fini della compatibilità con gentoo (che è la cosa che conta di più per me) è meglio acquistare un amd o è indifferente?

grazie!

stefano

edit: mi sono reso conto (in ritardo) che forse in questa sezione sono OT...  :Sad: 

----------

## xveilsidex

io prenderei sicuramente intel.. a parte il fatto che è piu' performante e poi penso che come architettura sia piu' compatibile rispetto a quella di amd 64

----------

## dema

infatti io mi ero orientato verso intel proprio per questioni di performance... solo che non sono riuscito a capire il livello di compatibilità del software rispetto all'architettura di amd...

----------

## randomaze

Moved from Forum italiano (Italian) to Forum di discussione italiano.

----------

## .:chrome:.

si, ma... attenzione...!

Intel implementa EM64T che è una tencologia con due scopi:

- indirizzare la memoria a 64 bit (che non vuol dire che la banda raddoppia)

- essere in grado di eseguire alcune istruzioni a 64 bit (guardacaso quelle di indirizzamento della memoria)

ma il processore, in sé è e rimane a 32 bit.

lo stesso vale per AMD.

i 64 bit nelle architetture x86 commerciali non sono nient'altro che tanto fumo e neinte arrosto. vili operazioni commerciali e niente di più.

indiscrezioni da parte di Intel dicono che forse arriveranno dei processori a 64 bit veri con la terza generazione core.

vuoi un processore che sia davvero a 64 bit? hai solo due possibilità: Intel Xeon serie 5100 o Intel Itanium.

----------

## randomaze

 *xveilsidex wrote:*   

> penso che come architettura sia piu' compatibile rispetto a quella di amd 64

 

Cosa intendi con più compatibile? Nei confronti di chi? L'architettura EM64T è stata inventata da AMD, mi riesce difficile credere che Intel sia più compatibile di AMD nei confronti di AMD stessa.

 *.:chrome:. wrote:*   

> i 64 bit nelle architetture x86 commerciali non sono nient'altro che tanto fumo e neinte arrosto. vili operazioni commerciali e niente di più.

 

Beh, quello che interessa il 90% di utenti non è sapere se il proprio processore è a 32, 64 o 128 bit ma solo che è al passo con i tempi, senza il minimo interesse per i dettagli implementativi.

Peraltro la vile operazione commerciale consente di superare i limiti di indirizzamento della vecchia architettura a 32 bit, e anche se le altre istruzioni sono sostanzialmente le stesse di prima un limite è stato superato. Con il tempo arriveranno anche gli altri, quando ci sarà bisogno  :Wink: 

----------

## .:chrome:.

 *randomaze wrote:*   

> Peraltro la vile operazione commerciale consente di superare i limiti di indirizzamento della vecchia architettura a 32 bit, e anche se le altre istruzioni sono sostanzialmente le stesse di prima un limite è stato superato. Con il tempo arriveranno anche gli altri, quando ci sarà bisogno 

 

non so te... ma io non ho mai considerato molto grave il fatto di non poter indirizzare più di 4 GB di memoria sul mio desktop.

la questione è che i 64 bit veri sono completamente diversi da quelli finti di adesso e dalle architetture a 32 bit.

tanto varrebbe tenersi architetture ben ottimizzate a 32 bit, sulle quali il software è anche più testato e meglio funzionante, no?

----------

## randomaze

 *.:chrome:. wrote:*   

> non so te... ma io non ho mai considerato molto grave il fatto di non poter indirizzare più di 4 GB di memoria sul mio desktop.

 

Beh dipende da quello che vuoi fare con il desktop. Dieci anni fa con il 386 facevo partire X e fvwm in 8Mb senza nessun problema. Oggi credo che sia un pò difficile.

Io ho superato gli 1,5G (700reali+1G swap)solo quando con imagemagick cercavo di ruotare di 45 gradi una foto.

Per quello giochicchiandoci un poco ho visto hugin e un pò di foto a 10Mp potrebbero andare ben oltre i suddetti 4G.

----------

## Luca89

 *randomaze wrote:*   

> Io ho superato gli 1,5G (700reali+1G swap)solo quando con imagemagick cercavo di ruotare di 45 gradi una foto.
> 
> Per quello giochicchiandoci un poco ho visto hugin e un pò di foto a 10Mp potrebbero andare ben oltre i suddetti 4G.

 

Cioé il classico uso che fa l'utente di un pc è quello di ruotare una fotografia di 10 megapixel?

----------

## randomaze

 *Luca89 wrote:*   

> Cioé il classico uso che fa l'utente di un pc è quello di ruotare una fotografia di 10 megapixel?

 

Non lo vedo così strano, le nuove reflex hanno quella risoluzione.

In ogni caso da 10 anni a questa parte il mondo continua a muoversi con le stesse istruzioni macchina (certo, a parte mmx, sse e altre simili) e aumentando la memoria a dismisura. Sei sicuro che entro l'anno un desktop "minimo" non superi il Gb di richieste? E se quello è il minimo lo sborone lo vorrà 4 volte tanto.

----------

## .:chrome:.

 *.:chrome:. wrote:*   

> non so te... ma io non ho mai considerato molto grave il fatto di non poter indirizzare più di 4 GB di memoria sul mio desktop

 

errata corrige: sono 16 GB, non 4 GB

la questione è comuque un'altra (e purtroppo siamo finiti OT), cioé quale delle due architetture "a 64 bit" sia migliore...

secondo me il vero problema è che i 64 bit gli utenti SOHO non li vedranno per un bel po', e che quei processori non sono a 64 bit, nella realtà, quindi da questo punto di vista uno vale l'altro, visto che sono due bidoni uguali.

il mio personalissimo consiglio è però quello di stare in casa Intel, perché ora come ora, i core 2 duo sono i migliori processori x86 che ci siano in giro

----------

## dema

 *.:chrome:. wrote:*   

> la questione è comuque un'altra (e purtroppo siamo finiti OT), cioé quale delle due architetture "a 64 bit" sia migliore...

 

Grazie  :Wink: 

Ad ogni modo la mia domanda era un'altra. Quello che interessa a me e' sapere se dal punto di vista della disponibilita' del software ci sono delle differenze tra prendere un amd64 piuttosto che un em64t. 

Quello che mi sembra di aver capito e' che l'architettura gentoo per em64t (e quindi per i core 2 duo) e' AMD64 e quindi ho pensato che tutto cio' che e' disponibile per un sistema basato su amd64 sia disponibile anche per un sistema basato su em64t. 

Poi pero' cercando informazioni in giro per i vari forums.gentoo.org mi sembra di aver letto che, ad esempio, il JDK di blackdown non funziona su un em64t (il link di riferimento e' questo: https://forums.gentoo.org/viewtopic.php?t=225828)... 

mi e' quindi sorto il dubbio che acquistare un processore basato su em64t si possa tradurre in una serie di limitazioni con conseguente danno permanente per fegato e nervi...  :Wink: 

A questo punto, in base alle vostre conoscenze in merito, vi risultano problemi di questo tipo o posso andare tranquillo e acquistare un core 2 duo?

----------

## .:chrome:.

 *dema wrote:*   

> Quello che mi sembra di aver capito e' che l'architettura gentoo per em64t (e quindi per i core 2 duo) e' AMD64 e quindi ho pensato che tutto cio' che e' disponibile per un sistema basato su amd64 sia disponibile anche per un sistema basato su em64t. 

 

sì. è corretto, ma forse avrai anche letto in giro per i forum che l'architettura AMD64 non è collaudatissima.

ad oggi non so di preciso come stiano le cose (lavish, se non ricordo male, può darti delle buone informazioni a riguardo), ma quello che è certo è che una certa parte del codice ha qualche problemino ad eseguire su AMD64

 *dema wrote:*   

> mi e' quindi sorto il dubbio che acquistare un processore basato su em64t si possa tradurre in una serie di limitazioni con conseguente danno permanente per fegato e nervi... 

 

se posso permettermi un consiglio, ti direi di prendere una EM64T, ma di usare qualche accorgimento.

quelle poche macchine che ho con EM64T le ho trattate come x86. niente indirizzamento di memoria a 64 bit, né registri estesi, né codice a 64 bit. tanto, come ho avuto modo di dire, il processore è e rimane a 32 bit, e quello che conta (protezione delle pagine di memoria, execution-disable, e indirizzo della memoria a 64 bit [*]) lo si può fare ugualmente anche a 32 bit.

permettimi però un piccolo OT (neanche tanto, in fondo): a me è sembrato di capire che tu hai bisogno di una certa potenza, che ti farebbero comodo i 64 bit, e che vuoi un po' di tranquillità sulla stabilità dell'architettura.

perché non prendi in considerazione un'architettura diversa da x86? magari UltraSPARC o PA-RISC? sono ugualmente supportate da Gentoo, tecnologicamente sono anni luce davanti rispetto ai nostri PC, e ormai non costano più un capitale

[*] l'indirizzamento a 64 bit della memoria è disponibile con il kernel 2.6.18

----------

## dema

 *.:chrome:. wrote:*   

> ad oggi non so di preciso come stiano le cose (lavish, se non ricordo male, può darti delle buone informazioni a riguardo), ma quello che è certo è che una certa parte del codice ha qualche problemino ad eseguire su AMD64

 

allora si attendono consigli e aggiornamenti sullo stato dell'arte del profilo adm64 da lavish...!  :Very Happy: 

 *.:chrome:. wrote:*   

> se posso permettermi un consiglio, ti direi di prendere una EM64T, ma di usare qualche accorgimento.
> 
> quelle poche macchine che ho con EM64T le ho trattate come x86. niente indirizzamento di memoria a 64 bit, né registri estesi, né codice a 64 bit. tanto, come ho avuto modo di dire, il processore è e rimane a 32 bit, e quello che conta (protezione delle pagine di memoria, execution-disable, e indirizzo della memoria a 64 bit [*]) lo si può fare ugualmente anche a 32 bit.

 

sono bene accetti tutti i consigli di natura costruttiva...  :Wink: 

questa in effetti potrebbe essere un'ottima soluzione. se ho ben capito quindi tu mi stai consigliando di trattare l'em64t come un comune x86 in modo da poter utilizzare il profilo x86 con tutti i vantaggi del caso, giusto?

 *.:chrome:. wrote:*   

> perché non prendi in considerazione un'architettura diversa da x86? magari UltraSPARC o PA-RISC? sono ugualmente supportate da Gentoo, tecnologicamente sono anni luce davanti rispetto ai nostri PC, e ormai non costano più un capitale

 

anche questa potrebbe essere una soluzione... provero' a prenderla in considerazione...

grazie

----------

## mambro

Dipende dall'uso.. ma con SPARC non avrebbe problemi di compatibilità enormi? Ce li ho io con PowerPC (Flash ancora inesistente e plugin java per firefox esistente da poco tempo..) che dovrebbe essere ben più diffuso, non oso immaginare con SPARC.

Da quel che ho capito dema vorrebbe avere tutto il parco software disponibile per il profilo x86.. facendo un giro su http://packages.gentoo.org/  mi sembra di capire che ben poca roba ha la flag per SPARC..

----------

## riverdragon

 *.:chrome:. wrote:*   

>  *.:chrome:. wrote:*   non so te... ma io non ho mai considerato molto grave il fatto di non poter indirizzare più di 4 GB di memoria sul mio desktop 
> 
> errata corrige: sono 16 GB, non 4 GB

 OT: è corretto 4 GB, su un processore a 32 bit lo spazio di indirizzamento in memoria è 2^32=4'294'967'296, con l'indirizzamento verticale ogni valore "indicizza" un byte. A 64 bit invece 2^64=18'446'744'073'709'551'616, cioè 16384 petabyte o 16 exabyte  :Shocked:  non esiste nemmeno un filesystem per dischi fissi in grado di gestire così tanto spazio... ext4 dovrebbe arrivare a 1024 petabyte  :Laughing: 

----------

## xdarma

 *.:chrome:. wrote:*   

> permettimi però un piccolo OT (neanche tanto, in fondo): a me è sembrato di capire che tu hai bisogno di una certa potenza, che ti farebbero comodo i 64 bit, e che vuoi un po' di tranquillità sulla stabilità dell'architettura.
> 
> perché non prendi in considerazione un'architettura diversa da x86? magari UltraSPARC o PA-RISC? sono ugualmente supportate da Gentoo, tecnologicamente sono anni luce davanti rispetto ai nostri PC, e ormai non costano più un capitale

 

Scusami se ti trascino nell'OT, ma ppc64 come ti sembra?

Sono macchine relativamente diffuse (leggi G5 dell'Apple) e che vantano un minimo di supporto sotto Gentoo.

Oltretutto in confronto a UltraSPARC presumo abbiano anche un minor costo per bogomips.

----------

## bender86

 *mambro wrote:*   

> Dipende dall'uso.. ma con SPARC non avrebbe problemi di compatibilità enormi? Ce li ho io con PowerPC (Flash ancora inesistente e plugin java per firefox esistente da poco tempo..) che dovrebbe essere ben più diffuso, non oso immaginare con SPARC.
> 
> Da quel che ho capito dema vorrebbe avere tutto il parco software disponibile per il profilo x86.. facendo un giro su http://packages.gentoo.org/  mi sembra di capire che ben poca roba ha la flag per SPARC..

 

In fondo basterebbe che funzionassero i programmi che servono a lui, non ci si compra una macchina grossa e potente per navigare sui siti in flash. Però è vero che essendo un'architettura non molto diffusa potrebbero esserci delle incompatibilità: ad esempio non funziona java (su Gentoo). Inoltre Gentoo su UltraSPARC ha solo il kernel a 64 bit, l'userland rimane a 32 (salvo profili sperimentali).Last edited by bender86 on Sun Nov 19, 2006 5:06 pm; edited 1 time in total

----------

## .:chrome:.

 *xdarma wrote:*   

> Scusami se ti trascino nell'OT, ma ppc64 come ti sembra?
> 
> Sono macchine relativamente diffuse (leggi G5 dell'Apple) e che vantano un minimo di supporto sotto Gentoo.
> 
> Oltretutto in confronto a UltraSPARC presumo abbiano anche un minor costo per bogomips.

 

su PPC64 non mi posso pronunciare, perché non l'ho mai provata.

però il fatto che Apple l'abbia abbandonata (ha sostituito i processori della linea PowerMac con gli Intel Xeon serie 5100) fa presupporre che lo sviluppo e il testing rallenteranno un bel po', dal momento che rimarranno solo sui server IBM di fascia alta

----------

## mambro

 *bender86 wrote:*   

> 
> 
> In fondo basterebbe che funzionassero i programmi che servono a lui, non ci si compra una macchina grossa e potente per navigare sui siti in flash. 

 

Si ovvio, il flash era solo un esempio   :Wink:   Era per dire che con uno SPARC ci perde di sicuro in compatibilità.. deve vedere se tutto ciò che gli serve è supportato..

----------

## dema

scusate, forse mi sono spiegato male (o forse non l'ho proprio detto) e sono stato frainteso... 

a me non serve un macchina particolarmente potente... mi serve solo una macchina al passo con i tempi, che mi permetta di non dover cambiare PC almeno per i prossimi 3-4 anni, che mi permetta di abbassare un po' tempi di compilazione (da qui la scelta di orientarmi verso un dual core), che mi permetta di fare del video editing, cosi' come poter fare le cose piu' banali come navigare (anche sui siti in flash...  :Wink:  ), scrivere un documento in latex, fare un presentazione con openoffice, ecc...

insomma, tutte cose abbastanza banali ma per le quali occorre una architettura piuttosto diffusa come potrebbe essere x86 o amd64 (che, a quanto mi pare di aver visto, e' la seconda architettura piu' supportata dopo, ovviamente, x86)...

in seguito a queste considerazioni avevo pensato di acquistare un x86_64 dual core... pensiero dal quale e' nato il dubbio (meglio amd o intel?) che mi ha spinto a chiedere consiglio a voi...

dal momento che scegliere amd piuttosto che intel e' abbastanza indifferente (per fare una citazione... tanto sono due bidoni uguali...  :Wink:  ) penso che acquistero' un intel dato che risultano essere piu' perfomanti degli amd e il supporto in gentoo e' identico...

----------

## GiRa

Parlo da possessore di AMD64 signle core.

Premessa: teoricamente una persona dovrebbe prendere un 64bit solo se ha bisogno di indirizzare tanta memoria (con un DBMS ad esempio).

Io ho preso l'Athlon64 perchè (ai tempo):

 - aveva un pipeline fantastica rispetto alla concorrenza

 - andava molto di più a parità di costo

Impressioni in ordine sparso:

Uso Gentoo a 64 bit però è una rottura avviare le applicazioni a 32 dato che hai sempre un po' di lag.

Mi sembra (nel senso che ho fatto il confronto con qualche ebuild ma non scentificamente) che compili più in fretta in ambiente a 64bit che a 32.

Wine va molto meglio su un PentiumM 1,5GHz che su un Athlon64.

Al momento gli Intel hanno prestazioni maggiori, io prederei un Intel. Magari usandolo come un dualcore a 32bit.

----------

## dema

 *GiRa wrote:*   

> Uso Gentoo a 64 bit però è una rottura avviare le applicazioni a 32 dato che hai sempre un po' di lag.

 

a questo punto sarebbe utile sapere da un utilizzatore di amd64 quali o magari quante sono le applicazioni di uso piu' comune (mi riferisco ad esempio a flash, jre, ecc..) che necessitano di essere avviate in ambiente a 32 bit...

 *GiRa wrote:*   

> Mi sembra (nel senso che ho fatto il confronto con qualche ebuild ma non scentificamente) che compili più in fretta in ambiente a 64bit che a 32.

 

a tuo parere, la differenza e' visibile o trascurabile...?

----------

## mambro

 *dema wrote:*   

> 
> 
> a questo punto sarebbe utile sapere da un utilizzatore di amd64 quali o magari quante sono le applicazioni di uso piu' comune (mi riferisco ad esempio a flash, jre, ecc..) che necessitano di essere avviate in ambiente a 32 bit...

 

Firefox (per usare il plugin flash) e mplayer (per usare alcune  codec binari disponibili solo per x86)

----------

## .:chrome:.

 *dema wrote:*   

> a tuo parere, la differenza e' visibile o trascurabile...?

 

rispondere a questa domanda è impossibile. non esistono parametri di confronto.

io direi di fare una cosa: prendi quello che ti pare, ma tieniti l'ambiente a 32 bit.

se prendi un processore con indirizzamento della memoria a 64 bit, la attivi nel kernel.

così tutti sono contenti. tu hai una macchina veloce, e il software è compatibilissimo

----------

## gioi

Sinceramente non capisco l'associazione maggior numero di bit -> velocità che spesso si fa.

I 64 bit virtuali della tecnologia em64t, servono, oltre che ad aumentare (sempre virtualmente) la memoria indirizzabile, a mettere a disposizione istruzioni in grado di lavorare con operandi di dimensione maggiore. Ma tali istruzioni non sono sicuramente mappate direttamente in hw, ma vengono tradotte "dinamicamente" dal processore, nella sequenza di istruzioni semplici corrispondenti. Cioè quindi una sorta di aggravio del processore nella traduzione delle stesse, rispetto ad un'ipotetica esecuzione diretta (come sugli sparc?)

Di contro, va detto, che non è dato sapere se, invece, in fase di compilazione, la presenza di registri virtuali più ampi, permette livelli di ottimizzazione del codice più performanti. Però, a livello hw, qualsiasi ottimizzazione andrebbe cmq tradotta nuovamente nella corrispondente procedura a 32 bit, perdendo, di fatto, ogni beneficio...

Partendo da queste considerazioni, IMHO, em64t non permette l'esecuzione più veloce delle singole istruzioni.

L'implementazione dell'EM64T porta sicuramente altri benefici... ad esempio, utilizzare un'istruzione virtuale (mappate in hw in una sequenza specifica) per eseguire una determinata operazione piuttosto che mille sequenze di codice diverso, permette un'esecuzione più fluida e ottimale. 

Questo significa che per determinati compiti l'EM64T permette un codice più ottimizzato, che porta benefici prestazionali probabilmente marginali, ma che dal punto di vista dell'esecuzione è molto proficuo, sia in termini di affidabilità del codice che IMHO, di utilizzo della potenza di calcolo (e quindi dei consumi e della potenza dissipata).

----------

## devilheart

 *dema wrote:*   

>  *GiRa wrote:*   Uso Gentoo a 64 bit però è una rottura avviare le applicazioni a 32 dato che hai sempre un po' di lag. 
> 
> a questo punto sarebbe utile sapere da un utilizzatore di amd64 quali o magari quante sono le applicazioni di uso piu' comune (mi riferisco ad esempio a flash, jre, ecc..) che necessitano di essere avviate in ambiente a 32 bit...
> 
> a tuo parere, la differenza e' visibile o trascurabile...?

 uso gentoo su amd64 da due anni e le uniche applicazioni a 32bit che uso sono i giochi proprietari

----------

## .:chrome:.

 *gioi wrote:*   

> Sinceramente non capisco l'associazione maggior numero di bit -> velocità che spesso si fa.

 

colpa di chi vuole per forza ragionare troppo, quando non sarebbe il caso di farlo (o di lasciarlo fare a qualcuno più bravo), e del fiorire di riviste ed e-zine di informatica che hanno al stessa autorevolezza del mio cane

----------

## dema

 *.:chrome:. wrote:*   

>  *dema wrote:*   a tuo parere, la differenza e' visibile o trascurabile...? 
> 
> rispondere a questa domanda è impossibile. non esistono parametri di confronto.

 

avevo preso spunto da questi bench (http://www.linuxhardware.org/article.pl?sid=06/08/22/0415251) per fare la domanda: volevo capire se le differenze nei risultati ottenuti sono visibili o se sono pippe mentali di cui ci si rende conto solo con i benchmark...

 *.:chrome:. wrote:*   

> io direi di fare una cosa: prendi quello che ti pare, ma tieniti l'ambiente a 32 bit.
> 
> se prendi un processore con indirizzamento della memoria a 64 bit, la attivi nel kernel.
> 
> così tutti sono contenti. tu hai una macchina veloce, e il software è compatibilissimo

 

ok!  :Very Happy: 

grazie a tutti per i consigli che mi sono stati dati finora!

----------

## mambro

 *.:chrome:. wrote:*   

> 
> 
> io direi di fare una cosa: prendi quello che ti pare, ma tieniti l'ambiente a 32 bit.
> 
> se prendi un processore con indirizzamento della memoria a 64 bit, la attivi nel kernel.
> ...

 

Scusa l'ignoranza.. ma il profilo amd64 allora a cosa serve? che vantaggi porta?

----------

## .:chrome:.

 *dema wrote:*   

> avevo preso spunto da questi bench (http://www.linuxhardware.org/article.pl?sid=06/08/22/0415251) per fare la domanda

 

se i test fossero stati fatti con processori più o meno identici, con la stessa frequenza, lo stesso quantitativo di cache, e installati sullo stesso sistema, sarebbe un conto... ma lì si fanno dei paragoni secondo me difficili. sicuramente le differenze ci sono, ma sono sempre da prendere con le pinze.

e poi c'è sempre il problema dei benchmark: non tutte e architetture (ovviamente) sono pensate per fare le stesse cose, quindi è difficile realizzare una suite di test che misuri le reali differenze senza tenere conto dei punti in cui un processore può essere favorito o penalizzato

 *mambro wrote:*   

> Scusa l'ignoranza.. ma il profilo amd64 allora a cosa serve? che vantaggi porta?

 

infatti io non ho detto che quello è il normale utilizzo dei processodi AMD64. è quello che ne farei io alla luce dei noti problemi di compatibilità di queste piattaforme verso il codice ordinario.

quanto alla possibilità di indirizzare comunque la memoria a 64 bit, è storia recentissima: è arrivata con il kernel 2.6.18

l'execution-disable è invece abilitabile via BIOS sui core 2 duo, mentre non so se AMD64 preveda questa possibilità. è comunque una funzione sempre implementabile in software senza nessun overhead

----------

## GiRa

Allora: vi potrei postare i risultati di genlop per qualche ebuild compilate con le stesse flag sullo stesso sistema in un'altra partizione sui dischi che uso (WD Raptor 10000rpm).

Però ripeto: il bello degli AMD64 è la pipeline, son passati più di due anni però quindi, ripeto, io direi di restare a 32bit e di scegliere il processore più performante.

Oppure se volete attendere le mie impressioni di utilizzo dello stesso sistema ricompilato a 32bit :p

----------

## gioi

 *mambro wrote:*   

> 
> 
> Scusa l'ignoranza.. ma il profilo amd64 allora a cosa serve? che vantaggi porta?

 

Beh, non credo che l'unico motivo per cui sia presente un profilo amd64 sia quello della presenza di registri (virtuali) a 64bit nel processore...

Credo che le ottimizzazioni di compilazione generali per questa architettura, vadano ben aldilà della tecnologia EM64T, che tra l'altro e IMHO, non è che trova applicazioni e porta benefici a tutti i generi di applicativi.

Secondo me ha senso creare un profilo del genere proprio per separare la parte che beneficia dell'EM64T da quella che non se ne fa nulla! Il tutto all'interno dello stesso sistema...

----------

## .:chrome:.

 *gioi wrote:*   

>  *mambro wrote:*   
> 
> Scusa l'ignoranza.. ma il profilo amd64 allora a cosa serve? che vantaggi porta? 
> 
> Beh, non credo che l'unico motivo per cui sia presente un profilo amd64 sia quello della presenza di registri (virtuali) a 64bit nel processore...

 

oddio. mi avete messo la pulce nell'orecchio, e ho provato a fare questo:

```
diff -aNru /usr/portage/profiles/default-linux/{x86,amd64}/2006.1/desktop
```

mi aspettavo di vedere delle differenze nelle C{,XX}FLAGS, e invece... nessuna differenza

tutto quello che cambia è che l'architettura x86 usa per default USE="gpm"

----------

## bender86

 *.:chrome:. wrote:*   

> oddio. mi avete messo la pulce nell'orecchio, e ho provato a fare questo:
> 
> ```
> diff -aNru /usr/portage/profiles/default-linux/{x86,amd64}/2006.1/desktop
> ```
> ...

 

Non dovresti controllare anche le directory precedenti (/usr/portage/profiles/default-linux/x86 e /usr/portage/profiles/default-linux/x86/2006.1)? Potrebbero esserci delle impostazioni globali che vengono ereditate da lì.

----------

## gioi

 *.:chrome:. wrote:*   

>  *gioi wrote:*    *mambro wrote:*   
> 
> Scusa l'ignoranza.. ma il profilo amd64 allora a cosa serve? che vantaggi porta? 
> 
> Beh, non credo che l'unico motivo per cui sia presente un profilo amd64 sia quello della presenza di registri (virtuali) a 64bit nel processore... 
> ...

 

Non lo so, ho sempre avuto l'impressione che i nuovi profili "default" di gentoo siano solo un punto di partenza per la customizzazione delle piattaforme... nel senso che a partire dal 2006.1 li hanno differenziati, ma ancora non abbiano inserito delle vere e proprie ottimizzazioni...

In generale il profilo amd64 cui mi riferivo non era quello gentoo, ma quello dei pacchetti precompilati...

----------

## .:chrome:.

 *bender86 wrote:*   

> Non dovresti controllare anche le directory precedenti (/usr/portage/profiles/default-linux/x86 e /usr/portage/profiles/default-linux/x86/2006.1)? Potrebbero esserci delle impostazioni globali che vengono ereditate da lì.

 

ma quanto sono coglione... è vero  :Sad: 

va bene... forse è meglio che dorma, la notte  :Wink: 

----------

## gioi

Riporto in vita questo 3ad perchè oggi mi è riuscito finalmente di testare una configurazione x86_64 in condizioni di stress estremo. Premetto che per stress estremo non intendo, purtroppo, applicazioni che fanno largo uso di codice a 64 bit, ma di applicazioni server "tradizionali" compilati con le opportune flag del profilo x86_64.

Purtroppo il sistema in questione non è un fiammante Intel Core2 Duo ma un vecchio Pentium 4 6xx che funge da webserver avanzato per un gruppo di testing nell'azienda per cui lavoro. Web server avanzato significa che non gira il semplice apache, ma una serie di servizi specifici (tomcat ed ant per le web application, mysql come db, ed un motore di rendering php che si chiama php-seargent).

Il confronto fatto con la precedente installazione (una RHEL4 contro la RHEL5 x86_64 attuale) ha evidenziato una sostanziale parità di prestazioni, eccetto che per un picco di utilizzo della memoria da parte del sistema x86_64 per quanto riguarda i motori in java di ant, tomcat e php-seargent. 

Il fatto è stato analizzato "al microscopio" e si è giunti alla conclusione che tale incremento delle dimensioni della memoria occupata dai suddetti motori "java" è da imputare al link statico verso alcune funzioni di libreria reso necessario per motivi di "compatibilità" (testuali parole "tradotte" di chi ha compilato le suddette librerie).

Per adesso, perciò, l'unica differenza sostanziale (e per sostanziale si intende una differenza di almeno un ordine di grandezza nella misura considerata) è il maggior utilizzo di memoria da parte di taluni processi.

Per il resto il dibattito sul se sia meglio un profilo a 32 bit o 64 bit per i suddetti processori sembrerebbe mera disquisizione tecnica.

Spero che questo post non scateni un flame, vuole essere solo la testimonianza di un'esperienza diretta.

----------

## comio

 *gioi wrote:*   

> Riporto in vita questo 3ad perchè oggi mi è riuscito finalmente di testare una configurazione x86_64 in condizioni di stress estremo. Premetto che per stress estremo non intendo, purtroppo, applicazioni che fanno largo uso di codice a 64 bit, ma di applicazioni server "tradizionali" compilati con le opportune flag del profilo x86_64.
> 
> Purtroppo il sistema in questione non è un fiammante Intel Core2 Duo ma un vecchio Pentium 4 6xx che funge da webserver avanzato per un gruppo di testing nell'azienda per cui lavoro. Web server avanzato significa che non gira il semplice apache, ma una serie di servizi specifici (tomcat ed ant per le web application, mysql come db, ed un motore di rendering php che si chiama php-seargent).
> 
> Il confronto fatto con la precedente installazione (una RHEL4 contro la RHEL5 x86_64 attuale) ha evidenziato una sostanziale parità di prestazioni, eccetto che per un picco di utilizzo della memoria da parte del sistema x86_64 per quanto riguarda i motori in java di ant, tomcat e php-seargent. 
> ...

 

Molto interessante. Iero ero rimasto che le arch a 64bit per noi "poracci" (ho sia amd64x2 che intel core duo 2) erano meno performanti di qualche virgola percentuale (non misurabile).  Rimango su 64bit più che altro perché è la piattaforma di riferimento per il prossimo futuro (sul presente... magari siamo ancora con x86 più diffusa).

ciao

luigi

----------

## gioi

 *comio wrote:*   

> 
> 
> Molto interessante. Iero ero rimasto che le arch a 64bit per noi "poracci" (ho sia amd64x2 che intel core duo 2) erano meno performanti di qualche virgola percentuale (non misurabile).  Rimango su 64bit più che altro perché è la piattaforma di riferimento per il prossimo futuro (sul presente... magari siamo ancora con x86 più diffusa).
> 
> ciao
> ...

 

Mah! In effetti nel sistema x86_64 è stato riscontrato un decadimento delle prestazioni non sensibile (non si parla di ordini di grandezza ma, come dici tu, di decimali), ma cmq credo sia imputabile all'utilizzo di librerie in modalità "compatibile" (non tutto il parco sw può essere ancora compilato con il profilo x86_64). Il lavoro fatto in tal senso da AMD e Intel credo sia notevole, perchè non deve essere facile tenere separata l'esecuzione x86_32 reale da quella x86_64 "virtuale", soprattutto quando si parla di ottimizzazione del codice (tipo -O2 o -O3 di gcc).

Bisognerebbe vedere quali vantaggi porta la virtualizzazione dei 64bit in codice che sfrutta realmente questa possibilità (sw scientifico e multimediale, e/o cmq con operazioni fp complesse IMHO, quindi non certo openoffice o firefox!)...

----------

## power83

Io ho un Pentium D 940 3.20 GHz Dual Core e con supporto EM64T, cioe' 64bit.

Feci poco fa' l'installazione amd64 per avere tutto a 64bit e posso affermare che c'erano diversi problemi, CHE ORA SONO RISOLTI CON L'INSTALLAZIONE x86 classica.

Ad esempio X ci metteva piu' tempo ad avviarsi (faccio login da terminale, niente gdm o simili)..... poi mplayer andava a scatti, sia legendo dalla skystar2 che anche solo riproducendo divx che prima era fluidissimi.......e poi X andava in freeze spesso.......

tutto era installato bene, ora ho installato la stessa roba stessa versione a 32 bit e va da dio, non si freeza piu' nulla e mplayer e' fluido come non mai anche dal  dvb-s.  :Laughing: 

----------

## Flonaldo

 *power83 wrote:*   

> Io ho un Pentium D 940 3.20 GHz Dual Core e con supporto EM64T, cioe' 64bit.
> 
> Feci poco fa' l'installazione amd64 per avere tutto a 64bit e posso affermare che c'erano diversi problemi, CHE ORA SONO RISOLTI CON L'INSTALLAZIONE x86 classica.
> 
> Ad esempio X ci metteva piu' tempo ad avviarsi (faccio login da terminale, niente gdm o simili)..... poi mplayer andava a scatti, sia legendo dalla skystar2 che anche solo riproducendo divx che prima era fluidissimi.......e poi X andava in freeze spesso.......
> ...

 

ho il tuo stesso processore, installazione con livecd per amd64 e non ho mai avuto un problema...anzi X va a bomba, ho messo su beryl e tutto il resto...va che è un piacere!

----------

## mambro

Quindi la differenza di prezzo tra uno Yonah (core duo) e un Merom (core 2 duo) di pari frequenza e quantità di cache è inguistificata? per quel che so io l'unica differenza è EM64T e un leggero miglioramento dei consumi...

Ma non ho ben capito.. il problema è software o sono proprio queste tecnologie che nascono perdenti in partenza?

----------

## gioi

 *mambro wrote:*   

> Quindi la differenza di prezzo tra uno Yonah (core duo) e un Merom (core 2 duo) di pari frequenza e quantità di cache è inguistificata? per quel che so io l'unica differenza è EM64T e un leggero miglioramento dei consumi...
> 
> Ma non ho ben capito.. il problema è software o sono proprio queste tecnologie che nascono perdenti in partenza?

 

Dal punto di vista hw dubito che la tecnologia EM64T vada a toccare i consumi... piuttosto implica una diversa ottimizzazione del codice avanzato.

Di per sè tale tecnologia non è perdente... ci sono ancora problemini di compatibilità, che implicano l'utilizzo di parti di codice compilato senza ottimizzazioni specifiche, ma pian piano le stanno risolvendo.

Tuttavia i benefici (a lungo termine a questo punto) che tale tecnologia porterà all'utente medio difficilmente saranno visibili ad occhio nudo!

----------

## riverdragon

 *gioi wrote:*   

>  *mambro wrote:*   per quel che so io l'unica differenza è EM64T e un leggero miglioramento dei consumi... 
> 
> Dal punto di vista hw dubito che la tecnologia EM64T vada a toccare i consumi... 

 

C'è scritto "EM64T e un leggero miglioramento dei consumi", non ha parlato di dipendenza di uno dall'altro. Intel alla presentazione dei merom diceva "20% di consumo in meno, 20% di prestazioni in più". Filtra questo attraverso gli occhi non-propagandistici e hai comunque un miglioramento tra il core 2 e il core.

Non è né il software né l'hardware che nascono perdenti, la situazione è più complessa: i 64 bit servono per ovviare a limiti che al giorno d'oggi quasi nessuno sente. Chi ne ha realmente bisogno si trova in una situazione talmente particolare da poter decidere di affidarsi ad un ultrasparc senza dover scendere a compromessi. Da un punto di vista più tecnico, raddoppiare la dimensione dei registri vuol dire dimezzare il tempo con cui la memoria di sistema si satura e questa è una diretta conseguenza delle scelte "filosofiche", non dipende né dall'hardware né dal software; si potrebbe dire: o la botte piena o la moglie ubriaca. In un futuro (remoto secondo me) ci sarà bisogno di indirizzare un quantitativo maggiore di 4GB di RAM (perché questo è il limite più prossimo al superamento dell'attuale tecnologia a 32 bit) anche nel normale utilizzo del computer, e solo allora la tecnologia a 64 bit sarà realmente necessaria.

Considero quella dei 64 bit una gigantesta operazione di immagine da parte di amd: nessuno di voi ha notato che ora il profilo a 64 bit di gentoo (come di altre distro) si chiama amd64 e non in altro modo? E quante volte si è pensato (anche io in passato, lo ammetto) che intel era indietro perché non aveva i 64 bit sui propri processori? Così, alla stessa maniera in cui amd ha adottato il p-number per i propri processori per contrastare l'effetto "numeri" (parlo dei megahertz) dei pentium, così intel ha approntato velocemente le estensioni a 64 bit per il proprio pentium4 EE, e per la maggior parte dell'utenza informatica "processore potente" è sinonimo di "pentium 4" e "64 bit" è sinonimo di "AMD" (sempre se ne hanno sentito parlare  :Laughing:  )

----------

## gioi

 *riverdragon wrote:*   

>  *gioi wrote:*    *mambro wrote:*   per quel che so io l'unica differenza è EM64T e un leggero miglioramento dei consumi... 
> 
> Dal punto di vista hw dubito che la tecnologia EM64T vada a toccare i consumi...  
> 
> C'è scritto "EM64T e un leggero miglioramento dei consumi", non ha parlato di dipendenza di uno dall'altro. Intel alla presentazione dei merom diceva "20% di consumo in meno, 20% di prestazioni in più". Filtra questo attraverso gli occhi non-propagandistici e hai comunque un miglioramento tra il core 2 e il core.
> ...

 

Scusami, non avevo capito... d'altra parte se dici che la differenza è unica e poi ne elenchi due...  :Razz: 

 *Quote:*   

> 
> 
> Non è né il software né l'hardware che nascono perdenti, la situazione è più complessa: i 64 bit servono per ovviare a limiti che al giorno d'oggi quasi nessuno sente. Chi ne ha realmente bisogno si trova in una situazione talmente particolare da poter decidere di affidarsi ad un ultrasparc senza dover scendere a compromessi. Da un punto di vista più tecnico, raddoppiare la dimensione dei registri vuol dire dimezzare il tempo con cui la memoria di sistema si satura e questa è una diretta conseguenza delle scelte "filosofiche", non dipende né dall'hardware né dal software; si potrebbe dire: o la botte piena o la moglie ubriaca. In un futuro (remoto secondo me) ci sarà bisogno di indirizzare un quantitativo maggiore di 4GB di RAM (perché questo è il limite più prossimo al superamento dell'attuale tecnologia a 32 bit) anche nel normale utilizzo del computer, e solo allora la tecnologia a 64 bit sarà realmente necessaria.
> 
> Considero quella dei 64 bit una gigantesta operazione di immagine da parte di amd: nessuno di voi ha notato che ora il profilo a 64 bit di gentoo (come di altre distro) si chiama amd64 e non in altro modo? E quante volte si è pensato (anche io in passato, lo ammetto) che intel era indietro perché non aveva i 64 bit sui propri processori? Così, alla stessa maniera in cui amd ha adottato il p-number per i propri processori per contrastare l'effetto "numeri" (parlo dei megahertz) dei pentium, così intel ha approntato velocemente le estensioni a 64 bit per il proprio pentium4 EE, e per la maggior parte dell'utenza informatica "processore potente" è sinonimo di "pentium 4" e "64 bit" è sinonimo di "AMD" (sempre se ne hanno sentito parlare  )

 

In realtà la questione è più complessa, perchè il vero vantaggio dell'EM64T non è la maggiore quantità di memoria indirizzabile, ma il poter aver a disposizione macroistruzioni che lavorano su operandi di dimensioni maggiori (che poi queste non siano mappate direttamente in hw è un altro discorso)... questo tipo di approccio permette in fase di generazione del microcodice ottimizzazioni più spinte per quanto riguarda queste macroistruzioni (il programmatore invece di crearsi la sua funzione utilizza la macro suggerita dal produttore della cpu, che quindi sa in anticipo con quali microistruzioni andrà a lavorare la cpu), e quindi vantaggi che possono essere di vario tipo (dall'aumento delle prestazioni, alla riduzione dei consumi o magari entrambi).

C'ho fatto la tesi di laurea su queste cose (l'analisi del flusso di microcodice di un P4!), e se c'è una cosa che ho imparato è che conoscere a priori la tipologia di codice che verrà elaborato è l'arma vincente per incrementare le prestazioni senza ricorrere all'ormai satura accoppiata frequenza/pipeline...

Certo poi sono ASSOLUTAMENTE d'accordo con te che quelli del marketing di AMD e Intel cerchino di far passare questa tecnologia per un'innovazione molto più grossa di quello che è in realtà, ma sono convinto che, con il passare del tempo, i programmatori impareranno ad apprezzare tali estensioni, fino a farle diventare, come accadde a suo tempo per mmx e derivate, indispensabile!

----------

## riverdragon

 *gioi wrote:*   

> 
> 
> Scusami, non avevo capito... d'altra parte se dici che la differenza è unica e poi ne elenchi due... 
> 
> 

 Non ho parlato di differenza unica, ma di indipendenza tra consumi e estensioni a 64 bit; ho comunque dimenticato di separare le frasi, la seconda parte era rivolta a mambro in risposta a quali siano i miglioramenti portati da merom. 

 *gioi wrote:*   

> 
> 
> In realtà la questione è più complessa, perchè il vero vantaggio dell'EM64T non è la maggiore quantità di memoria indirizzabile, ma il poter aver a disposizione macroistruzioni che lavorano su operandi di dimensioni maggiori (che poi queste non siano mappate direttamente in hw è un altro discorso)... questo tipo di approccio permette in fase di generazione del microcodice ottimizzazioni più spinte per quanto riguarda queste macroistruzioni (il programmatore invece di crearsi la sua funzione utilizza la macro suggerita dal produttore della cpu, che quindi sa in anticipo con quali microistruzioni andrà a lavorare la cpu), e quindi vantaggi che possono essere di vario tipo (dall'aumento delle prestazioni, alla riduzione dei consumi o magari entrambi).
> 
> C'ho fatto la tesi di laurea su queste cose (l'analisi del flusso di microcodice di un P4!), e se c'è una cosa che ho imparato è che conoscere a priori la tipologia di codice che verrà elaborato è l'arma vincente per incrementare le prestazioni senza ricorrere all'ormai satura accoppiata frequenza/pipeline...

 Curiosita`: ma tali macroistruzioni devono essere sfruttate dai compilatori, o sbaglio? Io e qualunque altro programmatore "normale" non abbiamo nulla a che fare con queste macroistruzioni, ci si appoggia a codice in c/c++/python/java ecc che si suppone venga compilato nel miglior modo possibile. Altra curiosita`, queste macroistruzioni sono paragonabili ai set di istruzioni sse/sse2/sse3/ssse4?

----------

## gioi

 *riverdragon wrote:*   

> Non ho parlato di differenza unica, ma di indipendenza tra consumi e estensioni a 64 bit; ho comunque dimenticato di separare le frasi, la seconda parte era rivolta a mambro in risposta a quali siano i miglioramenti portati da merom. 
> 
> 

  Si si, avevo capito (la 2a volta)...  :Razz: 

 *Quote:*   

> Curiosita`: ma tali macroistruzioni devono essere sfruttate dai compilatori, o sbaglio? Io e qualunque altro programmatore "normale" non abbiamo nulla a che fare con queste macroistruzioni, ci si appoggia a codice in c/c++/python/java ecc che si suppone venga compilato nel miglior modo possibile. Altra curiosita`, queste macroistruzioni sono paragonabili ai set di istruzioni sse/sse2/sse3/ssse4?

 

Beh anche se non programmi in assembler sei cmq condizionato dalla presenza di queste macro. Quando queste vengono implementate nei compilatori, vengono generate cmq delle tabelle di codifica funzione_in_linguaggio_ad_alto_livello -> macro, per cui anche se non richiamate "direttamente" dal programmatore, vengono cmq sfruttate nell'esecuzione.

Questo fenomeno è accentuato nelle librerie che possono essere compilate (e quindi ottimizzate) per sfruttare queste macro... per cui la risposta è il programmatore viene pesantemente influenzato da queste estensioni, anche se non sa di usarle.

In realtà le estensioni EM64T, per quanto ne so io, non sono un vero e proprio set esteso di istruzioni SIMD (mmx,3dNow!,sse,sse2,sse3,sse^n...) ma una sorta di modalità di funzionamento che permette alle istruzioni SIMD di emulare registri a 64bit (e quindi usare operandi di maggiori dimensioni)... Cioè non c'è una sorta di mappatura aggiuntiva all'interno della rom di microcodice, ma una sorta di decoder aggiuntivo che trasforma gli operandi a 64 bit in operandi compatibili con il microcodice della cpu...

----------

## !ico

scusate, solo una precisazione che non sono riuscito a cogliere leggendo qua e la:

io ho un amd3800+x2,  per avere un sistema interamente a 32 bit (visto che da quel che ho caipto per un uso 

"normale" non cambia molto..) devo scaricare e installare le iso x86 e mettere march=i686 nel make.conf? cioè, devo comportarmi come fosse un comune x86 o c'è altro?

grazie

ola;)

----------

## Scen

No, non devi fare altro, a parte stare attento nell'usare precisamente ISO e stage i686 (non x86/i586).

Anzi, se vuoi potresti configurare le CFLAGS come se il processore fosse un Athlon XP (vedi Codice 3.1).

----------

## djinnZ

-march=athlon-xp e -O2/-O3 con l'hardening creano enormi problemi (ci sto bestemmiando dietro qualche giorno, ora il gcc è andato). Da notare che il precendente sistema (di prova) compilato con -march=athlon (o quello in uso -march=i686) non ha creato alcuna rogna.

Non chiedetemi perchè ma xp non vuol saperne di funzionare (eppure è un athlon-xp il processore).

----------

## !ico

per curiosità, come sono le tue chost e cflags complete? che processore hai?

ola  :Wink: 

----------

## djinnZ

processori: amd64 3200 e sempron 3300.

cc flag: di default -O3 -fomit-frame-pointer -pipe che diventa -O2 -fno-strict-aliasing o -Os per un paio di pacchetti (kerberos di sicuro gli altri due non li ricordo) secondo i fallimenti degli emerge ed i crash.

ld: -Wl,-O1 -Wl,--as-need (che continuo a non capire perchè inseriti usando la sintassi di gcc, ma questo è un altro problema) con --as-need che devo togliere da alcuni pacchetti. Per i,l futuro pensavo di eliminare -O1 ed usare upx (o di usarlo solo con -O2 al gcc per i programmi più "piccoli" tipo baseutils, awk etc.)  

Profilo hardened con use da desktop (folle forse ma comodo, così uso gli stessi pacchetti dappertutto).

La cosa strana è che compilando il sistema con -march=athlon o meno -march=athlon-mp nessun problema (a parte quelli noti per l'ottimizzazione) con -march=athlon-xp mi va sempre a finire prima o poi che il gcc è inservibile (smash attack e crash vari in cc1 e cc1plus), questo ogni volta che ci provo da quattro anni a questa parte. Mi sa che ricompilo -march=athlon e tanti saluti (o trovo un modo per non far compilare gcc stesso hardened) voglia e tempo di investigare il perchè manca.

----------

