Macintel: le prime impressioni sui Developer Transition Kit

[cdimauro]

Originariamente inviato da Breakthru

Se apple usa un sistema che IMPEDISCE l'installazione su un pc.... microsoft userà LO STESSO SISTEMA per impedire di installare un windows non originale sui pc...

Si tratta di due problemi diversi.

E FORSE I NUOVI PROCESSORI INTEL SONO IL MODO PER FARLO!!!

Se integrano qualcosa di simile a Palladium, sì.

p.p.s. Microsoft guadagna molto producendo s.o. che si bloccano e che danno problemi, ogni problema è una spinta a comprare la nuova versione!!!!!

Ne abbiamo parlato parecchie volte, eppure vedo che contuini a riportare le stesse leggende metropolitane: non ti stanchi mai di fare il troll anti-MS?

Io credo che anche apple preferisce incrementare il guadagno che soddisfare l'utente (non sono legati come si pensa...)
eppure fa un s.o. migliore... se apple si slegasse dall'hardware diventa conveniente fare s.o. scadenti come fa microsoft (anche i pro m$ non possono negare che sono pieni di difetti).

Come tutti i sistemi. Per il resto, vedi sopra: quando la smetterai con le solite storie, farai un favore al forum...

[Yokoshima]

HOLA a tutti!

La discussione è davvero interessante e mi stimola molto!

