Torna indietro   Hardware Upgrade Forum > Hardware Upgrade > News

Huawei MatePad Pro, un ottimo tablet Android al giusto prezzo. La recensione
Huawei MatePad Pro, un ottimo tablet Android al giusto prezzo. La recensione
Huawei MatePad Pro punta ad offrire un'esperienza d'uso da top di gamma ad un prezzo sensibilmente inferiore rispetto alle proposte di Apple e Samsung, senza farsi però mancare nulla. Presenti a listino (ma non in dotazione, sono da acquistare separatamente), una comoda cover-tastiera dedicata e un pennino capacitivo.
The Last of Us: Parte II, le nostre prime impressioni sull'ambiziosa esclusiva PS4
The Last of Us: Parte II, le nostre prime impressioni sull'ambiziosa esclusiva PS4
Abbiamo trascorso le ultime giornate nel mondo post-apocalittico di The Last of Us: Parte II, approfittandone per trarre le nostre opinioni circa il lavoro svolto dal team capitanato da Neil Druckmann. Oggi possiamo condividere con voi le prime impressioni, spostando la lente d'ingrandimento su una determinata sezione del gioco.
TCL 10 Pro, un display 'top' ma prezzo da rivedere. La recensione
TCL 10 Pro, un display 'top' ma prezzo da rivedere. La recensione
TCL 10 Pro è uno smartphone che sorprende, migliorando drasticamente l'approccio nella categoria rispetto alle precedenti incursioni del produttore. Il display è finalmente in linea con le aspettative che suscita il brand, e l'esperienza d'uso è generalmente molto buona. Peccato per l'hardware integrato e il prezzo di listino: a nostro avviso si poteva osare di più per aggredire davvero il segmento medio del mercato.
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 09-11-2017, 15:01   #1
Redazione di Hardware Upg
www.hwupgrade.it
 
Iscritto dal: Jul 2001
Messaggi: 75179
Link alla notizia: http://www.hwupgrade.it/news/sistemi...686_72255.html

Arch Linux non offrirà più, a partire dalla giornata di oggi, il supporto ai pacchetti compilati per architetture i686 e, pertanto, destinati ai processori a 32 bit. Il futuro è a 64 bit anche per il Pinguino

Click sul link per visualizzare la notizia.
Redazione di Hardware Upg è offline   Rispondi citando il messaggio o parte di esso
Old 09-11-2017, 15:14   #2
s-y
Senior Member
 
L'Avatar di s-y
 
Iscritto dal: Nov 2007
Messaggi: 7455
beh, oddio, oltre che il futuro, il presente, ma anche il passato...
che, specialmente in passato, non fosse sto gran vantaggio e a volte anzi, ok, ma le versioni 64 bit ci sono da un pochinello di tempo, anche da prima rispetto ad altri os (per quanto non sia una gara e cmq è soprattutto la modularità del pinguino che ha permesso di 'migrare' prima)

Ultima modifica di s-y : 09-11-2017 alle 15:19.
s-y è offline   Rispondi citando il messaggio o parte di esso
Old 09-11-2017, 15:16   #3
mattia.l
Senior Member
 
L'Avatar di mattia.l
 
Iscritto dal: Apr 2014
Città: Ivrea (TO)
Messaggi: 713
e la i786? non era a 32bit anche quella?
__________________
Cooler Master 690|Asus Prime X299-Deluxe|Intel Core i7 7800x skt 2066|Gigabyte GTX 770 OC|16GB Corsair Vengeance RGB DDR4 3200|Noctua NH-U12P|Corsair HX850i
mattia.l è offline   Rispondi citando il messaggio o parte di esso
Old 09-11-2017, 15:30   #4
matrix83
Senior Member
 
