Confronto GL 3D (Quake3)

[Amiga Supremo]

Sarebbero interessanti anche i test con il Pegasos 1 G3 e con il Pegasos2 G3 e con Efika.

Coming soon.

Sys_Error: Hunk data failed to allocate 64 Megs

[divina]

consigli recevuti per Efika e Quake 3.

prova alcuni di questi :
- wihtout startup-sequence (bootmenu)
- remove all sbar plugin
- force 640x480 ambient screen (bootmenu)
- tweak the q3config
- reduce the initial shell window size to minimum
- didable Enhanced Display for Ambient screen

prova anche la prima versione di Quake3 (non la R2)
http://bigfoot.morphos-team.net/files/morphosquake3.lha

[Amiga Supremo]

Grazie!
Mi manca da provare soltanto l'eseguibile della precedende release; per ora sempre "out of memory".
Leggendo i due thread su MorphZone, comunque mi pare di capire che nessuno ci sia riuscito o che per lo meno nessuno abbia fornito i parametri precisi per riuscire a farlo.
Visto che così non si può che andar per tentativi, credo che poi l'esito del benchmark non potrà essere molto veritiero, in senso assoluto (troppe variabili e troppi range per queste ultime).
Al limite si potrà avere la soddisfazione di dire, "io l'ho lanciato in esecuzione".

[divina]

Al limite si potrà avere la soddisfazione di dire, "io l'ho lanciato in esecuzione".

Sì prova con la R1 di Q3, secondo me qualche elemento positivo lo ottieni comunque

[Seiya]

perchè solo Quake Arena e non anche quake 1 e 2?

Cmq è strano che Quake3 non vada su Efika
Funziona anche un P2@350 con 128 MB e XP SP3 con una vga da 32MB anche in 1280x1024 e oltre se il monitor la supportasse.
Forse il porting di Quake3 per AmigaOS richiede 64MB pieni e non ce ne sono abbastanza disponibili.

[divina]

perchè solo Quake Arena e non anche quake 1 e 2?

Cmq è strano che Quake3 non vada su Efika
Funziona anche un P2@350 con 128 MB e XP SP3 con una vga da 32MB anche in 1280x1024 e oltre se il monitor la supportasse.
Forse il porting di Quake3 per AmigaOS richiede 64MB pieni e non ce ne sono abbastanza disponibili.

Seiya ... ... ... mi sembra ovvio che testare Quake 3 permetta di valutare meglio le prestazioni degli OS e dell' hardware Amiga rispetto a Q2 e Q1 ...

L' Efika, è l' hardware Amiga NG meno performante (CPU) tuttavia il collo di bottiglia è certamente la presenza onboard di soli 128Mb; penso sia stato molto utile per il team di MorphOS avere un hardware come l' Efika per riuscire ad ottimizzare ulteriormente il bellissimo MorphOS 2.x.
Come avrai notato i suggerimenti forniti da MorphZone sono mirati ad avere più ram volatile possibile dopo il bootstrap del OS ...

Piuttosto sarebbe interessante che altri utenti partecipassero al test (in particolare mancano gli AmigaOne normale e micro G3, i Pegasos I e II G3, e svariati Mac G4 ... etc ...)

[Seiya]

.

il bellissimo MorphOS 2.x.

sappiamo che sbavi per morphOS

ma non hai riposto correttamente.
ho detto che quake arena gira su un hardware inferiore all'efika su un OS che è un mattone rispetto a MorphOS e OS4
Assurdo che 128 MB di ram non siano sufficienti a farlo manco partire, oppure questo OS tra menate e servizi vari è diventato più mattone di Windows

[divina]

@Seiya

difficile che io sbavi per un computer o per un Sistema Operativo diciamo che mi piace usare MorphOS, lo trovo decisamente funzionale, proficuo

Con MorphOS non è utilizzabile la memoria virtuale, pertanto essendo decisamente limitata la memoria nel Efika (128Mb), ne hai poca per determinati applicativi, games ... MorphOS non è per nulla un mattone, anzi è leggero come una farfalla

[AmigaCori]

Assurdo che 128 MB di ram non siano sufficienti a farlo manco partire, oppure questo OS tra menate e servizi vari è diventato più mattone di Windows