Io penso, l'Apple ha sempre puntato su processori RISC se non erro, ovvero:
- cpu con set-istruzioni molto piccolo e registri molto grandi;
- set-istruzioni molto "semplici" eseguibili quindi in circa un ciclo di clock e quindi un numero superiore di istruzioni eseguibili rispetto a cpu CISC;
- software molto complesso per via di istruzioni troppo semplici, ma di contro molto semplice da "specializzare" a svolgere un compito specifico (= improntare un elaboratore ad un'ambito specifico);
- hardware dedicato, ovvero macchine costruite a pennello per lo scopo (almeno fino a qualche tempo fa) selezionando i componenti per meglio armonizzare il tutto.

Questo è quello che mi sembra avesse intenzione di fare Apple dei suoi computers.

Adesso mi chiedo...passare a macchine x86 non potrebbe essere solo per un problema di costi?
Mi spiego, fare quello che dico sopra implica che una macchina debba essere studiata e testata non poco, quindi si spiegherebbero (in parte) i costi di priduzione elevati del pacchetto Apple.

Poi, io francamente trovo un pò bizzarro sentir dire che i sample abbiano dato risultati soddisfacenti... si tratta tratta di macchine con una CPU che nn trovi sotto i sassi no?
Perchè non hanno dato macchine con 2.8GHz? Sarei curioso di vedere che prestazioni offre il sistema Apple.

Per far girare il sample di test di S.O. Apple si è usata una configurazione etremamente spinta, tranne che per la scheda video (cosa che Apple ha abituato a fare negli ultimi tempi anche sui suoi sistemi).

Ergo secondo me o MAC O.S. diventa mooooolto simile a Windows o la Intel sfornerà processori appositi per i sistemi Apple o quanto meno modificati per tal sistema.
E per rispettare il possibile Dual-boot fara come ha fatto per tappare il buco dei 64bit per i desktop... una interfaccia aggiuntiva, o qualcosa di simile.

[cdimauro]

Originariamente inviato da riuzasan

Partiamo da chi ora spara a zero su Ibm e sulla architettura PPC. Chi lo fa, dimostra di non aver MAI usato una qualunque macchina con processore PowerPC (sia esso un PowerMac, un ODW o uno Starmax).
I PowerPC sono stati i primi processori ad usare tecniche SOI per la costruzione, cache di terzo livello e pipelines profondamente più complesse e performanti di qualunque X86 fino all'arrivo degli A64.

Mi spieghi che c'entra l'uso di una macchina PowerPC con la sua tecnologia costruttiva / implementazione? E' un passaggio logico che ho non ho poca difficoltà a seguire...

Per il resto, le pipeline più performanti evidentemente non bastano ai PowerPC, visto che hanno mediamente delle prestazioni inferiori rispetto agli x86...

Non solo ... ho letto delle sciocchezze sui Cell che onestamente dovrebbero far riflettere un pò meglio su quale sia il livello degli esperti che aprono bocca solo per sparare affermazioni senza una base di rigore scientifico.
I Cell sono dei processori eccellenti per l'utenza home. Più veloci di un ordine di generazione prestazionale, non temono confronti in quei campi dove davvero serve un processore veloce: quello dei calcoli vettoriali e in virgola mobile in generale.
E' inutile che un santone sostenga che per un ambiente Office un Cell non sia valido, è una autentica baggianata. Per gli ambienti office con uso di DB di media clompessità basta ed avanza anche un processore come un Sempron o un Celeron.
Qui si va a giudicare un processore, che sulla carta offre in applicativi 3D performance 3 volte superiori a quelle di un Athlon64 FX di pari cloccaggio, con un word processor.
Mi sa che chi ha sparato quelle affermazioni lo abbia fatto dopo aver letto uno dei tanti editoriali di riviste online notoriamente interessante solo alle architetture X86.

Evidentemente non hai seguito bene i commenti che sono stati fatti sul Cell, perché mi sembra piuttosto chiaro, ed è stato scritto a caratteri cubitali, che processori come Cell, x86, ecc. hanno CAMPI DI ECCELLENZA DIVERSI.

Che un Cell si possa essere usato in ambito desktop per delle operazioni "office", che possono interessare l'utente medio, è cosa nota. Che sia scarso per tante altre cose, è anch'esso cosa nota. E' chiaro che se ho bisogno di lavorare spesso con database, non compro un Cell, ma tutt'altro.

Non vedo dove stia il problema...

Infine, e scusate la franchezza, ma i pochi piccoli sviluppatori che non siano Adobe-Macromedia o Microsoft, sostengono che le prestazioni del Transition Kit non siano così eccellenti, anzi: incompatibilità e lentezza di numerosi applicativi, lagato ad un uso sproporzionato di memoria.
L'autore di DCAD ad esempio ha dichiarato che l'eseguibile occupa circo il doppio della Ram e che sul sistema in uso era dai benchmark circa due volte più lento di un dual G5.

L'incompatibilità può essere sistemata: Rosetta è un software, e come tale non può essere perfetto.
Il maggior uso di ram è strano, perché il codice x86 in genere è molto più compatto e occupa meno spazio dell'equivalente PPC.

E' chiaro che è un kit abbastanza giovane, e deve "rodarsi".

Queste prime voci trasversali, mi ricordano tanto gli annunci trionfalistici di Apple nel passaggio dai processori MC680x0 ai PPC "Già ora gira bene tutto il vecchio paro software" si ripeteva al vecchio SMAU del 94 ... Poi si è visto come giravano in realtà.

Idem come sopra: all'inizio c'erano processori 680x0 molto performanti, e i PPC di allora erano ancora i primi esemplari. Col tempo le cose sono cambiate, mi pare. Col tempo le cose cambieranno anche con questo passaggio...

[cdimauro]

Originariamente inviato da Jo

Sono pronto!!!
Coca cola, pop corn e patatine...
Fatevi sotto!!!!!!



Ciao, Jo

Lo sai che sei veramente cattivo?

[cdimauro]

Originariamente inviato da mjordan

Questo pero' mi sa di hype:

Come non si riconosce? Ma se un fat binary è quasi il doppio di dimensione...

Penso che si riferisse all'uso delle applicazioni: che siano PPC o x86, il feeling con l'utente rimane lo stesso (ed è la cosa più importante).
IMHO, chiaramente...

[cdimauro]

Originariamente inviato da Sallustius

Beh, a vantaggio della soluzione "RISC" resta sempre il maggior numero di registri, che non è cosa da poco (pensa al fattore di register spilling, e quanto può rallentare un programma....I soli 6+2 registri della IA32 non riescono a reggere il confronto nel caso di calcoli "local-variable intensive"...),

Questo è normale: le prestazioni dipendono sempre dal tipo di codice. Comunque è anche vero che, da un po' di anni a questa parte, gli x86 abbiano prestazioni mediamente superiori ai PPC.

Se aggiungiamo anche il fatto che con x86-64 il numero di registri raddoppierà, e che ci sarà un aumento medio del 15-20% nella velocità di esecuzione dello spesso codice (ma 32 bit), direi che le prospettive per il futuro sono anche migliori.
A completare il quadro c'è anche il fatto che x86-64 permette di usare valori a 64 bit e accedere a più di 4GB di memoria in maniera trasparente (è normale per questo modello architetturale), mentre un PPC per fare lo stesso subisce delle forti penalizzazioni.

e la relativa "semplicità" della programmazione a basso livello del sistema (ti assicuro che è umanamente disarmante provare a scrivere un codice assembler decente per una macchina CISC...

Sono anni che programmo in assembly per diverse macchine, e se ci sono delle architetture che sono più semplici da programmare a così basso livello, sono certamente quelle CISC. Gli x86 non saranno come i 68000, che in questo contesto erano una vera manna, ma si difendono piuttosto bene, e con l'incarnazione x86-64 la situazione migliora parecchio.
Programmare i RISC, per contro, richiede più tempo (per fare le stesse cose generalmente si deve scrivere più codice).

Ed è disarmante ancora di più sapere che poi l'unita di istruzioni provvede a spezzettare la tua bella movl m-r in tre istruzioni RISC-style...).

Sarà ugualmente disarmante sapere che è la stessa cosa che fanno RISC come il G5/Power4/Power5.

Per un programmatore, che normalmente si cura soltanto di vedere qual è la latenza, il throughput ed eventuali dipendenze, è un dettaglio poco rilevante sapere in che modo viene suddivisa un'istruzione in micro-op RISC-like.

Inoltre 64 bit fanno sempre comodo, e non solo per indirizzare "più di 4GB di RAM", come si leggeva da qualche parte sul sito Apple, ma anche per poter contare su una maggiore "resistenza" all'overflow con gli interi (che è una croce se non gestita bene...)..

I 64 bit non fanno sempre comodo: se servono si usano, altrimenti se ne fa a meno. E' molto più comodo indirizzare più di 4GB di ram, che avere i 64 bit per gli interi, che servono in pochi (ma in alcuni casi significati, sicuramente: i database, ad esempio) ambiti applicativi...

[cdimauro]

Originariamente inviato da Caesar_091

Euforici? Veramente io leggo troppi pareri discordanti. L'arrivo di CPU Intel non sarà tutto rose e fiori... basta vedere come vanno male gli attuali Mac-Intel con la compressione video.

E' chiaro che nel passaggio qualcosa si perderà, ma mi sembra una cosa normale. Bisogna quanto peserà e in quali settori.

E poi non capisco dove ho ipotizzato che per Mac sarà diverso? Tienimi fuori dalle tue solite inutili discussioni Mac-PC / MacOS-Windows che non me ne pò fregar di meno, grazie.

Sei tu che stai mettendo le mani avanti...

Io ho soltanto scritto che gli x86 hanno già dei sistemi dual core e che vengono commercializzati. Poi ho precisato che se la diffusione è scarsa, è perché l'utenza a cui sono rivolti non è la massa. Ho aggiunto semplicemente che la stessa cosa si verificherà quando arriveranno anche i dual core PPC.

Se ci vedi una guerra contro i Mac o MacOS (che non ho nemmeno citato), sono soltanto fatti tuoi: evidentemente non sei in grado di accettare l'opinione di qualcuno senza pensare che sotto sotto ci sia del marcio. Poco importa: io dormo lo stesso...

[cdimauro]

Originariamente inviato da Yokoshima

Io penso, l'Apple ha sempre puntato su processori RISC se non erro, ovvero:
- cpu con set-istruzioni molto piccolo e registri molto grandi;
- set-istruzioni molto "semplici" eseguibili quindi in circa un ciclo di clock e quindi un numero superiore di istruzioni eseguibili rispetto a cpu CISC;
- software molto complesso per via di istruzioni troppo semplici, ma di contro molto semplice da "specializzare" a svolgere un compito specifico (= improntare un elaboratore ad un'ambito specifico);
- hardware dedicato, ovvero macchine costruite a pennello per lo scopo (almeno fino a qualche tempo fa) selezionando i componenti per meglio armonizzare il tutto.

Questo è quello che mi sembra avesse intenzione di fare Apple dei suoi computers.

E' una differenziazione abbastanza vecchia: i processori CISC "moderni" (da una decina d'anni a questa parte), non rispecchiano più certi canoni, come anche per i RISC (che di istruzioni, ad esempio, non ne hanno poche, anzi!).

D'altra parte si programma quasi sempre in linguaggi ad alto livello, e le rare volte che viene usato l'assembly è per piccole porzioni di codice.

Adesso mi chiedo...passare a macchine x86 non potrebbe essere solo per un problema di costi?
Mi spiego, fare quello che dico sopra implica che una macchina debba essere studiata e testata non poco, quindi si spiegherebbero (in parte) i costi di priduzione elevati del pacchetto Apple.

E' proprio per una questione di costi che un Mac di oggi è molto più simile a un PC di quanto non lo fosse in passato (in comune aveva soltanto i chip per le memorie): per ridurli.

Quanto alla progettazione del software, proprio perché si usano per lo più linguaggi ad alto livelli, non incide sul tipo di processore utilizzato.

Poi, io francamente trovo un pò bizzarro sentir dire che i sample abbiano dato risultati soddisfacenti... si tratta tratta di macchine con una CPU che nn trovi sotto i sassi no?
Perchè non hanno dato macchine con 2.8GHz? Sarei curioso di vedere che prestazioni offre il sistema Apple.

Al contrario si tratta di CPU che vengono regolamente vendute, e abbastanza accessibili. Considera che ormai il "taglio minimo" è dato da processori a 3 / 3.2Ghz (Ghz o "equivalenti").

Per far girare il sample di test di S.O. Apple si è usata una configurazione etremamente spinta, tranne che per la scheda video (cosa che Apple ha abituato a fare negli ultimi tempi anche sui suoi sistemi).

Ergo secondo me o MAC O.S. diventa mooooolto simile a Windows o la Intel sfornerà processori appositi per i sistemi Apple o quanto meno modificati per tal sistema.
E per rispettare il possibile Dual-boot fara come ha fatto per tappare il buco dei 64bit per i desktop... una interfaccia aggiuntiva, o qualcosa di simile.

Penso che saranno PC come altri. Al più, se verrà usato un sistema Palladium-like, sarà questo che impedirà l'installazione su PC diversi da quelli che vuole Apple.

Comunque è presto per parlarne: aspettiamo il prossimo anno e vedremo come staranno realmente le cose...

P.S. Salutami Reiko e Okinu...

[Caesar_091]

Originariamente inviato da cdimauro

Sei tu che stai mettendo le mani avanti...

Io ho soltanto scritto che gli x86 hanno già dei sistemi dual core e che vengono commercializzati. Poi ho precisato che se la diffusione è scarsa, è perché l'utenza a cui sono rivolti non è la massa. Ho aggiunto semplicemente che la stessa cosa si verificherà quando arriveranno anche i dual core PPC.

Se ci vedi una guerra contro i Mac o MacOS (che non ho nemmeno citato), sono soltanto fatti tuoi: evidentemente non sei in grado di accettare l'opinione di qualcuno senza pensare che sotto sotto ci sia del marcio. Poco importa: io dormo lo stesso...

Beh... basta leggere qualche tread per capire qual'è l'andazzo che sei solito mantenere. Ma meglio così se è come dici.
Tanto per non lasciare nulla in sospeso: scrivere una cosa del genere "Intanto ci sono già e vengono venduti. Che il volume sia basso è una cosa ovvia, visto che il target non è certo "la massa", e non credo che per i Mac la cosa sarà diversa..." in risposta a quello che avevo scritto io ha decisamente poco senso se non si vuole fare sterile polemica. E' ovvio che quando e se arriveranno i dual core IBM sui PowerMac il discorso sarà diverso visto che la Apple vende solo 6 tipologie di macchine e che probabilmente le CPU dual core saranno adottate in tutte le macchine desktop pro.... indipendentemente dalle volontà degli utenti: vuoi un PowerMac? Bene o dual core o niente (anche se è probabile che lasceranno una configurazine base come al solito).

EDIT: ma a quando un chiarimento sulla questione deframmentazione? Se è come dicono sull'altro tread la cosa è ben lontana da quelllo che scrivi tu

[Yokoshima]

Originariamente inviato da cdimauro

E' una differenziazione abbastanza vecchia: i processori CISC "moderni" (da una decina d'anni a questa parte), non rispecchiano più certi canoni, come anche per i RISC (che di istruzioni, ad esempio, non ne hanno poche, anzi!).

D'altra parte si programma quasi sempre in linguaggi ad alto livello, e le rare volte che viene usato l'assembly è per piccole porzioni di codice.

Si, infatti è una suddivisione arcaica, si potrebbe dire che le due differenti vie di sviluppo si siano un pò incrociate ed influenzate no?

Originariamente inviato da cdimauro

Quanto alla progettazione del software, proprio perché si usano per lo più linguaggi ad alto livelli, non incide sul tipo di processore utilizzato.

Ma per i sistemi operativi? Vero che anche quelli sono scritti ad alto livello oramai, ma non penso che nn incida l'architettura della cpu.

Originariamente inviato da cdimauro

Al contrario si tratta di CPU che vengono regolamente vendute, e abbastanza accessibili. Considera che ormai il "taglio minimo" è dato da processori a 3 / 3.2Ghz (Ghz o "equivalenti").

Si, ma resta il fatto che un Pentium IV 3.6GHz non lo danno con le patatine, come non danno una mobo Dual-channel e 1GB di ram (con latenze molto basse suppongo).
Io personalmente non potrei permettermelo, e poi considerando la velocità degli sviluppi tecnologici attuali...

Originariamente inviato da cdimauro

Penso che saranno PC come altri. Al più, se verrà usato un sistema Palladium-like, sarà questo che impedirà l'installazione su PC diversi da quelli che vuole Apple.

Comunque è presto per parlarne: aspettiamo il prossimo anno e vedremo come staranno realmente le cose...

Lo spererei anche io.. e che a quel punto si sviluppi un mercato parallelo HW non Palladium-like. (Utopia?)

Originariamente inviato da cdimauro

P.S. Salutami Reiko e Okinu...

Te le saluto con piacere!!!
Sei il primo a fare il collegamento!
Complimenti! Appassionato anche tu?

[cdimauro]

Originariamente inviato da Caesar_091

Beh... basta leggere qualche tread per capire qual'è l'andazzo che sei solito mantenere. Ma meglio così se è come dici.

L'andazzo per me è il solito: io parlo di questioni tecniche, ed esprimo dei pareri senza farmi condizionare dalla squadra del cuore.

Magari dovrei scrivere una FAQ, ma penso che la gente si comporterebbe sempre allo stesso modo...

Tanto per non lasciare nulla in sospeso: scrivere una cosa del genere "Intanto ci sono già e vengono venduti. Che il volume sia basso è una cosa ovvia, visto che il target non è certo "la massa", e non credo che per i Mac la cosa sarà diversa..." in risposta a quello che avevo scritto io ha decisamente poco senso se non si vuole fare sterile polemica.

La polemica la solleva chi fa trasprire la classica favoletta della volpe e dell'uva. Le risposte arrivano di conseguenza.

EDIT: ma a quando un chiarimento sulla questione deframmentazione? Se è come dicono sull'altro tread la cosa è ben lontana da quelllo che scrivi tu

Come hai sottolineato, c'è già un thread, ma a quanto pare sono l'unico ad averci scritto. Il mio messaggio in merito alla deframmentazione è rimasto figlio unico...

[cdimauro]

Originariamente inviato da Yokoshima

Si, infatti è una suddivisione arcaica, si potrebbe dire che le due differenti vie di sviluppo si siano un pò incrociate ed influenzate no?

Più che altro le due architetture si sono "scambiate" tante soluzioni agli stessi problemi.

Ma per i sistemi operativi? Vero che anche quelli sono scritti ad alto livello oramai, ma non penso che nn incida l'architettura della cpu.

Anche i s.o. sono scritti ad alto livello: sono ben poche le parti scritte in assembly. A volte si usa anche in alcuni driver, ma sempre in qualche piccola parte.

Si, ma resta il fatto che un Pentium IV 3.6GHz non lo danno con le patatine, come non danno una mobo Dual-channel e 1GB di ram (con latenze molto basse suppongo).
Io personalmente non potrei permettermelo, e poi considerando la velocità degli sviluppi tecnologici attuali...

Nemmeno io me lo posso permettere, dopo aver comprato due A64 2800+... Comunque non sono molto costosi. E i dual core Intel di fascia bassa sono molto appetibili come prezzo.

Lo spererei anche io.. e che a quel punto si sviluppi un mercato parallelo HW non Palladium-like. (Utopia?)

Le società che hanno aderito al consorzio Palladium sono tantissime: penso che difficilmente vedremo due mercati paralleli...

Te le saluto con piacere!!!
Sei il primo a fare il collegamento!
Complimenti! Appassionato anche tu?

Divoratore di manga , anche a tempo perso, da qualche anno a questa parte...

[Caesar_091]

Originariamente inviato da cdimauro

L'andazzo per me è il solito: io parlo di questioni tecniche, ed esprimo dei pareri senza farmi condizionare dalla squadra del cuore.

Magari dovrei scrivere una FAQ, ma penso che la gente si comporterebbe sempre allo stesso modo...

La polemica la solleva chi fa trasprire la classica favoletta della volpe e dell'uva. Le risposte arrivano di conseguenza.

Sarà...

Come hai sottolineato, c'è già un thread, ma a quanto pare sono l'unico ad averci scritto. Il mio messaggio in merito alla deframmentazione è rimasto figlio unico...

Io non ti leggo da nessuna parte:
http://www.hwupgrade.it/forum/showth...49#post8886149

[Sallustius]

Originariamente inviato da cdimauro

Sono anni che programmo in assembly per diverse macchine, e se ci sono delle architetture che sono più semplici da programmare a così basso livello, sono certamente quelle CISC. Gli x86 non saranno come i 68000, che in questo contesto erano una vera manna, ma si difendono piuttosto bene, e con l'incarnazione x86-64 la situazione migliora parecchio.
Programmare i RISC, per contro, richiede più tempo (per fare le stesse cose generalmente si deve scrivere più codice).

Quando parlavo di poche possibilità di scrivere codice assembler "decente", intendevo codice assembler "elegante"...con un set d'istruzioni sterminato come quello IA32 è davvero difficile usare sempre l'istruzione "giusta" al posto "giusto"...c'è sempre il collega che dirà "sai qui però avrei usato l'istruzione x anzichè la y....è quella a pagina 900 del terzo volume del reference..."
un codice da implementare con un set RISC è a mio avviso molto più semplice da rendere "elegante", ed essendo più vicino a quello che l'EU della macchina farà effettivamente sarà di più semplice "progettazione" e controllo...
ma l'immediatezza d'implementazione è naturalmente una considerazione personale

Sarà ugualmente disarmante sapere che è la stessa cosa che fanno RISC come il G5/Power4/Power5.

I 64 bit non fanno sempre comodo: se servono si usano, altrimenti se ne fa a meno. E' molto più comodo indirizzare più di 4GB di ram, che avere i 64 bit per gli interi, che servono in pochi (ma in alcuni casi significati, sicuramente: i database, ad esempio) ambiti applicativi...

E' naturale che la comodità di utilizzo venga fuori nei casi in cui può effettivamente esserci OF...ma purtroppo è un problema che viene fuori spesso quando ci si trova a gestire valori interi di una certa consistenza, e la possibilità di usare valori a 64 bit consente spesso di non ripiegare sulla soluzione di rappresentazione dei valori come valori in virgola mobile (mantenendo così la possiblità di ricorrere nei calcoli a comode proprietà come l'associatività delle operazioni di addizione e moltiplicazione, che andrebbero perse in alcuni casi usando le approsimazioni operate dalla notazione scientifica IEEE754)