Iscritto dal: Dec 2006
Messaggi: 642
Quote:
Originariamente inviato da mattia.l Guarda i messaggi
e la i786? non era a 32bit anche quella?
i686 è un termine generico per indicare qualsiasi 32bit, quindi anche quello
matrix83 è offline   Rispondi citando il messaggio o parte di esso
Old 09-11-2017, 15:39   #5
silviop
Member
 
Iscritto dal: Jul 2017
Messaggi: 98
Pemtium 4 3Ghz HT ....

ha ancora molto da dire nel mondo aziendale e infatti windows 10 LTSB 2016 esiste a 32bit (e sara supportato per altri 10anni),non capisco tutta questa fretta delle distribuzioni di abbandonare i 32bit x86, che comunque saranno supportati PER SEMPRE dal kernel linux,
spero che almeno ubuntu 18.04 LTS abbia ancora la versione server a 32bit almeno staremo tranquilli fino al 2023.
silviop è offline   Rispondi citando il messaggio o parte di esso
Old 09-11-2017, 15:43   #6
fano
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2095
Alla fine se non ha applicazioni scritte col c*lo che necessitano di più di 4 GB solo loro per funzionare, 64 bit non serve mica a molto!
Anche .NET di default compila con "prefer 32 Bit" che su Windows 64 Bit funziona alla perfezione (con WoW64), su Linux visto che l'architettura "ibrida" 32 / 64 non sono stati capici a farlo Mono ignorava il flag ed andava sempre a 64 Bit.

Lo sapete sì che alla fine il risultato più "tangibile" di avere applicazioni a 64 Bit è che usano il doppio della RAM?
__________________
Cosmos C# Open Source Managed Operating System
Cosmos Thread Ufficiale
Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat!
fano è offline   Rispondi citando il messaggio o parte di esso
Old 09-11-2017, 16:23   #7
Marco71
Senior Member
 
L'Avatar di Marco71
 
Iscritto dal: Nov 2003
Città: Provincia di Lucca
Messaggi: 3238
Invero...

...la prima cpu Intel a disporre di architettura completamente a 32 fu il glorioso 80386 con i suoi circa 275000 transistor integrati.
Per "i686" si intende la prima microarchitettura x86 con esecuzione delle istruzioni "fuori ordine"...una grande "famiglia" che iniziò con il processore Pentium Pro.

Marco71.
Marco71 è offline   Rispondi citando il messaggio o parte di esso
Old 09-11-2017, 16:37   #8
benderchetioffender
Senior Member
 
L'Avatar di benderchetioffender
 
Iscritto dal: Sep 2010
Messaggi: 1166
x64 a livello consumer è arrivato nel 2003.... direi che x86 ha fatto il suo tempo, visto sopratutto che il 64bit puo gestire agevolmente il 32bit mentre non si puo nel contrario
__________________
hey! quello non è un ufo! quelle sono le mie chiappe!
fatto affari con: AbuJaffa, PoliCarpo87, FIFA, cos1950, luciferme, testasemidura, giacomo_uncino, j0h, SSLazio83, pingalep, Rumpelstiltskin, Brend_ON, circularCore, A-ha, costantine...& altri che ora non ricordo
benderchetioffender è offline   Rispondi citando il messaggio o parte di esso
Old 09-11-2017, 17:08   #9
danieleg.dg
Senior Member
 
L'Avatar di danieleg.dg
 
Iscritto dal: Jun 2011
Messaggi: 890
Quote:
Originariamente inviato da fano Guarda i messaggi
Alla fine se non ha applicazioni scritte col c*lo che necessitano di più di 4 GB solo loro per funzionare, 64 bit non serve mica a molto!
Anche .NET di default compila con "prefer 32 Bit" che su Windows 64 Bit funziona alla perfezione (con WoW64), su Linux visto che l'architettura "ibrida" 32 / 64 non sono stati capici a farlo Mono ignorava il flag ed andava sempre a 64 Bit.

