Torna indietro   Hardware Upgrade Forum > Hardware Upgrade > News

Samsung Galaxy S21, S21+ S21 Ultra: eccoli nella nostra video anteprima!
Samsung Galaxy S21, S21+ S21 Ultra: eccoli nella nostra video anteprima!
Siamo riusciti ad andare al quartier generale di Milano dove Samsung ci ha permesso di mettere le mani su tutte e tre le versioni dei nuovi smartphone Galaxy S21, S21+ e S21 Ultra. Tre diverse versioni proprio come tre erano gli smartphone lo scorso anno con la serie Galaxy S20. Ecco come sono fatti.
ASUS ZenBook Duo UX482: due schermi e tanta autonomia
ASUS ZenBook Duo UX482: due schermi e tanta autonomia
La nuova gamma di notebook ASUS per il 2021 vede il ritorno di modelli con due schermi, capaci di offrire un livello di produttività ancora più elevato dello standard. ZenBook Duo UX482 abbina uno schermo da 14 pollici Full HD al nuovo ScreenPad +, tutto su piattaforma Intel EVO con processore Core i7 Tiger Lake. Tanta potenza, dimensioni contenute e autonomia con batteria da vendere
Sony FE 35mm F1.4 GMaster, grande risoluzione e sfocato eccellente. La recensione
Sony FE 35mm F1.4 GMaster, grande risoluzione e sfocato eccellente. La recensione
Sony introduce per le sue mirrorless full frame un 35mm della famiglia GMaster, che si distingue per l'elevatissimo potere risolvente e l'eccellente resa dello sfocato.
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 22-11-2020, 21:46   #61
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 25065
Quote:
Originariamente inviato da amd-novello Guarda i messaggi
cmq avere tali prestazioni con consumi così ridicoli se non è una rivoluzione questa non so cosa lo sia.
Mi riquoto:
"In primis complimenti ad Apple che ha tirato fuori un chip [...] davvero superlativo."


Quote:
la competizione è sempre meglio per il cliente. intel si è meritata certi scossoni.
Ma anche no. La competizione migliore per i consumatori sarebbe stata se Intel NON avesse avuto problemi coi suoi processi produttivi, e quindi avesse potuto trarre beneficio della maggior densità dei transistor E dei minor consumi, permettendo quindi di avere CPU con molti più core e/o con core a prestazioni molte più elevate e/o con consumi più ridotti.

Augurare a Intel di meritarsi quel che sta passando equivale, per un consumatore, a darsi una martellata sui gioielli di famiglia.
Quote:
adesso spero si riprenda prima o poi se no anche amd alzerà così la cresta e venderà cpu a peso d'oro. INTEL : "se volete più di 4 core dovete darmi 1000 euri"
Ti svelo un segreto: il prezzo lo fa il mercato, e non Intel.

Ed è fondamentale che ci sia parecchia competizione nel mercato, per far abbassare i prezzi e/o per ottenere chip con prestazioni a parità di costo.
Quote:
Originariamente inviato da digieffe Guarda i messaggi
ho bisogno di un altro paio di cents

non credi che i soli 16 registri GRP dell'architettura x86_64 siano un limite alla possibilità di estrarre parallelismo e quindi ipc dal codice (questo a prescindere poi dalle risorse a valle come dispatcher ed unità di esecuzione)
C'è un paper che però è un po' vecchiotto, che ha indagato proprio sulla scalabilità delle prestazioni di x86-64 in base al numero dei registri a disposizione. Lo trovi qui.

Questa la sintesi:
"Finally, we observe that using 16 GPRs and 16 XMM registers significantly outperforms the scenario when only 8 GPRs and 8 XMM registers are used. However, our results also show that using 12 GPRs and 12 XMM registers can achieve as competitive performance as employing 16 GPRs and 16 XMM registers.
[...]
Figure 7 gives the normalized execution time (with respect to the base compilation using 16 GPRs and 16 XMM registers) with the REG_8 and REG_12 register configurations for the SPEC2000 benchmarks. On average, with the REG_8 configuration, the CINT2000 exhibits a 4.4% slowdown, and the CFP2000 exhibits a 5.6% slowdown; with the REG_12 configuration, the CINT2000 is slowed down by 0.9%, and the CFP2000 is slowed down by 0.3%. Clearly, these results show that REG_12 already works well for most of the SPEC2000 benchmarks.
[...]
In addition to performance, the normalized dynamic number of memory accesses (including stack accesses) for the CINT2000 and CFP2000 is shown in Fig. 8. On average, with the REG_8 configuration, the memory references are increased by 42% for the CINT2000 and by 78% for the CFP2000; with the REG_12 configuration, the memory references are increased by 14% for CINT2000 and by 29% for the CFP2000.
Overall, for the SPEC2000 benchmark suite, we can see the trend that when the number of available registers is increased from 8 to 12, the memory accesses are reduced dramatically, and moderate performance improvement is achieved. However, with more than 12 registers, although the memory accesses are further reduced, the performance is barely improved"