[cdimauro]

x Caesar_091 Perché t'ho scritto qui: http://www.hwupgrade.it/forum/showth...98#post8885198 e te l'avevo anche detto.

[cdimauro]

Originariamente inviato da Sallustius

Quando parlavo di poche possibilità di scrivere codice assembler "decente", intendevo codice assembler "elegante"...con un set d'istruzioni sterminato come quello IA32 è davvero difficile usare sempre l'istruzione "giusta" al posto "giusto"...c'è sempre il collega che dirà "sai qui però avrei usato l'istruzione x anzichè la y....è quella a pagina 900 del terzo volume del reference..."
un codice da implementare con un set RISC è a mio avviso molto più semplice da rendere "elegante", ed essendo più vicino a quello che l'EU della macchina farà effettivamente sarà di più semplice "progettazione" e controllo...
ma l'immediatezza d'implementazione è naturalmente una considerazione personale

Penso che tu debba dare un'occhiata al set d'istruzioni dei RISC moderni. Hanno centinaia di istruzioni: da questo punto di vista fanno concorrenza a CISC come gli x86.

Per contro, processori come il 68000, che era uno dei processori CISC "più CISC" , aveva poche istruzioni, ed era facilissimo da programmare. A tutt'oggi penso che sia uno dei più semplici da programmare...