Lo sapete sì che alla fine il risultato più "tangibile" di avere applicazioni a 64 Bit è che usano il doppio della RAM?
Anche 32bit è troppo, torniamo a 8 così si consuma un quarto di ram!
danieleg.dg è offline   Rispondi citando il messaggio o parte di esso
Old 09-11-2017, 17:46   #10
Yrbaf
Senior Member
 
Iscritto dal: Dec 2015
Messaggi: 4778
Non diciamo stupidate solo per muovere le dita.

Il futuro è a 64 bit ma 32 bit sono ancora sufficienti per una buona fetta delle applicazioni del presente e spesso le versioni a 64 bit se non sfruttano i 64 bit (o nel caso x86 i registri in più, cosa magari non vera in tutte le altre architetture a 64b) sono pure più lente della controparte 32b.

La ram ormai sarà poco costosa (in config oltre 4GB) ma le cache di primo livello dei processori non sono cresciute così tanto (come gli altri livelli) rispetto a quando si era solo a 32b.
Forse anche a livello di MMU c'è un carico maggiore nell'usare i 64b sempre anche quando non servono.

Senza contare che ci sono vecchie macchine che hanno il supporto a 64b ma la ram fisica limitata comunque a 3-4GB e obbligarle a passare alla versione a 64b dell'OS (che potrebbe girare) sarebbe forse solo una perdita di prestazioni e basta senza veri altri benefici.

Ultima modifica di Yrbaf : 10-11-2017 alle 01:26.
Yrbaf è offline   Rispondi citando il messaggio o parte di esso
Old 09-11-2017, 17:53   #11
Opteranium
Senior Member
 
Iscritto dal: Feb 2004
Messaggi: 3307
era ora. Anche ubuntu li ha lasciati con la 17.10, ormai hanno fatto il loro tempo
Opteranium è offline   Rispondi citando il messaggio o parte di esso
Old 09-11-2017, 19:34   #12
AleLinuxBSD
Senior Member
 
L'Avatar di AleLinuxBSD
 
Iscritto dal: Dec 2005
Messaggi: 7037
Il problema principale dato dall'abbandono del supporto delle architetture a 32bit non viene dal supporto ai 64bit da parte delle Cpu, ma al livello di memoria Ram.

I computer super obsoleti non soltanto hanno una limitata quantità di Ram, chiedendo in negozio, te la vendono a peso oro.

Che poi questa decisione fosse inevitabile, considerando la grande dispersione di risorse in ambito Linux, era scontato.

Considerando poi la micidiale combinazione costituita dall'avvento di Wayland, nonché di applicazioni videoludiche che fanno uso di recenti standard non supportati neanche da hardware relativamente recente, il cambio a 64bit rappresenta pure il minore dei mali.
__________________
Distro:Ubuntu LTS, Debian,SL,OpenBSD
I love Linux, Bsd and the free software! Fantasia: fotografica
[Icewm]: Thread Ufficiale - light window manager Benchmark Cpu per sistemi Linux/BSD
AleLinuxBSD è offline   Rispondi citando il messaggio o parte di esso
Old 09-11-2017, 20:01   #13
s-y
Senior Member
 
L'Avatar di s-y
 
Iscritto dal: Nov 2007
Messaggi: 7455
cmq sia la arch è sempre stata 'drastica' su questi aspetti. ad esempio non supportava già ai tempi gli i386 (da pentium pro a scendere), e non credo sia da prendere come esempio tipico del mondo pinguinesco
s-y è offline   Rispondi citando il messaggio o parte di esso
Old 10-11-2017, 08:44   #14
Phoenix Fire
Senior Member
 
L'Avatar di Phoenix Fire
 
