Washington (USA) – Non si ferma la campagna dei discografici americani della RIAA contro gli utenti del peer-to-peer. L’associazione industriale ha infatti confermato di aver sporto formalmente denuncia contro 531 utenti .
Stando a quanto dichiarato dalla RIAA, i propri software di esplorazione dei network di file sharing hanno individuato i numeri IP degli utenti che sarebbero in questo caso tutti riconducibili a residenti di quattro grandi città americane: Orlando, Philadelphia, Trenton, Atlanta.
Al contrario di quanto accaduto in passato, le major non possono chiedere ai provider che forniscono quegli IP i nomi degli utenti perché, come si ricorderà, un tribunale ha stabilito che una richiesta di questo genere deve provenire direttamente dalla magistratura. Questo è il motivo per cui, anziché contattare i singoli utenti offrendo loro la possibilità di un accordo extra processuale, RIAA ha ora scelto di ricorrere direttamente alla denuncia.
L’operazione della RIAA ricorda da vicino quanto già avvenuto in gennaio, quando un numero pressoché identico di utenti, 532 persone, furono denunciate per le medesime attività .
“Stiamo mandando un chiaro segnale – ha affermato il presidente RIAA, Cary Sherman – per far capire come scaricare o condividere musica sui network peer-to-peer senza autorizzazione è illegale, può portare a delle conseguenze e colpisce il futuro creativo della musica stessa”.
Le tesi delle major, dunque, rimangono quelle di sempre sebbene si supponga che gli IP rilevati siano collegati ad utenti che condividevano quantità notevoli di file musicali. La strategia della RIAA non mira, evidentemente, a scovare tutti gli utenti dei network, una impresa che sarebbe pressoché impossibile visto l’alto numero di frequentatori di queste reti, quanto invece di indurre chi condivide a smettere di farlo per timore di conseguenze giudiziarie.
Quando le major avranno i nomi degli utenti è prevedibile che li vorranno contattare per offrire loro delle transazioni che possano chiudere la vicenda personale di ciascuno anziché proseguire con un procedimento amministrativo nei loro confronti. Fin qui le major hanno fatto sapere di aver chiuso la stragrande maggioranza dei casi aperti dallo scorso settembre ad oggi con transazioni nell’ordine medio dei 3mila dollari .
leggi i 38 commenti
-
benchmark
Sapete dove si possono trovare dei benchmark ? -
casa windigitale
E tutta questa accozzaglia di device elettronici (costose fonti di ulteriori radiazioni elettromagnetiche insieme ai gia presenti frigo, forni a microonde, televisori ecc..) dovrebbe girare sotto winzoz?argh...sh4d -
Reale incremento di prestazioni!
Ho appena comprato un Athlon64 3200, ed ho subito fatto le prove che più mi stavano a cuore, per capire se in effetti i 64bit possono essere un vantaggio anche per noi utenti desktop "normali.Ho installato Fedora Core 1 per x86-32 e Fedora Core 1beta x86-64 e gli ho fatto fare le stesse operazioni: bzip2 ed md5sum (programmi che calcolano intensivamente) su di grossi file.Beh, con mio grosso stupore (e felicità!) gli stessi programmi, sugli stessi dati, semplicemente ricompilati a 64 bit sono stati più veloci di circa il 40% e 30% rispettivamente!Wow :)JugiP.S.: Ovviamente ho fatto attenzionie che il grosso file che ho usato per fare le prove (circa 700Mb) stesse tutto in cache in modo da non dipendere dalla velocità del disco-
Re: Reale incremento di prestazioni!
- Scritto da: Anonimo
Ho appena comprato un Athlon64 3200, ed ho
subito fatto le prove che più mi
stavano a cuore, per capire se in effetti i
64bit possono essere un vantaggio anche per
noi utenti desktop "normali.
Ho installato Fedora Core 1 per x86-32 e
Fedora Core 1beta x86-64 e gli ho fatto fare
le stesse operazioni: bzip2 ed md5sum
(programmi che calcolano intensivamente) su
di grossi file.
Beh, con mio grosso stupore (e
felicità!) gli stessi programmi,
sugli stessi dati, semplicemente ricompilati
a 64 bit sono stati più veloci di
circa il 40% e 30% rispettivamente!Decisamente non male... resta da capire (almeno per me) se la velocità dichiarata da AMD (i famosi 3.2 GHz di un ipotetico P4 equivalente) siano riferiti al codice a 32 bit o a quello a 64 bit.....-
vaglielo a spiegare...
- Scritto da: Anonimo
Beh, con mio grosso stupore (e
felicità!) gli stessi programmi,
sugli stessi dati, semplicemente
ricompilati
a 64 bit sono stati più veloci di
circa il 40% e 30% rispettivamente!Lo stesso incremento che ho provato con mano sul mio nuovo G5 (monoprocessore 1.6Mhz) contro il vecchio G4 (daul processor 1Ghz) usando Photoshop (con solo il plug-in 64 bit!!! ) Cinebench e FinalCut 4.1.1 ottimizato per G5...ma quando ho provato ha dirlo su questo Forum degli ..."ingegnieri" mi hanno dato del troll macchista, sostenendo che passando sui 64 l'incremento doveva essere "non più di un 5%"...e che stavo dicendo delle sciocchezze per fare un piacere ad Apple...plagiato dal marketing......che i 64bit sono utili sono se necessiti di più di 8 Gb di RAM e amenità varie......io oggi a 6 mesi di distanza, ho molti più software ottimizzati per G5 (OSX Panther in primis) e loro probabilmente usano lo stesso PC di allora convinti di avere il meglio....mah...tra un anno voi avrete Win2006 a 64 e gli stessi di cui sopra grideranno al miracolo......cmq sono contento per te, anche se per dare una pecentuale devi dichiarere prima rispetto a che cosa...CiaoFinalCut-
Re: vaglielo a spiegare...
- Scritto da: Anonimo...
Ciao
FinalCutIncremento di prestazioni fra G4 e G5 a parte... in effetti leggendo il tenore del resto del tuo post... si: sono daccordo con chi ti ha dato del troll....Ciao.... e.... dacci un taglio... se è finale anche meglio....
-
-
-
-
Codice a 64 bit
Qualcuno di voi programma in C su piattaforma a 64 bit?Quali accortezze occorre usare quando scrivo un programma per tale piattaforma?Gli int, float etc a quanti bit sono? 32 ?E i double a 64?E' verto che solo i puntatori saranno a 64 bit?-
Re: Codice a 64 bit
- Scritto da: Anonimo
Qualcuno di voi programma in C su
piattaforma a 64 bit?
Quali accortezze occorre usare quando scrivo
un programma per tale piattaforma?
Gli int, float etc a quanti bit sono? 32 ?
E i double a 64?
E' verto che solo i puntatori saranno a 64
bit? Praticamente tutti i linguaggi ad alto livello hanno tipi anche a 128bit. Cambieranno i puntatori come dici, e si potranno indirizzare maggiori quantita' di memoria. Non so se alcuni linguaggi hanno dei tipi interi a 32bit che diventeranno a 64 bit, previa riscrittura dell'interprete o del compilatore (se linguaggio interpretato o compilato). -
Re: Codice a 64 bit
- Scritto da: Anonimo
Qualcuno di voi programma in C su
piattaforma a 64 bit?
Quali accortezze occorre usare quando scrivo
un programma per tale piattaforma?
Gli int, float etc a quanti bit sono? 32 ?
E i double a 64?
E' verto che solo i puntatori saranno a 64
bit?Il fatto e' che se vuoi programmare per bene in un qualsiasi linguaggio ad alto livello uno dei primi accorgimenti e' cercare di NON sapere a quanti bit sono i tipi primitivi :)-
Re: Codice a 64 bit
- Scritto da: Anonimo
Il fatto e' che se vuoi programmare per bene
in un qualsiasi linguaggio ad alto livello
uno dei primi accorgimenti e' cercare di NON
sapere a quanti bit sono i tipi primitivi :)queste cose le può dire solo se stai studiando, e al 99% studi e non hai mai scritto codice su queste piattaforme.http://groups.google.it/groups?hl=it&lr=lang_it&ie=UTF-8&oe=UTF-8&frame=right&rnum=1&thl=0,1310697342,1310686394,1310472209,1310520768,1310498821,1310338144,1309969273,1309733085,1307357964,1307352370,1306877480&seekm=lsiC7.7605%2474.155403%40news2.tin.it#link1-
Re: Codice a 64 bit
- Scritto da: Anonimo
uno dei primi accorgimenti e' cercare
di NON sapere a quanti bit sono i tipi
primitivi :)
queste cose le può dire solo se stai
studiando, e al 99% studi e non hai mai
scritto codice su queste piattaforme.Non si studia più l'overflow? :-)
-
-
Re: Codice a 64 bit
- Scritto da: Anonimo
Il fatto e' che se vuoi programmare per bene
in un qualsiasi linguaggio ad alto livello
uno dei primi accorgimenti e' cercare di NON
sapere a quanti bit sono i tipi primitivi :)
http://punto-informatico.it/p.asp?i=47014Microsoft Internet Explorer Integer Overflow in Processing Bitmap Files Lets Remote Users Execute Arbitrary Code http://www.securitytracker.com/alerts/2004/Feb/1009067.htmlSe non conosci quanti bit vengono usati per i tipi primitivi ecco cosa succede.
-
-
Re: Codice a 64 bit
- Scritto da: Anonimo
Qualcuno di voi programma in C su
piattaforma a 64 bit?
Quali accortezze occorre usare quando scrivo
un programma per tale piattaforma?
Gli int, float etc a quanti bit sono? 32 ?
E i double a 64?
E' verto che solo i puntatori saranno a 64
bit?aehm.. purtroppo amd a furia di rimbambirvi con il marketing per star dietro a IBM tende ad omettere alcune cose fondamentali che chiariro' una volta per tutte, magari senza approfondire troppo per evitare suicidi in diretta e crisi letargiche Il 64bit di AMD non e' un processore 64 bit puro (ovviamente), esistono gia' processori, architetture e sw a 64 bit che funzionano molto bene (mips,alpha,sparc ecc..)ma ovviamente non per il mercato consumer e nemmeno per il prosumer.il 64bit amd funzionera' quasi sempre in legacy mode, cioe' fara' girare istruzioni a 32/16 bit esattamente come fa adesso (in modalita' reale e protetta con memoria segmentata). Sara poi possibile sfruttare i 64 bit utilizzando il long mode in 2 submodalita':*compatibility mode (che e' quello che verra' utilizzato nel 100% dei casi), richiede un os a 64 bit, non e' richiesta la ricompilazione del codice, l'indirizzamento e' a 32 bit *submodalita' 64-bit con indirizzamento a 64bit e nuovi registri a 64bit (oltre ai soliti estesi a 64bit), e' richiesto un os a 64bit, ricompilazione di tutto il sw che non girera' sui vecchi os e sui vecchi computer Gli analisti affermano che non c'e' mercato per questo genere di applicazioni, io affermo che alcuni giochi potrebbero sfruttare la modalita' a 64bit per incrementi di prestazioni ma ATTENZIONE, il 64 bit di per se' non accelera nulla! Le migliorie teoriche dipendono solo dalla maggiore quantita' di memoria indirizzabile e dalla maggiore quantita' di registri a disposizione . detto questo continuate pure a programmare come sapete Mela Marcia (tm)-
Re: Codice a 64 bit
- Scritto da: Anonimo
[...]
aehm.. purtroppo amd a furia di rimbambirvi
con il marketing per star dietro a IBM tende
ad omettere alcune cose fondamentali che
chiariro' una volta per tutte, magari senza
approfondire troppo per evitare suicidi in
diretta e crisi letargiche
Il 64bit di AMD non e' un processore 64 bit
puro (ovviamente), esistono gia' processori,
architetture e sw a 64 bit che funzionano
molto bene (mips,alpha,sparc ecc..)ma
ovviamente non per il mercato consumer e
nemmeno per il prosumer.Non capisco da dove tiri fuori tutta questa "ovvietà".L'athlon64 _è_ un processore a 64 bit puro, con in più la possibilità di lavorare in modalità mista 64/32 bit.Se mi dici che probabilmente il 90% delle persone lo utilizzerà in questo modo, soprattutto perchè utilizza windows, ti do ragione.Ma non è certo l'unico modo di usarlo.In particolare esistono già Gentoo e Suse _native_ a 64 bit, dove tutto il codice (compreso il kernel) è a 64 bit puro.Al punto che, se non sbaglio, in Gentoo non è nemmeno possibile far girare applicazioni a 32 bit al contrario di Suse che invece fornisce delle librerie a 32bit per il codice legacy.Che guarda caso, per linux è pochissimo, perchè essendo che quasi tutto il sw è open source, nella stragrande maggioranza dei casi è sufficiente ricompilarlo per avere una versione nativa a 64 bit, e quindi guadagnarne in efficienza e prestazioni.Anche Debian sta preparando una versione a 64 bit della propria distribuzione e ci metterà parecchio proprio perchè si vuole assicurare che sia in grado di far funzionare fianco a fianco codice a 64 e 32 bit. Come loro stessi affermano infatti, fare una versione pura a 64 bit è ben più semplice, e già seguito da altre distribuzioni.Alex-
Re: Codice a 64 bit - un paio di domande
L'athlon64 _è_ un processore a 64 bit
puro, con in più la
possibilità di lavorare in
modalità mista 64/32 bit....
sufficiente ricompilarlo per avere una
versione nativa a 64 bit, e quindi
guadagnarne in efficienza e prestazioni.mi intrometto, avrei un paio di domande:1° ma i processori x86-64 saranno realmente in grado di indirizzare a 64 bit? qualcuno ha link su dove informarsi meglio marketing a parte?2° compilatori: ci sono già compilatori open source, e per quali linguaggi (ho la sfortuna di non lavorare prevalentemente in c-like), in grado di compilare le applicazioni per questi processori? (In effetti la domanda su come verranno gestiti i tipi non è affatto banale!)grazie. -
Re: Codice a 64 bit
- Scritto da: Anonimo
Che guarda caso, per linux è
pochissimo, perchè essendo che quasi
tutto il sw è open source, nella
stragrande maggioranza dei casi è
sufficiente ricompilarlo per avere una
versione nativa a 64 bit, e quindi
guadagnarne in efficienza e prestazioni......
Come loro stessi affermano infatti, fare una
versione pura a 64 bit è ben
più semplice, e già seguito da
altre distribuzioni.
AlexSe non hai fatto casini coi tipi si.Problema: salvo su file una lista di interi.Poiche' il mio programma ricompilato suppone che gli interi siano improvvisamente divenuti a 64-bit cosa succede?Succede che prima leggo il numero di entries, poi le scrivo.Se le scrivi leggendo la dimensione reale della lista ok. Seinvece fai dei calcoli piu' o meno manuali gia' hai un problema. Il problema e' che tu potresti leggere i 32-bit altie scrivere una serie di zero.D'altra parte se usi un banale sizeof sulla versione a 64-bitti restituisce 4, su quella a 32-bit 2.In questo modo tu scrivi sul tuo file una serie di numeri a 64-bit. Pero' l'utonto linux che ha la distro a 32-bit legge il numerodi interi nella lista, fa il suo bel sizeof ottenendo due e poilegge. Risultato? Il primo e' corretto, il secondo e' zero, ilterzo e' il secondo, il quarto zero, il quinto e' il tezo, il sestoe' zero, etc.A meno che tu non abbia utilizzato un typedef per stabilireche quella lista e' a 32-bit.Nel qual caso mi sfugge il concetto di "ottimizzazzione" e"codice nativo".Codice nativo vuol dire ricompilare e sperare che il compilatore ottimizzi per noi? Vuol dire utilizzare tipisottodimensionati rispetto alla capacita' di un registro?Mah.-
Re: Codice a 64 bit
- Scritto da: Anonimo
- Scritto da: Anonimo
Che guarda caso, per linux è
pochissimo, perchè essendo che
quasi
tutto il sw è open source, nella
stragrande maggioranza dei casi è
sufficiente ricompilarlo per avere una
versione nativa a 64 bit, e quindi
guadagnarne in efficienza e prestazioni.
.....
Come loro stessi affermano infatti,
fare una
versione pura a 64 bit è ben
più semplice, e già
seguito da
altre distribuzioni.
Alex
Se non hai fatto casini coi tipi si.
Problema: salvo su file una lista di interi.
Poiche' il mio programma ricompilato suppone
che gli interi
siano improvvisamente divenuti a 64-bit cosa
succede?
Succede che prima leggo il numero di
entries, poi le scrivo.
Se le scrivi leggendo la dimensione reale
della lista ok. Se
invece fai dei calcoli piu' o meno manuali
gia' hai un
problema. Il problema e' che tu potresti
leggere i 32-bit alti
e scrivere una serie di zero.
D'altra parte se usi un banale sizeof sulla
versione a 64-bit
ti restituisce 4, su quella a 32-bit 2.
In questo modo tu scrivi sul tuo file una
serie di numeri a 64-
bit. Pero' l'utonto linux che ha la distro a
32-bit legge il numero
di interi nella lista, fa il suo bel sizeof
ottenendo due e poi
legge. Risultato? Il primo e' corretto, il
secondo e' zero, il
terzo e' il secondo, il quarto zero, il
quinto e' il tezo, il sesto
e' zero, etc.
A meno che tu non abbia utilizzato un
typedef per stabilire
che quella lista e' a 32-bit.
Nel qual caso mi sfugge il concetto di
"ottimizzazzione" e
"codice nativo".
Codice nativo vuol dire ricompilare e
sperare che il
compilatore ottimizzi per noi? Vuol dire
utilizzare tipi
sottodimensionati rispetto alla capacita' di
un registro?
Mah.Ecco, non per fare polemica, ora ti spiacerebbe spiegarmi che cosa c'entra in tutto questo discorso l' "utonto linux"?O uno ha la laurea in ingegneria elettronica o e' un' utonto?L' UTENTE non esiste?Lo dico senza nessuna vena polemica quindi non ti arrabbiare, voglio solo far riflettere sul significato di quello che si dice/scrive; le abitudini possono essere una buona cosa ma a volte sono diaboliche...Lo scrivo perche' pure io sono spesso caduto in questo tranello: sapendo molte cose (ma ammetto che molte altre mi mancano) relegavo gli "altri" alla categoria degli utonti... un po' come se l' elettricista considerasse tutti quelli che non sanno fare il suo mestiere (in pratica tutti i suoi clienti o potenzialmente tali) un branco di fessacchiotti....==================================Modificato dall'autore il 19/02/2004 14.28.53 -
Re: Codice a 64 bit
Ecco, non per fare polemica, ora ti
spiacerebbe spiegarmi che cosa c'entra in
tutto questo discorso l' "utonto linux"?be, ad esempio uno che ricompila un programma ottimizzato per una architettura a 32 bit con l'opzione "fammi il codice per un processore a 64 bit" fermamente convinto che il compilatore possa prendere decisioni che dovrebbe prendere il programmatore nello scrivere il codice... -
Re: Codice a 64 bit
- Scritto da: Alessandrox
Ecco, non per fare polemica, ora ti
spiacerebbe spiegarmi che cosa c'entra in
tutto questo discorso l' "utonto linux"?
O uno ha la laurea in ingegneria elettronica
o e' un' utonto?
L' UTENTE non esiste?Non intendevo quello, certo che l'utente esiste.Intendevo dire che magari il signor rossi installa il suonuovo linux-64 e si accorge che qualcosa non vaoppure che il guadagno in termini di prestazioni e' minimo.nb: Non credo che win64 vada meglio. -
Re: Codice a 64 bit
- Scritto da: Anonimo
Problema: salvo su file una lista di interi.
Poiche' il mio programma ricompilato suppone
che gli interi
siano improvvisamente divenuti a 64-bit cosa
succede?Usi sistemi di astrazione come le glib per Linux (la base delle gtk e quindi anche di gnome), che ti definiscono tipi come UINT32 e INT64 che sei sicuro siano di 32 e 64 bit rispettivamente in qualsiasi architettura (supportata dalle glib).I problemi che affronti alla fine del post non riguardano i 64 bit sui dischi, ma della CPU.Si`, l'ottimizzazione in parte la fa il compilatore. Se in un programma di analisi degli stream audio hai bisogno di analizzare dati a 48 bit (normalissimo sull'alta qualita`) con le macchine a 32bit usi 2 registri per ogni dato, con quelle a 64 uno solo, e raddoppi (o anche meglio, a volte triplichi) le prestazioni.Stessa cosa con gli algoritmi di crittazione (oggi a 48/64 bit per quanto riguarda quelli -
Re: Codice a 64 bit
- Scritto da: Shu
Si`, l'ottimizzazione in parte la fa il
compilatore. Se in un programma di analisi
degli stream audio hai bisogno di analizzare
dati a 48 bit (normalissimo sull'alta
qualita`) con le macchine a 32bit usi 2
registri per ogni dato, con quelle a 64 uno
solo, e raddoppi (o anche meglio, a volte
triplichi) le prestazioni.
Stessa cosa con gli algoritmi di crittazione
(oggi a 48/64 bit per quanto riguarda quelliNon metto in dubbio che una parte dell'ottimizzazione lafaccia il compilatore, tutt'altro.Il tuo esempio e' calzante ma mi fa venire un dubbioatroce. O tu hai scritto del codice che utilizza piu' variabili(in questo caso due) e in questo caso il passaggio a 64-bitnon serve a nulla oppure hai utilizzato una variabile longe hai lasciato fare al compilatore. In questo caso la tuaapplicazione va sicuramente molto piu' veloce su un opteronma il problema e' che probabilmente andava anche moltomolto lenta su un x86 standard... -
Re: Codice a 64 bit
- Scritto da: Anonimo
- Scritto da: Anonimo
Che guarda caso, per linux è
pochissimo, perchè essendo che
quasi
tutto il sw è open source, nella
stragrande maggioranza dei casi è
sufficiente ricompilarlo per avere una
versione nativa a 64 bit, e quindi
guadagnarne in efficienza e prestazioni.
.....
Come loro stessi affermano infatti,
fare una
versione pura a 64 bit è ben
più semplice, e già
seguito da
altre distribuzioni.
Alex
Se non hai fatto casini coi tipi si.
Problema: salvo su file una lista di interi.
Poiche' il mio programma ricompilato suppone
che gli interi
siano improvvisamente divenuti a 64-bit cosa
succede?
Succede che prima leggo il numero di
entries, poi le scrivo.
Se le scrivi leggendo la dimensione reale
della lista ok. Se
invece fai dei calcoli piu' o meno manuali
gia' hai un
problema. Il problema e' che tu potresti
leggere i 32-bit alti
e scrivere una serie di zero.
D'altra parte se usi un banale sizeof sulla
versione a 64-bit
ti restituisce 4, su quella a 32-bit 2.
In questo modo tu scrivi sul tuo file una
serie di numeri a 64-
bit. Pero' l'utonto linux che ha la distro a
32-bit legge il numero
di interi nella lista, fa il suo bel sizeof
ottenendo due e poi
legge. Risultato? Il primo e' corretto, il
secondo e' zero, il
terzo e' il secondo, il quarto zero, il
quinto e' il tezo, il sesto
e' zero, etc.
A meno che tu non abbia utilizzato un
typedef per stabilire
che quella lista e' a 32-bit.
Nel qual caso mi sfugge il concetto di
"ottimizzazzione" e
"codice nativo".lo stesso problema potresti averlo con due codifiche diverse di datiè buona abitudine salvare i dati in formato compressibile a diverse architetture
Codice nativo vuol dire ricompilare e
sperare che il
compilatore ottimizzi per noi? si!
Vuol dire utilizzare tipi
sottodimensionati rispetto alla capacita' di
un registro?cioè?
Mah. -
Re: Codice a 64 bit
- Scritto da: Anonimo
- Scritto da: Anonimo
- Scritto da: Anonimo
Che guarda caso, per linux è
pochissimo, perchè essendo
che
quasi
tutto il sw è open source,
nella
stragrande maggioranza dei casi
è
sufficiente ricompilarlo per avere
una
versione nativa a 64 bit, e quindi
guadagnarne in efficienza e
prestazioni.
.....
Come loro stessi affermano infatti,
fare una
versione pura a 64 bit è ben
più semplice, e già
seguito da
altre distribuzioni.
Alex
Se non hai fatto casini coi tipi si.
Problema: salvo su file una lista di
interi.
Poiche' il mio programma ricompilato
suppone
che gli interi
siano improvvisamente divenuti a 64-bit
cosa
succede?
Succede che prima leggo il numero di
entries, poi le scrivo.
Se le scrivi leggendo la dimensione
reale
della lista ok. Se
invece fai dei calcoli piu' o meno
manuali
gia' hai un
problema. Il problema e' che tu potresti
leggere i 32-bit alti
e scrivere una serie di zero.
D'altra parte se usi un banale sizeof
sulla
versione a 64-bit
ti restituisce 4, su quella a 32-bit 2.
In questo modo tu scrivi sul tuo file
una
serie di numeri a 64-
bit. Pero' l'utonto linux che ha la
distro a
32-bit legge il numero
di interi nella lista, fa il suo bel
sizeof
ottenendo due e poi
legge. Risultato? Il primo e' corretto,
il
secondo e' zero, il
terzo e' il secondo, il quarto zero, il
quinto e' il tezo, il sesto
e' zero, etc.
A meno che tu non abbia utilizzato un
typedef per stabilire
che quella lista e' a 32-bit.
Nel qual caso mi sfugge il concetto di
"ottimizzazzione" e
"codice nativo".
lo stesso problema potresti averlo con due
codifiche diverse di dati
è buona abitudine salvare i dati in
formato compressibile a diverse architetturealtrimenti devi prevedere un formato ad hoc per le diverse architetture...ovviamente per kernel e/o supporto runtime una semplice rincopilata a 64 bit nn basta ma buona parte dovra essere riscritto (scheduler, gestione della memoria, ecc) -
Re: Codice a 64 bit
- Scritto da: Anonimo
lo stesso problema potresti averlo con due
codifiche diverse di dati
è buona abitudine salvare i dati in
formato compressibile a diverse architettureCerto, tuttavia un conto sono due architetture diverse,una big endian e una little endian, un altro conto e'ricompilare pari pari una applicazione senza preoccuparsidei tipi, anzi supponendo che se gli int vengono estesi a 64-bit si ha un guadagno automatico. :)
Codice nativo vuol dire ricompilare e
sperare che il
compilatore ottimizzi per noi?
si!Secondo me codice nativo e' qualcosina in piu'.Per me vuol dire codice progettato ed ottimizzato per unaspecifica architettura.
Vuol dire utilizzare tipi
sottodimensionati rispetto alla
capacita' di
un registro?
cioè?Esempio semplice semplice.Cancellare un array. L'array e' di x entry da 1 byteciascuna.Utilizzando una cpu a 64-bit si possono cancellare 8entry per volta. Utilizzandone una a 32 se ne cancellano 4.Ci vogliono il doppio di cicli per effettuare una semplicecancellazione. Assumendo che il compilatore non abbiaproblemi a lavorare su un dato che occupa solo mezzoregistro, ad andare bene il solito codice va il doppio piu'veloce ad eseguire questa banale operazione. -
Re: Codice a 64 bit
anzi supponendo che se gli int
vengono estesi a 64-
bit si ha un guadagno automatico. :)e dove sarebbe il guadagno?
Vuol dire utilizzare tipi
sottodimensionati rispetto alla
capacita' di
un registro?
cioè?
Esempio semplice semplice.
Cancellare un array. L'array e' di x entry
da 1 byte
ciascuna.
Utilizzando una cpu a 64-bit si possono
cancellare 8
entry per volta. Utilizzandone una a 32 se
ne cancellano 4.
Ci vogliono il doppio di cicli per
effettuare una semplice
cancellazioneLOL questo in qualche rivista di fantascienza ;) Ci vogliono esattamente lo stesso numero di cicli perche' il processore non fa altro che azzerare locazioni di memoria (che potrebbero anche non essere contigue) di 1 byte, anzi a 64bit il codice amd potrbbe risultare piu' lento se si utilizzano registri a 64 bit per colpa 1- dei puntatori a 64bit che occupano il doppio dello spazio in cache2- se si utilizzano interi a 64bit e' necessario usare operandi che occupano un byte in piu' , altro spreco di spazio in cache (per questo il default per gli interi e' 32bit) una volta per tutte, e' FALSO che un processore a 64bit sia il doppio piu' veloce di uno a 32 bit , le uniche routine che potrebbero avvantaggiarsi dei registri estesi sono quelle che usavano interi a 64 bit (che venvano messi in 2 registri contigui) e quindi algoritmi di criptazione o di matematica di alta precisione... per tutto il resto l'aumento di prestazione e' dovuto solo all'aumento del numero dei registri (non della dimensione) e alla maggiore quantita' di memoria indirizzabile o a *rari* casi in cui si sfrutta la maggiore ampiezza del bus dati -
Re: Codice a 64 bit
Secondo me codice nativo e' qualcosina in
piu'.
Per me vuol dire codice progettato ed
ottimizzato per una
specifica architettura.programmi in linguaggio macchina? ti ricordo chenon soltanto l'architettura del processore è importante ma anche il compilatore, supporto runtime e sistema operativocertamente se hai una cpu a 64 e non hai altro nn ti resta (per sfruttarlo un po') che realizzare programmi ottimizzati in linguaggio macchina !
-
-
Re: Codice a 64 bit
L'athlon64 _è_ un processore a 64 bit
puro, con in più la
possibilità di lavorare in
modalità mista 64/32 bit.IMHO Il processore amd e' una mezza ciofeca che integra un processore 16 bit, 32, bit 64 bit con memoria segmentata o indirizzamento virtuale, modo protetto,registri che a seconda dei modi vengono mascherati, aumentano o diminuiscono, addirittura la dimensione di default degli operandi interi e' 32bit (a 64bit), per usare quelli a 64 bisogna utilizzare quello che amd chiama il REX prefix (un byte in piu' per istruzione) che diminuisce le prestazioni incidendo sulla cache... se questo e' un processore a 64 bit puro non hai mai letto un datasheet di un vero processore a 64 bit
Se mi dici che probabilmente il 90% delle
persone lo utilizzerà in questo modo,
soprattutto perchè utilizza windows,
ti do ragione.
Ma non è certo l'unico modo di usarlo.
In particolare esistono già Gentoo e
Suse _native_ a 64 bit, dove tutto il codice
(compreso il kernel) è a 64 bit puro.al tempo... tutto quello che ho detto era riferito a windows, su unix/linux il discorso cambia, del resto Linux gira a 64 bit gia' da svariati anni su altre architetture
Come loro stessi affermano infatti, fare una
versione pura a 64 bit è ben
più semplice, e già seguito da
altre distribuzioni.sono d'accordo Mela marcia (tm)-
Re: Codice a 64 bit
- Scritto da: Mela Marcia
L'athlon64 _è_ un processore a
64 bit
puro, con in più la
possibilità di lavorare in
modalità mista 64/32 bit.
IMHO Il processore amd e' una mezza ciofeca
che integra un processore 16 bit, 32, bit 64
bit con memoria segmentata o indirizzamento
virtuale, modo protetto,registri che a
seconda dei modi vengono mascherati,
aumentano o diminuiscono, addirittura la
dimensione di default degli operandi interi
e' 32bit (a 64bit), per usare quelli a 64
bisogna utilizzare quello che amd chiama il
REX prefix (un byte in piu' per istruzione)
che diminuisce le prestazioni incidendo
sulla cache... se questo e'
un processore a 64 bit puro non hai mai
letto un datasheet di un vero processore a
64 bitMi fanno ridere queste persone che danno dell'ignorante agli altri parlando di "datasheet" quando probabilmente non sanno nemmeno di cosa stanno parlando.Per chi conosce l'assembler, il REX prefix è il codice che AMD ha riservato per poter eseguire operazioni a 64 bit _da_ una modalità 32 bit (quindi quando il sistema operativo _non_ è a 64 bit), ed è esattamente la cosa analoga a quanto accadde con il 386 quando Intel introdusse questo (ottimo) trucchetto per poter lavorare a 32 bit anche se il sistema operativo era a 16 bit (a suo tempo il dos).La genialità della cosa sta nel fatto che grazie a questo prefisso, le _stesse_ istruzioni vengono eseguite in modalità 64 bit, se correntemente si è in modalità 32, e viceversa.Il bello di avere un sistema operativo completamente 64 bit (come alcune distribuzioni di linux) è che tali prefissi non servono più e quindi il processore può eseguire full speed, e senza decodificare inutili byte tutto il codice.Tutto l'ambaradan che descrivi, con bit che vengono mascherati, aumentano e diminuiscono è il pesante fardello che ci portiamo appresso per garantire la compatibilità con il passato, e c'è sempre stata, nel passaggio dall'architettura 8086 a quella 80286, e poi dalla 80286 alla 80386.Saluti,Alex
-
-
-
-
Re: Codice a 64 bit
- Scritto da: Anonimo
Qualcuno di voi programma in C su
piattaforma a 64 bit?
Quali accortezze occorre usare quando scrivo
un programma per tale piattaforma?
Gli int, float etc a quanti bit sono? 32 ?
E i double a 64?
E' verto che solo i puntatori saranno a 64
bit?aehm.. purtroppo amd a furia di rimbambirvi con il marketing per star dietro a IBM tende ad omettere alcune cose fondamentali che chiariro' una volta per tutte, magari senza approfondire troppo per evitare suicidi in diretta e crisi letargiche Il 64bit di AMD non e' un processore 64 bit puro (ovviamente), esistono gia' processori, architetture e sw a 64 bit che funzionano molto bene (mips,alpha,sparc ecc..)ma ovviamente non per il mercato consumer e nemmeno per il prosumer.il 64bit amd funzionera' quasi sempre in legacy mode, cioe' fara' girare istruzioni a 32/16 bit esattamente come fa adesso (in modalita' reale e protetta con memoria segmentata). Sara poi possibile sfruttare i 64 bit utilizzando il long mode in 2 submodalita':*compatibility mode (che e' quello che verra' utilizzato nel 100% dei casi), richiede un os a 64 bit, non e' richiesta la ricompilazione del codice, l'indirizzamento e' a 32 bit *submodalita' 64-bit con indirizzamento a 64bit e nuovi registri a 64bit (oltre ai soliti estesi a 64bit), e' richiesto un os a 64bit, ricompilazione di tutto il sw che non girera' sui vecchi os e sui vecchi computer Gli analisti affermano che non c'e' mercato per questo genere di applicazioni, io affermo che alcuni giochi potrebbero sfruttare la modalita' a 64bit per incrementi di prestazioni ma ATTENZIONE, il 64 bit di per se' non accelera nulla! Le migliorie teoriche dipendono solo dalla maggiore quantita' di memoria indirizzabile e dalla maggiore quantita' di registri a disposizione . detto questo continuate pure a programmare come sapete Mela Marcia (tm)-
Re: Codice a 64 bit
- Scritto da: Mela Marcia
Le
migliorie teoriche dipendono solo dalla
maggiore quantita' di memoria indirizzabile
e dalla maggiore quantita' di registri a
disposizione . Sono d'accordo e in più sto cominciando a pensare che avere un maggior spazio di indirizzamento e una maggiore quantità di memoria a disposizione da qui a 2-3 anni non sia una cosa così strana neanche per gli utenti finali.
-
-
Re: Codice a 64 bit
- Scritto da: Anonimo
E' verto che solo i puntatori saranno a 64
bit?Punta quello che vuoi a 64bit, comunque AMD-x64 indirizza solo a 48 bit e Itanium a 50 bit.Evviva i processori fatti bene... ovvero nessuno di questi!Ciaogl :)-
Re: Codice a 64 bit
- Scritto da: Anonimo
- Scritto da: Anonimo
E' verto che solo i puntatori saranno a
64
bit?
Punta quello che vuoi a 64bit, comunque
AMD-x64 indirizza solo a 48 bit e Itanium a
50 bit.
Evviva i processori fatti bene... ovvero
nessuno di questi!
Ciao
gl :)Non mi dire che 48 bit non ti bastano... :D-
Re: Codice a 64 bit
Non mi dire che 48 bit non ti bastano... :DNo.E poi le cose si fanno bene e subito, non un po' per volta con delle pezze qua e là (un po' come gli IRQ in cascata sui vecchi x86)Ciao!gl :)-
Re: Codice a 64 bit
- Scritto da: Anonimo
Non mi dire che 48 bit non ti
bastano... :D
No.
E poi le cose si fanno bene e subito, non un
po' per volta con delle pezze qua e
là (un po' come gli IRQ in cascata
sui vecchi x86)
Ciao!
gl :)Sai quanto puoi indirizzare con 48 bit?
-
-
-
Re: Codice a 64 bit
- Scritto da: Anonimo
- Scritto da: Anonimo
E' verto che solo i puntatori saranno a
64
bit?
Punta quello che vuoi a 64bit, comunque
AMD-x64 indirizza solo a 48 bit e Itanium a
50 bit.
Evviva i processori fatti bene... ovvero
nessuno di questi!Processori "fatti bene" ?Ma in che mondo vivi ?NESSUNA cpu a 64bit attualmente esce fuoricon 64bit di indirizzo fisico per cpu.E questo per la semplice ragione che nessunosano di mente spreca inutilmente pin sul packagee linee interne sulla circuiteria di i/o per fare lo sborone.I K8 di AMD sono full 64bit, l'unica limitazione e' chela *memoria fisicamente collegata* ad una cpusu Socket 754 oppure Socket 940 e' limitataad un TERAbyte (1024GB) ovvero "40 bit di indirizzo fisico".Con le capacita di memoria attuale ti servirebbeuna scheda madre capace di reggere 512 moduli DIMMda 2Gbyte l'uno per "saturare" di memoria *un* K8. :-)L'indirizzo fisico "propagato" sui link HyperTransportinvece e' a 48bit (in modo da supportarefino a 256 cpu "collegate tra loro" che mettonoinsieme tutta la memoria locale a cui sono collegate).Ben prima che si raggiunga la possibilita di installarerealmente mezzo terabyte di ram per cpu, il socket dellecpu x86-64 sara' cambiato almeno un paio di volte(e si sfruttera' l'occasione per estendere lo spazio di memoria fisico).
-
-
Re: Codice a 64 bit
- Scritto da: Anonimo
Qualcuno di voi programma in C su
piattaforma a 64 bit?
Quali accortezze occorre usare quando scrivo
un programma per tale piattaforma?
Gli int, float etc a quanti bit sono? 32 ?
E i double a 64?
E' verto che solo i puntatori saranno a 64
bit?
1- No.2- Piu' o meno le stesse che utilizzi per un programma a 32,che a loro volta erano le stesse di quando si lavorava a 16.3-Gli int per definizione hanno la dimensione di un registrointero. A rigor di logica un int e' a 64-bit su una cpu con registri a 64-bit. Quando lavoravo a 16 un int era 16 bit.Oggi un un int e' a 32 bit e uno short a 16. Domani unint sara' a 64, ma non ho idea di cosa sara' uno short.I float riguardano la FPU, e non e' assolutamente dettoche la FPU di una CPU a 64-bit abbia registri a 64-bit.Sin dall'80387 l'FPU tiene i dati in registri interni ad80-bit. Le modalita' d'uso sono due: una definita shortreal a 32bit e una long real a 64-bit che poi vengonoconvertite in temporary real (80-bit). Una cosa che forsenon tutti sanno e' che la FPU accetta e tratta anche numeriinteri.4- I double dovrebbero gia' essere a 64-bit. I float infattivengono convertiti in DD e i double in DQ. Devi vederel'assembler per x86 come riferimento. In C un tipo puo' essere chiamato in qualunque modo... cosi' viene fuoriche il tipo double non fa riferimento a DefineDoubleword, bensi' a DefineQuadword.5- Non e' detto. In ogni caso anche qui devi vedere come funziona davvero la CPU passando per l'asm. DS:SI sono due registri a 16 bit gia' presenti nel 286. A livello teorico sarebbero stati gia' in grado di indirizzare 32-bit. Allo stesso modo gia' da un 386 potresti utilizzare DS:ESI con il secondo registro a 32-bit riuscendo a indirizzare teoricamente 48-bit.Qui pero' entrano in gioco diversi fattori. La modalita'di indirizzamento e il tipo di compilatore al quale ti riferisci.Su 286+turboc+dos per indirizzare fuori dal segmento di 64kb dovevi utilizzare un puntatore far dichiarandolo esplicitamente. Infatti il registro DS puntava ad un segmento,mentre il registro SI indicizzava i 64kb di offset in quel segmento. Problema: l'indirizzo puntato da DS=1 non e'piu' grande di 64kb rispetto a DS=0. E' poco piu' grande.Quindi benche' tu potessi essere in grado di indirizzare4gb con un 286, questo non era possibile a causa dellamodalita' di indirizzamento. Per quanto questa soluzione possa sembrare folle, non lo era affatto. Potendo gestire isegmenti con offset molto piu' grande della precisionedel selettore si evita di sprecare un intero segmentoper indirizzare pochi bytes.Questo e' uno dei motivi per i quali i primi giochi davveroseri (tipo heretic) su standard VESA avevano bisogno del DOS4GW o del PMODE. Lo standard vesa permetteva diandare oltre la modalita' 320x200x256 colori. Lo scottoda pagare era l'aumento di memoria video. La memoria pero'era sempre e comunque indirizzabile solo a banchi di 64kb.Disegnare un poligono o uno sprite tenendo conto che a circaun quarto dello schermo devi cambiare selettore e' impensabile in termini di prestazioni. In modalita' protettainvece il segmento poteva essere selezionato in modo diverso permettendo di superare questo limite. -
Re: Codice a 64 bit
Da man gcc:"-m64 Generate code for a 32-bit or 64-bit environment. The 32-bit environment sets int, long and pointer to 32 bits and generates code that runs on any i386 system. The 64-bit environment sets int to 32 bits and long and pointer to 64 bits and generates code for AMD's x86-64 architecture."-
Re: Codice a 64 bit
- Scritto da: Anonimo
Da man gcc:
"-m64
Generate code for a 32-bit
or 64-bit environment.
The 32-bit environment
sets int, long and pointer to
32 bits and generates code
that runs on any i386 system.
The 64-bit environment
sets int to 32 bits and long and
pointer to 64 bits and
generates code for
AMD's x86-64 architecture.
"da quale versione in poi è supportato questo flag ?
-
-