E' naturale che la comodità di utilizzo venga fuori nei casi in cui può effettivamente esserci OF...ma purtroppo è un problema che viene fuori spesso quando ci si trova a gestire valori interi di una certa consistenza, e la possibilità di usare valori a 64 bit consente spesso di non ripiegare sulla soluzione di rappresentazione dei valori come valori in virgola mobile (mantenendo così la possiblità di ricorrere nei calcoli a comode proprietà come l'associatività delle operazioni di addizione e moltiplicazione, che andrebbero perse in alcuni casi usando le approsimazioni operate dalla notazione scientifica IEEE754)

Indubbiamente, ma appunto bisogna considerare il tipo di applicazione. Normalmente usare interi a 32 bit è sufficiente per la stragrande maggioranza delle applicazioni. Infatti non è un caso che x86-64 di default manipoli dati a 32 bit.

[luxifero]

non so se qualcuno ne ha parlato, ma avantieri ho visto su macity un bench comparativo fra il mactel per sviluppatori, un pb g4 1.5 gh e un dual g5 2 gh. il nuovo prodigio tecnologico ne usciva abbastanza malcolcio: ricordo un distacco di bel 10 minuti e passa nell'encoding degli mp3 con itunes! chissa' perche' la pagina non e' piu' disponibile su macity :-)
eh si', proprio veloci questi processori intel!

