Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Lenovo ThinkVision 3D 27, la steroscopia senza occhialini
Lenovo ThinkVision 3D 27, la steroscopia senza occhialini
Primo contatto con il monitor Lenovo ThinkVision 3D 27 che grazie a particolari accorgimenti tecnici riesce a ricreare l'illusione della spazialità tridimensionale senza che sia necessario utilizzare occhialini
La Formula E può correre su un tracciato vero? Reportage da Misano con Jaguar TCS Racing
La Formula E può correre su un tracciato vero? Reportage da Misano con Jaguar TCS Racing
Abbiamo visto ancora una volta la Formula E da vicino, ospiti di Jaguar TCS Racing. In questa occasione però curve e rettilinei erano quelli di un circuito permanente, molto diverso dagli stretti passaggi delle strade di Roma
Lenovo LEGION e LOQ: due notebook diversi, stessa anima gaming
Lenovo LEGION e LOQ: due notebook diversi, stessa anima gaming
Lenovo ha puntato forte sul gaming negli ultimi anni e lo testimoniano i marchi LEGION e LOQ, il primo per gli amanti delle massime prestazioni e dell'assenza di compromessi, il secondo per chi desidera soluzioni dal buon rapporto tra prestazioni e prezzo. Abbiamo provato due esponenti dell'offerta, così da capire l'effettiva differenza prestazionale.
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 28-12-2007, 16:10   #1
Barbalbero
Registered User
 
Iscritto dal: Aug 2006
Messaggi: 305
JAVA più lento del C++. Ma quanto?

Sul web i pareri sono discordi e contrastanti, sebbene tutti ammettano che C++ sia più performante di java. Alcuni però sostengono che le prestazioni siano simili. Voi che ne dite?
Parlando ad esempio di software di visione artificiale, credete sia conveniente l'utilizzo di java (comodo per via delle libererie disponibili) o è meglio utilizzare il C++?
Barbalbero è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 16:13   #2
subvertigo
Senior Member
 
L'Avatar di subvertigo
 
Iscritto dal: Dec 2002
Città: Milano
Messaggi: 5060
La filosofia di Java è chi va piano va sano e va lontano.

Tutto in Java è fatto per essere il più lento e pesante possibile .

Se hai mezzi/conoscenze per usare il C++ vai sicuro su quello...
subvertigo è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 16:16   #3
Barbalbero
Registered User
 
Iscritto dal: Aug 2006
Messaggi: 305
La mia filosofia è che se i mezzi o le conoscenze mancano, si è sempre in tempo ad acquisirle
Barbalbero è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 16:38   #4
^TiGeRShArK^
Senior Member
 
L'Avatar di ^TiGeRShArK^
 
Iscritto dal: Jul 2002
Città: Reggio Calabria -> London
Messaggi: 12068
Quote:
Originariamente inviato da subvertigo Guarda i messaggi
La filosofia di Java è chi va piano va sano e va lontano.

Tutto in Java è fatto per essere il più lento e pesante possibile .

Se hai mezzi/conoscenze per usare il C++ vai sicuro su quello...

guarda che è già da un paio di anni che è stato introdotto il JIT.
Java ha prestazioni paragonabili al C++ oggi come oggi.
Già un paio di volte avevo postato dei bench con sciencemark e con non ricordo quale altro software in cui si vedeva che mediamente, in quell'ambito, le prestazioni di java erano circa il 95% di quelle del C++.
__________________
^TiGeRShArK^ è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 16:47   #5
subvertigo
Senior Member
 
L'Avatar di subvertigo
 
Iscritto dal: Dec 2002
Città: Milano
Messaggi: 5060
Quote:
Originariamente inviato da ^TiGeRShArK^ Guarda i messaggi

guarda che è già da un paio di anni che è stato introdotto il JIT.
Java ha prestazioni paragonabili al C++ oggi come oggi.
Già un paio di volte avevo postato dei bench con sciencemark e con non ricordo quale altro software in cui si vedeva che mediamente, in quell'ambito, le prestazioni di java erano circa il 95% di quelle del C++.
Ok sono banalotto al 100%.... ma dimmi... secondo te si riuscirebbe a fare in Java un Utorrent da 100 Kb di codice oggetto, velocissimo e con pochissima occupazione di risorse?