Beh, dai lo sai che non e' cosi' , e' che ai sistemi Amigosi mancano alcuni tasselli che IMHO sono indispensabili ed altri raffinamenti (driver migliori), quindi anche se sono veloci nell'aprire le finestre, alla fine richiedono piu' risorse HW di Windows per funzionare.

[Seiya]

quindi anche se sono veloci nell'aprire le finestre, alla fine richiedono piu' risorse HW di Windows per funzionare.

si si, sono velocissimi, però in pratica hai detto che questi OS NG sono più pesantucci rispetto a Windows

[TheKaneB]

mmh... beh, facciamo le dovute distinzioni tra OS "pesante" e OS "poco efficiente".

Di sicuro Windows è pesante, nel senso che ha decine di servizi sempre attivi che non sono indispensabili (o perlomeno, lo sono solo in pochi casi), ha una GUI poco reattiva a causa di mille effettini (disabilitabili, volendo) e richiede molta ram anche se non sta facendo praticamente nulla. Ma è un sistema operativo efficiente, nel senso che gestisce le risorse in modo molto sofisticato, ha la memoria virtuale, lo scheduler per l'I/O molto avanzato, vari livelli di caching sul filesystem, filesystem journalized a prova di crash, ecc...

Allo stato attuale gli OS amiga NG sono molto leggeri, consumano poca ram, sono reattivi ecc... Ma gestiscono male le risorse, non hanno memoria virtuale, driver scadenti che non spremono bene tutto l'hardware, uno scheduler per i processi non troppo avanzato, e quello per l'I/O assente. E poi ci sono tante altre cose che sono sicuramente migliorabili... ad esempio manca un sistema evoluto per la gestione dei privilegi e dei domini virtuali, che rendono il sistema potenzialmente vittima non solo di attacchi malevoli, ma anche (e soprattutto) di banali errori nei software che possono far crashare tutto il sistema in modo plateale.

[MacGyverPPC]

mmh... beh, facciamo le dovute distinzioni tra OS "pesante" e OS "poco efficiente".

Di sicuro Windows è pesante, nel senso che ha decine di servizi sempre attivi che non sono indispensabili (o perlomeno, lo sono solo in pochi casi), ha una GUI poco reattiva a causa di mille effettini (disabilitabili, volendo) e richiede molta ram anche se non sta facendo praticamente nulla. Ma è un sistema operativo efficiente, nel senso che gestisce le risorse in modo molto sofisticato, ha la memoria virtuale, lo scheduler per l'I/O molto avanzato, vari livelli di caching sul filesystem, filesystem journalized a prova di crash, ecc...

Allo stato attuale gli OS amiga NG sono molto leggeri, consumano poca ram, sono reattivi ecc... Ma gestiscono male le risorse, non hanno memoria virtuale, driver scadenti che non spremono bene tutto l'hardware, uno scheduler per i processi non troppo avanzato, e quello per l'I/O assente. E poi ci sono tante altre cose che sono sicuramente migliorabili... ad esempio manca un sistema evoluto per la gestione dei privilegi e dei domini virtuali, che rendono il sistema potenzialmente vittima non solo di attacchi malevoli, ma anche (e soprattutto) di banali errori nei software che possono far crashare tutto il sistema in modo plateale.

OS4 ha la memoria virtuale

[TheKaneB]

da quello che ho letto ha una memoria virtuale "disattivabile" e configurabile manualmente dalle singole applicazioni. Non è una memoria virtuale vera e propria, ma solo un abbozzo. A quanto pare anche la protezione della memoria è assente.

Queste caratteristiche non fanno di OS4 un sistema operativo a memoria virtuale propriamente detto, diciamo che gli si avvicina un po'.

[andres]

Secondo te, sarà un lavoro davvero complicato aggiungere supporto multicore e memoria protetta che, presumibilmente, dovrebbero arrivare con la versione 4.2?

[TheKaneB]

beh, per dare una risposta esauriente devo entrare un po' nel tecnico...

Memoria protetta: facile da implementare, ma rompe la compatibilità con molti vecchi programmi... quindi bisogna andarci con i piedi di piombo.

Supporto Multiprocessore:
ACHTUNG: post chilometrico e soporifero in arrivo! leggere con cautela, in caso di convulsioni consultare il medico...