Iscritto dal: Sep 2006
Città: Aprilia
Messaggi: 10793
secondo me ha fatto bene, come detto da AleLinuxBSD, già le risorse mancano, se devo anche disperderle...
che poi come spiegato nell'articolo, non è che hanno "bloccato" la cosa, se la community vuole può continuare a svilupparseli lei, ma almeno io "distro" posso concentrare meglio le risorse
__________________
Quelli che dicevano che era impossibile non hanno mai fatto un tentativo
Inventario Steam contattatemi se interessati
Phoenix Fire è offline   Rispondi citando il messaggio o parte di esso
Old 10-11-2017, 09:10   #15
s-y
Senior Member
 
L'Avatar di s-y
 
Iscritto dal: Nov 2007
Messaggi: 7455
si, avevano preannunciato la cosa con anticipo motivando proprio con la difficoltà a manutenere entrambe le versioni

tra l'altro come specificato la v 32 è stata 'comunityzzata', e la serietà degli arch user esperti dovrebbe garantire una buona qualità di release, anche se da capire come proseguirà la cosa
s-y è offline   Rispondi citando il messaggio o parte di esso
Old 10-11-2017, 09:23   #16
WarDuck
Senior Member
 
L'Avatar di WarDuck
 
Iscritto dal: May 2001
Messaggi: 11070
Quote:
Originariamente inviato da fano Guarda i messaggi
Alla fine se non ha applicazioni scritte col c*lo che necessitano di più di 4 GB solo loro per funzionare, 64 bit non serve mica a molto!
Anche .NET di default compila con "prefer 32 Bit" che su Windows 64 Bit funziona alla perfezione (con WoW64), su Linux visto che l'architettura "ibrida" 32 / 64 non sono stati capici a farlo Mono ignorava il flag ed andava sempre a 64 Bit.

Lo sapete sì che alla fine il risultato più "tangibile" di avere applicazioni a 64 Bit è che usano il doppio della RAM?
Avere uno spazio di indirizzamento più ampio non vuol dire solo poter usare più RAM, ma anche sfruttare più bit per l'algoritmo di randomizzazione degli indirizzi logici (ALSR).

Le applicazioni 64 bit sono tendenzialmente più sicure delle stesse compilate a 32 bit.

Inoltre in x86_64 hai a disposizione il doppio dei registri, con tutti i benefici di ciò.

Il fatto che le applicazioni 64 usino il doppio della RAM non è un assoluto: sono i puntatori ad occupare il doppio.

Motivo per cui hanno sviluppato l'ABI x32, per il supporto ai registri a 64 bit con indirizzi a 32 bit.
__________________
Scythe Ninja 4 | Intel Core i5-6600k | ASUS Z170 Pro Gaming | 16GB DDR4 2400 CL12 kingston savage | EVGA GTX1060 SC 6GB | OCZ Vertex2 60g | WD 2tb | Dell UltraSharp U2518D | UAC: 1 2 | Win10 e aggiornamenti | Arch Linux | Dogmi
WarDuck è offline   Rispondi citando il messaggio o parte di esso
Old 10-11-2017, 10:18   #17
fano
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2095
Sì ma il doppio dei registri non è un vantaggio dei 64 bit era x86 che faceva un po' schifo c'erano processori a 32 bit (tipo ARM e forse pure M68K!) che di registri ne avevano comunque 32 o 64... mica 8!

Diciamo pure che x86 è nato male cresciuto peggio e che x64 cerca di metterci delle pezze, ma è un po' un casino di architettura.

L'ABI 32x che io trovo una soluzione interessante per uso "desktop" sembra come al solito essere stata abbandonata su Linux almeno io non la vedo molto pubblicizzata... non me la sentirei sinceramente di usarla in produzione: già i driver sono pochi figuriamoci per la versione "esotica" 32x.

La stiamo valutando per Cosmos credo che a tendere sarà quella la "nostra" versione a 32 bit, supportare 8087, farli i "long" a mano scrivendo dentro 2 registri, menarsela a salvare tutto nello stack non ha molto senso quando processori 32 bit "puri" sono una nicchia della nicchia, magari avrà senso per particolari soluzioni embedded in cui sono usate m*rdate tipo "Galileo" o "Geode".
__________________
Cosmos C# Open Source Managed Operating System
Cosmos Thread Ufficiale
Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat!