Già il fatto di usare una VM è di per sè più pesante...
subvertigo è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 16:55   #6
^TiGeRShArK^
Senior Member
 
L'Avatar di ^TiGeRShArK^
 
Iscritto dal: Jul 2002
Città: Reggio Calabria -> London
Messaggi: 12068
Quote:
Originariamente inviato da subvertigo Guarda i messaggi
Ok sono banalotto al 100%.... ma dimmi... secondo te si riuscirebbe a fare in Java un Utorrent da 100 Kb di codice oggetto, velocissimo e con pochissima occupazione di risorse?

Già il fatto di usare una VM è di per sè più pesante...

cioè tu misuri le performance in base al tempo di avvio di un'applicazione o in base alla memoria occupata dalla VM?
guarda..
io le performance, nel mio ambito, tendo a valutarle in base alla velocità di servizio a regime e, sinceramente, in un'epoca in cui 2 GB di ram costano 50 euro, che la VM in partenza mi occupi 20 MB sinceramente non mi pare uno scandalo.
L'importante è che le prestazioni siano paragonabili al C++ SENZA gli sbattimenti assurdi di quel linguaggio.
__________________
^TiGeRShArK^ è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 17:07   #7
mad_hhatter
Senior Member
 
L'Avatar di mad_hhatter
 
Iscritto dal: Oct 2006
Messaggi: 1105
Quote:
Originariamente inviato da subvertigo Guarda i messaggi
Ok sono banalotto al 100%.... ma dimmi... secondo te si riuscirebbe a fare in Java un Utorrent da 100 Kb di codice oggetto, velocissimo e con pochissima occupazione di risorse?

Già il fatto di usare una VM è di per sè più pesante...
ma parliamo di dimensione del codice oggetto o di velocita' dello stesso? mettiamoci d'accordo...

i benefici di java sono ben altri, non ti pare?
mad_hhatter è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 17:10   #8
stdecden
Member
 
L'Avatar di stdecden
 
Iscritto dal: Apr 2007
Messaggi: 263
Quote:
Originariamente inviato da ^TiGeRShArK^ Guarda i messaggi

cioè tu misuri le performance in base al tempo di avvio di un'applicazione o in base alla memoria occupata dalla VM?
guarda..
io le performance, nel mio ambito, tendo a valutarle in base alla velocità di servizio a regime e, sinceramente, in un'epoca in cui 2 GB di ram costano 50 euro, che la VM in partenza mi occupi 20 MB sinceramente non mi pare uno scandalo.
L'importante è che le prestazioni siano paragonabili al C++ SENZA gli sbattimenti assurdi di quel linguaggio.
É una cosa che non capiró mai...

I linguaggi diventano sempre piú lenti e pesanti, mentre i computer diventano sempre piú potenti...

Secondo me non ha senso creare linguaggi cosí pesanti e non sfruttare al massimo le capacitá della macchina.

P.S. Sto parlando in particolare dei linguaggi .NET, con java non ho tanta esperienza, ma credo sia la stessa cosa

Ultima modifica di stdecden : 28-12-2007 alle 17:15.
stdecden è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 17:34   #9
^TiGeRShArK^
Senior Member
 
L'Avatar di ^TiGeRShArK^
 
Iscritto dal: Jul 2002
Città: Reggio Calabria -> London
Messaggi: 12068

__________________
^TiGeRShArK^ è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 17:36   #10
^TiGeRShArK^
Senior Member
 
L'Avatar di ^TiGeRShArK^
 
Iscritto dal: Jul 2002
Città: Reggio Calabria -> London
Messaggi: 12068
Quote:
Originariamente inviato da stdecden Guarda i messaggi
É una cosa che non capiró mai...