Un kernel con supporto SMP (Symmetric Multi Processor), richiede una parziale riscrittura di alcuni moduli (tipicamente filesystem, task manager, scheduler e memory manager sono i più delicati) per renderli "compatibili" con un'architettura a processori multipli.

Il problema fondamentale è quello delle "race conditions" o corse critiche in italiano. E' un problema che si verifica quando due thread tentano di modificare la stessa area di memoria, o accedere alla stessa risorsa, contemporaneamente. Il modo corretto di gestire le race conditions consiste nel piazzare delle istruzioni di blocco (o lock esclusivo, o mutex) prima di accedere a queste risorse, e di rilasciare il blocco subito dopo.

Capite bene che questo è un lavoro "di fino", che bisogna fare con tanta pazienza e attenzione, per ogni singolo accesso a risorse (o aree di memoria del kernel) condivise, e ciò porta via tanto tempo.

Per dirla tutta esiste anche un altro metodo per rendere SMP un kernel senza troppe modifiche (e quindi fattibile nell'arco di pochi mesi). Si chiama Giant Lock, o Big Kernel Lock.
Detto in parole povere, invece di proteggere con un mutex ogni singola risorsa sensibile o area di memoria condivisa, si taglia carne e ossa e si piazza un unico singolo mutex che vale per tutto il kernel, su tutti i processori contemporaneamente.
Questo significa che, ad esempio, se ho 4 processori e un thread del processore #1 richiede una syscall, all'ingresso del kernel mode la CPU#1 attiverà il Giant Lock e inizierà a fare il suo lavoro in kernel mode. Le altre 3 CPU continuano a lavorare finchè una di queste, diciamo la CPU#2, non deve entrare anch'essa in kernel mode, ma stavolta troverà che il Giant Lock è già bloccato dalla CPU#1, quindi viene messo per così dire in "lista d'attesa".

Quando la CPU#1 avrà finito di fare i suoi porci comodi, lascerà il Giant Lock, e la CPU#2 avrà il diritto di procedere per completare il suo task in kernel mode.

Riassumendo, con questo metodo solo una CPU alla volta ha il diritto di eseguire istruzioni del kernel (mentre tutte possono eseguire istruzioni dei processi utente). Se questa soluzione può sembrare un buon compromesso all'inizio, col tempo ci si accorge che il metodo scala a fatica con più di 2 CPU, soprattutto quando i processi fanno molte richieste al kernel (ad esempio processi che sfruttano in modo intensivo le periferiche o il disco).

Molti sistemi operativi hanno seguito la strada del Giant Lock (ad esempio Linux o FreeBSD per citarne alcuni dei più eclatanti), ma dopo alcuni anni sono stati migrati pian piano verso una gestione dei lock molto più fine, per consentire a tutte le CPU di lavorare contemporaneamente in kernel mode e di bloccarne l'esecuzione parallea soltanto nei punti strettamente necessari.

Diciamo che con un Dual Core, con tipici programmi da ufficio, un kernel con GiantLock se la cava ancora piuttosto bene. Ma salendo a 4, 8, 16 o più core, con programmi che sfruttano intensamente il disco e/o le periferiche (ad esempio videogiochi 3D, programmi di montaggio video, server web, database, ecc...), il Giant Lock tende ad appiattire le prestazioni con il crescere dei core.

Secondo alcuni benchmark fatti su programmi database (PostgreSQL e MySQL, programmi che stressano tantissimo sia il disco che la rete), con FreeBSD 6.0 (che aveva ancora il Giant Lock sul solo filesystem, ma il resto del kernel era già migrato al lock "fine grained"), passando da 1 a 2 processori le prestazioni erano circa 1,6 volte maggiori; con 4 processori erano circa 3 volte maggiori e con 8 processori erano 4,5 volte maggiori. Un enorme spreco di risorse.

Con FreeBSD 7.0 (dopo l'eliminazione totale del Giant Lock), invece, 2 processori raddoppiavano di netto le prestazioni rispetto al singolo (circa 1,9 volte), con 4 processori si avevano 3,8 volte le prestazioni e con 8 processori circa 7,5 volte le prestazioni del singolo processore.

Grazie per l'attenzione. I dati relativi a FreeBSD sono dati più o meno "a memoria", eventuali imprecisioni sono da imputare alla mia svogliatezza cronica di andare a ripescare i grafici dei benchmark che ho letto l'anno scorso