Ultima modifica di fano : 10-11-2017 alle 10:22.
fano è offline   Rispondi citando il messaggio o parte di esso
Old 10-11-2017, 11:47   #18
Yrbaf
Senior Member
 
Iscritto dal: Dec 2015
Messaggi: 4778
Per la precisione Arm (32bit) e M68K di registri generici ne hanno solo 16 (sempre meglio degli 8 di x86) e non 32 o più.

32 registri (limitandoci agli interi, visto che sopra non ho contato gli FP) li avevano/hanno MIPS (in realtà 1 è un registro fisso a zero), PowerPC, Power di IBM, Dec Alpha, Sun/Oracle Sparc e gli Arm quando operano nella modalità a 64 bit (quindi Arm come x86 vede un raddoppio dei registri passando in ABI64).

PS
La JVM a 64 bit di Java usa la tecnica dei puntatori compressi.
I puntatori (interni non si ha accesso diretto ai puntatori in java) sono nativi a 64b ma finché non si richiedono più di 2/4GB di memoria per la JVM vengono compressi per stare in 32b, altrimenti i benchmark mostrano mediamente decrementi delle prestazioni (mi pare di aver letto -30%) per i software che non se ne fanno nulla di tanta ram ma con puntatori a 64b sfruttano di meno le cache.
Presumo (ma non lo so) che qualcosa di simile lo faccia anche Net.

Ultima modifica di Yrbaf : 10-11-2017 alle 11:54.
Yrbaf è offline   Rispondi citando il messaggio o parte di esso
Old 11-11-2017, 12:51   #19
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 24241
Quote:
Originariamente inviato da Yrbaf Guarda i messaggi
Non diciamo stupidate solo per muovere le dita.

Il futuro è a 64 bit ma 32 bit sono ancora sufficienti per una buona fetta delle applicazioni del presente e spesso le versioni a 64 bit se non sfruttano i 64 bit (o nel caso x86 i registri in più, cosa magari non vera in tutte le altre architetture a 64b) sono pure più lente della controparte 32b.
Sfruttare i registri in più di x64 è molto più semplice, nonché comune ed effettivamente usato, che sfruttare i 64 bit. Basta disassemblare un po' di applicazioni per rendersene conto.

Eseguibili IA-32/x86, con soli 8 registri a disposizione (in realtà 7, perché uno riservato allo stack), sono pieni di istruzioni PUSH e POP per salvare e ripristinare registri, a cui si aggiungono vagonate di istruzioni che referenziano locazioni nello stack.

Eseguibili per x86-64/x64, invece, presentano di gran lunga meno casi del genere, e un notevole sfruttamento degli 8 registri in più.

Applicazioni a 64 bit che girano più lentamente delle equivalenti a 32 bit ce ne possono essere, senz'altro, ma sono una minoranza. In genere un'applicazione a 64 bit gira il 10-15% più velocemente della stessa, ma a 32 bit.
Quote:
La ram ormai sarà poco costosa (in config oltre 4GB) ma le cache di primo livello dei processori non sono cresciute così tanto (come gli altri livelli) rispetto a quando si era solo a 32b.
No, ma quelle L2 e, soprattutto, L3 sono cresciute molto, e quindi mitigano molto l'accresciuta dimensione del codice (in genere il codice x64 è del 20-25% più grande di quello x86) e il raddoppio della dimensione dei puntatori (che è il problema primario quando si passare a un'ISA a 64 bit).
Quote:
Forse anche a livello di MMU c'è un carico maggiore nell'usare i 64b sempre anche quando non servono.
Sì, ed ed è sempre tutto legato alla maggior dimensione del codice e dei dati.
Quote:
Senza contare che ci sono vecchie macchine che hanno il supporto a 64b ma la ram fisica limitata comunque a 3-4GB e obbligarle a passare alla versione a 64b dell'OS (che potrebbe girare) sarebbe forse solo una perdita di prestazioni e basta senza veri altri benefici.
Con 4GB in genere si va abbastanza bene con s.o. & applicazioni a 64 bit.