In sintesi: con 12 registri anziché i classici 16 le prestazioni sono quasi le stesse. L'unica differenza è un aumento delle richieste di accesso alla memoria (+14% per CINT200 e +29% per CFP2000), che però non hanno praticamente influenza sulle prestazioni (-0,9% e -0.3% rispettivamente).

Questo penso per tre motivi.

Il primo è che Intel ha (aveva, all'epoca di questa ricerca) un'ottima micro-architettura che gestisce molto bene gli accessi alla memoria (d'altra parte basti analizzarne anche oggi i diagrammi per vedere proprio come Intel abbia da sempre privilegiato quest'aspetto).

Il secondo è che un'architettura (non micro-architettura) CISC ha bisogno di meno registri rispetto a una RISC, perché in genere può applicare l'accesso alla memoria (solo load+op, o load+op+store) a ogni istruzione (o comunque alla maggior parte / più comuni - "general purpose") che le consente di risparmiare registri utilizzati.

Oltre al fatto, ed è il terzo motivo a corollario del precedente, che dispone di molte più modalità d'indirizzamento verso la memoria, e quindi richiede meno registri per alcuni scenari più complicati, ma comunque abbastanza comuni.
Tipico esempio è l'accesso agli array con elementi superiori al byte (interi o float a 16, 32 e 64-bit), che ad esempio su x86/x64 (ma anche nei gloriosi Motorola 68020+ ) si risolve con la modalità d'indirizzamento [Base + Indice * Scala + Offset), che parecchi RISC non hanno a disposizione, e quindi soffrono nel tentare di emularla (in particolare RISC-V i cui accademici hanno ben pensato di offrire UNA sola modalità d'indirizzamento, Base + Offset, e poi si vede come le prestazioni crollino nei casi di cui sopra).
Quote:
dunque se così fosse non sarebbe arrivato il tempo di una revisione della base dell'architettura con un eventuale "x86_64+" 32GPR ecc? ^_^
Leggendo il paper di cui sopra sembrerebbe di no, e quindi che pure i 16 registri siano persino abbondanti.

In realtà, e come dicevo prima, il paper è molto vecchio e parecchi benchmark, come pure le applicazioni reali, sono cambiate nel corso degli anni.

Probabilmente oggi più registri potrebbero essere sfruttati meglio per migliorare le prestazioni e/o per ridurre gli accessi alla memoria (una santa cosa anche questa), ma in ogni caso a un CISC, x64 incluso (ormai x86 lasciamolo perdere, perché il futuro è chiaramente a 64 bit, tant'è che ormai persino nell'embedded comincia ad avere una percentuale rilevante), servirebbero meno registri.

Inoltre l'utilizzo dei registri si può ulteriormente ridurre in un CISC introducendo altre utili nonché comuni modalità d'indirizzamento verso la memoria (ad esempio quelle di pre/post inc/decremento), oppure con istruzioni di tipo memory-to-memory, o ancora facendo sì che le istruzioni possano essere "potenziate" consentendo di abilitare nuove caratteristiche che si applicano in parallelo al lavoro che fanno normalmente (ad esempio marcare come "non-temporal" l'accesso alla memoria in modo da evitare che i dati siano copiati nelle cache e quindi che la "inquinino". Oppure far sì che un'istruzione modifichi i flag se questa normalmente non lo prevede, o viceversa venga soppressa la modifica dei flag per le istruzioni che normalmente lo fanno. O ancora che si possa leggere dalla memoria un dato di dimensione minore rispetto a quello con la quale lavora l'istruzione, estendendolo con zero o con segno, ecc.).

Sono tutte cose che si possono implementare in un CISC, e che consentono di migliorare la densità di codice e/o di ridurre il numero di registri usati e/o di ridurre il numero di istruzioni eseguite e/o di ridurre l'utilizzo della memoria e/o di ridurre l'utilizzo delle cache dati.
Sfortunatamente ormai c'è poca ricerca nei CISC, perché da parecchio praticamente tutti, produttori di CPU e accademici, si sono buttati a pesce sui RISC.

La mia architettura, invece, va controcorrente perché è CISC, e nasce per proprio per dare impulso e sfruttare ancora meglio le caratteristiche / funzionalità di tale macrofamiglia. Infatti implementa tutte le caratteristiche di cui sopra più altre (che non ho snocciolato per non appesantire ancora di più il discorso), e i primi risultati mostrano che a livello di densità di codice c'è un miglioramento (soprattutto in confronto a x64), ma anche il numero di istruzioni eseguite è ridotto (perché due o più istruzioni x86/x64 sono "fuse" in una sola della mia ISA). Il tutto utilizzando soltanto una piccola frazione di tutte le nuove caratteristiche, e dunque con ampi margini di miglioramento.

Quindi, e per rispondere alla tua domanda, un "x86_64+" 32GPR ci sarebbe già, visto che la mia ISA è compatibile al 100% a livello di sorgenti con x86 e x64, e casualmente mette a disposizione proprio 32 registri GP (ma nei miei benchmark ne uso soltanto 9-10 quando la confronto con x86, e 17-18 quando la confronto con x64).

Non c'è compatibilità binaria, perché tanto è del tutto inutile, visto che se i registri diventano 32 dovresti comunque cambiare gli opcode, e quindi risulterebbe incompatibile con x86/x64. Cosa che peraltro è avvenuta con x64, visto che è sostanzialmente una nuova ISA (anche se basata in buona parte su x86; quindi non è nemmeno 100% compatibile a livello di sorgenti / istruzioni a disposizione), e che è avvenuta con AArch64 che non ha nulla a che vedere con la classica ARM visto che gli opcode sono completamente diversi ed è soltanto parzialmente compatibile a livello sorgente.
Quote:
Originariamente inviato da LMCH Guarda i messaggi
Condivido buona parte di quello che hai scritto, aggiungo solo un tre cose:

1) Big Sur su M1 esegue quasi 5 VOLTE PIÙ VELOCEMENTE acquisizione e rilascio degli NSObject (fonte https://daringfireball.net/2020/11/the_m1_macs ).

Praticamente quasi tutte le risorse a livello di S.O. e framework applicativi Apple sono gestite come NSObject (gestiti con reference counting), quindi questo ha effetto su tutte le applicazioni compilate appositamente per il S.O. Apple.
Si parla di circa 30 ns su x86, circa 6.5 ns su M1 nativo e circa 14 ns con codice "per Apple x86" emulato su M1.
Questo ha anche risvolti positivi sul risparmio energetico complessivo.
E suppongo che vi siano altre ottimizzazioni meno evidenti che traggono vantaggio da M1.
Sì, ma non è una novità: iOS funziona già così da anni pure coi precedenti SoC Apple.

Apple è passata all'architettura a soli 64 bit anche per questo motivo, perché sfrutta parte dei bit dei puntatori come "tag" per memorizzare delle informazioni per il garbage collector e altro. Ecco perché riesce a essere così veloce nell'allocazione, utilizzo, e rilascio degli oggetti.

E' una caratteristica peculiare dell'implementazione Apple di AArch64, ma che anche altri produttori CPU potrebbe utilizzare, anche con architetture completamente diverse.
Quote:
Penso che sia da li che hanno origine molti dei miglioramenti in termini di prestazioni e risparmio energetico: ottimizzazione sinergica di hardware e software.
Rispetto alle più che buone performance con app x86 compilate per Mac, c'è quindi da aspettarsi prestazioni più basse quando si fa girare in emulazione software x86 per Windows sugli M1.
Con codice x86 che chiama poco il S.O. rispetto al tempo in cui esegue codice le prestazioni saranno più basse, mentre se si usa solo software compilato per Mac (per M1 o per x86 ma che chiama spesso il S.O.) si avranno prestazioni migliori.
Esattamente, ed è anche normale e ovvio che sia così: il livello di integrazione nonché personalizzazione fra hardware e software che ha Apple non ce l'ha nessuno, e i benefici sono evidenti.
Quote:
2) il set di istruzioni è rilevante per quel che riguarda quali sono le ottimizzazioni architetturali di una cpu.
Se gli x86 di Intel ed AMD si sono fermati a decodificare 4..5 istruzioni per ciclo, mentre Apple ne decodifica 8, é perche con l'attuale architettura x86 il rapporto prestazioni/costo arriva fino a li, mentre con AArch64 è possibile salire oltre prima che il "costo implementativo" superi i benefici.
Questo succede perché quelle di x86/x64 sono istruzioni CISC, e che dunque generano più micro-op, mentre quelle di AArch64 sono RISC e normalmente non generano più micro-op.

Dunque non si possono confrontare direttamente le 4-5 (ma credo che siano 4 al massimo, pure con Skylake) di x86/x64 con le 8 di AArch64/Apple.

IMO il vero vantaggio (a livello prestazionale) delle micro-architetture Apple è il mostruoso backend unito a una montagna di risorse in più che sono messe a sua disposizione.

Il frontend di x86/x64, per quanto certamente molto più complicato di quello di AArch64, è relativamente piccolo perché da parecchi a questa parte è sostanzialmente lo stesso, con qualche piccola aggiunta che è stata via via fatta.

Considerato che il numero di transistor a disposizione (e utilizzati) raddoppia ogni 2 anni, puoi capire da solo che in tutti questi anni tale frontend occupi ormai ben poco spazio rispetto a tutto il resto.

Ricapitolando: è complicato e succhia energia, ma con chip da decine di miliardi di transistor ormai il suo peso è relativamente trascurabile.
Quote:
Sia chiaro che non è che Arm sia superiore ad x86 o viceversa, ma che set di istruzioni differenti possono richiedere ottimizzazioni architetturali differenti
Assolutamente. Uno dei vantaggi dei RISC, che si rivela essere una forte penalizzazione di x86/x64 in diversi casi comuni, è dato dalla possibilità di eseguire istruzioni ternarie (due registri sorgenti e uno destinazione), che consente loro di risparmiare sia un registro (o, al limite, di usare lo stesso registro, ma creando uno stallo nella pipeline a causa della dipendenza che si crea) sia un'istruzione eseguita (x86/x64 devono usare in ogni caso due istruzioni per poter fare la stessa cosa).
Quote:
(es: sugli x86 è già da anni conveniente avere l'hyperthreading, sugli Arm ancora no).
Anche sugli ARM sarebbe conveniente, e mi riferisco principalmente per le micro-architetture che hanno core grossi.

Il discrimine se usare tecnologie come HT/SMT IMO è proprio quello: quanto grandi siano i core (che, quindi, richiedono una piccola percentuale di transistor per duplicare le risorse necessarie per i due o più thread hardware).
Quote:
3) Gira voce che nel 2021 Apple proporrà sul mercato un evoluzione di M1 con 12 core (8 ad alte prestazioni e 4 a basso consumo), non mi stupirei se fosse quella la cpu che verrà proposta per la fascia desktop/workstation/server.
Sui desktop non avrei dubbi, ma su workstation e server sì, visto che lì serve parecchia memoria, e i SoC Apple hanno i chip saldati sopra.
Quote:
Ipotizzo che semplicemente non ci sarà la GPU integrata ed al suo posto ci saranno altri 4 core e le interconnessioni ed interfacce per supportare una maggior quantità di ram e la GPU "esterna" (oppure nello stesso package?).
La GPU integrata fa comodo, specialmente considerando che usa lo stesso bus per accedere alla memoria. E dunque diversi carichi di lavoro si possono smistare a questa componente.
__________________
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 22-11-2020, 22:56   #62
digieffe
Senior Member
 
L'Avatar di digieffe
 
Iscritto dal: Oct 2003
Città: Milano
Messaggi: 4046
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Cut
la tua architettura ha istruzioni ternarie?
ha qualche forma (non totalmente) di ortogonalità delle istruzioni ?
__________________
spesso, è solo quando sai che non ti resta molto tempo che ne apprezzi il reale valore
quote: "some users are a classic example of the inverse ratio between the size of the mouth and the size of the brain"
* se non vi rispondo è perché siete (150+) nella mia ignore list * mi chiedo perché chi è nella ignore list è spesso sospeso e, prima o poi, viene bannato *
digieffe è offline   Rispondi citando il messaggio o parte di esso
Old 22-11-2020, 23:32   #63
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 25065
Quote:
Originariamente inviato da digieffe Guarda i messaggi
la tua architettura ha istruzioni ternarie?
Certamente, e proprio per quanto detto sopra non potevano mancare.

Più precisamente per tutte le istruzioni che sono esclusivamente binarie (la maggior parte di quelle più vecchie; quelle nuove spesso sono già ternarie di loro, ma sono comunque poche al momento) ho tre possibilità:
- R1 = R2 op immediato-con-segno-a-8 bit soltanto per poche istruzioni (le più comuni: ADD, SUB, SBB, ecc..)
- R1 = R2 op R3 per tutte le istruzioni binarie;
- R1 = R2 op Memoria (oppure Memoria = R2 op R1) per tutte le istruzioni binarie, che vengono "promosse" (dall'attuale forma R1 = R1 op Memoria, oppure Memoria = Memoria op R1) potendo impiegare un registro addizionale (che ho chiamato genericamente R2) quale prima sorgente.

Le prime forme occupano 32-bit / 4 byte, quindi la dimensione è la stessa dei RISC, e non c'è penalizzazione da questo punto di vista. La terza forma, dovendo prevedere la possibilità di referenziare la memoria (oltre ai registri) occupa necessariamente più di 4 byte, ma in questo caso posso applicare/abilitare "gratuitamente" (senza richiedere ulteriori byte in più) alcune delle caratteristiche che ho elencato prima ("non-temporal", flag modificati o soppressi, estensione con zero o segno della seconda sorgente con dimensione inferiore all'istruzione).
Quote:
ha qualche forma (non totalmente) di ortogonalità delle istruzioni ?
Le istruzioni sono per lo più ortogonali, perché agiscono su tutti i registri indifferentemente, e soprattutto la dimensione dell'operando è liberamente selezionabile fra byte/word/longword/quadword (perfino per istruzioni che su x86/x64 supportano soltanto alcune di quelle dimensioni).

La cosa più interessante, però, è l'unità SIMD, che è totalmente ortogonale: ogni istruzione può operare indifferentemente:
- sui registri MMX, SSE, AVX, AVX-512;
- può essere scalare (non su MMX, ovviamente) o packed (128, 256, 512 o 1024 bit. Con l'opzione del supporto ai registri vettoriali a dimensione variabile nel caso di soppressione del supporto alle MMX);
- può essere intera o floating point;
- può essere a 8, 16, 32 o 64 bit se è intera, o 16, 32, 64 o 128 bit se è floating point;
- maschere e istruzioni di gather/scatter funzionano su qualunque set di registri (MMX, SSE, AVX, AVX-512), anche se le estensioni SIMD originali non lo prevedevano.

Nell'architettura ci sono anche delle istruzioni non ortogonali, ma sono per lo più relative alle versioni "compressed"/corte/"quick". Come, peraltro, capita con altre architetture (perché le istruzioni compresse hanno opcode più piccoli, e quindi si devono fare necessariamente delle scelte, come ad esempio supportare soltanto un sottoinsieme dei registri disponibili).
__________________
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

Ultima modifica di cdimauro : 22-11-2020 alle 23:35.
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 23-11-2020, 17:07   #64
amd-novello
Senior Member
 
L'Avatar di amd-novello
 
Iscritto dal: Aug 2001
Città: Novara (NO)
Messaggi: 18553
Quote:
Originariamente inviato da cdimauro Guarda i messaggi

Augurare a Intel di meritarsi quel che sta passando equivale, per un consumatore, a darsi una martellata sui gioielli di famiglia.

"il prezzo lo fa il mercato"

ma lol il mercato dove intel domina sempre e dove sente il pepe al culo perchè c'è amd non è lo stesso
__________________
ASUS N76VZ +crucial m500 Dell Latitude E5430 +ssd iPad2017 iPod2007 Huaweip10lite con PosteMobile samsung55m5500 ps4,wiiu
exVODA 82/18-78/16-77/13-90/11 exWIND 95/14-95/19-85/19-81/22 fritzbox 7490
su Tiscali 863/288

Ultima modifica di amd-novello : 23-11-2020 alle 19:00. Motivo: Errore
amd-novello è offline   Rispondi citando il messaggio o parte di esso
Old 24-11-2020, 06:31   #65
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 25065
Quote:
Originariamente inviato da amd-novello Guarda i messaggi
"il prezzo lo fa il mercato"

ma lol il mercato dove intel domina sempre e dove sente il pepe al culo perchè c'è amd non è lo stesso
Hai editato? Bravo, perché la motivazione che hai dato: "Motivo: Errore" è del tutto falsa, visto che alla tua prima scrittura mi avevi subito accusato di essere partigiano.

Che poi fa semplicemente ridere, detto da uno che ha scelto come nick amd-novello...

E hai editato anche perché prima avevi quotato questo:
"Augurare a Intel di meritarsi quel che sta passando equivale, per un consumatore, a darsi una martellata sui gioielli di famiglia."

e poi aggiunto il commento attuale, che ovviamente non c'entra assolutamente nulla con la frase quotata.

Evidentemente alla prima scrittura del commento era prevalso il cieco fanatismo della tua marca del cuore.

Poi, passate due ore (ce n'è voluto, eh!), ti sei ripreso e hai corretto il tiro, eliminando lo strafalcione (un accostamento che non aveva il minimo senso), ma lasciando comunque la tua vena polemica, sulla quale non replico nemmeno perché non ne vale la pena.
__________________
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 24-11-2020, 11:17   #66
amd-novello
Senior Member
 
L'Avatar di amd-novello
 
Iscritto dal: Aug 2001
Città: Novara (NO)
Messaggi: 18553
Lol ma curati
__________________
ASUS N76VZ +crucial m500 Dell Latitude E5430 +ssd iPad2017 iPod2007 Huaweip10lite con PosteMobile samsung55m5500 ps4,wiiu
exVODA 82/18-78/16-77/13-90/11 exWIND 95/14-95/19-85/19-81/22 fritzbox 7490
su Tiscali 863/288
amd-novello è offline   Rispondi citando il messaggio o parte di esso
Old 25-11-2020, 07:13   #67
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 25065
Quote:
Originariamente inviato da amd-novello Guarda i messaggi
Lol ma curati
Detto da un fanatico AMD (nomen omen: bel nick che ti sei scelto!) che vive nella più completa confusione (vedi sopra, dove mi sono semplicemente limitato a riportare quello che hai fatto) e che si sia sentito in dovere di difendere la propria marca del cuore anche quando non ce ne fosse assolutamente bisogno sennò non poteva dormire la notte, lo prendo come un complimento.

Continua pure a fare sogni bagnati con Lisa Su...
__________________
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
 Rispondi


Samsung Galaxy S21, S21+ S21 Ultra: eccoli nella nostra video anteprima! Samsung Galaxy S21, S21+ S21 Ultra: eccoli nella...
ASUS ZenBook Duo UX482: due schermi e tanta autonomia ASUS ZenBook Duo UX482: due schermi e tanta auto...
Sony FE 35mm F1.4 GMaster, grande risoluzione e sfocato eccellente. La recensione Sony FE 35mm F1.4 GMaster, grande risoluzione e ...
Motorola moto g 5G: vincente per l’autonomia incredibile! La recensione Motorola moto g 5G: vincente per l’autonomia inc...
Elgato 4K60 Pro: come registrare gameplay di qualità su PS5 e Xbox Series X Elgato 4K60 Pro: come registrare gameplay di qua...
EK Water Blocks sta lavorando su un back...
Tesla: richiamo per 158 mila auto a caus...
T-Mobile punta su Ericsson per la sua re...
Windows 10, basta un semplice comando pe...
Covalent sceglie la blockchain di IBM pe...
Super Nintendo World senza pace, il COVI...
Windows 10, Microsoft corregge il bug su...
I monitor DisplayPort 2.0? In ritardo, e...
Vodafone è la rete migliore in It...
Opel Crossland con il volto unico presen...
ho.mobile: cosa succede se cambiate il c...
L'attesa è finita: Xiaomi Mi Watc...
Samsung SmartTag: ecco come funziona il ...
Fitbit fa ora parte di Google: completat...
Caos WhatsApp, si muove il Garante della...
K-Lite Codec Pack Update
K-Lite Mega Codec Pack
K-Lite Codec Pack Full
IObit Uninstaller
IObit Smart Defrag
Opera Portable
3DMark
Opera 73
Prime95
CCleaner Portable
CCleaner Standard
Advanced SystemCare
IrfanView
Sandboxie
CrystalDiskMark
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: 16:53.


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