I linguaggi diventano sempre piú lenti e pesanti, mentre i computer diventano sempre piú potenti...

Secondo me non ha senso creare linguaggi cosí pesanti e non sfruttare al massimo le capacitá della macchina.

P.S. Sto parlando in particolare dei linguaggi .NET, con java non ho tanta esperienza, ma credo sia la stessa cosa

veramente + un programma è ad alto livello + è facile concentrarsi sul problema, magari avendo a disposizione + tempo per trovare algoritmi migliori per risolverlo.
Se invece ci si dovesse concentrare a tracciare un maledetto segmentation fault o qualche memory leak apparentemente impossibile si otterrebbero programmi di qualità + scadente (o per le features che non sono state implementate per carenza di tempo o per i bug ancora presenti)
__________________
^TiGeRShArK^ è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 18:12   #11
sottovento
Senior Member
 
L'Avatar di sottovento
 
Iscritto dal: Nov 2005
Città: Texas
Messaggi: 1722
Ciao,
volevo aggiungere il mio parere: la vita non e' riconducibile ad un benchmark
Il tuo programma sara' piuttosto lungo, con una parte piuttosto critica e (molte) altre parti meno critiche, ma comunque necessitanti di un certo grado di prestazioni.

Probabilmente in queste parti (circa l'80% del codice) troverai la conferma di quello che sto per dirti (sperando di non far partire un flame gigantesco): Java avra' prestazioni addirittura superiori al C/C++!
Ho avuto la possibilita' di vedere la stessa applicazione codificata nei due linguaggi e verificare, (non senza incredulita') questa affermazione.

Com'e' possibile? Semplice: nei benchmark pui codificare lo stesso algoritmo di test in entrambi i linguaggi, con una codifica che e' pressoche simile. In questo caso, spesso (non sempre e non cosi' frequentemente come si crede), C++ ha prestazioni superiori (i.e. e' piu' veloce, stiamo parlando di questo, no?).

Nella programmazione di una applicazione "vera", spesso lo stesso algoritmo deve essere codificato nei due linguaggi in due maniere diverse.
Il risultato e' che spesso, per evitare crash/leaks/... in C++ e' necessario ricorrere alle COPIE di oggetti, mentre in Java queste copie semplicemente non sono necessarie. La copia costa, in termini di memoria e di velocita' di esecuzione, e costa piu' della compilazione JIT (che avviene peraltro una sola volta).
Addirittura (esperienza personale) i programmatori non si accorgono nemmeno di aver fatto una copia poiche' essa e' implicita nel passaggio di argomenti, ritorno di funzioni, ....

Questo fa decadere le prestazioni drammaticamente.
Queste copie sono evitabili? Non sempre, e non sempre in modo "pulito".
Java non ha questi problemi. Ovviamente dovra' deallocare la memoria non piu' in uso, ma puo' usare trucchi basati su "economia di scala", per esempio, deallocando blocchi di oggetti contigui od usando un qualsiasi altro algoritmo.
E' questo un notevole vantaggio di cui C++ non puo' godere.

Esistono poi parecchi altri problemi relativi alle prestazioni, in un programma reale. Java li affronta mediamente meglio, e fa sicuramente meglio di un programmatore medio C++.

Il mio suggerimento e': scrivi tutto in Java. Ci saranno poi delle parti (saranno meno del 10%) che potranno essere ottimizzate cambiando linguaggio.
Potrai riscrivere queste parti in C++ (meglio in C) e chiamarle direttamente dall'ambiente Java, cercando cosi' di ottimizzare i benefici.
__________________
In God we trust; all others bring data
sottovento è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 19:45   #12
morskott
Member
 
Iscritto dal: Jul 2005
Messaggi: 280
Quote:
Originariamente inviato da sottovento Guarda i messaggi
Ciao,
volevo aggiungere il mio parere: la vita non e' riconducibile ad un benchmark
Il tuo programma sara' piuttosto lungo, con una parte piuttosto critica e (molte) altre parti meno critiche, ma comunque necessitanti di un certo grado di prestazioni.