Ovviamente dipende anche da quante se ne fanno girare, e di che tipo.
Quote:
Originariamente inviato da WarDuck Guarda i messaggi
Avere uno spazio di indirizzamento più ampio non vuol dire solo poter usare più RAM, ma anche sfruttare più bit per l'algoritmo di randomizzazione degli indirizzi logici (ALSR).

Le applicazioni 64 bit sono tendenzialmente più sicure delle stesse compilate a 32 bit.

Inoltre in x86_64 hai a disposizione il doppio dei registri, con tutti i benefici di ciò.

Il fatto che le applicazioni 64 usino il doppio della RAM non è un assoluto: sono i puntatori ad occupare il doppio.

Motivo per cui hanno sviluppato l'ABI x32, per il supporto ai registri a 64 bit con indirizzi a 32 bit.
*

Anche se purtroppo è un'ABI che viene usata troppo poco.
Quote:
Originariamente inviato da fano Guarda i messaggi
Diciamo pure che x86 è nato male cresciuto peggio e che x64 cerca di metterci delle pezze, ma è un po' un casino di architettura.
x64 è una pezza in tutti i sensi, perché il lavoro che hanno fatto lascia il tempo che trova.

Comunque il problema più grosso di x86/x64 è rappresentato dai decoder. Ma una volta che le istruzioni sono state tradotte in micro-op, il backend è poco influenzato dal "legacy".
Quote:
L'ABI 32x che io trovo una soluzione interessante per uso "desktop" sembra come al solito essere stata abbandonata su Linux almeno io non la vedo molto pubblicizzata... non me la sentirei sinceramente di usarla in produzione: già i driver sono pochi figuriamoci per la versione "esotica" 32x.
Purtroppo è proprio questo il problema: la scarsa adozione. Aggiungiamoci pure che Microsoft ha completamente ignorato quest'ABI.

E' un vero peccato, perché oggi si potrebbero tranquillamente utilizzare applicazioni x32 e x64, a seconda dei casi, sfruttando il meglio delle due ABI.
Quote:
La stiamo valutando per Cosmos credo che a tendere sarà quella la "nostra" versione a 32 bit, supportare 8087, farli i "long" a mano scrivendo dentro 2 registri, menarsela a salvare tutto nello stack non ha molto senso quando processori 32 bit "puri" sono una nicchia della nicchia, magari avrà senso per particolari soluzioni embedded in cui sono usate m*rdate tipo "Galileo" o "Geode".
Infatti i 32 bit "puri" (x86) hanno senso sostanzialmente solo in ambito embedded ormai.
Quote:
Originariamente inviato da Yrbaf Guarda i messaggi
Per la precisione Arm (32bit) e M68K di registri generici ne hanno solo 16 (sempre meglio degli 8 di x86) e non 32 o più.
In realtà i 68K hanno 8 registri dati e 8 registri indirizzi. I registri, quindi, non sono "ortogonali" (utilizzabili indifferentemente).

