Torna indietro   Hardware Upgrade Forum > Hardware Upgrade > News

Intervista a Stop Killing Games: distruggere videogiochi è come bruciare la musica di Mozart
Intervista a Stop Killing Games: distruggere videogiochi è come bruciare la musica di Mozart
Mentre Ubisoft vorrebbe chiedere agli utenti, all'occorrenza, di distruggere perfino le copie fisiche dei propri giochi, il movimento Stop Killing Games si sta battendo per preservare quella che l'Unione Europea ha già riconosciuto come una forma d'arte. Abbiamo avuto modo di parlare con Daniel Ondruska, portavoce dell'Iniziativa Europa volta a preservare la conservazione dei videogiochi
Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione
Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione
Abbiamo provato il nuovo Galaxy S25 Edge, uno smartphone unico per il suo spessore di soli 5,8 mm e un peso super piuma. Parliamo di un device che ha pro e contro, ma sicuramente si differenzia dalla massa per la sua portabilità, ma non senza qualche compromesso. Ecco la nostra prova completa.
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto
Pensato per il professionista sempre in movimento, HP Elitebook Ultra G1i 14 abbina una piattaforma Intel Core Ultra 7 ad una costruzione robusta, riuscendo a mantenere un peso contenuto e una facile trasportabilità. Ottime prestazioni per gli ambiti di produttività personale con un'autonomia lontano dalla presa di corrente che permette di lavorare per tutta la giornata
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 23-05-2004, 15:15   #41
Ikitt_Claw
Senior Member
 
Iscritto dal: Dec 2002
Città: /dev/urandom breed
Messaggi: 1689
Quote:
Originariamente inviato da cdimauro
Cosa?
So troppo poco degli internals di linux (e del processo di scrittura di driver in generale) per portare un'obiezione precisa.
Della situazione in windows non so nulla, per cui per ora non posso che darti ragione, fermo restando appunto che alcune cose non mi convincono.
Ikitt_Claw è offline   Rispondi citando il messaggio o parte di esso
Old 23-05-2004, 15:20   #42
Ikitt_Claw
Senior Member
 
Iscritto dal: Dec 2002
Città: /dev/urandom breed
Messaggi: 1689
Quote:
Originariamente inviato da ^TiGeRShArK^
se hai bisogno di driver performanti devi NECESSARIAMENTE scrivere le parti critiche in linguaggio makkina....
Uhm... Esempio di parte critica?

Quote:
e poi non te ne sei accorto usando linux???
Anche i device driver, in generale, sotto linux sono in C anziche` in ASM (e vorrei ben vedere...) eppure non mi pare affatto che le prestazioni ne risentano.

Quote:
mi vuoi dire ke i driver video in linux sono scritti interamente in c e hanno le stesse prestazioni dei driver ottimizzati in linguaggio makkina???
Premesso che un driver video, specie con la complessita` delle schede video attuali, sara comunque scritto per la maggior parte in un linguaggio a piu` alto livello dell'assembly, sarebbe salutare un confronto, ma non conosco schede con driver che possano essere adatte allo scopo.

Quote:
X me è QUI ke c'è qualcosa ke non mi convince nel tuo ragionamento...
Ci vorrebbe qualche numero per dirimere un bel po` di dubbi.
Queste famose "ottimizzazioni" dei driver sono fumose e vaghe come concetti (o mi son perso qualcosa io?)
Nella scena linux, e la cito perche` il sorgente e` a portata di mano, mica per altro, mi pare proprio che un'ottimizzazione del driver raramente si conretizzi nell'uso dell'ASM, men che mai in una riscrittura.
Ikitt_Claw è offline   Rispondi citando il messaggio o parte di esso
Old 23-05-2004, 15:40   #43
Immortal
Senior Member
 
L'Avatar di Immortal
 