Probabilmente in queste parti (circa l'80% del codice) troverai la conferma di quello che sto per dirti (sperando di non far partire un flame gigantesco): Java avra' prestazioni addirittura superiori al C/C++!
Ho avuto la possibilita' di vedere la stessa applicazione codificata nei due linguaggi e verificare, (non senza incredulita') questa affermazione.

Com'e' possibile? Semplice: nei benchmark pui codificare lo stesso algoritmo di test in entrambi i linguaggi, con una codifica che e' pressoche simile. In questo caso, spesso (non sempre e non cosi' frequentemente come si crede), C++ ha prestazioni superiori (i.e. e' piu' veloce, stiamo parlando di questo, no?).

Nella programmazione di una applicazione "vera", spesso lo stesso algoritmo deve essere codificato nei due linguaggi in due maniere diverse.
Il risultato e' che spesso, per evitare crash/leaks/... in C++ e' necessario ricorrere alle COPIE di oggetti, mentre in Java queste copie semplicemente non sono necessarie. La copia costa, in termini di memoria e di velocita' di esecuzione, e costa piu' della compilazione JIT (che avviene peraltro una sola volta).
Addirittura (esperienza personale) i programmatori non si accorgono nemmeno di aver fatto una copia poiche' essa e' implicita nel passaggio di argomenti, ritorno di funzioni, ....

Questo fa decadere le prestazioni drammaticamente.
Queste copie sono evitabili? Non sempre, e non sempre in modo "pulito".
Java non ha questi problemi. Ovviamente dovra' deallocare la memoria non piu' in uso, ma puo' usare trucchi basati su "economia di scala", per esempio, deallocando blocchi di oggetti contigui od usando un qualsiasi altro algoritmo.
E' questo un notevole vantaggio di cui C++ non puo' godere.

Esistono poi parecchi altri problemi relativi alle prestazioni, in un programma reale. Java li affronta mediamente meglio, e fa sicuramente meglio di un programmatore medio C++.

Il mio suggerimento e': scrivi tutto in Java. Ci saranno poi delle parti (saranno meno del 10%) che potranno essere ottimizzate cambiando linguaggio.
Potrai riscrivere queste parti in C++ (meglio in C) e chiamarle direttamente dall'ambiente Java, cercando cosi' di ottimizzare i benefici.
Dipende pure dall'ambito di utilizzo, un controllore di un nocciolo di una centrale nucleare col cavolo che lo programmerei in Java, ma diciamo che nelle altre situazioni (leggermente piu normali) il così tanto overhead di java in pratica non ce se ne accorge nemmeno, sempre che esista (come sottovento ha sottolineato).
Per utilizzi un po a metà tra il normale e lo strict real time farei la parte critica in C/C++ e lo chiamerei da java tramite JNI (spero di aver azzeccato la sigla).
morskott è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 20:23   #13
71104
Bannato
 
L'Avatar di 71104
 
Iscritto dal: Feb 2005
Città: Roma
Messaggi: 7026
Quote:
Originariamente inviato da subvertigo Guarda i messaggi
La filosofia di Java è chi va piano va sano e va lontano.

Tutto in Java è fatto per essere il più lento e pesante possibile .

Se hai mezzi/conoscenze per usare il C++ vai sicuro su quello...
guarda, tante volte non lo sapessi Jake è più veloce di Quake
71104 è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 20:26   #14
71104
Bannato
 
L'Avatar di 71104
 
Iscritto dal: Feb 2005
Città: Roma
Messaggi: 7026
Quote:
Originariamente inviato da subvertigo Guarda i messaggi
Già il fatto di usare una VM è di per sè più pesante...
Quote:
Originariamente inviato da ^TiGeRShArK^ Guarda i messaggi

