|
|
|
![]() |
|
Strumenti |
![]() |
#41 | |
Senior Member
Iscritto dal: Dec 2002
Città: /dev/urandom breed
Messaggi: 1689
|
Quote:
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. |
|
![]() |
![]() |
![]() |
#42 | ||||
Senior Member
Iscritto dal: Dec 2002
Città: /dev/urandom breed
Messaggi: 1689
|
Quote:
Quote:
Quote:
Quote:
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. |
||||
![]() |
![]() |
![]() |
#43 |
Senior Member
Iscritto dal: Feb 2004
Messaggi: 2507
|
ma non mi risp nessuno?
|
![]() |
![]() |
![]() |
#44 | |
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
|
Quote:
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 |
|
![]() |
![]() |
![]() |
#45 |
Senior Member
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 |
![]() |
![]() |
![]() |
#46 |
Senior Member
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 |
![]() |
![]() |
![]() |
#47 |
Senior Member
Iscritto dal: Jun 2003
Città: Udine
Messaggi: 1612
|
sotto leggera pressione di bill credo!
|
![]() |
![]() |
![]() |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 12:10.