Mentre in x64 (e x32) sono ortogonali.
Quote:
PS
La JVM a 64 bit di Java usa la tecnica dei puntatori compressi.
I puntatori (interni non si ha accesso diretto ai puntatori in java) sono nativi a 64b ma finché non si richiedono più di 2/4GB di memoria per la JVM vengono compressi per stare in 32b, altrimenti i benchmark mostrano mediamente decrementi delle prestazioni (mi pare di aver letto -30%) per i software che non se ne fanno nulla di tanta ram ma con puntatori a 64b sfruttano di meno le cache.
Presumo (ma non lo so) che qualcosa di simile lo faccia anche Net.
Davvero molto interessante, grazie.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 12-11-2017, 12:26   #20
fano
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2095
Quote:
Originariamente inviato da Yrbaf Guarda i messaggi
PS
La JVM a 64 bit di Java usa la tecnica dei puntatori compressi.
I puntatori (interni non si ha accesso diretto ai puntatori in java) sono nativi a 64b ma finché non si richiedono più di 2/4GB di memoria per la JVM vengono compressi per stare in 32b, altrimenti i benchmark mostrano mediamente decrementi delle prestazioni (mi pare di aver letto -30%) per i software che non se ne fanno nulla di tanta ram ma con puntatori a 64b sfruttano di meno le cache.
Presumo (ma non lo so) che qualcosa di simile lo faccia anche Net.
.Net in realtà quando usato con "AnyCpu" si intende "Prefer 32 Bit" quindi se possibile il Jitter crea istruzioni a x86 proprio per il problema di non usare troppa memoria.
Non è x86 "puro" visto che hanno iniziato ad usare comunque SSE per operazioni floating point e vettoriali, ma non può nemmeno essere chiamato x32... è una via di mezzo.

Durante l'esecuzione le applicazioni .NET girano quindi o "nativamente" sulla CPU se l'OS è a 32 bit oppure usano WoW per girare a 32 bit su Windows 64, il Jitter può comunque decidere di ignorare il "consiglio" e far girare tutto a 64 bit se così desidera (su Linux 64 non c'è "LoL" quindi...), questo credo vale solo su x86 non so una CPU ARM64 può switchare tra 64 / 32 bit a runtime...

Questo può essere simile ai "compressed pointers" di Java: https://github.com/dotnet/coreclr/issues/555
__________________
Cosmos C# Open Source Managed Operating System
Cosmos Thread Ufficiale
Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat!
fano è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Huawei MatePad Pro, un ottimo tablet Android al giusto prezzo. La recensione Huawei MatePad Pro, un ottimo tablet Android al ...
The Last of Us: Parte II, le nostre prime impressioni sull'ambiziosa esclusiva PS4 The Last of Us: Parte II, le nostre prime impres...
TCL 10 Pro, un display 'top' ma prezzo da rivedere. La recensione TCL 10 Pro, un display 'top' ma prezzo da rivede...
iPhone SE (2020): abbiamo davvero bisogno di un top di gamma? La recensione iPhone SE (2020): abbiamo davvero bisogno di un ...
OVHcloud Game Server, i server dedicati per giocatori (e non solo) alla prova OVHcloud Game Server, i server dedicati per gioc...
Razer Ornata V2: la tastiera con Mecha-M...
Se compri un notebook MSI Prestige o Cre...
LEGO Technic Lamborghini Sián FKP...
Il nuovo supercomputer Fugaku di Fujitsu...
iOS 14: ecco quali iPhone saranno compat...
iPhone 12, ecco come saranno tutti i qua...
Huawei, il prossimo flagship potrebbe av...
SpaceX Starlink: nel lancio di stanotte ...
Cisco Designed: un portafoglio di soluzi...
Sondaggio Snom: la metà degli ute...
Thermaltake, il primo dissipatore a liqu...
Il razzo SpaceX Falcon 9 della missione ...
Una Tesla Model 3 non rallenta per evita...
Immuni: attenzione alla mail ''fasulla''...
Tesla Model 3: in Italia a maggio ne son...
Firefox Portable
Firefox 77
Chromium
GPU Caps Viewer
PeaZip
IObit Software Updater
NTLite
K-Lite Codec Pack Update
K-Lite Mega Codec Pack
K-Lite Codec Pack Full
K-Lite Codec Pack Standard
K-Lite Codec Pack Basic
SiSoftware Sandra Lite
Paint.NET
OCCT
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 03:24.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Served by www3v
1