cioè tu misuri le performance in base al tempo di avvio di un'applicazione o in base alla memoria occupata dalla VM?
infatti non ha senso; la memoria occupata dal materiale specifico della virtual machine è in gran parte condivisa da tutti i processi che vi si appoggiano, quindi all'aumentare del numero di processi Java che girano contemporaneamente l'overhead rappresentato dalla JVM tende a scomparire. ma questa è solo la motivazione più stupida per la quale l'overhead della JVM non può assolutamente controbilanciare negativamente gli enormi benefici del programmare in una piattaforma managed piuttosto che in C++.
71104 è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 20:29   #15
71104
Bannato
 
L'Avatar di 71104
 
Iscritto dal: Feb 2005
Città: Roma
Messaggi: 7026
Quote:
Originariamente inviato da mad_hhatter Guarda i messaggi
ma parliamo di dimensione del codice oggetto o di velocita' dello stesso? mettiamoci d'accordo...

i benefici di java sono ben altri, non ti pare?
anche perché come dimensioni del... "codice oggetto" vince sicuramente Java; in genere gli eseguibili nativi sono molto più grossi dei .class o dei .jar (questi ultimi poi sono pure compressi).
71104 è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 20:30   #16
^TiGeRShArK^
Senior Member
 
L'Avatar di ^TiGeRShArK^
 