[cdimauro]

Quindi tu pubblichi una cosa, qualcuno la vede, poi la fai sparire, e automaticamente diventa vero quel che avevi scritto?

Aspettiamo qualche informazione che non sparisca e che sia verificabile, invece di speculare su queste banalità...

[sari]

Cdimauro ma quanto rispondi? è da un'ora che leggo risposte su risposte, scrivi meno che devo anche studiare uffa!!! :P
Apparte ciò, bene o male concordo, rimanendo comunque dell'idea che Mac e Intel non si doveva fare... gusti personali che ce posso fa.

C'è solo una cosa errata
"Le società che hanno aderito al consorzio Palladium sono tantissime: penso che difficilmente vedremo due mercati paralleli... "

Il mercato parallelo c'e' sempre... tra Redmond e Cupertino c'e' sempre stato, e sempre ci sarà, un terzo "incomodo"

[0rph3n]

Originariamente inviato da norp74

x 0rph3n: a lui interessa provare ad accedere al sito da piattaforme diverse per vedere se il rendering è quello previsto. non è una questione di rete, ma di browser Mac diverso da quello Win

[OT=on]
appunto, il rendering della pagina viene eseguito dal browser!
quindi non vedo il problema!
infatti anche usando 2 browser diversi (nella mia macchina ho IE6sp2 e FF1.0.4) sullo stesso OS (sempre nella mia macchina win xp pro sp2) il rendering può cambiare!
[OT=off]