Iscritto dal: Feb 2004
Messaggi: 2507
ma non mi risp nessuno?
Immortal è offline   Rispondi citando il messaggio o parte di esso
Old 24-05-2004, 06:23   #44
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
Quote:
Originariamente inviato da Ikitt_Claw
So troppo poco degli internals di linux (e del processo di scrittura di driver in generale) per portare un'obiezione precisa.
Della situazione in windows non so nulla, per cui per ora non posso che darti ragione, fermo restando appunto che alcune cose non mi convincono.
Per quanto riguarda i driver possiamo parlare in generale, perché è una questione che riguarda un qualunque s.o.
E' pacifico che un'applicazione che richiede un particolare servizio, finisca per richiamare un driver per il suo espletamento. Succede con le API grafiche ma, per prendere un esempio completamente diverso, può succedere per implementare via software il RAID 0 (banale "fusione" di due hd per simularne uno più grande) o RAID 0+1 (non ricordo di preciso la sigla), che esegue la stessa operazione, ma con 3 HD, di cui uno contiene lo XOR degli altri due (quindi c'è più lavoro da fare).
Ora, è chiaro che se un driver si occupa di qualcosa per cui riceve un enorme carico di lavoro, più velocemente lo porta a compimento, meglio si comporta globalmente il sistema. Quindi si ha interesse a fargli perdere quanto meno tempo possibile.
A questo punto la differenza la fa il linguaggio: in C, per quanto buono possa essere il back-end del compilatore, il codice risulterà più lento di uno scritto in assembly da una persona competente. Codice più lento -> prestazioni inferiori.

Se il problema che hai sollevato sta nella percezione delle differenze, è chiaro che bisogna effettuare dei test: magari qualche decina di frame al secondo in più o in meno con un gioco come Quake non si possono apprezzare, dato l'elevato numero di essi che viene generato normalmente. Potrebbe essere maggiormente apprezzabile nel caso di giochi di nuova generazione, che utilizzano DirectX 8 o superiori (oppure ABR OpenGL equivalenti), per cui richiamare una funzionalità, per il driver equivale a programmare opportunamente i registri della GPU e/o trasferire informazioni tramite il bus AGP. O ancora, nel caso del RAID (0 oppure 0+1), sarà il maggior o il minor tempo impiegato nel caso del trasferimento di file ad essere "percepibile".
E' chiaro che, poi, le prestazioni possono essere comunque elevate, anche usando esclusivamente il C, per cui si può accontentare.

Quanto ai driver, è vero che in generale la maggior parte di essi sono scritti in C: non avrebbe senso utilizzare l'assembly per ogni loro parte. Soltanto le parti critiche, che svolgono un lavoro che incide particolarmente nelle prestazioni, sono passibili di eventuale scrittura in assembly.

Infine, le ottimizzazione non sono "fumose": il problema del miglioramento delle prestazioni del codice non riguarda esclusivamente il settore dei driver, ma qualunque software. Se ancora oggi un engine grafico utilizza l'assembly per le cosidette parti critiche, un motivo ci sarà.
Allo stesso modo, è possibile ottimizzare le parti di un driver che si ritiene possano apportare benefici.
Stiamo parlando si software: la differenza fra i due ambiti non comporta una distinzione delle cose.

x Immortal: esistono delle apposite sezioni in questo forum.
__________________
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 o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 24-05-2004, 09:49   #45
ErPazzo74
Senior Member
 
L'Avatar di ErPazzo74
 
Iscritto dal: Sep 2001
Messaggi: 1521
Il problema dei driver ottimizzati o no, sinceramente mi fa' 1 po' ridere. Cioe' se voi commercializzate una periferica sarebbe (secondo me) meglio prima uscire con dei driver in C, poi magari ottimizzarli man mano.
Per esempio i driver delle videocamere DragonFly erano lentissimi negli algoritmi x la ricostruzione delle immagini (occupazione di CPU al 100% con l'algo + pesante) alla versione successiva si passo' al 25% della CPU. Beh all'inizio era poco serio che una telecamerica da 2500 euro avesse dei driver lenti ma poco dopo (qualche mese) erano ben ottimizzati.
Aggiungo che io preferisco driver stabili a driver veloci ma con dei bug importanti.
Non metto in dubbio ovviamente che ottimizzare in assembly (come mi e' capitato di fare) direttamente sia + efficiente del codice in C anche se ben compilato. Ma mi ripeto non credo che ci sia questa estrema ricercatezza delle prestazione nei driver attuali delle periferiche.
Lo scetticismo e' dovuto al fatto visto quanto sono potenti i nostri computer sembrano pur sempre dei pachidermi rispetto ai tempi del C64.
Ciao Ciao
__________________
Ciao a Tutti dal Pazzo!!!
Asus M4A79XTD EVO + X3 720 + ati 9200 + 4Gb OCZ 1800Mhz + WD BLACK 750Gb
ErPazzo74 è offline   Rispondi citando il messaggio o parte di esso
Old 24-05-2004, 21:22   #46
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
Beh, mi sembra normale che quando si sviluppa un driver (o qualunque altro programma), prima si utilizzi un linguaggio ad alto livello, e poi eventualmente se ne riscrivono le parti critiche in assembly.
Quest'ultimo è un percorso che, come ho già scritto, viene intrapreso se se ne evidenzia la necessità. E questo a prescindere dalla potenza disponibile per i nostri computer, perché:
1) la "massa" non ha disponibile il miglior hardware
2) l'aggiornamento è un'operazione che non viene eseguita spesso, anzi!
3) la potenza aumenta, ma iù vengono presentate applicazioni sempre più complesse e pesanti.

D'altra parte, ripeto, non è che si debba ottimizzare TUTTO il codice: solo per una piccola parte dev'essere fatto...
__________________
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 o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 25-05-2004, 21:14   #47
dragunov
Senior Member
 
L'Avatar di dragunov
 
Iscritto dal: Jun 2003
Città: Udine
Messaggi: 1612
sotto leggera pressione di bill credo!
dragunov è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Intervista a Stop Killing Games: distruggere videogiochi è come bruciare la musica di Mozart Intervista a Stop Killing Games: distruggere vid...
Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione Samsung Galaxy S25 Edge: il top di gamma ultraso...
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto HP Elitebook Ultra G1i 14 è il notebook c...
Microsoft Surface Pro 12 è il 2 in 1 più compatto e silenzioso Microsoft Surface Pro 12 è il 2 in 1 pi&u...
Recensione REDMAGIC Astra Gaming Tablet: che spettacolo di tablet! Recensione REDMAGIC Astra Gaming Tablet: che spe...
Le 18 offerte Amazon del weekend, senza ...
Galaxy S25 Ultra 512GB sotto i 1.000€ su...
Vi piace l'iPhone nero? Su Amazon sono s...
MacBook Air M4 16GB/256GB e 16GB/512GB s...
4 portatili per risparmiare tanto ed ess...
San Marino multa TikTok: non controllano...
Dreame e Roborock in saldo su Amazon: ro...
Pazzesco su Amazon: crollano i prezzi de...
La Corea del Sud vorrebbe costruire una ...
Rilasciati i primi risultati delle anali...
Robot umanoidi low cost? Unitree ci prov...
Non solo Rocket Lab, anche Avio potrebbe...
Chips Act UE: 41,5 milioni di euro a Eph...
Ryzen Threadripper 9000 al debutto il 31...
Nuovi coupon nascosti Amazon (aggiorname...
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: 12:10.


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