Iscritto dal: Jul 2002
Città: Reggio Calabria -> London
Messaggi: 12068
Quote:
Originariamente inviato da morskott Guarda i messaggi
Dipende pure dall'ambito di utilizzo, un controllore di un nocciolo di una centrale nucleare col cavolo che lo programmerei in Java, ma diciamo che nelle altre situazioni (leggermente piu normali) il così tanto overhead di java in pratica non ce se ne accorge nemmeno, sempre che esista (come sottovento ha sottolineato).
Per utilizzi un po a metà tra il normale e lo strict real time farei la parte critica in C/C++ e lo chiamerei da java tramite JNI (spero di aver azzeccato la sigla).
solo se serve..
l'ottimizzazione del codice se effettuata senza alcun dato preciso di profiling, e, in caso non sia strettamente necessaria, porta sempre ad un peggioramento del codice rendendolo meno leggibile e + soggetto ai bug.
Io di solito scrivo in Java (o python o ruby o C# o quello che capita) e finora non ho mai avuto necessita di ottimizzare i miei programmi dato che la velocità di esecuzione è generalmente ottimale.
In caso fosse strettamente necessaria, la prima fase di ottimizzazione da fare SEMPRE, è quella di utilizzare un algoritmo + performante.
Con un semplice cambio di algoritmo si possono averee vantaggi MOLTO + drastici rispetto all'uso dello stesso algoritmo con JNI.
In caso ancora non fosse sufficiente cercherei di ottimizzare il tutto nello stesso linguaggio utilizzato, e, solo come soluzione estrema, ottimizzerei l'1% critico di codice con un linguaggio compilato staticamente.
__________________
^TiGeRShArK^ è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 20:31   #17
71104
Bannato
 
L'Avatar di 71104
 
Iscritto dal: Feb 2005
Città: Roma
Messaggi: 7026
Quote:
Originariamente inviato da stdecden Guarda i messaggi
I linguaggi diventano sempre piú lenti e pesanti,
ma dove...

Quote:
Secondo me non ha senso creare linguaggi cosí pesanti e non sfruttare al massimo le capacitá della macchina.
e allora esci dal luogo comune, quello è ovvio che non ha senso.
71104 è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 20:37   #18
71104
Bannato
 
L'Avatar di 71104
 
Iscritto dal: Feb 2005
Città: Roma
Messaggi: 7026
Quote:
Originariamente inviato da morskott Guarda i messaggi
Dipende pure dall'ambito di utilizzo, un controllore di un nocciolo di una centrale nucleare col cavolo che lo programmerei in Java, ma diciamo che nelle altre situazioni (leggermente piu normali) il così tanto overhead di java in pratica non ce se ne accorge nemmeno, sempre che esista (come sottovento ha sottolineato).
Per utilizzi un po a metà tra il normale e lo strict real time farei la parte critica in C/C++ e lo chiamerei da java tramite JNI (spero di aver azzeccato la sigla).
praticamente stai dicendo che il codice critico (cioè diciamo quello che deve funzionare a tutti i costi) tu non lo affideresti mai ad una virtual machine, ma preferisci scrivertelo da solo. teoricamente hai ragione dal momento che la Sun non si assume responsabilità per danni che la tecnologia Java può provocare alle persone, all'ambiente, ecc. ecc. ma nella pratica lasciati dire che nello scrivere il tuo codice critico sbaglierai con probabilità molto maggiore di quanto potrebbe mai sbagliare la JVM, semplicemente perché la JVM è un prodotto software molto maturo.
71104 è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 20:46   #19
71104
Bannato
 
L'Avatar di 71104
 
Iscritto dal: Feb 2005
Città: Roma
Messaggi: 7026
Quote:
Originariamente inviato da ^TiGeRShArK^ Guarda i messaggi
solo come soluzione estrema, ottimizzerei l'1% critico di codice con un linguaggio compilato staticamente.
io veramente a quel punto proporrei l'acquisizione di hardware migliore... seriamente, per un 1% ti stai ad ammazzare rendendo i tuoi sorgenti incomprensibili e per nulla manutenibili, aumentando a dismisura i costi futuri di riutilizzo di quel codice?
e secondo te un 1% di performance in più non lo puoi guadagnare migliorando l'hardware? perché cavolo deve essere il programmatore a farsi un didietro così a scrivere software? tantopiù che siamo a Natale
71104 è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2007, 21:06   #20
^TiGeRShArK^
Senior Member
 
L'Avatar di ^TiGeRShArK^
 
Iscritto dal: Jul 2002
Città: Reggio Calabria -> London
Messaggi: 12068
Quote:
Originariamente inviato da 71104 Guarda i messaggi
io veramente a quel punto proporrei l'acquisizione di hardware migliore... seriamente, per un 1% ti stai ad ammazzare rendendo i tuoi sorgenti incomprensibili e per nulla manutenibili, aumentando a dismisura i costi futuri di riutilizzo di quel codice?
e secondo te un 1% di performance in più non lo puoi guadagnare migliorando l'hardware? perché cavolo deve essere il programmatore a farsi un didietro così a scrivere software? tantopiù che siamo a Natale
infatti l'ho citata appositamente come ultimissima scelta giusto per evitare l'impalamento e la crocifissione in sala mensa
__________________
^TiGeRShArK^ è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Lenovo ThinkVision 3D 27, la steroscopia senza occhialini Lenovo ThinkVision 3D 27, la steroscopia senza o...
La Formula E può correre su un tracciato vero? Reportage da Misano con Jaguar TCS Racing La Formula E può correre su un tracciato ...
Lenovo LEGION e LOQ: due notebook diversi, stessa anima gaming Lenovo LEGION e LOQ: due notebook diversi, stess...
Nothing Ear e Ear (a): gli auricolari per tutti i gusti! La ''doppia'' recensione Nothing Ear e Ear (a): gli auricolari per tutti ...
Sony FE 16-25mm F2.8 G: meno zoom, più luce Sony FE 16-25mm F2.8 G: meno zoom, più lu...
ASML, intesa con il governo olandese: pi...
Portatile Low cost potentissimo: AMD Ryz...
I nuovi coupon nascosti di Amazon: ecco ...
Torna il super tablet da 109€ con displa...
Continuano le super offerte su Google Pi...
Meta copia Microsoft con Windows: il sis...
Blackmagic Design: arriva il nuovo softw...
La sonda spaziale NASA Voyager 1 ricomin...
Blackmagic PYXIS 6K per riprendere filma...
Sapphire Nitro+ B650I Wi-Fi: un’ottima s...
E4 Computer Engineering potenzierà...
Blackmagic URSA Cine 12K: la videocamera...
Ecco i TV TCL in esclusiva per Amazon: p...
Amazfit porta l'Intelligenza Artificiale...
La NASA potrebbe modificare i piani per ...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
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: 08:06.


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