RIAA denuncia 531 utenti internet

Sono colpevoli a suo dire di aver usato i network peer-to-peer per condividere materiali protetti. Per sapere i nomi ha denunciato ignoti. Saranno i giudici a chiedere i nomi ai provider


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 .

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • atari scrive:
    benchmark
    Sapete dove si possono trovare dei benchmark ?
  • Anonimo scrive:
    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
  • Anonimo scrive:
    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
    • Anonimo scrive:
      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.....
      • Anonimo scrive:
        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
        • Anonimo scrive:
          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....
  • Anonimo scrive:
    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?
    • Anonimo scrive:
      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).
    • Anonimo scrive:
      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 :)
      • Anonimo scrive:
        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
        • Anonimo scrive:
          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? :-)
      • Anonimo scrive:
        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.
    • Anonimo scrive:
      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)
      • Anonimo scrive:
        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
        • Anonimo scrive:
          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.
        • Anonimo scrive:
          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.
          • Alessandrox scrive:
            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
          • Anonimo scrive:
            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...
          • Anonimo scrive:
            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.
          • Shu scrive:
            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
          • Anonimo scrive:
            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...
          • Anonimo scrive:
            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.
          • Anonimo scrive:
            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)
          • Anonimo scrive:
            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.
          • Mela Marcia scrive:
            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
          • Anonimo scrive:
            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 !
        • Mela Marcia scrive:
          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)
          • Anonimo scrive:
            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
    • Mela Marcia scrive:
      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)
      • Anonimo scrive:
        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.
    • Anonimo scrive:
      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 :)
      • Anonimo scrive:
        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
        • Anonimo scrive:
          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 :)
          • Anonimo scrive:
            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?
      • Anonimo scrive:
        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).
    • Anonimo scrive:
      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.
    • Anonimo scrive:
      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."
      • Anonimo scrive:
        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 ?
Chiudi i commenti